人们很容易将现代通信工具视为理所当然。在过去，我们中的一些人依赖他人来管理重要的工作任务，而跟踪所有事情十分困难。

即使在互联网上也是如此。在“HTTP”出现之前，大多数互联网文档都是孤立存在的。超文本传输协议将它们连接起来，并为网页浏览器提供了一套通用的访问规则。

如今的人工智能智能体有点像 HTTP 出现之前的网页。它们是由不同框架和技术栈提供服务的孤岛。可以构建自定义集成来弥合分歧，但这些集成可能昂贵、脆弱且难以扩展。

“没有通用标准，每一次集成都像是昂贵的胶带修补，”IBM 副总裁 Armand Ruiz 在 LinkedIn 上如是说。

IBM 的解决方案无需胶带修补。其智能体通信协议（ACP）为人工智能智能体提供了一种共享语言，使它们能够连接和协作，以执行复杂的现实世界任务。ACP 为开源平台 BeeAI 提供支持，用于发现、运行和组合人工智能智能体，IBM 已于三月份将其贡献给非营利性的 Linux 基金会。

在 YouTube 上观看此视频——我尝试使用 ACP（智能体通信协议）让大语言模型协同工作。

“我们的目标是构建智能体通信的 HTTP，”IBM Research 产品孵化总监 Kate Blair 说道，她领导了构建 BeeAI 的团队。

ACP 的设计旨在补充 Anthropic 的模型上下文协议（MCP），后者在六个月内已成为智能体访问外部工具和数据的标准化方式。ACP 和 MCP 旨在支持技术栈的不同层次，可以在任何多智能体编排系统中一起使用，包括 BeeAI。ACP 连接智能体与智能体；MCP 连接智能体与其工具和知识。

例如，一对智能体可以使用 MCP 同时收集市场数据并运行模拟，然后调用 ACP 来比较结果并提出建议。“要扩展现实世界的人工智能系统，我们两者都需要，”IBM Research 的产品经理 Jenna Winkler 在 LinkedIn 上写道。

ACP 和 MCP 针对各自的角色进行了定制。MCP 使用 JSON-RPC 作为其通信协议，而 ACP 采用基于 HTTP 实现的 RESTful 架构，支持同步和异步的智能体交互。

ACP 允许开发者直接使用 curl、Postman 或简单的网页浏览器等工具与智能体交互，无需专门的软件开发工具包（不过提供了 Python 和 TypeScript 的 SDK（软件开发工具包））。ACP 还允许智能体携带自己的元数据，以便即使在安全或气隙环境中也能被发现。

ACP 开辟了超越“管理者”模式的新架构，即由老板智能体调用其他智能体。借助 ACP，智能体可以作为对等方进行交互，而不是通过中介。当组织内部或外部的智能体需要自行处理业务时，这一点尤为重要。

“任何一方都应该能够发起对话或委派任务，”Blair 说。“在一个组织内，你可能有一个智能体在对客户查询进行分诊，它应该能够将客户发送给正确的服务智能体，然后由后者关闭工单。”

BeeAI 团队在 3 月于旧金山举行的 AI Dev 25 大会上展示了 ACP 的早期版本，该大会由科技企业家兼 DeepLearning.AI 创始人 Andrew Ng 主办。几周后，Google 发布了自己的智能体到智能体协议 A2A。

是否有空间容纳两种智能体协议？“绝对有，”Blair 说，“至少目前如此。现在还为时过早，我预计随着协议在真实世界使用中接受检验，会有很多次迭代。”

作为一个由社区主导、采用开放治理结构的项目，ACP 允许开发者采用并改进该标准，而不必担心供应商锁定。“我们每月举行开放社区电话会议，并设有活跃的 GitHub 讨论区，”Blair 说。“我们确保项目始终有任务供社区成员认领和参与。”

而且 ACP 已经成为 AI 课程的一部分。从 6 月 25 日开始，Linux Foundation 和 BeeAI 将通过 Ng 的教育平台 DeepLearning.AI 提供一门关于 ACP 的短期课程。ACP 课程将补充现有的 MCP 课程，并由 IBM AI 工程师 Sandi Besen 和 Nicholas Renotte 授课。请在日历上做好标记。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：IBM Research Blog

原创地址：https://research.ibm.com/blog/agent-communication-protocol-ai