延迟感知工具选择:当“当下的足够好”优于“未来的最出色”
你智能体系统提示词中的工具描述是一个六个月前的评估产物(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 秒的最新工具。
这些并不是罕见的信号。你的平台已经收集了所有这些数据——它们存在于驱动值班人员查看的延迟仪表盘的指标后端中。工作重点不在于生成信号,而在于将其接入规划器做出路由决策的地方,即提示词中。
