本文深入解析了2024-2026年Agent通信协议的演进历程，从MCP、A2A到ACP和ANP，阐述了它们各自解决的问题和分层互补关系。文章详细拆解了MCP的Host-Client-Server架构和2025-11-25版本新增特性、A2A的Task状态机和Agent Card发现机制、ACP并入A2A的收敛案例、ANP的去中心化身份实验，揭示了协议栈的分层互补本质，并给出了场景驱动的协议选型决策框架。对于想要学习大模型和Agent通信协议的程序员，本文提供了系统性的解析和实用的选型建议。

Agent 通信的"巴别塔"问题

想象你是一家企业的架构负责人。客服系统用了 LangGraph Agent，代码审查用了 Spring AI Agent，新收购的创业公司用 CrewAI Agent。现在老板要求三个 Agent 协作：客服 Agent 遇到技术问题时自动转交代码审查 Agent，代码审查 Agent 需要客户数据时调用客服 Agent。

你开始调研集成方案，然后发现——每个框架发明了自己的通信层。LangGraph 用 subgraph 传递状态，Spring AI 用 REST API，CrewAI 用内部消息队列。没有共享协议，没有发现机制，没有标准消息格式。每对 Agent 之间需要写定制集成代码，三个 Agent 就是三对集成，十个 Agent 就是四十五对。

这就是 Agent 通信的"巴别塔"问题。2024 年之前，N 个 Agent 之间的集成复杂度是 O(N²)——每对 Agent 需要定制代码。MCP 和 A2A 的出现，分别从垂直层（模型-工具）和水平层（Agent-Agent）把这个复杂度降到了 O(N)。

但一个常见的误解是：MCP 和 A2A 是竞争关系，“选一个就行”。实际上它们解决的是完全不同层次的问题——MCP 是"USB 接口"，A2A 是"TCP/IP"。理解协议栈的分层本质，才能避免"选错层"或"重复造轮子"。

图 1: Agent 通信协议栈。MCP 是垂直层（模型-工具连接），A2A 是水平层（Agent-Agent 协作），ANP 是身份层（去中心化发现），Pilot Protocol/HTTP 是传输基础设施。

这里先做一个版本限定：本文中的协议能力、生态数据和选型建议，都是截至 2026-05-20 的快照。MCP 与 A2A 都处在快速演进期，尤其是 MCP 的实验性原语和 A2A 的 Agent Card 字段，生产落地时应以锁定的协议版本和 SDK 版本为准，而不是只按"最新文档"实现。

读这篇文章时，可以先把"通信协议"拆成五个连续动作：

1. 发现：我怎么知道某个工具或 Agent 存在？

2. 理解：我怎么知道它能做什么、需要什么输入、会返回什么？

3. 委托：我怎么把任务交给它，并让它开始执行？

4. 跟踪：我怎么知道它做到哪一步、是否需要我补充信息？

5. 治理：我怎么限制权限、审计调用、撤销能力和处理失败？

MCP 主要覆盖前两个半动作：发现工具、理解工具、调用工具。A2A 覆盖后面更完整的任务生命周期：发现 Agent、委托任务、跟踪状态、传递产物。ANP 则把"发现和身份"从企业内部推向开放互联网。后文所有协议细节，其实都可以放回这五个动作里理解。

---

MCP：模型-工具连接的"USB 接口"

MCP（Model Context Protocol）解决的核心问题是：模型如何连接工具和数据源？在 MCP 之前，每个 AI 应用自己实现工具连接——写 API 客户端、解析返回值、处理错误。MCP 把这个过程标准化了：工具提供方实现一个 MCP Server，任何 AI 应用作为 MCP Client 就能调用，不需要为每个应用写定制集成。

Host-Client-Server 架构

MCP 的架构灵感来自 LSP（Language Server Protocol）。一个 Host 应用（比如 Claude Desktop、Cursor）包含一个或多个 MCP Client，每个 Client 与一个 MCP Server 维持有状态会话。

图 2: MCP Host-Client-Server 架构。Host 应用包含多个 MCP Client，每个 Client 与一个 MCP Server 维持有状态会话。

关键设计决策：

有状态会话：Client 和 Server 之间维护会话状态（Mcp-Session-Id），支持可恢复性和重传。这和 HTTP 的无状态模型不同——MCP 需要会话是因为工具调用往往涉及多步交互

协议版本协商：通过 MCP-Protocol-Version header 协商版本，确保 Client 和 Server 兼容

一对多关系：一个 Host 可以同时连接多个 MCP Server，每个 Server 提供不同的工具集

三大原语 + 2025-11-25 新增

MCP 定义了三种核心原语，2025-11-25 版本又新增了三种：

原语	类型	作用	类比
Resources	Client 读取	上下文数据（文件、数据库记录、实时数据流）	文件系统读取
Tools	Client 调用	可执行函数，结构化参数 → 结构化结果	RPC 调用
Prompts	Client 获取	可复用的提示模板	代码片段
Tasks ⭐	双向	跟踪长时间运行的服务器操作	Job tracker
Elicitation ⭐	Server→Client	安全的带外交互，服务器请求用户提供信息	表单弹窗
Sampling with Tools ⭐	Server→Client	Agentic Server——MCP Server 自身调用 LLM	工具调用工具

⭐ = 2025-11-25 版本新增，其中 Tasks 仍属于实验性能力，生产落地时需要关注客户端和服务器 SDK 的兼容性。

三个新增原语的意义：

