第12章:Agent 推理模式——从 CoT 到 ReAct 再到自主执行
系列导读:本章深入 Agent 的"思考方式",是它之所以"智能"的核心机制。理解了推理模式,你才能真正设计好一个 Agent 的行为逻辑。
一、推理模式:Agent 的"思考方式"
LLM 面对复杂任务时,“一口气"预测答案容易出错。推理模式就是给 LLM 一个"思考框架”,让它分步骤、有结构地解决问题。
从最基础到最复杂,主要有三种推理模式:
| 模式 | 本质 | 是否可观察推理过程 | 复杂度 |
|---|---|---|---|
| Direct(直接回答) | 一步到位给出答案 | 否 | 低 |
| CoT(思维链) | 先写出推理过程,再给答案 | 是 | 中 |
| ReAct(推理+行动) | 交替推理和工具调用,形成循环 | 是 | 高 |
二、CoT:Chain-of-Thought 思维链
核心思想:让 LLM 不要直接给答案,而是先把中间推理步骤写出来。
为什么 CoT 有效?
数学问题是最好的案例:
不用 CoT:
问题:小明有 5 个苹果,小红比他多 3 个,小红有几个? 答案:8(对了)
用 CoT:
问题:小明有 5 个苹果,小红比他多 3 个,小红有几个? 推理:小明的数量 = 5,小红比小明多 3 个,所以小红的数量 = 5 + 3 = 8。 答案:8(更可靠)
虽然加法例子不明显,但换到多步推理时:
问题:鸡兔同笼,头共 35 个,脚共 94 只,鸡和兔各多少?
不用 CoT 时,模型可能直接猜一个数。用 CoT 时,模型会一步步:
- 设鸡 x 只,兔 y 只
- x + y = 35
- 2x + 4y = 94
- 解方程组…
触发 CoT 的方法
最简单的触发是在 prompt 里加一句:
“Let’s think step by step."(让我们一步步来)
进阶方法是给几个 Few-shot 示例,每个示例都展示完整的推理过程:
“请按照以下格式回答:[推理过程] → [最终答案]”
三、ReAct:Reason + Act 推理+行动
ReAct 是 Agent 中最核心的推理模式,来源论文:《ReAct: Synergizing Reasoning and Acting in Language Models》(2022)。
ReAct 的核心循环
LLM 在执行中的每一步,都必须输出一个固定格式的三元组:
Thought: [对当前状态的推理思考]
Action: [决定调用哪个工具,带什么参数]
Observation: [工具返回的结果]
循环执行,直到任务完成:
用户:北京今天天气怎么样适合穿什么?
Thought: 用户想知道北京的天气和穿衣建议。我需要先查天气。
Action: weather_query(city="北京", date="today")
Observation: {temperature: 25, condition: "多云", wind: "2级"}
Thought: 北京今天25度多云,适宜穿着。可以建议轻薄长袖或短袖加薄外套。
Action: user_answer("北京今天多云,气温25度,风力较小。建议穿短袖配薄外套,或轻薄长袖。")
ReAct 为什么是最主流的 Agent 模式?
- 推理过程透明:每一步都在 “Thought” 里写明白了为什么做这个决定
- 错误可诊断:如果结果错了,可以回看 “Thought” 找到决策缺陷
- 接口标准化:代码只需要解析 Thought/Action/Observation 三种标签
- 可扩展性强:新工具加进来,不需要改代码逻辑,只需要加 schema
ReAct 的实现要点
System Prompt 的设计:
你是 ReAct 智能体。遵循以下工作流程:
1. 分析当前任务状态
2. 在 Thought 中写出你的推理过程
3. 如果有需要调用的工具,在 Action 中输出工具调用 JSON
4. 等待 Observation 结果
5. 重复步骤 1-4 直到任务完成
6. 最后直接在 Answer 中给出最终答案
格式要求:
Thought: [你的思考]
Action: {"tool": "tool_name", "params": {...}}
Observation: [工具结果(由系统自动填充)]
Answer: [最终答案(仅在任务完成时输出)]
重要:如果没有需要调用的工具,直接输出 Answer。不要编造 Observation。
四、Plan-and-Execute:先规划再执行
ReAct 是"走一步看一步"的灵活模式,Plan-and-Execute 是"先想好全盘再动手”。
流程对比
ReAct:
用户目标 → LLM 思考 → 调工具 → 看到结果 → LLM 再思考 → 调工具...
(每一步都根据上一步结果动态决定)
Plan-and-Execute:
用户目标 → LLM 生成完整计划(步骤1-5) → 按顺序执行每一步 → 汇总输出
各自优劣
| ReAct | Plan-and-Execute | |
|---|---|---|
| 适用任务 | 信息不确定、需要探索的 | 流程清晰、确定性高的 |
| 灵活性 | 高 | 低 |
| 可控性 | 低(可能跑偏) | 高 |
| token 消耗 | 多(每步都推理) | 少(一次规划) |
| 调试难度 | 高 | 低 |
实践中怎么选?
- 知识问答类(搜索→整合→回答):ReAct,过程中信息不确定
- 数据分析类(读数据→分析→出报告):Plan-and-Execute,流程相对固定
- 复杂长流程:混合模式,大方向 plan → 每步内部用 ReAct 灵活处理
五、Reflection:自我检查与修正
Reflection 不是独立的流程,而是给 ReAct 或 Plan-and-Execute 加的质量检查 buff。
思路
在完成输出后,让 LLM 自己审视一下:
Thought: 我已经完成了任务,给出了回答。让我检查一下:
1. 答案是否完整覆盖了用户的所有问题?
2. 有没有遗漏的关键信息?
3. 推理过程是否有漏洞?
反思:我注意到用户的问题里还提到了"预算",但我的回答里没有涉及费用评估...
修正:补充预算分析...
适用场景
- 高风险任务(如医疗建议、法律分析)
- 输出后用户可以清晰判断对错的任务
- 有客观评估标准的任务
代价
Self-reflection 多跑一次 LLM,token 成本和延迟都会增加。这是工程上的必要取舍。
六、三种范式的核心区别
| 范式 | 解决什么问题 | 决策时机 | 工程复杂度 |
|---|---|---|---|
| ReAct | 单步灵活性,动态调整 | 每一步实时决策 | 高 |
| Plan-and-Execute | 长任务不跑偏 | 开始前一次性规划 | 中 |
| Reflection | 输出质量不够好 | 完成后检查修正 | 中(作为模块叠加) |
七、本章小结
- 推理模式是给 LLM 一个"思考框架"
- CoT 教 LLM"先想后答",适合数学题、推理解释
- ReAct 教 LLM"边想边做",是 Agent 最主流的推理范式
- Plan-and-Execute 教 LLM"先想全再做",适合确定性流程
- Reflection 是"做完检查"的质量保障机制,可与前两者叠加
- 选型标准:任务复杂度、流程确定性、输出质量要求
思考题
- 一个客服 Agent 处理退款申请,适合用哪种推理模式?为什么?
- 如果你发现 ReAct 模式下 Agent 经常陷入循环(思考 → 调工具 → 思考 → 调同一个工具),你会从哪些角度排查和解决?