2025年4月，Google在Cloud Next’25大会上发布了一个看似低调、实则可能改变整个AI行业格局的开放协议——A2A（Agent-to-Agent Protocol）。一年后，这个协议已经从Google的单方面提案，演变为Linux基金会托管的、拥有150+组织贡献的行业标准，官方SDK覆盖6种编程语言，合作伙伴超过50家（包括Salesforce、SAP、Atlassian、PayPal等企业级巨头）。
与此同时，Anthropic推出的MCP（Model Context Protocol）正在成为”Agent连接工具”的事实标准。两个协议的出现，让很多人产生了同一个疑问：A2A和MCP到底是什么关系？它们是竞争还是互补？
本文将从协议设计、技术架构、代码实现、行业生态四个维度，深度拆解A2A协议。无论你是AI应用开发者、企业架构师，还是纯粹的技术观察者，这篇文章都值得你花10分钟读完。
一、为什么需要A2A？AI Agent的”巴别塔”困局
2026年，AI Agent已经从概念验证走向生产部署。但一个根本性问题始终没有得到解决：不同框架、不同厂商构建的Agent之间无法互相通信。
想象一个真实场景：你想让一个”差旅规划Agent”帮你完成出差安排。这个Agent需要调用”日历Agent”查看你的日程、调用”机票Agent”搜索航班、调用”酒店Agent”预订房间、调用”报销Agent”提交费用。问题是——这些Agent可能分别由Google Calendar、Expedia、Booking.com和你的公司财务系统提供，它们运行在不同的框架上（LangChain、CrewAI、AutoGen、自研），使用不同的通信方式。
这就是AI Agent领域的”巴别塔”问题——每个Agent都在说自己的语言，彼此无法理解。在A2A出现之前，唯一的解决方案是为每一对Agent之间写一个定制的集成适配器，复杂度随Agent数量呈O(n²)增长。
A2A的核心愿景很简单：定义一种通用的”Agent间通信语言”，让任何Agent都能发现、理解并与任何其他Agent协作，无论它们运行在什么框架上。
二、A2A协议核心架构：四大支柱
A2A的设计哲学可以概括为四个词：开放、简单、企业级、可组合。协议建立在一个极其成熟的基础之上——JSON-RPC 2.0 + HTTP(S)，这意味着任何能发HTTP请求的系统都能参与A2A生态。
支柱一：Agent Card——Agent的”名片”
每个A2A Agent都通过一个标准化的Agent Card来宣告自己的存在和能力。Agent Card是一个JSON文件，发布在约定路径/.well-known/agent.json下，遵循Web标准的”well-known”发现机制。
一个Agent Card的典型结构如下：
{
"name": "TravelPlanningAgent",
"description": "专业的差旅规划智能体，支持机票、酒店、日程的协调安排",
"url": "https://travel-agent.example.com/a2a",
"version": "1.0.0",
"protocolVersion": "0.2.1",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{
"id": "flight-search",
"name": "航班搜索",
"description": "搜索并比较全球航班信息",
"tags": ["travel", "flight", "booking"]
},
{
"id": "hotel-booking",
"name": "酒店预订",
"description": "搜索和预订酒店",
"tags": ["travel", "hotel"]
}
],
"defaultInputModes": ["text/plain", "application/json"],
"defaultOutputModes": ["text/plain", "application/json"],
"provider": {
"organization": "TravelCorp",
"url": "https://travelcorp.com"
}
}
关键字段解读：
- name / description：人类可读的Agent标识，用于Agent发现时的初步判断
- url：A2A消息端点，客户端通过此URL发送JSON-RPC请求
- capabilities：声明Agent支持的高级特性（流式传输、推送通知等）
- skills：Agent的具体技能列表，每个skill有独立的ID、描述和标签，是Agent路由的核心依据
- defaultInputModes / defaultOutputModes：声明Agent接受的输入输出MIME类型
支柱二：Task——Agent协作的”工作单元”
A2A中的所有交互都围绕Task（任务）展开。当Agent A需要Agent B帮忙时，它会创建或发送消息到一个Task。Task是A2A的核心状态机，拥有一个精心设计的生命周期：
submitted → working → input-required → completed
↘ failed
↘ canceled
- submitted：任务已提交，等待Agent处理
- working：Agent正在执行任务
- input-required：Agent需要更多输入才能继续（这是A2A最精妙的设计之一——支持多轮对话式的Agent协作）
- completed：任务成功完成
- failed：任务失败
- canceled：任务被取消
每个Task包含三个核心数据载体：
- Messages：Agent之间的对话消息，每条消息有role（user/agent）和parts
- Artifacts：任务的产出物，比如生成的文件、分析结果等
- Parts：消息和产出物的基本单元，支持三种类型——TextPart（纯文本）、FilePart（文件引用或内联base64）、DataPart（结构化JSON数据）
支柱三：流式通信与推送通知
对于长时间运行的任务（比如一个Agent需要几分钟甚至更久才能完成），A2A提供了两种机制：
- SSE（Server-Sent Events）流式传输：客户端发送请求后，保持连接打开，Agent通过SSE逐步推送状态更新和部分结果。这对实时仪表盘和进度追踪至关重要。
- Push Notifications（推送通知）：对于超长任务，客户端可以注册一个Webhook URL，Agent在任务状态变化时主动推送通知。客户端无需保持长连接。
这两种机制的组合，使得A2A既能支持毫秒级的快速交互，也能支持跨越数小时甚至数天的异步任务协作。
支柱四：企业级安全模型
A2A的安全设计直接面向企业级部署场景：
- 传输层：强制HTTPS，所有通信加密传输
- 认证：支持API Key、OAuth 2.0 Bearer Token、mTLS双向证书认证
- 授权：Agent Card中可以声明所需的认证方式，客户端按需提供凭证
- 隔离：每个Task在独立的上下文中运行，Agent之间无法访问彼此的内部状态
三、A2A vs MCP：竞争还是互补？
这是2026年AI领域被问得最多的问题之一。答案是：它们解决的是完全不同层面的问题，不是竞争关系，而是互补关系。
用一个类比来理解：MCP像是”手”——让Agent能操作工具、访问数据、调用API；A2A像是”嘴”——让Agent能与其他Agent对话、协商、协作。
| 维度 | MCP（Anthropic） | A2A（Google） |
|---|---|---|
| 核心定位 | Agent ↔ 工具/数据（垂直连接） | Agent ↔ Agent（水平协作） |
| 协议基础 | JSON-RPC 2.0 + stdio/SSE | JSON-RPC 2.0 + HTTP(S) + SSE |
| 发现机制 | Server声明Resources和Tools | Agent Card（/.well-known/agent.json） |
| 核心概念 | Resources、Tools、Prompts | AgentCard、Task、Message、Artifact |
| 典型场景 | Agent调用数据库、读写文件、调用API | 多个Agent协调完成复杂任务 |
| 状态管理 | 无状态（每次调用独立） | 有状态（Task生命周期管理） |
| 发起方 | Anthropic（2024年11月） | Google（2025年4月） |
| 治理 | Anthropic主导 | Linux基金会（2025年6月捐赠） |
| SDK | Python、TypeScript | Python、TypeScript、Go、Java、C#、Rust |
在实际的Agent系统中，两者是同时存在、同时使用的。一个Agent通过MCP连接各种工具和数据源来增强自身能力，同时通过A2A与其他Agent通信来完成自己无法独立处理的子任务。Google官方和Anthropic都多次公开表示，A2A和MCP是互补关系。
更多关于AI Agent技术架构和生态的讨论，推荐阅读AI Agent 2026全面解读，其中详细分析了Agent的技术架构和六大落地场景。
四、动手实践：用Python构建一个A2A Agent
理论讲完了，让我们动手写代码。A2A官方提供了6种语言的SDK（Python、TypeScript、Go、Java、C#、Rust），下面以Python为例，演示如何从零构建一个A2A Agent Server，并让另一个Agent调用它。
4.1 安装SDK
pip install a2a-sdk
4.2 实现一个”翻译Agent”服务端
from a2a.server.apps import A2AServer
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.agent_execution import AgentExecutor
from a2a.types import (
AgentCard, AgentSkill, Message, TextPart, Task
)
# 定义Agent能力
agent_card = AgentCard(
name="TranslationAgent",
description="专业的多语言翻译Agent",
url="http://localhost:8000/a2a",
version="1.0.0",
skills=[
AgentSkill(
id="translate",
name="文本翻译",
description="将文本翻译为目标语言",
tags=["translation", "nlp", "language"]
)
],
defaultInputModes=["text/plain"],
defaultOutputModes=["text/plain"],
)
# 实现Agent执行逻辑
class TranslationExecutor(AgentExecutor):
async def execute(self, task: Task) -> Task:
# 获取用户输入
user_message = task.messages[-1]
source_text = user_message.parts[0].text
# 调用翻译API（这里简化为模拟）
translated = await self._translate(source_text, "en", "zh")
# 返回结果
task.artifacts.append(
Artifact(parts=[TextPart(text=translated)])
)
return task
async def _translate(self, text, src, tgt):
# 实际项目中调用DeepL/Google Translate等API
return f"[翻译结果] {text}"
# 启动A2A Server
handler = DefaultRequestHandler(
agent_card=agent_card,
executor=TranslationExecutor()
)
server = A2AServer(handler=handler, port=8000)
server.run()
4.3 从客户端调用Agent
from a2a.client import A2AClient
async def main():
client = A2AClient("http://localhost:8000/a2a")
# 发现Agent能力
card = await client.get_agent_card()
print(f"发现Agent: {card.name}")
print(f"技能: {[s.name for s in card.skills]}")
# 发送翻译请求
response = await client.send_message(
Message(
role="user",
parts=[TextPart(text="Hello, how are you today?")]
)
)
print(f"翻译结果: {response.artifacts[0].parts[0].text}")
这就是A2A的核心用法——服务端声明能力，客户端发现并调用。当多个这样的Agent互相发现、互相调用时，就构成了一个动态的”Agent协作网络”。
五、真实场景：多Agent协作的差旅规划
让我们看一个更贴近实际的场景。假设公司部署了以下A2A Agent：
- OrchestratorAgent：协调者，负责理解用户意图并分配子任务
- CalendarAgent：连接Google Calendar（通过MCP），查询和安排日程
- FlightAgent：连接航空公司API（通过MCP），搜索航班
- HotelAgent：连接酒店预订系统（通过MCP），预订房间
- ExpenseAgent：连接财务系统（通过MCP），提交报销
当用户对OrchestratorAgent说”帮我安排下周一到上海出差两天”时，协作流程如下：
- OrchestratorAgent解析意图，创建主Task
- 向CalendarAgent发送A2A消息：”查询下周一和周二是否有空”
- CalendarAgent通过MCP查询Google Calendar，返回”有空”
- 向FlightAgent发送A2A消息：”搜索周一早上北京→上海、周二晚上上海→北京的航班”
- FlightAgent通过MCP调用航空公司API，返回航班列表
- 向HotelAgent发送A2A消息：”预订周一晚上海酒店”
- 收集所有子任务结果，向ExpenseAgent提交费用汇总
- 返回最终方案给用户确认
注意这里的关键设计：每个Agent只负责自己擅长的一小块，通过A2A进行Agent间协调，通过MCP访问各自的工具和数据。这就是A2A + MCP组合的威力——水平协作 + 垂直能力 = 完整的Agent生态。
这种多Agent协作模式正在被各大平台采纳。Coze 3.0已经实现了多人多Agent协作能力，详见Coze 3.0多Agent协作时代。微信也上线了AI Agent能力，覆盖13亿用户，详见微信AI Agent深度分析。
六、A2A的生态版图：谁在用？
A2A自2025年4月发布以来，生态扩张速度惊人。截至2026年6月，核心参与者包括：
企业级合作伙伴（50+家）
- CRM/ERP：Salesforce、SAP、ServiceNow、Workday、UKG
- 协作工具：Atlassian（Jira/Confluence）、Box
- 金融支付：PayPal、Mastercard、Intuit
- AI平台：Cohere、LangChain、Google Cloud
- 数据库：MongoDB
框架集成
- LangChain / LangGraph：原生支持A2A Agent作为节点
- CrewAI（v0.80+）：支持将A2A Agent作为Crew成员
- Microsoft Agent Framework：支持A2A互操作
- AWS Strands：支持A2A协议集成
- Google ADK（Agent Development Kit）：原生A2A支持
- Dify：工作流中可嵌入A2A Agent调用
治理与开源
2025年6月，Google将A2A协议捐赠给Linux基金会，标志着A2A从Google主导的开源项目升级为行业共治的标准协议。目前已有150+组织贡献代码，协议版本已迭代至v1.0.1（2026年5月28日）。GitHub仓库（google/A2A）提供Apache 2.0许可下的全部代码和文档。
七、A2A的局限与未来
尽管前景广阔，A2A仍面临一些现实挑战：
- 信任问题：当Agent A调用Agent B时，A如何信任B的输出？当前协议没有内置的”Agent信誉”或”结果验证”机制，这在金融、医疗等高风险场景中是个隐患。
- 成本控制：多Agent协作意味着多次LLM调用，成本可能迅速膨胀。A2A协议本身不涉及成本优化，需要上层框架来处理。
- 状态同步：当多个Agent同时操作同一个Task时，状态冲突的解决机制还不够完善。
- 生态碎片化：虽然有Linux基金会治理，但各厂商的实现可能存在微妙的不兼容。”标准”的价值取决于”遵循标准的程度”。
- 安全审计：Agent之间的通信可能涉及敏感数据，目前缺乏标准化的审计日志和合规性框架。
不过，A2A团队已经在路线图中规划了这些能力的演进。随着更多企业投入生产使用，这些问题将逐步得到解决。
八、总结：A2A是AI基础设施的”TCP/IP时刻”
回顾互联网发展史，TCP/IP协议并不是最好的网络协议，但它是第一个让所有计算机能互相通信的开放标准。正是因为有了TCP/IP，才有了后来的HTTP、Web、移动互联网和云计算。
A2A正在扮演AI Agent领域的类似角色。它不追求完美，但追求开放、通用、可组合。当每一个Agent都能通过标准协议被发现、被调用、被组合时，AI的能力边界将不再受限于单个Agent的智能程度，而是扩展到整个Agent网络的集体智慧。
对于开发者和企业来说，现在正是投入A2A生态的最佳时机。协议已成熟（v1.0.1），SDK覆盖6种语言，主流框架都已集成，Linux基金会提供了长期治理保障。等到所有企业都接入A2A时再跟进，就已经太晚了。
延伸阅读：如果你正在构建Agent系统，以下文章值得一读——AI Agent 2026全面解读、DeepSeek V4.1与MCP协议、DeepSeek编程Agent四路横评、2026年6月AI大模型最新进展，从协议标准到实战落地，全面覆盖AI前沿动态。
📢 延伸阅读：A2A协议只是AI Agent浪潮的一部分。了解本周四大事件如何共同定义了AI Agent时代：AI Agent时代正式来临：一周四大事件揭示AI下半场走向
