延迟预算博弈：如何告诉产品经理“实时性”是有能力代价的

一位产品经理走进规划会议，提出了一个只有一行的需求：“响应时间低于两秒，就像 ChatGPT 那样。”讨论中的智能体 (agent) 需要调用六次工具，检索两个索引，运行一个带有思考预算 (thinking budget) 的推理模型，并由第二个评审模型验证其输出。目前端到端的 p50 延迟是 9 秒。工程团队有三个选择：答应下来并悄悄地把智能体削弱成更糟糕的东西；拒绝并眼睁睁看着产品经理去寻找那些在演示视频中吹得天花乱坠的供应商；或者做一件入职培训中没人教的事 —— 开启一场结构化谈判，将每一秒的延迟都转化为智能体放弃的一项能力。

大多数团队会选择第一种。智能体上线后延迟确实到了 2 秒，但准确率下降了 12 个百分点，发布会仍被视为成功，因为达到了标题上的延迟指标。三个月后，团队开始与质量退化作斗争，却没人能将其归因于某项改动，因为退化本身就是那次发布。延迟目标从未被定价，它仅仅是从一份将速度视为免费午餐的产品规格说明书中继承而来的。

这篇文章是关于如何为延迟定价。必须进行的对话不是“我们做不到”，而是一场结构化的预算谈判。在这里，延迟、准确率和能力被摆在桌面上，产品负责人从中三选二。不进行这场谈判的团队，交付的将是别人做出的权衡。

为什么“把它变快”在架构上毫无意义

为什么“快一点”会让对话陷入僵局？因为智能体系统中的延迟不是一个单一的拨盘。它是架构决策的总和，单个决策的成本是可知的，但总成本只有在最后才会显现。一次 LLM 调用可能需要 800ms；一个带有反射循环的编排器-执行器流程则需要 10–30 秒。当你要求工程团队将延迟减半时，你不是在要求他们优化 —— 你是在要求他们移除组件，而这些组件都是有名有姓的。

每个组件换取的是特定的能力：

• 一次工具调用换取的是在模型未知的系统中进行接地 (grounding)。
• 一次检索过程换取的是对上下文窗口放不下的事实的访问权。
• 一个推理模型在多步问题上换取的是不同的准确率曲线。
• 一次验证环节换取的是针对特定错误类别的防护 —— 幻觉引用、错误单位、伪造的 API。
• 第二个模型对第一个模型的评估，换取的是在对抗性输入下的鲁棒性。

当产品部门在不重新定义能力集的情况下要求智能体提速三倍时，他们实际上是在默许工程团队选择删除其中哪些项，并默默承担后果。工程团队不应该做这个决定。产品拥有能力定义权；工程拥有实现架构的所有权。将两者混为一谈，你得到的就是一个又快又错的智能体。

在对话开始前建立转换表

让这场谈判变得可行的是一张基于你实际技术栈生成的“延迟-能力转换表”。不是通用的厂商跑分，而是你的追踪记录 (traces)、你的工具、你的模型、你的网络路径。

它看起来像这样：

• 一次工具调用：600–900ms（取决于工具 —— 你的 CRM 查询比内存缓存慢）
• 一次检索过程：热索引下 200–400ms，冷索引下 1.5s
• 一次低负载推理：1.2s，并增加约 300 个隐藏 token
• 一次高负载推理：4–8s，在给出答案前可能消耗 80% 的可用输出 token
• 一次验证模型调用：600–1200ms
• 在同一查询中将推理模型更换为快速模型：延迟减少 3s，但在评测集上准确率下降 8 到 15 个点
• 一次上下文压缩步骤：400ms，平均为下游节省 1100 个 token

从生产环境的追踪数据中生成这些数据，而不是厂商的营销页面。将表格保存在产品经理能看到的文档中。每季度更新一次，因为随着模型、基础设施和工具延迟的变化，转换率也在变。表格的意义不在于精确，而在于让权衡在双方都能认可的单位中变得可协商。

