Hugging Face 的 LOGO

🦸🏻#17: 什么是 A2A，以及为什么它——仍然！——被低估了？

社区文章 发布于 2025 年 5 月 7 日
赞
13
Ksenia Se's avatar
Ksenia Se
Kseniase

🔳 关于 Google 的 Agent2Agent 协议，你需要知道的一切（如果 Google 构建了世界上第一个代理目录，A2A 将是它所使用的语言）

企业 AI 采用面临的最大挑战之一是如何让基于不同框架和供应商的代理协同工作。

Google，关于代理互操作性的重要性

还记得我们希望 AI 代理能够顺畅完成的经典例子吗？“下周末给我订去纽约的旅行。首选直飞航班，周五下午出发，周日晚上返回。再找一个靠近好爵士酒吧的酒店。”这个问题（除了变成老生常谈）是 AI 代理仍然难以理解你的全部意图，跨多个步骤进行规划，以及在各种工具上可靠地行动——所有这些都无需持续的人工干预。每个步骤（解析任务、寻找选项、权衡、预订）单独工作都还可以，但是将它们平稳安全地整合在一起呢？这仍然很脆弱，容易出错。目前大多数代理都是孤立运行的，每个都局限于自己的生态系统或供应商。因此，我们面临着一个碎片化的局面，代理之间无法直接通信，从而限制了它们在复杂的跨系统工作流中的作用。2025 年 4 月，Google 推出了 Agent2Agent (A2A) 作为一个开放协议，旨在打破这些孤岛。它得到了由 50 多个合作伙伴（从 Atlassian 和 Salesforce 到 LangChain）组成的全明星阵容的支持。A2A 旨在成为一种“通用语言”，让独立的 AI 代理能够跨应用程序无缝协作。

然而，尽管声势浩大地发布，并有 50 家知名合作伙伴，但几周后 A2A 仍然被低估。它并没有像人们预期的那样，掀起一阵狂潮。

image/png Reddit 上的受欢迎程度以及命名问题😳

目前，趋势显示增长放缓——为什么这项可能成为关键基础设施的技术，却反应平平？

image/png 图片来源：GitHub Star History

在本文中，我们将深入探讨 A2A——它是什么，为什么存在，如何工作，人们如何看待它——并探讨其采用滞后的原因（以及为什么这种情况可能很快改变）。我们将介绍 A2A 的技术基础，将其与 Anthropic 的 MCP 等协议进行比较，并解释构建多代理系统所面临的实际挑战。在此过程中，我们还将探讨 Google 推动代理互操作性可能带来的更大影响——甚至可能为可搜索的、互联网规模的 AI 代理目录奠定基础。一如既往，这是一份很棒的入门指南，但对于那些已经尝试过 A2A 并希望了解更多信息的人也很有用。深入了解吧！

📨 点击关注！如果你想直接在收件箱中接收我们的文章，请在此订阅

在 🎥 YouTube、Twitter 和 Hugging Face 🤗 上关注我们

在本期节目中，我们将讨论

为什么 A2A 尚未掀起波澜（但很快就会）

谷歌发布 A2A 协议的每一步都恰到好处：一个引人注目的跨代理协作愿景、重量级合作伙伴、开源代码，甚至与 Anthropic 的模型上下文协议（MCP）形成互补关系。理论上，时机完美。AI 世界正为“代理”框架而沸腾——但大多数第一代“AI 代理”堆栈都是单兵作战，单个大型语言模型配备了工具箱插件或 API。最近，我们看到 MCP 的巨大成功，它标准化了 AI 代理访问工具和上下文的方式，充当了一种“AI 的 USB-C 端口”。A2A 从此基础上接续：标准化多个自主代理如何通信，使它们能够在没有自定义集成粘合的情况下交换任务和结果。

那么，为什么 A2A 没有一夜爆红呢？部分原因是炒作动态。Anthropic 在 2024 年底发布 MCP 时，最初反响平平；直到几个月后，它才作为游戏规则改变者而受到关注。A2A 可能也正在经历类似的认知延迟。它的价值乍一看有点抽象——企业代理互操作性不像新的最先进模型或编写代码的聊天机器人那样立竿见影。许多开发人员尚未感受到多代理协作的痛苦，因为他们仍在尝试单代理应用程序。在较小规模的项目中，人们可能只是在一个脚本中编排多个 API 调用，或者在内部使用 LangChain 这样的框架，而不需要正式的协议。A2A 解决方案的真正紧迫性在更大、更复杂的环境中变得显而易见——正是在大公司中——但这个故事仍在向更广泛的社区传播。