Tasks 解决了长时间运行操作的问题。之前 MCP 没有标准方式跟踪"正在执行"的操作——Server 返回结果要么成功要么失败，没有中间状态。Tasks 原语让 Client 可以查询操作进度、取消操作、接收完成通知。

Elicitation 解决了"Server 需要额外信息"的问题。比如一个数据库查询工具需要用户选择查询范围，Server 可以通过 Elicitation 请求 Host 弹出交互界面，用户选择后继续执行。这比"在工具参数里加一个可选字段"更安全——敏感信息（密码、授权码）不会出现在模型上下文中。

Sampling with Tools 是最激进的新增。它让 MCP Server 自身可以调用 LLM——也就是说，一个"工具"本身可以是一个 Agent。这模糊了"工具"和"Agent"的边界，也暗示 MCP 和 A2A 的未来可能进一步融合。

图 3: MCP 2025-11-25 版本新增特性。Tasks 跟踪长操作，Elicitation 安全交互，Sampling with Tools 让 Server 变成 Agent。

Wire Format 与传输

MCP 使用 JSON-RPC 2.0 编码，UTF-8。两种传输方式：

stdio：Client 启动 MCP Server 为子进程，通过 stdin/stdout 通信。适合本地工具——零网络配置，零部署成本。一个 Python 脚本、一个 Node.js 程序，只要实现 JSON-RPC 2.0 的 stdin/stdout 交互就能成为 MCP Server。

Streamable HTTP：Server 作为独立 HTTP 进程，支持多 Client 连接，可选 SSE（Server-Sent Events）流式传输。适合远程服务——工具部署在云端，多个 AI 应用共享同一个 Server。

一个重要的版本变更：2025-11-25 版本废弃了旧版 HTTP+SSE 传输，Streamable HTTP 是替代方案。旧版的问题是双通道设计（HTTP 请求 + SSE 通知）过于复杂，Streamable HTTP 统一为单通道，Client 可以选择是否启用 SSE。

安全与授权

远程 MCP Server 使用 OAuth 2.1 + PKCE 授权。2025-11-25 版本新增了三个安全特性：

Client ID Metadata Documents（CIMD）：简化 OAuth 流程，Client 无需预先在 Server 注册。Client 发布一个 CIMD 文档描述自己，Server 动态验证

Cross App Access：企业 SSO 场景，允许跨应用授权。比如 Cursor 可以授权访问部署在内部网络的 MCP Server

Authorization Extensions：可扩展的授权框架，支持自定义授权策略

简化后的授权流程是：Client 先读取 Server 的授权元数据，发起带 PKCE 的授权请求；用户在授权服务器完成登录和授权；Client 拿到授权码后换取 access token；后续每次调用远程 MCP Server 时携带 token。CIMD 的价值在于让 Client 的身份描述可以通过元数据文档动态发现，而不是每接入一个 Server 都手工预注册一个 client_id。

安全防护方面，DNS 重绑定攻击是一个重要威胁——恶意 MCP Server 可能通过 DNS 重绑定访问 Client 的本地网络。MCP 要求 Server 验证 Origin header，Client 验证 Server 的 TLS 证书。

发现与生态

MCP Registry 是 MCP 生态的发现中枢。2025 年 9 月发布，集中索引所有可用 MCP Server。截至 2025 年 11 月，已有近 2000 个条目（407% 增长）。

生态数据：Python + TypeScript SDK 月下载 97M+；10,000+ 活跃 Server；Anthropic、OpenAI、Google、Microsoft 一等公民支持。

治理：2025 年 12 月，MCP 捐赠给 Linux Foundation AAIF（Agentic AI Foundation），由 Anthropic、Block、OpenAI 联合创立。这意味着 MCP 不再是 Anthropic 的私有协议，而是行业共同治理的开放标准。

但 MCP 的边界也很明确：它标准化的是"一个模型/应用如何连接工具"，不是"多个 Agent 如何分工协作"。MCP Server 可以变得越来越 agentic，但调用方看到的仍然主要是工具、资源和提示模板。只要你的问题变成"把一个任务交给另一个自治 Agent，让它自己规划和推进"，MCP 就不是最自然的抽象，这正是 A2A 要解决的层次。

MCP 落地设计：工具不是 API 的简单搬运

很多团队第一次接 MCP 时，会把已有 REST API 原封不动包一层：一个 API 对应一个 Tool，参数照搬，返回照搬。这样能跑通 demo，但很快会在生产里遇到问题：模型不知道该选哪个工具，参数太细导致填错，返回太大挤爆上下文，权限也很难收敛。

更好的做法是把 MCP Tool 当成"面向模型的能力接口"，而不是"面向程序员的 API 接口"。

设计项	常见错误	更好的设计
Tool 粒度	每个后端 API 暴露一个 Tool	按用户意图聚合，比如 search_customer_orders 而不是 GET /orders
参数 Schema	直接暴露数据库字段或内部枚举	用业务语言命名，给出约束、默认值和示例
返回内容	返回完整 JSON 或整页 HTML	返回模型决策需要的摘要、关键字段和可追溯 id
错误信息	只返回 HTTP 500 / stack trace	区分参数错误、权限错误、资源不存在、可重试失败
权限边界	Tool 内部再判断权限	在 Tool 暴露、调用授权和数据过滤三层都做限制

举个例子，CRM 系统里可能有 customers、contracts、tickets、payments 四组 API。如果直接暴露成几十个 MCP Tool，模型会在工具选择上浪费大量 Token，还可能把"查客户投诉"误选成"查客户付款"。更合理的做法是按任务设计 Tool：summarize_customer_risk、find_recent_support_issues、get_contract_renewal_context。底层仍然可以调用多个 API，但模型看到的是更接近业务意图的能力。

