Agent概述 | Civilization Museum

type

Post

status

Published

password

date

May 12, 2026

slug

summary

概述

Agent：你给一个目标，它自己查资料、做计划、分步执行、自动纠错，直到把事做完。

两种模式

ReAct 模式（Reason + Act）

走一步、想一步、看一步。Thought（思考）→ Action（行动）→ Observation（观察）→ 重复

Reason（思考）我现在要干嘛？缺什么信息？下一步该做什么？

Act（行动）去查资料、调用工具、计算、搜索

Observe（观察）结果对不对？够不够？要不要继续？

💡

适合：信息不固定、需要实时查、实时决策的场景

Plan-And-Execute

先把完整方案想清楚，再一步步执行。

Plan（规划）把任务拆成步骤：1）做什么2）做什么3）做什么4）最后怎么验收

Execute（执行）按步骤一条条执行，可能会微调，但大方向不变

💡

适合复杂、长流程、目标明确的任务，不容易跑偏

Docs by LangChainPrebuilt middleware - Docs by LangChain

Prebuilt middleware - Docs by LangChain

Prebuilt middleware for common agent use cases

workflow与agent

Workflow 是让 AI 按部就班地执行指令，而 Agent 则是赋予 AI 自由度去自主达成目标。

工作流是一种传统的自动化范式，其核心是对一系列任务或步骤进行预先定义的、结构化的编排。它本质上是一个精确的、静态的流程图，规定了在何种条件下、以何种顺序执行哪些操作。一个典型的案例：某企业的费用报销审批流程。员工提交报销单（触发）-> 如果金额小于 500 元，直接由部门经理审批 -> 如果金额大于 500 元，先由部门经理审批，再流转至财务总监审批 -> 审批通过后，通知财务部打款。整个过程的每一步、每一个判断条件都被精确地预先设定。

基于大型语言模型的智能体是一个具备自主性的、以目标为导向的系统。它不仅仅是执行预设指令，而是能够在一定程度上理解环境、进行推理、制定计划，并动态地采取行动以达成最终目标。一个典型的例子，是智能旅行助手。当我们向它下达一个新指令，例如：“你好，请帮我查询一下今天北京的天气，然后根据天气推荐一个合适的旅游景点。” ；智能旅行助手通过"感知-思考-行动-观察"的闭环循环自主完成任务：首先感知用户查询天气并推荐景点的请求，经思考后自主调用天气工具获取北京晴天信息，随后基于天气上下文再次思考并调用景点工具获取推荐，最后在收集足够信息后综合生成包含天气状况和景点建议的完整答复并结束任务，整个过程展现了智能体从任务分解、工具选择到上下文理解的完整自主决策能力。

从零实现Agent

提示词说明

工具

读取文件

写入文件

运行终端命令

数据流

工具

一个良好定义的工具应包含以下三个核心要素：

名称 (Name)：一个简洁、唯一的标识符，供智能体在 Action 中调用，例如 Search。

描述 (Description)：一段清晰的自然语言描述，说明这个工具的用途。这是整个机制中最关键的部分，因为大语言模型会依赖这段描述来判断何时使用哪个工具。

执行逻辑 (Execution Logic)：真正执行任务的函数或方法。

自定义工具类

当智能体需要使用多种工具时（例如，除了搜索，还可能需要计算、查询数据库等），我们需要一个统一的管理器来注册和调度这些工具。为此，我们创建一个 ToolExecutor 类。

使用

模式

ReAct

ReActAgent 的核心是一个循环，它不断地“格式化提示词 -> 调用LLM -> 执行动作 -> 整合结果”，直到任务完成或达到最大步数限制。

从零实现Agent

ReAct示例

优点

高可解释性：ReAct 最大的优点之一就是透明。通过 Thought 链，我们可以清晰地看到智能体每一步的“心路历程”——它为什么会选择这个工具，下一步又打算做什么。这对于理解、信任和调试智能体的行为至关重要。

动态规划与纠错能力：与一次性生成完整计划的范式不同，ReAct 是“走一步，看一步”。它根据每一步从外部世界获得的 Observation 来动态调整后续的 Thought 和 Action。如果上一步的搜索结果不理想，它可以在下一步中修正搜索词，重新尝试。

