你的编排器在规划步骤上消耗的延迟预算

我上季度合作的一个团队对一个客户支持智能体（Agent）进行了为期一周的埋点分析。从纸面上看，该智能体的中值延迟非常合理：P50 在 SLO 范围内，P95 虽然偏高但尚可解释，工具调用的追踪（traces）看起来也很健康。然而，当有人按类型对 span 进行分桶统计时，全场陷入了沉默。该智能体每次运行的墙钟时间（wall-clock time）中，约有 58% 耗在了标记为“规划（plan）”、“反思（reflect）”、“决定下一步（decide-next-step）”和“自我检查（self-check）”的 span 中。而真正的工具执行——数据库查询、CRM 写入、权限检查——占比不足 30%。这个智能体在核心业务逻辑上花费的精力，竟然比那些没人关注的中间步骤还要少。

这个比例并非偶然。它是任何你不主动监管的“规划-行动-观察（plan-act-observe）”循环的自然状态。编排器（Orchestrator）为了思考和行动支付延迟代价，而增加思考步骤几乎总是比增加行动步骤更容易，因此它会野蛮生长。当你意识到这一点时，“决定下一步做什么”已经变成了一个独立的预算大头——甚至比你最初构建智能体要服务的业务逻辑还要大。

更健康的视角是将规划器开销（planner overhead）视为一等 SLO 目标，而不是免费的协调成本。一旦你将其与工具延迟放在同一维度衡量，你就会做出不同的架构决策——涉及模型大小、重规划频率、规划缓存，以及你的“智能体”是否真的需要在每一步都表现得像个智能体。

为什么规划开销的膨胀速度超出预期

三种力量的叠加使得规划 span 成了智能体运行中沉默的大多数。

首先，每一次规划轮次都会重新进行整个对话的 prefill（预填充）。每一步都会增加之前的工具结果、之前的思考和之前的行动，因此上下文在循环中单调增长。Prefill 耗时大致与上下文长度呈线性关系，在典型的每 1k token 耗时 50ms 的 prefill 速率下，一个初始为 1k token 且每步增加 800 token 的 10 步 ReAct 循环，在产生第一个输出 token 之前，就会贡献约 180ms 的纯 prefill 开销。这部分成本在服务商的“首字延迟（TTFT）”指标中是不可见的，因为它发生在模型服务器内部。

第二种力量是层级化或多智能体编排会成倍增加每个用户请求的规划调用。一个三层架构，如果每一层都有两秒的 LLM 调用，那么在任何执行器开始工作之前，你至少已经消耗了六秒的协调时间。一个四智能体流水线通常会积累约 950ms 的纯协调开销，而实际工作时间仅为 500ms 左右。编排层完全是在履行其职责，只是没人注意到它是在串行执行。

第三种力量最隐蔽：通过增加更多步骤，规划部分最容易被做得“更好”。增加反思轮次、增加自我批评环节、增加“验证规划”步骤。孤立地看，每一次增加都像是质量提升，但每一项都在消耗用户实际体验到的延迟预算。更糟糕的是，这些步骤往往是由负责提示词（prompt）的团队增加的，而不是负责 SLO 的团队，因此在发布时没有人对其实际耗时影响进行建模。

综合影响是：规划器开销会自发增长，且增长方向看起来都符合工程直觉，没有任何天然的压力来制约它。

将规划器开销视为 SLO 专项类目

第一步是停止将智能体延迟测量为单一标量。端到端 P95 无法告诉你时间花在 哪里 了，而“哪里”是智能体系统唯一有用的信号。将追踪拆解为特定类型的 span——规划、工具调用、检索、反思、定稿——并针对每一个 span 报告其预算。

对于一个面向用户的智能体，一个合理的预算分配方案大致如下：工具调用延迟分配 40% 的总预算，因为那是用户可见的工作发生的地方。检索分配 15%。规划分配 25%。反思和自我检查共分配 10%。剩下的 10% 是序列化、网络和网关跳数的开销余量。当任何一个分桶超出其配额时，你就确切地知道该调查哪个提示词、模型或跳转。当总延迟违反 SLO 但没有任何单个分桶违规时，你遇到了聚合问题——步骤太多了，而不是某一步太慢了。

大多数团队在第一次审视这个视角时会发现，他们的规划器分桶消耗了 50-70% 的预算。那一刻，对话就会从“智能体太慢了”转变为“我们正在支付昂贵的模型延迟，去决定那些我们在编译阶段就能决定的事情”。

值得内化的推论：超过预算的规划 span 是一种缺陷，而不是一种“较慢的路径”。像对待缓慢的数据库查询一样对待它——发送告警、剖析性能、优化它，或者直接移除它。

规划 span 里的时间究竟花在了哪里

一旦你接受了 SLO 专项类目的框架，下一步就是决定削减什么。通常存在三类规划成本，它们有不同的修复手段。

最大的类别是 重新决策未改变的事项。智能体在每一轮都会重新推导出：用户想要订单状态、用户已通过身份验证、应使用的工具是 get_order。这些事实都没有改变。一个在每一步都重新推导这些事实的规划器，是在支付全额推理成本来恢复它三轮前就已经掌握的状态。规划缓存（Plan caching）可以直接解决这个问题——规划器根据请求形态生成可复用的计划，后续类似的请求可以完全跳过规划 span。最近关于智能体规划缓存的基准测试显示，智能体服务的平均延迟降低了约 27%，而缓存生成的成本仅占运行时间的 1% 左右。

