《Agentic Design Patterns》第 15 章导读：智能体间通信（A2A）

《Agentic Design Patterns》第 15 章导读：智能体间通信（A2A）

本文是对开源书籍《Agentic Design Patterns》第 15 章的解读与导读，内容忠实呈现原文，并附个人思考。
原书在线阅读：https://adp.xindoo.xyz/ ｜ 翻译项目代码仓库：https://github.com/xindoo/agentic-design-patterns

第 7 章我们聊了多智能体协作——多个智能体一起干活。但那章有个隐含前提：这些智能体都是同一个框架、同一个系统里的。

现实世界哪有这么规整？你可能用 LangChain 写了个数据分析智能体，我用 CrewAI 搭了个报告生成智能体，他用 Google ADK 做了个日历管理智能体……各搞各的，谁也不认识谁。

怎么让这些"不同出身"的智能体也能协作？这就需要一个通用的通信协议——就像人类世界的 HTTP 协议让各种网站能互相通信一样。

第 15 章讲的智能体间通信（Agent-to-Agent Communication，A2A），就是干这个的：用一套开放标准，让任何框架、任何公司的智能体都能互相说话、互相协作。

一、什么是 A2A：智能体世界的"通用语言"

A2A 协议是 Google 发起的一个开放标准，目标是让不同 AI 智能体框架之间能够通信和协作。不管你的智能体是用 LangGraph、CrewAI、Google ADK，还是别的什么框架做的，只要支持 A2A 协议，就能互相调用、互相配合。

这个协议的支持者阵容很豪华：Atlassian、Box、LangChain、MongoDB、Salesforce、SAP、ServiceNow……微软也计划把 A2A 集成到 Azure AI Foundry 和 Copilot Studio 中。这么多大公司一起支持，说明这个方向是行业共识。

为什么需要 A2A？因为现在的智能体生态太碎片化了。每个框架都有自己的一套，想把不同框架的智能体拼到一起，成本极高——你得为每个集成写定制代码，费时费力还不好维护。A2A 就是要解决这个问题，建立一个标准化的智能体协作生态。

二、A2A vs MCP：一对好搭档

看到这里你可能会问：“第 10 章不是讲了 MCP 吗？MCP 也是标准化协议，A2A 跟它有什么区别？”

书中专门对比了这两个协议——它们是互补关系，不是竞争关系。

图 1：A2A 和 MCP 的关系——MCP 管智能体与外部资源的交互，A2A 管智能体之间的协作。

简单区分：

• MCP（模型上下文协议）：面向"智能体 ↔ 外部工具/数据"。解决的是"智能体怎么调用外部能力"的问题，关注的是上下文构建和资源交互。
• A2A（智能体间通信）：面向"智能体 ↔ 智能体"。解决的是"智能体之间怎么协作"的问题，关注的是任务委派和协同工作。

一个是"智能体怎么用工具"，一个是"智能体怎么找其他智能体帮忙"——层次不同，各管一段。

三、A2A 的核心概念

A2A 协议建立在几个核心概念之上，理解了它们，你就理解了 A2A 的全貌。

核心参与者

A2A 里有三个主要角色：

• 用户：发起请求的人；
• A2A 客户端（客户端智能体）：代表用户去请求其他智能体干活的应用或智能体；
• A2A 服务器（远程智能体）：提供 HTTP 端点、处理请求、返回结果的智能体系统。它是"不透明"的——客户端不用知道它内部是怎么运作的，只要按协议调用就行。

Agent 卡片（Agent Card）

这是 A2A 里最核心的概念之一。Agent 卡片就是智能体的"身份证"+“能力说明书”，通常是个 JSON 文件，里面写了：

• 智能体叫什么、是干嘛的；
• 端点 URL 在哪、版本号是多少；
• 支持什么能力（流式传输？推送通知？）；
• 有哪些技能（每个技能的名字、描述、输入输出格式、示例、标签）；
• 需要什么认证方式。

给你看个例子就明白了：