工具协同能力：ReAct 范式天然地将大语言模型的推理能力与外部工具的执行能力结合起来。LLM 负责运筹帷幄（规划和推理），工具负责解决具体问题（搜索、计算），二者协同工作，突破了单一 LLM 在知识时效性、计算准确性等方面的固有局限。

ReAct 的固有局限性

对LLM自身能力的强依赖：ReAct 流程的成功与否，高度依赖于底层 LLM 的综合能力。如果 LLM 的逻辑推理能力、指令遵循能力或格式化输出能力不足，就很容易在 Thought 环节产生错误的规划，或者在 Action 环节生成不符合格式的指令，导致整个流程中断。

执行效率问题：由于其循序渐进的特性，完成一个任务通常需要多次调用 LLM。每一次调用都伴随着网络延迟和计算成本。对于需要很多步骤的复杂任务，这种串行的“思考-行动”循环可能会导致较高的总耗时和费用。

提示词的脆弱性：整个机制的稳定运行建立在一个精心设计的提示词模板之上。模板中的任何微小变动，甚至是用词的差异，都可能影响 LLM 的行为。此外，并非所有模型都能持续稳定地遵循预设的格式，这增加了在实际应用中的不确定性。

可能陷入局部最优：步进式的决策模式意味着智能体缺乏一个全局的、长远的规划。它可能会因为眼前的 Observation 而选择一个看似正确但长远来看并非最优的路径，甚至在某些情况下陷入“原地打转”的循环中。

调试技巧

当你构建的 ReAct 智能体行为不符合预期时，可以从以下几个方面入手进行调试：

检查完整的提示词：在每次调用 LLM 之前，将最终格式化好的、包含所有历史记录的完整提示词打印出来。这是追溯 LLM 决策源头的最直接方式。

分析原始输出：当输出解析失败时（例如，正则表达式没有匹配到 Action），务必将 LLM 返回的原始、未经处理的文本打印出来。这能帮助你判断是 LLM 没有遵循格式，还是你的解析逻辑有误。

验证工具的输入与输出：检查智能体生成的 tool_input 是否是工具函数所期望的格式，同时也要确保工具返回的 observation 格式是智能体可以理解和处理的。

调整提示词中的示例 (Few-shot Prompting)：如果模型频繁出错，可以在提示词中加入一两个完整的“Thought-Action-Observation”成功案例，通过示例来引导模型更好地遵循你的指令。

尝试不同的模型或参数：更换一个能力更强的模型，或者调整 temperature 参数（通常设为0以保证输出的确定性），有时能直接解决问题。

Plan-and-Solve

Plan-and-Solve 将整个流程解耦为两个核心阶段。

规划阶段 (Planning Phase)：首先，智能体会接收用户的完整问题。它的第一个任务不是直接去解决问题或调用工具，而是将问题分解，并制定出一个清晰、分步骤的行动计划。这个计划本身就是一次大语言模型的调用产物。

执行阶段 (Solving Phase)：在获得完整的计划后，智能体进入执行阶段。它会严格按照计划中的步骤，逐一执行。每一步的执行都可能是一次独立的 LLM 调用，或者是对上一步结果的加工处理，直到计划中的所有步骤都完成，最终得出答案。

Plan-and-Solve示例

Plan_and_solve.py

7.2 KiB

Planner

Executor

优点

大幅提升复杂推理准确率：先规划步骤，再一步步执行，减少跳跃、漏算、逻辑断层，数学题、逻辑题正确率显著更高。

减少幻觉（Hallucination）：模型必须先列出可验证的步骤，再基于步骤推导，不容易凭空编造答案。

缺点吧

模型规划的步骤可能不合理、缺步骤、顺序错，后面执行再完美也没用。（可以加入re plane模块解决这个问题）

只会按步骤走，缺乏灵活变通，遇到非常规问题反而不如直接推理。

Reflection

Reflection 机制的核心思想，正是为智能体引入一种事后（post-hoc）的自我校正循环，使其能够像人类一样，审视自己的工作，发现不足，并进行迭代优化。

Reflection示例

优点

解决方案质量显著提升，能够将初始方案从"合格"优化为"优秀"，实现从功能正确到性能高效、从逻辑粗糙到逻辑严谨的跃迁。

鲁棒性与可靠性增强，通过内部自我纠错循环，能够发现并修复逻辑漏洞、事实性错误和边界情况处理不当等问题，大大提高最终结果的可靠性。

