ReAct + Reflection 双循环机制：从原理到生产落地的完整指南
前言
如果你关注过 AI Agent 的技术架构，一定听说过 ReAct 这个词。它不是什么高深莫测的学术概念，而是一套非常朴实的工程范式------让大模型先思考、再行动、拿到结果继续思考，循环往复直到任务完成。
这套范式已经成为当今企业级 Agent 的事实标准。本文将结合生产落地实战经验，从原理到代码，从单循环到双循环，带你一次性吃透 ReAct + Reflection 机制。
一、ReAct 是什么
ReAct = Reason（推理思考）+ Act（行动执行）
大模型不再一次性输出答案，而是每走一步都先思考"我还缺什么信息"，然后决定是否调用外部工具（搜索、查数据库、调接口），拿到真实结果后继续推理，直到信息完备再输出最终答案。
它的核心思想可以概括为一句话：
不止空想，用外部真实行动补齐信息。
这与传统的 CoT（思维链）有本质区别------CoT 让模型"多想几步"，但依然是模型在脑补；而 ReAct 让模型"走出去拿证据"，依赖的是外部真实数据。
二、标准五层循环流程
ReAct 的标准循环是一个五步闭环：
Observation 观测层
↓
Thought 推理层
↓
Action 决策层
↓
Execution 执行层
↓
Feedback Observation 新观测层（回到推理层）逐层详解
1. Observation 观测层
接收用户提问、历史对话、上一轮工具返回结果、会话状态、环境变量，整合为完整上下文输入。
2. Thought 推理层
模型进行结构化思考：问题缺口在哪、缺什么信息、用什么路径解决、是否需要外部能力。
3. Action 决策层
确定调用工具名称、入参字段、调用优先级，生成标准化调用指令。
4. Execution 执行层
路由分发、参数校验、权限校验、重试策略、超时控制，执行真实外部调用。
5. Feedback Observation 反馈观测层
清洗、精简、过滤工具返回数据，剔除冗余内容，更新上下文，进入下一轮循环。
分支判定逻辑
模型每轮思考后，有两个出口：
| 分支 | 含义 | 触发条件 |
|---|---|---|
| Finish Action | 结束推理，汇总答案 | 信息已充足，无需更多工具调用 |
| Tool Action | 指定工具+参数，发起调用 | 信息缺口存在，需要外部数据 |
通俗示例
用户问：2026 年武汉高考人数多少？
- Observation：用户问 2026 武汉高考人数
- Thought：我不知道实时数据，必须联网搜索
- Action：调用 Search 工具
- Action Input：query=2026 年武汉高考报名人数
- Observation：拿到搜索结果 → "6.5 万人"
- 再次 Thought：信息足够，无需再调用工具
- Finish：整理答案输出
三、生产落地：四层工程管控
原生 ReAct 只做逻辑循环，生产落地必须叠加四层工程管控。
这是把 Demo 变成产品的关键分水岭。
1. 次数熔断层
限制最大迭代轮次（默认 5~8 轮）、单会话最大工具调用数，到达上限强制终止。
2. 规则强控层
高危操作、数据删除、资金操作、隐私查询禁止模型自主 Action，走人工审批流程。例如：删除订单、转账汇款、查询他人隐私数据。
3. 性能延时层
单工具超时、全链路总超时、并发限流、排队降级。
4. 成本管控层
Token 计数、调用计费统计、超额自动降级切换小模型或模板应答。
生产级终止条件
强制硬终止（优先级最高）：
- 达到最大 ReAct 迭代轮次
- 单会话最大工具调用次数超限
- 全链路请求超时
- 总消耗 Token 超出会话配额
- 触发敏感/高危操作拦截
智能软终止（模型自主判断）：
- 已集齐全部所需信息
- 多次调用结果一致，无新增信息
- 问题无可行外部工具可解决
- 答案可信度达标
四、三大生产痛点及解决方案
痛点 1：无限循环死调用
现象：模型不停调工具，永无止境。
方案 ：全局轮次计数器 + 时间双熔断，到达上限强制截断。这不是"尽量优化"，而是必须实现的硬约束。
痛点 2：上下文爆炸、Token 暴涨
现象：每轮工具返回结果不断累加，上下文越来越长，成本飙升。
方案：
- 工具返回结果摘要精简后存入上下文，而非原始数据
- 历史对话滑动窗口裁剪
- 非关键观测信息丢弃
痛点 3：模型随意调用高危接口
现象：模型在不可预知的路径下，自主发起危险操作。
方案：
- 工具分级：通用工具放开，业务高危工具规则锁死
- Action 指令先过规则引擎校验，不通过直接驳回，不给模型执行机会
五、从单循环到双循环：引入 Reflection
纯 ReAct 有一个致命短板------容易思路跑偏、调用无效工具、拿到错误数据而不自知。就像一个人只知道埋头干活，从不回头检查成果。
Reflection（反思循环） 就是来解决这个问题的。
核心关系
| 循环 | 职责 | 方向 |
|---|---|---|
| ReAct 主循环 | 思考→行动→拿结果，信息搜集、工具执行、任务推进 | 向外解决问题 |
| Reflection 子循环 | 复盘→纠错→优化，校验结果、修正思路、补齐漏洞 | 向内自查自检 |
融合模式：ReAct 推进任务，Reflection 逐层校验纠偏，形成"执行+复盘"双闭环。
Reflection 四步流程
1. Review 回顾
复盘上一轮 ReAct：调用了什么工具、传入什么参数、拿到什么结果、执行是否顺畅
2. Evaluate 评估（三方面打分）
- 信息完整性：是否拿到所需内容
- 结果准确性：数据/内容是否可靠无误
- 路径合理性：执行思路是否走偏、是否绕路
3. Correct 纠错
- 参数错误 → 修正调用参数
- 工具选错 → 更换适配工具
- 信息不足 → 补充新增检索维度
- 逻辑错误 → 推翻原有思考重新推理
4. Replan 重规划
基于反思结论，生成新一轮更合理的 ReAct 执行思路两种融合模式
模式 1：逐轮反思（轻量常用）
每跑完 1 轮 ReAct，立刻进入 1 次 Reflection 反思校验。
适用场景：问答检索、简单多轮查询、实时客服。
模式 2：阶段式反思（重度复杂任务）
连续跑完多轮 ReAct 完成一个子任务阶段，统一批量反思复盘。
适用场景：数据分析、方案撰写、复杂流程编排、长链路业务。
业务实战示例
需求：查询近一月门店营收并生成精简分析
- ReAct1：调用营收 SQL 查询 → 拿到原始营收数据
- Reflection1 反思：
- 回顾：只拿到总额，无环比、无客流维度
- 评估：信息不全，无法分析
- 纠错：需补充同期数据 + 客流数据
- 重规划：新增两个查询动作
- ReAct2：批量调取环比数据、门店客流数据
- Reflection2 反思：
- 评估：数据齐全、维度完整、无错误
- 判定：无需再优化
- 退出双循环，汇总数据生成分析结论
反思停止机制（生产必配）
硬停止：
- 单阶段最大反思次数（默认 3 轮）
- 整体会话超时、Token 用尽直接终止
软停止：
- 评估得分达标，结果满足业务要求
- 连续两次反思无优化空间，判定已达最优解
- 已无法通过现有工具继续优化
六、与 NLU + DM + NLG 整体架构融合
ReAct 不是独立存在的，它嵌入在对话系统的整体架构中：
用户输入 → NLU（意图识别+实体抽取）
↓
DM 对话管理层（状态管理+会话持久化）
├── ReAct 循环（任务执行引擎）
└── Reflection 循环（质量校验引擎）
↓
NLG（话术生成+格式适配+安全审核）
↓
输出各层职责：
| 模块 | 职责 |
|---|---|
| NLU | 输出意图、实体、业务约束，作为双循环初始输入 |
| DM 对话管理层 | 维护会话状态、轮次计数、反思次数；控制执行节奏、触发反思时机；统一管理熔断、规则、权限、成本限流 |
| ReAct | DM 内部任务执行引擎，负责任务拆解、路径决策、工具调度、多轮推演 |
| Reflection | DM 内部质量校验 & 纠错引擎，负责结果审查、逻辑纠偏 |
| NLG | 双循环全部终止后，统一整理结构化结果，生成自然话术对外输出 |
七、核心伪代码
python
# 全局硬限制
MAX_REACT_ROUND = 8
MAX_REFLECT_ROUND = 3
def react_run(user_query, session_state):
"""纯 ReAct 模式"""
obs = init_observation(user_query)
while True:
# 硬终止判定
if session_state.round >= MAX_REACT_ROUND or session_state.time_out():
break
thought = llm_reason(obs)
action = llm_parse_action(thought)
if action.is_finish:
break
# 规则拦截
if rule_check_block(action):
break
# 执行工具
res = execute_tool(action)
obs = refresh_observation(obs, res)
session_state.round += 1
return llm_summary(obs)
def react_reflect_pipeline(user_query, session_state):
"""ReAct + Reflection 双循环"""
observation = build_init_obs(user_query)
while session_state.react_round < MAX_REACT_ROUND:
# ========== ReAct 外循环 ==========
thought = llm_reason(observation)
action = parse_action(thought)
if action.is_finish:
break
if rule_block(action):
break
tool_result = execute_tool(action)
observation = update_obs(observation, tool_result)
session_state.react_round += 1
# ========== Reflection 内循环 ==========
reflect_cnt = 0
while reflect_cnt < MAX_REFLECT_ROUND:
review_info = review_last_react(observation)
eval_res = evaluate_result(review_info)
if eval_res.pass_ok:
break
correct_info = correct_error(eval_res)
observation = replan_update_obs(correct_info)
reflect_cnt += 1
# 双循环结束，生成最终回答
return nlg_summary(observation)八、生产级 Prompt 模板
你严格遵循 ReAct 推理范式：
Observation -> Thought -> Action -> ActionInput
约束规则：
1. 最多进行 {max_round} 轮工具调用，超出直接总结现有信息回答
2. 仅可使用给定工具列表，不可编造工具
3. 涉及隐私、删除、资金操作禁止发起调用
4. 工具结果简洁提炼，不要冗余复述
可用工具：
1. search - 联网搜索
2. sql_query - 数据查询
3. calculator - 数值计算
用户问题：{{user_query}}
历史观测记录：{{history_obs}}
请开始推理。九、双循环核心优势
- 解决纯 ReAct 短板：自动纠偏，大幅提升任务正确率
- 降低幻觉：ReAct 拿事实，Reflection 审事实，双重控假
- 复杂任务自优化：自主发现流程漏洞、补齐信息缺口、调整执行策略
- 工程可控性强：两层循环均配置独立熔断上限，不会无限执行
十、面试速记版
ReAct 是思考+行动交替循环的 Agent 推理范式，模型先思考分析问题缺口，主动调用外部工具获取信息，把返回结果作为新观测再次推理，不断迭代直至信息充足，最终输出答案，有效降低大模型幻觉。
ReAct + Reflection 双循环 进一步在每轮或每阶段执行后引入反思校验机制，Review → Evaluate → Correct → Replan 四步闭环，自动发现并修正执行偏差。
生产落地必须叠加轮次熔断、超时控制、权限规则、成本限流四重约束，杜绝死循环与越权行为。这是目前企业级多工具智能 Agent 最主流的双闭环执行架构。
结语
ReAct 范式看似简单------思考、行动、再思考------但正是这个朴素的循环，解决了大模型"只会空想、不会求证"的核心痛点。加上 Reflection 反思机制后，Agent 不仅会做，还会检查自己做得好不好，实现了从"单线程执行"到"执行+复盘"的进化。
在实际生产落地中，工程管控比算法设计更重要。轮次熔断、权限校验、成本控制这些看似"不性感"的东西，恰恰是决定一个 Agent 系统能否真正上线运行的关键。
希望这篇文章能帮你从原理到实践，全面掌握 ReAct + Reflection 双循环机制。