【Agent】规划-执行分离中的接口、上下文与模型分工调研

问题背景

围绕 Planner -> Executor 这种 Agent 架构，一个核心争议是:

1. 规划本质上是不是“生成后续 prompt”
2. 如果规划模型和执行模型不同，是否天然破坏了原始训练分布
3. 分离后上下文不共享，是否会导致执行器接不住规划器
4. 执行阶段遇到环境错误时，是否会因为缺少全局目标而无法恢复

这份调研的重点，不是泛泛讨论“plan-first 好不好”，而是专门看论文里有没有研究这些更细的问题。

结论先行

先给一个浓缩结论:

1. 文献整体上支持“规划-执行分离是有价值的”，但前提是 接口必须被显式设计，不能只靠松散自然语言。
2. 你担心的三个问题都是真问题，而且在论文里都有不同形式的体现:
   • 训练分布不对齐
   • 上下文 / 工作记忆断裂
   • 执行失败后无法回灌到高层计划
3. 目前主流论文给出的解决路径不是“回到完全一体化”，而是:
   • 把 plan 结构化
   • 把 planner 输出对齐到 executor 可执行表示
   • 让执行反馈能回流到 planner
   • 甚至用共享 backbone 或联合训练来减少 planner / executor 之间的语义断层
4. 所以更准确的判断不是“分离天然不好”，而是:
   • 未经对齐的分离通常不稳
   • 带结构化接口、反馈闭环和训练对齐的分离，往往比纯 ReAct 更可扩展

最相关的论文

1. ReAct: Synergizing Reasoning and Acting in Language Models

• 链接: https://arxiv.org/abs/2210.03629
• 作用: 作为“不分离”的强基线
• 论文要点:
  • ReAct 采用 Thought -> Action -> Observation 交替闭环，把思考、行动和环境反馈放在同一条上下文链里。
  • 它的优势正好对应你提到的第二、第三个担心: 规划和执行共享完整轨迹，执行器不会丢失目标，且每一步都能利用环境反馈即时修正。
  • 但它也暴露了代价: 上下文越来越长，容易漂移，且长任务成本高。
• 对当前问题的意义:
  • ReAct 可以看作对“为什么不要轻易分离”的最好论据。
  • 它说明统一上下文对于反应式纠错和局部适配很重要。

2. ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models

• 链接: https://arxiv.org/abs/2305.18323
• 作用: 直接研究“reasoning 和 tool feedback 要不要解耦”
• 论文要点:
  • ReWOO 把系统拆成 Planner -> Worker -> Solver。
  • Planner 一次性生成带变量引用的 blueprint，例如 Plan + #E1、Plan + #E2；Worker 去取证据；Solver 再综合答案。
  • 论文明确指出，ReAct 一类 observation-dependent reasoning 会导致重复 prompt、token 冗余和工具失败引发的循环。
  • 它们还观察到 ReAct 容易因坏工具反馈进入重复调用循环。
• 对当前问题的意义:
  • 这是对“分离有价值”的强支持。
  • 但 ReWOO 同时也承认另一面: 如果 Planner 对后续证据的假设错了，plan 也会失效。
  • 也就是说，分离能降低上下文耦合，但会引入前视规划假设错误。
• 和你的观点的对应:
  • 你说“规划过程其实是在生成后续提示词的一部分”，ReWOO 很接近这个视角。
  • 它实际上把 plan 变成了一个中间程序，后续模块围绕这个中间表示工作，而不再共享完整原始思维轨迹。

3. LLMCompiler: An LLM Compiler for Parallel Function Calling

• 链接: https://arxiv.org/abs/2312.04511
• 作用: 研究 planner / executor 的接口设计、依赖管理和 replanning
• 论文要点:
  • 系统拆成 Function Calling Planner -> Task Fetching Unit -> Executor。
  • Planner 不是输出松散自然语言，而是输出 带依赖关系的 DAG 任务图。
  • Executor 按依赖执行，支持并行；当当前计划不足时，再通过反馈环返回 Planner 触发 replanning。
  • 论文显式指出，ReAct 这类顺序串行方法存在重复调用、被中间结果干扰、过早停止等失败模式。
• 对当前问题的意义:
  • 它非常直接地回答了“表达接口要对齐”这个问题。
  • 论文的核心思想就是: plan 必须是一种 executor 能严格消费的表示，而不是一段泛泛而谈的自然语言说明。
  • 同时，它用 replanning 回路解决了“执行中遇到新情况怎么办”。
• 和你的观点的对应:
  • 你担心执行组件不知道全局目标。LLMCompiler 的答案是:
    • 不让 Executor 猜目标
    • 而是让 Planner 输出带变量和依赖的任务图
    • 再让执行反馈回 Planner
  • 这其实是在用“编译器式中间表示”替代自由文本接口。