{
"name": "WeatherBot",
"description": "提供准确的天气预报和历史数据。",
"url": "http://weather-service.example.com/a2a",
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": false
},
"authentication": { "schemes": ["apiKey"] },
"skills": [
{
"id": "get_current_weather",
"name": "获取当前天气",
"description": "查询任何地点的实时天气。",
"examples": ["巴黎现在天气怎么样？", "东京当前状况"]
}
]
}

有了 Agent 卡片，客户端智能体就能知道"这个智能体能干嘛、怎么调用、需要什么权限"——发现和交互都基于这张卡片。

Agent 发现

客户端智能体怎么找到服务器智能体？有三种策略：

跟互联网早期的"网站怎么被找到"很像——从直接配置到门户网站到搜索引擎，一步步演化。

通信与任务

A2A 的通信是围绕异步任务组织的。每个任务有唯一 ID，有状态流转（已提交 → 工作中 → 已完成/失败），支持复杂操作中的并行处理。

通信的内容由消息承载，消息包括：

• 属性：元数据（优先级、创建时间等）；
• 部分（Parts）：实际内容（文本、文件、结构化 JSON 等）。

智能体生成的实际输出叫工件（Artifacts），也由一个或多个部分组成，可以流式传输。

所有通信都走 HTTP(S)，用 JSON-RPC 2.0 协议。多轮对话靠 contextId 来维系——把相关的任务分组，保持上下文。

四种交互机制

A2A 提供了四种交互方式，适应不同的应用需求：

从简单到复杂、从同步到异步、从轮询到推送——覆盖了各种时间尺度的交互需求。

安全性

安全是 A2A 的基本考量，内置了多重机制：

• 双向 TLS（mTLS）：加密+认证，防止窃听和冒充；
• 全面审计日志：所有通信都记录下来，可追溯、可排查；
• Agent 卡片声明：认证要求在卡片里写清楚，集中管理；
• 安全凭据处理：用 HTTP 头传递 OAuth 令牌或 API 密钥，不放在 URL 或消息体里。

四、应用场景

A2A 的核心价值在于打破智能体之间的壁垒，让它们能组合起来解决更复杂的问题。

• 多框架协作：这是 A2A 最直接的用途——不管你用 ADK、LangChain 还是 CrewAI 做的智能体，都能通过 A2A 通信。复杂系统里，不同团队可以用不同框架各做各的，最后用 A2A 拼起来。
• 自动化工作流编排：企业环境里，一个智能体做数据采集，然后委派给另一个做分析，再委派给第三个生成报告——所有通信都通过 A2A 协议，松耦合、易扩展。
• 动态信息检索：主智能体可以从专门的"数据获取智能体"那里请求实时市场数据，数据智能体去调外部 API，再把结果发回来——各司其职。

本质上，A2A 让智能体从"各自为战的孤岛"变成了"互联互通的生态"。

五、实操示例：日历智能体接入 A2A

书中展示了怎么用 Google ADK 把一个日历管理智能体变成 A2A 服务。核心步骤是：

关键代码结构大概是这样：

# 1. 定义 ADK 智能体
adk_agent = LlmAgent(
model='gemini-2.0-flash-001',
name='calendar_agent',
description="管理用户日历的智能体",
tools=calendar_tools,
)

# 2. 定义 Agent 卡片（智能体的"身份证"）
agent_card = AgentCard(
name='Calendar Agent',
description="管理用户日历的智能体",
url=f'http://{host}:{port}/',
version='1.0.0',
capabilities=AgentCapabilities(streaming=True),
skills=[AgentSkill(id='check_availability', name='检查可用性', ...)],
)

# 3. 包装成 A2A 服务
agent_executor = ADKAgentExecutor(runner, agent_card)
a2a_app = A2AStarletteApplication(
agent_card=agent_card,
http_handler=DefaultRequestHandler(agent_executor=agent_executor)
)

开发人员只需要关注智能体本身的逻辑，A2A 的通信协议、发现机制、流式传输这些细节，框架都帮你处理好了。

六、速览

