工具行为漂移：Schema 没变，语义却变了

你的契约测试通过了。Schema 校验器显示正常。工具返回的数据结构与上个季度完全一致。然而，面向用户的回答已经悄无声息地错了六个星期。

这就是契约测试从未设计用来捕捉的故障模式。契约测试验证的是传输格式没有改变——比如 search() 是否仍然返回 { results: [{ id, title, score }] }，create_event 是否仍然接受 ISO 8601 字符串，地理编码器是否仍然输出 { lat, lng }。它们无法捕捉到的是：搜索端点开始按新近度而非相关性排序的时刻；日历 API 在欧盟地区静默地将你 14:07 的开始时间吸附到 14:00；地理编码器在同一个模糊的多边形内选择了一个不同的点；或者作为工具的 LLM 分类器在稳定的端点后升级到了新模型，导致你的评估集从未采样过的某个类别中误报率上升了四个百分点。Schema 没变，但行为变了。你的智能体继续读取着代表通过的绿色勾选，并产生了没有任何错误日志捕捉到的退化答案。

这种模式在供应商关系中如此普遍，以至于它值得拥有自己的名字：工具行为漂移 (tool behavior drift)。对于 AI 智能体系统而言，它就像 API 行为变更之于传统的客户端-服务器系统——只不过智能体察觉和恢复的手段更少。一项关于静默工具故障的 2026 年研究发现，小型模型在检测工具是否返回了“正确的形状”但“错误的内容”方面表现尤为糟糕；它们信任结构并在其基础上进行推理。治理框架没有“后置条件”的概念，无法将“工具今天说的话”与“工具上周针对相同输入说的话”进行对比。因此，漂移不断累积，直到人类发现退化，并追溯每一个没有触发警报的层级。

你编写的契约与你依赖的契约

捕捉行为漂移的第一步是承认：Schema 并不是契约。Schema 只是契约的外壳 (envelope)。契约是你依赖工具所做的每一件事——包括那些因为看起来显而易见而从未写下来的事情。

搜索端点的契约不只是 returns: list of results。它的契约是：结果按与查询的相关性排序；查询 Q 的排名第一的结果在六个月内一直是 R；对于没有合理匹配的结果，查询返回空列表而不是字符串距离最接近的匹配项；分页令牌在至少 60 秒内保持稳定。你的提示词是针对这些特性进行调优的。你的评估集是针对这些特性进行评分的。你的下游工具选择——“如果排名第一的分数低于 0.4，则回退到另一条检索路径”——也是基于这些特性假设的。

供应商的发布日志会说新版本“改进了新鲜度信号”。你的 Schema 校验器会说没有任何变化。你的智能体将开始呈现更新但相关性更低的结果，你提示词中关于分数阈值的校准将悄然失效，你的下游回退触发频率会降低，回答质量将朝着你目前记录的任何指标都无法显示的维度漂移。

这是从业者在非 AI 系统中讨论了多年的差距。正如一位 PactFlow 工程师所言：“保持 Schema 不变的行为变更仍会破坏客户端——例如，如果一个列表端点静默切换到最终一致性，有时会丢失最新记录，即使 JSON 看起来没问题，许多客户端在生产工作流中也会崩溃。”智能体是我们交付过的对行为最敏感的客户端。它们基于内容进行推理，结构反而是最次要的。

不触发 Schema 测试的五种漂移模式

在生产环境中构建智能体系统的从业者反复被同样的几种模式所困扰。为它们命名很有帮助，因为每种模式都有不同的检测策略。

• 排序策略漂移 (Ranking-policy drift)：检索工具更改了其排名函数——纯相关性变为混合新鲜度，BM25 变为与向量重排序器混合，平局处理从按字母顺序变为按受欢迎程度。列表形状完全一致。列表内容发生了偏移。任何依赖排名第一稳定性的下游环节都会退化。
• 量化和舍入漂移 (Quantization and rounding drift)：日历 API 开始在某个区域将时间吸附到 15 分钟的边界。定价 API 从八位小数的浮点数切换到以分为单位的整数。地理编码器将坐标舍入到四位小数而不是六位。智能体的工具调用产生的值看起来正确，但存在细微偏差——直到它们撞上一个在意精度的系统。
• 作为工具的 LLM 模型漂移 (LLM-as-tool model drift)：这是最隐蔽的一种。供应商在稳定的端点后更换了模型——同样的名称，同样的 Schema，但权重变了。误报率移动了几个百分点。详细程度发生了变化。拒绝模式发生了偏移。你的评估套件从未采样过的一个类别出现了实质性退化。独立研究表明，91% 的生产环境 LLM 在部署后 90 天内会经历静默的行为漂移，从发生到收到第一个用户投诉，检测延迟平均为 14–18 天。
• 副作用漂移 (Side-effect drift)：一个“创建”调用现在默认还会发送一封通知邮件。一个“删除”调用现在变为 30 天窗口的软删除而非硬删除。一个“转录”调用现在还会生成智能体并未要求的摘要。响应形状未变，但响应所描述的世界中包含的效果或多或少发生了变化。
• 消歧漂移 (Disambiguation drift)：处理模糊输入（部分姓名、具有多个匹配地址的多边形、具有多种合理解释的查询）的工具更改了其选择“胜出者”的方式。地理编码器以前返回最大匹配多边形的质心；现在它返回最近编辑的那个。用户查询“Springfield”以前默认指向人口最多的城市；现在默认指向离用户最近的。你智能体的下游推理是针对旧的默认值进行调优的。

这些都不是 Schema 变更。但它们都会破坏智能体。

