考察点
这道题出自 Google 大模型应用岗的技术面试，DSPrep 标注 Google/Amazon/OpenAI 三家常考，是 Agent 方向最经典的一题。面试官想确认你理解 ReAct 不只是一篇论文，而是「让 LLM 当控制器、工具当执行器」的工程范式——循环怎么收敛、轨迹怎么进 prompt、失败怎么回传。做过的人会主动讲工具描述工程、max_iterations、轨迹 token 膨胀这些坑；只背过概念的人会停在「先想再做再观察」。追问会往 function calling 与 ReAct 的关系、plan-and-execute、多智能体走。
参考答案
ReAct 循环的本质：LLM 当控制器
ReAct（Reasoning + Acting）的核心思想是让模型把「想」和「做」交织起来，每一步输出结构化的三段：
- Thought：对当前局的推理——我现在知道什么、还缺什么、下一步该干嘛；
- Action：从注册的工具里挑一个，给出结构化参数；
- Observation：工具执行结果，由框架执行后回填，作为下一轮输入。
如此循环，直到模型输出「我有足够信息了」给出最终答案，或者撞上迭代上限。它解决的根本问题是：LLM 的知识是冻结的、计算是不可靠的，查证交给搜索、算术交给计算器、业务数据交给 API，模型只负责规划下一步——这正是它比自己硬编答案可靠的原因。论文里在 HotpotQA 这类多跳问答上，ReAct 明显减少了纯 CoT 的幻觉率，因为事实来自 Observation 而非参数记忆。
在 LangChain 里落地，关键不在 API 在细节
框架层面很简单：定义若干 @tool 装饰的函数（名称、描述、参数 schema），创建 ReAct 风格 agent，套进 AgentExecutor 跑。真正的工程量在三处：
工具描述是 Agent 的「产品文档」。 模型的工具选择全靠 name + description + 参数注释，写得含糊它就乱选。好的描述要回答「什么时候用我、什么时候别用我」：search_docs 写成「搜索内部产品文档，适合查功能用法；不适用于查询订单状态，订单用 query_order」比一句「搜索文档」的调用准确率高一截。参数同理，date: 格式 YYYY-MM-DD，相对日期如"今天"需先换算，能省掉大量参数错误。
错误必须作为 Observation 回传，不能抛异常中断。 工具执行失败（超时、参数非法、空结果），要把错误信息包装成文本喂回给模型，让它在下一轮 Thought 里看到失败原因并调整——换个参数重试、换个工具、或者承认做不到。直接 raise 把循环炸掉是最常见的初级错误。空结果也要显式回传「未找到」，否则模型会把沉默当成成功继续编。
收敛控制三件套：max_iterations、超时、轨迹预算。 ReAct 循环不保证收敛——模型可能在两个工具间反复横跳，或者对一个失败工具无限重试。max_iterations 一般设 5-10，撞限后要优雅降级成「基于已有信息回答 + 说明未完成的部分」。另一个隐形炸弹是轨迹膨胀：每一步的 Thought-Action-Observation 都追加进 prompt，一个检索结果几千 token，十步之后 prompt 几万 token，延迟和成本失控。工程上要对 Observation 截断（比如单次工具返回限 2000 token），必要时滚动摘要早期轨迹。
ReAct 和 function calling 的关系
现在主流模型原生支持 tool calling，很多场景已经不用 prompt 模拟 ReAct 文本格式再正则解析了——模型直接输出结构化 tool_calls，可靠性高一个量级。但 ReAct 的思想依然是理解 Agent 的框架：显式推理轨迹、工具结果回传、迭代收敛。面试里能说清「prompt 版 ReAct 是协议，native tool calling 是能力升级，循环范式没变」，比只会背论文强。另外对不支持 tool calling 的开源小模型，prompt 版 ReAct 仍是可用方案，代价是要写健壮的输出解析和修复逻辑。
可能的追问
1. ReAct 和 plan-and-execute 怎么选？
ReAct 是边想边做，适合步骤不可预知、每步依赖上一步结果的任务；plan-and-execute 先出完整计划再逐步执行，适合步骤可预见的长任务，能减少 LLM 调用次数，但计划错了要 replan。复杂任务可以混合：先粗 plan，执行中按 ReAct 局部调整。
2. 怎么调试 Agent 的诡异行为？
把完整轨迹（每步 Thought/Action/Observation/耗时）打到 LangSmith 或自己的 tracing 里，逐轮复盘模型为什么选这个工具、Observation 里有什么误导。Agent 的 bug 九成在工具描述歧义或回传信息不完整，靠轨迹能定位。
3. 工具很多（几十个）时怎么办？
不要全塞进 prompt——选择空间太大模型会选错，描述也吃 token。按意图先路由：用检索或小模型把用户问题映射到 3-5 个候选工具，再进 ReAct 循环。工具集市化之后「工具检索」本身就是个召回问题。