Appearance
48. Agent 链路耗时很长时，如何定位性能瓶颈？
难度 P1 高频 · 岗位 应用 · 频率 ★★★ · 预计阅读 5 min
👔面试官：Agent 链路耗时很长时，如何定位性能瓶颈？
🙋♂️我：看日志，找哪一步慢。
👔面试官：对，但要分层拆解：模型层、检索层、工具层、编排层、结果层。而且很多"5分钟任务"不是卡在单次模型调用，而是状态流转没设计好。你能系统讲吗？
💡 简要回答
五层拆解：
| 层级 | 检查点 |
|---|---|
| 模型层 | 单次推理时长、首 token 延迟、输出长度 |
| 检索层 | 召回、重排、外部搜索耗时 |
| 工具层 | API 延迟、浏览器动作、代码执行 |
| 编排层 | 路由判断、Supervisor判断、重复重试、串行等待 |
| 结果层 | 后处理、校验、存储、日志落盘 |
关键认知：很多长耗时不是"模型太慢"，而是状态流转和执行闭环没设计好。
📝 详细解析
性能瓶颈定位的系统方法
第一步：打 Trace。每个 Agent 步骤打一个 Span，记录开始时间、结束时间、输入输出大小。工具：LangSmith、Phoenix（Arize）、OpenTelemetry + Jaeger，或自研 trace 系统。
第二步：看 Wall Time 分布。把总耗时按层级拆分：
总耗时 = Σ(模型调用) + Σ(工具调用) + Σ(检索) + 编排开销
典型分布：
- 模型调用：30-60%（单次 2-5s，多步累加）
- 工具调用：20-50%（外部 API 慢时占大头）
- 检索：10-30%
- 编排：< 5%（若过高说明状态机设计有问题）常见瓶颈模式：
- 模型调用串行：每步等上一步完成。优化：能并行的工具调用改为并发
- 重复检索：同一上下文被多次检索，结果几乎一样。优化：步骤内缓存检索结果
- 工具失败重试风暴：一个工具超时，Agent 反复重试。优化：指数退避 + 最大重试次数限制
- 上下文累积膨胀：每步把完整历史拼入 Prompt，输入 token 线性增长。优化：滚动窗口 + 历史压缩
优化优先级
1. 找最大的耗时 Span → 集中优化（80/20 原则）
2. 串行 → 并行：独立工具并发执行
3. 减少无效调用：规则能判断的不进模型
4. 缓存：重复检索、重复工具调用结果缓存
5. 换更快的模型：延迟敏感路径用小模型🎯 面试总结
分层拆解，打 trace 和 span。先看 wall time 花在哪，再优化。