Resources 也不是"把数据库开放给模型"。它更适合承载可读上下文：文档片段、配置、只读记录、实时状态。凡是会修改外部世界的动作，都应该进入 Tools；凡是涉及用户确认、权限升级或敏感信息补充的动作，都应该通过 Elicitation 或 Host 侧交互完成，而不是让模型在上下文里自行拼接。

Sampling with Tools 让 MCP Server 具备更强自治性，但也带来一个新的治理问题：谁为 Server 内部的模型调用负责？ 如果一个 MCP Server 自己调用 LLM，再调用工具，再把结果返回给 Host，Trace、成本、权限和安全审计就不能只看 Host 侧。生产环境里至少要明确三件事：

1. Server 内部模型调用是否计入用户任务预算？

2. Server 内部工具调用是否继承 Host 的用户权限，还是使用 Server 自己的服务权限？

3. Server 生成的中间结论是否需要进入审计日志和可观测性平台？

这也是为什么 MCP 的 agentic 化并不意味着 A2A 失去价值。MCP Server 可以变聪明，但只要它对外仍以 Tool/Resource 的形式呈现，它就仍然更像"可调用能力"；A2A 的核心仍然是"可委托主体"。

---

A2A：Agent-Agent 协作的"TCP/IP"

MCP 解决了"模型如何连接工具"的问题，但没解决"Agent 如何与其他 Agent 协作"的问题。一个 Agent 可以通过 MCP 调用工具，但如果它需要把一个子任务委托给另一个 Agent 呢？另一个 Agent 可能是不同团队开发的、部署在不同服务器上、用不同框架实现的。

A2A（Agent-to-Agent Protocol）就是解决这个问题的——它定义了 Agent 之间如何发现彼此、委托任务、交换消息、传输产出物。

设计哲学：Agent 是不透明的

A2A 最核心的设计假设是：Agent 是不透明的（opaque）。调用者不知道也不需要知道 Agent 的内部实现、工具或推理链。你只需要知道这个 Agent 能做什么（能力声明），不需要知道它怎么做。

这和 MCP 的"透明工具"形成鲜明对比：

维度	MCP	A2A
对象	工具（透明）	Agent（不透明）
调用者知道什么	工具的完整 Schema（参数、返回值、约束）	Agent 的能力声明（能做什么）
交互模式	远程过程调用（RPC）	任务委托（Delegation）
执行控制	调用者控制流程	Agent 自主决定如何完成
类比	调用一个函数	委托一个任务

说白了，MCP 是"我调用你的函数"，A2A 是"我把任务交给你，你自己搞定"。这个区别决定了两个协议的整个设计差异。

核心概念

Agent Card 是 A2A 的发现机制。它是一个 JSON 元数据文档，发布在 /.well-known/agent-card.json，描述 Agent 的身份、能力、端点和认证方式。

Agent Card 包含：

身份信息：Agent 名称、描述、提供者、协议版本

skills 数组：每个 skill 有 id、name、description、tags、examples——声明"我能做什么"

capabilities 对象：streaming、pushNotifications、extendedAgentCard 等——声明"我支持什么交互模式"

端点和传输：主 URL、preferredTransport、additionalInterfaces——声明"从哪里、用什么传输访问我"

认证与安全：securitySchemes、security、signatures——声明"调用我需要什么凭据，Card 如何验证"

v0.3.0 之后尤其要注意一点：Agent Card 不只是"一个 URL + 一组 skills"。它还承担了传输协商和安全声明的职责。Client 不能只读 url 就开始调用，而应该检查 preferred transport、additional interfaces、securitySchemes 和 signatures，确认自己和目标 Agent 在协议版本、传输方式、认证模型上真正兼容。

Task 是 A2A 的核心交互单元。一个 Task 的生命周期：

图 4: A2A Task 状态机。submitted → working → completed/failed/canceled/rejected，支持 input-required 中间状态。

关键状态转换：

submitted → working：Agent 接受任务，开始执行

working → input-required：Agent 需要用户澄清，暂停任务等待输入

working → completed：任务完成，返回 Artifact

working → failed：任务失败，返回错误信息
working → canceled：Client 主动取消任务

submitted → rejected：Agent 拒绝任务（能力不匹配、资源不足等）

input-required 状态很有意思——它让 Agent 可以在执行过程中"问问题"，而不是预设所有参数。这比 MCP 的工具调用更灵活：MCP 工具需要一次性提供所有参数，A2A Agent 可以边做边问。

Message / Part / Artifact 是 A2A 的数据模型：

Message：Agent 间通信的消息，包含多个 Part

Part：TextPart / FilePart / DataPart——支持多模态（文本、文件、结构化数据）

Artifact：Task 的最终产出物，可以包含多个 Part

一个端到端协作示例

用一个企业内部场景把 A2A 和 MCP 串起来会更直观。

用户对客服 Agent 说：“上周那个企业客户又反馈接口超时，你帮我查一下是不是我们最近发布导致的。”

这句话背后至少包含四个子任务：

1. 客服 Agent 需要从工单系统里找到客户、时间范围和问题描述

2. 运维 Agent 需要查询对应时间段的错误率、延迟和发布记录

3. 代码审查 Agent 需要检查相关服务最近的代码变更

4. 客服 Agent 需要把技术结论翻译成客户可理解的回复

