在事故复盘报告中，最昂贵的代码行反而是没人写出的那一行：一个字段缺失的 200 OK。原本应该将难题上报（Escalate）给更强模型的路由，在整整六周的时间里上报的流量为零。成本看板在欢庆，质量看板却在下滑——但仅限于那组被现有评估集低估的难题切片。直到客户投诉系统以前能正确处理的特定问题时，一切看起来都还像是场胜利。
起因是协议栈上层的一个响应结构变化。供应商的中级方案取消了逐 Token 的 logprobs，这在发行说明中被称作“特定层级的特性对等调整”。客户端收到的仍是有效的 JSON，HTTP 状态码依然是 200，响应中的模型标识符与请求中的模型标识符也完全匹配。唯一的变化是，路由用来做上报决策的字段消失了，而一年前在一次事故中添加的防御性默认设置，悄然变成了每个请求的生产环境默认行为。
你智能体系统提示词中的工具描述是一个六个月前的评估产物（eval artifact）。它说 search_pricing 返回“带有结构化定价的最新库存数据”，规划器（planner）对此深信不疑，因为自描述调优的那天起，提示词中的任何内容都没有更新过。而实际上，在过去的 40 分钟里，search_pricing 端点的 p95 延迟一直保持在 11 秒，因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具，只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing，因为描述读起来仍和评估时一样，且规划器没有任何关于目前调用这两个工具成本的信号。
这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题，而等待成本正是你的提示词模板所看不见的东西。
大多数团队通过在系统提示词中加入一句话来处理弃权（abstention）问题：“如果你不确定，就说你不知道。”模型偶尔会遵守，但经常不遵守，而且这种失败模式是不对称的。一个自信的错误答案会以全速发布——它直接落入用户手中，在 Slack 讨论串中被引用，在下游摘要中被采纳。而一个诚实的弃权则会触发客户成功（CS）升级，因为用户期望智能体处理请求，而现在必须有人解释为什么它没有处理。六个月后，团队已经了解到哪种失败的发布成本更低，而那个名义上控制弃权的系统提示词修改，已经被悄悄地调整为倾向于顺从，而非诚实。
解决这个问题的准则不是寻找更好的措辞。而是要认识到，弃权是一个路由决策，而不是一种提示词模式。它理应拥有一个一等公民级别的输出通道、自己的 SLO、自己的评估套件，以及在系统拓扑中的独立位置——位于提示词之外，可以被测试、维护和扩展。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
