告别无脑循环：深入解析 ReWOO 与 Plan-and-Execute Agent 架构

在构建 LLM Agent 时，大多数人最先接触的是 ReAct (Reasoning and Acting) 模式。ReAct 的核心是一个紧密的“思考 -> 行动 -> 观察”循环。 听起来很完美，但当你把 Agent 投入生产环境处理复杂任务时，ReAct 的痛点便暴露无遗：

1. Token 焦虑症：每执行一步工具，都要把前因后果连同巨大的上下文重新喂给大模型，Token 消耗如流水。
2. “失忆”与“死循环”：在长链条任务中，LLM 容易忘记最初目标，或者在某个报错步骤上反复横跳。
3. 串行低效：如果步骤 A 和步骤 B 没有依赖关系，ReAct 依然傻傻地排队执行。 为了解决这些问题，业界开始探索**“规划与执行解耦”**的架构。其中，ReWOO 和 Plan-and-Execute 是目前最主流的两种进阶范式。它们虽然都打着“先想后做”的旗号，但底层哲学却大相径庭。

---

一、 ReWOO：极致效率的“开环蓝图”

ReWOO 全称是 Reasoning WithOut Observation（无观察推理）。这个名字一语道破了它的核心机制：在规划和推理阶段，绝对不看工具执行的结果。

1. 架构拆解

ReWOO 将 Agent 严格切分为三个独立角色：

• Planner（规划器）：只看用户 Prompt，一次性生成完整的执行计划。计划中的每一步以 #E{序号} 作为变量占位符，代表未来工具的返回值。
• Worker（执行器）：一个无情的 API 调用机器。它不理解业务，只负责解析 Planner 的指令，调用对应工具，并将结果存入对应的 #E 变量中。关键点：Worker 可以并发执行无依赖的任务。
• Solver（求解器）：最后出场，它接收最初的用户问题、完整的计划列表，以及 Worker 填充好的所有 #E 变量值，进行最终整合并输出答案。

2. 代码级工作流示例

用户：对比苹果和微软最新财报的营收数据。 Step 1: Planner (一次 LLM 调用)

1. #E1 = Search(apple latest quarterly revenue)
2. #E2 = Search(microsoft latest quarterly revenue)
3. #E3 = Compare(#E1, #E2) (注：这里只是伪代码，实际可能由Solver完成) Step 2: Worker (0次 LLM 调用，纯代码逻辑) 并行发起请求 -> #E1 = "Apple Q4 revenue: 90B" | `#E2` = "Microsoft Q4 revenue: 62B" Step 3: Solver (一次 LLM 调用) 接收到：Prompt + Plan + #E1 + #E2。 输出：“根据最新财报，苹果营收 90B 美元，超越微软的 62B 美元...”

3. ReWOO 的优缺点

• ✅ 极致省钱提速：整个流程只需 2 次 LLM 调用（Planner + Solver），极大压缩了 Token 消耗和响应延迟。
• ✅ 天然支持并发：Worker 层通过简单的依赖图分析（例如 #E3 依赖 #E1 和 #E2，但 #E1 和 #E2 互相独立），可以轻松实现并行工具调用。
• ❌ 开环系统的致命伤：因为 Planner 在做计划时“眼瞎”（看不到执行结果），如果计划本身有误，或者某一步工具报错了，整个流程就会烂尾，没有纠错能力。

---

二、 Plan-and-Execute：灵活应变的“闭环迭代”

如果说 ReWOO 是画好图纸不让改的盲建，那么 Plan-and-Execute 就是边施工边看图纸的敏捷开发。

1. 架构拆解

这种架构通常包含（在 LangGraph 中被广泛实现）：

• Planner（规划器）：生成初步计划（通常是一个 Task 列表，而不是 ReWOO 那种带占位符的代码）。
• Executor（执行器）：从计划队列中取出一个任务，执行对应的工具调用。
• Replanner（重规划器）：这是灵魂组件。 每次执行完一个任务后，Replanner 会介入，结合【原始目标】+【历史执行结果】+【剩余计划】，决定是继续原计划，还是修改计划，或者是直接结束。

2. 代码级工作流示例

用户：帮我写一份关于 SpaceX 星舰最新发射的深度报告，需要包含技术参数和外界评价。 Loop 1:

