跳转到主要内容

延迟感知工具选择:当“当下的足够好”优于“未来的最出色”

阅读需 1 分钟Tian PanTian Pan

你智能体系统提示词中的工具描述是一个六个月前的评估产物(eval artifact)。它说 search_pricing 返回“带有结构化定价的最新库存数据”,规划器(planner)对此深信不疑,因为自描述调优的那天起,提示词中的任何内容都没有更新过。而实际上,在过去的 40 分钟里,search_pricing 端点的 p95 延迟一直保持在 11 秒,因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具,只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing,因为描述读起来仍和评估时一样,且规划器没有任何关于目前调用这两个工具成本的信号。

这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题,而等待成本正是你的提示词模板所看不见的东西。

静态描述问题

2026 年典型的工具描述看起来就像《构建高效智能体》(Building Effective Agents)及类似入门教材中所写的那样:一个名称、一段功能简介、一个参数 Schema,可能还有一条关于何时优于同类工具的注释。这些描述在你发布时就被锁定了,而证明智能体能选择正确工具的评估套件也同时被锁定了。两者都是针对工具行为与描述相符的世界进行调优的。

世界在变迁。search_pricing 那 11 秒的 p95 延迟不在描述中。地理编码供应商迁移区域后 lookup_address 出现的 4% 错误率激增不在描述中。上游系统 Schema 变更后缓存命中率从 92% 降至 71% 也不在描述中。规划器读取的是评估时的真实情况,选择了评估所奖励的工具,并支付了评估从未衡量过的运行时成本。

生产环境中的工具选择 Bug 几乎从未表现为“智能体选错了工具”。它们通常表现为“智能体选择了一个合理的工具,但该工具今天正好状况不佳”。评估套件仍然能通过提示词测试,因为评估是用描述中声明的行为来模拟(mock)工具的。用户体验却是本应 400 毫秒完成的轮次变成了 14 秒。

这与破坏长期运行智能体的“指令衰减”(instruction-decay)模式相同,只是被压缩到了单次轮次中。描述在其整个生命周期内平均来看是正确的,但在你今天 14:23 发起的特定调用中是错误的。

等待成本是路由信号,而非工具属性

值得采用的心理模型是:工具成本是一个随时间变化的信号,而不是一个静态属性。规划器需要该信号“现在”的值,而不是六个月前调优描述时使用的值。

在实践中起作用的信号包括:

  • 当前 p95 延迟:过去 1–5 分钟的数值。不是历史平均值,而是最近的百分位值,因为这是下一次调用将要支付的成本。
  • 近期错误率:限定在同一时间窗口内。过去一分钟 30% 的错误率就是一个路由信号,即使历史错误率只有 0.4%。
  • 熔断器状态:如果工具的电路处于半开或开启状态,规划器应该知道——调用它不仅慢,还可能被刻意拦截。
  • 剩余配额 / 预算:当一个工具有限流容量而同类工具没有时非常有用。近期研究中的“预算追踪器”(Budget Tracker)模式将剩余预算显现到智能体的推理循环中,并持续提升了不同模型的准确性。
  • 缓存新鲜度(如果相关):一个拥有 30 秒前答案的缓存工具,通常严格优于一个延迟为 9 秒的最新工具。

这些并不是罕见的信号。你的平台已经收集了所有这些数据——它们存在于驱动值班人员查看的延迟仪表盘的指标后端中。工作重点不在于生成信号,而在于将其接入规划器做出路由决策的地方,即提示词中。

当“现在够用”优于“稍后最佳”

一旦你开始衡量这些指标,就会出现三种具体的失败模式。

带尾部限制 SLO 的流式对话。 智能体对首个数据块有 6 秒的预算,对完整响应有 12 秒的预算。一个在 9 秒内返回完美答案的“最佳”工具违反了 SLO;而一个在 1.5 秒内返回 95% 效果答案的“还不错”的工具则没有违反。针对工具正确性进行优化的规划器,实际上是在针对错误的目标进行优化。用户看到的是超时,而不是更好的答案。

语音智能体。 插话窗口(barge-in window)大约为 800 毫秒。任何 p95 超过 600 毫秒的工具在语音路径上功能性不可用,即使它是目录中最准确的选择。规划器需要知道,提示词要求首选的工具由于这种模式下的物理限制实际上是被取消资格的。

事务背后的同步流。 结账时的欺诈检查需要在支付意向过期前获得结果。如果主要的欺诈评分工具今天很慢,系统需要立即获得回退启发式结果,而不是最终获得权威评分。等待“最佳”工具的成本是订单流失,而评估套件从未对这一成本进行定价。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 9 分钟

工具延迟尾部:为什么 p99 重塑了智能体架构而 p50 掩盖了问题

基于单个工具中位数构建的智能体延迟预算在生产环境中会悄无声息地失效:经过 7 个步骤后,尾部延迟开始占据主导地位,导致尽管单个工具的仪表盘显示为绿色,用户却仍在等待。本文将深入探讨为什么 p99 会重塑智能体架构,相关的工程规范是什么样的,以及哪些具有 40 年历史的分布式系统技术可以直接应用。

insider
ai-agents
阅读需 9 分钟

串行工具调用瀑布:Agent循环中隐藏的延迟税

Agent框架默认串行执行工具调用,即使这些调用在逻辑上相互独立,造成与N+1查询问题如出一辙的延迟级联。本文介绍如何识别并修复这一问题。

insider
ai-agents
阅读需 12 分钟

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

将 200 毫秒的搜索调用换成 4 秒的 Agent 循环,延迟预算并没有消失 —— 它从基础设施迁移到了 UX。如果团队没有捕捉到这种交接,就会在交付一个指标更好但实际体验更差的产品。

insider
ai-agents
阅读需 10 分钟

那个本该计算却随口编造数字的智能体

LLM 智能体往往会随口说出一个看似合理的数字,而不是去进行计算,流畅的文字掩盖了缺失的工具调用。本文探讨如何强制使用工具并为每一个数据附上出处。

insider
ai-agents
阅读需 10 分钟

生产级智能体的 90 秒冷启动:当 LLM 不再是瓶颈时

生产级智能体在模型运行之前,通常需要 60 到 120 秒进行冷启动。解决方案不在于更快的 TTFT — 而在于将冷启动延迟视为一级 SLO,并通过预热池、快照/恢复、工具延迟加载以及 CI 门禁来进行优化。

insider
ai-agents