当一个符合性检查器在真实答案为“否”时却回答“是”，这比根本没有检查器更糟糕。正是这一担忧塑造了我一直在为统一商务协议构建的一个小型开源副项目——这是一种开放式的、基于智能体的电子商务标准，旨在让人工智能代理发现商品并与商家完成结账流程。
这是一个非官方的独立项目。它尚处于早期阶段，尚未覆盖所有内容，也从不声称服务器已“获得认证”。我分享它主要是因为其背后的理念——让每次检查都证明其具备失败的能力——被证明比我预期的更有用，而且我真诚地希望得到反馈（包括“你这里搞错了”这样的意见）。
担忧：无法失败的检查
大多数快速符合性检查归结为“收到状态码 200，看起来没问题”。如果服务器实际上已损坏，但检查从未失败，那么这就不是检查——而是装饰，而且很危险，因为它会给你一种虚假的信心。
因此，我试图让工具遵循一条规则：
除非我证明了当服务器出错时该检查会失败，否则不会发布任何检查项。
每项检查如何赢得信任
每项检查都锚定在我未亲自编写的内容上：
- 失效测试。对于每项检查，我会注入它旨在捕获的特定缺陷——删除必填字段、翻转状态码、破坏主体内容。如果检查仍然通过，则存在误报风险，并被禁止发布。只有当检查捕获了其自身注入的错误并且在已知良好的服务器上干净地通过时，才会发布该检查项。
-
以官方模式验证器作为权威标准。与其手动编写 JSON 模式逻辑（这是细微差异的经典来源），不如调用官方
ucp-schema验证器，因此载荷是根据规范自身的模式进行评判的——而不是根据我对它们的解读。 - 规范引用。每项检查都指向固定版本规范中的特定规范性条款，因此结果是可以追溯的，而不是要求人们“相信我”。
整个套件还在持续集成环境中测试自身——如果任何检查失去了捕获其对应缺陷的能力，构建状态就会变红（失败）。
发现的问题（需要注意的是，我可能遗漏了某些背景信息）
针对实际实现进行测试时，有几件事引人注目。我将这些表述为“这是我的观察结果”，而非指责：
- 官方 Node.js 参考示例似乎将
capabilities作为 JSON 数组提供，将services.<name>作为对象提供，而固定的 2026 年版配置文件模式似乎分别要求使用带键的对象和数组。Python 参考服务器和一个实时的 Shopify 生产商店都使用了符合模式结构的形式，这让我认为这是一种真正的偏差，而非规范歧义——但我已向上游提交了包含复现步骤的问题报告，以防我误读了某些内容。 - 它标记出了一些参考实现中的缺失，而不是静默通过（例如，错误主体使用
{detail, code}而非规范中更完整的封装结构；规范与官方测试套件之间在版本协商状态码上的差异）。
这些都不是对统一商务协议项目的批评——该规范确实很好，示例也很有用。揭示此类偏差正是符合性工具的用途所在。
