ReAct 推理范式是什么？它如何让 Agent 更可靠地完成任务？
参考答案
ReAct（Reasoning + Acting）是 2022 年由 Google 和普林斯顿大学提出的一种让大模型交替进行推理和行动的范式。核心思路是：让模型在执行每一步操作之前，先用自然语言”想一想”为什么要这么做，然后再去做，做完之后再根据结果”想一想”下一步该怎么办。
在 ReAct 出现之前，推理和行动是分开的。Chain-of-Thought 让模型一步步推理，但只停留在”想”的层面，不能真正去做事。纯 Action 模式让模型直接输出工具调用，但不会解释为什么这么做，出了问题也很难排查。
ReAct 把两者结合起来了。一个典型的 ReAct 步骤：Thought（我需要查一下用户提到的这个公司的最新财报）→ Action（调用搜索工具，关键词”XX 公司 202x 年 Q1 财报”）→ Observation（搜索返回了以下结果…）→ Thought（根据搜索结果，营收同比增长 15%，我现在可以回答用户了）。
这种范式让 Agent 更可靠的原因有两个。第一，推理过程是显式的，每一步决策都有 trace 可查，出了问题容易定位是哪一步推理出了偏差。第二，模型会基于观察结果动态调整策略，而不是一开始就制定一个死板的计划然后盲目执行。某个工具调用结果不符合预期，模型可以在下一个 Thought 中立刻调整方向。
扩展知识
ReAct 的工程实现
在早期实现中，ReAct 通过 Prompt 引导模型按特定格式输出：
1 | ▼ |
不过在目前实际 Agent 系统中，很多框架已经不严格按这种文本格式来了。现代做法是利用大模型原生的 Function Calling 能力来处理 Action 部分，Thought 部分可能是模型内部的推理过程（Claude 的 extended thinking、OpenAI 的 reasoning tokens），也可能被简化掉。但 ReAct 的核心思想，推理和行动交替进行，仍然是几乎所有 Agent 系统的底层范式。
ReAct 的局限性
最大的问题是它本质上是一种”顺序推理”模式，每一步只往前走一步，不会回头审视整个执行过程。如果前面某一步的推理方向就偏了，后续步骤会在错误基础上继续走，越走越远。
效率也是个问题。每一步都要生成 Thought 文本，额外消耗 token。对于”查个天气”这种简单操作，花 50 个 token 来”思考”为什么要查天气，纯属浪费。所以很多生产环境中的 Agent 会做优化：简单操作跳过 Thought 步骤，只在复杂决策节点才进行显式推理。
ReAct vs Plan-and-Execute
ReAct 是”走一步看一步”的模式，适合需要根据实时信息动态调整的场景。Plan-and-Execute 是”先规划再执行”的模式，先让模型制定一个完整计划，然后逐步执行。
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 决策时机 | 每一步都决策 | 开头一次性规划 |
| 灵活性 | 高，随时能调整方向 | 低，计划定了就按步骤走 |
| Token 消耗 | 高，每步都要推理 | 低，规划一次后续执行不需要反复思考 |
| 适合场景 | 不确定性高、需要动态探索 | 步骤明确、信息充分 |
| 典型应用 | 信息检索、问题排查 | 代码重构、批量数据处理 |
成熟的 Agent 系统会根据任务复杂度动态选择。OpenAI 的 GPT-5.5 等模型内置了类似 Plan-and-Execute 的规划能力，遇到复杂任务先拆分再逐步执行；Claude Code 则更偏 ReAct 风格，走一步看一步，灵活应对各种意外情况。
从 ReAct 到 Reflexion
ReAct 的”不会回头看”问题催生了 Reflexion 这个改进范式。Reflexion 在 ReAct 的基础上加了一层自我反思：任务执行完或失败后，Agent 会回顾整个过程，总结经验教训，然后把这些反思存到记忆里。下次遇到类似任务时，可以调取之前的反思来避免重复犯错。
这个思路在 2025-2026 年的 Agent 系统中已经被广泛采用，很多框架都在 Agent Loop 里内置了 reflection 步骤。
面试官追问
提问：ReAct 在实际工程中怎么防止模型的 Thought 越写越长，导致上下文爆炸？
回答：主流做法有三种。第一种是在 system prompt 里约束模型”推理部分控制在 2-3 句话以内，只写关键判断依据”，模型会自行压缩推理，效果损失很小。第二种是在拼接历史上下文时，只保留过去轮次的 Action 和 Observation，把历史 Thought 摘要或直接省略掉，这样不影响当前轮的推理质量，又能节省大量上下文空间。第三种是利用模型的 thinking/reasoning 字段（如 Claude 的 extended thinking），推理过程不计入对话历史，不会拼回后续请求，从根本上避免了上下文膨胀。
提问：如果 ReAct 过程中工具调用返回了错误结果，模型怎么知道结果是错的？
回答：模型本身没有能力验证工具结果的绝对正确性，但它能做合理性判断。比如查询”2026 年美国总统”，如果工具返回了一个 2019 年的新闻，模型可以从时间上判断这不对。工程上常见的做法是给 Observation 附加元信息，比如 HTTP 状态码、数据时效性标记。更激进的方案是引入 validator Agent，专门负责校验每一步的结果合理性，不合理就让执行 Agent 重试。
提问：ReAct 范式和现在的 Function Calling 是什么关系？是替代还是互补？
回答：两者是不同层面的东西，互补而非替代。ReAct 是一种推理范式，定义了”先思考再行动再观察”的循环结构；Function Calling 是 Action 环节的工程实现，让工具调用从”模型输出文本 → 正则解析”升级为”模型输出结构化 JSON → 直接调用”，更可靠也更易维护。用主流大模型做 Agent 开发时，模型在决定调用哪个 function 之前，内部一定经历了类似 Thought 的推理步骤，只是这个推理过程不一定以显式文本暴露出来。所以本质上现在的 Function Calling Agent 仍然在跑 ReAct 循环，只是 Thought 可能隐式化了，Action 的格式从自由文本变成了结构化调用。