Agent Communication Protocol

1. 调研缘由

ACP 全称 Agent Communication Protocol，是面向 AI agents、应用和人类协作的开放协议。它要解决的问题很直接：agent 越来越多，但彼此往往被困在不同框架、团队和基础设施里，难以互相发现、通信和协作。[S1][S2]

它值得看，是因为 agent 生态如果继续碎片化，每家公司都会做自己的 agent、自己的消息格式、自己的工具链。到最后，自动化能力会很多，但跨系统协作会很差。

这篇主要回答：ACP 做什么；它和 MCP、A2A、AG-UI 的差异；以及为什么 agent 协议层正在从“好奇概念”变成工程基础设施。

2. 简介与产品工作流

ACP 官方文档把它定义为 open protocol for agent interoperability，用来连接 AI agents、applications 和 humans，并通过 standardized RESTful API 支持 agent 通信。[S1]

GitHub 仓库也说明，ACP 是 open protocol for communication between AI agents, applications, and humans，支持用 multimodal messages 进行 communication and coordination。[S2]

一个典型工作流可以拆成四步：

1. agent 暴露标准接口：不同框架里的 agent 按 ACP 规范暴露能力、消息和交互入口。[S1][S2]
2. 应用或其他 agent 发现并调用：调用方不必理解对方内部框架，只需按协议通信。
3. 通过 RESTful API 与多模态消息交换任务：ACP 重点是通信、协调和互操作，而不是定义模型本身。[S1][S2]
4. 在平台层组合多个 agent：企业可以把不同来源的 agent 接入统一平台或工作流。

因此，ACP 的核心价值是降低 agent 之间的互操作成本。

3. 团队与资本背景

IBM Research 的介绍说明，ACP powers BeeAI，BeeAI 是用于 discovering、running 和 composing AI agents 的 open-source platform；IBM 在 2025 年 3 月把 BeeAI 贡献给 Linux Foundation。[S3]

LF AI & Data Foundation 文章也说明，IBM Research 在 2025 年 3 月推出 ACP，随后 BeeAI 项目和 ACP 被捐赠给 Linux Foundation。[S4]

这意味着 ACP 不是某个单一厂商内部接口，而是在往开放治理和社区路线移动。

4. 技术基础与生态位

ACP 的技术基础是 RESTful API、结构化 agent 描述、消息交换和多模态通信。[S1][S2]

IBM Think 页面把 ACP 描述为 open standard for agent-to-agent communication，目标是把孤立 agent 变成可互操作的 agentic systems。[S5]

生态位上，ACP 处在 agent 协议层。MCP 更偏工具和上下文接入，AG-UI 更偏 agent 和用户界面的事件流，A2A 更偏 agent 间协作与互操作；ACP 的重点也是 agent 间通信，但有 IBM/BeeAI 和 Linux Foundation 背景。[S4][S5]

5. 市场与外部信号

ACP 的市场信号来自官方文档、GitHub、IBM Research、IBM Think 和 LF AI & Data Foundation。[S1][S2][S3][S4][S5]

LF AI & Data Foundation 还提到 ACP joins forces with A2A under the Linux Foundation，这说明 agent 互操作标准可能会走向合并、兼容或分工，而不是无限分叉。[S4]

对企业来说，这类协议的吸引力在于减少平台锁定：今天用这个 agent 框架，明天接另一个 agent 框架，理想情况下不需要重写所有通信逻辑。

6. 公开评价与主要分歧

正面评价：

ACP 的优势是问题真实。agent 孤岛、框架碎片化、跨团队协作困难，是企业落地 agent 时一定会遇到的工程问题。[S1][S5]

另一个优势是开放治理信号。Linux Foundation 相关路径能增加企业对协议长期性的信任。[S4]

主要分歧：

第一是协议竞争。MCP、A2A、AG-UI、ACP、Agent Client Protocol 等名字相近，开发者很容易混淆。

第二是生态采纳。协议是否有价值，最终取决于主流 agent 框架、IDE、云平台和企业系统是否真的接入。

第三是边界收敛。ACP 与 A2A 的关系如果继续演进，后续标准名称和实现路径可能发生变化。

7. 同类对比（与头部/高知名度同类项目）

主要对标项目： MCP、A2A、AG-UI、Agent Client Protocol。

维度	ACP	MCP	A2A	AG-UI
核心定位	agent、应用、人类之间通信与互操作。[S1][S2]	模型/agent 连接工具和上下文。	agent 间通信协作。	agent 与用户界面交互。
强项	RESTful、开放协议、IBM/BeeAI/Linux Foundation 背景。[S3][S4]	工具生态扩散快。	跨 agent 协作叙事清晰。	前端状态和实时 UI。
适合场景	多 agent 平台、企业系统互操作。	工具调用和上下文接入。	agent 联邦和任务分发。	产品化 agent UI。
风险	与 A2A 边界需继续观察。	工具安全和权限。	标准成熟度。	生态采纳。

ACP 的差异点，是把 agent 通信问题放在开放、RESTful、跨框架互操作这个工程切口上。

8. 信息缺口与后续观察

本文未核验 ACP 当前生产部署数量、主流框架接入程度、与 A2A 合并后的长期路线和企业真实使用案例。

后续重点观察：ACP 与 A2A 的关系是否继续收敛；BeeAI 是否形成平台采用；以及主流 agent 框架是否把 ACP 当作默认互操作层。

9. 归纳洞察 ★

ACP 的意义不在于又多了一个 agent 名词，而在于它承认了一个现实：未来不会只有一个 agent 框架。

企业里会同时存在客服 agent、数据 agent、代码 agent、知识库 agent、流程 agent。它们如果不能沟通，就只是很多孤立自动化；它们如果能沟通，才可能组成真正的业务系统。

所以 ACP 这类协议最终比拼的不是概念，而是谁能让不同 agent 在真实组织里少一点胶水代码，多一点可复用协作。

10. 来源与更新时间

• 信息截至(as_of): 2026-07-30
• 最后复查(last_checked): 2026-07-30
• 最后更新(last_updated): null