AI 工程从零开始

主题

ReWOO 与 计划-执行（Plan-and-Execute）：解耦式规划 ​

ReAct 在同一条流中交错进行思考与行动。ReWOO 将二者拆开：先做一个完整的大计划，再执行。令牌数少 5 倍，HotpotQA 上准确率提高 4%，而且你还可以把规划器蒸馏到一个 7B 模型里。计划-执行（Plan-and-Execute）对它做了泛化；计划-行动（Plan-and-Act）则把它扩展到了网页导航。

类型： 构建 语言： Python（标准库） 先修要求： 第 14 阶段 · 01（智能体循环） 时间： 约 60 分钟

学习目标 ​

  • 解释为什么 ReWOO 的规划器（Planner）/执行器（Worker）/求解器（Solver）拆分，相比 ReAct 的交错循环，能节省令牌并提升鲁棒性。
  • 仅用标准库实现一个计划 DAG（有向无环图）、一个按依赖顺序执行的执行器，以及一个组合执行器输出的求解器。
  • 使用 2026 年“五种工作流模式”的框架（Anthropic）来判断任务应采用“先规划后执行”，还是交错式 ReAct。
  • 识别何时需要计划-行动（Plan-and-Act）的合成计划数据，以处理长时程（long-horizon）的网页或移动端任务。

问题 ​

ReAct 的“思考-行动-观察”交错循环简单而灵活，但每次工具调用都必须携带此前的全部上下文——包括之前的每一步思考。令牌用量会随深度呈平方级增长。更糟的是：当工具在循环中途失败时，模型必须根据错误观察重新推导整个计划。

ReWOO（Xu 等，arXiv:2305.18323，2023 年 5 月）注意到了这一点，并押注于另一种方式：先把整件事规划完，再并行获取证据，最后组合出答案。一次 LLM 调用用于规划，N 次工具调用用于取证（可并行），再一次 LLM 调用用于求解。它的权衡是：牺牲一些灵活性（计划是静态的），换来更高的令牌效率和更清晰的失败模式。

概念 ​

三种角色 ​

Planner:  user_question -> [plan_dag]
Workers:  [plan_dag]     -> [evidence]        (tool calls, possibly parallel)
Solver:   user_question, plan_dag, evidence -> final_answer

规划器产出一个 DAG。每个节点会注明工具、其参数，以及它依赖哪些更早的节点（如 #E1、#E2 这样的引用）。执行器按拓扑顺序执行节点。求解器将所有内容拼接起来。

为什么令牌少 5 倍 ​

ReAct 的提示长度会随步骤数线性增长。到了第 10 步，提示里包含思考 1、行动 1、观察 1、思考 2、行动 2、观察 2，以此类推。每一个中间步骤还会重复包含原始提示。

ReWOO 只需支付一次规划器提示（较大）、N 次较小的执行器提示（每次只是工具调用，没有整条链），以及一次求解器提示。论文在 HotpotQA 上测得令牌数约少 5 倍，同时绝对准确率提升 4 个百分点。

为什么它更稳健 ​

如果 ReAct 中的第 3 个执行器节点失败了，循环必须在中途从错误中继续推理。而在 ReWOO 中，第 3 个执行器节点只会返回一条错误字符串；求解器会在原始计划的上下文里看到它，并可以优雅降级。失败定位是按节点进行的，而不是按步骤进行的。

规划器蒸馏 ​

论文的第二个结果是：因为规划器看不到观察结果，所以你可以用一个 175B 教师模型产出的规划结果来微调一个 7B 模型。这个小模型负责规划；推理时不再需要大模型。如今这已是标准做法——许多 2026 年的生产级智能体都会使用“小规划器 + 大执行器”或反过来的组合。

计划-执行（Plan-and-Execute）（LangChain，2023） ​

LangChain 团队在 2023 年 8 月的文章中把 ReWOO 泛化成了一种模式名：计划-执行（Plan-and-Execute）。前置规划器输出一个步骤列表，执行器依次运行每一步，还可以有一个可选的重规划器在观察到结果后修订计划。它比 ReWOO 更接近 ReAct（因为重规划器让观察结果重新进入规划过程），但仍保留了令牌节省。

计划-行动（Plan-and-Act）（Erdogan 等，arXiv:2503.09572，ICML 2025） ​

