ReAct 不是什么新概念，但能把它聊透的人不多。本文从历史起源到工程兜底，帮你一次理清。
一、历史与作用
ReAct 决策循环由谷歌于 2022 年在学术论文中首次提出。当时的初衷很简单——为大语言模型构建一个标准化的执行框架，提升输出答案的准确率。
后来业界发现这框架天然适配智能 Agent 场景，于是被延伸应用至 Agent 领域，一路迭代至今。
在当前的 Agent 体系中，ReAct 解决了三个核心痛点：
- 短期记忆可解释性缺失——模型"黑盒"推理过程从此有迹可循
- 上下文截断缺陷——传统对话任务中长上下文的断裂问题得到改善
- 自主迭代能力——赋予 Agent 自我优化、持续改进的能力
二、ReAct 决策循环流程
ReAct 的核心包含三大环节：Reason → Action → Observation。
需要注意的是，这个框架在落地工程化 Agent 场景时，实际内涵已经和原始论文产生了偏离。原始论文的三大环节全部面向大模型自身能力设计；而在工程化架构中，体系被拆分为大模型与外部工具两层协同模式。
1. Reason（推理）
将用户请求输入大模型，由模型自主思考，决策后续的工具调用逻辑与执行思路。
2. Action（行动）
把大模型推理输出的决策指令下发至外部工具，完成具体的工具调用与业务执行动作。
3. Observation（观察）
汇总本轮推理、调用及执行的全量信息，回传给大模型，让模型完整感知本轮行为与结果，为下一轮决策提供依据。
三者之中，Observation 是核心环节。 通过复盘每一轮的执行结果，形成迭代优化依据，指导模型后续行为持续调优。
同时，ReAct 循环结构也是通用 Agent 短期记忆的主要承载载体。依托闭环结构，多轮对话与任务间的短期记忆得以连贯传递。
三、工程落地细节：提示词模板
工程实践中，ReAct 提示词模板的设计理念与多数学术论文、课程中的常规设计存在明显区别。
核心原则：极致精简、控制体量。
这条原则基于两点现实考量：
- 模型注意力资源存在上限——即便依托 Transformer 架构，超长上下文仍易引发输出不稳定。精简提示词可规避对用户原始 Query 的干扰，突出核心逻辑，提升推理稳定性。
- Token 即成本——当前高性能大模型的推理计费与 Token 消耗量强相关，精简模板是控制开销的关键优化手段。
工业级 ReAct 提示词四大模块
剔除冗余话术，不添加多余角色设定与背景描述，各模块分工明确：
1. 工具列表
采用轻量化嵌套 JSON 结构，本质是哈希表嵌套形式。外层定义工具名称，内层规范输入参数与输出字段，保证模型生成内容可被外部程序直接解析调用。
{
"tool_name": "搜索工具",
"input": {"query": "用户问题"},
"output": {"result": "工具返回结果"}
}
2. 固定输出格式
约束模型严格遵循 Reason → Action → Observation 的循环格式输出，固化执行逻辑，消除格式混乱问题，降低解析成本。
按以下格式响应：
Reason: 推理过程
Action: 工具调用（JSON）
Observation: 工具结果
3. 终止规则
用于规避模型无效空转、无限循环迭代。仅使用极简约束话术，要求模型在信息充足时主动终止推理循环并输出最终答案。循环次数上限交由代码层硬编码控制，不占用提示词 Token。
4. 业务特殊要求
可选自定义模块，根据落地场景补充专属业务约束——例如输出格式限制、敏感内容过滤、专业术语规范等。无特殊需求时直接省略。
一句话总结： 工程化 ReAct 提示词 = 工具列表 + 固定格式 + 终止规则 + 业务要求。四个模块，缺哪个看场景。
四、优化策略：兜底策略
工程落地中，ReAct 流程常会遇到三类典型异常，需要配套完整的兜底策略做异常闭环处理。
1. 无限思考与循环调用
方案：代码层设定最大迭代轮数，达到上限后强制终止工具调用。
- 已有有效中间结果 → 整理输出
- 无可用结论 → 直接告知用户任务无法完成
2. 调用超时、返回结果为空
业界有两种主流方式：
| 方式 | 说明 |
|---|---|
| 直接回传 | 将超时 / 空结果直接作为 Observation 回传给大模型，由模型自主复盘并调整思路重试 |
| 内置重试 | 在 ReAct 循环内部内置 2~3 次重试机制，把重试后的异常状态统一封装为 Observation 再交给模型决策，不额外侵入外部代码逻辑 |
多次重试仍无法解决 → 触发兜底逻辑，向用户反馈任务无法完成。
3. 返回格式错误
- 前端防御：在工具 JSON 定义中严格规范输出结构，明确告知模型无把握时仍需遵循指定格式生成
- 异常自愈：格式解析失败时将异常信息纳入 Observation，供模型自查修正
- 兜底容错：重试无效后对外告知本次任务执行失败
五、总结
| 维度 | 要点 |
|---|---|
| 框架结构 | Reason → Action → Observation 三层循环 |
| 核心环节 | Observation——复盘执行结果，驱动迭代优化 |
| 提示词设计 | 极致精简：工具列表 + 固定格式 + 终止规则 + 业务要求 |
| 异常兜底 | 轮数上限 + 内置重试 + 格式异常自愈 |
| 成本控制 | 精简提示词 Token 占用，代码层控制循环次数 |
ReAct 从理论框架到循环流程，从工程提示词设计到异常兜底优化，形成了一套完整可落地的闭环体系。它既保留了原始论文的核心推理思想，又针对工业场景做了精简、降本、稳定性与异常容错的适配。
说它是当下智能 Agent 开发中最通用、性价比最高的基础决策框架，不过分。
如果这篇文章对你有帮助，欢迎点赞收藏 ❤️ 有疑问或不同见解，评论区见。
