智能体规划模块：隐藏的架构缝隙

大多数智能体系统在构建时都基于一个隐含的架构假设：LLM 在同一次推理调用中同时处理规划和执行。要求它完成一个包含十个步骤的任务，模型会决定做什么、去执行、检查结果、再决定下一步做什么——这一切都在一个连续的 ReAct 循环中完成。这看起来很优雅。但在实际工作负载下，它会以一种难以诊断的方式崩溃，因为其失败模式看起来更像是模型质量问题，而非设计问题。

智能体规划模块——即纯粹负责任务拆解、依赖建模和排序的组件——是大多数从业者都会跳过的接缝。只有当事情变得困难到无法忽视时，它才会显现出来。

为什么单体智能体在大规模应用时会失败

问题不在于 LLM 不擅长规划，而在于分步贪婪推理（step-wise greedy reasoning）在数学上与长程规划是不兼容的。单体智能体在每一步都选择局部最合理的下一个动作。这是一种贪婪策略，而贪婪策略已被证明在处理多步问题时并非最优——这种负面影响并非偶尔发生，而是以几何倍数叠加。

2026 年的一项研究将其正式化：在多跳问答基准测试中，贪婪推理智能体选择的短视动作在 55.6% 的情况下于第一个决策点就导致整个任务偏离轨道。浅层任务的准确率维持在 47% 左右；而在长程任务中，准确率接近于零。更宽的集束搜索（beam search）反而让情况变得更糟，将陷阱选择率推高至 71.9%。一旦智能体走错第一步，在贪婪策略下的恢复概率仅为 5% 左右。相比之下，即使是带有浅层预瞻（lookahead）的方法，恢复概率也会跃升至近 30%。

但还有第二个失败因素会加剧第一个：错误自调节（error self-conditioning）。当 LLM 在任务早期犯错时，它会随之将该错误视为事实。这个错误变成了上下文的一部分，影响随后的每一次推理调用。在重复执行任务的基准测试中发现，拥有数千亿参数的前沿模型在简单的顺序任务中，其准确率在 15 个轮次内就会降至 50% 以下。这种退化并非渐进的，而是随着错误历史的累积而加速。

而在这两者之下是上下文腐烂（context rot）。LLM 处理上下文窗口的方式并非均匀的。模型对第 10,000 个令牌的关注度与第 100 个令牌不同。随着单体智能体在数十个步骤中积累工具响应、观察历史和中间推理，可用于新决策的有效上下文会逐渐萎缩。针对这一现象的研究发现，即使是单一的干扰项也会显著降低准确率，且这种影响会随着上下文长度的增加而复合——甚至影响到最大的前沿模型。实际塑造模型行为的有效上下文可能只是标称窗口的一小部分。

将这三种失败——贪婪短视、错误自调节和上下文腐烂——结合在一起，你就会得到一个随着任务复杂度增加而可预见地退化的系统。在最近发布的最全面的长程规划基准测试之一中，表现最好的前沿模型得分仅为 0.343（总分 1.0）。所有受测模型的平均得分仅为 0.232。这些并非极端情况，而是当前行业的最前沿水平。

架构层面的修复：将规划与执行分离

尽管实现起来并不容易，但核心见解非常直接：规划和执行是认知上截然不同的操作，不应共享同一次推理调用。

规划器（Planner）接收高层任务并生成结构化的多步拆解。它负责推理目标、约束、步骤间的依赖关系以及执行顺序。它不执行任何操作。执行器（Executor）则从该计划中提取单个步骤，并将其转化为具体的工具调用。它不需要思考整个问题——它只需要完成一个规格明确的工作单元。

这反映了贯穿系统工程的关注点分离原则。执行器可以是一个更小、更便宜的模型，甚至是确定性的代码。它不承担整个任务的认知负担；它只需要步骤级的上下文和步骤级的工具访问。规划器是一个独立的、较慢的推理调用，它在前期或关键检查点运行，而不是在每一步都运行。

这种分离带来的实际影响是可衡量的。与 ReAct 风格的循环相比，预先规划所有工具调用并使用变量替换（即后续步骤通过名称引用早期输出，而不是重新阅读完整的观察历史）的架构，可减少约 65% 的令牌消耗，并带来显著的准确率提升。执行器永远不会看到臃肿的观察历史；它将 $E1 和 $E2 视为输入，并产出 $E3 作为输出。上下文腐烂从结构上得到了预防。

当规划器生成依赖图而非扁平的顺序列表时，会出现进一步的提升：独立的任务可以并发运行。执行三个独立查找的顺序智能体只能一个接一个地执行。而具备任务调度功能的图形感知执行器会并行运行它们，仅在输入可用后才将结果代入依赖步骤。在生产基准测试中，与顺序 ReAct 风格的执行相比，这种方法使延迟缩短了 3-4 倍，成本降低了 6 倍，准确率提升了约 9%。

基于图的规划：不仅仅是优化

从有序列表向依赖图的转变不仅仅是性能上的提升——它代表了一种不同的正确性模型。

扁平的编号计划暗示了一种实际上可能并不存在的顺序。彼此独立的步骤被意外地序列化了。那些输出结果确实依赖于前序步骤的任务，虽然在计划中可能顺序正确，但这种依赖关系并没有编码在系统可以检查或强制执行的任何地方。

