ANP 消息协议重大升级：专为智能体协作而设计的协议

最近，我们对 ANP 消息协议进行了重大调整。我们还在社区会议中分享了此次升级背后的思考。本文将系统地解释这些变化。

首先，让我们从高层回答几个关键问题。更详细的技术总结将在文章后半部分展开。如果你对整体思路感兴趣，阅读下面的部分就足够了；如果你想了解技术细节，请继续阅读。

• 为什么我们需要协议？

我在之前的文章中多次讨论过这个问题。用一句话概括：未来的智能体不仅会在单个组织内部协作，还会在互联网的跨领域环境中协作。协议是传递上下文最高效的方式，尤其是在开放的互联网上。

• 为什么我们需要新协议？

在消息传递方面，已经有许多现有协议，如 XMPP、Matrix 和电子邮件。为什么还要设计一个新协议？

最重要的原因是，大多数现有协议都是为人机交互的即时通讯（IM）或电子邮件系统设计的，且大多数都将身份与通信紧密耦合。在智能体场景中，身份不仅用于通信，还必须支持支付、交易、授权以及许多其他活动。

因此，我们需要一个原生于智能体的协议。与其他方案相比，ANP 将身份与业务逻辑保持更松散的耦合。

• 为什么不使用基于 DID 且同样将身份与通信分离的 DIDComm？

在设计早期阶段，我们研究过 DIDComm。DIDComm 是一个基于 DID 的通用安全消息框架；它不是一个完整的即时通讯协议。它更像是一个“安全消息信封 + 路由 + 上层协议载体”，而非聊天系统。

此外，它缺乏群组等核心 IM 概念。

• 这次升级主要解决了什么问题？

这次升级花费了一些时间，但非常值得。主要改进包括：

• 更强的安全性。 签名现在采用 RFC 9421 和 RFC 9530 以加强安全性，并采用更标准化的身份验证方法。

• 更强的跨域能力。 之前的设计在跨域协作方面仍有不足。例如，我们如何从密码学上证明消息确实来自特定用户，而不是由服务器构造的？新设计利用证明机制，确保跨域流程中的每一步都是安全的。

• 更强的端到端加密（E2EE）。 我们一直非常重视端到端加密。这也是全球关注的重点；例如，Elon Musk 的 XChat 的头号功能之一就是端到端加密。在此次升级中，私聊的 E2EE 对齐了 Signal 风格的方法，而群聊则使用 IETF MLS。将 MLS 与 DID 结合，解决了以往群聊 E2EE 设计的许多不足，例如成员变更的复杂性。

• 支持文件传输及文件 E2EE。 上一版本对文件的支持较弱。此版本提供了全面的文件支持，包括私聊和群聊中的文件、文件安全考量以及文件的端到端加密。

• 更灵活的消息信封。 消息使用 JSON-RPC 2.0 进行封装。JSON-RPC 2.0 作为消息信封非常灵活，因此我们直接复用。

• 这次升级未包含什么？

• 未包含多设备支持。 Matrix 和 Signal 拥有强大的多设备支持，但我们在此次升级中未在协议层面添加该功能。我们认为 ANP 定位为一个跨域互操作协议。智能体拥有多少设备是域内事务，不应向其他域暴露复杂性。换句话说，当我向另一个域的智能体发送消息时，该智能体是在一台设备上接收还是在多台设备上接收是其内部事务。我不需要关心。这降低了整体协议复杂性，并为实现提供了更多灵活性。否则，协议将变得极其复杂。

• 架构目前仅支持中继转发。 这是什么意思？如果一个智能体希望与另一个平台上的智能体交换消息，它需要有自己的消息服务；它不直接向对方智能体发送消息。从技术上讲，智能体到智能体的直接消息传递是可能的。这次未包含它主要是因为我相信主流架构将是智能体连接到附近的消息服务，而这些消息服务提供中继能力。这种架构也能提供最佳的服务质量（QoS）。

• 升级过程中最大的惊喜是什么？

DID 确实非常有用。我们将 DID 身份不仅应用于智能体，还应用于群组和服务。这完美解决了多方流程中复杂的身份、权限和凭证问题。