语义黄金追踪、行为变更日志与金丝雀套件

解决方案不是停止使用第三方工具，而是建立第二层监控，像契约测试监控结构（shape）那样监控行为。这类词汇在金丝雀分析（canary-analysis）文献中已经存在；只是需要将其应用于工具层面，而不是你自己的部署。

语义黄金追踪（Semantic golden traces） 是固定的查询/响应对，用于测试行为而非结构。针对每个工具，挑选 10–50 个输出稳定且已知的输入。“对于这个固定查询，排名第一的结果在六个月内一直是文档 D。”“对于这个固定地址，地理编码器返回的 (lat, lng) 精确到小数点后四位。”“对于这个固定提示词，分类器返回 category: A 且置信度高于 0.7。” 定期运行这些测试。与基准进行对比。当差异超过你针对自然噪声校准的范围时发出告警。这是契约测试在行为层面的对应物，它能捕捉到上一节中所有不改变传输格式的偏移模式。

行为变更日志（Behavior changelogs） 是团队针对每个工具订阅的信息流，其重视程度应等同于安全公告。包括供应商的发布说明、API 状态页面、模型卡修订历史，以及供应商提供的响应头中暴露的模型名称和量化指纹（如果供应商提供的话）。当供应商不发布变更日志时（许多供应商确实不发布，特别是针对由 LLM 支持的端点），你的黄金追踪就 成了 变更日志 —— 金丝雀套件的回归是行为发生变化的第一个信号，而你的事件响应则是通过供应商的沟通渠道去回填“发生了什么变化”的问题。

针对每个工具的金丝雀套件（Per-tool canary suites） 持续运行。生产环境金丝雀分析的模式可以直接应用：少量强相关的指标比大量弱相关的指标更有用。对于每个工具，挑选两到三个你的 Agent 下游推理真正依赖的属性，编写专门测试这些属性的探测器，并每小时运行一次。跟踪该指标。当它越过某个范围时，呼叫负责人。Google SRE 的金丝雀文献中明确指出：过于严格的阈值会导致误报，直到团队关闭告警；过于宽松的阈值则会让错误的发布蒙混过关。调优是一项实实在在的工作，它本身就是系统的一部分。

工具级熔断器（Tool-level circuit breakers） 是执行层。行为指标越过阈值与错误率越过阈值没有什么不同 —— 它应该像 5xx 错误率触发一样，将 Agent 切换到后备路径。其机制与任何熔断器相同：闭合 → 半开 → 断开，而驱动转换的指标是行为指标（误报率、排名第一的稳定性、输出长度分布），而非传输指标（HTTP 状态、超时）。生产级的 Agent 框架正开始提供这种原语 —— 网格中的每个 Agent 都有一个配置好的后备序列，当行为质量指标越过其范围时，路由器会降级主工具。

揭示工具偏移而非模型偏移的追踪

当 Agent 的质量下降时，团队的本能是责怪模型。模型是最显眼的组件，获得的关注最多，而且其供应商会发布显眼的升级。于是团队回滚提示词，对不同的模型版本进行 A/B 测试，运行评估套件 —— 结果一无所获。模型没有变。是工具变了。

这是耗费精力最多的失败模式，因为团队正在调试错误的层级。架构上的修复方案是独立于模型层面对工具层面进行埋点。每次工具调用都会获得一个追踪跨度（trace span），其中包含完整的输入、完整的输出、工具报告的版本（如果有），以及响应的哈希值，以便你与黄金追踪基准进行对比。当发生回归时，你打开的第一个仪表盘不是“随时间变化的模型行为”，而是“随时间变化的工具行为，按工具、按输入类别划分”。发生偏移的工具会在其黄金追踪差异率中显示为阶跃函数；而模型如果没有变化，则会保持平顺。

更深层的认识是，你的提示词是与工具的行为共同调优的，而不仅仅是与模型的行为。一个写着“总结排名第一的结果”的提示词，隐含地假设了排名第一的结果就是你想要总结的内容。当排名发生变化时，提示词突然就错了，即使提示词的文本没有任何改变。从业者越来越将“系统提示词”视为 Agent 上下文中所有塑造其输出的内容 —— 而工具的行为，由于嵌入在它返回的响应中，也是该上下文的一部分。请据此进行监控。

规范化运作后的样子

一个处理得当的团队会有一些明显的习惯。每个外部工具都有一个负责人 —— 一名工程师或一个子团队负责其行为健康，就像每个数据库表都有负责人一样。负责人维护黄金追踪集，监控金丝雀，并在行为指标越过范围时收到告警。团队针对“生产环境 Agent 回归”的运行手册首先写着“在触碰模型之前先检查工具仪表盘”。与供应商的关系包括行为变更频道 —— Slack connect、邮件列表或专门的联系人 —— 而不仅仅是在停机时才触发的状态页面。

当团队添加新工具时，集成检查清单包括“除了模式（schema）之外，这里的行为契约是什么？” —— 答案在工具随 Agent 发布前就被捕捉为一组探测器。这些探测器与提示词和评估集一起进行版本管理，并保持相同的发布节奏。行为偏移是一个预料之中的事件类别，而不是在复盘中才被解释的意外。

只监控模式的团队只监控了一半的契约。他们没关注的那一半，正是 2026 年代工具层面不断变化的那一半 —— 因为提供这些工具的供应商本身也在发布机器学习系统，而他们唯一能承诺保持稳定的只有传输格式。语义才是产品，而产品正在迭代。你 Agent 的可靠性取决于你的监控是否能在你的用户发现之前察觉到这种迭代。