不吃辣的Chris · AI 实践指南

Appearance

63. ReAct 模式（Reason and Act） ​

难度 P1 高频 · 岗位 应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 OpenAI · Google · Meta 相关题 Q61 反射模式 · Q62 工具使用模式 · Q11 ReAct 实现

本题阅读地图 ​

  1. 面试场景还原 — 1 min
  2. TL;DR 速记 — 30 sec
  3. 图解 — 30 sec
  4. 详细解析 — 5 min
  5. 常见踩坑与反例 — 1 min
  6. 面试官可能继续追问 — 1 min

面试场景还原 ​

�面试官：如果用户问「明天适合去颐和园吗？」，Agent 应该怎么处理？

🙋‍♂️我：调用天气 API 查明天天气，然后回答。

👔面试官：对，但这只是单次调用。如果问题是「北京和上海哪个城市明天更适合户外拍照？」呢？

🙋‍♂️我：分别查两个城市的天气，然后对比分析？

👔面试官：很好。但这个「分析」过程应该怎么设计？如果每步都要调用工具、都要基于上一步的结果再做判断，应该怎么组织？

🙋‍♂️我：呃……可以一步步来，先查北京，再查上海，然后对比？

👔面试官：对，这叫 ReAct 模式。关键点是：每个循环里，模型先「思考」下一步该做什么，然后「行动」调用工具，再「观察」工具返回，进入下一轮循环。不是一次性规划所有步骤，而是走一步看一步。

TL;DR 速记 ​

  • 是什么：Reason（推理）+ Act（行动）的循环模式，走一步看一步
  • 核心循环：思考（下一步做什么）→ 行动（调用工具）→ 观察（获取结果）
  • 与纯工具调用的区别：ReAct 是多步推理-行动的闭环，每一步都基于前一步的结果再决策
  • 适用场景：需要多步推理、动态决策、根据中间结果调整策略的复杂任务
  • 关键参数：max_iterations 防止无限循环，early_stopping 控制提前终止

图解 ​

图 1：ReAct 循环架构 ​

图 2：ReAct 处理复杂问题的完整示例 ​

详细解析 ​

ReAct 的核心思想：思考与行动的交替 ​

ReAct 这个名字来自 Reason（推理）+ Act（行动）。它的核心思想是：Agent 不应该一次性规划所有步骤然后执行，而是应该走一步、看一步、想一步。

这就像人类解决复杂问题的方式：

  1. 面对问题，先思考需要什么信息
  2. 去获取信息（行动）
  3. 看到结果后（观察），再思考下一步
  4. 重复直到问题解决

ReAct 把这种方式形式化为一个标准循环，让 Agent 能够动态地、自适应地处理复杂任务。

ReAct 解决的核心问题：

  • 纯 LLM 只能基于内部知识推理，无法获取外部信息
  • 纯工具调用是「一次性」的，无法处理需要多步决策的任务
  • ReAct 结合两者，让 Agent 既能思考又能行动，且能持续迭代

ReAct 循环的三步分解 ​

每个 ReAct 循环包含三个明确的步骤：

第一步：思考（Reason） Agent 基于当前上下文，思考下一步该做什么：

  • 分析问题当前状态
  • 判断还缺什么信息
  • 决定调用哪个工具、填什么参数

思考结果通常会以自然语言形式输出，帮助理解 Agent 的决策过程：

思考：用户问哪个城市更适合拍照，我需要知道两地的天气情况。先查北京天气。

第二步：行动（Act） 根据思考结果，执行工具调用：

json
{
  "action": "get_weather",
  "action_input": {"city": "北京"}
}

这一步是真正的工具调用，Agent 通过工具与外部世界交互。

第三步：观察（Observe） 工具执行后，结果返回给 Agent：

观察：北京明天天气晴朗，温度 25°C，适合户外活动。

这个观察结果成为下一轮循环的输入，Agent 基于新信息继续思考。

完整的 ReAct 轨迹示例：

用户：北京和上海明天哪个更适合户外拍照？

思考：需要比较两地的天气情况。先查北京天气。
行动：调用 get_weather("北京")
观察：北京：晴天，25°C，空气质量优

思考：北京天气很好。现在需要查上海天气来做对比。
行动：调用 get_weather("上海")
观察：上海：小雨，18°C，湿度高

思考：上海有雨不适合户外拍照。再查一下北京有哪些适合拍照的景点。
行动：调用 search("北京 户外拍照景点")
观察：颐和园、天坛、北海公园等

思考：综合对比：北京天气晴朗且有很多户外景点，上海下雨不适合。推荐北京。
行动：输出最终答案

回答：推荐北京。明天北京天气晴朗（25°C），而上海有小雨（18°C）。北京有颐和园、天坛等多个适合户外拍照的经典景点。

ReAct 与单纯工具调用的区别 ​

维度单次工具调用ReAct 模式
决策次数一次多次迭代
规划方式预先规划走一步看一步
灵活性低高
适用任务简单、明确的任务复杂、多步骤、需要动态调整的任务
实现复杂度低中等
延迟/成本低较高

本质区别：

  • 单次工具调用：开发者写死流程「先调 A，再调 B，然后返回」
  • ReAct：模型自己决定「接下来该调什么」，根据上一步结果动态决策

示例对比：

用户问「明天适合去颐和园吗？」

  • 单次调用：开发者预判用户需要天气，直接调用天气 API
  • ReAct：Agent 先思考「去颐和园需要考虑什么？」→ 天气 → 调用天气 API → 再思考「还有别的因素吗？」→ 交通 → 查交通 → ...

ReAct 的适用场景与局限性 ​

