用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。
这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。
你的智能体管道很慢，于是你把任务拆分给五个并行子智能体。p50 下降了，你把它上线了。三天后，告警响了：一批用户请求超时。你挖进去发现 p99 从 4 秒涨到了 22 秒。单个智能体本身没有任何变化。超时是因为编排层在等最慢的那个——它以 1% 的概率遇到了检索抖动，但现在任何触碰全部五条路径的请求都会遇到这个概率。
这就是并行陷阱：这个模式看起来是显而易见的提速方案，实则以一种伤害真实用户更多的方式重构了延迟分布，p50 的改善远不能弥补 p99 的恶化。在生产基准测试中，单个智能体在 64% 的评估任务上能匹配甚至超过多智能体管道。并行扇出奏效的时候，确实奏效得很干净——但仅限于特定类别的问题。把扇出当作默认选项，才是错误所在。
查看你的网关重试配置。三次尝试。带有抖动的指数退避。在 5xx 错误和超时时重试。最大延迟限制在几秒钟。这看起来很合理，而且是某人两年前从微服务运行手册中复制过来的。但这正是你的 P99 是 P50 两倍、在服务商发生故障期间 Token 费用激增，以及相当一部分用户在默默流失前盯着 30 秒加载圈的最主要原因。
专为 50 毫秒 RPC 设计的重试策略在面对 8 秒的 LLM 调用时注定会失效。失败的形式不同，每次尝试的成本不同，用户感知到的时间维度也不同。默认设置并不安全，只是让人感到熟悉。大多数团队通过同样的方式发现这一点：在一次事后回顾中，网关日志显示响应成功，而客户的截图却显示 UI 已经卡死。
仪表盘显示智能体很快。P50 停留在 1.2 秒，团队开会庆祝，然后放弃率却在持续攀升。没有人关注用户真正体验到的那个图表。
这是生产环境中多步智能体可靠的失效模式：中位数是你能够达到的指标，而尾部延迟才是你用户感受到的指标。随着你在流水线上不断增加子调用，这两者之间的差距会呈非线性增长。一个包含四个步骤的智能体，即使每一步在“中位数表现”上都很快，其 P99 通常也会比任何单步操作糟糕 6 到 8 倍。用户体验到的不是中位数，而是他们那次特定请求中最慢的一步。
如果你的团队优化了错误的分位线，你交付的系统将拥有出色的基准测试表现和精美的演示效果，但在你从未监测的长尾场景中，用户正不断流失。
我最近交流的一个团队为他们的 AI 助手构建了一个所谓的“深度防御”（defense in depth）流水线。一个输入分类器检查提示词注入；一个越狱过滤器扫描对抗性模式；模型生成回复；一个输出审核环节扫描结果；一个拒绝检测器检查模型是否回避了问题，如果是，则通过重新表述步骤，用更委婉的框架再次提问。评估套件显示该提示词在 1.4 秒内生成了答案，但真实用户的等待时间中值是 3.8 秒，p95 则超过了 9 秒。
每一个安全层都是一次往返。每一次往返都包含网络跳数、排队时间、模型加载和解码。当你将它们串行地堆叠在生成调用前后时，你为产品设定的延迟预算就会灰飞烟灭——而几乎没人在设计评审时考虑到这一点。更糟糕的是：流水线中最慢、最昂贵的路径往往是那些触发了安全边缘提示词的路径，而这恰恰是你的安全机制存在所要处理的长尾场景。你正在默默地用普通用户的账单来补贴这些长尾流量。
评估套件在凌晨 2 点运行。流量很低。缓存是冷的，但队列是空的。供应商的连续批处理程序有空闲插槽，并将以接近其 TTFT（首 Token 延迟）底线的水平处理每个请求。延迟分布很紧凑，评测模型分数稳定，仪表盘显示一片绿色。团队发布上线。
六个小时后，太平洋时间上午 8 点，同样的 Prompt 在美国早高峰期间进入生产环境。p95 延迟是评估报告的 2.4 倍。相当一部分请求从一个供应商那里收到了 529 错误，并回退到另一个供应商的较小路由层级。流式传输的节奏更加断断续续。评测模型（当天晚上对生产环境追踪样本进行重新运行）给出的中位数得分比凌晨 2 点给出的相同 Prompt 的得分低了半分。代码库没有变化。Prompt 没有变化。只是挂钟时间变了。
必须意识到的架构真相是：LLM 调用不是其输入 Token 的纯函数。它是一个随机分布式系统调用，其输入包括挂钟时间、供应商集群的负载、Prompt 缓存的状态、当前解码批次的大小，以及供应商负载均衡器在你的请求到达的那一毫秒所做出的路由决策。在凌晨 2 点运行评估的团队，是在一种用户永远无法体验到的条件下校准仪器。
仪表盘显示 p95 的 agent.run = 28s。用户反馈该功能感觉已经挂了。值班工程师打开 Trace（追踪），看到一个没有任何值得调查的子节点的“肥大”长条，然后开始盲猜。当有人重建出足够的心理模型，搞清楚瓶颈到底是模型、检索器，还是某个没人添加 Span 的工具调用时，故障已经变成了积压的任务单，而用户早已放弃了。
这就是 2026 年 Agent 运营核心的失败模式：传统的 APM 将 Agent 步骤视为一个黑盒，而“Agent 延迟”并不是一个单一指标——它是七个指标的总和，这些指标根据 Agent 在该轮次中的决策，以不同的方式分解实际用时 (Wall-clock time)。如果一个团队不暴露这七个数字，他们交付的功能虽然大家都能感觉到慢，但谁也无法修复。
评测团队在 PPT 上写下一个数字：“p95 延迟为 1.2s。” 产品上线。一周后，值班人员发布了一张图表：生产环境中的 p95 为 4.8s，并且在晚餐高峰期持续攀升。工程师们在接下来的五天里争论是否有性能倒退、为模型版本增加埋点、向供应商提交工单——最终发现，除了测量数字的地点之外，什么都没有改变。评测环境报告的是一台安静的机器在热缓存上运行串行调用的延迟。而生产环境是另一套系统。p95 从未出错；它只是在回答一个不同的问题。
这就是评测工具的延迟谎言。这并不是因为基准测试做得不好——大多数团队使用的工具都很合理，报告数字也很诚实。问题在于“模型延迟”与“用户感知的延迟”之间的鸿沟，以及你为开发构建的环境几乎总是测量前者，却暗示后者这一事实。一旦你理解了这一点，基于基准测试得出的延迟 SLO 就不再像是产品承诺，而更像是对一个没人能复现的私人测试环境的声明。
你的延迟仪表盘显示一切正常。p95 的首字延迟（TTFT）低于 800ms 的目标。p99 的总生成时间也在 4 秒的预算之内。然而，一位资深 PM 转发了一个支持线程：“助手在回答中途卡住了大约三秒钟”，“它停顿了一下，然后突然吐出一整段文字”，“我以为它死机了”。本周有三位用户因为同样的投诉卸载了应用。团队中没人能在笔记本电脑上重现这个问题，而且你记录的每一项指标都显示系统运行健康。
能解释这个 Bug 的指标正是你没在测量的那个：连续 Token 之间时间间隔的分布。一个看起来很完美的 p95 总时长可能会掩盖这样一种流：其中 8% 的响应在生成中途包含一个 2.5 秒的停顿。对于一个看着字符实时出现的用户来说，这种停顿意味着系统出故障了，而不仅仅是慢。你的仪表盘测量的是电影的总时长，而你的用户正在观看电影。
当你第一次发布语音智能体（voice agent）时，你会听到两个相同的抱怨：“它打断了我”和“它感觉很不礼貌”。这两者其实是同一个 Bug。智能体并不是真的没礼貌——它只是在运行一个你从未明确记录过的延迟预算（latency budget）。聊天机器人那种“在输入完成后响应”的直觉，在语音场景下会产生一种挫败感：就像在和一个人聊天，他总是打断你的话，又在不该沉默的时候突然安静。
人类在对话中的轮换（turn-taking）通常发生在约 100 到 300 毫秒的窗口内，这在所有已测量的语言中都是一致的。中位数 200ms 的说话者间隙不是一个目标，而是一个人类校准的基准。任何更慢的反应都会被解读为困惑，任何更快的反应都会被解读为打断。如果语音智能体没有明确模拟这种节奏，每一轮对话都会掉进这两个坑里的其中一个。
解决方案不是用更快的模型，而是承认语音 AI 是一个软实时系统（soft real-time system），其预算由人类对话的物理特性决定，并在发布前记录下这个预算。
你的仪表盘显示 GPU 状态健康。利用率维持在 80% 左右，每秒生成的 token 吞吐量看起来很正常，冷启动很少见，而且模型也是你要求的那个。然而，你的报警器响了，因为 p99 延迟翻了三倍，少数用户遇到了超时，支持工单都在描述同一件事：“应用冻结了 20 秒，然后又恢复了。” 你调取了一个追踪（trace），发现一个毫不相关的客户发送的 28,000 个 token 的推理请求，正与每一个停滞的调用处在同一个批次（batch）中。某个租户的深度思考提示词刚刚抢走了其他所有人的机会。
这就是队头阻塞（head-of-line blocking），它是推理模型进入流量组合后，破坏共享 LLM 推理的典型故障模式。这种模式并不新鲜 —— 存储系统和网络栈已经与之斗争了几十年 —— 但由于连续批次（continuous batching）和 KV 缓存固定（KV-cache pinning）的工作方式，它在 GPU 上呈现出一种特定的形态。大多数团队针对平均负载进行设计，却太晚才发现，一旦请求大小不再相似，“共享推理更便宜”就不再成立了。
你的仪表板很干净。昨天的部署也已干净地回滚。模型版本已锁定。提示词没有更改。但你的 TTFT p99 刚刚翻了一倍，客户成功渠道已经炸锅了，而你唯一能给出的诚实回答是“这是提供商的问题”。这个答案显得很苍白——就像耸耸肩一样——它通常会引出一个团队中没人能回答的后续问题：证明它。
这是托管 LLM 推理中营销页面不会讨论的部分。当你调用前沿模型 API 时，你正在与你看不见的负载共享 GPU、PCIe 结构、连续批处理和 KV 缓存预算。你的 p99 是这些负载突发的函数。大规模推理的经济性取决于租户的多路复用是否足够紧密，以使硬件利用率保持在 60-70% 以上，这意味着你的尾部延迟在结构上与同一分片上最大、最不规整、最不稳定的租户耦合。你购买的不是容量；你购买的是一个别人也排在其中的队列切片。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