缺点

模型调用成本增加，每轮迭代至少需要额外调用两次大语言模型，多轮迭代会导致API调用成本和计算资源消耗成倍增长；

任务延迟显著提高，串行过程使得总耗时延长，不适合对实时性要求高的场景；

提示工程复杂度上升，需要为"执行"、"反思"、"优化"等不同阶段设计和调试高质量、有针对性的提示词，增加了开发工作量。

记忆

helloAgent记忆设计

基于 helloagent 项目的设计与实现逻辑，解析智能体（Agent）的记忆机制及核心工作原理。

MemoryTool

ㅤ	工作记忆	情景记忆	语义记忆	感知记忆
概述	将短期、临时的记忆存储在内存中。具有容量有限、时效性强的特点，自动删除超时记忆。	通过内存缓存、SQLite数据库和向量数据库(Qdrant)，以实现高效的记忆管理。	结合了向量检索和图数据库技术，实现了一种混合的语义记忆存储和检索机制。	存储多模态记忆。
添加	移除过期记忆，添加新的记忆到内存中	添加新的记忆到内存、sqlite、向量数据库中	提取实体与关系，将其存储在图数据库中；对记忆内容进行向量化处理添加到向量数据库。	添加新的记忆到内存、sqlite、向量数据库中。
检索	移除过期记忆，按照user_id进行过滤，通过TFIDF+关键字进行检索	可选参数用户id、会话id、检索时间范围、重要性进行通过sql初步筛选；然后通过向量进行优选；最后根据获取到的memory_id从sqllite中读取完整信息。	根据查询从向量数据库中检索，从图数据库中进行检索；合并两种检索结果。	根据查询从向量数据库中检索；然后根据重要度、时间等进行筛选；最后从sqlite中提取完整数据。
更新	更新内存中指定记忆的内容、重要性、元数据	ㅤ	ㅤ	ㅤ
遗忘	自动删除超时的记忆	ㅤ	ㅤ	ㅤ
删除	从内存中删除指定的记忆项	ㅤ	ㅤ	ㅤ
获取记忆统计信息	获取记忆数量、容量使用情况等	ㅤ	ㅤ	ㅤ
计算记忆重要性	ㅤ	ㅤ	ㅤ	ㅤ
用途	ㅤ	例如在rag中添加文件的时候，可以使用情景记忆。2024年添加《深度学习》文件到rag中	ㅤ	ㅤ

💡

默认记忆重要度计算方法：通过预设的关键词列表（如"重要"、"错误"等）来检测文本内容中的特定触发词。若内容包含任一关键词，系统判定其具有较高优先级，并将重要性评分提升0.2。

💡

整合记忆：从一种记忆转换为另一种记忆。例如从工作记忆转换成情景记忆。

工作记忆

情景记忆

语义记忆

感知记忆

RAG系统

OpenClaw记忆

上下文工程

上下文工程（Context Engineering）关注的是“在每一次模型调用前，如何以可复用、可度量、可演进的方式，拼装并优化输入上下文”，从而提升正确性、鲁棒性与效率。

方案	核心机制	示例	适用复杂度
压缩整合 (Compaction)	事后清理：对话接近上限时，高保真总结历史并重启新窗口	使用llm对一份万字技术文档进行总结	中低（单任务、线性流程）
结构化笔记 (Structured Note)	外部持久化：定期写入非易失存储，按需检索	将关键结论、等写入外部文件。每次对话从外部 “召回” 当前需要的信息	中高（长期项目、多步骤任务）
子代理架构 (Sub-agent)	主代理做规划，子代理深挖具体任务并仅回传摘要	主代理将复杂任务拆解，让一个子代理专门查金融数据，一个子代理查房产政策，最后只把凝练的 1000-2000 字结论回传给主代理	高（复杂研究、多模块并行开发）

helloAgent的上下文工程

ContextBuilder

输出结果

NoteTool

NoteTool 是为"长时程任务"提供的结构化外部记忆组件。它以 Markdown 文件作为载体，头部使用 YAML 前置元数据记录关键信息，正文用于记录状态、结论、阻塞与行动项等内容。

💡

搜索笔记时，检查笔记的 title、content、tags 是否包含查询关键词。

markdown存储示例

笔记索引