4. Formal-LLM: Integrating Formal Language and Natural Language for Controllable LLM-based Agents

• 链接: https://arxiv.org/abs/2402.00798
• 作用: 研究“planner 产出的计划为什么经常不可执行”
• 论文要点:
  • Formal-LLM 认为 LLM agent 的一个核心问题是会生成 invalid / non-executable plans。
  • 解决方法不是继续增强 prompt，而是用 CFG / PDA 之类形式化约束来限制 plan 生成空间。
  • 论文报告，形式化约束能把 valid plan rate 提到 100%，并显著提高整体任务表现。
• 对当前问题的意义:
  • 这篇论文几乎直接证明了你的一个关键直觉:
    • 自然语言计划并不是一个可靠接口
  • 如果 planner 输出没有被 formalize，那么 executor 非常容易接收到“看起来合理、实际不可执行”的高层计划。
• 和你的观点的对应:
  • 你说“规划模型和执行模型的表达接口要对齐”，Formal-LLM 可以看成最强硬的版本:
    • 不只是对齐
    • 而是把接口限制到形式语言层面

5. Plan-and-Act

• 链接: https://arxiv.org/abs/2503.09572
• 作用: 直接研究 planner / executor 分离下的训练对齐问题
• 论文要点:
  • 论文开宗明义地说: LLMs 通常没有被训练来生成这种高层 plan / 低层 action 分离表示。
  • 它提出一个双模块系统: Planner 先出高层 plan，Executor 按环境执行；环境变化后 Planner 再动态 replanning。
  • 为了解决训练数据稀缺和接口不对齐，作者专门设计了 grounded plan generation:
    • 从成功动作轨迹反推出高层计划
    • 再做合成数据扩增
  • 论文反复强调 planner 的 step 必须写得足够明确，不能默认 executor “知道整条任务和完整轨迹”。
• 对当前问题的意义:
  • 这是最直接支持你第一个担心的论文。
  • 它实际上承认:
    • planner / executor 分离不是预训练自然长出来的能力
    • 需要额外数据构造和训练对齐
  • 而且它还明确处理了你第二、第三个担心:
    • step 里要包含 executor 完成任务所需的具体信息
    • 执行后的环境变化要反馈回 planner，触发重新规划
• 和你的观点的对应:
  • 你担心“执行器不知道对应上下文/目标”，这篇论文在 prompt 设计层面就把这个问题写死了:
    • planner 生成步骤时不能假设 executor 看过完整任务或轨迹
    • 必须在 step 内把必要目标信息显式写出来

6. Pre-Act

• 链接: https://arxiv.org/abs/2505.09970
• 作用: 研究在 ReAct 基础上引入 multi-step plan 和 plan refinement
• 论文要点:
  • Pre-Act 不像硬分离的 planner / executor 那么彻底，但它把 ReAct 从“只为当前动作思考”升级成“先生成多步计划，再逐步细化”。
  • 每一步执行后，会把新 observation 和累计上下文用于下一步 plan refinement。
  • 它还做了专门的数据改造和二阶段微调，让模型学习显式 plan + 每步 reasoning。
• 对当前问题的意义:
  • Pre-Act 是一个中间路线:
    • 不完全保留原始 ReAct 的一体化
    • 也不完全切成彼此独立的 planner / executor
  • 它说明很多问题不是“要不要分离”，而是“分离多少、何时重连上下文”。
• 和你的观点的对应:
  • 如果担心强分离破坏训练分布，Pre-Act 代表一种更稳的折中:
    • 仍保留共享上下文
    • 但把 plan 变成显式对象
    • 再通过 refinement 保持执行时的适应性

7. CoDA: A Context-Decoupled Hierarchical Agent with Reinforcement Learning

• 链接: https://arxiv.org/abs/2512.12716
• 作用: 更新近的证据，直接研究 context decoupling 与 joint optimization
• 论文要点:
  • CoDA 明确把问题定义为 Context Explosion。
  • 它不是简单使用两个完全独立模型，而是用 单一共享 backbone 扮演 Planner 和 Executor 两个上下文隔离的角色。
  • 关键点在于它用联合优化（PECO）来训练 planner / executor 协作。
• 对当前问题的意义:
  • 这篇论文非常接近你的第一条担心的正面回应。
  • 它隐含的判断是:
    • 完全独立模型容易语义断裂
    • 所以最好共享底层参数，再对角色做上下文隔离和联合训练

论文对你三个担心的具体回应

1. “不同模型会破坏原始训练数据结构”这个担心，对不对

结论: 对，而且已经有论文基本正面承认这一点。

