万字长文讲透智能体｜智能体的架构、探索与应用

5月14日，OpenAI 的发布会深夜炸场。每一次的发布，都能给我们带来很大的震撼。在模型每半年一次大升级的前提下，如何思考、设计未来的应用架构，尤其是 Agent 的架构至关重要。

最近业务领域的应用，也是层出不穷，不仅各大模型厂商推出了自己的大模型应用 APP，之前的传统 APP 也都集成了 AI 的能力， 尤其支付宝智能助手的发布，预示着以大模型为核心技术的 AI 应用，开始逐步渗透到每个人的生活当中。

但饶是如此，截止目前应用层面尚未出现让人持续心动的现象级产品。可能一方面来讲，确实大模型技术从 ChatGPT 出现到今天也仅仅只有一年半时间，我们需要给新的产品一点耐心。但另一方面来讲，这个时代以 Copilot 为重心的业务场景落地，更适合锦上添花。毕竟就目前这一代人在经历过互联网产品的投喂之后，单单搞出点有用高效的东西，已经很难戳中他们的嗨点了。所以要出现现象级的产品，还一定得要有趣、好玩。

所以，以前的应用构建逻辑跟以后的会出现很大的不同。以前的应用是我办个事情，顺便玩个游戏。以后的应用大概率都会是找乐子的时候把事给办了。当前最典型的就是正刷着抖音，然后顺手下单购个物。

在大模型出现之前，智能体的研究主要用来扮演策略函数，解决一些具体场景中的问题，并且一般都是在隔离的环境中进行。直到大模型发布，智能体开始出现井喷式爆发发展。尤其在2023年随着AutoGPT、BabyAGI、MetaGPT、ChatDev、AutoGen等开发框架的出现，智能体的研究与应用浪潮被推到了一个崭新的高度。

今天，智能体被认为是实现通用人工智能(AGI)的一种最具潜力的方案，已经在技术圈形成了一定的共识。但对于构建Agent与大规模应用来讲，还有很长的路要走，因为Agent的构建需要像人一样，需要具备持续自我进化的能力。为了弥补LLM和自主智能体之间的差距，一个关键的步骤是设计Agent的架构来缩小大语言模型与人类的差距。沿着这个思路，先前的开发者们已经开发了很多模块化的工具来弥补这些工作，典型的如Langchain、Llama-index等。但这些早期的框架主要是聚焦在工具链的使用，缺少从Agent架构层面系统的设计。

经过对一系列的Agent框架与理论的研究，根据《A survey on large language model based autonomous agents》智能体综述文章我们总结出Agent核心具备的几个核心特性与模块。

• Profile模块: Profile模块，Profile模块的目的主要是做Agent角色认定，回答的核心问题有: 我是谁？我在哪？我该干什么？无论是在当前的人与人之间的协同，还是人与智能体的协同，亦或是智能体与智能体间的协同。

• Memory模块:  Memory即记忆模块，主要用来存储、获取、检索信息。

• Planning模块:  制定计划，可以根据过去的行为与目标动态规划下一步的行动

• Action模块: 执行模块，执行智能体的具体决策。

Profile模块

自主智能体通常是通过假定特殊的角色来进行解决问题。比如编程专家、老师、领域专家。Profile模块目的就是设定智能体的角色，做角色认定。通常通过Prompt来进行指定，通过角色认定可以影响大模型的行为。智能体的Profile通常会说明其年龄、职业、心理、社会关系等信息。

角色认定是一种重要的社会和组织机制，通过明确个体在特定系统或环境中的地位和职责，有助于维护秩序、提升效率和促进合作。当然在实际应用中，描述代理信息取决于具体的业务场景。

下面是一个确认Profile的例子, 主要分为以下几个方面:

• 命名，即每个智能体都有一个名称作为代号，如Visionary

• 角色,  设定智能体的角色定义，比如Reporter

