排查 LLM API 响应慢，先把“等模型”和“等 Agent 的其他环节”拆开。测试命令慢、反复重试、等待审批，都可能占据大部分任务时间，即使模型生成本身很快。
下面是一套建议的测量流程，不是 Agent.Space 速度实测。服务商资料核验日期为 2026 年 9 月 29 日。
先定义“慢”指哪一段
选择你关心的时间范围：
- 首次可见输出时间： 用户多久才能看到有用的回应。
- 生成时间： 回答持续产生输出的时间。
- 工具时间： 读文件、跑命令、等待外部服务的时间。
- 任务验收时间： 从开始到拿到可用结果的全过程，包括重试和检查。
流式输出可以让进度更早出现，但不一定缩短整项任务。OpenAI 的延迟优化说明把流式、输出长度、请求数量作为不同的优化手段讨论。
把一项任务记成时间线
固定模型、任务、客户端和接口，用一致的时钟记录这些事件：
响应事件可能只是元数据，并非正文。应明确自己的定义，不要把两种不同的“首字时间”拿来比较。
同时记录请求 ID、输出大小、重试次数，以及是否命中缓存，不记录原始密钥或敏感提示词。模型路由核验指南解释了为什么模型的自我介绍不能当成路由证据。
找到慢的那一层再动手
只有客户端计时，无法把服务商排队和模型计算准确拆开。缺少更强证据时，应把这段叫作“服务商/通信等待”。延迟也不能证明服务商替换了模型。
一次只比较一种改动
用小预算跑一组代表任务。每次只改一个因素，例如减少多余输出、减少重复请求、修正重试策略，同时确认结果仍满足原有验收条件。
保留每次耗时和失败记录，不要只看平均值。少量样本能发现可复现的卡顿，但不足以证明可靠的生产百分位延迟，也不能做通用模型排名。
如果大部分时间花在工具上，换模型可能只增加费用；如果回答变短却遗漏必要工作，也不能算有效提速。
让连接与任务都可核对
先用 Developer API 指南建立已知可用的连接，再查性能。计时证据清楚后，需要选模型可参考 Coding Agent 模型选择指南。
需要受支持的客户端配置时，可以打开 Agent.Space。从可复现的小任务开始，以拿到可用结果的时间判断速度，而不是只看第一个跳出来的字。