如果只用 MCP，客服 Agent 可以调用工单工具、监控工具、代码工具，但它仍然要自己规划所有步骤，自己理解每个工具的返回，并承担跨域判断。随着工具增多，它会变成一个"超级 Agent"，上下文越来越大，失败面也越来越大。

如果引入 A2A，客服 Agent 可以把"排查服务超时原因"作为 Task 委托给运维 Agent，把"检查相关代码变更"委托给代码审查 Agent。运维 Agent 内部再通过 MCP 连接 Prometheus、日志平台和发布系统；代码审查 Agent 内部通过 MCP 连接 GitHub、CI 和代码搜索。客服 Agent 不需要知道 Prometheus 查询语法，也不需要知道代码审查 Agent 用什么框架实现，只需要跟踪 Task 状态、接收 Artifact，然后汇总成最终回复。

这个例子体现了两个边界：

A2A 边界：谁负责某个子任务，子任务状态如何，最终产物是什么

MCP 边界：某个 Agent 为了完成子任务，需要调用哪些工具和数据源

当系统规模很小时，这个拆分可能显得"重"。但当 Agent 分属不同团队、不同框架、不同权限域时，这个边界会显著降低集成复杂度。

传输与安全

A2A 复用 Web 基础设施，但不再只能理解成"HTTP + JSON-RPC + SSE"。在 v0.3.0 规范中，A2A 支持 JSON-RPC 2.0、gRPC、HTTP+JSON/REST 等传输，并要求不同传输在语义上保持功能等价。SSE 主要承担流式更新能力，gRPC 也可以使用原生 streaming。

长时间运行的任务，Client 可以选择：

轮询：定期查询 Task 状态

SSE 流式：实时接收状态更新

Push Notification：Webhook 回调，Agent 主动通知 Client

这带来一个工程判断：企业内部系统可以优先用 JSON-RPC 或 HTTP+JSON，方便调试、审计和网关接入；已有 gRPC 基础设施的团队可以用 gRPC 复用服务治理能力；面向浏览器或低门槛集成时，HTTP+JSON/REST 更容易被普通 Web 工程团队接受。协议的重点不是"哪种传输最高级"，而是同一个 Agent Card 能否把可用传输声明清楚，让 Client 有稳定的选择规则。

认证方面，A2A 支持 OpenAPI 兼容的认证方案，包括 In-Task 二次认证——Agent 可以在任务执行过程中要求 Client 提供额外的认证信息（比如访问敏感数据时要求二次验证）。

举个例子：采购 Agent 接到"查询供应商合同风险"的任务后，前两步只需要普通企业 SSO；但当它准备读取合同原文或调取付款记录时，可以把 Task 切到 input-required，要求 Client 触发二次认证或补充审批凭据。认证因此不再只是"连接前一次性完成"，而是可以成为任务执行过程的一部分。

发现机制

A2A 支持三种 Agent 发现方式：

1. Well-Known URI：/.well-known/agent-card.json——最简单，类似 robots.txt。你只需要知道 Agent 的域名，就能获取它的 Agent Card

2. Registry / Directory：集中式 Agent 目录——企业内部常用。所有 Agent 注册到一个中心目录，Client 从目录查询

3. DNS-based：通过 DNS SRV 记录发现——ANP 的方案，适合开放互联网场景

2026 年新增了 Agent Card 签名：验证 Card 完整性，防止中间人篡改。这在开放互联网场景中特别重要——你从第三方获取的 Agent Card 可能被篡改，签名可以验证其真实性。

图 5: Agent Card 发现与交互序列。Client 通过 Well-Known URI/Registry 发现 Agent，获取 Agent Card，然后创建 Task 并交互。

生产环境里，不应该把 Agent Card 当成"能解析的 JSON"就直接信任。更合理的做法是把它当成一个可验证的能力合约：

校验项	要回答的问题
身份与来源	provider 、签名、公钥链路是否能证明这个 Agent 真是它声称的服务？
端点可信度	URL 域名、TLS 证书、网络边界是否与企业信任策略一致？
认证模型	securitySchemes 是否覆盖调用、流式订阅、Push Notification 等不同交互？
能力范围	skills 是否足够具体，是否能映射到内部权限和审批策略？
版本与传输	协议版本、transport、streaming/push 能力是否与 Client 兼容？
失效策略	Agent Card 是否有缓存、轮换、撤销和降级策略？

这张表的意义很实际：A2A 让 Agent 之间可以"发现彼此"，但发现不等于信任。只要 Agent 能被动态发现，就必须同时设计动态信任和动态撤销。

Agent Card 还需要生命周期管理。一个生产级 Agent Card 至少要覆盖五个阶段：

阶段	关键动作	常见风险
发布	生成 Card，声明 skills、transport、securitySchemes、signatures	描述过宽，导致错误路由
缓存	Client 或 Registry 缓存 Card，减少发现延迟	缓存过期后仍调用旧端点
灰度	新版本 Card 只对部分 Client 或租户可见	新旧 skills 混用，产物格式不一致
轮换	端点、密钥、签名、公钥链路更新	签名验证失败或旧 Client 无法调用
撤销	下线 Agent、禁用 skill、移除高风险能力	撤销传播慢，仍有 Client 调用旧能力

因此，Agent Card 不应该由某个服务随手生成后就长期不管。更稳妥的方式是把它纳入发布流程：和代码版本、Prompt 版本、权限策略一起评审、发布、回滚。对企业内部 Registry 来说，Agent Card 甚至可以看成 Agent 的"生产准入许可证"。

治理与生态

A2A 由 Google 于 2025 年 4 月发布，50+ 技术伙伴支持。2025 年 6 月捐赠给 Linux Foundation，创始成员包括 AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNow。