当你第一次把这张表放在产品经理面前时，对话的形式就变了。“把它变快”变成了“好吧，我愿意放弃其中的哪一项”。这才是你想要进行的对话。

“三选二”框架强迫诚实的选择

终结这场谈判的重构是“三选二”框架：“在低于 2s 的响应时间、95% 的准确率和完整的工具集之间，你可以任选其二 —— 选好后我会据此进行架构设计。”这不只是话术，这是当前成本和能力边界下智能体系统的结构性事实。这样表述将对话从“工程团队态度消极”转向了“产品究竟在优化哪一维度”。

每种组合都有可辩护的架构：

• 低于 2s + 完整工具，准确率较低：使用快速模型，激进地并行化工具调用，去掉验证环节，接受最差的 10% 输入会产生错误答案。适用于用户可以识别错误并重试的场景 —— 如自动补全、搜索辅助、行内建议。
• 低于 2s + 95% 准确率，较小的工具集：将工具集激进地精简为工作流中真正需要的工具。缓存重复查询的计划。使用内存层将常见模式从 30s 的规划缩短到 300ms 的检索。接受智能体在超出其定义范围的边缘案例中显得很笨。
• 95% 准确率 + 完整工具，延迟较高：使用推理模型，运行验证环节，保留丰富的工具集，允许延迟拉长到 8–15 秒。通过流式传输展示进度，让等待过程看起来像是在“工作”而不是“死机”。适用于那些替代方案是人类花费 20 分钟完成任务的工作流。

那些说“我三样都要”的产品经理不是在要求一个产品 —— 他们是在要求进入另一个行业。“三选二”框架将这一点摆在了台面上，且不带个人色彩。它也迫使他们阐明哪个维度对用户来说才是真正关键的。大多数情况下，当被迫做出选择时，他们会选择那个在最初规格说明书中并未被提及的维度。

TTFT 才是产品真正关心的延迟指标

显式进行协商的一个附带好处是，它能暴露几乎每个产品规格中都潜藏的一个测量误差：用户真正关心的延迟指标很少是端到端的完成时间，而是首个 Token 生成时间（TTFT）。

原始规格中的两秒目标，在 PM 的脑海里几乎肯定指的是 TTFT。他们心中有一种特定的用户体验：用户提交查询，屏幕上瞬间开始有所反应，响应让人感觉是活的。完整的响应是需要两秒还是二十秒，远没有第一个字符是否在几百毫秒内出现重要。在 100ms 以下，系统让人感觉是瞬时的。在 500ms 以下，它让人感觉是有响应的。超过几秒钟如果没有可见的进展，系统就会让人感觉坏掉了 —— 即便最终的答案非常出色。

这对协商至关重要，因为 TTFT 和端到端延迟是可以独立控制的。你可以拥有一个需要九秒钟的 Agent，它流式传输思考过程，显式地调用工具，并在 200ms TTFT 时显示进度 —— 用户会认为这比一个在四秒钟内返回完整答案块的 Agent 更快。流式传输是一种感知技术，它能让你在不支付移除组件的架构成本的情况下，获得大部分用户体验上的红利。

在你接受任何延迟目标之前，先问问产品人员他们指的到底是什么数字。有一半的时间，规格会坍缩为 “TTFT 在 500ms 以内并伴有可见的完成进度”，这比规格字面上的意思要容易解决得多，工程成本也低得多。

用多层级评估证明质量悬崖

另一个让协商变得真实的产物是“质量-延迟”曲线，该曲线是针对固定的评估集进行评分的。这不仅仅是当前架构下的单一分数，而是针对如果你收紧延迟目标时会考虑构建的每种架构的多个分数。

评估矩阵的行代表架构（完整推理 + 验证器、快速模型 + 验证器、快速模型 + 并行工具、仅快速模型），列代表 Agent 支持的每种任务类型的准确率。当产品人员看到从四秒目标转为两秒目标会导致他们最关心的工作流损失 18 分时，协商在开始之前就已经结束了。他们之前没意识到曲线会如此陡峭。他们想象的是一种平滑的权衡。

