ReAct、CoT 与 Tool-Use：从想清楚到做清楚

一句话：CoT 解决”想清楚”，Tool-Use 解决”查清楚/做清楚”，ReAct 把两者编成闭环——推理指导行动，行动反馈推理。这是现代 AI Agent 的核心范式。

三个概念，一张关系图

在 AI 工程的语境里，有三个高频概念总是纠缠在一起：

Chain-of-Thought (CoT)：让模型把推理过程一步步写出来
Tool-Use：让模型调用外部工具获取信息或执行操作
ReAct：把推理和行动交织成循环

它们不是三个并列的方案，而是递进的能力层次：

1	纯 LLM（只靠记忆）→ 加 CoT（会想了）→ 加 Tool-Use（有手了）→ ReAct（脑手协调）

下面逐个讲透。

一、Chain-of-Thought：让模型把过程写出来

核心思想

让模型在给出最终答案前，把中间推理步骤显式地生成出来。就像老师要求学生”写解题过程，不能只写答案”。

直观对比

不用 CoT：

Q: 商店有 23 个苹果，卖了 15 个，又进货 8 个，现在有几个？
A: 16

用 CoT：

Q: 商店有 23 个苹果，卖了 15 个，又进货 8 个，现在有几个？
A: 初始有 23 个苹果，卖出 15 个后剩 23−15=8 个，再进货 8 个，8+8=16 个。答案是 16。

看起来只是多写了几行字，但对 LLM 来说这是本质性的变化。

为什么 CoT 有效？——三个层面

1. 计算层面：中间步骤就是额外的计算层

LLM 是自回归模型——每生成一个 token，都经历一次完整的前向传播。一个 10 步推理被展成 10 个 token 序列，比 1 步直接输出答案多了 9 次前向传播的机会。中间步骤给了模型更多的”计算带宽”。

2. 注意力层面：写下来的过程能被回头看

写出的中间步骤成为后续 token 的 attention 上下文。模型在生成后面的步骤时，可以通过 attention 机制”看到”自己之前写的内容，减少信息丢失。没写出来的推理，后续 token 就看不到。

3. 训练分布层面：更接近模型见过的数据

预训练语料中大量数学推导、逻辑分析、技术文档都是”分步书写”的。CoT 格式让输入输出的分布更接近模型训练时见过的数据，自然表现更好。

两种触发方式

方式	做法	适用场景
Zero-shot CoT	prompt 末尾加 `"Let's think step by step"`	通用触发，零成本
Few-shot CoT	提供几个带推理过程的示例	效果更稳定，需要构造示例

CoT 的局限

问题	说明
Hallucination	推理过程看着逻辑通顺，但基于错误前提或编造事实——整条推理链都是空中楼阁
自我修正困难	中间某步出错，后续步骤基于错误结论继续推，很难自我发现和回退
无法获取信息	遇到事实性问题（”特斯拉 Q1 营收”），只能靠记忆猜，没有验证手段
Token 开销大	中间步骤消耗大量 token，成本和延迟都不友好

一句话：CoT 让模型”想得更清楚”，但它始终在模型内部打转，走不出自己的知识边界。

二、Tool-Use：给模型一双手

核心思想

给模型配备外部工具（搜索引擎、数据库、代码解释器、API 等），让它在需要时调用工具获取真实信息或执行操作，突破自身知识的限制。

工作流程

1	用户提问 → 模型判断是否需要工具 → 生成 tool_call → 外部执行 → 结果返回 → 模型基于结果生成回答

具体例子

用户问：“北京现在的天气怎么样？”

模型发现自身无法获取实时数据，决定调用天气 API
生成 tool call：get_weather(city="北京")
系统执行 API 调用，返回：{temp: 22°C, condition: "晴", humidity: 45%}
模型拿到结果，生成自然语言回答

技术实现：Function Calling

模型侧的关键能力是 function calling——模型经过专门训练，能输出结构化的工具调用 JSON，而非自然语言。

// 工具定义（告诉模型有哪些工具可用）
{
  "name": "get_weather",
  "description": "获取指定城市的当前天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名"}
    },
    "required": ["city"]
  }
}

// 模型输出的 tool call
{
  "name": "get_weather",
  "arguments": {"city": "北京"}
}

主流模型（GPT、Claude、Gemini、DeepSeek 等）都原生支持 function calling。这不是 prompt trick，而是模型层面的能力。

常见工具类型

工具类型	典型用途	示例
搜索	获取实时信息	Google Search、Tavily
代码执行	计算、数据处理	Python REPL、Code Interpreter
数据库查询	业务数据	SQL 查询、REST API
文件操作	读写文档	读取 PDF、写入 CSV
外部 API	特定领域服务	天气、地图、股票行情

Tool-Use 的局限

问题	说明
缺乏规划	模型可能上来就乱调工具，没想清楚需要什么信息、该调哪个
调用过多	一步能搞定的事，模型调了 5 次工具，浪费时间和 token
参数错误	传错参数（城市名拼错、格式不对），拿到无效结果
依赖工具质量	工具返回垃圾数据，模型照用不误——garbage in, garbage out
安全风险	工具可能有副作用（删数据、发邮件），需要权限控制