最直接的证据来自 Plan-and-Act。

它明确指出，LLM 并不是天然被训练成“一个模型输出高层 plan，另一个模型拿 plan 去执行低层动作”这种模式的。也正因为如此，它专门做了两件事:

1. 从成功 action trajectory 反推 grounded high-level plan
2. 用这些数据训练 planner，让 planner 的输出更像 executor 真能消费的中间表示

这其实就是在补你说的“训练分布断裂”。

换句话说，论文界的主流态度不是“分离没问题，直接拆就行”，而是:

• 分离有系统价值
• 但 planner 语言必须被重新训练成一种可执行接口语言

更进一步，较新的 CoDA 给出另一条路线:

• 不把 planner 和 executor 做成完全不同的模型
• 而是共享一个 backbone，再做角色级别的上下文隔离和联合优化

这可以被理解为一种“既要分离职责，又尽量不破坏底层语义空间”的折中做法。

2. “分离后上下文不共享，执行器不知道规划时的真实意图”这个担心，对不对

结论: 非常对，而且这是 planner-executor 架构最核心的问题之一。

相关论文的解法，大体有三类。

解法 A: 把 plan 结构化，而不是只写自然语言

对应论文:

• ReWOO
• LLMCompiler
• Formal-LLM

这些论文共同说明一件事:

• 如果 plan 只是“去搜一下，然后总结一下，再比较一下”这种自然语言
• executor 很容易丢失变量绑定、依赖关系、输入输出约束

所以它们分别做了不同程度的结构化:

• ReWOO: 用 #E1/#E2 这样的证据变量
• LLMCompiler: 用 DAG 和占位符变量
• Formal-LLM: 直接用 CFG/PDA 约束 plan 的合法结构

这几篇论文背后的共同立场是:

planner 输出应该更像一种中间程序，而不是一段 loosely coupled 的解释性文本。

解法 B: 在 step 里显式补足 executor 需要的信息

对应论文:

• Plan-and-Act

这篇论文几乎是把这个问题写进了 prompt 规范里:

• planner 不能假设 executor 看过完整任务
• 每个 step 必须写得足够具体
• 既要高层，又不能抽象到无法落地

这和你的判断高度一致:

• plan 不是“写给人看的摘要”
• plan 是“写给下游执行器消费的任务表示”

解法 C: 干脆减少强分离，保留共享工作记忆

对应论文:

• ReAct
• Pre-Act

ReAct 代表完全共享上下文。

Pre-Act 代表较温和的分离:

• 先有多步 plan
• 但执行后 observation 继续进入累计上下文
• 下一步会基于当前上下文 refine plan

这条路线的含义是:

如果 planner / executor 之间的语义桥很脆弱，不如不要做太强的隔离。

3. “执行时遇到错误，分离架构因为缺少全局目标而无法恢复”这个担心，对不对

结论: 对，如果没有 replanning 闭环，planner-executor 很容易在真实环境里失灵。

这一点在几篇论文里都非常明显。

ReWOO 的启发

ReWOO 说明，预先规划虽然能减少 token 和避免 ReAct 式循环，但也会引入一个新问题:

• 规划器对未来观测做了假设
• 一旦实际证据和假设不符，后续 plan 就可能失效

也就是说，提前计划并不自动等于更鲁棒。

LLMCompiler 的启发

LLMCompiler 非常明确地加入了 replanning 机制。

它的逻辑是:

• 先出一批任务
• Executor 执行
• 如果现有 plan 无法继续，或者需要新的信息，反馈给 Planner 重新生成任务

这其实是 planner-executor 架构想在真实环境里工作所必需的东西。

Plan-and-Act 的启发

Plan-and-Act 也不是“一次规划、一路执行到底”。

它在系统图中就明确写了:

• 环境反馈既可以给 Executor
• 也可以给 Planner，在必要时生成新 plan

这说明现在比较成熟的分离式架构，几乎都默认:

planner 不是一次性组件，而是一个可被执行反馈重新唤起的上层控制器。

一个更系统的归纳

如果把这些论文放在一起，可以把 planner-executor 的核心难题总结成三个“对齐”问题。

1. 表达对齐

问题:

• planner 说的话，executor 能不能唯一、稳定、低歧义地理解

代表论文:

• ReWOO
• LLMCompiler
• Formal-LLM
• Plan-and-Act

解决思路:

• 变量化
• DAG 化
• 形式语言化
• grounded plan supervision

2. 记忆对齐

问题:

• planner 和 executor 是否共享同一份工作记忆与目标状态

代表论文:

• ReAct
• Pre-Act
• CoDA

解决思路:

• 保留共享轨迹
• 只隔离局部工作空间，不隔离底层模型
• 通过 refinement / joint optimization 维持一致性