另一个因素是“又来一个标准”的疲惫感。在过去的一年里，许多扩展大型语言模型（LLM）的方法层出不穷：OpenAI 的函数调用、各种插件系统、自定义 RPC 方案，更不用说特定于供应商的代理 API。开发人员可能会问：我们真的需要另一个协议吗？目前，A2A 仍然非常新，很少有公开的成功案例——没有令人瞠目结结舌的“代理与代理对话”的病毒式杀手级演示。如果没有这种火花，A2A 仍将默默无闻，只对那些阅读规范的人悄然有趣，但在日常 AI 开发人员的聊天中尚未成为流行语。（请记住，所有进一步学习的链接都包含在文章末尾。）

image/png

那么，A2A 是什么？它是如何工作的？

其核心是，Agent2Agent (A2A) 是一种通信协议，允许独立的 AI 代理以结构化、安全的方式相互交流。具体来说，它定义了一组基于 HTTP 的 JSON 消息，供一个代理请求另一个代理执行任务，并获取结果——如果需要，可能还需要来回的对话。它是一个开放标准（在 Apache 许可下开源），任何代理框架或供应商都可以实现，实现互操作性，就像 Web 浏览器和服务器共享 HTTP/HTML 标准一样。

image/png

让我们分解 A2A 的关键组件：

A2A（代理间通信）的核心是 代理卡（Agent Card）——一个公开的清单，通常托管在 /.well-known/agent.json，它描述了代理的能力、端点 URL 和身份验证要求。可以把它想象成一个 OpenAPI 风格的配置文件：客户端代理可以获取另一个代理的卡片，并立即查看，例如，“这个代理可以处理 CRM 票证并生成报告”，然后才决定向它发送任务。

A2A 定义了两种灵活的角色：客户端（请求代理）和服务器（执行代理）。任何符合 A2A 规范的代理都可以灵活地切换角色，从而实现灵活的拓扑结构，如点对点网格或中心辐射模型。

协作的核心单位是任务（Task）。客户端在请求远程代理执行工作时创建任务，使用 tasks/send 请求。每个任务都有唯一的 ID，并经历生命周期：提交、工作中、需要输入、已完成或失败。两个代理共同跟踪任务进度，支持更丰富、多步骤的交互，如澄清问题或部分交付。

消息（Messages）及其部分（Parts）构建了对话。一条消息可以是用户请求、状态更新或后续操作，每条消息都由多个部分组成——这些内容块可以是纯文本、结构化 JSON 数据，也可以是图像或 PDF 等二进制文件。这种设计支持多模态通信：例如，代理可以发送表单（结构化数据）而不仅仅是文本，从而使交互更加动态。

当任务完成时，输出将打包成一个工件（Artifact），它也由多个部分组成。工件是持久的、结构化的结果——PDF 报告、JSON 数据集、图像——其他代理可以在新任务中立即重用，而无需额外的解析。

A2A 还支持流式传输和通知。长时间运行的任务可以通过服务器发送事件（SSE）流式传输实时更新，让客户端代理订阅任务进度。代理甚至可以直接将更新推送到客户端的 Webhook，从而允许异步架构进行干净集成。

在底层，A2A 完全建立在熟悉的 Web 标准之上：带有 JSON-RPC 2.0 有效载荷的简单 HTTP 请求、用于流式传输的 SSE，以及典型的 REST API 身份验证方法，如 OAuth 2.0、双向 TLS 或签名 JWT。没有异构传输层或自定义二进制编码——只是务实的选择，使企业采用变得更加容易。

一个典型的 A2A 交互可能如下所示：代理 Alpha（客户端）需要一张销售图表。它获取代理 Beta（服务器）的代理卡，并看到一个“create_chart”功能。Alpha 发送一个任务：“生成第一季度按地区划分的销售条形图。”Beta 确认任务并在工作时流式传输进度更新。如果 Beta 需要更多详细信息——例如，澄清哪些地区——它会发送一个需要输入的消息，Alpha 则回复。当图表准备好后，Beta 返回最终工件（图像文件），Alpha 可以使用它或将其交给另一个代理。

