“规划并执行”只是营销而非契约：将计划依从度作为一等 SLI

智能体（Agent）打印了一个五步计划。第三步是“从发票服务中获取用户的账单历史”。追踪链路（Trace）显示，第三步实际上调用了订单服务，关联了一个过时的客户表，并产生了一个看起来正确的数字。输出通过了评估（Eval）。六个月后，财务部门发现仪表盘与事实源（Source-of-truth）悄然出现了 4% 的偏差，复盘时才发现了这次回归（Regression）。

没有人写出 Bug。规划器（Planner）写下了一份执行器（Executor）从未签署的契约。

这就是“计划与执行”架构在其优雅的架构之下所掩盖的失败模式。这种模式被推销为一种赋予智能体长程连贯性的方式：由一个强大的模型起草计划，较弱的模型执行步骤，计划起到脚手架的作用。在实践中，计划只是一种“营销产物”——在 t=0 时发出的一个看起来合理的预告，随后在 t>0 时发生的每一件趣事都会迅速令其失效。追踪链路显示了计划，追踪链路也显示了行动。但几乎没有人去衡量两者之间的距离。

计划是预测，而非契约

默认的心理模型是错误的。大多数团队对待规划器的输出就像对待函数签名一样：一个具有约束力的意图声明，而执行器是具体的实现。但规划器并没有强制执行权。它只是输出文本。执行器（通常是一个独立的智能体循环，通常是不同的模型）可以自由地解释、跳过、重新排序、替换工具，甚至发明从未规划过的步骤。在 LangGraph 或 deepagents 的参考架构中，没有任何规定要求行动集必须是计划集的子集。重规划器（Replanner）之所以存在，正是因为偏差是预料之中的。

利益相关者在追踪链路中看到的是位于日志顶部的计划，看起来权威可靠。而实际执行的内容位于下方，通常分散在数十个工具调用中，其参数在文本上与计划的描述并不匹配。视觉层级在撒谎。计划读起来像契约，实则只是预测。

这之所以重要，是因为“计划与执行”智能体的可审计性故事是建立在“计划能告诉你发生了什么”这一假设之上的。在合规审查、事故后分析和评估分类中，工程师和评审员往往锚定在计划上，而仅对行动进行抽查。如果计划看起来合理，最终答案也看起来合理，中间过程就会被跳过。而回归（Regressions）往往就潜伏在这些中间过程中。

为什么步骤正确性会掩盖失败

标准的智能体评估标准衡量的是步骤级的正确性：每个工具调用是否返回了正确类型的结果，每个推理步骤是否保持了事实依据（Grounded），最终答案是否完成了任务。这些是必要的指标，但还不够。

一个“计划与执行”智能体即使在步骤正确性上达到 100%，仍可能背离其计划。考虑三种现实世界的失败形式：

• 替换漂移（Substitution drift）：计划说“使用 v2 搜索 API”。执行器使用了 v1，因为 v1 更便宜且结果看起来相似。每个步骤在技术上都是正确的，但计划已死。
• 步骤省略（Step elision）：计划说“在发送前验证客户的授权记录”。执行器认为验证已隐含在用户的请求中，从而跳过了这一步。在这种情况下输出是正确的，但在接下来的上千个案例中，合规性已然崩塌。
• 隐形重规划（Stealth re-planning）：计划说“如果 A 返回空结果，请询问用户”。执行器却静默地调用了一个后备工具并返回了一个猜测的答案。面向用户的输出看似合理。计划宣称会升级（Escalation），但追踪链路中没有任何体现。

步骤正确性问的是“每一个行动是否都说得通？”计划一致性（Plan Adherence）问的是“智能体是否在做它声称正在做的事情？”这是两个不同的问题，只有第二个问题能保护你免受“既定策略”与“实际行为”之间缓慢漂移的侵害。

deepeval 的 PlanAdherenceMetric 是这一理念的早期库实现之一——从追踪链路中提取任务和既定计划，然后让 LLM 裁判对实际执行步骤与计划的匹配程度进行评分。实现细节各有不同，但这种思维框架的转变比具体指标更重要。

计划与行动的分歧指标

将分歧视为一个可衡量的量，而不是二元判断。一个实用的指标需要四个要素：

