ANP：把 Agent 网络从工具连接推进到身份、发现与跨域通信

Source: https://github.com/agent-network-protocol/AgentNetworkProtocol

ANP 不是“再做一个 agent tool protocol”。它更像是在定义 agent 互联网的底层网络栈：先解决身份与安全通信，再解决协议协商，再往上长出 agent 描述、发现、即时消息和支付。

1. 项目概览

ANP（Agent Network Protocol）是一个面向 agent 通信的开源协议体系，目标是成为 Agentic Web 时代的 HTTP。

从 GitHub 信号看，它已经不是轻量 demo：

Stars：1,276
Forks：86
Open issues：22
License：Apache-2.0
Latest release：1.0 / V1.0
最近 push：2026-04-22
语言构成几乎完全是文档 / 规范 / 可视化素材，说明它是一个 协议与生态叙事中心，不是单体应用仓库
官方 README 还明确把实现拆到了 AgentConnect，所以 repo 本体更像 标准 + 说明书 + 路线图

一句话判断

ANP 的价值不在于“能不能做聊天”，而在于它试图把 agent 之间的连接方式标准化成一整套协议栈。

2. 架构拆解

ANP 的结构可以理解成三层，再加两条横向能力。

Agent A
  |
  | 1) DID / secure identity
  v
Agent discovery (.well-known / ADSP)
  |
  | 2) ADP / description document
  v
Meta-protocol negotiation
  |
  +--> direct message / group message
  +--> attachment / object transfer
  +--> payment / commerce
  |
  v
Verified response / audit trail

关键入口

01-agentnetworkprotocol-technical-white-paper.md
- 总体愿景和技术叙事
03-did-wba-method-design-specification.md
- DID-WBA 方法设计
04-anp-did-wba-name-space-specification.md
- 命名空间设计
06-anp-agent-communication-meta-protocol-specification.md
- 元协议层，定义协议协商
07-anp-agent-description-protocol-specification.md
- Agent 描述协议 ADP
08-ANP-Agent-Discovery-Protocol-Specification.md
- Agent 发现协议 ADSP
09-ANP-end-to-end-instant-messaging-protocol-specification.md
- 端到端即时消息
application/10-anp-agent-payment-protocol-specification.md
- AP2 / 支付协议

结构分层

1) 身份与安全通信层

这一层是 ANP 的根。

它的关键动作不是“发消息”，而是先回答：

这个 agent 是谁？
它是否可验证？
它的身份是否跨平台可识别？
它能否在不依赖单一中心的情况下通信？

ANP 在这里引入 DID / did:wba 思路，把身份做成协议一部分，而不是应用层附属功能。

2) 元协议层

这层是 ANP 最有野心的地方。

它不是直接规定“消息长什么样”，而是规定：

两个 agent 如何先协商采用什么通信方式
如何把自然语言、结构化协议、任务执行、附件转移等场景统一起来
如何让 agent 网络具备一定的自组织和自协商能力

这相当于把“连接”从静态规范推进到动态协商。

3) 应用协议层

在这一层，ANP 才开始长出具体能力：

Agent 描述（ADP）
Agent 发现（ADSP）
即时消息
支付 / 交易（AP2）

这意味着 ANP 的目标不是只做一个通道，而是做一个可扩展的协议家族。

一个更直观的分层图

[Identity / Secure Communication]
  - DID / did:wba
  - signing / verification
  - end-to-end security
 
[Meta-Protocol]
  - protocol negotiation
  - capability alignment
  - structured exchange planning
 
[Application Protocols]
  - ADP: agent description
  - ADSP: agent discovery
  - IM: direct/group messaging
  - AP2: payment / commerce

3. 核心机制

3.1 先有身份，再有通信

ANP 的第一性原则很清楚：agent 网络不是先发消息，而是先确立 可信身份。

这也是它和纯工具协议最大的不同。MCP 解决的是“模型如何安全接入工具和上下文”，ANP 解决的是“agent 如何作为网络主体被识别、被发现、被验证、被联系”。

3.2 ADP：把 agent 写成可机器理解的名片

ADP 定义了 agent 的公开描述文档。

它的作用很像一个 agent 的“公开主页 / 名片 / profile”：

谁在提供服务
能力是什么
接口是什么
支持什么协议
如何被其他 agent 发现和调用

这里最关键的是：描述文件不是单纯的自然语言简介，而是 结构化可消费文档。这让搜索、索引、编排和自动调用成为可能。

3.3 ADSP：把发现做成 .well-known 入口