当前版本 v0.3.0，Apache 2.0 许可。100+ 公司验证或集成，SDK 覆盖 Python、JS/TS、Java、Go、C#。

注意版本号——v0.3.0 意味着 API 可能变更。生产使用需要锁定版本，做好升级准备。

A2A 也没有解决所有问题。它假设 Agent 可以通过能力声明被发现、通过 Task 被委托，但不负责定义 Agent 内部怎么规划、怎么调用工具、怎么保证结果质量。它还默认存在某种可接受的信任边界：企业内部目录、注册中心、签名 Agent Card、统一认证系统。到了开放互联网场景，身份、信誉、滥用防护和跨组织治理会立刻变成更大的问题，这也是 ANP 这类协议继续探索的空间。

---

ACP 并入 A2A：协议收敛的案例分析

2025 年 8 月，IBM Research 和 BeeAI 团队发布的 ACP（Agent Communication Protocol）正式并入 A2A。这是 Agent 协议领域第一个重要的收敛事件，值得拆解。

ACP 的设计理念

ACP 于 2025 年 3 月发布，核心设计理念是"简单"——开发者只需 cURL 或 Postman 即可使用，不需要专门的 SDK。

ACP 的架构是三层联邦模型：

语义层：意图映射 + SLA 协商——Agent 协商"我需要什么"和"你能提供什么"

联邦发现层：去中心化注册 + DID 身份验证——基于 W3C DID 标准的身份系统

传输层：RESTful HTTP + MIME 多类型消息——标准 HTTP，无特殊协议

ACP 还有一个特色：本地优先（local-first）。它针对云连接受限、不可靠或合规禁止的场景设计——Agent 可以在本地网络内通信，不需要互联网连接。

为什么并入 A2A？

四个驱动力：

1. 避免标准碎片化：ACP 和 A2A 解决的是同一个问题（Agent 间通信），分裂会损害生态。开发者不想在两个相似协议之间做选择

2. 加速协议发展：合并资源，统一社区。IBM 的工程力量可以加速 A2A 的成熟

3. 技术互补：ACP 的本地优先和 DID 身份验证能力可以增强 A2A。A2A 目前假设 Agent 在企业边界内，ACP 的去中心化身份可以扩展 A2A 的适用范围

4. 统一生态：IBM 本身是 A2A 的创始成员，ACP 并入 A2A 是自然的选择

图 6: ACP 并入 A2A 的时间线。2025.3 ACP 发布 → 2025.4 A2A 发布 → 2025.8 ACP 并入 A2A → 迁移路径 acp_sdk → beeai_sdk。

迁移路径

从 ACP 迁移到 A2A 的关键变更：

acp_sdk → beeai_sdk：SDK 更换

Metadata → AgentDetail：元数据模型对齐 A2A 的 Agent Card

消息处理和扩展系统：更新为 A2A 的 Message/Part/Artifact 模型

但真实迁移不应该从"替换 SDK"开始，而应该从能力盘点开始。一个更稳妥的迁移路径是：

能力盘点 → Agent Card 建模 → 双栈适配 → 流量灰度 → 观测对齐 → 旧协议退役

每一步要回答的问题不同：

阶段	要做什么	退出条件
能力盘点	列出现有 ACP Agent 的能力、输入、输出、权限和 SLA	每个能力都能映射到 A2A skill 或明确废弃
Agent Card 建模	把 Metadata/AgentDetail 转成 A2A Agent Card	Card 能被 Client 发现、验证和路由
双栈适配	同一个 Agent 同时支持旧 ACP 调用和 A2A 调用	两条路径结果一致，Trace 能关联
流量灰度	逐步把低风险 Client 切到 A2A	错误率、延迟、产物格式无明显退化
观测对齐	对齐 Task 状态、错误分类、成本和审计字段	新旧协议指标可比较
旧协议退役	冻结 ACP 新能力，设置下线窗口	所有生产调用已迁移或有豁免记录

迁移的核心风险不是"新协议能不能跑"，而是语义漂移。比如 ACP 里的"任务完成"和 A2A 的 completed 是否等价？ACP 的本地优先身份模型如何映射到 A2A 的 securitySchemes？旧系统里的 SLA 协商是否需要变成 Agent Card 的 skill 描述，还是进入 Registry 的策略层？这些问题不处理，迁移就会变成"接口换了，语义乱了"。

对选型的启示

三句话总结：

新项目直接用 A2A，不要考虑 ACP

现有 ACP 实现应规划迁移，但不必急于重写——ACP 和 A2A 可以共存

协议收敛是常态：关注 Linux Foundation 的统一治理，而非单个公司的协议

这个案例也揭示了一个规律：在协议的早期阶段，多个竞争协议是正常的；但随着生态成熟，收敛到一个统一标准几乎是必然的——因为互操作性的价值远大于差异化的价值。

---

ANP 与去中心化身份：前沿实验

ANP（Agent Network Protocol）探索的是一个更远的问题：如果 Agent 不在企业边界内，而是在开放互联网上，它们如何安全地发现和连接彼此？

ANP 由 Gaowei Chang 于 2024 年创建，MIT 许可。核心目标：互联网规模的去中心化 Agent 网络。

两个关键特性：

去中心化身份：基于 W3C DID 标准。每个 Agent 有一个 DID 标识符，不需要中心化的身份提供商。这和 MCP 的 OAuth 2.1、A2A 的 OpenAPI 认证完全不同——后两者都假设有一个中心化的授权服务器。

