Proof上线x401：企业Agent接入前，怎样核对协议版本？

Proof在10月15日09:00美国东部时间发布公告，宣布身份钱包、开放HTTP协议x401及生产MCP服务可用。公告描述，接收请求的网站可索取身份凭证，并通过其方案检查用户对特定交易条款的签署。这是厂商发布的能力说明，本站没有对产品进行实测。

本次事件日期和公告发布日期均为10月15日；来源核验日期为10月16日。当前规范页面标注Draft 0.2.0，旧版页面标注Draft 0.1.0，产品页仍以0.1.0展示。规范页没有给出0.2.0的发布日期，因此不能把它说成10月15日刚升级的版本。

适合关注这条消息的是正在连接外部Agent、凭证管理器或需要属性证明的业务接口团队。普通内部知识问答未必需要增加这套协议。实际支持的凭证、发行方、客户端和部署版本，应向对接方逐项确认；公告中的兼容助手名单不能代替自己的集成验收。

这里的验证方，是保护资源并决定接受何种证明的服务。凭证管理器可以是钱包或持有凭证的服务。两版差异同时涉及消息方向和请求结构，不能在网关里把旧字段重命名，就宣称完成升级。

下面的方法是本站接入建议：先选双方共同支持的一版，记录规范地址、读取日期、服务与客户端版本。若需兼容两版，分别解析、校验和测试；未知版本停止证明分支并返回可诊断错误，不让模型推测字段含义。

0.2草案把凭证请求的组合交给验证方，Agent可调用凭证管理器，也可转交受支持的远程服务获取结果。Agent不得修改credential_requirements的条目。签名请求是规范推荐的模式；验证方仍负责检查结果绑定、凭证状态和发行方信任。

本站建议把协议解析放在确定性的客户端或服务层。模型可向用户解释缺少哪类证明，但不负责改写凭证条件、选择一个更宽松的发行方或生成“已证明”标记。获取到结果后交回原受保护路由，由验证方判定是否满足。

以下为本站虚构教学：Agent读取供应商Q-204的报价摘要，附加规格资料仅供满足合作伙伴资格要求的调用方取得。服务可以返回公开摘要，同时用PROOF-REQUEST说明受限内容所需的证明。HTTP 200下仍可存在这种要求；不能把可用的公开摘要丢弃，也不能声称尚未取得的附件已经读到。

先在隔离环境约定正常期望：公开摘要可显示；受限资料处于待证明状态。用户通过测试凭证管理器提供结果，验证方接受后才取得附加资料。若只用固定JSON模拟结果，演练仅覆盖解析与流程，不能据此声称密码学验证或真实凭证互通已经通过。

消息从业务服务到Agent，可能经过反向代理、SDK和浏览器。本站建议用同一脱敏请求关联号，对照原始响应头与客户端实际读到的头。浏览器跨域调用还需核对CORS是否允许发送、读取对应proof头；命令行能读到，并不能证明浏览器也读得到。

不要把证明信息放进自然语言正文来补救丢头。这样会让协议处理依赖模型阅读，也掩盖基础链路问题。若只是公开页面，不支持x401，客户端应按该站实际能力处理，不能把任意401都解释成x401挑战。

重试应有次数和截止条件。重复收到同一个无法满足的要求时，说明缺失组件或凭证条件并停止。认证已失效、协议不兼容、证明被拒绝要指向不同负责人，反复要求用户重新登录无法修复字段或版本不匹配。

Proof的产品公告描述了签署具体交易条款的能力；x401基础草案的职责是传递并验证路由所需的证明，另有可组合的调用方绑定或委托机制。不能据此推断每个x401响应天然包含当前商品、数量、收件对象的批准。需要这些约束的业务，应确认实际使用的方案到底覆盖哪些字段。

在Q-204演练中，取得合作伙伴规格资料只表示这次读请求满足相应条件。后续创建采购单，应走企业已有对象权限、候选参数确认和写入结果核验。本文不提供真实支付接入或法律效力判断。

证明与付款在规范中分别处理。若部署另外要求付款，应检查对应支付协议和业务结果，不能拿凭证结果当付款凭据，也不能拿付款成功当身份证明。

对已经接入旧版的团队，先确认现有服务端版本，再评估迁移范围。不要仅因latest页面变化就替换生产请求头。将本次对照和六个演练加入已有集成验收，记录尚未验证的环节、负责人及处理时间。