ANP Release 1.1 正式发布：聚焦智能体跨域通信
经过三个月时间的打磨，ANP 1.1 在上周已经正式发布。
这个版本之前在社区例会中讨论过很多次，中间也根据大家的反馈以及我们的实施，做了不少调整。今天正式总结一下这个版本几个大的改进，以及背后的一些思考。
本次升级最核心的内容主要有两个：一个是自主身份控制，另一个是消息协议升级，尤其是跨域通信和安全通信。
自主身份控制
ANP 一直是基于 DID 来做智能体身份的。
DID 最大的好处，是可以把身份、密钥、服务入口这些东西放在一个可验证的文档里。这样不同平台、不同组织之间就不需要依赖同一个账号系统，也可以互相识别和认证。
did:web 是一个很好的方法。它把 DID 和现有 Web 基础设施结合起来，直接复用域名、HTTPS、.well-known 这些成熟机制，部署门槛比较低，也很容易和现有互联网系统兼容。
但 did:web 也有一个问题：DID Document 是托管在 Web 服务器上的。也就是说，如果服务器有能力修改 DID Document，那么在一些高安全场景里，它就可能影响用户身份和密钥的可信度。
比如我们基于 DID 做端到端加密通信，如果服务器能够悄悄替换 DID Document 里的密钥材料，那么通信双方以为自己是在和某个 Agent 安全通信，但实际上密钥可能已经被替换了。这个问题在普通登录认证里可能还没那么明显，但在端到端加密、跨域身份验证这些场景里，就会变得非常关键。
所以这次我们对 did:wba 做了升级。
这里需要说准确一点：我们不是在 DID 里携带用户私钥，私钥永远不应该写到 DID 里。did:wba 的做法，是在路径型 DID 中携带绑定公钥指纹。简单理解，就是 DID 本身和用户控制的公钥之间建立一个可验证的绑定关系。
这样做之后，即使 DID Document 是由某个 Web 服务托管的，验证方也可以检查 DID 路径中的公钥指纹，和 DID Document 中声明的密钥是否一致。服务器如果想静默替换密钥，就不再那么容易。
这带来的效果是：用户对私钥的控制，可以更直接地反映到 DID 身份本身上。DID 不再只是一个 Web 地址下的文档，而是和用户实际控制的密钥建立了更强的关系。
当然，did:web 仍然有自己的优势。它稳定、简单、兼容性好，特别适合很多低门槛部署场景。所以 ANP 1.1 并不是要放弃 did:web，而是同时兼容原生 did:web 和 did:wba。不同场景可以选择不同方案，它们之间也可以互通。
在身份这一块，1.1 还有一个重要设计，就是 Handle。
我们为什么要设计 Handle？主要有两个原因。
第一个原因是可读性。
DID 对机器很友好，但对人不友好。一个完整 DID 往往很长，不适合出现在聊天窗口、名片、联系人列表或者邀请链接里。用户也很难手动输入和记忆。
所以我们需要一个更适合人使用的标识，比如：
alice.example.com这种形式用户更容易看懂，也更容易传播。
第二个原因，是为 did:wba 锚定一个稳定 ID。
因为 did:wba 路径里会绑定公钥指纹，当底层密钥发生变化时，DID 本身可能也要变化。这从安全角度是合理的，但从用户体验角度看，大家还是希望有一个长期稳定的名字。
Handle 就是为了解决这个问题。Handle 可以保持稳定，底层 DID 可以随着密钥、安全策略或设备变化而轮换。用户看到的是 Handle，协议真正验证时再解析到当前有效的 DID。
所以，Handle 不是替代 DID。它解决的是“人怎么识别”的问题；DID 解决的是“协议怎么验证”的问题。
Handle和DID的关系，类似与域名和IP地址的关系。
消息协议升级
这次 1.1 另一个大的改进，是消息协议。
第一版草案的消息协议是能跑的，但在继续推进实现时，我们发现还有几个潜在问题。
比如附件支持不够完整，跨域协作还有一些硬伤，端到端加密方案距离业界成熟方案还有差距，尤其是前向安全、群聊密钥管理这些问题还不够清楚。
在继续优化之前，我们首先重新定义了一下问题。
我们并不希望把 ANP 做成一个像 Matrix 那样非常完整的 IM 协议。Matrix 解决的是从客户端到服务器、服务器到服务器，再到多设备同步、房间状态、历史消息等一整套问题。这个方向很强大，但也非常重。
ANP 要解决的问题不一样。
我们更关注的是：不同域、不同系统里的智能体之间，如何进行跨域消息通信。
至于每个域内部怎么实现账号系统，客户端怎么注册，是用手机号验证还是邮箱验证，一个 Agent 内部有没有多个设备、多个执行器，这些我们都不希望放到协议主线里定义。
如果把这些都定义进去，协议复杂度会非常高，而且很多内容其实是系统内部问题，不是跨域互操作问题。
所以 1.1 的消息协议，核心聚焦在三个场景：
第一，智能体之间怎么私聊和群聊。
第二，消息里怎么发送附件和大对象。
第三，在需要的时候，智能体之间怎么进行端到端加密通信。
这就是我们对问题边界的定义。
问题定义清楚之后，就可以做下一个设计决策：ANP 1.1 不在协议层定义多设备。
多设备会带来很高的协议复杂度。不同设备之间怎么同步状态，怎么同步密钥，怎么处理离线消息和历史消息，这些都很复杂。而且不同系统对多设备的需求也不一样。
我们认为，一个 Agent 内部有多少设备、多少执行节点、多少副本，应该由各个系统自己解决。ANP 只把 Agent 看成一个跨域通信主体。只要这个 Agent 对外能收发消息，内部怎么调度，不进入协议互操作边界。
这个决策让协议可以更轻，也更聚焦。
消息协议和 DID 的结合
在这次消息协议升级里，一个很重要的设计，是消息协议和 DID 的深度结合。
我们不只是给人或智能体分配 DID，还为群组、消息服务也引入了 DID。这样在消息系统里，就形成了几个不同角色。
第一个是 Agent DID，也就是消息的发送方和接收方。当然，人类也可以申请一个DID。
第二个是 Group DID，也就是群组自己的身份。群不是某个服务器内部的普通房间 ID，而是可以跨域识别、跨域发现、跨域验证的协议主体。
第三个是 Service DID，也就是提供消息服务的服务器身份。跨域通信时，服务和服务之间也需要相互认证，不能只看业务消息里的发送者是谁。
这样设计之后，身份层次就清楚很多。
Agent DID 用来证明谁发起了消息。Group DID 用来证明群的身份、群状态和群事件顺序。Service DID 用来证明当前这一次跨域调用是哪一个服务发起的。
这几个 DID 不能混在一起。
比如，某个服务器可以帮助 Alice 的 Agent 把消息转发到另一个域，但它不能把这条消息说成是自己发的。服务身份只能证明“我在转交”，不能替代业务身份。
在完整性证明上也是一样。不同角色可以使用自己的 DID，对不同层次的对象进行证明。Agent 可以证明自己发起了一条消息，Group Host 可以证明某条群消息已经被群接受并排序，服务可以证明某一次 HTTP 调用确实来自自己。
这也是我们在实现过程中很深的一个感受：DID 非常适合跨域。
因为跨域系统最怕的就是身份语义混乱。DID 让每个主体都可以有自己的身份、自己的密钥、自己的证明方式，而且这些证明不依赖同一个中心账号系统。
未来如果有一天，必须要支持多设备，也可以为每个设备创建一个DID。
跨域消息不再额外包一层
这次还有一个很重要的设计决策：跨域消息不额外包一层 Relay 协议。
也就是说，私聊跨域还是使用 direct.send，群聊跨域还是使用 group.send，群成员变更还是使用原来的群管理方法。跨域 Profile 只规定怎么发现目标服务，怎么认证当前服务，怎么保留原始发送者证明，以及什么时候算成功。
这个选择看起来简单，但很重要。
如果域内一套方法，域间再发明一套 Relay 方法，长期看协议会越来越复杂。业务语义会被拆成两套，实现者也很容易搞混：到底应该验证 Relay 层，还是验证原始业务层？
所以我们选择让业务方法保持一致。跨域只是调用边界发生了变化，不应该重新定义一套业务语义。
附件与对象传输
附件也是这次重点补强的部分。
我们不希望消息服务变成文件转发服务。大文件、图片、音视频这些对象，如果直接跟着消息跨域转发，会带来很大的成本和稳定性问题。
所以 1.1 把消息和对象拆开。
消息里只携带附件描述，也就是 attachment manifest。真正的对象上传和下载，走独立的 HTTPS 通道。跨域消息服务只参与控制面，比如申请上传位置、提交对象、获取下载票据等，不负责一路转发文件字节。
这样做更加工程化，也更适合真实部署。
如果对象需要更高保密性，还可以启用对象级加密。Object Service 可以负责存储和分发，但不需要知道对象明文。
端到端加密通信
最后说一下端到端加密。
我们非常重视这件事。因为在一些重要场景里，智能体之间的消息不应该被服务器获得。服务器可以帮忙路由、排序、存储、分发，但不应该默认拥有读取内容的能力。
在私聊端到端加密上，我们参考了 Signal 的一些思路。发送方不需要等接收方在线，可以先获取对方公开的建链材料，然后发起加密会话。后续消息再通过类似 Double Ratchet 的机制不断更新密钥，从而支持更好的前向安全。
在群聊端到端加密上，我们采用 IETF 的 MLS，也就是 Messaging Layer Security。
我们没有选择自己设计一套 Sender Key 群密钥方案。传统 Sender Key 方案在小群里看起来简单，但成员加入、退出、踢人、密钥轮换都会变得很麻烦。尤其是在跨域场景里，谁来更新密钥，谁来同步状态，谁来证明当前群状态，都会产生很多问题。
MLS 的优势在于，它本来就是为群组安全通信设计的。它有比较清晰的群密钥状态机，能更好地处理成员变化、密钥更新和群消息加密。我们在 ANP 里用 DID 绑定成员身份，用 Group Host 负责业务排序和回执，用 MLS 负责群加密状态。
这样分工会更清楚，也比自己重新发明一套群加密协议更可靠。
我们在这里的主要工作是，将DID与MLS融合起来。
相关文档：
https://github.com/agent-network-protocol/AgentNetworkProtocol/tree/main/message
下一步计划
ANP 1.1 发布之后，我们接下来会重点推进两个方向。
第一个方向是智能体的权限控制与审计。
智能体之间协作，不只是能发消息，还需要知道谁有权限做什么，以及最后产生的结果能不能被审计。这里我们会结合 W3C DID 配套的 VC，也就是 Verifiable Credentials，来实现更细粒度的权限表达和结果证明。
VC 现在在很多方向都有研究，我们认为它非常适合智能体协作中的授权、委托和审计场景。
第二个方向是消息系统中的上下文共享。
智能体通信不只是发送一句话，还经常需要共享任务背景、工具调用结果、上下文状态和协作过程。我们会继续探索在消息系统里，智能体之间如何更好地共享上下文，同时又不把协议做得过重。
总的来说，ANP 1.1 是一次比较关键的版本升级。它让 ANP 从“能连接”往“能跨域协作、能验证、能保护内容”更进一步。
我们的目标还是一样：让智能体像今天的 Web 服务一样，可以开放连接、独立部署、跨域协作。
Release 1.1，是朝这个方向继续往前走的一步。