元协议协商（meta-protocol negotiation）：Agent 可以动态协商使用哪种通信协议。比如两个 Agent 初次连接时，先协商"我们用 A2A 还是 MCP 还是别的"，然后按协商结果通信。这比"所有 Agent 必须用同一个协议"更灵活。

ANP 和 A2A 的根本区别：A2A 假设 Agent 在企业边界内（有防火墙、有 SSO、有内部网络），ANP 假设 Agent 在开放互联网上（没有信任前提、没有共享基础设施）。

成熟度评估：ANP 仍处于实验阶段，没有大规模生产部署。去中心化身份和元协议协商是有价值的探索方向，但标准化和互操作性挑战巨大。对大多数企业场景，MCP + A2A 的组合已经足够。

---

协议栈视角：分层互补而非竞争

回到核心问题：MCP、A2A、ANP 是竞争关系吗？不是。它们是 Agent 通信栈的不同层次。

四层协议栈模型

层次	协议	解决的问题	类比
L4 身份与发现	ANP	去中心化身份、元协议协商	DNS
L3 Agent 协作	A2A	Agent 间任务委托、能力发现	TCP/IP
L2 工具连接	MCP	模型-工具/数据源连接	USB
L1 传输基础设施	Pilot Protocol / HTTP	网络层连接、NAT 穿透	以太网/WiFi

关键洞察：A2A Server 内部可能使用 MCP 来完成任务。比如一个 A2A Agent 接收到"查询客户信息"的任务后，可能通过 MCP 连接到 Salesforce MCP Server 获取数据。MCP 和 A2A 是组合使用，而非二选一。

四种组合模式

1. MCP only：单 Agent + 多工具，不需要 Agent 间协作。最简单的起步方案

2. A2A + MCP：多 Agent 协作，每个 Agent 内部用 MCP 连接工具——最常见的生产模式

3. A2A only：Agent 间协作，但工具连接用自定义 API——已有遗留系统时

4. ANP + A2A + MCP：去中心化身份 + Agent 协作 + 工具连接——开放互联网场景（实验性）

"全栈 Agent"的协议组合

一个完整的多 Agent 系统的协议调用链：

用户请求 → A2A Client（发现并委托任务）
         → A2A Server（接收任务，决定如何完成）
           → MCP Client（连接工具和数据源）
             → MCP Server（执行具体操作）

A2A 负责 Agent 间的"谁做什么"，MCP 负责 Agent 内部的"怎么做"。两者组合，才是一个完整的多 Agent 通信方案。

把这条调用链落到工程实现上，最容易出问题的不是"协议能不能调通"，而是边界契约是否清楚。建议在 A2A + MCP 组合中显式定义以下映射关系：

边界	A2A 侧	MCP 侧	设计要点
任务语义	Task、Message、Artifact	Tool call、Resource、Prompt	A2A 描述"要完成什么"，MCP 描述"调用什么能力完成"
身份凭据	Agent 之间的认证与授权	工具/数据源访问凭据	不要复用同一 token，避免 Agent 委托扩大工具权限
追踪链路	Task id、Message id	MCP request id、Session id	统一注入 trace id，才能跨 Agent 和工具定位失败
错误传播	failed 、input-required、rejected	JSON-RPC error、工具异常	工具错误不一定等于任务失败，需区分可重试、需澄清、不可恢复
产物交付	Artifact / Part	Tool result / Resource content	明确哪些工具结果会进入最终 Artifact，哪些只用于中间推理

这个映射表可以直接变成接口评审清单。否则系统上线后很容易出现一种尴尬：A2A 看起来任务失败了，MCP 看起来工具调用成功了，最后没人知道责任边界在哪里。

图 7: 全栈 Agent 的协议组合。A2A 负责 Agent 间任务委托，MCP 负责 Agent 内部工具连接。

---

互操作性的三个层级：能连、能懂、能管

谈 Agent 协议时，"互操作"这个词很容易被说得过于轻巧。两个系统能发 HTTP 请求，不等于互操作；能解析 JSON，也不等于互操作。生产里的互操作至少有三个层级。

第一层：能连

能连解决的是传输层问题：Client 能找到 Server，能完成认证，能发请求，能收到响应。

这一层看起来最基础，但也是 demo 最容易停留的层次。很多协议集成的第一周都能完成"能连"：拿到一个 endpoint，发一个 JSON-RPC 请求，拿到一个 completed 状态或工具返回。问题是，能连只证明网络和格式正确，不证明系统真的能协作。

这一层的关键检查项包括：

endpoint 是否可发现，发现结果是否可缓存和撤销

认证是否支持服务间调用、用户代理调用和二次授权

请求超时、重试、取消、流式响应是否有明确行为

协议版本不兼容时如何降级或拒绝

第二层：能懂

能懂解决的是语义层问题：调用方能否正确理解对方的能力、输入、输出和限制。

MCP 的 Tool Schema、A2A 的 Agent Card、skills、Message/Part/Artifact 都在解决这一层。但 Schema 只能描述形状，不能完全描述语义。比如一个 Agent Card 声称自己支持 code_review，它到底是做风格检查、安全审计、架构评审，还是自动修复？如果描述不清，调用方就会把错误任务委托给正确协议下的错误 Agent。

这一层的关键不是字段越多越好，而是能力声明要能支持路由决策。一个好的 skill 描述应该包含：

适合处理的任务类型

不适合处理的边界

输入要求和必要上下文

输出产物的格式和可信度

典型示例和反例

第三层：能管