计划-行动（Plan-and-Act）将这种模式扩展到长时程的网页与移动智能体。它的关键贡献是合成计划数据：一个带标签的轨迹生成器会产生显式包含计划的训练数据。这些数据可用于微调规划器模型，使其在 WebArena 一类任务中，即使超过 30–50 步仍能保持有效，而单条 ReAct 轨迹往往会失去连贯性。

何时选择哪一种 ​

模式适用场景
ReAct短任务、环境未知、需要响应式异常处理
ReWOO工具已知的结构化任务、对令牌敏感、证据可并行获取
计划-执行（Plan-and-Execute）类似 ReWOO，但允许在部分执行后重规划
计划-行动（Plan-and-Act）长时程（>30 步）、网页/移动端/计算机使用任务
思维树（Tree of Thoughts）值得为搜索付费的场景（第 04 课）

Anthropic 在 2024 年 12 月的建议是：从最简单的方式开始。如果任务只是一次工具调用再加总结，就不要构建 ReWOO。如果任务是一项 40 步的研究任务，就不要只用 ReAct。

动手构建 ​

code/main.py 实现了一个玩具版 ReWOO：

  • Planner —— 一个脚本化策略，根据提示生成计划 DAG。
  • Worker —— 通过注册表分发每个节点的工具调用。
  • Solver —— 一个脚本化组合器，读取证据并生成最终答案。
  • 依赖解析 —— 像 #E1 这样的引用会在执行分发时被替换为较早的执行器输出。

演示会回答这个问题：“法国首都的人口是多少，四舍五入到百万位？”它使用一个两步计划：（1）查找首都；（2）查找人口；然后求解。

运行：

python3 code/main.py

输出轨迹会先显示完整计划，再显示执行器结果，最后显示求解器的组合结果。把令牌数（我们会打印一个粗略的字符数）和 ReAct 风格的交错式运行做比较——对于这种结构化任务，ReWOO 更占优。

使用它 ​

LangGraph 将计划-执行（Plan-and-Execute）作为一种配方提供（ReAct 用 create_react_agent，plan-execute 用自定义图）。CrewAI 的 Flows 则直接编码了这种模式：你预先定义任务，然后由 Flow DAG 执行它们。计划-行动（Plan-and-Act）的合成数据方法目前仍主要停留在研究阶段；但其运行时模式（显式计划 DAG）已经通过 LangGraph 和 CrewAI Flows 进入生产环境。

交付上线 ​

outputs/skill-rewoo-planner.md 会根据用户请求和工具目录生成一个 ReWOO 计划 DAG。在把计划交给执行器之前，它会先校验计划（无环、每个引用都能解析、每个工具都存在）。

练习 ​

  1. 为彼此独立的计划节点实现并行执行器执行。在一个有 6 个节点、包含 2 个并行组的 DAG 上，这能带来什么收益？
  2. 添加一个重规划器节点：当任意执行器返回错误时触发。让 ReWOO 变成计划-执行（Plan-and-Execute）的最小改动是什么？
  3. 用一个小模型（7B 级别）替换 Planner，同时保留 Solver 使用前沿模型。比较端到端质量——这种拆分会在什么地方失效？
  4. 阅读 ReWOO 论文第 4 节关于规划器蒸馏的内容。从概念上复现 175B -> 7B 的结果：你需要什么训练数据？又该如何给计划质量打分？
  5. 把这个玩具实现迁移到计划-行动（Plan-and-Act）的轨迹形态：计划是一个序列，而不是 DAG。有哪些权衡会发生变化？

关键术语 ​

术语人们常说实际含义
ReWOO“没有观察的推理”先规划，再并行获取证据，最后求解——规划提示中不包含观察结果
计划-执行（Plan-and-Execute）“LangChain 的计划-执行模式”ReWOO 外加一个执行后可选的重规划器节点
计划-行动（Plan-and-Act）“扩展版的计划-执行”显式规划器/执行器拆分，并为长时程任务配备合成计划训练数据
证据引用“#E1、#E2、...”在分发时用先前执行器输出替换的计划节点占位符
规划器蒸馏“小规划器，大执行器”用大教师模型的规划轨迹微调一个小模型
令牌效率“更少的往返”论文中相比 ReAct，在 HotpotQA 上令牌数少 5 倍
DAG 执行器“拓扑分发器”按依赖顺序运行计划节点；每一层都可并行

延伸阅读 ​