人工智能代理的兴起引发了几乎所有行业专业代理的爆炸式增长，每个代理都是为处理特定的重复性或复杂任务而量身定制的。

从简化医疗保健操作到优化零售定价，再到自动化招聘流程，这些代理有望显著提高效率和能力。由不同公司开发的、基于不同框架构建的、专注于不同业务领域的代理往往各自为政。

但迄今为止，大多数代理都是孤立运行的，各自局限于自己的系统或供应商。而现实生活中的问题很少局限于单一应用或领域。

如果这些代理可以相互对话，并代表我们进行协作，那将是多么美好的事情。

谷歌最新发布的Agent2Agent（A2A）协议旨在实现这一目标，开启“代理互操作性的新时代 ”。

这一开放协议可让不同的人工智能代理在不同的应用程序和组织之间进行通信、共享信息和协调行动，即使它们是由不同的供应商开发。这样一来，人工智能系统就能无缝协作，解决复杂任务。

Agent2Agent（A2A）是一个代理与另一个代理对话的标准方法——交换任务、响应和数据——无论代理是谁开发的，也无论它们在什么框架上运行。

就像互联网协议（如 HTTP）可以让任何网络浏览器和服务器进行交互一样，A2A 为人工智能代理提供了一种通用语言，“无论底层框架或供应商是谁，它们都可以相互协作”。

其目标是打破人工智能代理的 "孤岛 "性质，释放多代理协同效应。

如今，企业可能会部署许多专门的代理（用于 IT 支持、调度、分析、客户服务等），它们通常来自不同的供应商。如果没有一个标准，这些代理就无法直接协同工作，从而限制了它们的作用。

A2A 的设计目的是使代理能够在不同系统间互操作，这样他们就可以组成临时团队来完成更大的任务。这意味着，如果 A 公司的代理与 B 公司的代理都使用 A2A 语言，那么 A 公司的代理可以安全地向 B 公司的代理请求帮助。通过允许这种交叉对话，企业可以从人工智能中成倍地提高生产力，同时避免被供应商锁。

谷歌认为，通过让代理在整个企业堆栈中进行协调，A2A 将“提高自主性，成倍地提高生产力，同时降低长期成本”。

A2A 的一些主要特点和原则包括

A2A 协议的核心是为人工智能代理提供一种通用 “语言”，使其能够进行对话、协调和合作。谷歌表示：“A2A 协议将允许人工智能代理相互通信、安全地交换信息，并在各种企业平台或应用程序之上协调行动”。

通过开源 A2A 并从第一天起就动员 50 多个行业合作伙伴支持它（包括 Atlassian、Box、Salesforce、SAP 和许多其他公司），谷歌正在推动它成为一个通用标准。

在他们的设想中，未来的人工智能代理无论如何构建，都能 “无缝协作解决复杂问题”**。

从高层次上讲，A2A 定义了客户端代理和远程代理之间的结构化对话。

客户代理是发起请求的一方——通常是直接为用户提供服务或协调工作流的代理。远程代理是客户代理请求执行子任务或提供信息的助手或专家。

能力发现：代理通过"代理卡"（JSON 格式的元数据）宣传自己的能力。在合作之前，客户代理可以查看另一个代理的卡片，了解其能力，并决定该代理是否适合特定的工作。例如，一个代理的卡片上可能写着 “我可以检索企业销售数据”或 “我可以生成营销文案”。这样，代理就能动态地为某项任务找到最佳合作伙伴。

任务请求：客户代理制定一项任务——基本上是对需要完成的任务的描述——并使用 A2A 协议将其发送给远程代理。任务是 A2A 定义的标准数据结构（对象）。它可以包括目标、任何输入数据和参数等细节。例如，“为纽约具有 Python 经验的软件工程师职位寻找候选人”可以是一个任务。

代理协作和消息传递：一旦任务被共享，两个代理就会进入来回对话（如果需要）以完成任务。他们会交换包含上下文、中间结果、澄清问题或与任务相关的任何其他信息的消息。A2A 并不强迫对话采用死板的格式——代理以自然、灵活的方式进行交流（可能是自然语言指令，必要时加上结构化数据）。这可能涉及远程代理询问更多细节，或者客户代理提供远程代理可能需要的上下文。

