跳到主要内容

ReAct范式

1. 定义与边界​

ReAct 是 Reasoning and Acting 的缩写，来自论文《ReAct: Synergizing Reasoning and Acting in Language Models》。它的核心思想是让模型在任务过程中交替生成推理线索和行动，通过外部观察结果修正后续步骤。

典型结构：

Thought -> Action -> Observation -> Thought -> Action -> Observation -> Final

在生产系统中，不一定要暴露完整 Thought；更重要的是让系统保留“决策摘要、行动、观察、状态更新”的可审计轨迹。

2. 为什么重要​

ReAct 解决了纯 Chain-of-Thought 和纯工具调用的两个缺陷：

  • 纯推理容易在缺少外部信息时编造。
  • 纯行动缺少解释和计划，容易盲目调用工具。

ReAct 通过观察结果让模型接地，适合搜索、问答、代码、排错、导航等需要多步交互的任务。

3. 核心机制​

ReAct 的关键不是“写出思维链”，而是把行动与观察嵌入循环。

ReAct 状态结构​

ReAct 在工程上应保存可审计的“推理摘要-行动-观察”三元组，而不是依赖不可控的长篇 Thought。

{
  "step": 2,
  "reasoning_summary": "需要确认订单状态后才能判断退款路径",
  "action": {
    "tool": "get_order",
    "arguments": {"order_id": "A123"}
  },
  "observation": {
    "status": "ok",
    "summary": "订单已签收，物流显示本人签收",
    "evidence_id": "obs_002"
  },
  "next_constraint": "必须读取退款政策后再决定是否建单"
}

4. 架构模式​

显式 ReAct​

Prompt 中要求模型输出 thought/action/observation 格式。适合研究和调试，但在生产中要谨慎暴露内部推理。

隐式 ReAct​

使用工具调用 API 或 Agent SDK，让模型选择工具，系统记录决策摘要和工具结果。更适合生产。

ReAct + Workflow​

Workflow 固定外层流程，内部某个节点使用 ReAct 处理探索性任务。

ReAct + Reflection​

在若干步后加入评估器或自评步骤，检查是否偏离目标。

5. 工程实现​

工具调用版 ReAct：

def react_loop(question, tools):
    state = {"question": question, "observations": []}

    for step in range(6):
        decision = model.choose_action(
            context=state,
            tools=[tool.schema for tool in tools]
        )

        if decision.type == "final":
            return validate_final(decision.output)

        tool = tools[decision.tool_name]
        args = validate_args(tool.schema, decision.arguments)
        observation = tool.invoke(args)

        state["observations"].append({
            "tool": tool.name,
            "args": redact(args),
            "result_summary": summarize(observation)
        })

    raise AgentFailed("max_steps_exceeded")

Prompt 结构示例：

任务：基于可用工具回答问题。
规则：
1. 不要猜测工具可查到的信息。
2. 每次只调用一个最相关工具。
3. 工具返回不足时说明缺口或请求升级。
4. 最多 6 步。

工程示例：政策问答不是一步 RAG​

用户问题：“客户说没收到货，要退款，我该怎么处理？”

一个 ReAct 轨迹应像这样：

步骤决策摘要行动观察下一步
1需要确认订单真实状态get_order(A123)订单已签收查政策
2签收后退款需看物流争议政策read_refund_policy(status=delivered)需先建物流争议创建争议草稿
3不能直接退款，应建争议工单create_dispute_ticket工单创建成功输出处理建议

如果系统第一步就回答“可以退款”或“不能退款”，它不是 ReAct，只是基于不完整上下文的猜测。

6. 生产实践​

问题实践
观察结果过长工具返回结构化摘要和引用
调用工具过多限制步数、工具分组、先路由后执行
错误观察对工具结果做校验和可信度标记
推理不可审计记录 decision_summary、tool、args、observation
结果不稳定用任务集回归测试轨迹

7. 常见反模式​

反模式表现后果修正
长 Thought 当解释保存或展示大段内部推理泄漏风险、解释不稳定保存决策摘要和证据
Observation 原样拼接网页、日志、邮件整段进入上下文上下文污染和注入风险工具返回结构化摘要和来源
工具失败后硬答timeout 或 policy conflict 后仍 final编造和错误行动将错误转为状态，重试或升级
每步看全历史上下文越来越大成本高、注意力稀释滚动摘要 + 必要证据引用
任何任务都 ReAct一步检索也多轮循环延迟和成本浪费先判断是否需要多步观察
Action 无参数校验模型输出直接调用工具参数错、越权、重复写schema、权限、幂等校验

8. 评测方法​

ReAct 需要评测轨迹：

指标说明
Required Tool Coverage是否调用必须工具
Forbidden Tool Avoidance是否避免禁用工具
Observation Usefulness最终答案是否基于观察结果
Step Efficiency是否多次无效搜索或重复调用
Error Recovery工具失败后是否换策略或升级

评测样本应包含干扰信息、工具错误、缺失数据和 prompt injection 文档。

轨迹级断言示例：

{
  "id": "react_refund_007",
  "required_order": ["get_order", "read_refund_policy"],
  "allowed_extra_tools": ["create_dispute_ticket", "ask_user_clarification"],
  "forbidden_tools": ["issue_payment"],
  "assertions": [
    "final_answer cites at least one observation",
    "no final answer before policy observation",
    "tool error must not be treated as success"
  ]
}

9. 安全与治理​

ReAct 的风险在于模型会把观察内容纳入后续思考。如果观察来自网页、邮件、文档或 MCP 工具结果，必须防止其中的恶意指令影响系统目标。

控制手段：

  • 外部观察结果标记为不可信数据。
  • 工具结果只返回必要字段。
  • 系统指令和外部内容结构隔离。
  • 高风险行动不因模型推理而自动授权。
  • 对行动前参数做策略校验。

10. 权威资料​