• 目标,  设定智能体的目标: Read the provided historical messages, collect various analysis SQLs, from them, and assemble them into professional reports.

• 性格、社会关系等约束条件设定。You are only responsible for collecting and sorting out the analysis  SQL that already exists in historical messages, and do not generate any analysis sql yourself. etc

profile: ProfileConfig = ProfileConfig(name=DynConfig("Visionary",category="agent",key="dbgpt_agent_expand_dashboard_assistant_agent_profile_name",),role=DynConfig("Reporter",category="agent",key="dbgpt_agent_expand_dashboard_assistant_agent_profile_role",),goal=DynConfig("Read the provided historical messages, collect various analysis SQLs ""from them, and assemble them into professional reports.",category="agent",key="dbgpt_agent_expand_dashboard_assistant_agent_profile_goal",),constraints=DynConfig(["You are only responsible for collecting and sorting out the analysis ""SQL that already exists in historical messages, and do not generate ""any analysis sql yourself.","In order to build a report with rich display types, you can ""appropriately adjust the display type of the charts you collect so ""that you can build a better report. Of course, you can choose from ""the following available display types: {{ display_type }}","Please read and completely collect all analysis sql in the ""historical conversation, and do not omit or modify the content of ""the analysis sql.",],category="agent",key="dbgpt_agent_expand_dashboard_assistant_agent_profile_constraints",),desc=DynConfig("Observe and organize various analysis results and construct ""professional reports",category="agent",key="dbgpt_agent_expand_dashboard_assistant_agent_profile_desc",),)

当然完成上述工作才是自主Agent构建的开始，后续我们需要持续给Agent构建档案，让其具备完整的"人格"与角色认定。为什么一定要构建档案与角色认定，大家不妨回顾一下。我们人类的培养与成长，伴随一生的一个核心命题就是做角色认定，而档案是角色认定非常重要的一环。档案的构建是一个持续的过程，一般会用到如下一些方法：

• 手工制作法: eg: "你是一个外向的人"，"你是一个数据库专家"。

• 大模型生成法: 给定一些关键词，让大模型辅助生成。

• 数据集对齐法: 在这种方法下，智能体的Profile通过真实世界的数据集来持续构建。

Memory模块

Memory模块在Agent架构中，扮演非常重要的角色。它存储环境以及先前对话记忆，并指导下一步的行动。记忆模块可以帮助智能体积累经验，自进化，变成一个更一致、更具逻辑、更高效的"人"。

下面我们从记忆模块结构、格式以及操作几个层面介绍。

记忆结构：基于大模型的自主代理通常结合源自人类记忆过程，基于人类对认知科学研究的原理和机制。

人类记忆遵循从纪录知觉输出的感觉——短期记忆，在到长期信息巩固的长期记忆。

• 短期记忆: 受限于大语言模型上下文窗口的制约。

• 长期记忆：类似于外部向量存储，智能体可以根据需要快速查询和检索。

• Unified Memory: 类似人类的短期记忆，，通常通过上下文来学习，一般直接写在Prompt里面。

• Hybrid Memory: 混合记忆基于人类的短期记忆和长期记忆进行建模。短期记忆纪录最近的信息，长期记忆纪录整个生命周期里面最重要的信息。比如短期记忆包括Agent当前情况下上下文的信息，长期记忆存储过去的行为和思考，长期记忆可以通过当前的事件进行检索。

记忆格式：自然语言记忆与Embedding记忆

• 自然语言：在这种格式下，记忆直接通过自然语言描述。

• Embedding: 在这种格式下，记忆直接通过Embedding向量来存储。

• 数据库：记忆信息被存储在数据库中，允许智能体更高效、全面操纵记忆。

• 链式结构：链表、树

记忆操作: 记忆模块通过与环境的交互来获取、积累、利用重要知识。

• 记忆读: 从记忆中抽取有用的信息。抽取维度有Recent、Relevance、Importance