用户体验协商：比较有趣的是，当代理交换信息时，它们会协商输出的格式和用户将看到的内容。A2A 中的每条信息都可以包含一个或多个 "部分"，其中每个部分都是具有特定类型（文本、图像、视频、表单等）的内容。该协议允许代理明确讨论如何展示结果。例如，如果远程代理有能力返回图表或交互式地图，客户端代理就可以说明用户界面是否支持（也许用户使用的设备无法显示交互式地图，因此静态图像更好）。这种用户体验协商可确保任务结果以最适合终端用户环境的格式交付。

任务生命周期和完成：任务有一个生命周期——它可以立即一步完成，也可以在代理完成任务时保持“进行中”。对于快速任务，远程代理可能会直接回复最终结果。对于时间较长的任务，远程代理可以发送进度更新（如“20% 已完成…”），客户端代理可以实时通知用户。任务完成后，远程代理会返回最终的工件——任务的输出。工件可以是一段数据、一份文档、一张图片——无论任务产生了什么。然后，客户端代理会使用该工件来满足用户的请求（例如，显示找到的候选者列表）。

安全协作：在整个交换过程中，A2A 处理底层安全——确保每个请求都经过验证和授权。代理使用令牌/凭据，以便远程代理只接受来自受信任客户端代理的任务，类似于 API 要求密钥或 OAuth 令牌的方式。所有通信都通过安全通道（HTTPS）进行，由于 A2A 是开放的，因此可以对其合规性进行审核。从本质上讲，A2A 的建立是为了让企业能够信任代理，使其能够在不向错误方暴露敏感数据的情况下协同工作。

上图展示两个人工智能代理如何通过 A2A 协议进行通信。 客户端代理 （蓝色）向 远程代理 （绿色） 委派任务 。

它们交换信息（语音气泡）以合作完成任务，远程代理返回结果（工件）和状态更新（图中绿色复选标记表示已完成项目，红色 X 表示缺失项目）。

黄色圆圈突出了 A2A 的关键组成部分：它实现了 安全协作、 任务和状态管理 （跟踪任务的生命周期和状态）、 用户体验协商 （就结果格式/用户界面达成一致）和 能力发现 （宣传并发现代理能做什么）。

从本质上讲，A2A 将代理变成了团队成员。

客户代理可以发现有能力的对等代理，将子任务委托给对等代理，然后双方进行协调，直到任务完成，同时保持用户在环路中。最妙的是，两个代理都不需要共享其全部内部数据或内存——它们只需通过 A2A 接口进行通信，从而保护了隐私和模块化。

这就像公司的一个部门向另一个部门发送请求一样：每个部门都有自己的工具和数据，但它们通过以通用格式交换必要信息来进行协作。

谷歌在 GitHub 上发布了 A2A 协议的完整规范草案，详细说明了所有的信息类型和字段。不过，即使不细究这些细节，A2A 也能为多代理通信提供一个强大、灵活的框架：发现能力、基于任务的结构化交换、持续更新和丰富的内容支持，所有这些都内置了安全性。

谷歌提供了一个实际案例：在 hiring 中寻找候选人。该场景展示了多个人工智能代理使用 A2A 来简化招聘软件工程师的流程。你不需要是技术专家也能看懂——把每个代理想象成具有特定角色的专业同事，把 A2A 想象成他们用于协调的语言。

就像Anthropic 工程师 Barry Zhang 在 AI Engineer 工作坊上的一个分享 “如何构建有效的 Agent”，其中一个观点：Don’t build agents for everything，每个 Agent 并不需要是一个多面手，它们只需要负责对应的场景即可。

我们不再需要一个单一的人工智能来做所有的事情（也许会失败），而是有一个由专业人工智能组成的团队来处理不同的工作，并相互交接。

经理的工作效率大大提高：整个招聘团队可能需要花费数天或数周的时间（寻找候选人、安排面试、背景调查），而这些工作在很大程度上都是由相互协作的代理自动完成的。所有这些代理甚至可以来自不同的供应商，例如，招聘代理可以是第三方人力资源软件服务，日程安排代理可以与微软的日历系统集成，等等。只要它们使用 A2A，人力资源代理（可能在谷歌平台上运行）就能与它们协同工作。

