ANP

简体中文

English

简体中文

English

Appearance

默认显示最新 1.1；也可查看历史 1.0。

ANP-端到端即时消息协议规范总纲 ​

  • 文档编号：ANP-09
  • 标题：ANP-端到端即时消息协议规范总纲
  • 状态：已发布
  • 版本：1.1
  • 语言：中文
  • 适用范围：本文档适用于 ANP 端到端即时消息规范集的总体说明、分层说明与 Profile 索引。

本文是 ANP端到端即时消息规范集的总纲性说明，用于帮助读者快速理解整套协议的目标、分层、核心理念与关键技术路线。本文不是逐条规范性条文，规范性要求以各 Profile 原文为准。

1. ANP端到端即时消息是什么 ​

ANP端到端即时消息是一套面向 Agent 与 Agent 跨域即时消息通信 的协议规范。

它要解决的不是“某个产品内部如何聊天”，而是：

  • 不同域、不同平台、不同实现的 Agent，如何彼此发现；
  • 如何发送私聊与群聊消息；
  • 如何在需要时提供端到端加密；
  • 如何传输附件与大对象；
  • 如何在跨域场景下完成路由、中继、排序与结果见证。

ANP 的协议终点是 Agent，不是设备、终端或内部副本。一个 Agent 内部是否有多个执行器、多个工作节点或多个设备实例，不属于 ANP 的互通边界，而是 Agent 自身的实现问题。

2. 核心理念 ​

2.1 联邦制，而不是单一中心 ​

ANP 采用的是一种 联邦式（Federated） 架构，理念上更接近 Email，而不是单一中心服务器架构。

每个 Agent 或群都可以属于不同的域，不同域通过标准化的服务发现、服务到服务直接调用和结果见证机制完成互通。也就是说：

  • 身份是分布式的；
  • 服务入口是分布式的；
  • 跨域服务调用可以发生；
  • 但每一类操作都有明确的责任边界。

在私聊场景中，目标 Agent 所在域的入口服务负责接收消息；在群场景中，群 Host Service 负责群状态排序与群事件序列化。

2.2 身份优先、服务发现优先 ​

ANP 的一等标识不是用户名或设备号，而是：

  • agent_did
  • group_did

ANP 通过 DID 文档发现可交互的服务端点，并以此建立后续的消息发送、密钥发现、群服务发现和对象服务发现路径。当前版本中，DID 文档对外公开的 ANP 服务入口统一收敛为 ANPMessageService；私聊、群聊、密钥材料访问和对象控制等能力由该统一入口承载。

2.3 分层设计，而不是“大一统协议” ​

ANP 不把所有问题塞进一份文档，而是拆成 9 个 Profile：

  • P1 / P2：共同绑定与身份发现
  • P3 / P4：私聊和群聊的基础业务语义
  • P5 / P6：私聊与群聊的 E2EE Overlay
  • P7：附件与大对象
  • P8：联邦、跨域服务调用与群事件分发
  • P9：群消息 mention 与 selector 语义

这种设计的好处是：

  • 基础消息语义和安全语义解耦；
  • 明文模式和加密模式可以共存；
  • 私聊、群聊、附件、联邦各自清晰；
  • 后续升级某一层，不必推翻整套协议。

2.4 控制面与数据面分离 ​

ANP 明确区分：

  • 控制面：建群、邀请、加人、踢人、能力协商、票据签发、跨域服务调用等；
  • 数据面：私聊消息、群消息、附件对象内容。

尤其在附件场景中，ANP 明确采用：

  • 消息里传 manifest（清单）；
  • 对象内容通过独立 HTTP(S) 通道下载；
  • 跨域服务调用链路不转发对象字节流。

3. 核心设计 ​

3.1 统一外层绑定：JSON-RPC ​

ANP 的统一外层绑定采用 JSON-RPC 2.0，并做了收紧：

  • params 使用对象形式；
  • id 使用字符串；
  • 不使用 batch；
  • Notification 仅用于明确的异步通知场景。

这样做的目的，是在保持实现简洁的同时，让不同语言、不同平台、不同服务之间拥有统一的请求/响应/错误模型。

3.2 私聊与群聊分别建模 ​

ANP 没有把“消息”做成一个模糊的大对象，而是明确区分：

  • direct.send：私聊
  • group.send：群聊

同时，群聊不仅是“发消息”，还包括：

  • group.create
  • group.invite
  • group.accept_invite
  • group.join
  • group.add
  • group.remove
  • group.leave
  • group.update_profile
  • group.update_policy

这使得群治理、群状态和群加密可以自然衔接。

3.3 明文与 E2EE 并存 ​

ANP 允许：

  • transport-protected：仅依赖传输安全
  • direct-e2ee：私聊端到端加密
  • group-e2ee：群聊端到端加密

也就是说，基础 Profile 可以独立运行；安全 Overlay 则在其之上叠加。这样既利于渐进部署，也有利于不同场景采用不同安全级别。

4. 核心技术路线 ​

4.1 传输与消息绑定：JSON-RPC 2.0 ​

ANP 采用 JSON-RPC 2.0 作为统一消息绑定层，作用不是“模拟函数调用”，而是给跨域协议提供统一的：

  • 请求格式
  • 响应格式
  • 错误模型
  • 能力协商接口
  • 异步通知机制

这使得 ANP 在私聊、群聊、附件控制、跨域服务调用等不同场景下，都能共享一致的外层协议形状。

4.2 私聊端到端加密：X3DH-like + Double Ratchet-like ​

ANP 的私聊 E2EE 采用如下技术路线：

  • 身份锚点：did:wba
  • 密钥发现：通过 DID 文档公开的 ANPMessageService 获取
  • 初始建链：X3DH-like
  • 后续消息保护：Double Ratchet-like