• 记忆写: 将感知环境的信息写入到记忆存储中。

• 记忆反思：记忆反思模仿人类见证评估自己认知、情感和行为过程的能力。

Planning 模块

当面临复杂任务时，人类倾向于将其构造为简单的子任务并且独立进行解决。计划模块的目的是通过类人的能力，让Agent的行为更具逻辑性、更强大、更可信。我们可以根据是否需要人类反馈对计划过程进行分析。

没有反馈的计划制定

在此方法中，agent不会接收反馈对未来的行动做出调整。

• 单路径推理: 此策略中，最终的任务被分解为几个步骤，这些步骤被级链方式进行连接。每一步只有一个子步骤，LLM遵循这些步骤完成最终的目标。

• 多路径推理：此方法中，推理步骤生成的最终计划是一棵数结构，其中每一步可能会有多个子步骤，这个方法类似于人类的思考，在每一步上会有多个选择。CoT(Chain Of Thoughts认为每个复杂问题都有多种思维方式来推导出最终答案。因此通过CoT的方式生成一系列的推理步骤。多路径推理中常用的方法有CoT(Chain Of Thoughts)、ToT(Tree Of Thoughts)、GoT(Graph Of Thoughts)、AoT(Algorithm of thoughts)等。在每个步骤中，他们首先生成多个可能的后续步骤，然后根据可接收的行动的距离来确定最终步骤。

有反馈的计划制定

在许多真实场景中，Agent需要制定长远的计划解决复杂问题。面对这些任务时，没有反馈的计划模块由于下面的原因很难制定正确的计划。

• 首先从一开始制定一个完美的计划非常困难，因为它需要各种复杂的前提条件，所以仅仅简单遵循初始计划大概率会导致失败。

• 计划的执行也会遇到非预期的行为与输出。

• 外部真实环境与人类的反馈能够及时纠正Agent可能的犯错。

Action 模块

Action模块负责将智能体的决策转化为具体的结果。该模块一般直接与环境交互。会受到profile、memory和计划模块的影响。

• Action的目标：动作的意图？

• 完成任务
• 交流
• 环境探测

• Action的生成：Action是如何生成的？

• 通过记忆，该Action是通过从Memory中抽取信息来生成的。
• 通过计划遵循

• Action的行动空间：哪些action可用？

• 拓展工具: APIs、Database & KBQA、拓展模型
• LLMs内在知识

  基于预训练的知识，LLMs本身具备规划能力

• Action的影响:  -> before action, in-action, after-action

Agent能力的获取

• 通过微调(Capability acquisition with fine-tuning)
• Prompt工程
• 设计适当的agent进化机制.  (机制工程)

• 反复试验
• 群众智慧
• 经验积累
• 自我驱动进化

为什么需要编排

大语言模型已经在特定领域具备了生成有效计划的能力，为什么还需要编排？在技术理念上，我们认为智能体的应用主要有两种场景。1. 比较开放性的问题，比如制定一个旅行计划，这类问题的编排可以用智能体AutoPlan  2.但绝大多数场景是有固定流水线的，尤其在工业尤为明显。这类确定性的领域，需要有智能体的确定性编排。

此外计划与编排是人类协作与管理的基础。智能体要参与到人类生产、生活当中，必然需要遵循人类社会的规则， 需要有一套统一的架构管理编排。

什么是AWEL（智能体编排语言）？

AWEL（Agentic Workflow Expression Language）是一套专为大模型应用开发设计的智能体工作流表达语言，它提供了强大的功能和灵活性。AWEL通过设计标准输入、输出来定义Agent之间的交互协议，通过编排让Agent之间的协作更加高效。

通过 AWEL API 您可以专注于大模型应用业务逻辑的开发，而不需要关注繁琐的模型和环境细节，AWEL 采用分层 API 的设计， AWEL 的分层 API 设计架构如下图所示：

AWEL分层设计

AWEL在设计上分为三个层次，依次为算子层、AgentFrame层以及DSL层，以下对三个层次做简要介绍。

• 算子层

算子层是指LLM应用开发过程中一个个最基本的操作原子，比如在一个RAG应用开发时。检索、向量化、模型交互、Prompt处理等都是一个个基础算子。在后续的发展中，框架会进一步对算子进行抽象与标准化设计。可以根据标准API快速实现一组算子。

• AgentFrame层

AgentFrame层将算子做进一步封装，可以基于算子做链式计算。这一层链式计算也支持分布式，支持如filter、join、map、reduce等一套链式计算操作。后续也将支持更多的计算逻辑。

• DSL层

DSL层提供一套标准的结构化表示语言，可以通过写DSL语句完成AgentFrame与算子的操作，让围绕数据编写大模型应用更具确定性，避免通过自然语言编写的不确定性，使得围绕数据与大模型的应用编程变为确定性应用编程。

Agent 在 DB-GPT 项目中的定位

如下图所示， 在DB-GPT项目中，Agent是一等公民。其他如SMMF(多模型管理)、RAGs、数据源、插件、工具、可视化组件等都是Agent所依赖的资源。

expand包下面主要是具体的Agent的实现，DB-GPT默认内置了代码助手、数据分析助手、SQL助手、插件助手、图表助手、知识库助手等智能体。

在Core包下agent.py文件中，对Agent做的接口做了定义与抽象。一个Agent主要包含以下核心方法:

• Agent: 基类，用来表征Agent

• send: 发送消息

• receive: 接收消息

• generate_reply: 生成响应

• thinking: 思考&反思

• review: 结果审查

• act: 执行

• verify: 校验

• name: 名称

• role: 角色认定

• desc: 描述

• AgentContext：Agent依赖的上下文

• AgentGenerateContext: Agent依赖的上下文

• AgentReviewInfo: Agent审查信息

• AgentMessage: Agent消息处理

• AgentManage: 对Agent进行管理，主要是Agent的注册与发现。

base_agent.py文件中实现了ConversableAgent，ConversableAgent继承了Agent、Role两个父类，并对通用方法做了实现。后续在具体Agent实现上，可以直接继承ConversableAgent

Thinking方法

Thinking方法基于历史的消息与记忆来推理完成当前目标需要做的具体行动，会根据上一次执行的错误信息进行反思重试，一般会重试3次。

资源bind

bind方法会绑定Agent所依赖的资源，包括模型、记忆、知识库、插件、数据源和工具等。

Agent构建

build方法会完成一个Agent的构建工作，会前置检查Agent的可用性，并做资源的预加载与初始化。

Profile核心是做Agent的角色认定，所以在实现上比较简洁。重心是如何持续围绕大模型构建好Prompt以及Agent档案。

VALID_TEMPLATE_KEYS = {"role","name","goal","resource_prompt","expand_prompt","language","constraints","examples","out_schema","most_recent_memories","question",}
_DEFAULT_SYSTEM_TEMPLATE = """You are a {{ role }}, {% if name %}named {{ name }}, {% endif %}your goal is {{ goal }}.Please think step by step to achieve the goal. You can use the resources given below. At the same time, please strictly abide by the constraints and specifications in IMPORTANT REMINDER.{% if resource_prompt %} {{ resource_prompt }} {% endif %}{% if expand_prompt %} {{ expand_prompt }} {% endif %}
*** IMPORTANT REMINDER ***{% if language == 'zh' %}Please answer in simplified Chinese.{% else %}Please answer in English.{% endif %}
{% if constraints %}{% for constraint in constraints %}{{ loop.index }}. {{ constraint }}{% endfor %}{% endif %}
{% if examples %}You can refer to the following examples:{{ examples }}{% endif %}
{% if out_schema %} {{ out_schema }} {% endif %}"""# noqa
_DEFAULT_USER_TEMPLATE = """{% if most_recent_memories %}Most recent observations:{{ most_recent_memories }}{% endif %}
{% if question %}Question: {{ question }}{% endif %}"""
_DEFAULT_SAVE_MEMORY_TEMPLATE = """{% if question %}Question: {{ question }} {% endif %}{% if thought %}Thought: {{ thought }} {% endif %}{% if action %}Action: {{ action }} {% endif %}{% if observation %}Observation: {{ observation }} {% endif %}"""

如下图目录结构所示，Memory模块里面，我们实现了前面提到的短记忆、长记忆、混合记忆等多种方式。同时也实现了Memory的核心操作接口，比如存储、读、写、裁剪、清理、重要性计算等。

写混合Memory

这里我们以混合记忆为例，介绍一下记忆的读写操作，如下图所示是写的过程。

首先会将感知记忆写入到存储当中，然后获取并写短期记忆，最后写长期记忆。在这个过程中，会同时更新记忆的重要性指标。

读混合Memory

读的过程也类似，首先读长期记忆，然后读短期记忆。

计划与编排，主要实现了三种方式的编排。

• single_agent，即完成单一的目标。
• auto-plan: 根据一个目标进行拆分，然后分发给多Agent协作完成。
• AWEL: 基于工作流的人为编排。
  
  

  

Action是一个智能体决策的具体执行，一般需要根据具体的场景来进行具体实现。代码中我们定义了通用的接口与方法，结合场景的实现需要根据实际情况进行编写。

这里我们来介绍一个简单的SQL-Agent的实现，主要具备根据RAG + 数据源 + Text2SQL能力实现SQL生成、翻译、优化等工作。

实现数据SQL-Agent

这里我们实现了一个简单的SQL助手，由于我们的目的主要是SQL生成、翻译、优化，所以我们制定的Action是一个空Action。

"""SQL Assistant Agent.
Use RAG and Schema-Linking, which can generate,translate,and correct SQL based on user questions."""
import asynciofrom dbgpt.agent import BlankAction, ConversableAgent, DynConfig, ProfileConfig

class SQLAssistantAgent(ConversableAgent):"""SQL Agent Use RAG and Schema-Linking."""
profile: ProfileConfig = ProfileConfig(name=DynConfig("kevin",category="agent",key="dbgpt_agent_expand_sql_expert_name",),role=DynConfig("SQLExpert", category="agent", key="dbgpt_agent_expand_sql_expert_name_role"),goal=DynConfig("SQL generation, SQL translate, SQL diagnostics",category="agent",key="dbgpt_agent_expand_sql_expert_name_goal",),constraints=DynConfig(["""You are a SQL expert who can generate, translate,and correct SQL based on user questions.If the user's input is not related to SQL,you need to prompt the user to output SQL-related content."""],category="agent",key="dbgpt_agent_expand_sql_expert_profile_constraints",),desc=DynConfig("""You are a SQL expert who can generate, translate,and correct SQL based on user questions.""",category="agent",key="dbgpt_agent_expand_sql_expert_profile_desc",),)
def __init__(self, **kwargs):"""Create a new SQLAssistantAgent."""super().__init__(**kwargs)self._init_actions([BlankAction])

SQL Agent 还需要一个数据库连接作为依赖的资源，这里我们创建一个SQLite表：

def _create_temporary_connector():"""Create a temporary database connector for testing."""from dbgpt.datasource.rdbms.conn_sqlite import SQLiteTempConnector
connector = SQLiteTempConnector.create_temporary_db()connector.create_temp_tables({"user": {"columns": {"id": "INTEGER PRIMARY KEY","name": "TEXT","age": "INTEGER",},"data": [(1, "Tom", 10),(2, "Jerry", 16),(3, "Jack", 18),(4, "Alice", 20),(5, "Bob", 22),],}})return connector

构建Agent，绑定资源并做初始化。

async def main():from dbgpt.agent import AgentContext, AgentMemory, UserProxyAgent, LLMConfigfrom dbgpt.agent.resource import RDBMSConnectorResourcefrom dbgpt.model.proxy import OpenAILLMClient
agent_memory = AgentMemory()
llm_client = OpenAILLMClient(model_alias="gpt-3.5-turbo")context: AgentContext = AgentContext(conv_id="sql_agent")
connector = _create_temporary_connector()sqlite_resource = RDBMSConnectorResource("SQLite Database", connector=connector)
user_proxy = await UserProxyAgent().bind(agent_memory).bind(context).build()sql_agent = (await SQLAssistantAgent().bind(context).bind(LLMConfig(llm_client=llm_client)).bind(sqlite_resource).bind(agent_memory).build())
await user_proxy.initiate_chat(recipient=sql_agent,reviewer=user_proxy,message="What is the name and age of the user with age less than 18",)
print(await agent_memory.gpts_memory.one_chat_completions("sql_agent"))

if __name__ == "__main__":asyncio.run(main())

本Agent中，我们准备了两类资源。1. 知识库  2. 数据库。知识库里面主要对一些字段与上下文进行描述。

更多关于Agent的教程，正在更新中，尽情期待。

在Agent的应用方面，我们主要聚焦在数据基础设施、数据分析与基础设施运维等领域。涉及的Agent主要有智能问答Agent、SQL-Agent、数据分析Agent、诊断Agent、风险分析Agent、运维Agent等场景。当然也包括一些完全基于Multi-Agent Auto-plan的智能体实现。

有很多有趣的尝试，但也遇到非常多的挑战。包括但不限于

• 意图识别: 如何准确理解用户的意图，并匹配到对应的Agent

• Agent-Linking: 多Agent如何提供一个统一的入口，回答多个领域专业问题的同时，还可以自由对话。如一个对话智能体Kevin后面，可以进行多种任务对话，比如智能问答，SQL-生成、诊断、运维&API调用、自由对话等。

• 召回准确率：如何准备高质量的问答与知识库，结合多种RAG检索技术，准确召回相关内容。

• 多轮对话进行参数补充: 比如在意图识别中，用户单次的对话无法满足场景的参数需求，需要智能体反问用户达到槽位填充的目的。

Agent的评估分为两种方式。1. 主观评估 2. 客观评估

主观评估Agent能力主要是基于人类的判断。一般适用于没有评测数据集或者很难设计高质量的指标的场景。比如说评估Agent的智力与用户友好性。下面我们介绍两种普通的主观评估策略

1. 人工标注: 与人类的直接评分和排序相关。

2. 图灵测试

因为自主Agent是被人类设计满足人类需求的，因此人类的主观测试非常重要。同时也会面临非常多的问题，比如高成本、低效、偏见。为了解决这些问题，越来越多的研究人员正在研究试用LLM本身进行主观评价。

• 评估指标
• 协议
• benchmarks

指标

1. 任务成功率指标
2. 人类相似度指标
3. 效率指标

协议&Benchmarks

1. 真实世界的评估
2. 社会评估
3. 多任务评估：人类使用一组来自不同领域的任务来进行评估。
4. 软件测试

随着模型效果越来越强，自主智能体的实现越来越成为可能。但是面向未来，随着模型效果每半年一次的大迭代，设计Agent架构以及构建Agent应用时，需要充分考虑Agent进化与迭代的机制。同时，虽然当下在Agent的构建中，大家更多关注的是Plan，但角色认定、长期记忆等在人类交互中最基本的要求，或许应该花更多的精力。另外，当下关于Agent开发的框架跟平台很多，但观察整个演变的趋势，很难由一套架构或者平台统一所有的应用。因此统一架构理念，设计合理的注册与交互协议，也是框架跟平台需要重点考虑的。

总之自主智能体这场冒险刚刚开始，对未来必然会面对的新物种，特别期望大家能够躬身入局，一起探索，一起尝试。