Agent 循环从搜索框偷走的延迟预算

发布指标看起来很干净。回答质量提升了，引用率上升了，评估套件全绿。那个用基于 Agent 的检索器替换旧关键词搜索的团队发布了产品，赢得了胜利，然后转向了下一个项目。六周后，有人注意到该界面的周活跃用户数下降了 12%，但没人能找到性能回归。其实并没有回归。Agent 运行正常。用户离开是因为以前在 200 毫秒内就能给出答案的搜索框，现在需要 4 秒钟，而发布回顾中没有任何内容涉及到这方面的预算。

这就是延迟预算转移问题，而且几乎没有人会画出能捕捉到这一问题的组织架构图。搜索框不仅仅是一个函数调用。它是与用户神经系统签订的一份为期三十年的契约：输入、查看结果、扫视、点击。200 毫秒的响应并不是某个仪表盘上的性能指标——它是当结果送达时，用户的注意力仍然留在屏幕上的原因。当搜索框背后的团队用 Agent 循环替换关键词索引时，函数调用表面看起来是一样的，但新调用的 SLA 处于一个完全不同的范畴。延迟预算从拥有索引的团队转移到了拥有 Agent 的团队，又从拥有 Agent 的团队转移到了用户身上，而唯一参加会议的只有用户。

搜索框是三十年的肌肉记忆，而非 UI 元素​

Jakob Nielsen 的响应时间阈值——0.1 秒感觉是即时的，1 秒能保持用户的思路连贯，10 秒是注意力崩溃前的极限——比阅读本文的大多数工程师都要年长。它们不是风格指南。它们是对当反馈以不同延迟到达时，人类感知系统反应的描述。在 100 毫秒以内，用户感觉自己是在直接操作页面。超过一秒，用户会察觉到机器正在工作。超过十秒，用户就会开始另一项任务。

在你交付产品的每一个用户的职业生涯中，搜索框都一直处于第一个范畴。Google 培养了全球性的预期；开放网络上的每个搜索框都继承了这一点。当你团队旧的关键词搜索在 180 毫秒内返回时，用户并没有意识到等待——他们意识到的是答案。从用户的角度来看，延迟预算实际上是零，这就是为什么运行索引的团队以毫秒为单位处理他们的 p99，而产品团队根本不需要考虑它。

Agent 循环并不属于那个范畴。一个包含检索、规划和工具调用的单次 LLM 调用，完整响应通常在三到八秒之间。首字用时 (Time to First Token)，即流式界面能给出的最快信号，根据供应商和负载的不同，在 200 毫秒到 1.5 秒之间。即使是 Agent 循环中开销最小的部分，也已经达到或超过了用户察觉到机器正在工作的阈值。而开销大的部分则超过了用户开始考虑做其他事情的阈值。

产品界面没有变。用户的心理模型没有变。但延迟范畴移动了一个数量级。问题不在于新答案是否更好。问题在于当答案送达时，你是否还在页面上。

那个没有邀请预算持有团队的发布回顾​

拥有关键词索引 200 毫秒 SLA 的团队并没有参与 Agent 的发布决策。这项决策读起来像是一个算法更换，而不是性能变更。准确率评估全绿，成本模型计算可行，发布计划也涵盖了回退行为和配额。延迟在幻灯片中仅表现为一个数字——新管道的 p50——而且没有人提出索引团队会问的问题：这里的面向用户的预算是多少，谁拥有它，以及超过哪个阈值我们会将发布视为失败？

这就是结构性失效。当实现方式改变时，延迟预算的所有者也会改变，但组织很少能捕捉到这种交接。基础设施团队的 SLA 针对的是一个已不再存在的调用。产品团队的 SLO 隐含地就是基础设施团队s的 SLA——没有人写下来，因为三十年来没人需要这样做。当实现方式被替换时，SLO 也随之消失，而发布新实现的团队继承了一份他们甚至不知道自己拥有的预算。

解决方法不是将发布回退到索引模式。解决方法是在发布之前，以书面形式确定延迟预算——将其作为产品 SLO，而非基础设施 SLO。一个有用的 SLO 版本不应该仅仅是 “p99 低于 300 毫秒”，而更应该像是一个分层预算：首个有用标记的出现时间必须落在用户之前的预期内；完成完整答案的时间可以放在较长的时间桶中，但前提是界面要告诉用户中间发生了什么。该 SLO 的所有者是产品团队，而不是推理团队。推理团队拥有的是另一个 SLO：为其提供支持的底层数据指标。

如果你能点名团队中负责 Agent 界面面向用户延迟预算的人，那么你已经完成了最艰难的工作。如果你不能，那么这份预算就处于无人认领的状态，这等同于没有预算。

First-useful-token 是用户真正感知的唯一数字​

流式传输让延迟变成了一个动态目标，而不再是一个单一数字，但大多数团队衡量的是错误的指标。首个 Token 时间（Time to First Token, TTFT）——这个传输层的指标——是模型供应商提供的，也是大多数可观测性栈展示的图表。而首个有用 Token 时间（Time to First Useful Token, TTFUT）——即屏幕上出现用户可以阅读、扫描或操作的内容的时刻——才是决定用户最后是否还留在页面上的关键。

两者并不等同。如果一个流式响应以“好的，我可以帮你解决这个问题。让我思考一下这个疑问……”开头，会将用户的首个有用 Token 推迟几百毫秒。而如果一个响应以答案的首个具体主张、首个相关引用或计划的单行总结开头，就能落在用户注意力依然集中的区间内。传输指标保持不变，但 UX 指标却跨越了一个完整的注意力阈值。

这是一个设计问题，而不是性能问题。解决之道在于提示词（Prompt）、流式格式以及渲染流的界面。指令模型优先输出响应中的核心承重部分。一旦解析出结构化数据块（如一个列表项、一张卡片、一个大纲），就立即渲染，而不是等待整个段落结束。如果界面已经有“我正在处理”的提示，就删掉礼貌性的开场白。花在开场白上的每一个 Token，都是在消耗用户的注意力预算。

这个指标的真实版本是可观测的。在监测 TTFT 的同时记录首个有用 Token 时间，将“有用”定义为用户在不看后续内容的情况下就能采取行动的首个数据块，然后观察直方图。TTFT 和 TTFUT 之间的差距，就是你的提示词在客套话上浪费的闲置时间。大多数团队没有测量它，因为流式 API 不会提供这个数据；你必须在应用层对其进行定义。