最后，如果你对这项技术感兴趣，我们将在明天的社区会议（5月14日）上再次介绍此次升级。欢迎加入讨论并提供贡献。

以下是详细的协议升级说明。你可以继续阅读，或直接访问原始技术文档：

• did:wba 方法规范: https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/03-did-wba-method-design-specification.md

• 基于 DID:WBA 的命名空间规范: https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/04-anp-did-wba-name-space-specification.md

• 即时通讯规范: https://github.com/agent-network-protocol/AgentNetworkProtocol/tree/main/message

摘要

本次协议升级的重点不是对小幅度修补旧规范。相反，它将“身份认证”和“即时通讯”从“可用”提升到“更标准化、更可验证、更适合跨域互操作”的水平。

在身份方面，新的 did:wba 不再仅仅是“基于 DID 的请求签名”。它进一步引入了基于路径的 DID 与绑定公钥指纹之间的强绑定、DID 文档的顶层完整性证明、基于 RFC 9421 的 HTTP 消息签名以及基于 RFC 9530 的 Content-Digest。这些机制共同连接了四个层面：DID、密钥、文档和请求。

在消息方面，新的 ANP 不再使用一个巨大的单体规范来承载所有语义。它被拆分为八个配置档案：核心绑定、身份与发现、私聊基础语义、群聊基础语义、私聊 E2EE、群聊 E2EE、附件与对象传输、联邦/跨域通信。因此，业务语义、安全语义、对象传输和跨域调用被解耦，同时仍能通过统一的绑定层重新组合。

简而言之，新设计的价值在于：身份更加可信，消息更加分层，加密更加标准化，跨域协作在工程实践中真正可部署。

一、为什么继续升级？

之前的 did:wba 和即时通讯协议已经经历了一次重要升级。之前的身份方案已将 DID 引入跨平台认证。之前的即时通讯协议也从早期的 WebSocket 路由和交互握手演变为基于 JSON-RPC 2.0 的消息格式、基于 HPKE 的私聊 E2EE 和基于 Sender Key 的群聊 E2EE。换句话说，之前的设计并不原始；它已经解决了让智能体聊天和加密消息的核心问题。

然而，随着协议进一步迈向跨域互联、群治理、附件传输、联邦服务调用和长期标准化，之前的设计开始暴露出新瓶颈：

• 身份认证不够标准化，绑定不够强。 之前的 did:wba 已经可以进行签名认证，但 DID 路径与绑定的公钥之间没有默认的强绑定。请求签名仍使用自定义的 Authorization: DIDWba ... 头。顶层 DID 文档证明、现代 TLS 服务身份验证规则和标准化的挑战机制仍不完善。

• 消息协议仍然过于单体化。 之前的即时通讯规范将消息格式、传输绑定、E2EE、群组、接口示例等功能放在一个文档中。这虽然便于上手，但随着协议的持续发展，其边界变得日益模糊。

• 群组、附件和联邦等复杂场景需要更清晰的抽象层。 之前的群聊 E2EE 使用 Sender Key + 纪元轮换。它有效，但在大群组可扩展性、标准化、与群组状态的绑定以及见证群组结果方面仍有改进空间。对象传输和联邦跨域通信也未分离为清晰独立的能力层。

因此，新设计并非推翻旧设计。它在此基础上延续，并向可长期维护的协议栈演进。

二、新的身份认证：从“能签名”到“强绑定、强验证、强互操作性”

2.1 新 did:wba 的整体思路

新 did:wba 的核心目标是让 DID 回答不仅仅是“我在哪里找到文档？”它还必须回答以下问题：

• 此 DID 实际绑定的是哪个密钥？

• 此 DID 文档是否被平台静默替换？

• 此请求是否由对应 DID 的私钥持有者发起？

• 服务器是否可以在不增加额外往返次数的情况下完成标准化验证？

围绕这些问题，新的 did:wba 引入了四层设计：

• DID 层：基于路径的 DID 默认携带绑定的公钥指纹。

• 文档层：e1_ 基于路径的 DID 需要 DID 文档中的顶层证明。

