Agent 核心认知框架：从 ReAct 到自我反思，一文理清智能体的大脑设计
目录
一、写在前面：Function Calling 只是 Agent 的手脚
四、Plan-and-Execute：先规划再执行，适合固定流程
六、Self-Reflection：让 Agent 学会检查自己
一、写在前面：Function Calling 只是 Agent 的手脚
很多同学刚开始学 Agent，最容易把 Function Calling 当成 Agent 的全部。
Function Calling 确实很重要。它让大模型不再只是输出自然语言，而是可以输出结构化指令，比如：
- 要调用哪个函数；
- 函数参数是什么；
- 工具返回后如何组织最终回答。
也就是说，模型从“只会说话”变成了“能发出可执行指令”。
但这只是第一步。
一个 Agent 只会调用工具，并不代表它真的会解决复杂问题。真实任务往往不是“一问一答”，而是包含理解、拆解、执行、观察、修正和总结的连续过程。
举个简单例子：
帮我查一下北京天气，如果下雨就提醒我带伞，否则推荐一个户外活动。这个需求至少包含三层逻辑：
- 先判断是否需要查天气；
- 根据天气结果决定下一步动作；
- 最后生成面向用户的自然语言建议。
所以，Function Calling 更像是 Agent 的“手脚”，而 ReAct、Plan-and-Execute、Self-Ask、Self-Reflection 这些模式，才更接近 Agent 的“大脑”。
二、为什么 Agent 需要认知模式
有了工具调用能力之后，Agent 还需要回答一个更关键的问题：
面对复杂任务时，它到底应该怎么思考？
真实业务里的任务通常有这些特点：
- 目标不一定一开始就完整；
- 中间结果可能影响下一步决策；
- 可能需要调用多个工具；
- 可能需要检索外部知识；
- 可能遇到工具失败或参数错误；
- 输出前还需要检查结果是否完整。
如果没有认知框架，Agent 很容易变成一个“工具调用脚本生成器”：看起来能动，但遇到复杂任务就乱。
常见的 Agent 认知模式主要有四类：
| 认知模式 | 核心流程 | 解决的问题 | 适合场景 |
|---|---|---|---|
| ReAct | Thought -> Action -> Observation | 如何边思考边行动 | 探索型任务、动态问答 |
| Plan-and-Execute | Plan -> Execute -> Finalize | 如何先规划再执行 | 固定流程、批量任务 |
| Self-Ask | 自问 -> 检索 -> 综合 | 如何拆解知识问题 | 多跳推理、事实问答 |
| Self-Reflection | 执行 -> 评价 -> 修正 | 如何发现并修正错误 | 代码、写作、高价值输出 |
这四种模式不是互斥关系。一个成熟的 Agent 系统，往往会把它们组合起来使用。
三、ReAct：边想边做，适合不确定任务
ReAct 是 Reasoning and Acting 的缩写，可以理解为“推理和行动协同”。
它的核心思想是：
模型不要直接一步到位回答复杂问题，而是每一步先思考，再行动，再根据观察结果决定下一步。
基本流程如下：
Thought -> Action -> Observation -> Thought -> Action -> Observation -> Final Answer每一轮包含三个关键部分：
| 组成 | 含义 | 示例 |
|---|---|---|
| Thought | 模型基于当前状态进行推理 | 我需要先查询北京人口 |
| Action | 模型采取行动，通常是调用工具 | call population_tool(city="北京") |
| Observation | 工具或环境返回结果 | 北京常住人口约 2185 万 |
比如用户问：
北京和上海哪个城市人口更多？ReAct 的处理过程可能是：
Thought: 我需要分别查询北京和上海的人口。
Action: 查询北京人口。
Observation: 得到北京人口数据。
Thought: 还需要查询上海人口。
Action: 查询上海人口。
Observation: 得到上海人口数据。
Thought: 比较两个数字。
Final Answer: 输出人口更多的城市。这种方式的优点很明显：
- 过程透明；
- 每一步可调试；
- 可以基于实时工具结果回答；
- 适合中间结果会影响后续决策的任务。
ReAct 适合哪些场景
ReAct 特别适合不确定性高的任务，例如：
- 智能客服；
- 研究助手；
- 动态问答；
- 需要根据工具结果调整策略的任务；
- 用户需求不完整，需要边问边做的任务。
ReAct 的问题
ReAct 最大的问题是成本和效率。
因为它每一步都可能调用一次模型，复杂任务很容易跑出 5 到 10 轮循环。如果每一轮都使用高成本模型，整体开销会比较高。
生产环境里用 ReAct，需要特别注意：
- 设置最大步数，防止死循环；
- 记录每一步 Thought、Action、Observation；
- 处理工具调用失败；
- 处理参数解析错误；
- 必要时加入终止条件和兜底策略。
一句话总结：
ReAct 适合探索，但不要无节制地循环。
四、Plan-and-Execute：先规划再执行，适合固定流程
ReAct 灵活，但不是所有任务都需要每一步重新思考。
比如下面这个任务：
查北京天气 -> 计算 15*8+20 -> 查询上海介绍 -> 汇总结果这类任务的流程很清晰，没有必要每一步都让模型重新判断下一步该做什么。更合理的方式是：先生成计划，再按计划执行。
这就是 Plan-and-Execute。
它分为两个阶段：
- Plan：根据用户目标生成步骤清单；
- Execute：按清单执行每一步，最后汇总结果。
典型状态结构可以设计成：
input: 用户输入
plan: 待执行步骤列表
past_steps: 已执行步骤及结果
response: 最终输出执行节点的逻辑也很直观：
取出 plan 的第一步
执行当前步骤
把结果追加到 past_steps
从 plan 中移除已执行步骤
如果还有步骤，继续执行
否则进入 finalizer 汇总结果ReAct 和 Plan-and-Execute 的区别
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 决策方式 | 每一步动态决策 | 先生成完整计划 |
| 模型调用次数 | 通常每步一次 | 规划一次，执行阶段按需调用 |
| 灵活性 | 高 | 较低 |
| 成本 | 高 | 较低 |
| 速度 | 慢，常串行 | 快，可并行执行无依赖步骤 |
| 适用场景 | 探索性任务 | 固定流程任务 |
一句话概括：
ReAct 适合探索，Plan-and-Execute 适合编排。
Plan-and-Execute 的局限
Plan-and-Execute 的问题在于：如果初始计划错了，后续步骤可能一路错下去。
所以在真实系统里，Plan-and-Execute 往往还需要配合：
- 重规划机制；
- 工具异常处理；
- Reflection 结果检查；
- 对关键步骤加入人工确认。
比较实用的组合是：
正常情况：Plan-and-Execute 执行固定流程
异常情况：切换到 ReAct 动态处理
完成之后：Reflection 检查结果质量五、Self-Ask：先拆问题再检索，减少幻觉
Self-Ask 解决的是另一个常见问题：
模型不知道自己应该查什么。
面对事实问答、多跳推理、对比分析时，如果模型直接回答，很容易依赖过时知识，甚至产生幻觉。
Self-Ask 的思路是：
- 先把原问题拆成多个子问题；
- 对每个子问题进行检索；
- 最后综合子问题答案，得出最终结论。
例如：
OpenAI 的 CEO 毕业于哪所大学？这道题看起来简单，但模型无法直接回答，需要先知道"OpenAI 的 CEO 是谁"才能进一步查学历。
Self-Ask 会拆成：
子问题 1：OpenAI 的 CEO 是谁？
子问题 2：他毕业于哪所大学？
最终综合：得出完整答案。这才是 Self-Ask 最典型的使用场景——多跳推理：每一跳的答案，都是下一跳的输入。
Self-Ask 和 ReAct 的区别
| 维度 | ReAct | Self-Ask |
|---|---|---|
| 关注点 | 下一步怎么做 | 我需要知道什么 |
| 核心动作 | 思考、行动、观察 | 自问、检索、综合 |
| 适合任务 | 动态交互、探索任务 | 事实问答、多跳推理 |
| 工具依赖 | 任意工具 | 搜索、数据库、知识库 |
简单记忆：
ReAct 重探索，Self-Ask 重检索。
Self-Ask 适合哪些场景
Self-Ask 非常适合：
- 最新事实查询；
- 多跳问题；
- 多对象属性对比；
- RAG 系统中的问题拆解；
- 需要审计推理链路的问答系统。
但它也有成本。简单问题如果强行拆解，会增加延迟，甚至把问题复杂化。
所以 Self-Ask 的关键不是“凡事都拆”，而是识别出哪些问题确实需要外部事实支撑。
六、Self-Reflection：让 Agent 学会检查自己
即使 Agent 会 ReAct、会规划、会检索，它仍然可能犯错。
常见错误包括：
- 调用了错误工具；
- 参数提取错误；
- 推理逻辑不一致；
- 回答遗漏用户问题；
- 工具结果没有正确整合；
- 输出格式不符合要求；
- 反复调用同一工具，陷入循环。
Self-Reflection 的作用，就是让 Agent 对自己的输出进行检查，发现问题后再修正。
基本流程如下：
执行 -> 评价 -> 修正评价维度可以包括：
- 完整性：是否回答了用户所有问题；
- 准确性：事实是否正确；
- 一致性：推理过程是否自洽；
- 格式：是否符合指定输出格式；
- 安全性：是否包含不应输出的内容；
- 可执行性：如果是计划或代码，是否真的能落地。
自我反思和审计 Agent
反思可以分为两种方式：
| 方式 | 含义 | 优点 | 缺点 |
|---|---|---|---|
| 自我反思 | 同一个 Agent 检查自己 | 轻量、实现简单 | 可能不够客观 |
| 审计 Agent | 独立 Agent 检查主 Agent | 更客观、可并行 | 成本更高、系统更复杂 |
实际项目里可以按任务价值分层：
- 简单任务：不反思，比如查天气；
- 中等任务：反思一轮，比如写文案、写代码片段；
- 高价值任务：多轮反思或引入人工审核，比如合同、财报、关键代码修改。
七、综合案例：命理机器人怎么设计
这里用“命理机器人”举一个综合案例，它很适合用来理解 Agent 架构设计。
它的目标是：根据用户出生信息，生成星座、生肖、运势和建议。
看起来简单，但它同时涉及：
- 信息收集；
- 多步骤计算；
- 条件判断；
- 多轮记忆；
- 建议生成；
- 输出完整性检查。
可以这样拆：
| 功能 | 说明 | 适合的认知模式 |
|---|---|---|
| 信息收集 | 用户没提供生日时主动询问 | ReAct |
| 星座计算 | 根据生日确定星座 | Plan-and-Execute |
| 生肖计算 | 根据年份确定生肖 | Plan-and-Execute |
| 运势生成 | 根据星座和日期生成运势 | Plan-and-Execute |
| 建议生成 | 结合用户信息生成建议 | ReAct 或模型执行节点 |
| 多轮记忆 | 支持“那明天呢？” | 状态管理 / Checkpointer |
| 结果检查 | 检查最终回答是否缺字段 | Reflection |
整体流程可以设计为：
命理机器人 Agent 流程
- 用户输入
- collect_info：收集生日和意图
- 判断信息是否完整
- 缺少生日：返回追问，请用户提供出生日期
- 信息完整：planner 生成计划
- executor 执行当前步骤
- 判断是否还有步骤：有则继续执行，无则进入检查
- reflector 检查结果完整性
- 缺失字段：回到执行节点补齐
- 完整：finalizer 输出最终答案
状态中可以保存：
messages: 对话消息
user_info: 用户信息，例如生日、星座、生肖、运势、建议
plan: 待执行计划
past_steps: 已执行步骤及结果
final_answer: 最终回答
needs_replan: 是否需要重新规划
ask_tomorrow: 是否询问明天运势这样用户第一次说：
我 1995 年 8 月 23 日出生，今天运势如何？系统提取生日，计算星座和生肖，生成今天的运势。
用户第二次追问：
那明天呢？Agent 不需要再次询问生日，只需要基于已有状态重新计算明天的运势。
这就是状态管理对多轮 Agent 的价值。
八、从认知模式走向工程架构
上面四种模式主要解决的是“模型怎么思考”。但生产级 Agent 还必须解决工程问题：
- 任务来了先交给谁处理？
- 是否需要拆成多个步骤？
- 哪些步骤可以并行？
- 哪些信息应该放进上下文？
- 哪些工具调用需要人工确认？
- 如何观察 Agent 的执行过程？
- 如何评估这次输出到底好不好？
现代 Agent 工程里，经常会用到这些模式：
| 工程模式 | 核心作用 | 适合场景 |
|---|---|---|
| Augmented LLM | LLM + tools + retrieval + memory | 大多数 Agent 应用起点 |
| Prompt Chaining | 固定步骤串联 | 文案、报告、结构化生成 |
| Routing | 分类后分派专家或流程 | 客服、工单、模型分流 |
| Parallelization | 并行子任务后聚合 | 研究、代码审查、多视角评估 |
| Orchestrator-Workers | 主控拆任务，worker 执行 | 编程、调研、数据分析 |
| Evaluator-Optimizer | 生成、评价、修改循环 | 代码、写作、高价值输出 |
| Multi-Agent Supervisor | 中心化多 Agent 管理 | 企业复杂工作流 |
| Handoff | Agent 之间动态交接 | 多角色连续对话 |
| Context Engineering | 管理进入模型上下文的信息 | 长任务、多 Agent、代码项目 |
| Guardrails + Human-in-the-loop | 安全校验和人工审批 | 金融、医疗、生产操作 |
| Observability + Evals | 追踪、评测和回归测试 | 所有生产级 Agent |
以上模式将在后续文章中逐一展开，每种模式都值得单独一篇来讲清楚。这里先建立整体认知，重点展开两个最容易被低估的能力：
1. Context Engineering
以前大家经常讲 Prompt Engineering，但 Agent 进入长任务之后，更关键的问题变成：
每一次调用模型时，到底应该把哪些信息放进上下文？
上下文可能包括：
- 系统提示词；
- 用户需求；
- 历史对话；
- 工具说明；
- 检索结果；
- 文件内容；
- 任务计划；
- 已执行步骤；
- 错误日志；
- 长期记忆。
Context Engineering 的目标是：
text
用最少、最高信号的信息，让模型在当前步骤做出正确行为。上下文太少，模型会判断失真；上下文太多，模型会注意力分散，还会增加成本。
2. Observability + Evals
Agent 的行为不是固定代码路径，而是模型根据上下文动态决策。
所以如果没有 Trace 和 Eval，你很难知道问题出在哪里：
- 是模型理解错了？
- 是工具描述不清楚？
- 是检索结果质量差？
- 是中间步骤遗漏？
- 是最后总结时丢了信息？
生产级 Agent 至少要记录：
- 每次模型调用输入输出；
- 工具调用参数和结果；
- 中间步骤；
- 错误和重试；
- 最终答案质量；
- 成本和延迟。
没有可观测性，就很难稳定迭代 Agent。
九、四种模式怎么组合使用
真实项目中，不建议死磕某一种模式。
更好的方式是按任务特点组合：
ReAct + Self-Ask
适合动态交互中的知识检索。
例如复杂事实问题，Agent 可以先用 ReAct 判断需要检索，再用 Self-Ask 拆子问题，最后调用搜索或知识库。
Plan-and-Execute + Reflection
适合企业业务流程。
例如批量生成报告：
先规划报告生成步骤
按计划查询数据、生成图表、撰写摘要
完成后检查是否缺少关键指标
缺失时重新补充ReAct + Plan-and-Execute
适合先澄清需求，再执行固定流程。
例如用户只说：
帮我做个销售分析。Agent 需要先追问时间范围、数据来源、分析维度。需求明确后，再进入固定分析流程。
四种模式综合使用
一个成熟 Agent 可以这样工作：
ReAct: 先理解用户需求，必要时追问
Self-Ask: 把复杂知识问题拆成可检索子问题
Plan-and-Execute: 对明确流程生成计划并执行
Reflection: 输出前检查完整性和质量十、总结
这篇文章最重要的结论，其实可以压缩成一句话：
Agent 的智能，不在于它能调用多少工具，而在于它如何思考、规划、验证和反思。Function Calling 让 Agent 有了手脚。
ReAct 让 Agent 能够边想边做。
Plan-and-Execute 让 Agent 能够先规划再执行。
Self-Ask 让 Agent 能够把复杂知识问题拆成可检索的小问题。
Self-Reflection 让 Agent 能够检查自己的输出，并在发现问题后修正。
再往生产环境走，还必须补上 Routing、Prompt Chaining、Parallelization、Orchestrator-Workers、Context Engineering、Guardrails、Observability 和 Evals。
所以，不要把 Agent 理解成一个“会调用工具的大模型”。更准确地说：
Agent 是一个由大模型驱动、能够使用工具、管理状态、根据反馈循环行动，并由工程系统约束和评估的任务执行系统。
理解到这一层，再去看 LangChain、LangGraph、OpenAI Agents SDK 或多 Agent 框架，就不会被各种名词绕晕了。因为你会发现，框架变来变去，底层核心问题始终是那几个：
任务怎么拆？
工具怎么用？
状态怎么存？
上下文怎么管？
结果怎么验？
错误怎么改？
上线后怎么评估？把这些问题想清楚，才算真正入门 Agent 工程。
参考资料：
- ReAct: Synergizing Reasoning and Acting in Language Models
- Reflexion: Language Agents with Verbal Reinforcement Learning
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models
- Anthropic: Building effective agents
- OpenAI Agents SDK
- LangGraph 官方文档
欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。
更多推荐
8
0- 0
已为社区贡献1条内容
所有评论(0)