第二类是 在错误的粒度上进行规划。步进式规划器在每次迭代中都会询问模型“我下一步该做什么？”。全局规划器（Full-horizon planners）则一次性询问“完整的步骤序列是什么？”，然后执行该计划，仅在失败时重新规划。对于任务形态良好的场景，全局规划变体在准确度上可以与步进式变体持平，同时大幅减少规划 token 的使用。正确的粒度取决于任务——探索性任务需要细粒度规划，而定义明确的任务显然不需要——但大多数生产环境中的智能体默认使用细粒度规划，因为框架示例就是这么写的。

第三类是 使用了错误的模型进行规划。对于小模型就能胜任的任务，使用大型规划模型就是“过度设计”。一种常见的重构是让大模型生成一次计划，然后将每步的执行和简单的“现在用哪个工具”决策委托给更小、更快的模型。这是“规划与执行（plan-and-execute）”架构的核心洞察：昂贵的推理发生在循环顶部，廉价的调度发生在循环内部。延迟的收益是结构性的，而不仅仅是数值上的——你停止了在每次迭代中调用那个缓慢的模型。

当 Agent 应当停止作为 Agent 的时候

更难的问题，也是经常被回避的问题：这个代码路径到底需不需要规划器（planner）？

你 Agent 中的某些工作流其实是伪装成确定性的。用户提出了一个已知形状的问题，系统检索了一个已知形状的文档，模型写出了一个已知形状的回复。如果你追踪一百次运行，发现规划器在 95% 的时间里都以相同的顺序选择了相同的三个工具，那么你拥有的其实是一个被编译好的工作流，却被当作自由形式的规划问题来执行。将其替换为静态图——相同的节点，相同的边，没有每一步的 LLM 决策——通常会完全删除该路径上的规划器跨度（planner span）。延迟的改进是巨大的，这并不是因为规划器变快了，而是因为规划器不复存在了。

这里可以借用编译器的思维模型。规划型 Agent 是在运行时解释你的业务逻辑；而编译后的工作流则在设计时就解决了逻辑。当输入分布确实是开放式的时候，解释是正确的选择。但当你为一个结果证明是规律性的工作负载支付解释成本时，它就是错误的选择。

许多团队最终达成的一个务实分工是：让规划器处理长尾和真正新颖的意图，而为头部分布发布编译好的图。大多数 Agent 的流量都集中在少数意图上，因此即使是部分编译也能捕获大部分延迟收益。你可以在同一种请求类型上对这两条路径进行 A/B 测试，观察规划器跨度的 SLO 变化。

当规划器开销变得可见时会发生什么

将规划器跨度视为“一等公民”会对团队的构建方式产生二阶效应。

Prompt 的更改将根据延迟预算进行审查，而不只是针对质量。增加一个反思（reflection）轮次过去是一个悄无声息的改进；一旦反思跨度有了具体的数字，团队就会根据 SLO 对其进行权衡，并经常发现质量的提升并不值得延迟的代价。增加“验证计划”步骤也会受到同样的对待。Prompt 团队和 SRE 团队开始互相沟通，因为 Prompt 团队现在负责一个 SRE 团队在凌晨 3 点会收到报警的指标。

模型选择变成了针对每个跨度的决策，而不是针对每个 Agent 的决策。规划器可以在快速的大型模型上运行；执行器（executor）可以在廉价的小型模型上运行；在热门路径上可以完全砍掉反思器（reflector）。你不再是为“Agent”选择模型，而是为跨度选择模型，这更接近于任何人设计非 AI 系统的方式。

重新规划（replanning）的频率变成了一个可调参数。默认情况下，许多 Agent 在每个工具结果后都会重新规划。如果结果是确定性的成功——数据库返回了一行，鉴权调用返回了 200——那就没有什么可重新规划的。如果在结果符合预期形状时添加一个抑制重新规划的守卫（guard），通常能在不影响质量的情况下将规划器跨度的数量减少一半。

最后，团队不再以“每个节点都使用大模型的自由形式 规划-行动-观察（plan-act-observe）”架构将新 Agent 发布到生产环境。这种默认设置之所以存在，是因为它是教程中的默认设置，而不是因为有人对其进行了基准测试。一旦你有了 SLO 视图，你就会有意识地做出选择，或者根本不去做这个选择。

总结

插桩（instrumentation）这一步是成本最低的。将你的 Agent 跨度分桶为规划（plan）、行动（act）、检索（retrieve）、反思（reflect）、完成（finalize）。为每个桶设定预算。当任何一个桶超出预算时进行报警。大多数团队在第一次进行这项练习时都会发现，Agent 中最慢的部分不是数据库，不是模型提供商，也不是网络——而是编排器在最大的模型上，带着全部上下文，一遍又一遍地决定下一步该做什么。

一旦规划器的开销变成了仪表盘上的数字，而不再是民间传闻，优化手段就会变得显而易见。缓存规划。粗化规划粒度。将每一步的决策降级到更小的模型。编译头部分布。抑制不必要的重新规划。这些都不是奇技淫巧。它们只是对于一个无法以毫秒为单位看清 Agent 在想什么的团队来说，是无法实现的。

问题不在于 Agent 进行规划。问题在于规划被当作协调开销——免费的、隐形的、不在仪表盘上的——而它却悄悄地变成了主要的工作负载。