这种跨供应商的互操作性正是 A2A 的目的所在——让用户自由选择最适合每项工作的人工智能，并让它们相互合作。

谷歌的演示场景只是其中一个案例，我们还可以想象许多其他案例：IT 支持代理将网络问题委托给专门的服务器代理，或者个人助理代理将旅行预订任务委托给旅游平台代理，等等。

当代理可以将他们的优势串联起来时，可能性将是无限的。

谷歌的 A2A 和 Anthropic 的 MCP 是互补协议，而非直接竞争对手。

A2A 是关于代理与其他代理对话以协作完成任务，MCP 则是将代理与数据源和工具连接起来，为它们提供上下文。

可以认为 MCP 解决的问题是：“人工智能助手如何获取所需的信息？”而 A2A 解决的问题是：“多个人工智能助手如何协调行动？”

MCP 提供了“连接人工智能系统与数据源的通用、开放标准，以单一协议取代零散的集成。”

在实践中，MCP 让人工智能模型（如 Anthropic 的 Claude，甚至 OpenAI 的 ChatGPT）以安全、标准化的方式检索外部信息或触发操作。例如，MCP 集成可以让人工智能查询公司数据库、从 Google Drive 获取文档或在 Slack 上发送消息，所有这些都可以通过通用协议实现。开发人员可以建立MCP服务器，公开某些数据或服务，人工智能代理（MCP客户端）可以根据需要调用这些服务器。

Anthropic把MCP比作人工智能的“USB-C接口”——数据和工具的通用插头。

MCP 是为人工智能提供上下文和辅助工具，而不是两个对等代理聊天。例如，如果人工智能代理需要客户关系管理（CRM）中的客户数据，MCP 就能让它获取这些数据。但是，MCP 本身并没有说明一个自主代理如何就涉及推理的任务向另一个自主代理寻求帮助。

这就是 A2A 的用武之地。

谷歌明确指出：“A2A 是一个开放协议，是对 Anthropic 的《模型上下文协议》（MCP）的补充 ，后者为代理提供了有用的工具和上下文。”一个代理可以使用 MCP 获取它需要的数据，然后使用 A2A 与另一个代理合作，根据这些数据采取行动。

概念差异： MCP将一个代理与数据和工具连接起来；A2A将一个代理与其他代理连接起来。

MCP 通常是单代理场景（人工智能 + 数据源），而 A2A 则是多代理场景（人工智能 + 人工智能）。例如，使用 MCP，人工智能可以从 Confluence 获取文档，但使用 A2A，同一人工智能实际上可以要求文档分析代理为其总结该文档。它们解决的是拼图中的不同部分，实际上我们可能会看到它们一起使用。

网络上有个评论很好地捕捉到了这一点，他说 A2A 和 MCP 可以共同构成新兴的 "代理互联网"的骨干——在这个互联网中，代理可以自由共享上下文（通过 MCP）和能力（通过 A2A），从而完成工作

OpenAI 的函数调用（function calling）采用了一种不同的方法来扩展人工智能模型的能力。

在 OpenAI 的方案中，开发人员可以定义函数（带有名称和参数模式），并将这些定义交给人工智能模型（GPT-4 或 GPT-3.5）。然后，模型可以在对话过程中决定 "调用 "其中一个函数，方法是输出一个符合函数规范的 JSON 对象。调用系统（模型外部）会检测到这一点并实际执行该函数，然后将结果返回给模型以继续对话。

这样做的目的是让 ChatGPT 以可控的方式与外部工具和 API 接口。例如，如果你问 ChatGPT"芝加哥的天气如何？"，它可以在引擎盖下调用get_weather(location)函数，获取答案，然后回复信息。

函数调用有效地将自然语言查询转换为结构化 API 调用。该模型经过训练，能够识别问题何时应使用函数（如数据库查询），并输出所需的精确 JSON 信息。这是一种获得更准确、更可行结果的强大技术，因为模型可以将某些任务委托给现实世界中的函数（如数学计算、数据库查询等）。

