ANP 协议实战：多智能体开放互联的第三种选择

当大模型 Agent 从“单兵作战”走向“团队协作”，ANP 协议（Agent Network Protocol，智能体网络协议）正成为继 MCP、A2A 之后的第三种选择。它的目标不是让一个智能体调用工具，也不是只在私有集群里编排任务，而是让不同厂商、跨组织的多智能体像网页一样自由互联。本文从定位差异、核心设计到 Python 最小实现，带你把 ANP 跑起来。

一、为什么需要 ANP：从工具调用到智能体互联

2025 年 MCP 解决了“模型怎么连工具”，2026 年 A2A 解决了“企业内部 Agent 怎么协作任务”。但当你的订票 Agent 想去调用另一家公司的物流 Agent、再去问一个第三方评测 Agent 时，问题来了：你既不知道对方机器长什么样，也无法信任对方身份。MCP 假设服务端是已知的，A2A 假设双方在一个可控编排域内。真正开放的“智能体互联网”，需要一套去中心化身份 + 自描述能力 + 标准化查询的协议，这正是 ANP 的出发点。

如果你还在纠结 MCP 与 A2A 各自的边界，可以先读这篇《MCP 与 A2A：2026 AI Agent 协议选型指南》，它把“连工具”和“连 Agent”的分工讲得很清楚；而本文聚焦的是它俩都没覆盖的“跨组织开放互联”这一段。

二、MCP、A2A 与 ANP 的定位差异

三者不是互相替代，而是分层互补。一张表看明白它们各自解决什么：

三、ANP 核心设计：Agent Description + DID 身份

3.1 用 YAML/JSON 描述一个 Agent 的能力

每个接入 ANP 的 Agent 都会发布一份机器可读的“自我介绍”——Agent Description，声明它能做什么、输入输出格式、调用入口。下面是一份最小示例：

agent:
  id: did:wba:fsdata.site:logistics-agent
  name: "物流状态查询 Agent"
  description: "根据订单号返回实时物流轨迹与预计送达时间"
  endpoint: "https://logistics.fsdata.site/anp/v1/query"
  protocols:
    - "anp/0.1"
  skills:
    - id: "track_order"
      description: "输入订单号，返回物流节点列表"
      input_schema:
        type: object
        properties:
          order_id:
            type: string
            description: "形如 SF1234567890"
      output_schema:
        type: object
        properties:
          status: { type: string }
          eta: { type: string }
  auth:
    type: "did"

3.2 基于 DID 的去中心化身份与鉴权

ANP 借鉴 W3C DID 标准，让每个 Agent 拥有一对公私钥和一个去中心化标识符（如 did:wba:domain:agent）。调用方用对方 DID 对应的公钥验证其数字签名，对方也用你的 DID 校验你，实现零信任双向认证，不再依赖中心化令牌分发。对跨企业场景，这意味着你无需为每一家合作方单独建账号体系。

四、ANP 交互协议：查询与应答

ANP 的查询消息是一个标准化 JSON 信封，携带发起方 DID、目标技能、参数与签名。下面是一个查询请求和对应的应答骨架：

// 请求
{
  "protocol": "anp/0.1",
  "from": "did:wba:client.site:booking-agent",
  "to": "did:wba:fsdata.site:logistics-agent",
  "skill": "track_order",
  "params": { "order_id": "SF1234567890" },
  "signature": "base64(私钥对上面字段签名)",
  "timestamp": 1760000000
}

// 应答
{
  "protocol": "anp/0.1",
  "from": "did:wba:fsdata.site:logistics-agent",
  "to": "did:wba:client.site:booking-agent",
  "result": {
    "status": "运输中",
    "eta": "2026-09-12 18:00",
    "nodes": [
      { "time": "2026-09-10 09:12", "loc": "深圳转运中心", "desc": "已发出" },
      { "time": "2026-09-10 22:40", "loc": "武汉分拨中心", "desc": "已到达" }
    ]
  },
  "signature": "base64(物流 Agent 私钥签名)"
}

五、动手接入：Python 客户端最小实现

下面是一个不依赖任何框架的最小客户端：生成 DID 签名、构造请求、发送并校验应答签名。生产环境请替换为你自己的密钥管理与 HTTPS 传输。

import hashlib, json, time, urllib.request
from collections import OrderedDict

