ReAct
一句话定义
ReAct（Reasoning + Acting）是Single-Agent的重要构建范式，通过”思考(Thought)→行动(Action)→观察(Observation)“的循环让Agent能够自主推理并逐步调用工具解决问题。
摘要
ReAct范式由Yao等人在2022年提出，核心思想是让大模型在执行任务时交替进行推理和行动。与传统的单一推理或单一行动不同，ReAct将二者结合，使Agent能够”自言自语”地规划，一步步调用工具、补充上下文来解决问题。在大淘宝技术的实践中，ReAct被用于秒杀AI答疑系统的域Agent构建，与Plan范式结合形成更强大的计划-推理能力。
详情
起源与背景
ReAct范式由Shunyu Yao等人在2022年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出。其核心观察是：纯推理方法（如Chain-of-Thought）缺乏与外部世界的交互能力，纯行动方法（如Act-only）缺乏高层次的规划能力。ReAct将二者融合，让模型在推理的同时可以行动，在行动的同时可以推理。
核心机制 / 工作原理
ReAct循环
Thought: 我需要查询商品X的报名状态
Action: 调用query_product_status(product_id="X")
Observation: 商品X状态为"审核中"，报名时间为2026-05-28
Thought: 商品已在审核中，我需要检查审核进度
Action: 调用check_audit_progress(product_id="X")
Observation: 审核进度60%，预计还需2小时
Thought: 我已经获取了完整信息，可以回答用户
Action: 返回答案
单步思考的局限
ReAct每次都是基于当前信息推理下一步的最佳行动，这种单步思考的方式决定了它更擅长解决理性类问题（如排查一个商品为什么不能报名），对于主观类问题效果有限。因此实践中通常会结合Plan范式：
- Plan：产出全局计划，沉淀优秀计划模版
- ReAct：执行细分领域推理，在垂直领域表现出更好的效果
应用场景
- 多步骤工具调用的任务
- 需要中间推理过程的复杂查询
- 与Plan结合形成PlanAgent的推理引擎
- Multi-Agent中各域Agent的核心推理机制
局限与注意事项
- 单步推理可能陷入局部最优，缺乏全局视角
- 对主观类问题效果不佳，需结合Plan范式
- 推理链过长时可能出现错误累积
- Token消耗较大，需要控制推理轮次
与其他范式的对比
| 范式 | 核心思想 | 优势 | 劣势 |
|---|---|---|---|
| ReAct | 推理+行动交替 | 可解释性强、可调用工具 | 单步视角、Token消耗大 |
| Plan | 全局规划后执行 | 全局最优、可复用计划 | 计划质量依赖模型能力 |
| CoT | 纯推理链 | 简单高效 | 无法与外部交互 |
| Reflexion | 反思+自我修正 | 可从错误中学习 | 额外推理开销 |
与 Loop Engineering 的关系：Inner Loop
腾讯技术工程在 CodeBuddy 的实践中把 ReAct 明确定位为 Loop-Engineering 的 Inner Loop——ReAct 负责”单次任务内怎么一步步做”（思考→行动→观察），外层 Loop Engineering 作为 Outer Loop 负责”跨任务做什么、谁来做、何时停、怎么续”。
两者不是替代而是叠加：在 CodeBuddy 里用 /goal 设一个可验证条件后，每一轮内部 AI 仍以 ReAct 模式思考-行动，而 /goal 的独立评估器在 Outer Loop 层面判断整体进度是否达成。ReAct 的几个固有局限（上下文窗口有限会遗忘、同模型自我检查有盲区、无跨任务进度记录、单 Agent 串行）正是 Loop Engineering 用状态外置、对抗验证、断点续跑、多 Agent 并行来补位的。演进链可记为 Prompt（怎么问）→ ReAct（怎么做）→ Loop Engineering（怎么管）。
在大淘宝技术中的实践
在秒杀AI答疑场景中，ReAct被用于各业务域Agent的核心推理引擎：
- 商品域Agent：基于ReAct推理商品报名失败原因
- 订单域Agent：排查订单状态异常
- 库存域Agent：分析库存扣减问题
- 报名域Agent：处理报名流程中的复杂问题
每个域Agent基于ReAct+Plan范式实现，由中心Agent统一做意图识别与任务分发，形成MOE（混合专家）形态的Multi-Agent系统。