能管解决的是治理层问题：系统出问题时，能不能审计、限权、回滚、下线和追责。

这也是很多 Agent 协议讨论最容易缺失的一层。只要 Agent 可以动态发现、动态调用、动态委托，就必须能动态治理。否则互操作性越强，风险扩散也越快。

能管至少包含五类能力：

治理能力	典型问题
权限治理	谁可以调用这个 Agent？这个 Agent 可以访问哪些工具？
成本治理	每个 Task 的 Token、工具调用、外部 API 成本是否有预算？
质量治理	Agent 输出是否需要 Judge、规则校验或人工审批？
审计治理	每次委托、工具调用、产物生成是否能追溯？
生命周期治理	Agent Card 更新、撤销、下线和版本迁移由谁负责？

所以，协议选型不能只问"这个协议支持什么字段"，还要问"这个协议让我们怎么治理一个越来越大的 Agent 网络"。MCP 和 A2A 的价值都不只是调用格式，而是把治理对象变得可见：MCP 让工具能力可见，A2A 让 Agent 能力可见。

---

协议选型决策框架

理论讲完了，怎么选？

场景驱动的选型矩阵

场景	协议组合	理由
单 Agent + 内部工具（<10）	MCP	简单直接，stdio 传输零配置
单 Agent + 外部 API	MCP（Streamable HTTP）	远程连接，OAuth 2.1 授权
多 Agent 协作（同框架）	框架内置通信	LangGraph subgraph / CrewAI manager，无需跨框架协议
多 Agent 协作（跨框架）	A2A + MCP	A2A 解决 Agent 间通信，MCP 解决工具连接
企业多租户	A2A + MCP + OAuth 2.1	A2A 的 Agent Card 发现 + MCP 的企业授权
开放互联网 Agent	ANP + A2A + MCP（实验性）	去中心化身份 + Agent 协作 + 工具连接

选型决策树

1. 是否需要 Agent 间协作？ 否 → MCP only

2. Agent 是否跨框架/跨组织？ 否 → 框架内置通信

3. 是否需要去中心化身份？ 是 → ANP + A2A + MCP（实验性）

4. 默认 → A2A + MCP

图 8: 协议选型决策树。从"是否需要 Agent 间协作"开始，逐步缩小协议组合范围。

风险提示

A2A 仍处于 v0.3.0，API 可能变更——生产使用需要锁定版本，做好升级准备

MCP 的 Streamable HTTP 传输在 2025-11-25 才稳定，旧版 HTTP+SSE 已废弃——新项目直接用 Streamable HTTP

ANP 仍处于实验阶段，不建议生产使用

协议组合增加系统复杂度——只在确实需要跨框架/跨组织协作时才引入 A2A，不要为了"用协议"而用协议

上线前可以用一个更硬的检查清单收口：

1. 协议版本是否锁定，并有升级回滚方案？

2. Agent Card 是否验证签名、端点、认证方式和能力范围？

3. A2A Task id、MCP Session id、工具调用 id 是否能串成同一条 Trace？

4. Agent 之间的凭据和 Agent 内部工具凭据是否隔离？

5. 对 input-required、超时、拒绝、工具失败是否有统一用户体验？

6. 当目标 Agent 不可达时，系统是重试、降级、转人工，还是直接失败？

7. 每个 Agent 的治理责任人是谁，谁能下线、撤销或更新它的能力声明？

企业落地路线图

如果从零开始建设企业级 Agent 通信体系，不建议一上来就铺满 MCP、A2A、Registry、ANP。更稳的路线是分四个阶段推进。

阶段一：工具标准化

先把高价值、低风险、只读为主的能力做成 MCP Server。例如知识库检索、工单查询、配置读取、日志摘要。目标不是让所有 API 都变成工具，而是沉淀一套 Tool 设计规范：命名、参数、返回摘要、错误分类、权限过滤、Trace 注入。

阶段二：单域 Agent 协作

在一个业务域内引入 A2A，比如客服域、研发域、运维域。所有 Agent 仍在同一个信任边界内，统一 SSO、统一日志、统一 Registry。这个阶段重点验证 Task 状态、Artifact 格式、input-required 交互和失败处理。

阶段三：跨域 Agent 目录

当多个业务域都有 Agent 后，再建设集中 Registry / Directory。此时治理重点从"能不能调用"变成"能不能发现正确对象"：Agent Card 审核、skill 分类、权限审批、版本管理、撤销机制都要进入平台流程。

阶段四：跨组织或开放网络探索

只有当企业内部的身份、审计、预算、质量门禁都跑顺后，再考虑 ANP、DID 或开放互联网 Agent。否则开放发现只会放大内部治理缺口。

可以把每个阶段的目标压缩成一句话：

阶段	目标	主要协议
工具标准化	让模型安全调用工具	MCP
单域协作	让同一业务域内 Agent 分工	A2A + MCP
跨域目录	让 Agent 能被治理性发现	A2A Registry + MCP
开放探索	让跨组织 Agent 建立身份和信任	ANP + A2A + MCP

这条路线的好处是每一步都有清晰收益，也能避免"为了上协议而重构全部系统"。

---

典型故障模式：协议打通之后还会怎么失败

协议打通只是开始。真正的生产故障往往发生在"协议层看起来没错，但系统行为错了"的地方。

故障一：能力声明过宽

一个 Agent Card 写着"支持数据分析"，调用方就把财务报表、用户增长、日志排障、AB 实验全都委托给它。结果 Agent 在自己并不擅长的领域也接受任务，最后产物质量不稳定。