TerminalTool

即时访问和探索文件系统。允许智能体执行命令是一个强大但危险的能力。TerminalTool 通过多层安全机制确保系统安全：

命令白名单：只允许安全的只读命令，完全禁止任何可能修改系统的操作。

工作目录限制：TerminalTool 只能访问指定的工作目录及其子目录，无法访问系统其他部分：

超时控制：每个命令都有执行时间限制，防止无限循环或资源耗尽。

输出大小限制：限制命令输出的大小，防止内存溢出。

通信协议

mcp：智能体与外部工具/资源的通信方式，智能体需要访问文件系统、数据库、GitHub、Slack 等各种服务。mcp没有规定client与大模型之间的协议规范。

A2A：实现智能体之间的点对点通信。与 MCP 关注智能体与工具的通信不同，A2A 关注的是智能体之间如何相互协作。

ANP：如果说 MCP 解决的是"如何访问工具"，A2A 解决的是"如何与其他智能体对话"，那么 ANP 解决的是"如何在大规模网络中发现和连接智能体"。

MCP

智能体与外部工具/资源的通信方式，智能体需要访问文件系统、数据库、GitHub、Slack 等各种服务。mcp没有规定client与大模型之间的协议规范

helloAgent使用MCP

第一步：LLM输入输出

第二步：解析工具

第三步：MCP执行结果

579

第四步、拼接MCP结果

MCP Inspector

安装

启动

http

A2A

传统的中央协调器（星型拓扑）方案存在三个主要问题：

单点故障：协调器失效导致系统整体瘫痪。

性能瓶颈：所有通信都经过中心节点，限制了并发。

扩展困难：增加或修改智能体需要改动中心逻辑。

A2A 协议采用点对点（P2P）架构（网状拓拓），允许智能体直接通信，从根本上解决了上述问题。

helloAgent使用A2A

第一步、LLM输入

第二步、解析工具

第三步、A2A执行结果

第四步、拼接执行结果

第五步、解析工具

第六步、A2A执行结果

第七步、拼接执行结果

第八步、解析工具

第九步、工具返回结果

通过 HTTP POST 请求调用函数并返回执行结果。

输出结果

第十步、拼接结果并返回答案

ANP

💡

与A2A协议类似，主要区别在于ANP支持在协议内部进行身份认证。A2A只能通过第三方进行认证。

Agentic RL训练

智能体在不断变化的环境中与外部世界交互，执行多步行动来完成复杂任务，并根据过程中得到的反馈调整下一步决策，其优化目标为长期累积奖励，而非单步即时奖励。

例如：在 Agentic RL 场景中，用户提出 “分析某 GitHub 仓库代码质量” 的需求后，智能体将分步执行任务：调用 GitHub API 获取仓库信息，完成后获得 0.1 奖励；读取核心代码文件并获取内容，获得 0.1 奖励；完成代码质量分析，获得 0.2 奖励；最终生成高质量分析报告，获得 0.6 奖励。总奖励为各步骤奖励之和，总计 1.0。

数据集格式

helloAgent的数据集

SFT数据格式

RL数据格式

奖励函数

奖励函数的设计直接影响训练效果。好的奖励函数应该能清楚地定义什么是成功、不会产生过大的方差、容易调整和组合。糟糕的奖励函数可能只在任务结束时给奖励，中间步骤无反馈、存在奖励欺骗，使得智能体找到"作弊"方式获得高奖励、多个目标相互矛盾、方差过大，训练不收敛。

helloAgent的奖励函数

准确率奖励

准确率奖励(AccuracyReward)是最基础的奖励函数，它只关心答案是否正确。数学定义为:

其中是模型生成的答案，是正确答案。这是一个二值奖励函数，答案正确得 1 分，错误得 0 分。

长度惩罚

长度惩罚(LengthPenaltyReward)鼓励模型生成简洁的回答，避免冗长啰嗦。数学定义为:

其中是生成文本的长度(字符数或 token 数)，是目标长度，是惩罚系数(默认 0.001)。只有在答案正确的情况下才应用长度惩罚，避免模型为了减少惩罚而生成错误的短答案。

💡

设计思路是：如果答案错误，奖励为 0 ；如果答案正确且长度合理，奖励为 1；如果答案正确但过长，奖励为。

步骤奖励