• Planner:
  1. 搜索 SpaceX 星舰最新一次发射的时间及结果。
  2. 搜索该次发射的具体技术参数（高度、推力等）。
  3. 搜索主流媒体对该次发射的评价。
  4. 汇总撰写报告。
• Executor: 执行任务 1。返回结果："星舰 IFT-4 于 2024 年 6 月成功发射，实现助推器软着陆。" Loop 2 (动态反馈的体现):
• Replanner: 分析任务 1 的结果 -> 发现 IFT-4 是最近的一次。但为了写深度报告，可能需要对比历史数据。
• Replanner 更新后的计划:
  1. 搜索发射时间 (已完成)
  2. 搜索 IFT-4 与 IFT-3 的技术参数对比。
  3. 搜索马斯克及 NASA 对 IFT-4 的评价。
  4. 撰写报告，强调“超重型助推器捕获”这一技术突破。
• Executor: 执行更新后的任务 2...

3. Plan-and-Execute 的优缺点

• ✅ 强大的容错与纠错能力：遇到 API 限流、工具失效或意料之外的信息，Replanner 能立刻调整策略，不会一条道走到黑。
• ✅ 信息渐进式获取：前面步骤的发现可以指导后面步骤的优化，非常适合探索性任务（如深度调研、复杂代码 Debug）。
• ❌ 成本高昂：每执行 1~N 个步骤，就需要调用一次 LLM 进行 Replan，Token 消耗呈指数级上升。
• ❌ 串行瓶颈：为了获得反馈以进行重规划，任务往往只能串行执行，牺牲了速度。

---

三、 场景对决：什么时候用谁？

为了更直观，我们把这两个架构放到真实的业务场景中去 PK。

场景 A：每日数据流水线自动化

需求：每天早上 8 点，抓取 A 网站的销售额、B 网站的库存量、C 网站的汇率，计算汇总后发送到飞书群。

• ReWOO 表现 (S 级)：步骤完全固定，毫无悬念。Planner 生成并行抓取计划，Worker 并发请求三个网站，Solver 计算并发送飞书。极快，极稳，每天节省大量 Token。
• P&E 表现 (C 级)：杀鸡用牛刀。每抓完一个网站，Replanner 还要思考一下“接下来干嘛”，白白浪费钱和延迟。

场景 B：自动化渗透测试 / 漏洞扫描

需求：扫描目标 IP 的端口，发现 80 端口开放后尝试识别 Web 框架，如果发现是 Struts2，则尝试执行特定漏洞 POC，如果失败则切换扫描策略。

• ReWOO 表现 (不及格)：Planner 在一开始根本不知道目标开了什么端口，无法制定准确的后续 POC 计划。一旦第一步发现不是 Web 服务，整个计划直接作废。
• P&E 表现 (S 级)：完全契合。先扫端口，Replanner 根据端口结果动态生成“识别服务”的计划；再根据服务类型，动态生成“打 POC”的计划。完美应对未知环境。

---

四、 工程师的终极选择：混合架构

在真实的商业级 Agent 框架（如 LangGraph）中，成熟的工程师很少非黑即白地二选一，而是采用**“宏观 Plan-and-Execute，微观 ReWOO”**的混合策略。 举个例子：组织一场大型技术峰会。

1. 外层使用 Plan-and-Execute：作为大总管，先制定宏观计划（定场地、定嘉宾、宣发）。如果发现“某嘉宾无法到场”，外层 Replanner 迅速启动预案，修改宏观计划（寻找替代嘉宾）。
2. 内层使用 ReWOO：当执行到“宣发”这个子任务时，将其交给 ReWOO 微观引擎。Planner 一次性规划出“并发发布到知乎、微博、公众号”，Worker 并行调用三个平台的 API，Solver 汇总发布链接。快速且低成本。

结语

从 ReAct 的“走一步看一步”，到 ReWOO 的“谋定而后动（但不看路况）”，再到 Plan-and-Execute 的“摸着石头过河”，Agent 架构的演进本质上是在“Token 成本”、“执行延迟”与“任务成功率”这三个相互制约的维度上寻找平衡点。 理解了这两种架构的底层差异，你就能在构建下一个杀手级 AI 应用时，不再盲目堆砌 Prompt，而是像架构师一样，精准地为你的 Agent 装上最合适的“大脑”。