2 篇博文 含有标签「schema-drift」

一名后端工程师将参数从 user_id 重命名为 account_id，因为两者在半年前就不再是同一个东西了，而且一个支持工单终于让这种歧义变得无法忍受。JSON schema 在发布重命名的 pull request 中得到了更新。该工具的文本描述——即模型实际阅读以决定是否调用该工具以及如何调用的那个段落——却存在于另一个代码库中，由另一个团队负责，通过工单队列更新，并且仍然写着“传递 user_id 以查找账户”。没有人标记出这一点。模型尽职尽责地使用正确的 schema 调用工具，填充正确的字段，并在每一个快乐路径（happy-path）查询中获得正确答案。这个 bug 是隐形的，直到有一天用户输入的内容中，他们经过身份验证的 user_id 与他们询问的 account_id 是两个不同的实体，而智能体自信地返回了别人的数据。

一个下游搜索服务在周二下午发布了 v2.3.2 版本。发布说明提到重命名了一个状态字段，新增了一个可为空的 confidence 值，并重新排列了结果包中的数组。CHANGELOG 中没有任何内容被标记为破坏性变更。提供商自家的客户端库通过一个小版本更新消化了这些变化。你团队的 HTTP 集成通常会在一小时内记录下反序列化错误。但你的智能体——那个通过该搜索工具路由客户问题的智能体——并没有报错。它继续回答。问题依然得到解决。仪表盘依然是一片绿色。

六周后，有人注意到“缺货”回复在查询中的比例从 2% 攀升到了 11%。根本原因是 v2.3.2 的升级。重命名后的状态字符串从 in_stock 变为 available，而智能体——作为一个对文本进行灵活推理而非严格遵守模式（schema）的客户端——将旧令牌（token）的缺失解读为“无货”，然后将这一发现组织成乐于助人、语气自信但内容错误的客户消息。契约回归在消费者端被吸收了，而那里没有任何测试套件在监控。

这是传统的 API 规范（hygiene）从未被设计用来捕捉的故障模式。严格的客户端会大声报错。智能体则静默失效。你越是将智能体当作普通的 HTTP 消费者对待，这类 Bug 隐藏在看似正常的指标中的时间就越长。