ANP 的发现协议最值得注意的设计是：

主动发现：.well-known/agent-descriptions
被动发现：向搜索服务提交描述

这一步很重要，因为它说明 ANP 不是幻想一个“全新网络”，而是尽量借用现有 web 约定去搭建 agent 可发现性。

它在思路上更接近“站点发现 + 搜索索引”，而不是封闭式目录。

3.4 即时消息：联邦式，而不是单中心式

ANP 的即时消息规范把消息系统说得很明确：

端点是 agent，不是设备
体系是 federated，不是单一中心
需要区分 control plane 和 data plane
直接消息和群消息是分开建模的
JSON-RPC 2.0 被作为统一外层绑定

这意味着 ANP 不是只想做“chat protocol”，而是想把 agent 的直接通信做成一个标准网络层对象。

3.5 AP2：把交易也纳入协议家族

AP2 说明 ANP 不是只谈通信，还把支付和商业交易纳入其协议族。

这非常关键，因为它揭示了 ANP 的长期叙事：

agent 不是只会聊天或调工具，它最终要能完成服务采购、确认、交付和结算。

所以 payment 不是附属功能，而是它通往“agent 服务网络”的自然延伸。

4. 对比与生态位

ANP 最容易被拿来和 MCP、A2A 比。

维度	MCP	A2A	ANP
核心问题	模型接工具 / 数据源	Agent 之间任务交换	Agent 网络的身份、发现、通信与协商
网络想象	工具插件层	agent-to-agent 协作层	agent internet / 协议网络
身份	较弱，远程身份不是核心	在形成中	很强，DID / WBA 是底座
发现	不是主目标	有但不是核心叙事	ADSP 是核心一环
通信	local / intranet 更成熟	agent 间任务交换	federated messaging + meta-protocol
商业化	工具集成与开发者生态	agent 工作流协作	进一步扩展到服务与支付

怎么理解差异

MCP 更像“给模型接 USB-C”
A2A 更像“agent 之间互发任务的协作层”
ANP 更像“把 agent 互联网的身份、发现、消息、支付一起做成协议栈”

所以 ANP 的野心更大，但复杂度也更高。

5. 优势与不足

优势

维度	优势
系统完整性	从身份到发现到消息再到支付，协议家族更完整
网络视角	不把 agent 看成孤立工具，而是看成网络主体
可扩展性	用元协议层承接后续新协议，理论上更有弹性
兼容现实	借用了 DID、JSON-LD、JSON-RPC、`.well-known` 等既有 web 约定
生态叙事	很适合承接 registry / inbox / service marketplace 的长期方向

不足

维度	风险 / 代价
复杂度	三层 + 多协议族，学习和落地门槛都高
证据重心	仓库偏 spec/documentation，执行实现分散到别的 repo
标准竞争	MCP、A2A、ACP、AP2 等都在争夺 agent 时代接口叙事
早期 adoption	协议越完整，越容易“方向很大、落地慢”
协议边界	如果没有足够一致的实现，容易停留在概念整合层

6. 适合谁

最适合的人群 / 场景

做 agent registry / discovery / inbox 的基础设施团队
做跨域 agent 通信的协议设计者
做 enterprise agent network / service marketplace 的团队
研究 agent internet、DID、联邦消息系统的人

不适合的人群 / 场景

只想快速给模型接几个工具的团队
只需要本地或内网工具集成的产品
希望“今天接入、明天上线”的轻量项目

什么时候该选它

你真的要做 agent 网络，而不是单个 agent 工具链
你需要身份、发现、消息、审计、支付这类长期能力

什么时候不该选它

你现在只需要 MCP / 轻量 A2A / 私有工作流编排
你的组织还没有准备好承受协议复杂度和生态建设成本

7. 我的判断

ANP 是我看过的 agent 通信项目里，最像“网络协议”而不是“应用协议”的一类。

它的强项不是某个局部功能，而是把整个问题提升到：

agent 如何被识别
agent 如何被发现
agent 如何建立可信通信
agent 如何进入可交易的服务网络

这条路线很有价值，但也意味着它不会像 MCP 那样容易快速普及。MCP 解决的是连接工具的现实需求，ANP 解决的是未来 agent internet 的结构性需求。

最终判断

ANP 更适合被看作“agent 网络时代的协议蓝图”，而不是今天就能全面替代 MCP 或 A2A 的现成产品。

如果你在做的是身份、发现、inbox、跨域协作、服务网络这条线，ANP 值得重点关注；如果你只想快速落地工具集成，它不是第一选择。