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

Fri, 26 Jun 2026 00:00:00 +0000

第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 经常陷入循环（思考 → 调工具 → 思考 → 调同一个工具），你会从哪些角度排查和解决？

ReAct on SelfTechHub

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

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

一、推理模式：Agent 的"思考方式"

二、CoT：Chain-of-Thought 思维链

为什么 CoT 有效？

触发 CoT 的方法

三、ReAct：Reason + Act 推理+行动

ReAct 的核心循环

ReAct 为什么是最主流的 Agent 模式？

ReAct 的实现要点

四、Plan-and-Execute：先规划再执行

流程对比

各自优劣

实践中怎么选？

五、Reflection：自我检查与修正

思路

适用场景

代价

六、三种范式的核心区别

七、本章小结

思考题