由于 Beta 的技能是公开可发现的，并且通过统一的 JSON 协议调用，整个交互避免了通常脆弱的 API 移交和自定义粘合代码。这就是 A2A 的承诺：使代理协作像调用 REST 端点一样无缝。

我如何实际开始使用 A2A？（最基本的方式）

你需要什么

  • 代码编辑器，例如 Visual Studio Code (VS Code)
  • 命令行提示符，例如 Terminal (Linux)、iTerm (Mac) 或 VS Code 中的 Terminal

怎么做

  1. 克隆仓库 git clone https://github.com/google/A2A && cd A2A —— 它包含规范、Python SDK 和可运行的演示代理。

  2. 启动两个示例代理

cd samples/python/agents/hello_world
python server.py --port 5001      # “remote” agent
cd ../cli
python main.py --task "say_hi"    # “client” agent

您将看到任务生命周期消息完全按照规范的描述通过 HTTP 流动。

  1. 给你的代理一个身份 在你的服务旁边放置一个名为 /.well-known/a2a.json 的文件（代理卡）。它是一个单页简历：名称、描述、身份验证方法，以及最重要的——宣示你可以处理哪些任务的能力数组。
  2. 封装你自己的逻辑 如果你已经有一个基于 LangChain、CrewAI 或纯 Python 的代理，安装小适配器并暴露它。
