中国吧 · AI 观察
「Agent 的通用语言」：MCP 与 A2A 协议如何重塑 AI 智能体生态
（本文为中文深度解读。点击右上角 中 / EN 按钮可切换查看英文概要）
一句话：MCP 与 A2A 是什么
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年 11 月开源的一项开放协议。它的目标很直接：给 AI 模型提供一个连接外部世界的统一接口——工具、数据库、文件系统、各类 API，都通过同一种方式接入。在此之前，每个 AI 应用都要为每个工具单独写对接代码，N 个模型乘以 M 个工具，就是 N×M 次重复劳动；MCP 把这件事变成「一次接入，处处可用」：工具方实现一个 MCP Server，任何支持 MCP 的模型客户端都能直接调用。
A2A（Agent2Agent Protocol）是 Google 在 2025 年 4 月发布的开放协议，解决的是另一个层面的问题：智能体与智能体之间如何互操作。一个用某框架构建的客服 Agent，如何把任务委托给另一个团队用不同技术栈构建的检索 Agent，并拿回结构化的结果？A2A 定义了智能体互相发现能力、交换消息、委托任务、流式返回结果的通用语言。该协议已交由中立的开源基金会托管，成为社区共建的开放标准。
两者分工：一个向下接工具，一个向上联智能体
两者经常被放在一起谈，但它们解决的是不同层级的问题，关系是互补而非竞争：
| 维度 | MCP | A2A |
|---|---|---|
| 解决的问题 | 模型如何调用外部工具与数据 | 智能体之间如何协作与互操作 |
| 连接方向 | 纵向：模型 → 工具 / 数据源 | 横向：Agent ↔ Agent |
| 参与者 | 模型客户端（Host）与工具服务器 | 对等的智能体，可跨厂商、跨框架 |
| 核心机制 | 工具调用、资源读取、提示模板（Tools / Resources / Prompts） | 能力名片（AgentCard）发现、任务对象、消息流 |
| 传输方式 | JSON-RPC，可走本地进程或 HTTP / SSE | JSON-RPC over HTTP，支持流式返回 |
| 一句话类比 | 像 USB-C：设备端统一插口，插上就能用 | 像 HTTP：让不同服务器互联互通 |
记住这个类比就够了：MCP 像 USB-C——不管充电器、硬盘、显示器是什么牌子，插口统一了就能用，它统一的是「模型使用工具」那一端；A2A 像 HTTP——不管服务器跑什么系统、谁家写的代码，只要都讲 HTTP，网页就能互联，它统一的是「智能体之间对话」那一端。在一个完整的智能体应用里，两者会同时出现：Agent 通过 MCP 调用工具干活，通过 A2A 把子任务分给别的 Agent。
对普通读者来说，记住分层就够了：当你看到某个 AI 应用宣称「支持 MCP」，意味着它能直接调用生态里现成的工具；当你看到「支持 A2A」，意味着它的智能体能和其他智能体组队干活。两个标签，代表两种连接能力。
为什么协议比模型更重要
模型每几个月就换代一次：更强、更便宜、上下文更长。今天最强的模型，明年可能只是基准线。押注某一个具体模型，就像在互联网早期押注某一家服务器厂商——赢面取决于别人，主动权不在自己手里。
协议一旦成为事实标准，沉淀下来的不是某个产品的市场份额，而是整个生态的连接关系。HTTP 没有规定网页长什么样，却定义了整个万维网；USB 没有规定设备做什么，却让外设生态爆发。MCP 与 A2A 正在对 AI 智能体做同样的事：把「模型能用什么工具」「智能体能和谁协作」从各家私有的对接，变成公共的基础设施。
对开发者和创业者来说，这意味着战略重心的转移：模型能力会快速商品化，真正的护城河长在生态位上——你提供的 MCP Server 被多少 Agent 调用，你的 Agent 能通过 A2A 接入多少协作网络。理解协议，就是理解下一轮生态卡位战的规则。
开发者落地路径：从接一个 MCP Server 开始
协议听起来宏大，落地可以很小。建议按这个顺序走，每一步都有即时回报：
- 先用起来：给自己的 AI 应用接入现成的 MCP Server——文件读写、数据库查询、网页抓取，社区都有现成实现。先体验「模型突然长出手」的感觉，这一步成本最低。
- 再封装出去：把你最擅长的能力（内部 API、专有数据源、特色工具）封装成一个 MCP Server。它立刻能被所有支持 MCP 的客户端调用——你的能力第一次有了跨应用的复用入口。
- 然后连别人：当你需要多个 Agent 分工（一个负责检索、一个负责写作、一个负责审核），用 A2A 让它们互相发现、委托任务、回传结果，而不是写一堆定制胶水代码。
- 安全先行：统一接口意味着统一的信任边界。给每个 MCP Server 最小权限——只读、限定目录、敏感操作二次确认，并记录完整的工具调用日志用于审计。协议放大能力，也放大风险。
风险与开放问题：协议的战争才刚刚开始
乐观之余要清醒：今天的协议生态远未到「大局已定」，至少有三团乌云：
- 标准之争还没结束：MCP 和 A2A 之外，各家大厂仍在推自己的私有协议与扩展。历史告诉我们，标准战争的结局往往是「一个胜出、多个长尾」，但在胜出之前，开发者要为多套协议并存、版本快速演进做好兼容预案。
- 碎片化与版本更迭：协议还在快速迭代，接口变化、能力扩展层出不穷。今天写死的对接，明天可能要重写。应对策略是把协议调用封装在适配层后面，不让它渗进业务核心。
- 安全是统一接口的另一面：当所有工具都走同一个协议通道，一个恶意的工具服务器就可能污染整条调用链——在模型读取的内容里夹带有害指令，诱导 Agent 执行越权操作。协议本身不解决信任问题：接入前审查来源、运行时最小权限、事后完整审计，一项都不能少。
展望：从「聪明的模型」到「互联的智能体社会」
回头看，每一次计算平台的跃迁都始于协议：PC 时代有 USB，互联网时代有 TCP/IP 与 HTTP，移动时代有应用商店的分发规范。AI 智能体时代的跃迁，始于 MCP 与 A2A 这样的互操作协议。
可以想象的终局是：无数专精的 Agent 在网上互相发现、谈判分工、协作完成任务，人类只下达目标，不再关心路径。那一天到来之前，所有提前把能力「协议化」的人——封装好 MCP Server、接入 A2A 协作网络——都会站在生态的上游。
协议不会让模型变聪明，但它决定了聪明的模型能调动多少外部力量。在智能体时代，连接能力就是智能本身的一部分。
常见问题 FAQ
MCP 和 A2A 到底是什么关系？
互补，而非竞争。MCP 管的是「纵向」连接——模型如何调用外部工具与数据；A2A 管的是「横向」协作——智能体之间如何互相发现、委托任务、交换结果。在一个完整应用里，一个 Agent 会同时扮演两种角色：作为 MCP 客户端调用工具干活，作为 A2A 参与者与其他 Agent 协作。记住 USB-C 与 HTTP 的类比，就不会把它们搞混。
普通开发者现在该学哪个？
从 MCP 开始。MCP 直接解决「让我的 AI 用上外部工具」这个最高频刚需，接入成本最低、社区生态也最成熟：先给自己的应用接上现成的 MCP Server，再把自己的能力封装成 Server 对外提供。当你开始搭建多智能体协作、需要跨团队甚至跨厂商的 Agent 互操作时，再引入 A2A。顺序是：先让单个 Agent 变强，再让一群 Agent 协作。
协议会取代 Agent 框架吗？
不会。它们在不同层级：框架解决「单个 Agent 内部如何思考、规划、记忆、调用工具」的工程问题，协议解决「不同系统之间如何对话」的互操作问题。现实的走向是框架内建对协议的支持——你的 Agent 框架会原生支持调用 MCP Server、通过 A2A 与其他 Agent 协作，而不是被协议消灭。选框架看开发效率，跟协议看生态位，两者都要跟。
协议生态最大的风险是什么？
两个：标准碎片化与安全。碎片化方面，多套协议并存、版本快速演进，今天写死的对接明天可能要重写，对策是把协议调用封装在适配层之后；安全方面，统一接口放大了供应链风险——一个恶意的工具服务器可能污染整条调用链，在模型读取的内容里夹带有害指令。对策永远是老三样：接入前审查来源、运行时最小权限、事后完整审计。