MCP 给了 AI 手，A2A 给了 AI 同事：一文搞懂 2026 智能体时代的“两条协议“

MCP 给了 AI 手，A2A 给了 AI 同事：一文搞懂 2026 智能体时代的"两条协议"

如果 2024 年是"单个 AI Agent"元年，2025 年是多智能体框架混战，那 2026 年真正在发生的，是智能体之间开始"互相打电话"了。而这通电话用的标准，叫 A2A。

引子：我们造了一堆"聪明孤岛"

过去两年，智能体（Agent）像野草一样长出来：LangGraph、CrewAI、AutoGen、AgentScope、Google ADK……每个 SaaS 产品也都在塞一个自己的 Agent——你的 CRM 有一个，邮箱有一个，日历有一个，IDE 里还蹲着一个。

问题来了：它们互不说话。

你想让"客服 Agent"去问"账单 Agent"退个款，再让"库存 Agent"查下库存——对不起，得你这个人肉当中间层，把 prompt 从一个工具复制到另一个。我们造了一堆高度智能的"微服务"，却忘了发明连接它们的"HTTP"。

这正是 Google 在 2025 年 4 月甩出 A2A（Agent2Agent）协议 要解决的问题。到 2026 年 4 月它满一周岁时，这件事已经不再是 Google 的"实验"，而是一个有 150+ 组织、22000+ GitHub Star、三大云全面支持的生产级行业标准。

一、A2A 到底是什么？

一句话：

A2A 是一个开放协议，让任何框架、任何厂商、甚至任何公司搭出来的 AI 智能体，都能互相"发现对方、商量事情、把活派出去、把结果拿回来"——而且彼此不用共享内存、不用共享工具、不用暴露内部逻辑。

最直观的类比是 HTTP：HTTP 不管你后端是 Rails 还是 Go，它只定义"请求和响应长什么样"。A2A 对智能体干的事一模一样——它只管"Agent A 和 Agent B 之间的契约"，至于你用哪个 LLM、哪个框架、哪个数据库，它统统不关心。

它的底层其实很朴素：JSON-RPC 2.0 over HTTPS，长任务用 Server-Sent Events（SSE）流式推送。你的 Agent 只要能发 HTTP 请求、能解析 JSON，就能说 A2A 这门"普通话"。

三个核心原语

A2A 刻意把"表面积"做得极小，只定义三样东西：

1. Agent Card（智能体名片）
一个放在 https://你的域名/.well-known/agent.json 的 JSON 文件，相当于 Agent 的"领英主页"或"招聘启事"。它写清楚：我能干啥（skills）、你要给我什么输入、我能吐什么输出、怎么鉴权。

2. Task（任务）
这是工作的基本单元。一个 Task 有自己的生命周期：submitted → working → input-required（需要补充信息）→ completed / failed / canceled。因为智能体的活儿常常要跑很久，你不能 await 干等，得有状态机来追踪进度。

3. Artifact（产物）
Task 干完，真正交付的东西（一份报告、一段代码、一张图）就叫 Artifact，流式回传给调用方。

把这三样串起来：你的 Agent 读对方的 Agent Card → 发一个 Task → 对方边干边流式回报进度 → 干完返回一个 Artifact。这就是 A2A 的全部魔法。

二、A2A vs MCP：2026 最该搞清楚的一组关系

讲 A2A 绕不开 MCP（Model Context Protocol）。这两个名字总被放在一起比，但它们是互补的，不是对手。

那句流传很广的总结特别准：

MCP gives your agent hands. A2A gives your agents colleagues.

（MCP 给你的 Agent 一双手，A2A 给你的 Agent 一群同事。）

为什么它们不是"你死我活"？

因为再强的 Agent，也得同时面对两件事：一是得能操作世界（连工具），二是得能跟同伴协作（连其他 Agent）。 MCP 负责第一件，A2A 负责第二件。

举个真实场景：你说"帮我规划一趟旅行"。规划 Agent 用 A2A 把"订机票"派给航班 Agent、"订酒店"派给酒店 Agent；而航班 Agent 自己用 MCP 去调航司 API 和支付工具，酒店 Agent 用 MCP 去查预订数据库和地图服务。结果通过 A2A 作为 Artifact 回流，规划 Agent 拼成行程。

抽掉 MCP，Agent 没手；抽掉 A2A，Agent 是孤魂野鬼。 所以 2026 年企业架构师的共识是：把这两层叠在一起用，这就是默认的"智能体技术栈"。

三、它是怎么跑起来的？（一个最小例子）

光说概念太虚，看一眼真实的 A2A 长什么样。一个 Agent 的"名片"（Agent Card）大致是：

{
"name": "航班预订 Agent",
"description": "负责查询和预订机票",
"url": "https://flights.example.com/a2a",
"skills": [
{
"id": "search_flight",
"name": "查航班",
"description": "按出发地、目的地、日期查可用航班"
},
{
"id": "book_flight",
"name": "订机票",
"description": "下单并生成电子客票"
}
],
"authentication": { "schemes": ["Bearer"] }
}

