智能体延迟优化，首先不是“换一个更快的模型”，而是回答一个更具体的问题：一次请求究竟把时间花在了哪里。端到端延迟通常由输入处理、模型推理、工具调用和上下文重组共同构成。只看模型生成耗时，容易把真正的瓶颈误判为算力不足。
先建立可拆解的延迟账本
排查应从一次完整请求开始，记录各阶段耗时，并区分首 Token 延迟、后续生成速度、外部接口往返时间、上下文处理时间和调度排队时间。模型推理往往只占总延迟的约 40% 到 60%，其余时间可能消耗在工具等待、历史消息拼接和任务调度上。因此，模型速度提升一倍，并不意味着用户等待时间也会减少一半。
上下文是最容易被忽略的隐性成本。多轮任务中，历史消息、工具原始返回值和中间结果会不断累积；其中不少内容已经失效，或与当前决策无关。应重点观察输入 Token 是否随轮次持续增长，并检查是否存在重复提示词、冗余 JSON 和未清洗的工具结果。若上下文增长明显，优先做摘要、滑动窗口和关键字段提取，而不是立即更换模型。
工具调用则要看依赖关系，而不只是单次响应速度。串行链路会把每次模型推理和接口等待逐项叠加；无依赖的调用如果仍然逐个执行，就存在明确的并行空间。以三个外部 API 为例，若每次模型推理耗时 2 秒、接口往返耗时 1.5 秒，完全串行约需 10.5 秒；其中两个调用并行后，总耗时可压缩至约 7 秒。
用长尾指标确认真正瓶颈
平均延迟不足以支撑判断，还应同时观察 P50、P95 和 P99 端到端延迟、工具调用耗时、排队等待时间、上下文 Token 数，以及等待外部调用时的模型空闲率。P95 偏高，通常意味着外部服务或调度队列存在长尾；模型空闲率偏高，则说明资源正在等待工具返回，编排层可能缺少并行调度。
实际优化宜遵循“先定位、再改动、后验证”的顺序：先用压测确认模型基线，再检查上下文、工具和队列，最后通过 A/B 测试验证结果。多数场景应先处理上下文压缩和工具结果清洗，再推进并行调用与流式输出，之后才根据监控数据决定是否引入更复杂的缓存和调度策略。延迟优化的目标不是追求绝对零等待，而是让每一次等待都对应必要的计算或业务价值。