函数调用并不是两个自主代理之间的对话，它更像是人工智能代理使用工具。被调用的函数并不是一个拥有自己智能的人工智能，而是执行特定任务的代码。

模型处于主导地位，决定是否以及何时使用函数。相比之下，在 A2A 世界中，远程代理拥有自己的 "大脑"。它甚至可以转过身来向客户代理询问情况，或在内部处理多步骤工作等。A2A 的对称性和交互性更强。

举例说明两者的区别：如果使用函数调用，ChatGPT 可能会调用schedule_meeting(人，时间)来预约会议——该函数将直接与日历系统对接，并返回成功/失败。而使用 A2A 时，代理将联系日程安排代理并进行对话（如果存在冲突，日程安排代理可能会提出其他时间等）。

功能调用是一劳永逸的，而 A2A 交流可以是持续和丰富的。

此外，A2A 的建立是为了处理长时间运行的任务和流式结果等问题，而函数调用并不能直接解决这些问题。如果函数调用需要很长时间，模型就会一直等待，直到得到结果；而有了 A2A，代理就可以启动任务，两个代理通过进度更新保持同步。A2A 还引入了协商结果返回方式（如格式或模式）的概念。在函数调用中，不需要协商格式，因为函数的输出格式是由模式预定义的。

函数调用就像给人工智能提供工具（函数），让它在需要时使用。A2A 则是为人工智能提供可以合作的同事（其他代理）。函数调用通常是单轮调用和响应（一个模型对一个函数），而 A2A 则支持两个智能代理之间的多轮对话。

这两种方法都可用于实现复杂的结果，但 A2A 更为灵活，可用于需要两个人工智能共同推理或协同处理部分问题的场景。事实上，我们可以想象在一个代理中使用函数调用作为其工具包的一部分，然后使用 A2A 将该代理与另一个代理连接起来——这些都是可以叠加的层级，而不是相互排斥的选项。

谷歌推出 Agent2Agent 协议是一项战略举措，它让我们了解到企业人工智能的发展方向以及谷歌对人工智能系统未来的设想。

谷歌并不是凭空创造出 A2A 的——它是在观察企业尝试大规模部署人工智能的过程中产生的。

许多公司一直在尝试 "代理式人工智能"，但一大挑战是如何让不同团队或供应商构建的代理协同工作。谷歌指出，他们利用了"内部在扩展代理系统方面的专业知识"，并将互操作性视为为客户部署大规模、多代理解决方案时的一个关键问题。

通过推出 A2A，谷歌直接解决了这一痛点。他们为客户提供了一种标准化的方式，以便在"不同的平台和云环境 "中管理众多人工智能代理。

从本质上讲，谷歌看到，如果没有像 A2A 这样的协议，人工智能的价值可能会受到孤立部署的限制，因此他们采取行动消除这一障碍。

谷歌从一开始就将 A2A 作为一个开放的协议，并给予合作伙伴广泛的支持。超过 50 家技术公司和服务提供商（包括 Salesforce、SAP、Intuit、Accenture 等大公司）被宣布为贡献者或支持者。这表明，谷歌将 A2A 定位为行业标准基础，而非谷歌专有的 API。

从战略上讲，这与谷歌过去的举措（例如，开源用于容器编排的 Kubernetes）类似。通过率先推出开放标准，谷歌可以影响行业的发展方向，确保自己的平台（如谷歌云的顶点人工智能）与之顺利整合，同时避免给客户造成锁定的印象。

这是一种"水涨船高 "的方法——如果 A2A 得到广泛采用，谷歌的服务就能在多代理世界中脱颖而出，而每个人都能从互操作性中受益。

A2A 通过谷歌云发布，表明它与谷歌的云战略紧密结合。谷歌希望成为企业构建和运行人工智能代理的首选供应商。谷歌不仅提供人工智能模型，还提供管道和粘合剂（如 A2A 以及 Vertex AI 上的 Agent Development Kit 和 Agent Orchestration 等工具），从而为企业人工智能提供了一个全栈解决方案。

他们认为“我们有模型、平台（Vertex AI），现在又有了互操作性标准（A2A），可以将一切联系在一起”。对于需要各种人工智能和软件系统进行合作的公司来说，这种全面的方法可能非常具有吸引力。

