《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 CommunicationA2A就是干这个的用一套开放标准让任何框架、任何公司的智能体都能互相说话、互相协作。一、什么是 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 跟它有什么区别”书中专门对比了这两个协议——它们是互补关系不是竞争关系。图 1A2A 和 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 发现客户端智能体怎么找到服务器智能体有三种策略发现方式做法适用场景标准 URI智能体在/.well-known/agent.json路径托管卡片公开的、可自动化发现的服务精选注册表集中式目录发布卡片、可按条件查询企业环境需要集中管理和访问控制直接配置卡片信息直接嵌入或私下共享紧耦合的私有系统不需要动态发现跟互联网早期的网站怎么被找到很像——从直接配置到门户网站到搜索引擎一步步演化。通信与任务A2A 的通信是围绕异步任务组织的。每个任务有唯一 ID有状态流转已提交 → 工作中 → 已完成/失败支持复杂操作中的并行处理。通信的内容由消息承载消息包括属性元数据优先级、创建时间等部分Parts实际内容文本、文件、结构化 JSON 等。智能体生成的实际输出叫工件Artifacts也由一个或多个部分组成可以流式传输。所有通信都走 HTTP(S)用 JSON-RPC 2.0 协议。多轮对话靠contextId来维系——把相关的任务分组保持上下文。四种交互机制A2A 提供了四种交互方式适应不同的应用需求交互方式特点适用场景同步请求/响应发请求 → 等结果 → 一次性返回快速、即时的操作异步轮询发请求 → 返回处理中任务ID → 客户端定期查状态耗时较长的任务流式更新SSE建立持久连接 → 服务器实时推送增量结果需要实时、增量反馈推送通知Webhook客户端注册 webhook → 任务有重大变化时服务器主动通知超长时间运行、资源密集型任务从简单到复杂、从同步到异步、从轮询到推送——覆盖了各种时间尺度的交互需求。安全性安全是 A2A 的基本考量内置了多重机制双向 TLSmTLS加密认证防止窃听和冒充全面审计日志所有通信都记录下来可追溯、可排查Agent 卡片声明认证要求在卡片里写清楚集中管理安全凭据处理用 HTTP 头传递 OAuth 令牌或 API 密钥不放在 URL 或消息体里。四、应用场景A2A 的核心价值在于打破智能体之间的壁垒让它们能组合起来解决更复杂的问题。多框架协作这是 A2A 最直接的用途——不管你用 ADK、LangChain 还是 CrewAI 做的智能体都能通过 A2A 通信。复杂系统里不同团队可以用不同框架各做各的最后用 A2A 拼起来。自动化工作流编排企业环境里一个智能体做数据采集然后委派给另一个做分析再委派给第三个生成报告——所有通信都通过 A2A 协议松耦合、易扩展。动态信息检索主智能体可以从专门的数据获取智能体那里请求实时市场数据数据智能体去调外部 API再把结果发回来——各司其职。本质上A2A 让智能体从各自为战的孤岛变成了互联互通的生态。五、实操示例日历智能体接入 A2A书中展示了怎么用 Google ADK 把一个日历管理智能体变成 A2A 服务。核心步骤是定义智能体创建一个能管理日历的 ADK 智能体配好日历工具定义 Agent 卡片描述智能体的身份、技能、端点地址包装成 Web 服务用 A2A 框架把智能体暴露成 HTTP 服务启动服务用 Uvicorn 跑起来其他智能体就能通过 A2A 协议调用它了。关键代码结构大概是这样# 1. 定义 ADK 智能体adk_agentLlmAgent(modelgemini-2.0-flash-001,namecalendar_agent,description管理用户日历的智能体,toolscalendar_tools,)# 2. 定义 Agent 卡片智能体的身份证agent_cardAgentCard(nameCalendar Agent,description管理用户日历的智能体,urlfhttp://{host}:{port}/,version1.0.0,capabilitiesAgentCapabilities(streamingTrue),skills[AgentSkill(idcheck_availability,name检查可用性,...)],)# 3. 包装成 A2A 服务agent_executorADKAgentExecutor(runner,agent_card)a2a_appA2AStarletteApplication(agent_cardagent_card,http_handlerDefaultRequestHandler(agent_executoragent_executor))开发人员只需要关注智能体本身的逻辑A2A 的通信协议、发现机制、流式传输这些细节框架都帮你处理好了。六、速览问题背景单个 AI 智能体尤其是用不同框架构建的在处理复杂多方面问题时很吃力。最大的挑战是缺少让它们有效通信协作的通用语言或协议。这种孤岛状态阻碍了复杂系统的创建——多个专门智能体结合独特技能才能解决大问题。没有标准化方法集成这些异构智能体成本高、耗时长阻碍了更强大、更有凝聚力的 AI 方案的开发。解决方案智能体间通信A2A协议提供了开放、标准化的解决方案。它是基于 HTTP 的协议实现了互操作性——不同的 AI 智能体不管底层技术是什么都能协调、委派任务、共享信息。核心组件是 Agent 卡片Agent Card——描述智能体能力和通信端点的数字身份文件促进发现和交互。A2A 定义了同步、异步等多种交互机制适应不同用例。通过为智能体协作创建标准A2A 促进了构建复杂多智能体系统的模块化、可扩展生态系统。实践建议当你需要协调两个或多个 AI 智能体协作时使用此模式——特别是如果它们是用不同框架Google ADK、LangGraph、CrewAI 等构建的。非常适合构建复杂、模块化的应用其中专门智能体处理工作流的特定部分比如把数据分析委派给一个智能体把报告生成委派给另一个。当智能体需要发现和使用其他智能体的能力来完成任务时这个模式也必不可少。七、可视化总结图 2A2A 智能体间通信模式——不同框架的智能体通过标准化协议协作。关键要点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/ 整理供学习交流版权归原作者所有。