• 问题背景：单个 AI 智能体（尤其是用不同框架构建的）在处理复杂多方面问题时很吃力。最大的挑战是缺少让它们有效通信协作的通用语言或协议。这种孤岛状态阻碍了复杂系统的创建——多个专门智能体结合独特技能才能解决大问题。没有标准化方法，集成这些异构智能体成本高、耗时长，阻碍了更强大、更有凝聚力的 AI 方案的开发。
• 解决方案：智能体间通信（A2A）协议提供了开放、标准化的解决方案。它是基于 HTTP 的协议，实现了互操作性——不同的 AI 智能体不管底层技术是什么，都能协调、委派任务、共享信息。核心组件是 Agent 卡片（Agent Card）——描述智能体能力和通信端点的数字身份文件，促进发现和交互。A2A 定义了同步、异步等多种交互机制，适应不同用例。通过为智能体协作创建标准，A2A 促进了构建复杂多智能体系统的模块化、可扩展生态系统。
• 实践建议：当你需要协调两个或多个 AI 智能体协作时，使用此模式——特别是如果它们是用不同框架（Google ADK、LangGraph、CrewAI 等）构建的。非常适合构建复杂、模块化的应用，其中专门智能体处理工作流的特定部分，比如把数据分析委派给一个智能体，把报告生成委派给另一个。当智能体需要发现和使用其他智能体的能力来完成任务时，这个模式也必不可少。

七、可视化总结

图 2：A2A 智能体间通信模式——不同框架的智能体通过标准化协议协作。

关键要点

• Google A2A 协议是一个开放的、基于 HTTP 的标准，促进使用不同框架构建的 AI 智能体通信和协作；
• AgentCard 作为智能体的数字标识符，让其他智能体能够发现和理解其能力；
• A2A 提供同步请求-响应和流式更新，适应不同的通信需求；
• 协议支持多轮对话，包括 input-required 状态，让智能体可以请求额外信息、维护上下文；
• A2A 鼓励模块化架构——专门智能体在不同端口独立运行，实现可扩展和分布式部署；
• A2A 管的是智能体间的任务和工作流协调，MCP 管的是 LLM 与外部资源的标准化交互——两者互补。

结语与个人思考

A2A 这一章让我想起了互联网的早期。在 HTTP 和 HTML 出现之前，每个网络服务都是孤岛，想跨服务调用难如登天。有了标准协议之后，一切都连接起来了，然后就有了我们今天看到的互联网。

A2A 想做的，就是智能体世界的 HTTP。

这个方向的想象空间很大：

• 以后可能有"智能体应用商店"——你需要什么能力，直接调用对应的 A2A 智能体就行；
• 复杂任务可以自动拆解，分派给不同的专业智能体去做，最后汇总结果；
• 小团队可以专注做自己最擅长的那个智能体，不用做全栈，靠生态协作就能提供完整解决方案。

但挑战也不少：

第一个是标准的采用问题。A2A 现在有 Google 牵头，很多大厂支持，但最终能不能成为事实标准，还要看生态发展的速度和质量。历史上，技术标准的竞争中，技术好的不一定赢，生态好的才赢。

第二个是智能体的发现与匹配。当世界上有几百万个 A2A 智能体的时候，怎么快速找到"最适合干这件事"的那个？靠注册表？靠搜索引擎？还是靠智能体自己去试错？发现机制的效率，直接决定了整个生态的效率。

第三个是信任与安全。你调用一个陌生的智能体，它会不会泄露你的数据？它的输出质量靠谱吗？它会不会故意使坏？在人类的商业世界里，我们有品牌、有评级、有合同、有法律来解决信任问题。智能体生态的信任机制怎么建？也是个大问题。

最后，我觉得 A2A 最有意义的地方在于，它代表了 AI 行业从"比拼单个模型能力"到"构建生态系统能力"的转向。以后决定一个智能体平台强不强的，可能不是它自己的模型有多厉害，而是它能连接多少其他智能体、能调动多少生态资源。就像手机操作系统的竞争，比的不是系统本身，而是应用生态。

智能体的互联网时代，也许比我们想象的来得更快。

下一步，建议阅读第 16 章 资源感知优化（Resource-Aware Optimization）——看看智能体怎么在有限的计算资源下，把效率做到最优。

本文基于开源书籍《Agentic Design Patterns》（https://github.com/xindoo/agentic-design-patterns ，在线阅读 https://adp.xindoo.xyz/ ）整理，供学习交流，版权归原作者所有。