谷歌投资于代理协作协议这一事实表明，他们预见到人工智能将从单一的大型模型转向由小型专业代理组成的网络。

这是一个值得注意的战略眼光。

近年来，人工智能的热潮主要集中在制造规模更大、能力更强的单个模型上，而谷歌正在认识到，通往智能的另一条道路是协调。通过推出 A2A，谷歌打赌未来的人工智能实践将涉及多个代理的协调，而不仅仅是依赖一个超级大脑。

这反映了一种思维模式，即人工智能在实用性方面的下一次飞跃可能来自组合——将人工智能系统连接在一起——就像来自纯粹的算法突破一样。谷歌很可能希望引领这种模式，就像早期的互联网公司通过制定标准获益一样（想想谷歌对网络标准的关注、安卓系统的开放性等）。

这也是一种防御性举措：通过创建一个开放标准，谷歌可以阻止其他公司拥有多代理互操作层。

就谷歌的研究方向而言，A2A 暗示谷歌未来将把多代理系统、通信和协调作为一个研究领域进行探索。我们可能会看到谷歌研究（并改进）代理如何相互协商，如何共同制定最佳计划，以及如何确保多个人工智能代理在交互时保持一致。

它将人工智能与分布式系统，甚至人机交互的各个方面联系在一起（因为代理合作往往涉及到对人类的中间反馈）。谷歌现在推出 A2A，表明他们希望加快这一领域的创新，并为人工智能代理如何协同工作制定议程。

在高层次上，A2A 为人工智能代理提供了一个即插即用的生态系统。

公司可以集成来自不同供应商的最佳代理，并让它们协同工作。这种灵活性意味着你不会被一家供应商的 “单一 ”解决方案所束缚——你的 Salesforce 人工智能可以与您的谷歌人工智能对话，而谷歌人工智能又可以与你的内部人工智能对话，等等。

这种互操作性对于充分发挥人工智能的潜力至关重要，因为没有任何一个系统会拥有各种情况下所需的所有数据或功能。

A2A 允许每个代理专注于自己最擅长的领域，然后将这些结果结合起来。

这种专业化可以带来更好的结果。例如，与其试图建立一个无所不能的巨型代理，你可以拥有一个财务代理、一个法律代理、一个营销代理——每个代理都是其领域的专家——通过 A2A，他们可以共同处理一个复杂的项目。正如我们在招聘场景中所看到的，这可以大大简化工作流程。

这类似于人类团队在完成复杂任务时胜过单打独斗的普通人。代理可以将子任务委托给拥有适当专业知识的其他人，从而获得更高质量的结果和更快的完成速度。谷歌及其合作伙伴指出，A2A 可以通过这种方式实现更丰富的大规模委托和协作。

通过在代理之间建立任务链，A2A 可以进一步推动自动化。

代理可以通过调用其他代理自行启动后续行动。这意味着只需最少的人工干预即可处理端到端的流程。对用户来说，这就像有一支助手大军在协调工作。你可以向人工智能助理提出 "处理我的旅行事宜"，它就会在幕后激活机票预订代理、酒店代理、汽车租赁代理等，将一切都安排妥当。

用户无需手动协调这些不同的步骤。这就成倍地提高了工作效率，超出了单个代理的能力范围。

由于 A2A 支持长期交互和流媒体，因此代理可以处理连续或开放式任务，并根据情况变化进行调整。例如，管理供应链的代理可以通过 A2A 保持沟通，在发现延迟或短缺时实时调整订单和物流。这种动态反馈循环能力可使人工智能系统在执行关键任务时反应更迅速、更强大。

这不仅仅是“点火即忘”；在整个任务生命周期中，代理都会保持同步。

用户体验协商功能意味着多代理协作的输出可以最有效的方式呈现给用户。代理不仅能以原始文本的形式提供结果，还能以富媒体、互动元素或用户界面能处理的任何形式提供结果。

这将使人工智能辅助更加人性化，视觉信息量更大。

想象一下，在一对代理中，一个生成数据可视化，另一个确保其在仪表板中正确显示——结果就是一个易于消化的精炼答案。A2A 基本上有助于确保代理合作时，最终产品具有凝聚力并符合用户需求。