步骤奖励(StepReward)鼓励模型生成清晰的推理步骤，提高可解释性。数学定义为：

其中是检测到的推理步骤数量，是步骤奖励系数(默认 0.1)。同样，只有在答案正确的情况下才给予步骤奖励。

💡

步骤检测方法包括:查找"Step 1:"， "Step 2:"等标记、查找换行符数量、使用正则表达式匹配推理模式。步骤奖励最大max score分

SFT

SFT 的作用是教会模型任务的基本规则。首先，学习输出格式，让模型知道如何组织答案(如使用"Step 1"， "Final Answer"等标记)。其次，学习推理模式，通过示例学习如何分解问题、逐步推导。再次，建立基线能力，为后续的强化学习提供一个合理的起点。最后，减少探索空间，强化学习不需要从零开始，可以在 SFT 的基础上优化。

helloAgent

原始文本

输入

label

损失函数

交叉熵损失函数，使用Qwen3版本的交叉熵损失函数。

RL

helloAgent

原始文本

输入

label

使用大模型生成多个结果。后续分析每个结果好，让模型向着好的结果进行迭代。

序号	内容
0	“<think>\nOkay, let me try to figure out how much money Betty needs to buy her new wallet. So, the problem says that Betty has half of the money she needs for the wallet. The wallet costs $100, so she needs $100 in total. But she only has half of that. Let me write that down.\n\nFirst, the total amount needed is $100. Betty has half of that, so she has 1/2 * 100 = $50. Then, her parents decided to give her $15 for that purpose. So adding that to her current money, her total would be 50 + 15 = $65. \n\nAfter that, her grandparents gave her twice as much as her parents. Her parents gave her $15, so twice that would be 2 * 15 = $30. Adding that to her total, she now has 65 + 30 = $95. \n\nWait, so now she has $95. But the wallet is supposed to cost $100. Therefore, the difference between $100 and $95 is $5. So Betty needs an additional $5 to buy the wallet”
1	"<think>\nOkay, let's try to figure out how much more money Betty needs to buy the wallet. Hmm, let's start by breaking down the problem step by step. \n\nFirst, Betty needs to save $100 for a new wallet. But she has only half of the money she needs. So, if the total amount she needs is $100, and she has half of that, then how much does she have already?\n\nWait, half of $100 would be $50. So Betty currently has $50. But then her parents decided to give her $15 for that purpose. So adding that to her existing $50, she now has $50 + $15 = $65. \n\nNext, her grandparents gave her twice as much as her parents. Her parents gave $15, so twice that would be $30. Therefore, adding that to her current $65, she now has $65 + $30 = $95. \n\nSo, after all the donations, Betty has $95. The question is asking how much more money she needs to buy the wallet. Since the wallet costs $100, and she already has $95, the”
…	ㅤ
15	"<think>\nOkay, let's see. Albert wants to know how many pizza slices he can eat in one day. He bought 2 large pizzas and 2 small pizzas. A large pizza has 16 slices, and a small pizza has 8 slices. If he eats all of it, how many pieces does he eat?\n\nAlright, first, I need to figure out the total number of slices he has. So, he has 2 large pizzas and 2 small ones. Let me break that down. Each large pizza is 16 slices, so two of them would be 16 multiplied by 2. Let me calculate that. 16 times 2 is 32 slices from the large pizzas. Then, he has 2 small pizzas, each with 8 slices. So, 8 slices per small pizza times 2 would be 16 slices from the small ones. \n\nAdding those together, the total slices should be 32 (from large) plus 16 (from small) equals 48 slices. So, he eats all 48 slices. Wait, is there anything else I need to consider? The question says he eats it all, so there's no leftovers. So the answer should be”

奖励函数

奖励函数包括"prompt", "completion", "completion_ids”以及原始数据集中的其他字段。其中"prompt"是模型输入的文本、 "completion"是模型输出的文本。

prompt：列表，列表中每个元素是字符串形式，代表模型的输入。

completion：列表，列表中每个元素是字符串形式，代表模型的输出。

completion_ids：列表，列表中每个元素是int形式，代表模型输出的token_id。

reward_kwargs：数据集中的其他字段，字段同样是list形式；以及trainer_state。

损失函数

损失函数是奖励函数+KL散度

🩲
二十二、强化学习-大模型

评估

概述