其中：

  • DID 文档中的认证密钥用于证明身份；
  • DID 文档中的 keyAgreement（例如 X25519）用于协商；
  • Prekey Bundle 用于异步离线建链；
  • Ratchet 用于后续每消息密钥滚动、乱序容忍与重放防护。

这条路线适合 Agent 异步通信，而且保留了向更强套件升级的空间。

4.3 群组端到端加密：MLS + did:wba 绑定 ​

ANP 的群组 E2EE 主线采用：

  • MLS 作为群密钥状态机；
  • did:wba 作为身份锚点；
  • Group Host Service 作为排序与回执权威。

这意味着：

  • 群应用消息使用 PrivateMessage 承载；
  • 成员加入、移除、欢迎、外部加入等能力通过 MLS 的 KeyPackage / Commit / Welcome / External Commit 完成；
  • group_did、group_state_version、policy_hash 与密码学群状态建立绑定；
  • group_receipt 负责证明“群已接受并排序了该操作/消息”。

这种做法比自己发明一套群密码学状态机更适合成为长期标准。

4.4 附件与对象：Manifest + 独立 HTTPS 下载 + 可选对象级加密 ​

附件方案采用三层结构：

  1. 消息层：只传 attachment_manifest
  2. 访问层：通过 Object Service 与短时下载票据控制下载
  3. 内容层：必要时对对象本身做对象级加密（object-e2ee）

因此：

  • 大对象不通过跨域服务调用链路传输；
  • 下载链接可以做成 locator 而不是长期直链；
  • 即使链接泄露，也可以通过对象级加密确保第三方拿不到明文。

4.5 联邦：服务到服务直接调用 ​

ANP 的联邦层定义了：

  • 服务发现
  • 跨域服务到服务直接调用
  • 群 Host 排序
  • 附件控制面的跨域调用
  • attachment.get_download_ticket 的最终落点

其中一个重要原则是：

  • 跨域时直接使用原有业务方法或控制方法与目标服务交互，而不是新增独立的 Relay 包装协议；
  • 对象字节流必须独立 HTTPS 下载；
  • 群操作以 Group Host 的接受与排序作为跨域成功语义；
  • 私聊以目标 Agent 入口服务的接受作为跨域成功语义。

5. 关键设计取舍 ​

ANP 有几个有意识的设计取舍：

5.1 不把设备概念放进协议 ​

ANP 认为“设备、多终端、内部副本”是 Agent 内部实现问题，而不是互通协议问题。

5.2 群治理优先于极致匿名性 ​

在群场景中，ANP 同时保留：

  • 发起者证明（谁发起了请求）
  • 群结果见证（群是否接受）
  • 群内消息机密性（MLS）

这意味着它更偏向“治理友好型 Agent 协议”，而不是纯匿名聊天协议。

5.3 附件安全不依赖“隐藏链接” ​

ANP 不把“绝对隐藏下载链接”作为核心安全手段，而是采用：

  • 受控下载票据
  • 短时 URL
  • 对象级加密

来确保即使链接泄露，也不一定能获取有意义的明文。

6. 文档结构 ​

以下 9 份 Profile 构成 ANP 当前规范集：

编号文档作用内容概览
101-核心绑定定义统一外层绑定规定 JSON-RPC 互操作约束、通用 params 结构、负载表示、能力协商、幂等、错误模型和方法命名空间。
202-身份与发现定义标识与服务发现规定 Agent DID / Group DID 的语义、DID 文档中的 ANP 解释规则、统一 ANPMessageService 服务入口以及发现流程。
303-私聊基础语义定义私聊基础业务层规定 direct.send 等私聊基础方法、内容模型、接受语义、幂等语义、排序语义和发送方证明边界。
404-群组基础语义定义群生命周期与群消息基础层规定群创建、邀请、加入、成员变更、群资料/策略更新、group.send、群状态版本与群 Host 排序职责。
505-私聊端到端加密定义私聊 E2EE Overlay规定 Prekey Bundle、did:wba 绑定、X3DH-like 初始建链、Double Ratchet-like 后续消息、AAD、重放防护和会话重建。
606-群组端到端加密定义群组 E2EE Overlay规定基于 MLS 的群密码学状态、KeyPackage 发布与发现、群基础方法到密码学状态机的映射，以及 epoch 与分叉处理。
707-附件与对象传输定义附件与大对象语义规定 attachment_manifest、Object Service、上传/提交/下载票据、对象级加密以及附件在私聊和群聊中的承载方式。
808-联邦与跨域定义跨域服务调用原则规定服务角色、发现与路由、服务到服务安全、跨域直接调用原则、群事件分发以及跨域成功语义。
909-消息Mention扩展定义群消息 mention 载荷语义规定结构化 mention 对象、@all、@agents、@humans 等 group selector、Group Base 与 Group E2EE 的放置规则以及终端侧校验。

建议阅读顺序为：

  • 先读 P1 / P2
  • 再读 P3 / P4
  • 然后读 P5 / P6
  • 最后按需读 P7 / P8 / P9

7. 总结 ​

ANP 的核心，不是做一个“聊天协议”，而是做一套 面向 Agent 生态的跨域通信标准。

它的基本思路可以概括为：

  • 联邦制：像 Email 一样跨域互通；
  • 身份优先：以 DID 为统一锚点；
  • 分层设计：业务、加密、附件、联邦各自分离；
  • E2EE 可选叠加：基础协议可独立运行，安全 Overlay 可按需启用；
  • 附件直连下载：消息传 manifest，对象走独立 HTTP(S) 数据面；
  • 治理友好：尤其在群场景中，同时兼顾身份、排序、回执与加密。

这使 ANP 既能作为一个可实现的协议体系，也能作为后续长期标准化演进的基础。