最适合的场景：

  1. 需要多步推理的问题 例如：「苹果公司 2024 年的营收和净利润分别是多少？利润率相比 2023 年变化了多少？」

    • 需要分别查询 2024 和 2023 的营收、净利润
    • 需要计算利润率并对比

  2. 需要动态决策的问题 例如：「帮我规划从北京到杭州的行程，要最快且不超过 1000 元」

    • 可能需要比较高铁、飞机等不同方案
    • 根据实时价格动态选择

  3. 需要根据中间结果调整的问题 例如：「找一本关于机器学习的书，作者是中国人，豆瓣评分 8 分以上」

    • 先搜索机器学习书籍
    • 筛选中国作者
    • 查豆瓣评分
    • 可能需要多轮筛选

局限性：

  1. 延迟较高 每个循环都要调用 LLM + 工具，多步任务延迟会累积。

  2. 成本较高 多次 LLM 调用，Token 消耗比单次调用高。

  3. 可能陷入循环 如果任务定义不清或模型判断失误，可能无限循环调用工具。

  4. 不适合简单任务 对于明确、简单的工具调用，ReAct 的额外思考步骤是浪费。

ReAct 的工程实现要点 ​

关键参数设置：

python
{
    "max_iterations": 10,  # 最大循环次数，防止无限循环
    "early_stopping_method": "generate",  # 完成时直接输出答案
    "handle_parsing_errors": True,  # 工具调用格式错误时自动处理
}

Prompt 设计原则：

ReAct 的 Prompt 通常遵循固定格式，指导模型按「思考-行动-观察」的结构输出：

你是一个智能助手，可以使用以下工具：
- get_weather: 获取城市天气
- search: 搜索信息

请按以下格式回复：
思考：你的思考过程
行动：工具名称
行动输入：工具参数
观察：工具返回结果（由系统自动填充）

重复「思考-行动-观察」直到问题解决，然后输出：
最终答案：你的回答

停止条件设计：

Agent 需要在以下情况停止循环：

  1. 任务完成（模型输出最终答案）
  2. 达到最大迭代次数
  3. 连续多次工具调用失败
  4. 用户主动取消

工具结果回传机制：

工具返回结果需要格式化为「观察」Prompt，重新输入给模型：

python
observation = f"观察：{tool_result}"
new_prompt = previous_prompt + "\n" + observation
response = llm.generate(new_prompt)

常见踩坑与反例 ​

踩坑 1：混淆 ReAct 和单次工具调用 ​

错误描述：「ReAct 就是能调工具的 LLM」

问题：忽略了 ReAct 的循环迭代特性，把它当成简单的工具包装。

正确理解：ReAct 的核心是「多步循环」，模型每步都基于前一步结果重新思考决策。

踩坑 2：max_iterations 设置不合理 ​

错误做法：

  • 不设上限：可能导致无限循环
  • 设得太小（如 2-3 次）：复杂任务还没完成就被截断

正确做法：

  • 一般任务：5-10 次
  • 复杂任务：15-20 次
  • 一定要设置，不能无限制

踩坑 3：Prompt 格式不统一 ​

错误做法： 模型输出的「思考」「行动」格式混乱，程序无法解析。

正确做法： 使用严格的 Prompt 模板，要求模型按固定格式输出，便于程序解析。

踩坑 4：忽略工具失败处理 ​

错误做法： 工具调用失败后直接终止，没有给模型处理失败的机会。

正确做法： 工具失败信息也要作为「观察」回传给模型，让模型决定是重试、换工具还是终止。

踩坑 5：对所有任务都用 ReAct ​

错误做法： 不管任务简单还是复杂，都用 ReAct 模式。

正确做法： 简单任务用单次调用，中等任务用简单链式调用，复杂任务才上 ReAct。避免过度设计。

面试官可能继续追问 ​

  • 追问 1：ReAct 和 Plan-and-Execute 模式有什么区别？ 答题要点：ReAct 是「走一步看一步」，每步都重新规划；Plan-and-Execute 是「先一次性规划所有步骤，再执行」。ReAct 灵活但慢，Plan-and-Execute 快但遇到意外难调整。

  • 追问 2：ReAct 的延迟问题怎么优化？ 答题要点：1）减少迭代次数；2）并行调用多个工具（如果独立）；3）用更小的模型做思考；4）缓存常见问题的思考路径。

  • 追问 3：ReAct 模式适合多智能体系统吗？ 答题要点：单 Agent 用 ReAct 处理复杂任务；多 Agent 系统中，每个 Agent 内部可以用 ReAct，Agent 之间用 A2A 协议协调。

  • 追问 4：ReAct 和 Reflection 模式怎么结合？ 答题要点：ReAct 的每个循环内部可以嵌入 Reflection：思考 → 行动 → 观察 → 反射（检查结果是否正确）→ 下一轮。这样可以提升每步的质量。

面试总结 ​

ReAct 是构建复杂任务 Agent 的标准模式。面试时强调三点：

  1. 核心机制：思考-行动-观察的循环，走一步看一步
  2. 与单次调用的区别：动态决策 vs 预先规划，循环迭代 vs 一次完成
  3. 应用场景：多步推理、动态决策、需要根据中间结果调整的任务

记住：ReAct 不是万能的，它有延迟高、成本高的缺点。简单任务不要用 ReAct，复杂任务才需要。LangChain、LlamaIndex 的 Agent 实现几乎都是 ReAct 变体，掌握这个模式是 Agent 开发的基础。

章节首页 · ← Q62 · Q64 →

最后更新2026-05-05
难度P1
频率high
阅读8 min
主题agent / react / reasoning
觉得有帮助？把这个链接转给正在求职的朋友 · 用 Ctrl + K 全站搜索其它题