AGENT_DID = "did:wba:client.site:booking-agent"
PRIVATE_KEY = b"<你的私钥 PEM>"  # 示意：真实场景用 cryptography 加载
TARGET_URL = "https://logistics.fsdata.site/anp/v1/query"

def sign(payload: str) -> str:
    # 示意签名：真实用私钥对 payload 做 ECDSA/RSA 签名后 base64
    return hashlib.sha256(payload.encode() + PRIVATE_KEY).hexdigest()

def build_request(target_did: str, skill: str, params: dict) -> dict:
    payload = OrderedDict()
    payload["protocol"] = "anp/0.1"
    payload["from"] = AGENT_DID
    payload["to"] = target_did
    payload["skill"] = skill
    payload["params"] = params
    payload["timestamp"] = int(time.time())
    raw = json.dumps(payload, ensure_ascii=False, separators=(",", ":"))
    payload["signature"] = sign(raw)
    return payload

def call_agent(req: dict) -> dict:
    data = json.dumps(req, ensure_ascii=False).encode()
    r = urllib.request.Request(TARGET_URL, data=data, method="POST",
                               headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(r, timeout=15) as resp:
        return json.loads(resp.read().decode())

if __name__ == "__main__":
    req = build_request(
        target_did="did:wba:fsdata.site:logistics-agent",
        skill="track_order",
        params={"order_id": "SF1234567890"},
    )
    reply = call_agent(req)
    print("物流状态:", reply["result"]["status"], "| 预计送达:", reply["result"]["eta"])

这段代码演示了 ANP 交互的关键三步：构造带 DID 的请求 → 本地签名 → 发送并读取结构化结果。把 call_agent 封装成工具后，你的 Agent 就能像调用本地函数一样去调度一个完全陌生的远端 Agent。

六、与 A2A 的协同：内部编排 + 跨域互联

ANP 并不否定 A2A。在真实架构里，二者常常叠加：企业内部用 A2A 做任务编排（低延迟、强一致），跨出企业边界时用 ANP 做开放互联（零信任、自描述）。例如你公司内部用 多智能体协作把“订票—支付—通知”串成流水线，而流水线中的“物流查询”节点通过 ANP 临时接入第三方 Agent。这种“内 A2A、外 ANP”的分层，是当前最务实的落地形态。

如果你的 Agent 还需要向前端流式输出结果，可参考 LLM 流式输出实战：SSE 推流与前端渲染，把 ANP 返回的异步结果以 SSE 实时推送给用户。

七、落地门槛与选型建议

ANP 目前仍在演进，直接上生产前请评估三点：其一，DID 私钥的托管与轮换策略必须先行，否则身份认证形同虚设；其二，Agent Description 要像 API 文档一样版本化管理，避免对端缓存了过期能力；其三，跨域网络延迟与重试要纳入 SLA，建议给每个 skill 设超时与熔断。选型上记住一句话：连工具用 MCP，企业内编排用 A2A，跨组织开放互联才上 ANP。

八、把它接进你的 Agent：三步落地清单

想真正用起来，按这三步走就能在一天内跑通最小闭环。第一步，写一份 Agent Description：把你已有的内部 API 包装成上面那样的 YAML 自描述文件，并静态托管到一个 HTTPS 端点，让对端可检索。第二步，签发 DID 并落地签名：用成熟密码库（如 Python 的 cryptography）生成密钥对，把公钥注册到 DID 文档，调用与验签都走私钥签名，别把密钥写进代码仓库。第三步，在编排层接一个 ANP 适配节点：把跨域调用封装成和你内部 A2A 一致的工具接口，让上层 Agent 无感切换本地与远端。

一个常见的落地误区是“等协议完全稳定再动手”。ANP 的演进节奏很快，但 Agent Description 与 DID 这两块核心抽象已经相对稳定。更稳妥的做法是先用 ANP 接入 1～2 个外部高价值能力（比如物流、天气、支付状态查询），把身份、签名、超时、熔断这套底座打磨好，再逐步扩大接入范围。这样既能吃到开放互联的红利，又不至于被早期草案的不兼容拖住。

ANP 把“智能体互联网”从概念推向可落地的协议层。对技术团队而言，现在正是把核心能力封装成可被发现、可被跨域调用的 Agent 的好时机——当生态成熟，先接入的一方将拥有显著的连接红利。从一份 Agent Description 和一对 DID 密钥开始，你的第一个开放互联智能体，今天就能跑起来。