3. 反馈对齐

问题:

• 执行时的异常、失败、偏离，能不能回流到上层计划

代表论文:

• LLMCompiler
• Plan-and-Act
• Pre-Act

解决思路:

• 显式 replanning
• 执行反馈回 planner
• 把 planner 设计成持续在线，而非一次性生成器

对你原始观点的判断

你的观点整体上是很有根据的，而且和最近几类论文的方向相当一致。

观点 1: “规划本质上也是优化提示词”

部分成立，但可以再精确一点。

更准确地说:

• 在很多系统里，plan 不只是提示词
• 它是 中间表示

如果只是 prompt augmentation，那么 plan 只是让下一个模型“更好想”。
但在 ReWOO / LLMCompiler / Formal-LLM / Plan-and-Act 里，plan 已经更像:

• 程序草图
• DAG
• 变量依赖图
• 受约束的执行规范

所以我会把它定义为:

规划是把自然语言目标编译成可执行中间表示的过程。

观点 2: “不同模型会破坏原始训练数据结构”

基本成立。

但论文给出的更精确说法是:

• 不是“不能分离”
• 而是“分离后必须额外做接口监督或联合优化”

Plan-and-Act 和 CoDA 都在某种程度上承认这一点。

观点 3: “上下文不共享会导致执行器不知道真实目标”

高度成立。

这正是为什么:

• ReAct 一体化架构仍然很强
• 结构化接口研究会这么重要
• 很多新方法都要加 refinement / replanning / shared backbone

观点 4: “执行出错时，如果没有全局语境就很难恢复”

高度成立。

没有反馈闭环的 plan-first 方法，在动态环境里通常都不够稳。
比较成熟的论文基本都不是静态一次规划，而是带 replanning 或 refinement。

一个工程上更可信的判断

基于这些论文，我认为现实里最稳的路线不是二选一，而是三种范式的渐进升级:

路线 A: ReAct / Pre-Act

适合:

• 环境变化快
• 任务长度中等
• 需要大量依赖局部 observation 调整策略

优点:

• 上下文连续
• 容易纠错

缺点:

• token 成本高
• 容易 context explosion

路线 B: Planner + Executor + Replanning

适合:

• 长任务
• 可分解任务
• 需要降低成本和提高可观测性

前提:

• planner 输出必须结构化
• executor 接口必须明确
• 执行反馈必须能回 planner

路线 C: Shared Backbone + Role Separation

适合:

• 既想分离上下文，又担心 planner / executor 语义断裂

代表思路:

• CoDA 这类共享 backbone、角色隔离、联合优化的方法

这条路线很可能是未来更合理的折中:

• 职责分离
• 但语义不彻底分家

对实际系统设计的启发

如果以后真的要做 planner-executor 架构，我会优先遵循下面几条原则。

1. 不要把 planner 输出当作文案，要当作 IR
2. step 里必须写 executor 真正需要的信息，不能假设它看过完整上下文
3. 给 plan 加变量引用、依赖关系、输入输出约束
4. executor 的异常必须能触发 replanning，而不是只在局部兜底
5. 如果 planner 和 executor 用不同模型，最好:
   • 用同一套格式化 plan schema
   • 做针对性训练或蒸馏
   • 或者至少在小规模任务上先验证接口稳定性
6. 如果任务环境动态性很强，不要做“只规划一次”的静态架构

我自己的综合判断

“先规划，后执行”并不自动意味着“规划模型和执行模型分开就是更优”。

从论文证据看，更接近事实的说法是:

• 分离职责是对的
• 强分离模型未必天然对
• 真正关键的是中间表示、共享状态设计、以及反馈闭环

换句话说，Planner / Executor 架构的成败，往往不取决于“是不是两个模型”，而取决于:

• 计划是不是可执行表示
• 执行器是不是拿到了足够目标信息
• 错误是不是能回流到上层
• 两边是不是经过了数据或训练层面对齐

参考论文与链接

1. ReAct: Synergizing Reasoning and Acting in Language Models
   https://arxiv.org/abs/2210.03629
2. ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models
   https://arxiv.org/abs/2305.18323
3. LLMCompiler: An LLM Compiler for Parallel Function Calling
   https://arxiv.org/abs/2312.04511
4. Formal-LLM: Integrating Formal Language and Natural Language for Controllable LLM-based Agents
   https://arxiv.org/abs/2402.00798
5. Plan-and-Act
   https://arxiv.org/abs/2503.09572
6. Pre-Act
   https://arxiv.org/abs/2505.09970
7. CoDA: A Context-Decoupled Hierarchical Agent with Reinforcement Learning
   https://arxiv.org/abs/2512.12716