智能体响应变慢的排查顺序用户看到页面一直等待并不能说明模型生成慢。一次智能体请求可能经历鉴权、排队、图像或文件预处理、检索、工具调用、模型首字、流式输出和结果保存。排查先把请求定位到唯一标识再为每个阶段记录开始、结束、状态和取消原因才能区分真正的瓶颈与前端未显示进度的问题。先检查入口是否接到请求和是否排队再查看输入处理与检索随后查看工具调用、模型响应和流式传输最后确认浏览器是否收到首个事件并正确渲染。不要在没有 trace 的情况下同时改并发、模型、超时和缓存否则恢复后也无法知道原因。并发要由依赖关系决定互不依赖的工具调用可以并发但并发前要有次数、超时、权限与成本上限。很多外部 API 共享配额或会修改状态不能因为想缩短耗时就全部并发。需要先完成检索才能构造查询的步骤仍应串行并发任务应传递取消信号用户离开页面后不再继续消耗资源。图像解码、压缩和大文本处理可能占用事件循环或 worker。将 CPU 密集任务移到合适的线程或进程池前先测量当前执行方式增加 worker 会带来内存与调度成本。检索慢时也要拆分网络等待、索引查询、重排和结果序列化而不是泛称为“向量库慢”。async def record(name, operation, spans): start time.perf_counter() try: return await operation finally: spans.append((name, time.perf_counter() - start)) async def run(request): spans [] docs await record(retrieve, retrieve(request), spans) answer await record(generate, generate(request, docs), spans) return answer, spans计时数据需要与请求版本、输入类别和错误状态关联。总耗时不能简单等于各 span 相加并发 span 会重叠重试和排队也会改变用户感知时间。对流式请求至少记录首字时间、最后一段时间、客户端取消和上游完成状态避免只优化 TTFT 却让完整任务更慢。用证据选择优化动作若队列等待高检查容量、并发限制和优先级若预处理高检查输入大小和 CPU 资源若工具慢检查依赖超时与重试若模型慢检查上下文、输出上限和服务端排队。每次只验证一个主要假设并在代表性请求上比较前后差异。异常时要给用户明确状态例如排队、正在检索、需要重试或已取消。日志与 trace 中不要记录完整提示词、附件或令牌。可靠的排查不是让所有阶段“更快”而是让每个阶段的等待都可观察、可解释并受到边界控制。还应分别查看成功、失败和取消请求。只分析完成的调用会遗漏超时与用户中止平均值也会掩盖少量长尾请求。将这些分类与发布日期、模型版本和依赖版本放在同一仪表盘中才能确认性能变化来自哪里。对已经确认的瓶颈设定回归用例后续改动才能避免重新引入同一种等待。