ReAct 是什么
ReAct 是推理与行动交替的模式：模型先想一步（Thought），决定调用什么工具、传什么参数（Action），拿到工具返回结果（Observation）后再想下一步，如此循环，直到信息足够给出结论。Yao 等人 2022 年提出这个框架时的观察是，只推理不行动会受限于模型已有知识，只行动不推理又容易在错误方向上空跑；交替进行能让推理被外部结果校正。它是今天工具型 Agent 的基础循环。
三个角色各管什么
Thought 负责定方向：现在缺什么信息、下一步该做什么。Action 触发外部能力：检索、查库、执行计算、调用接口。Observation 是唯一的新信息来源，模型必须基于它继续，而不是忽略它凭原有猜测往下走。工程实现上，Thought 与 Action 由模型输出，Observation 由系统在执行工具后回填，模型不能自己编造 Observation——这是最常见的失败模式。
基本要素
| 循环结构 | Thought → Action → Observation，可重复多轮，最后给 Final Answer |
|---|---|
| 工具清单 | 白名单方式声明可用工具、参数格式与各自的使用条件 |
| 轮数上限 | 设置最大轮数（如 5 轮）与总时长，防止原地打转 |
| 停止条件 | 信息足够、达到轮数上限、或工具连续报错时退出并说明 |
| 参数温度 | 多步流程取低温（0 - 0.2），让动作序列可预测、可复现 |
典型使用场景
- 检索增强问答：先查资料再回答，答案是资料与推理的结合
- 运维排障助手：查询监控、拉取日志、核对配置，每步结果决定下一步
- 数据核对流程：读接口、比对字段、输出差异清单
- 多系统操作：查询订单状态、发起工单、回写备注的串联流程
- 需要留痕的自动化：每步的思考与动作都写进日志，便于复盘与审计
提示骨架
提示骨架
按以下循环作答：
Thought: 我还缺什么信息？ # 定方向，只写一句
Action: 调用哪个工具、参数是什么 # 参数按声明格式写，不自由发挥
Observation: （由系统回填，模型不得自行编造）
……（循环，最多 5 轮）
Final Answer: 结论与依据工具声明片段
工具声明片段
可用工具：
- search(query)：检索文档，返回前 5 条片段
- run_sql(sql)：只读查询，禁止写操作 # 权限用只读账号兜底
使用条件：涉及实时数据时先 search；证据不足时说明缺什么，不要猜。
收到 [TOOL_RESULT: …] 后继续推理；不需要工具的问题直接回答。失败模式与对策
| 失败模式 | 表现 | 对策 |
|---|---|---|
| 原地打转 | 反复调用同一工具、参数几乎不变 | 限制轮数，要求每轮不得重复上次动作 |
| 忽视观察结果 | 拿到结果仍按原假设作答 | 在提示中写明结论必须引用 Observation 内容 |
| 编造观察结果 | 模型自己写了工具返回内容 | Observation 只允许系统回填，提示里明确禁止 |
| 工具选择错误 | 该检索却直接回答，或调错工具 | 在工具描述里写清使用条件与不适用场景 |
| 死循环报错 | 工具连续失败仍重试 | 设失败次数上限，超限则转人工或给出部分结论 |
工具权限按最小可用原则配置：只读账号、参数校验、调用频率上限，模型输出不能直接当命令执行。
ReAct 的收益在需要外部信息的任务上最明显；纯推理题用普通思维链即可，套上循环只会增加延迟与失败面。