由于 A2A 是开源的，并且欢迎贡献，因此它可以促进创新社区的发展。任何人都可以建立一个符合 A2A 标准的代理，并立即与成千上万个其他代理合作。

这就打开了代理 “应用商店 ”或生态系统的大门，新的代理（具有独特的能力）可以在这里出现，并立即被其他人使用。谷歌与众多合作伙伴合作的举动表明，我们将看到各种符合 A2A 标准的代理和集成出现。这不禁让人想起互联网上的标准协议是如何导致网络服务爆炸式增长的。在这里，人工智能代理的标准可能会导致可互操作的人工智能服务的爆炸式增长，从而共同解决问题。这将加速人工智能的应用，因为企业可以混合和匹配解决方案，而不必担心选错。

总之，A2A有可能开启一个代理互操作性的新时代，促进创新，并创造出更强大、更通用的代理系统。

对于企业来说，为代理提供标准的通信方式也意味着更好的监督。A2A 可以更统一地跟踪代理对彼此提出的要求及其产生的结果，而不是让每个代理都成为一个黑盒子。这可以简化整个企业人工智能决策的合规性和审计工作。谷歌特别指出，企业将受益于这种管理不同代理的标准化方法——很可能是因为它可以与现有的管理工具和安全控制集成。

简而言之，A2A 可能会让统一应用管理策略变得更容易（例如，记录所有跨代理的交互，强制规定某些数据不能离开某些代理等）。它所指向的未来，人工智能不是一个超级大脑，而是一个由大脑组成的协作网络，每个大脑都能做出贡献。

就像人类组织通过分工和交流扩大规模一样，人工智能系统也可能通过联合许多代理的智能来扩大规模。谷歌的 A2A 就是朝着这个方向迈出的一大步。

尽管A2A前景广阔，但也不是没有障碍。解决方案目前还处于草案的形式。它的优势来源于网络效应，在大量代理实施的情况下才能发挥真正的作用。虽然现在谷歌有很多合作伙伴，但是要让整个行业广泛地采用A2A还需要时间。

短期内，我们可能会看到一些分散的情况：一些公司使用了这套协议，一些公司就会使用不同的方法，可能会出现替代的标准，或者说不是所有人都同意这个方法。

谷歌它所要面临的挑战就是如何促进采用，并且通过一个标准的机构将其正式化。在这个协议普及之前，开发者可能就会面临各种集成方法的拼凑。

使用标准化协议意味着每个代理交互都要通过一个定义的接口，通常是通过 HTTP/JSON。这对兼容性非常有利，但与紧密集成的系统相比，可能会带来性能开销。

通过 A2A 调用远程代理可能会比在代码中调用本地函数慢（网络延迟、JSON 序列化/反序列化）。如果一个代理需要进行几十次子调用，这些延迟可能会增加。在开发方面也有开销：必须对代理进行编程，以处理 A2A 协议及其所有消息类型，这比一次性快速集成工作量更大。

随着时间的推移，工具（如 SDK 和库）将会减轻这种情况，但最初需要付出努力来启用 A2A 支持。

设计多代理协作系统本身就比单一代理解决方案复杂。开发人员必须考虑以下问题如何将给定任务分配给最佳代理？如何处理代理不响应或任务中途失败的情况？如果两个代理陷入循环或出现分歧怎么办？

这些问题类似于分布式计算问题，需要强大的协调逻辑。谷歌正在提供一些工具（如 Vertex AI 中的代理开发工具包和代理协调）来帮助管理这些问题，但对许多人来说，这仍然是一种新的模式。调试不同代理之间的交互可能很棘手——如果出了问题，你必须追踪代理之间的对话，还可能要跨不同的系统。

在多代理工作流程中，存在许多故障点。网络可能会出现故障，某个代理可能会误解任务，或者某个代理可能会生成无效的工件。系统需要从容应对这些问题——或许是重试，或许是设置后备代理，或许是通知人工。这就增加了设计开销。