有向无环图（DAG）使依赖关系显性化。每个任务节点都指定了其工具、参数以及它所依赖的任务 ID 列表。任务调度器——本质上是一个带有并行调度的拓扑排序——在任务的依赖项得到满足后立即运行该任务。没有依赖项的任务会立即并发运行。处理第 3 步的执行器接收到的是已经解析好的 $E1 和 $E2；它不需要思考这些值是什么或来自哪里。

在实践中，这看起来像是规划器输出的结构化内容：

任务 1: search("法国首都") → $E1 [依赖: 无]
任务 2: search("德国首都") → $E2 [依赖: 无]
任务 3: compare($E1, $E2, question="哪个更古老？") [依赖: 1, 2]

任务 1 和任务 2 并行运行。任务 3 在两者都完成后运行。规划器表达了结构；调度器强制执行了结构。

该模式在多跳推理（multi-hop reasoning）基准测试中的准确率提升是显著且一致的：支持并行调度的图感知规划在多跳问答任务中将准确率提高了 10-15 个百分点，同时减少了顺序步骤的数量和总响应长度。这些提升并非源于更聪明的模型，而是源于更聪明的执行结构。

分层规划（Hierarchical planning）进一步扩展了这一点。对于真正复杂的任务，全局规划器生成高层里程碑。特定领域的子规划器将每个里程碑分解为具体步骤。执行器处理单个工具调用，甚至从未看到过完整的问题。在针对长周期的法律和研究任务的评估中，消融实验发现，仅全局规划一项就贡献了 8 个百分点以上的提升，而完整的分层架构相比 ReAct 基线实现了 12-20% 的增长。

重新规划是一项功能，而非退路

对预先规划最常见的反对意见是计划会过时。智能体运行到第 4 步时发现了一些让第 7 步失效的信息。静态计划无法适应变化。

这种反对意见是现实存在的，但这应该成为将重新规划（replanning）构建进架构的理由，而不是将规划倒退回执行过程的理由。重新规划是一个在特定条件下触发的独立机制，并生成修正后的计划。它并非没有成本（这是另一次规划推理调用），因此问题在于何时触发它。

四种重新规划策略涵盖了大多数用例：

**错误触发的重新规划（Failure-triggered replanning）**仅在执行器步骤返回错误或产生违反前提条件的输出时触发。这是成本最低的选项，并且在任务定义明确时能妥善处理大多数任务偏差。

**观察触发的重新规划（Observation-triggered replanning）**在每个执行步骤后触发，将新的环境状态传回给规划器。虽然成本高昂，但在环境动态或部分可观测的任务中效果最好。在网页导航任务的生产评估中，观察触发的重新规划比相同任务下的静态规划提高了 10 个百分点以上的准确率。

**定期重新规划（Periodic replanning）**每隔 N 步触发一次，在成本和适应性之间取得平衡。对于环境逐渐变化的长任务，这是一个合理的默认选择。

**有限视野重新规划（Bounded-horizon replanning）**仅承诺执行计划中的下 K 步，并在每个 K 步边界处重新规划。它在全局最优性与局部正确性之间权衡，当任务结构在单步层面可预测但在长周期内不确定时效果良好。

核心洞察在于：计划是一个假设，而不是一个契约。在架构中显式地编码这一点——而不是假设规划器产生了一个完美的序列——可以产生更健壮的系统。

这对系统设计的意义

将规划模块分离出来，在你的系统中创造了一个值得深思熟虑去设计的接缝，而不是任其偶然产生。

规划器需要一种执行器可以解析的计划表示格式。编号列表适用于顺序任务。带有显式依赖数组的 JSON 任务图适用于并行任务。带有变量替换的结构化 DAG 可以处理这两种情况。格式并非偶然——它决定了哪些执行模式是可能的，以及执行器需要进行何种程度的推理。

执行器应该只接收当前步骤所需的信息。不是完整的工具集，而是与该步骤操作相关的工具。不是完整的对话历史，而是计划步骤、其已解析的输入变量以及任何特定于步骤的上下文。这既是性能属性（更短的上下文，更少的衰减），也是安全属性（针对幻觉或对抗性工具调用的爆炸半径更小）。

规划器和执行器不需要使用相同的模型。规划器受益于全局层面的强大推理能力；执行器受益于局部层面的速度和成本效率。在架构上使用大型尖端模型进行规划，使用较小的专门模型进行执行，既整洁又通常能显著降低成本。

监控需要在两个层面进行。规划失败（无效的依赖图、不可能的步骤顺序、歧义的变量引用）看起来与执行失败（工具错误、格式错误的参数、意外输出）截然不同。将它们视为同一类别会使调试变得异常困难。追踪（Traces）应当标记出规划事件与执行事件之间的边界。

添加规划模块的时机

并非每个智能体（agent）都需要一个显式的规划模块。对于只有两三个步骤、没有依赖关系且工具行为稳定的任务，ReAct 循环就足够了。此时，独立规划器的额外开销并不合理。

你需要规划模块的信号通常有以下三种：你的智能体在需要五六个以上连续步骤的任务中出现可预见的失败；随着上下文长度增加（而非单个步骤的任务难度增加），你发现准确率在下降；或者你正在运行包含独立子任务的任务，但除了默认的顺序结构外，没有其他理由让这些子任务被串行处理。

到那时，规划模块就不再是一项优化。它是区分一个“凑合能用”系统与一个“可扩展”系统的架构变革。

缝隙一直都在。有意识地暴露这个缝隙，明确设计规划器与执行器之间的接口，并通过它路由监控和重新规划逻辑，正是区分“优雅降级”的智能体与“神秘失败”的智能体的决策点。