给 Agent 数据源加上质量契约

API 返回 200、JSON 结构校验通过，Agent 仍可能拿到一批无法支撑报告的数据。dev.to 上的一篇文章提出，给数据源增加「质量契约」，检查字段是否可用、数据是否及时、记录是否足够，以及取值是否异常趋同。作者还做了工具 driftprobe，把这些检查接入自动化流程。

目前能确认什么

原文给出的故障示例是：50 个商品中，42 个的 price 变成 null，updated_at 数月未更新，但接口仍正常响应。Agent 继续生成报告，状态码监控和结构检查都没有发现问题。

原因并不复杂：HTTP 状态码描述请求处理结果，JSON Schema 约束数据结构；字段存在，不代表字段里的内容能满足业务需求。

driftprobe 从消费方定义四类检查：

• 覆盖率：有多少记录包含可用字段，null、空字符串、空数组和空对象不计入。
• 时效性：检查最新的 updated_at 距今多久。
• 数量：列表是否达到最低记录数。
• 取值差异：识别整列都变成同一个值的情况。

作者通过本地代理观察真实调用，再学习生成契约，并称只存储结构、不存储具体值。检查失败会返回退出码 1，可让 CI 失败；工具也支持 MCP 调用。

我的判断

数据结构合法，不能替代业务数据可用。

对程序员来说，最直接的用途是在数据进入 Agent 报告流程前检查关键依赖。例如，价格比较需要足够多的有效价格，仅检查 price 字段存在远远不够。

不过，自动学到的契约也可能把已有坏数据当成基线，业务阈值仍需要人工确认。原文还说明，目前要手动指定 Agent 实际读取的字段。

它能发现数据缺失、陈旧或异常趋同，不能证明数据真实。

还有两个边界需要后续确认：单看最新更新时间，能否覆盖列表中大量旧记录的问题；检查失败后，怎样接入 Agent 的停止生成或降级流程。作者正在开展持续观测，目前不能据此判断这类故障有多普遍。