例如，如果一个代理没有按时完成任务（可能是一个长期运行的任务卡住了），发起代理应该有一个策略（等待更长的时间？）这些协议的作用取决于它们所考虑的失败模式。A2A 在实践中如何处理所有边缘情况尚未得到证实。早期采用者很可能会发现需要在规范中更加明确或改进的情况。

这些挑战中有许多与其他技术领域（微服务通信、分布式计算、B2B API 等）相似，因此有经验可以借鉴。随着时间的推移，谷歌的参与和开放社区可以共同解决这些问题。但在短期内，任何人在实施 A2A 时都应深思熟虑，并进行适当的测试和监控。

谷歌的 Agent2Agent 协议是人工智能大趋势的一部分：从孤立智能走向互联智能。

正如互联网将全球计算机连接起来一样，我们可能很快就会看到一个由人工智能代理组成的网络，这些代理可以实时地相互发现和互动。A2A 和 MCP 等协议为一些人所说的代理互联网奠定了基础。

在这一愿景中，需要某种能力（无论是数据访问还是专业技能）的代理可以查询代理目录，就像设备在互联网上查找服务一样。然后，它们将通过标准协议进行对接，组成临时联盟来解决问题。这有点未来主义，但构件正在逐步到位。

如果这一技术得以实现，人工智能代理最终将形成复杂的智能供应链，在全球范围内相互获取信息并采取行动。

随着谷歌和Anthropic等主要企业推动开放协议，很可能会推动标准的融合。我们可能会看到为确保 A2A 和 MCP 顺利合作所做的努力（它们本来就是互补的，但也许会出现一个统一的框架或参考实施方案）。可能会成立一个行业联盟或工作组来管理这些代理交互标准，确保它们在发展过程中吸收众多利益相关者的意见（类似于网络标准的管理方式）。

如果其他科技巨头（微软、亚马逊等）加入进来，他们可能会提出自己的想法或要求，从而可能扩大代理协议的覆盖范围。

管理多代理系统可能会成为一种新的软件类别。我们已经在谷歌顶点人工智能（Vertex AI）中的代理引擎（Agent Engine）和代理开发工具包（Agent Development Kit）中看到了这方面的蛛丝马迹。

未来，我们可能会有专门的“代理协调平台”，可以为企业部署、监控和优化代理舰队。这些平台将在引擎盖下使用 A2A 等协议，并提供一个仪表板来配置代理工作流、设置策略（允许哪些代理对话、允许执行哪些任务等）和分析性能。

从本质上讲，随着代理协作的普及，管理这种协作的工具也将日趋成熟。这类似于微服务导致 Kubernetes 和服务网格的兴起，多代理系统可能需要自己的管理层。

随着代理更多地在后台协作，人类监督或与这些多代理流程互动的方式也将发生变化。我们可能会获得可视化流程图或对话界面，向用户显示 "这是你的代理现在正在做的事情"。

也许经理可以在中间进行干预：“告诉招聘代理也筛选一下 Python 技能”——实质上不仅是与一个人工智能对话，而是与人工智能团队对话。新的用户体验范式可能会发展起来，用于协调和监督代理团队。谷歌提到的"像Agentspace这样的统一界面 "暗示了一个早期的想法，即作为用户管理多代理协作的单一场所。

未来的用户界面可以通过拖放来连接代理，或者通过仪表盘来显示某个代理是否需要获得批准才能继续工作等。

从单一的大模型到协同的多代理生态，人工智能在企业级落地的路径正逐渐演变为“分工+互联”的形态。A2A 协议的出现，意味着代理间可以跨越供应商与技术栈的限制，携手完成更庞杂而精细的工作流。结合其他开放标准（如 MCP）与各式功能调用（Function Calling），多代理协作可进一步摆脱“信息孤岛”的掣肘，为企业带来成倍的效率提升与灵活度。

当然，这一切仍处在早期阶段——生态建设、性能调优、标准化治理以及对多代理系统的管理与安全策略，都是摆在行业面前的现实课题。也正因如此，A2A 的诞生既是对当下分布式智能需求的直接回应，更预示着未来人工智能将以多代理的“互联网络”形态绽放新的可能。可以想见，随着更多厂商与开发者的加入，统一的协议和工具链将不断成熟，最终为各行各业带来开放互联的“AI 代理互联网”。