• 请求层：请求使用 Signature-Input / Signature / Content-Digest 进行签名。

• 会话层：认证成功后，通过 Authentication-Info 返回访问令牌。

2.2 基于路径的 DID 默认引入 e1_ 绑定公钥指纹

新 did:wba 中最大的结构变化是新创建的基于路径的 DID的默认设计：DID 路径的最后一段必须是一个 e1_ 绑定公钥指纹。这不仅仅是“添加后缀”；它使 DID 本身直接携带与绑定公钥相关的可验证语义。

这带来了三个直接好处：

• DID 与用户持有密钥之间的强绑定

• 降低平台静默替换身份公钥的风险

• 身份轮换的界限更清晰，稳定名称委托给 Handle / WNS

新主规范中的默认配置是 e1_，这意味着 Ed25519。同时，k1_ 兼容性扩展仍保留在附录中，以支持 secp256k1 生态系统。这意味着新设计的主路径强调标准化和长期互操作性，同时不会突然放弃对现有生态系统的兼容性。

相比之下，之前 did:wba 中的基于路径的 DID 是普通路径；它们没有将绑定的公钥指纹直接放在 DID 路径内。

2.3 DID 文档从“列出公钥”升级为“证明绑定关系”

之前的 did:wba DID 文档已经可以表达 authentication、keyAgreement 和 service 等字段，并允许多种验证方法类型。然而，在新版本中，DID 文档的角色被提升：它不仅必须“列出密钥”，还必须“证明此文档与 DID 路径绑定一致”。

因此，对于默认的 e1_ 配置，新版本增加了几个关键约束：

• DID 文档必须具有顶层证明。

• 证明必须使用 DataIntegrityProof + eddsa-jcs-2022。

• proof.verificationMethod 对应的 Ed25519 公钥的 RFC 7638 拇指印必须与 DID 路径中最后的 e1_ 指纹完全匹配。

这一步至关重要。之前的 did:wba 主要在“请求认证”层验证签名。新版本将DID 路径、绑定密钥、文档证明和认证关系统一为一条连续的验证链。

2.4 请求认证从自定义头升级为标准 HTTP 消息签名

之前的 did:wba 请求认证方法是自定义的：

Authorization: DIDWba did=..., nonce=..., timestamp=..., verification_method=..., signature=...

这个设计有效，但本质上是一种协议私有格式，使其难以与现有的 HTTP 安全机制和标准生态系统集成。

新的 did:wba 直接走上标准化路径：

• 使用 RFC 9421 Signature-Input 和 Signature 头来表示请求签名。

• 使用 RFC 9530 Content-Digest 来绑定消息主体完整性。

• 认证成功后，通过 Authentication-Info 返回访问令牌。

• 认证失败时，通过 WWW-Authenticate + Accept-Signature 返回挑战信息和下一个请求应覆盖的组件。

这意味着新的身份认证方案不再是“自定义 DID 签名头”。相反，它将 DID 身份验证嵌入到成熟的 HTTP 标准语义中。对于工程实现，这一变化非常有价值：

• 请求覆盖范围更清晰。

• 服务器挑战更标准化。

• 中间件和网关更容易集成。

• 标准库和现有实现更容易复用。

2.5 TLS、令牌和高保证授权语义也更加清晰

新的 did:wba 还收紧了几个工程关键问题：

• TLS 服务身份验证：之前的版本更接近“证书通用名称匹配”。新版本明确要求 subjectAltName.dNSName，不再依赖 Common Name。

• 令牌返回方式：之前的版本更接近将访问令牌作为普通的 Authorization: Bearer ... 响应头返回。新版本明确要求服务器通过 Authentication-Info 返回访问令牌。

• 人工确认语义：之前的 DID 文档包含 humanAuthorization 字段。新版本明确移除了该字段，并将“是否需要人工在场”从 DID 文档移至上层授权策略和接口语义中，例如 authorizationLevel: user-presence-required。这将 DID 文档回归其应有的职责：声明身份能力，而不是混合过多的业务授权语义。

2.6 身份认证：旧版本 vs 新版本