Agent 如何实现低延迟响应：从 TTFT 到 Agent 循环的每一毫秒优化
普通 API 的延迟是一次网络往返，Agent 的延迟是一条「推理 × 多轮 × 工具」的乘法链。优化 Agent 延迟，本质上是在优化这条链上每一环的系数。
一、先定义延迟：Agent 的端到端延迟构成
一个标准的 ReAct Agent 处理一次请求，端到端延迟（E2E Latency）可以分解为：
T_e2e = T_ingress + T_plan + Σ(T_llm_i + T_tool_i) + T_build + T_render
其中每个环节又包含若干子项：
| 环节 | 构成 | 典型占比 |
|---|---|---|
| T_ingress（入口） | 网关、鉴权、路由 | 2%~5% |
| T_plan（规划） | 意图识别 + 任务规划（1 次 LLM） | 15%~25% |
| Σ T_llm（推理） | 每次 LLM 调用的 TTFT + 生成时间 | 50%~70% |
| Σ T_tool（工具） | 检索、API 调用、计算 | 10%~20% |
| T_build（组装） | 上下文拼接、消息序列化 | 3%~8% |
两个关键洞察：
- LLM 推理占大头，但工具调用和上下文组装同样不可忽视——当推理优化到位后，它们会从「小头」变成「瓶颈」；
- Agent 的延迟是指数叠加的：单次 LLM 调用优化 20%，如果链路有 4 次调用，端到端只优化约
1 - 0.8^4 = 59%中的一部分——每优化一环，收益会被放大。
二、拆解 LLM 调用的延迟：TTFT 与生成速度
单次 LLM 调用的延迟由两部分组成：
T_llm = TTFT（首 token 时间）+ ITL × (输出 token 数)
2.1 TTFT：上下文越长，首 token 越慢
TTFT 约等于「处理输入所有 token 的预填充（Prefill）时间」。输入 8K token 与输入 1K token，TTFT 可以相差 4~8 倍。因此降低 TTFT 的第一手段是降低输入长度。
2.2 生成时间：输出越长，等待越久
生成阶段每个 token 需要一次前向传播，输出 1000 token 的时间基本是输出 100 token 的 10 倍。降低生成时间的核心是让模型少说废话——输出格式约束、更精确的指令，效果立竿见影。
三、策略一：上下文瘦身——为每一轮推理减负
Agent 的上下文膨胀是延迟的隐形杀手。每一轮循环，Agent 都会把历史消息、工具结果、检索文档重新拼进 prompt。常见的膨胀路径：
原始上下文 2K
→ 检索出 20 个文档 +8K
→ 工具返回原始结果 +6K
→ 三轮循环历史累积 +12K
→ 第四次调用时上下文已达 28K，TTFT 是初始的 14 倍
3.1 检索收敛：宁缺毋滥
- 检索 top-k 从 20 压到 5~8，配合**重排序（Reranker）**保证召回质量不下降；
- 检索结果做摘要压缩再入上下文：
压缩后 = 摘要(原始文档)，把 8K 压到 1.5K； - 对文档做相关性过滤，与 query 无关的 chunk 直接丢弃。
3.2 历史裁剪：Agent 不需要记住每一句话
- 采用 滑动窗口 + 摘要：最近 5 轮消息保留原文，更早的历史压缩成 1~2 条摘要；
- 工具返回结果落库，Agent 只保留「结果摘要 + 引用 key」，需要细节时再按 key 取；
- 每条历史消息标注有效性，已被后续结果覆盖的消息（如旧的检索结果）直接剔除。
3.3 Prefix Caching：重复上下文不再重复计算
Agent 的系统提示词、工具描述、Few-shot 示例几乎每轮都原样出现。开启 Prefix Caching（vLLM --enable-prefix-caching / SGLang RadixAttention）后，这些重复前缀的预填充直接从「计算」降为「内存读取」，单次调用的 TTFT 可降低 40%~70%，且在 Agent 循环内、跨请求间都生效。
四、策略二：并行化——把串行链变成并行 DAG
Agent 最大的延迟浪费，在于本该并行的事情被串行执行。
4.1 并行工具调用
传统的 ReAct 一次只调一个工具。但「查天气 + 查航班 + 查酒店」这类请求彼此独立，完全应该并行：
# 串行：3 个工具 × 各 800ms = 2.4s
tools_serially = [call(t) for t in ["weather", "flight", "hotel"]]
# 并行：asyncio.gather → 约 800ms
tools_parallel = await asyncio.gather(
call("weather"), call("flight"), call("hotel")
)
OpenAI Function Calling / Anthropic Tool Use 原生支持一次请求携带多个工具调用，LangGraph 也支持并行分支节点。把「单工具循环」升级为「批量工具调用」，是 Agent 延迟优化中性价比最高的改动。
4.2 计划先行，检索并行
Plan-and-Execute 模式天然适合并行：规划 Agent 先产出任务清单，然后所有独立子任务同时执行，最后汇总。相比 ReAct 的一步步探索，能省掉 1~2 轮串行循环。
4.3 投机执行（Speculative Execution）
对「大概率会用到」的步骤提前执行：例如用户问「北京明天的天气和限行」，检索 Agent 可以同时预取天气和限行数据，即使最终只用到一个。代价是部分浪费，收益是省掉一次串行 RTT。适合对工具调用延迟高、且预测准确的场景。
五、策略三：流式输出——让「感知延迟」先于「实际延迟」
用户感知的延迟 ≠ 完整生成时间。只要首字节到达，用户就认为系统「开始响应」了。
5.1 全链路流式化
- 后端：所有 LLM 调用走 SSE 流式，第一层 Agent 的输出边生成边推送；
- 中间层：工具调用阶段推送「正在查询航班数据…」等进度事件，把「等待」变成「可感知的进展」；
- 前端：逐 token 渲染，而非等完整响应。
5.2 流式协议设计
event: agent_step # 事件类型
data: {"step": "plan", "content": "正在规划任务..."}
event: token # LLM token 增量
data: {"delta": "北京"}
event: tool # 工具调用状态
data: {"tool": "weather_api", "status": "executing"}
event: done
data: {"cost_tokens": 3200}
TTFB（首字节时间）从「完整生成 5 秒」降到「规划输出 300ms」，用户的等待感知发生质变。
六、策略四：模型分层与推理优化
6.1 让大模型只做必要的事
| 环节 | 推荐模型 | 理由 |
|---|---|---|
| 意图识别 / 路由 | 7B~14B | 分类任务，小模型又快又稳 |
| 任务规划 / 工具选择 | 14B~32B | 需要一定推理，但无需顶级模型 |
| 最终生成 | 70B+ | 只有最终输出值得用最强模型 |
分层后，链路中 70% 的调用由小模型承担，平均单次调用延迟可下降 40%~60%。
6.2 推理层调优手段
- 投机解码（Speculative Decoding）：小模型草稿 + 大模型验证，输出速度提升 1.5~2.5 倍；
- KV Cache 量化 / FP8：降低显存占用，提高批大小，间接降低排队时延；
- 张量并行与流水并行的合理配比：过度的张量并行会增加通信开销，小模型单卡即可，大模型 2~4 路张量并行通常最优；
- 预热与常驻：避免冷启动（模型权重加载动辄几十秒），推理实例常驻 + 池化。
七、策略五：缓存与预计算——把时间花在刀刃上
7.1 语义缓存：相同问题不重复推理
向量化相似度匹配（相似度 > 0.95 判定为重复问题），命中直接返回缓存结果，延迟从秒级降到毫秒级。配合 3.3 的前缀缓存，形成「语义层 + token 层」双层缓存。
7.2 工具调用结果缓存
- 检索结果、公共数据 API 按 key 缓存（带 TTL）；
- 把「缓存查询」本身做成一个 Agent 工具，Agent 循环中先查缓存、未命中才真正调外部 API。
7.3 预计算热点
对高频任务（每日简报、例行查询），定时离线执行，用户请求时直接读取结果。这是把延迟问题变成「新鲜度问题」的降维打击。
八、策略六：可观测的延迟治理
低延迟优化必须建立在精确测量之上，否则就是盲人摸象。
8.1 全链路追踪
用 OpenTelemetry 给每个环节打点：
span: agent.request # 总延迟
span: agent.plan # 规划
span: llm.call#1 # 第 1 次推理（记录 TTFT、tokens）
span: tool.search # 检索（记录召回数）
span: llm.call#2
span: context.build # 上下文组装（记录输入 token 数）
重点记录三个指标：TTFT、每环 token 数、每环耗时。
8.2 分位数管理
- 只看平均值会被长尾掩盖，必须盯 P50 / P95 / P99；
- 为每个环节设定预算：如规划 ≤ 400ms、单次推理 ≤ 1.5s、工具 ≤ 1s；
- 超出预算的环节自动告警，定位是上下文太长、队列排队还是工具慢。
8.3 一个实用的延迟预算表
| 环节 | 预算 | 优化手段 |
|---|---|---|
| 入口/鉴权 | ≤ 50ms | 就近部署、缓存鉴权 |
| 规划 | ≤ 400ms | 小模型 + 前缀缓存 |
| 单次推理 TTFT | ≤ 800ms | 上下文瘦身 + Prefix Cache |
| 单次推理生成 | ≤ 1s | 输出约束 + 投机解码 |
| 工具调用 | ≤ 1s | 并行 + 结果缓存 |
| 端到端 P95 | ≤ 3s | 以上全部 |
九、实战案例：一个 5 秒 → 1.5 秒的优化记录
一个典型的 RAG 问答 Agent 优化前后对比：
| 环节 | 优化前 | 优化后 | 手段 |
|---|---|---|---|
| 意图识别 | 70B 模型 900ms | 7B 模型 150ms | 模型分层 |
| 检索 | top-20 + 原始文档入上下文 1.2s | top-8 + Rerank + 摘要压缩 400ms | 收敛 + 重排 |
| 生成 | 输出 800 token 2.4s | 输出约束 350 token 1s | 格式约束 |
| 上下文 | 三轮循环累积 15K | 摘要化历史 4K | 历史裁剪 |
| 总延迟 | ~5.2s | ~1.6s | 组合拳 |
注意顺序： 先做「减少输入」再做「推理优化」。上下文从 15K 减到 4K 后，TTFT 自然大幅下降，此时投机解码等推理层优化的收益才会被放大。
十、关键结论
- 延迟是乘法链：每一环的优化都会放大到端到端；反过来，一个环节的瓶颈会吃掉其他所有优化的成果。
- 优先降输入，再谈推理：上下文瘦身 + Prefix Caching 是 TTFT 优化的两大支柱，收益往往大于推理引擎调优。
- 并行是免费的午餐：并行工具调用、Plan-and-Execute 改造，是延迟优化中性价比最高的动作。
- 流式改变感知：SSE + 进度事件让「感知延迟」先于「实际延迟」抵达用户。
- 用预算管理延迟：给每个环节设定分位延迟预算，超出即告警，延迟优化才能持续而非一次性的。
低延迟 Agent 不是「一个更快的模型」，而是「一个更懂取舍的系统」——知道哪些上下文该留、哪些该剪，哪些步骤该并行、哪些该缓存。