1. 计划提取：规划器的输出必须足够结构化，以便进行比较。如果你的规划器输出自由格式的散文，你就是在对幻觉进行字符串匹配 QA。强制其进入类型化模式（Typed Schema）：具有明确工具意图、预期输入和明确成功条件的有序步骤。这是不可商量的基础设施。
2. 行动归因：每一个执行的工具调用必须带有一个回溯引用，指向它声称要满足的计划步骤。要么由执行器输出（最好，也最难），要么由事后裁判进行分配。没有归因，你就无法计算覆盖率。
3. 分歧评分：包含两个组件：未实现的计划步骤（已计划但从未尝试）和计划外行动（已执行但从未计划）。两者都根据计划长度进行归一化。分别追踪它们——它们的失败原因各不相同。
4. 偏差分类器：并非所有分歧都是缺陷。有些是针对环境变化的正当重规划。分类器将分歧分为：已授权（带有陈述理由的重规划事件）、可容忍（白名单内的微小参数替换）和未经授权（其他所有情况）。

像对待延迟或错误率一样，将分歧（Divergence）作为 SLI 发布。设定目标，并在超标时报警。人们往往倾向于将分歧视为每月在离线评估集中评分一次的质量信号。要抵制这种倾向。这一指标的漂移是你最早的信号，表明规划器和执行器已不再对“智能体是什么”达成共识，而离线评估往往比生产环境滞后数周。

一个有用的初始阈值：未经授权的分歧低于执行行动的 2%，计划覆盖率高于 90%。以此为基础进行调整。绝对数值的重要性次于捕捉到它们发生变动的那一天。

计划即契约的强制执行

缺乏强制执行的测量最终会变成没人看的仪表盘。架构必须让计划对执行具有约束力，而不只是提供建议。

明确的偏离授权。 当执行器需要偏离计划时，强制它通过一个会产生审计记录的单一关键点：它打算跳过或替换哪个步骤，为什么，以及新的动作将是什么。这与捕获异常而不是吞掉它们的原则相同。实现它的成本很低（执行器必须调用的一个命名良好的函数），但后期改造的代价很高。在第一天就构建它，否则你永远不会去构建它。

受限的重计划预算。 生产环境常见的一个故障是代理陷入螺旋式循环：一个动作失败了，触发重计划，新计划也失败了，再次触发重计划，四十个步骤之后，账单金额巨大，而用户一无所获。为每个任务设置重计划次数上限。3 次是一个合理的默认值；确切的数字取决于你的任务分布。当达到上限时，移交给拒绝路径，向用户返回明确的失败，而不是让代理永远试图表现得“很忙”。这是一个披着质量决策外衣的可用性决策。

计划不可变窗口。 一旦计划器输出了计划并且执行器已经开始执行，就将计划的某个受限前缀视为只读。在到达该边界之前进行重计划是可疑的 —— 这通常意味着计划器输出了一个它自己都不相信的计划，或者执行器在躲避它不想运行的步骤。无论哪种情况都值得调查。

重计划差异（Diff）可见性。 当发生重计划时，记录与上一个计划的差异，而不仅仅是孤立的新计划。差异才是真正的信号。一个删除了许可检查步骤并增加了回退路径的新计划，与一个仅仅调换了两次检索顺序的新计划是完全不同的。如果没有 Diff，追踪记录中的每一次重计划看起来都一样。

组织层面的危害

计划执行架构最深层的失败模式并非技术性的。而是计划对人类具有某种说服力，而追踪记录（Traces）则不然。

产品经理阅读计划并看到了意图。合规审查员阅读计划并看到了控制点。高管在演示中阅读计划并批准代理进入生产环境。他们每个人实际上都在验证计划器 —— 这是系统中最简单的部分。没有人是在验证执行器，而执行才是工作实际发生的地方，也是失败真正源起的地方。

组织层面的修复方法是将计划遵循度作为核心指标，放在与成功率相同的仪表盘上。不是单独的评估文档。不是没人打开的观测工具里的一个标签页。就在同一个仪表盘上。当成功率是 98% 而遵循度是 71% 时，团队需要感觉到这是一种值得解决的矛盾，而不是两个无关的事实。

智能体 AI 中的审计追踪悖论现在已经众所周知：日志不是证明。日志里的计划更不是证明。如果计划器和执行器之间没有强制的契约，你拥有的系统在理论上是可审计的，但在实践中是不可证伪的 —— 每一个动作都可以被事后合理化为“只要你宽泛地解读，它就与计划一致”。

宽泛的解读正是 Bug 的温床。

将遵循度视为 SLI

这种转变在代码上很小，但在立场上很大。停止将计划视为对代理所做工作的描述。开始将其视为执行器要么证实、要么反驳的一个假设，并为其差距附带指标、告警和预算。计划与行动的差异指标应该与延迟 p99 和错误率处于同一层级。受限的重计划预算应该与请求超时处于同一层级。偏离授权应该与审计日志处于同一层级。

如果你在 2026 年构建计划执行代理，却无法回答“上周我们计划的步骤实际执行了百分之几？”这个问题 —— 那么这个计划是在做品牌公关，而不是工程开发。修改契约，而不是修饰文案。