先这样答
延迟排查的第一步不是优化，是归因：在链路每个环节打点（LLM 推理、每次工具调用、检索、编排逻辑），把一次请求的时间轴拉出来看。Agent 的延迟结构和普通应用不同：它是多轮循环，每轮都有一次 LLM 调用，串行叠加。不做归因就直接优化，方向经常是错的。
归因之后，常见的时间大头按概率排。
第一大头：轮数太多。十轮串行调用，每轮哪怕只花一秒，加起来也是灾难。优化方向是减轮次：一次工具调用拿回足够的信息（把三次分页查询合成一次带完整参数的）；任务拆分时控制粒度，别为省上下文把任务切得太碎；规划类任务先整体规划再执行，减少走错路的返工轮。
第二大头：LLM 推理本身。输出长度直接决定推理时间，生成长报告就是慢。手段：流式输出（总时间没变，但首字时间骤降，体感完全不同）；输出约束（别让模型写废话）；需要快的环节换小模型或开厂商的加速选项。
第三大头：工具执行。外部 API 慢、数据库查询没走索引、串行调了本可并行的多个工具。手段：能并行就并行（三个独立的数据源查询并发执行）；慢工具加超时和降级；查询类工具加缓存。
第四大头：检索链路。Embedding 计算、向量库查询、重排模型，各自都可能慢。手段：索引参数调优、重排候选数减少、检索结果缓存。
最后补架构层的一句：把「能提前做的」提前：会话开始时预载记忆和常用上下文、异步预取可能用到的数据，把同步链路里的工作挪到用户等待之前。
面试官会怎么追问
- 怎么衡量「慢」？ 分层看指标：首字时间（TTFT，用户体感的核心）、端到端总时长、各环节耗时分布；按任务类型分别建基线，查询单和报告单的合理延迟完全不同。
- 并行会不会引入新问题？ 会：并行工具调用要做依赖分析（真独立才能并行）、结果合并顺序要确定、失败处理更复杂；收益大时值得，但要带着并发控制做。
- 流式输出对 Agent 有什么限制？ 最终答案可以流式，但中间的工具调用轮没法流给用户，所以产品上要设计「过程可见」：把「正在查询订单系统」这类状态实时推给用户，等待感会小很多。
回答的坑
- 不打点就开药。先归因后优化是性能题的铁律，直接背优化手段反而丢分。
- 只盯推理时间。轮数才是 Agent 延迟的第一大头，这一点想不到说明没维护过真系统。
同系列的题
—— 本题完 ——