Marico's space
最近把市面上的 Agent 间通信协议翻了个底朝天，想找个客观的评估维度，结果发现所有对比文章都是软文式的叙事——协议 A 强调发现能力，协议 B 任务模型更丰富，都很有前景，还需要更多工作。确实有几篇综述做得不错，但看完还是不知道该信谁。
所以自己动手整了一个评估框架。十个维度，每个维度有序数级别，每个级别锚定的是规范文档里能找到的具体属性，而不是"质量好不好"这种主观判断。然后把这十三份规范从头到尾读了一遍，对其中八份做了完整评分。八十个评分格子，每个都附上规范原文里对应的句子。
锚定属性的好处是让评分不再是个人意见。如果你觉得 A2A 在授权这个维度不该只有一级，你不是在挑战我们的品味，而是在说某个具体条款存在——这个争议是可以坐下来对着原文掰扯清楚的。
第三个维度问的是授权怎么传递。Agent A 代表用户 P 让 Agent B 干活，B 能拿出证据证明 P 真的授权了吗？
级别从 0 到 3。一级是 OAuth scope 或者 token 转发：A 直接把自己的 token 交给 B。二级是有签名能力声明，明确的 scope、audience、时间范围，绑定两个具名参与者。三级是链条，每个跳点的授权都能被没有见证过授权过程的第三方独立验证。
三级是空的。不是稀疏，是完全没有。
八份协议参与评分。授权维度的最高级别没有任何参与者。
八份协议里，四份在一级，四份在二级。没有一份定义了可被第三方验证的委托链。每份协议都把具体实现方案推给了"上层身份架构"——这是规范层面的说法，翻译成人话就是"谁爱管谁管"。
有意思的是，商业支付类协议确实达到了三级。它们能实现意图、授权、回执全套，是因为支付授权根本不可能用别的方式。这说明业界在另一个层面确实有可用的方案——只不过那个层面只处理钱的事。
我们原本想找反例，毕竟这是个全局性结论，值得认真挑战。最好的候选是 ACNBP。它威胁覆盖最广，十二类里覆盖了十类，而 A2A 和 MCP 各只覆盖一类。它还有个 Capability Binding（能力绑定）仪式，是我们读过的所有规范里最严格的两方单跳机制。但它依然只能绑定恰好两方。主要作者确认这是设计意图——这种坦诚反而让结论更有说服力。单跳的严谨不等于可传递的授权，这是两码事，评估框架必须分开处理，否则根本看不到这个空白。
因为生产环境不会等规范完善。企业需要委托机制今天就能跑，所以只能转发 token。安全研究界早就量化过这个代价。
AgentLeak 基准测试那个数字让我们重新审视了整个问题。Agent 间消息泄露个人信息内容的比例是 68.8%。输出通道——那个大家都在审计的通道——泄露率是 27.2%。只看输出的审计会漏掉大约 41.7% 的违规。
所以这个差距是规范层面的疏漏，却有实测的部署层代价。这比"授权还需要更多工作"这种废话可操作多了。如果让我列下一个标准化周期的优先事项，这件事排第一。
我们原本以为评分强度和 adoption（采用率）至少有点相关性。并没有，反而是负相关。
评分最高的两份协议，ACNBP 24 分和 LOKA 23 分，能追溯到的部署规模最小。部署规模最大的两份，A2A 14 分和 MCP 10 分，评分反而一般。A2A 和 MCP 各只在十二类威胁中覆盖了一类，还是规范层面的。
真正预测采用率的是制度位置：基金会的背书、厂商的支持、生态系统的加持。规范层面的技术严谨性基本预测不了什么。
我们把这个当作发现而不是抱怨，是因为它对做这个方向工作的人有实际影响。影响力最大的技术贡献，是那个有制度位置去推动落地的。这说明应该在 AAIF 和 W3C 轨道内工作，而不是在旁边旁观。我们也是这么做的。
这个领域最被热议的对决根本不是对决。MCP 是工具绑定协议，A2A 是点对点消息协议，根本不在同一个分类层级。生产环境里它们是组合关系，不是替代关系。
评估框架最推荐的技术组合根本没被部署：ANP 的身份层做底座，A2A 的任务层做上层。ANP 在身份维度领先，用的是去中心化身份标识（DID，可验证凭证）。A2A 在任务维度领先。没有任何一份被评估的协议同时具备已部署的任务模型和去中心化身份模型。
这里说的是具体的身份层。ANP 的 DID 机制不依赖它整个技术栈的其他部分。但它的描述和发现协议是另一回事：它们和 A2A 的 AgentCard 重叠，属于竞争关系而不是上下堆叠。这个区别只有在各维度分别评分后才能看清楚。给每份协议打一个总分反而会把这个信息藏起来。
每个分数都是一个人的阅读理解。我们没有评分者间一致性统计，而且在摘要里就说了，不是在局限段落里藏着。
我们提供的是可审计性。评分存在一个 YAML 文件里，每个格子都有证据字符串和引用。每个表格和图都是程序从这个文件生成的，所以表格不可能和背后的数据脱节。你可以不同意某个格子，然后准确指出不同意哪一点。
十三份协议里有五份做了调研但没评分。都是商业结算类，十个维度里六个没有参照物。结算信封没有任务模型，也没有多模态内容处理。给其中一份评了而其他保持未评，会因为范围原因而不是实质原因移动平均值。UCP 是个有意思的案例：它可以给出一个站得住脚的分数，但我们还是没评。
规范本身的版本迭代也比审稿周期快。所以调研在第一页声明了 2026-Q1 截止日期，每个结论都精确到具体版本和 commit。这种精确不是书呆子做法。我们读到的一份协议发布了两套 tag，声称同一个版本号，相差几千行。
我们针对发现的空白提了三个扩展：工作区命名方案、上下文选择信封、出口证明信封。以为三个是独立的。
结果发现它们是同一张凳子的三条腿。防护信封没有规范的工作区名称，就得自己发明一套重复的命名标准。上下文选择信封没有边界概念，就没有东西可以挂策略。命名方案两者都没有，就只有范围没有执行。
这说明为什么评估框架的维度不能独立处理。身份、授权、安全在任何一个跨组织边界的部署里都是同一个问题戴着三顶帽子。三个扩展都是下一个修订周期的草案，不是已经验证的标准——与其吹过头，不如说清楚。
原文链接已删。如果发现某个格子有问题，欢迎直接指出。已经有好几个格子通过这种方式修正了，包括一个因为主要作者告诉我们评分过于慷慨而降分的。