pip install python-a2a
from python_a2a.langchain import to_a2a_server
a2a_server = to_a2a_server(my_langchain_agent)
a2a_server.run(port=5000)
``` :contentReference[oaicite:3]{index=3}

此后的一切——安全性、注册表、可观测性——都只是正常的微服务卫生，只是现在您的“微服务”以任务和工件而非 REST 动词进行通信。

A2A 之前：孤立代理的碎片化世界

在 A2A 之前，大多数 AI 工作流都围绕着一个“超级代理”来编排一系列工具——因此 MCP 崛起——所以真正的代理到代理的交接是罕见的。多代理协作的尝试都是临时性的：脆弱的自然语言聊天或供应商锁定的框架，它们无法在没有大量粘合代码的情况下混合 Microsoft、Google 和开源代理。由于没有通用方法来发现对等体、传递任务或引用工件，每个握手都是定制的——碎片化很快就成为扩展的噩梦。（20 世纪 90 年代，像 KQML 和 FIPA-ACL 这样的学术协议曾试图解决这个问题，但它们从未进入当今的 LLM 世界。）

image/png

A2A 是 AI 协作的灵丹妙药吗？+ 挑战

有如此多的前景，重要的是要问：A2A 能解决所有问题吗？当然不能。就像 MCP 或任何新技术一样，A2A 也有其自身的一系列挑战，并非多代理系统的万灵药。最好将 A2A 视为一个强大的赋能者——一个可以使以前不可能的工作流变得可行的集成层——但它本身并不能保证成功。

一个重要的限制是：A2A 并不能让代理更智能——它只是让它们更容易交流。如果你连接两个平庸的代理，你不会得到卓越；你只会冒着任务传递无休止却毫无进展的风险。有效的协作仍然需要仔细设计：决定谁处理什么，确保共享目标，处理故障。简而言之，A2A 并不能消除对编排智能的需求；它只是将编排中的通信标准化。

采用 A2A 还会带来额外的运营开销。每个代理都成为一个服务（带有 HTTP 端点或嵌入式服务器），这意味着要管理一个代理网格：Workday 上的 HR、Salesforce 上的销售、自定义 Python 分析——所有这些都需要发现、身份验证、监控和弹性。这又是微服务的老一套。对于小型工作流，简单的脚本可能更容易。就像 MCP 一样，只有当你拥有许多工具和上下文时才能发挥作用，A2A 只有在你将许多具有不同功能的代理连接在一起时才能发挥作用。

A2A 的规范是全新的（技术上仍是草案），并且很可能会不断发展。实施者应该预期到可能出现重大更改、边缘情况错误和不断变化的目标。与任何新协议一样，早期采用者也扮演着测试者的角色。如果您不准备积极参与社区，这可能会成为一个障碍。

兼容性是另一个障碍。A2A 得到越多代理和供应商的支持，其价值就越大。如果没有达到临界质量，您可能最好使用原生 API。Google 已经召集了一批令人印象深刻的企业合作伙伴，但 OpenAI 和 Microsoft 等主要参与者尚未公开认可 A2A（Microsoft 的 Semantic Kernel 博客展示了一个实验性的 A2A 适配器，但这只是 SDK 团队的实验——并非正式认可）。Anthropic 的 MCP 是互补的，但并非相同。如果我们最终陷入协议战争——A2A vs. MCP vs. 其他——开发人员可能会陷入构建适配器或退回到脆弱集成的困境。

安全是另一个前沿。A2A 包含了令牌认证和 TLS，但实际策略、凭据和审计则留给用户。企业可能需要“代理网关”——相当于 API 网关——来管理代理之间的信任。

所有这些都不是阻碍。这只是新基础设施的样子。微服务需要数年才能成熟。A2A 也会如此。它不是万灵药——它是一种协议粘合剂。但有了正确的期望和试点项目，它可以解决多代理系统中的通信问题。其余的仍然取决于良好的设计、周到的实施以及一个愿意推动其发展的社区。

MCP 和 A2A 会成为竞争对手吗？

简短的回答是不会。尽管有些人认为，如果 A2A 开始吸收传统上由 MCP 涵盖的功能——特别是如果公司开始主要将数据和服务建模为独立代理而不是简单的工具或资源——那么竞争可能会出现，但我认为这种情况极不可能。

工具和资源将始终是代理系统中独特且必不可少的基础构建块，它们的集成空间足以轻松容纳这两种协议。MCP 擅长标准化 LLM 与外部数据源或工具之间的交互，而 A2A 则解决安全、有状态的代理间通信。鉴于它们互补的优势和代理生态系统的庞大规模，MCP 和 A2A 将共存，各自找到其明确定义且有价值的角色。

A2A 在代理编排中的应用及其在 AI 堆栈中的地位

A2A 在新兴的 AI 基础设施堆栈中占据怎样的位置？要回答这个问题，请想象将原始 AI 模型转化为有用自主代理所涉及的各个层级。在之前的讨论中，我们已经分解了代理系统的组成部分——例如内存、推理和工具使用。A2A 并不试图解决所有这些问题；它作为一个通信和协调层插入其中。

首先，考虑单个代理。它通常由一个核心模型（如大型语言模型）、行为逻辑（通过提示或规划）以及与外部世界（工具、API）交互的机制组成。像 LangChain、Semantic Kernel 和 Google 的 Agent Development Kit (ADK) 这样的框架有助于管理这些部分。MCP，正如我们之前介绍的，标准化了代理如何连接到外部工具。

A2A 位于更高一层：代理到代理。如果 MCP 和工具 API 使代理能够对世界采取行动，那么 A2A 则使代理能够相互作用。它们是互补的，而不是竞争对手。事实上，它们经常结合使用。一个代理的 A2A 卡可以宣传其内部由 MCP 提供支持的功能——例如，“发票处理代理”可以提供提取发票字段（通过 A2A），同时在后台使用 OCR 工具（通过 MCP）。A2A 编排多代理工作流，而将内部工具管理留给每个代理。

堆叠起来

  • 大型语言模型（LLM）和推理——核心智能和决策逻辑。
  • 工具/上下文接口（MCP，插件）——让代理使用外部工具和数据。
  • 代理框架/运行时——管理代理循环、内存和任务拆分。
  • 代理间协议（A2A）——允许代理跨系统协调和委托。
  • 编排器/管理器——（可选）决定何时调用其他代理的监督逻辑。

重要的是，A2A 不会取代 LangChain、Semantic Kernel 或其他框架——它允许它们互操作。A2A GitHub 仓库已经包含了 LangChain、LlamaIndex、Marvin、Semantic Kernel 等的适配器。现在，一个 LangChain 代理和一个 Semantic Kernel 代理可以无需自定义粘合代码即可协作。

这是一个熟悉的模式：在早期网络开发中，应用程序无法通信，直到 REST 等协议标准化了通信方式。现在，A2A 试图为 AI 代理做同样的事情。

最后，虽然 OpenAI 的函数调用允许代理内部工具使用，但 A2A 实现了代理间的协作。它们服务于不同的范围，很可能会在复杂的系统中共存。

如果成功，A2A 将成为多代理工作流的通用语言——一个不起眼但至关重要的 AI 基础设施下一阶段的推动者。

image/png

A2A 开启的新可能性

由于 A2A 尚未引起主流关注，许多人低估了它所能实现的工作流和协作类型。让我们来看几个例子。

  • 专家代理协同工作：A2A 允许专业代理团队动态协作，而不是构建一个巨大的代理来处理所有事情。例如，在客户支持中，技术故障排除代理、财务代理和促销代理可以在一个会话中无缝地移交任务，这就像人类团队的运作方式一样。用户只与一个前端交互，而代理在后台协作。
  • 跨企业工作流：企业运行在许多平台上——Salesforce 用于 CRM，ServiceNow 用于 IT，Workday 用于 HR。有了 A2A，HR 代理可以请求 IT 配置一台笔记本电脑，而无需手动 IT 工单或脆弱的 API 粘合代码。每个代理在其各自领域保持卓越，但可以通过协议插入更大的、跨公司的工作流。
  • 动态代理切换和升级： A2A 标准化了功能，为模块化打开了大门。你可以用一个商业总结代理替换一个开源总结代理，而无需改变其调用方式。随着时间的推移，这可能会导致一个可互操作代理的市场——雇佣一个法律分析代理、一个翻译代理、一个市场研究员——所有这些代理都使用 A2A 进行通信。
  • 人机协同监督：并非所有代理都必须是 AI。人类也可以通过 A2A 客户端参与——批准或修改 AI 建议的任务，或监控代理之间敏感的交互。通过标准化的工件和任务状态，这种正式的交接和监督变得更加容易。
  • 跨组织联合代理： 从长远来看，A2A 可以让不同公司的代理安全地协作，跨组织边界交换任务。供应链代理协商库存、跨公司研发团队——一旦信任层和协议到位，所有这些都成为可能。

在 A2A 出现之前，许多这些设置要么不可行，要么成本极高。讽刺的是，当 AI 世界追求更大的模型和更花哨的提示时，像 A2A 这样不起眼的“管道”却可能解锁质的新能力。通过使代理协作模块化、安全和即插即用，A2A 降低了创新的门槛——我们才刚刚开始看到它的可能性。

总结思考——Google 能否将 A2A 变成一个像 Google 搜索一样的公共代理索引？

技术上，是的。该规范已经要求每个兼容的代理在 /.well-known/agent.json 发布一个机器可读的代理卡片。这是爬虫的完美钩子：只需跟随 URL，获取卡片，然后将元数据放入 Bigtable——这正是 Google 将 robots.txt + sitemap.xml 转化为 Web 索引的方式。今天，这个发现步骤是点对点的，但没有什么能阻止 Googlebot-for-Agents 在互联网规模上做同样的工作。

Google Cloud 内部的早期信号显示了这种需求。Agentspace 的 Agent Gallery 已经是一个受限的、可搜索的企业客户目录；它列出了 Google 构建的、合作伙伴和内部代理，并利用 Cloud Marketplace 进行分发。这是一个迷你的代理应用商店——只是缺少公共爬虫。

image/png

A2A 铺设了管道；至于 Google 是否会将这些管道变成世界的总机，这仍然是一个悬而未决的问题。不过，A2A 仍处于早期阶段。它今天不为人知的地位，让人想起容器、Kubernetes 和 REST API 最初的窃窃私语——在生态系统发生转变后，这些技术才爆发式增长。如果山景城真的推出了一个公共代理索引，它可能会成为自主软件的 DNS——强大、有利可图，且具有政治敏感性。在这个未来明朗之前，请试用 A2A，跟踪竞争对手的规范，并保持敏捷。基础设施的成功，与其说是靠才华，不如说是靠信任、激励和成千上万个默默无闻的集成故事。关注这些故事吧。

作者：Ksenia Se

深入了解的资源：

来自 Turing Post 的资料

📨 如果您想直接在收件箱中收到我们的文章，请在此订阅

社区

注册或登录以评论

赞
13