延迟优化

一句话理解：Agent 慢，通常不是模型“想得慢”，而是步数多、串行等待、上下文太长、输出太长；先用 Trace 找到时间花在哪，再决定并行、缓存、流式、换小模型还是删掉步骤。

用户对 Agent 的耐心，和对网页的耐心完全不同。一个 SEO 诊断报告跑 3 分钟，用户可以接受，因为人工做要半天；一个客服场景里“帮我查下退款到哪一步了”要等 40 秒，用户会直接关掉窗口。

优化延迟最常见的错误是凭感觉动手：“模型太慢，换个快的”。结果换了模型，质量下降，速度却没快多少，因为真正的瓶颈是一个 8 秒才返回的退款查询接口。这一课先教你拆解延迟，再给出一套按收益排序的优化手段。

延迟由什么组成

一次 Agent 运行的端到端耗时可以拆成：

端到端耗时 = Σ 模型调用耗时 + Σ 工具调用耗时 + 审批与人工等待 + Harness 开销
模型调用耗时 ≈ 处理输入的时间 + 输出 Token 数 × 每 Token 生成时间

两个直觉：

• 输出 Token 通常比输入 Token 更“贵时间”。 模型是一个 Token 一个 Token 地生成的，让模型少写 300 字的“思路复述”，往往比缩短同样长度的输入更能省时间。
• 串行的步骤会累加。 8 步、每步 2 秒的模型调用，再加上工具，很容易超过 30 秒。

用 Trace 画出瀑布图，一眼就能看出时间花在哪。以上一课的客服订单诊断为例（图 1）：

这张图里，模型调用合计约 11 秒，工具约 14 秒。直接换更快的模型，最多省下几秒；而处理掉两个慢工具和串行等待，收益更大。

七个优化手段

OpenAI 的延迟优化指南总结了七条原则，这里结合 Agent 场景逐条展开：

原则	Agent 场景做法	客服例子	代价
处理 Token 更快	选用更快的模型或推理配置	分类、参数提取这类简单步骤用小模型	可能降低复杂判断的质量
生成更少 Token	限制输出长度，要求结构化简短输出，控制推理预算	结论从 600 Token 缩到 250 Token，详情按需展开	可解释性需要另外设计
使用更少输入	精简工具返回、清理旧结果、使用提示缓存	退款流水只返回最近 5 条而不是全部 200 条	可能丢失信息
减少请求次数	合并工具，一步拿到多个数据	提供 get_order_overview 一次返回订单、支付与退款状态	工具粒度变粗
并行	无依赖的工具调用同时发出	get_refunds 与 get_payment 同时调用	需要框架支持并行工具调用
让用户少等	流式输出、先给部分结果、展示进度	先显示“已确认订单与支付正常，正在核对退款流水”	需要前端配合
不默认用 LLM	确定性步骤交给程序、预计算或规则	订单号格式校验、时效计算直接用代码	需要工程投入

把前五条用在上面的例子里（图 2）：

从约 25 秒降到约 8 秒，而主力模型没有换。

关于提示缓存： 缓存不仅降低成本，对长前缀的请求也通常能减少处理时间，因为缓存命中的部分不需要重新计算。所以“把稳定内容放前面、动态内容放后面”的上下文结构，同时服务于成本和延迟，详见 提示缓存。

关于路由： 小模型路由省时间，但要用评测集确认它在对应步骤上的质量没有明显下降，详见 模型选型与路由。

感知延迟同样重要

同样是 20 秒，用户盯着转圈的菊花，和看着“已检查订单 ✓ → 已检查支付 ✓ → 正在核对退款流水…”，体验完全不同。几个常用手段：

• 流式输出：最终回答边生成边显示，关注首个输出时间。OpenTelemetry GenAI 约定中也专门定义了流式响应的首块时间（time to first chunk）相关属性与指标。
• 进度可见：把工具调用翻译成用户能理解的步骤，详见 计划与进度。
• 先给部分结果：先返回已确认的事实，再补充需要长时间分析的部分。
• 转为异步：超过用户愿意等待的时长，就让任务在后台运行并通知，详见 异步任务体验。

为不同任务定延迟预算

不要给所有任务一个统一的“要快”，而是按场景定预算：

场景	用户预期	建议形态	延迟预算示例
客服查订单	即时	同步 + 流式	首个输出 2 秒内，完成 10 秒内
订单售后诊断	愿意等一会儿	同步 + 进度	完成 30 秒内
销售周报分析	可离开	异步 + 通知	完成 5 分钟内
全站 SEO 诊断	批量任务	后台 + 批处理	完成 1 小时内

图 3 把四档预算放在一条轴上：

表中数字是示例，需要结合你的用户研究来定。定下预算后，把端到端耗时的 P50 / P95 放进看板，按场景分别监控。

常见误区

• “慢就换更快的模型。” 先看瀑布图。如果瓶颈在工具或步数，换模型解决不了问题，还可能损失质量。
• “把推理预算调到最低最快。” 对需要判断的关键步骤，省掉思考可能导致走错路，多出来的纠错步骤反而更慢。按步骤区分，而不是全局一刀切。
• “并行越多越好。” 有依赖关系的步骤强行并行会拿到错误的输入；过度并行还会触发下游接口限流。
• “只优化平均耗时。” 用户记住的是最慢的那几次。P95 与超时比例同样要管。

产品经理检查清单

• 每类任务是否定义了延迟预算，并明确是同步、同步加进度还是异步？
• 是否用 Trace 瀑布图确认了瓶颈在模型、工具、步数还是等待？
• 无依赖的工具调用是否已经并行？
• 模型输出是否有长度约束？是否存在大段不必要的复述？
• 确定性的步骤（校验、计算、格式转换）是否已经交给程序？
• 长任务在超过预算时，界面是否有进度展示或转为后台运行？

练习

拿一条你手头 Agent 的真实 Trace（或使用本课的客服例子，30–45 分钟）：

1. 画出瀑布图，标出耗时最长的 3 个 Span。
2. 对照七个手段，为每个瓶颈写一条优化方案，并预估节省的时间。
3. 指出其中哪一条可能影响质量，说明你会用什么评测来确认没有退化。

延伸阅读

• OpenAI：Latency optimization
• Claude 文档：Prompt caching

下一步

Trace、指标、成本和延迟都到位之后，关键是让它们持续驱动改进。下一课「持续改进闭环」讲如何把线上失败变成评测用例，再变成可验证的修改。