一句话：Tool-Use 让模型”能做事了”，但缺乏策略规划，容易像无头苍蝇一样乱调工具。

三、ReAct：脑手协调的闭环

核心思想

ReAct = Reasoning + Acting

出自 2022 年 Yao et al. 的论文《ReAct: Synergizing Reasoning and Acting in Language Models》。核心思想：让 LLM 在解决问题的过程中，把”思考”和”行动”交织在一起，形成 Thought → Action → Observation 的循环。

Thought：模型生成一段推理，分析当前状态、规划下一步
Action：模型调用外部工具，获取真实信息
Observation：工具返回的结果，成为下一轮 Thought 的输入

三者不断交替，直到模型判断信息足够，给出最终 Answer。

具体例子

用户问：“特斯拉 2025 年 Q1 的营收是多少？和去年同期相比如何？”

步骤	类型	内容
1	Thought	我需要查特斯拉最新财报数据，先搜索 2025 Q1 营收
2	Action	`search("Tesla 2025 Q1 earnings revenue")`
3	Observation	Tesla Q1 2025 revenue $21.3B…
4	Thought	拿到了 2025 数据，但用户还要对比，需要查 2024 Q1
5	Action	`search("Tesla 2024 Q1 revenue")`
6	Observation	Tesla Q1 2024 revenue $21.3B…
7	Thought	两年数据都拿到了，可以给出对比回答
8	Answer	特斯拉 2025 Q1 营收为 $21.3B，与 2024 Q1 基本持平…

关键点：每一步 Thought 都是基于前一步 Observation 做出的增量推理，而不是一次性猜答案。模型在”想”和”做”之间交替推进。

ReAct vs 纯 CoT vs 纯 Tool-Use

维度	纯 CoT	纯 Tool-Use	ReAct
推理能力	✅ 擅长	❌ 缺乏规划	✅ 擅长
获取外部信息	❌ 只靠模型内部知识	✅ 可以	✅ 可以
幻觉风险	🔴 高——无外部验证	🟡 中——调用对了就行	🟢 低——推理+验证双保险
决策质量	🟡 单靠推理可能走偏	🔴 缺乏规划容易乱调工具	🟢 推理指导行动，行动反馈推理

vs CoT：CoT 纯靠模型”想”，遇到事实性问题容易 hallucination。ReAct 通过 Action 拿到真实数据来校准推理。
vs 纯 Tool-Use：纯 Tool-Use 缺乏规划，模型可能盲目调工具、调错工具。ReAct 的 Thought 步骤提供了策略性规划。

ReAct 落地的常见问题

1. 循环死结（Loop）

模型反复执行相同的 Action，得不到有效 Observation，陷入无限循环：Thought→Action→Obs→Thought→同一个 Action…

解法：设最大步数限制 + 重复动作检测。

2. 上下文爆炸（Context Explosion）

每一步的 Thought + Action + Observation 都塞进 context，长任务很容易撑爆 token 窗口。

解法：对话摘要压缩、只保留关键 Observation、滑动窗口。

3. 工具选择错误

模型推理出错，调了不合适的工具，拿到无关 Observation，后续推理全部跑偏。

解法：更精确的 tool description + few-shot 示例引导。

4. Observation 噪声

工具返回的信息太多或太杂，模型无法从中提取有效信号。

解法：对 Observation 做后处理或摘要，再喂回模型。

5. 延迟堆积

每一步都要等工具返回，多步任务的延迟累加。

解法：并行调用无依赖的 Action，或采用 Plan-and-Solve 变体先规划再执行。

四、关键追问：有搜索能力的助手算不算 Agent？

这是一个常见的概念混淆点。答案：不算。 具备搜索能力的问答助手，更准确的定位是 RAG 系统或 Tool-augmented Assistant。

为什么？关键看三个维度

1. 决策权在哪？

	搜索助手	Agent
谁决定要不要搜索？	人——用户问了才搜	模型自己——判断需不需要搜、搜什么、搜几次
搜索策略	固定流程：用户问→搜→答	动态规划：根据结果决定下一步
执行几步？	通常 1 步	多步迭代

2. 有没有自主规划能力？

真正的 Agent 会自己拆解问题、规划搜索路径、评估信息是否充足。搜索助手只是”一问一搜一答”。

3. 有没有行动循环？

Agent 的标志性特征是 Observation 驱动的迭代——搜了一次结果不够就换策略再搜，调了一个工具报错就换个方式重试。搜索助手是开环的：搜一次就结束，不管结果质量如何。

能力光谱

纯 LLM → RAG/搜索助手 → Tool-Use 助手 → Agent → Multi-Agent
  |           |              |            |           |
 只靠记忆   加了搜索      加了多种工具   自主规划    多个Agent
 无外部能力  单步调用      但缺乏规划    多步循环     协作分工

搜索助手处在光谱的第二格，比纯 LLM 强，但离 Agent 还差关键的两步：自主规划和行动循环。