ReAct 模式是什么？和 Function Calling 有什么关系？

详细解析#

为什么要让推理和行动交替进行#

ReAct 出自 Yao 等人 2022 年的论文。核心思想是两者互补：推理让行动有计划、能随结果调整，行动给推理提供真实依据，减少凭空编造。什么是 Agent 里有一个最简单的例子，下面看一个结果会改变后续决策的轨迹。

一段轨迹#

问题：我上周买的耳机怎么还没到？

Thought: 先找到用户最近购买耳机的订单
Action: search_orders({"keyword": "耳机"})
Observation: 订单 O123，已发货，快递单号 SF1001
Thought: 已经发货，接下来查物流
Action: track_shipment({"trackingNo": "SF1001"})
Observation: 3 天前到达转运中心，之后没有更新
Thought: 物流停滞超过 3 天，属于异常，按规则可以帮用户催件
Action: create_ticket({"type": "催件", "orderId": "O123"})
Observation: 工单 T88 已创建
Final Answer: 订单已经发货，但物流 3 天没有更新，已为你创建催件工单 T88……

第二步和第三步做什么，都取决于上一步的观察结果，这是 ReAct 和"一次性规划好再执行"的区别。

早期实现：Prompt 约定格式，再解析文本#

const prompt = `你可以使用以下工具：${toolDescriptions}
按下面的格式交替输出，直到得出答案：
Thought: 你的思考
Action: 工具名[输入]
Observation: 工具结果（由系统填写，你不要写）
Final Answer: 最终答案

问题：${question}
${history}`

// llm.complete 是文本补全的伪接口。遇到 Observation 就停止，防止模型自己编造工具结果
const text = await llm.complete({ prompt, stop: ['\nObservation:'] })
const final = text.match(/Final Answer:\s*([\s\S]*)/)
const action = text.match(/Action:\s*(\w+)\[([\s\S]*?)\]/)
// 两者都匹配不到说明格式不对，要把错误提示追加到 history 里让模型重来

这种写法的问题：格式经常出错，解析容易失败；参数只能是一段字符串，很难表达结构化的参数；工具结果和指令混在同一段文本里。

现在的实现：基于原生工具调用#

• 工具定义通过接口参数传入，模型用专门的结构返回工具名和 JSON 参数，不用再解析文本
• 工具结果作为单独的消息回传，和普通对话内容分开，模型也没法"替系统"编造结果
• Thought 的位置：可以是模型调用工具前输出的一段说明文字；推理模型则在内部的思考过程中完成。不少接口只返回思考的摘要或加密数据，不返回完整原文。多步工具调用时，有的接口要求把返回的思考块原样回传（如 Anthropic 的 thinking 块，同一轮工具调用中必须完整、不加修改地传回），有的建议回传（如 OpenAI Responses API 的 reasoning 项），让模型接着之前的推理继续
• 循环的完整代码见 手写一个最小的 Agent 循环

ReAct 的问题#

• 步骤多：每一步都是一次模型调用，延迟和成本随步数增加，上下文越来越长
• 容易跑偏：只看眼前一步，缺少全局计划；前面一步出错会一路传下去；可能在两个动作之间来回打转
• 被观察结果带偏：工具返回的内容很长或带有误导信息时，模型可能偏离最初的目标

改进方向：先做计划再执行，见 Agent 的规划能力是怎么实现的；设置步数上限和重复检测，见 怎么防止 Agent 失控。

面试官可能追问#

易错点#

• 把 ReAct 当成某个框架或 API。它是一种模式，任何能调用工具的循环都可以实现
• 把 ReAct 和 Function Calling 混为一谈：一个是组织方式，一个是接口能力
• 认为思考写得越长越好。推理会增加延迟和成本，简单任务直接行动反而更好