Agent 设计模式 ReAct 的核心，就是让大模型在每一步行动前先写一段「思考」，再调用工具、读取结果、继续思考，如此往复直到得出答案——这个 Thought→Action→Observation 的循环，是目前绝大多数智能体框架（LangChain 、 LangGraph 、 Claude Agent SDK 等）默认采用的执行骨架。很多团队一上来就堆工具列表，结果智能体胡乱调用、错误层层传播，问题往往不在工具，而在缺少这套「边想边做」的结构。
ReAct 从哪来：一篇论文定义了智能体
ReAct 由姚顺雨等人在 2022 年 10 月的论文《 ReAct: Synergizing Reasoning and Acting in Language Models 》（arXiv:2210.03629，ICLR 2023）中提出。它的出发点很直接：此前推理（如 Chain-of-Thought）和行动（如计划生成）是被分开研究的，前者容易幻觉、后者缺乏反思。 ReAct 让模型交替生成「推理轨迹」和「任务动作」，推理帮助模型制定、跟踪和修正计划，行动则让它与知识库、 API 等外部环境交互获取真实信息。论文在 HotpotQA 问答和 FEVER 事实核查上显著缓解了纯 CoT 的幻觉与错误传播问题，在 ALFWorld 、 WebShop 两个交互决策基准上分别超出模仿学习基线 34% 和 10% 的绝对成功率，且只需一两个示例提示、零参数训练。
我的理解是，ReAct 真正的贡献不是某个 prompt 技巧，而是把「 LLM 智能体」的操作语义写清楚了：模型每次只能做一小步，结果由环境给出而不是模型自己编。这也是它后来成为事实标准的原因。
Thought→Action→Observation 循环怎么转
一轮完整的 ReAct 执行包含三种角色：
- Thought（思考）：模型自由生成的推理文本，外化当前信念和下一步计划，也负责在出错后自我纠正；
- Action（行动）：从预定义工具集中选择一个动作及参数，例如
search[普朗克]，由外层程序解析执行——模型不能发明不存在的工具； - Observation（观察）：工具返回的真实结果，由你的代码拼接回上下文。这是唯一可靠的事实来源，Thought 只是计划，不是事实。
当模型输出形如 finish[答案] 的动作时，循环终止。下面是一个最小 Python 伪代码，展示这个循环的工程实现：
def react_loop(question, tools, llm, max_steps=8):
context = build_prompt(question, tools) # 注入工具列表与格式要求
for step in range(max_steps):
output = llm.generate(context)
thought, action = parse(output) # 抽取思考与动作
if action.name == "finish": # 模型自认完成
return action.input
observation = run_tool(action) # 真正执行工具调用
context += f"{thought}\nAction: {action}\nObservation: {observation}"
return "达到步数上限，中止"这段代码里有三个工程要点：必须限制最大步数防止死循环；Observation 要截断长度避免上下文爆炸；工具执行的异常也要作为 Observation 回传，让模型自己决定重试还是换路。工具定义部分可以结合 OpenAI Function Calling 实战（OpenAI Function Calling 实战）中的 schema 写法来落地，比论文时代的正则解析稳健得多。
Agent 设计模式 ReAct 与 Plan-and-Execute 、 Reflection 的对比
ReAct 不是唯一的智能体模式，选型时可以对照下面的表格：
| 模式 | 核心思路 | 优势 | 短板 | 典型场景 |
|---|---|---|---|---|
| ReAct | 思考与行动逐步交替 | 可解释、可纠错、接工具自然 | 步数多、 token 消耗大 | 问答、检索、客服 |
| Plan-and-Execute | 先一次性生成完整计划再逐步执行 | 全局视野、减少来回往返 | 计划失败后重规划成本高 | 长流程任务、报告生成 |
| Reflection | 执行后自我批判再改进 | 质量上限高 | 延迟翻倍、可能过度修改 | 代码生成、写作打磨 |
实践中三者经常组合：用 Plan-and-Execute 拆任务，每个子任务内部跑 ReAct 循环，关键产出再套一层 Reflection 。当单智能体能力不够时，可以把多个 ReAct 智能体编排成团队，具体做法见多智能体怎么编排一文。
什么时候该用 ReAct，什么时候不该
根据我在实际项目中的经验，ReAct 适合与不适合的场景界限分明：
适合的场景
- 需要查证的事实型任务：多跳问答、资料检索、事实核查，答案必须有来源；
- 交互式决策：操作网页、调用内部 API，走一步看一步比预写脚本灵活；
- 对可解释性有要求的场景：Thought 轨迹就是现成的审计日志，方便排查。
不适合的场景
- 纯创作类任务（写诗、头脑风暴）：不需要外部观察，套 ReAct 只是浪费 token；
- 答案在单一文档里的检索：一个普通 RAG 流水线（参见RAG 检索增强生成）更便宜也更稳定；
- 强实时或严格延迟预算的场景：多轮循环的延迟不可控。
另外，ReAct 能显著减少但不能消灭幻觉——Thought 本身仍是模型生成的，可能带着错误假设污染后续推理。因此工具返回的 Observation 应当尽量结构化、带元数据，并且把记忆读写（长期偏好、历史结论）从循环中拆出去单独管理，可参考AI Agent 记忆怎么实现中的分层方案。
评论 (0)