第12章:Agent 推理模式——从 CoT 到 ReAct 再到自主执行

第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 时,模型会一步步:

  1. 设鸡 x 只,兔 y 只
  2. x + y = 35
  3. 2x + 4y = 94
  4. 解方程组…

触发 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 模式?

  1. 推理过程透明:每一步都在 “Thought” 里写明白了为什么做这个决定
  2. 错误可诊断:如果结果错了,可以回看 “Thought” 找到决策缺陷
  3. 接口标准化:代码只需要解析 Thought/Action/Observation 三种标签
  4. 可扩展性强:新工具加进来,不需要改代码逻辑,只需要加 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 是"做完检查"的质量保障机制,可与前两者叠加
  • 选型标准:任务复杂度、流程确定性、输出质量要求

思考题

  1. 一个客服 Agent 处理退款申请,适合用哪种推理模式?为什么?
  2. 如果你发现 ReAct 模式下 Agent 经常陷入循环(思考 → 调工具 → 思考 → 调同一个工具),你会从哪些角度排查和解决?