很多团队优化 agent 延迟时，先压模型 token，再砍上下文，结果用户体感几乎没变化。根因是优化没打在关键路径上。
真正要解决的问题是：你优化的是“看板上的平均值”，还是“用户真正等待的最长链路”。
关键路径不是理论概念，是预算基线
在 DAG 中，总耗时由最长依赖链决定：
$$T_ = \max\left(\sum_{n \in path_i} t_n\right)$$
这意味着并行分支优化 30%，如果不在最长链上，体感时延可能几乎不变。
先分层，再分配预算
建议先按执行阶段分层，再按阶段分配预算：
| 路径阶段 | 初始预算 | 常见瓶颈 |
|---|---|---|
| 计划编译 | 10% | 目标解析不稳定、重规划 |
| 数据准备 | 20% | 检索抖动、依赖等待 |
| 推理与工具执行 | 45% | 长上下文、外部接口慢 |
| 审批与合并 | 15% | 人工节点拥堵、冲突重算 |
| 提交与收尾 | 10% | 状态写入与通知串行化 |
注意这是初始模板，不是固定答案。真实预算必须由 trace 反推。
三个常见误区
- 只看平均值不看 P95：平均值变好，尾部依旧灾难。
- 按模块优化不按路径优化：各团队都在优化，但用户无感。
- 把审批等待当作“不可优化”：实际上可通过队列策略和分级审批优化。
实操方法：关键路径贡献度排序
对每个 run 计算节点贡献度：
$$Contribution(n)=\frac{t_n}{T_{critical_path}}$$
把优化 backlog 按贡献度与可实施性排序，优先处理高贡献且低改造成本节点。
失败案例：优化了 5 个节点，关键链没变
某系统把 5 个并行节点优化 40%，看板上的“节点平均耗时”很好看，但用户等待几乎不降。复盘后发现关键链是“证据抓取 -> 规则评估 -> 人工审批”。
他们把优化重心改为：
- 证据抓取增加缓存命中策略
- 规则评估拆分为快速预判与精确复核
- 人工审批启用分级 SLA
这次改动后，用户体感等待明显下降。
如何把预算嵌入发布门禁
建议在发布流程加入两条硬门禁：
- 关键路径 P95 不得劣化超过阈值
- 高风险路径必须通过预算回归样本
这能避免“局部优化上线，整体体验倒退”。
指标看板建议
| 指标 | 用法 |
|---|---|
| Critical Path P50/P95 | 判断体感时延 |
| Path Budget Violation Rate | 预算违规率 |
| Human Node Waiting Ratio | 人工节点拖慢占比 |
| Replan Rate on Critical Path | 关键链重规划频率 |
只有把这些指标放到同一屏，优化决策才不容易偏。
关键路径数据从哪里来
不要靠估算。关键路径必须从 runtime event 里计算出来。每个节点至少记录：
- scheduledAt
- startedAt
- completedAt
- dependencyReadyAt
- retryCount
- queueName
有了这些字段，才能区分三种完全不同的慢：
| 慢的类型 | 典型原因 | 优化方向 |
|---|---|---|
| 排队慢 | worker 不足、队列拥堵 | 调度与容量 |
| 执行慢 | 工具慢、模型慢、上下文大 | 节点内部优化 |
| 等依赖慢 | 上游慢、人工节点慢 | 路径重排或并行化 |
如果这三类混在一起看，团队很容易把排队问题误判成模型问题。
预算不是一次定死，而是按任务类型分层
同一个平台里，不同任务应该有不同预算。例如：
| 任务类型 | 用户期望 | 预算策略 |
|---|---|---|
| 即时问答 | 秒级反馈 | 轻图、少工具、快速失败 |
| 内容生成 | 分钟级可接受 | 重质量、允许异步 |
| 高风险审批 | 准确优先 | 预算更宽，但必须可解释 |
| 批量后台任务 | 低实时性 | 成本优先，错峰执行 |
不要用一个全局 SLA 管所有 workflow。那会同时伤害体验和成本。
优化手段的优先级
一条关键链超预算时，可以按这个顺序处理：
- 删除不必要节点：最便宜，也最容易被忽视。
- 并行化无依赖节点：收益明显，但要处理合并冲突。
- 缓存稳定中间结果：适合证据检索、规则配置、上下文切片。
- 降级慢工具：给外部依赖设置替代路径。
- 换模型或压 token：最后再做，避免牺牲质量。
很多团队一上来就换模型，是因为没有路径级数据。
一个预算复盘样例
某个 run 的关键路径如下：
| 节点 | 耗时 | 贡献度 |
|---|---|---|
| parse_request | 1.2s | 4% |
| collect_context | 11.8s | 40% |
| draft_solution | 8.4s | 28% |
| risk_review | 3.6s | 12% |
| human_approval_wait | 4.9s | 16% |
这时优化 parse_request 几乎没有意义。最应该先看 collect_context：是否重复检索、是否可以缓存、是否可以先返回部分结果。
执行 Checklist
- 每个 run 都能计算关键路径
- 预算按路径而非按模块分配
- 优化项标注是否命中关键链
- 看板默认展示关键路径贡献度
- 关键链变化后自动重算预算
- 发布门禁包含关键路径回归
延伸阅读：