另一个 Agent 读到这张卡，就知道"哦，这家伙能查航班、能订票、要用 Bearer Token 鉴权"，于是发一个 Task 过去。航班 Agent 异步干活，边干边推进度，最后把电子客票作为 Artifact 扔回来。整个过程，它完全不需要知道航班 Agent 内部用了哪个 LLM、哪个框架、连了哪几个 MCP 工具——这就是"保持不透明（opacity）"的价值：协作，但不泄露内部。

企业最喜欢这点：我的 Agent 问你的 Agent 一个问题，你的 Agent 把答案递回来，我的 Agent 对"你背后偷偷调了哪 47 个破工具"一无所知。安全和审计的边界，一下子就清晰了。

四、一周年盘点：它已经从"标准"变成"现实"

2026 年 4 月 9 日，Linux Foundation 公布了 A2A 一周年成绩单——这一年的进展，远超绝大多数企业协议：

• 150+ 支持组织（一年前刚发布时只有 50+ 家），包括 AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow 等巨头；
• 22000+ GitHub Star，核心仓库热度惊人；
• v1.0 稳定版发布——首个生产级规范，带来多协议支持、企业级多租户、现代化安全流；
• Signed Agent Cards（签名名片）：Agent 名片带加密签名，调用方先验真再信任，这一条直接打通了企业采购的信任关卡；
• AP2 支付协议（Agent Payments Protocol） 同步推出：让 Agent 能安全地"花钱办事"，已有 60+ 支付与金融机构支持；
• SDK 扩到 5 种语言：Python、JavaScript、Java、Go、.NET（一年前只有 Python 一个）；
• 三大云全面 GA：Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock AgentCore Runtime 原生支持，Google ADK 更是从一开始就内置。

一句话：A2A 已经跨过了"从规范到标准"那条最难的横沟。

五、什么时候该用 A2A，什么时候别用？

A2A 不是银弹。官方和社区都反复提醒，它适合这些场景：

• Agent 分属不同组织、不同平台；
• 服务独立部署，彼此不该共享内存；
• 任务是长时、对话式的（有中间状态、要异步回报）；
• 远程 Agent 需要实现自治，你不该窥探它内部；
• 框架无关很重要（一个 LangGraph Agent 派活给一个 CrewAI Agent）。

而下面这些情况，老老实实用普通 API 或内部函数更香：

• 操作简单、确定性强（比如查个配置项）；
• 延迟极度敏感，同进程调用就行；
• 两端共享同一套代码和内存，压根不需要"协商"；
• 一个强类型请求-响应契约就够用了。

Google ADK 自己都警告：对紧耦合、性能攸关的操作，强行上 A2A 反而帮倒忙。

六、观点：我们正在见证"智能体互联网"的地基

我把话说直白一点：

未来 AI 的竞争力，不在"谁的单一模型更全能"，而在"谁能把一群各有所长的 Agent 编排到一起"。 单 Agent 已经成了入场券，真正的护城河是编排——而 A2A 想当那个"连接组织"。

这个判断有几个支撑：

第一，孤岛成本已经高到不可忍。 企业不可能只用一个厂商的 Agent。采购用 SAP 的、客服用 Salesforce 的、研发用自己搭的——这些 Agent 必须能对话，否则每次对接都是一次定制集成。A2A 把"M×N 集成"压成"M+N"，和当年 HTTP、MCP 干的事一模一样。

第二，治理归 Linux Foundation 是定心丸。 一个由公司主导的标准，公司一撤资就凉。但 A2A 和 MCP 现在都在 Linux Foundation 的 Agentic AI Foundation 屋檐下，OpenAI、Anthropic、Google、Microsoft、AWS 都是成员——当你的三个最大竞争对手都坐在标准委员会里，通常意味着"格式大战"已经结束了。

第三，它正在从"通信"走向"经济"。 AP2 支付协议的推出是个信号：智能体不只要能聊天，还要能安全地替你花钱、结算、留痕。这一步踩下去，A2A 就进入了高信任、强监管的金融场景。

但挑战也摆在桌上

别被热度冲昏头。A2A 自己还没解决的硬骨头：Agent 之间的身份验证、信任与声誉系统、恶意 Agent 防范、跨厂商交易审计。Agent Card 能描述"我能干啥"，但描述不等于可信。延迟、成本、跨厂商可靠性的统一基准，目前也还没有。

给开发者的建议很明确： 今天你做 Agent，别再执着于把它养成"什么都会的上帝模型"——那是一条死路。反过来，把你的 Agent 当成一个 A2A Server 来设计：清晰定义它能接什么活、吐什么产物、怎么鉴权。会"接线"的人，才是下一个十年架构 Web 的人。

结语

2025 年我们还在争论"哪个多智能体框架最好用"。2026 年答案开始清晰：框架之争让位于协议之争——谁能成为那层"通用的连接"，谁就赢了。

MCP 解决了"Agent 怎么够到工具"，A2A 正在解决"Agent 怎么够到彼此"。两条协议合起来，一个"智能体互联网（Internet of Agents）"的雏形，已经看得见轮廓了。

下期如果你想看，我可以拆 AP2 支付协议——当 Agent 开始替你花钱，那才是真正刺激的地方。

觉得这篇有用？转发给一个正在被"Agent 互相不说话"折磨的同事。关注「AI Agent 实战指南」，我们只写用得上的。