治理策略是把 skill 写窄：从"数据分析"改成"面向产品指标的漏斗分析"、“面向服务稳定性的日志聚合分析”。同时允许 Agent 在 submitted 阶段拒绝任务，而不是硬着头皮执行。

故障二：工具权限被委托放大

A Agent 有调用 B Agent 的权限，B Agent 有访问生产数据库的 MCP 权限。一次看似普通的 A2A 委托，可能间接让 A 获得了本不该拥有的数据访问路径。

治理策略是把 Agent 间认证和工具访问认证分开。A2A 委托只证明"可以把任务交给 B"，不自动证明"可以使用 B 背后的所有工具权限"。涉及敏感数据时，B 应该触发 In-Task 二次认证或审批。

故障三：状态语义不一致

A2A Task 显示 completed，但 Artifact 只是"部分完成"；MCP Tool 返回 success，但业务操作实际进入异步处理队列。调用方看到成功状态后继续下一步，最后造成错误决策。

治理策略是统一状态语义：completed 必须意味着调用方可以消费最终产物；如果只是接受请求，应返回 working 或中间状态。工具返回也要区分"请求已受理"和"业务已完成"。

故障四：错误被过度抽象

底层 MCP Tool 报权限不足，A2A Agent 只向上返回"任务失败"。调用方不知道是该重试、补充认证、换 Agent，还是告诉用户无法完成。

治理策略是定义错误分类：可重试错误、需用户补充输入、需二次授权、能力不匹配、不可恢复错误。错误不需要暴露所有内部细节，但必须保留足够的决策信息。

故障五：Trace 断裂

一个用户请求跨越三个 Agent、十几个 MCP Tool，最后输出错误。每个系统都有自己的日志，但没有共享 trace id。排查时只能靠时间戳猜测，问题定位从分钟级变成小时级。

治理策略是在 A2A Task 创建时生成全局 trace id，并在 MCP 调用、工具执行、Artifact 生成、用户反馈中持续传播。Trace 不是可观测性的"高级功能"，而是多 Agent 系统的基本生存条件。

故障六：传输能力不一致

Agent Card 声明支持多个 transport，但不同 transport 的行为不完全一致：JSON-RPC 路径支持 streaming，REST 路径不支持；gRPC 路径返回的错误码比 HTTP 路径更细；某些 Client 只测试了其中一条路径。结果是"同一个 Agent，不同 Client 调出来像两个 Agent"。

治理策略是做协议一致性测试。每个暴露的 transport 都要跑同一组任务样本，检查 Task 状态、Artifact 结构、错误分类、认证失败行为是否一致。additionalInterfaces 不是装饰字段，声明了就意味着要承担一致性责任。

故障七：Registry 变成新的单点

集中 Registry 能降低发现成本，但也可能变成新的单点故障：Registry 不可用时 Client 无法发现 Agent；Registry 数据过期时 Client 调用旧端点；Registry 审核过松时低质量 Agent 混入生产目录。

治理策略是把 Registry 当成控制平面，而不是唯一运行时依赖。Client 应该缓存已验证的 Agent Card，并有明确 TTL 和撤销检查；Registry 需要健康检查、审计日志、审批流和回滚能力。对核心 Agent，可以配置静态兜底端点，避免 Registry 短暂故障导致全链路不可用。

---

前沿方向：协议融合与 Agent 互联网

三个值得关注的趋势：

MCP Agentic Server 模糊了工具和 Agent 的边界。2025-11-25 版本的 Sampling with Tools 让 MCP Server 自身可以调用 LLM——一个"工具"本身可能就是一个 Agent。这意味着 MCP Server 可能同时是 A2A Agent，两个协议的边界在模糊。未来可能出现标准化的"A2A-over-MCP"组合模式：A2A 负责任务委托，MCP 负责工具调用，但同一个进程同时扮演两个角色。

协议治理的统一。MCP 和 A2A 都在 Linux Foundation 下，未来可能进一步整合治理流程。一个可能的演进方向是：MCP 和 A2A 共享同一个发现机制（MCP Registry + A2A Agent Card 合并），共享同一个安全模型（OAuth 2.1 统一授权），只在交互模式上保持差异。

Agent 互联网的协议栈。ANP 的去中心化身份 + A2A 的 Agent 协作 + MCP 的工具连接，可能构成"Agent 互联网"的协议栈——但这是 3-5 年的远景。当前的瓶颈不在协议本身，而在身份信任、安全策略和治理结构的跨组织协调。

---

总结：协议不是目的，互操作才是目的

回到开头的"巴别塔"问题。三个 Agent 无法互操作，不是因为缺少协议，而是因为缺少正确的协议——MCP 连接工具，A2A 连接 Agent，ANP 连接网络。

一句话总结：Agent 通信协议不是"选一个赢者"，而是"选对的层"。

你需要连接工具和数据源？用 MCP——它是模型-工具连接的 USB 接口

你需要 Agent 间协作？用 A2A——它是 Agent-Agent 协作的 TCP/IP

你需要去中心化身份？关注 ANP——但它仍在实验阶段

你需要两者？A2A + MCP 组合——最常见的生产模式

ACP 并入 A2A 的案例告诉我们：协议收敛是常态，互操作性的价值远大于差异化的价值。选型时关注 Linux Foundation 的统一治理，而非单个公司的协议。

最后，不要为了"用协议"而用协议。如果你的 Agent 都在同一个框架内，框架内置的通信机制可能比 A2A 更简单。协议的价值在于跨框架、跨组织的互操作——只有在这个场景下，引入 A2A 才是值得的。

---

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？