工具调用能力评估

工具调用是智能体的核心能力之一。智能体需要理解用户意图，选择合适的工具，并正确构造函数调用。相关的评估基准包括：

BFCL (Berkeley Function Calling Leaderboard)：UC Berkeley 推出，包含 1120+测试样本，涵盖 simple、multiple、parallel、irrelevance 四个类别，使用 AST 匹配算法评估，数据集规模适中，社区活跃。

ToolBench：清华大学推出，包含 16000+真实 API 调用场景，覆盖真实世界的复杂工具使用场景。

API-Bank：Microsoft Research 推出，包含 53 个常用 API 工具，专注于评估智能体对 API 文档的理解和调用能力。

通用能力评估

评估智能体在真实世界任务中的综合表现，包括多步推理、知识运用、多模态理解等能力：

GAIA (General AI Assistants)：Meta AI 和 Hugging Face 联合推出，包含 466 个真实世界问题，分为 Level 1/2/3 三个难度级别，评估多步推理、工具使用、文件处理、网页浏览等能力，使用准精确匹配（Quasi Exact Match）算法，任务真实且综合性强。

AgentBench：清华大学推出，包含 8 个不同领域的任务，全面评估智能体的通用能力。

WebArena：CMU 推出，评估智能体在真实网页环境中的任务完成能力和网页交互能力。

多智能体协作评估

评估多个智能体协同工作的能力：

ChatEval：评估多智能体对话系统的质量。

SOTOPIA：评估智能体在社交场景中的互动能力。

自定义协作场景：根据具体应用场景设计的评估任务。

常用评估指标

不同基准使用不同的评估指标，常见的包括：

准确性指标：Accuracy（准确率）、Exact Match（精确匹配）、F1 Score（F1 分数），用于衡量答案的正确性。

效率指标：Response Time（响应时间）、Token Usage（Token 使用量），用于衡量执行效率。

鲁棒性指标：Error Rate（错误率）、Failure Recovery（故障恢复），用于衡量容错能力。

协作指标：Communication Efficiency（通信效率）、Task Completion（任务完成度），用于衡量协作效果。

数据集简介

ToolBench

模型看用户问题 + 所有工具列表

输出：是否调用工具、调用哪个、参数是什么

本地 ToolEnv 执行工具，返回结果

模型根据结果判断：继续调用？还是结束？

重复直到模型说 “任务完成”

应用示例

旅行助手

💡

数据流转过程如下：用户在前端填写表单 → 后端验证数据 → 调用智能体系统 → 智能体依次调用景点搜索、天气查询、酒店推荐、行程规划 Agent → 每个 Agent 通过 MCP 协议调用外部 API → 整合结果返回前端 → 前端渲染展示。

Agent

AttractionSearchAgent

根据用户偏好搜索景点。它的输入是城市名称和用户偏好(比如"历史文化"、"自然风光")。它需要调用amap_maps_text_search工具，参数是关键词和城市。它的输出是景点列表，包含名称、地址、评分等信息。

提示词

输入

WeatherQueryAgent

任务是查询天气。输入是城市名称，输出是天气信息。

系统提示词

输入

HotelAgent

任务是搜索酒店。它的输入是城市名称和住宿类型，输出是酒店列表。

系统提示词

输入

PlannerAgent

任务是整合所有信息。它的输入是用户需求和前三个 Agent 的输出，输出是完整的旅行计划(JSON 格式)。

系统提示词

输入

自动化深度研究智能体

💡

用户输入：用户在前端输入研究主题

前端发送：前端通过 SSE 连接到/research/stream

后端接收：FastAPI 接收请求，创建研究状态

规划阶段：调用研究规划 Agent，分解为 3 个子任务

执行阶段：逐个执行每个子任务

使用 SearchTool 搜索

调用任务总结 Agent 总结

使用 NoteTool 记录结果

报告阶段：调用报告生成 Agent，整合所有总结

流式返回：通过 SSE 推送进度和结果到前端

前端展示：前端实时更新任务状态、进度条、日志、报告

Agent

研究规划专家

核心任务是理解用户的研究主题，分析主题的关键方面，然后生成一系列子任务。这个过程类似于人类研究者在开始研究前的"头脑风暴"阶段。

提示词

输入

附录

Function Call

OpenAI

OpenAI的函数调用机制