这之所以有效，是因为产品人员对于延迟-质量曲线的直觉几乎总是错向同一个方向：人们想象的是一个平缓的坡度，而现实却是一个悬崖。这个悬崖位于你为了达到目标而不得不移除的任何架构组件之处。用数据展示悬崖比任何争论都更有说服力。你不是在要求他们相信你的话 —— 你是在向他们展示如果他们有时间运行评估，他们自己也会收集到的数据。

这也为对话创造了一个有用的逃生阀。当产品人员看到悬崖时，自然的后续问题是“有没有办法推后这个悬崖？”这是一个很好的工程对话。内存层、语义缓存、模型蒸馏、更智能的检索 —— 这些都是真正的杠杆。它们也是长期的工程投资，在延迟协商的同一场对话中为它们定价，可以将它们作为跨季度的项目呈现出来，而不是让它们像简单的任务一样被塞进发布冲刺中。

失败模式是直接接受规格

上面描述的一切都是一种协商。值得点名的失败模式是当没有发生协商时会发生什么。

工程团队将延迟目标作为一种约束接受。他们离开并根据这个目标设计架构。他们换入的快速模型在评估未能很好覆盖的一类输入上产生了微妙的变差。Agent 停止调用的工具原本是用来防止一类尚未命名的幻觉。他们移除的验证器每周能捕捉到一次单位转换的漏洞。这些都不会体现在发布指标中，因为发布指标是延迟和 CSAT（客户满意度）—— 而 CSAT 很高，因为 Agent 反应迅速且自信，用户直到很晚才会发现答案是错的。

六个月后，团队正在应对一个无法定位的质量退化。自发布以来的每一次提交都是嫌疑对象。真正的元凶其实是发布本身：一个未定价的延迟目标，它在没有人承担权衡责任的情况下，用能力换取了速度。PM 不记得要求过更换模型，工程团队也不记得被要求过。决策发生在规格与架构之间的鸿沟中，而这个鸿沟就是一个盲点。

弥合这一鸿沟的纪律是小而程序化的。产品规格中的延迟目标在成为承诺之前，需要工程团队的反向提案。反向提案用转换表所使用的单位指明了能力的权衡。如果产品接受了这种权衡，它就会和延迟数字一起写入规格 —— “两秒，无验证器环节，标准评估预期准确率为 84%”。如果产品不接受，延迟数字就会改变。无论哪种方式，这两个数字是一起移动的，并且都有负责人。

延迟是一项跨职能约束，而非性能指标

这一切背后的架构层面认知是：智能体系统中的延迟并非一个孤立优化的性能指标。它是一项约束，决定了下游每一个架构选择的成本——工具调用、模型选择、验证深度、检索广度以及规划视野。将延迟视为性能指标的团队只会优化单一数字，最后交付的智能体在其他指标下滑时甚至无人察觉。而将延迟视为约束的团队会进行博弈、构建转换表、揭示临界点，并交付一个权衡取舍（tradeoffs）明确的智能体。

最初几次这样的沟通可能会让你感到不适。PM 习惯于将延迟视为工程团队负责的事。工程团队则习惯于将产品规格视为硬性需求，而非讨论的起点。在 PM 第一次看到转换表并感叹“哦——我没意识到验证器为我们带来了这么多提升”之前，转换表可能显得有些过度设计。在那次沟通之后，随后的每一次博弈都会变得更短，因为双方对于一秒钟的延迟究竟能换取什么有了共同的语境。

2026 年能够成功交付的智能体，并非那些延迟最低或准确度最高的，而是那些权衡取舍经过主动选择而非被动继承的。进行博弈的团队才真正掌控自己的产品。而不进行博弈的团队，只是在交付一份在对临界点一无所知的情况下编写的他人规格。