智能体通信协议 (ACP) 是智能体之间通信的开放标准。通过该协议，我们可以将当前的环境转变为可互操作的智能体系统，从而更轻松地进行整合和协作。
借助最初由 IBM 的 BeeAI 推出的 ACP，AI 智能体可以跨团队、框架、技术和组织进行自由协作。这是一项通用协议，将如今各自为政的 AI 智能体转化为互联互通的协作伙伴；凭借这一开放标准，互操作性、复用能力与规模水平都跃升至全新层次。模型上下文协议（MCP）是工具和数据访问的开放标准，作为该协议的下一步，ACP 定义了智能体的操作和通信方式。1
就上下文而言，AI 智能体是指能够代表用户或其他系统自主执行任务的系统或程序。它通过设计工作流并利用可用工具来实现这些功能。多智能体系统 (MAS) 由多个 AI 智能体组成，它们共同工作，代表用户或其他系统执行任务。
ACP 作为一个开放治理的 AI 智能体通信标准，允许 AI 智能体跨不同的框架和堆栈进行通信。从接受用户以自然语言形式提出的询问到执行一系列操作，AI 智能体在使用通信协议的情况下会表现得更好。这些协议在工具、其他智能体之间传递此信息，并最终传递给用户。
AI 智能体通信是指人工智能智能体如何相互交互、与人类或外部系统交互以交换信息、做出决策并完成任务。这种通信在多智能体系统（多个 AI 智能体协作）和人机交互中尤其重要。
ACP 是包括 BeeAI 在内的日益壮大的生态系统的一部分。以下是一些主要功能，您可以在官方文档中阅读更多有关核心概念和详细信息的内容。
- 基于 REST 的通信：ACP 使用标准 HTTP 协议进行通信，因此很容易集成到生产环境中。而 MCP 依赖于 JSON-RPC 格式，需要复杂得多的通信方法。
- 无需 SDK： ACP 不需要任何专门的库。您可以使用 cURL、Postman 甚至浏览器等工具与智能智能体进行交互。为了增加便利性，还提供 SDK。
- 离线发现：ACP 智能体可以将元数据直接嵌入到其分发包中，即使处于非活跃状态也能被识别。这支持缩放到零环境，能够动态分配资源，且无需保持持续在线状态。
- 异步优先，支持同步：ACP 设计时以异步通信为默认模式。此方法非常适合长时间运行或复杂的任务。ACP 也支持同步请求。
注意：ACP 可为任何智能体器架构提供智能体编排，但不管理智能体之间的工作流、部署或协调。相反，它通过标准化不同智能体的通信方式，实现了不同智能体之间的协调。IBM Research 构建了 BeeAI，这是一个开源系统，旨在通过使用 ACP 作为通信层来处理智能体编排、部署和共享。
随着智能体式 AI 不断发展，如何为用例在不受限于特定供应商的情况下从每种独立技术中获得最佳结果的复杂性也在不断增加。每个框架、平台和工具包都具有独特的优势，但将它们全部集成到一个智能体系统中却极具挑战性。
如今，大多数智能体系统都孤立运行。这些系统基于互不兼容的框架开发，对外提供定制化 API 与端点服务，且缺乏统一的通信协议标准。连接它们需要脆弱且不可重复的整合，构建成本高昂。
ACP 代表了一种根本性变革：从原本碎片化、临时拼凑的生态系统，转变为由智能体构成的互联网络——其中每个智能体都能自主发现、理解并与其他智能体协作，无论其开发者或底层技术栈为何。借助 ACP，开发人员可以利用不同智能体的集体智慧来构建比单个系统单独实现的更强大的工作流。
为了说明现实世界中智能体与智能体之间通信的需求，请考虑两个组织：
- 一家制造公司，使用自主智能体根据内部库存和客户需求来管理生产计划和订单履行。
- 一家物流提供商，通过智能体提供实时运输估价、承运商可用性查询和路线优化。
现在假设制造商的系统需要为一笔大型定制设备订单估算交货时间，以便向客户报价。
不使用 ACP： 此方法需要在制造商的规划软件与物流提供商的 API 之间构建定制整合。这意味着要手动处理身份验证、数据格式不匹配和服务可用性等问题。随着更多合作伙伴的加入，这些整合成本高昂、脆弱且难以扩展。
使用 ACP： 每个组织都用 ACP 接口包装其智能体。制造智能体将订单和目的地详细信息发送给物流智能体，物流智能体则回复实时运输选项和预计到达时间 (ETA)。这两个系统都执行智能体协作，而无需公开内部或编写自定义整合。只需实施 ACP 即可引入新的物流合作伙伴。AI 智能体与 ACP 配合提供，可提供自动化功能，从而实现可扩展性并简化数据交换。
简易性是 ACP 的核心设计原则。只需几行代码即可使用 ACP 包装智能体。使用 Python SDK ，您只需通过函数装饰器即可定义一个符合 ACP 标准的智能体。
此为最简实现：
- 创建 ACP 服务器实例。
- 使用 @server.agent() 装饰器定义智能体函数。
- 该智能体基于 LangChain 框架实现，采用大语言模型（LLM）作为后端，并配备记忆模块以实现上下文持久化。
- 在 ACP 消息格式和框架本地格式之间进行转换，以返回结构化的响应。
- 启动服务器，使智能体可通过 HTTP 访问。
代码示例：
from typing import Annotated
import os
from typing_extensions import TypedDict
from dotenv import load_dotenv
#ACP SDK
from acp_sdk.models import Message
from acp_sdk.models.models import MessagePart
from acp_sdk.server import RunYield, RunYieldResume, Server
from collections.abc import AsyncGenerator
#Langchain SDK
from langgraph.graph.message import add_messages
from langchain_anthropic import ChatAnthropic
load_dotenv()
class State(TypedDict):
messages: Annotated[list, add_messages]
#Set up the AI model of your choice
llm = ChatAnthropic(model="claude-3-5-sonnet-latest",
api_key=os.environ.get("ANTHROPIC_API_KEY"))
#------ACP Requirement-------#
#START SERVER
server = Server()
#WRAP AGENT IN DECORACTOR
@server.agent()
async def chatbot(messages: list[Message])-> AsyncGenerator[RunYield, RunYieldResume]:
"A simple chatbot enabled with memory"
#formats ACP Message format to be compatible with what langchain expects
query = " ".join(
part.content
for m in messages
for part in m.parts
)
#invokes llm
llm_response = llm.invoke(query)
#formats langchain response to ACP compatible output
assistant_message = Message(parts=[MessagePart(content=llm_response.content)])
# Yield so add_messages merges it into state
yield {"messages": [assistant_message]}
server.run()
#---------------------------#
现在，您已经创建了一个完全符合 ACP 标准的智能体，它可以：
- 被其他智能体（在线或离线）发现。
- 同步或异步处理请求。
- 使用标准消息格式进行通信。
- 与任何其他与 ACP 兼容的系统集成。
为了更好地理解 ACP 在不断发展的 AI 生态系统中的作用，我们不妨将其与其他新兴协议进行比较。这些协议并不一定是竞争对手。相反，它们涉及 AI 系统整合的不同层，并且通常相互补充。
概述：
模型上下文协议 (MCP)：旨在通过工具、内存和资源丰富单个模型的上下文。由 Anthropic 推出。
重点：一个模型，多种工具
智能体通信协议 (ACP)：专为跨系统和跨组织的独立智能体之间的通信而设计。由 IBM 的 BeeAI 推出。
重点：实现多智能体安全对等协作，避免供应商锁定，采用开放治理模式
智能体间通信协议 (A2A)：专为跨系统和跨组织的独立智能体之间的通信而设计。由 Google 推出。
重点：众多智能体协同工作，针对 Google 生态系统进行优化
ACP 团队最初探索调整模型上下文协议 (MCP)，因为它为模型-上下文交互提供了坚实的基础。然而，该协议很快就遇到了架构限制，使其不适合真正的智能体与智能体之间的通信。
为什么 MCP 不适合多智能体系统：
流式传输：MCP协议支持基础流式传输（通常为完整消息），但未实现更细粒度的“增量更新”（delta）模式——即无法在数据变动时实时推送更新。Delta流，如令牌和轨迹更新，是由增量更新而非完整数据负载组成的流。这种限制源于这样一个事实，即在创建 MCP 时，它并不适用于智能体式交互。
记忆共享： MCP 不支持在维护共享记忆的同时跨服务器运行多个智能体。ACP 也尚未完全支持此功能，但这是一个正在开发的领域。
消息结构：MCP 接受任何 JSON 架构，但不定义消息正文的结构。这种灵活性为互操作性带来了困难，特别是对于构建必须解释不同消息格式的智能体而言。
协议复杂性：MCP 使用 JSON-RPC 并需要特定的 SDK 和运行时。而 ACP 基于 REST 的设计具有内置的异步/同步支持，更加轻量级且易于整合。
将 MCP 想象给个人提供更好的工具（例如计算器或参考书），以提高其性能。相比之下，ACP 旨在支持人们组建团队，其中每个人或智能体在 AI 应用程序中协作贡献自己的能力。
ACP 和 MCP 可以相互补充：
在 ACP 之后不久，Google 推出了 Agent2Agent 协议 (A2A)，该协议也旨在规范 AI 智能体之间的通信。两种协议均以实现多智能体系统为目标，但在原理和治理模式上存在显著差异。
主要区别：
ACP 的设计初衷是：
- 通过使用常见的 HTTP 工具和 REST 协议，可轻松实现集成。
- 灵活适用于各种智能体类型和工作负载。
- 供应商中立，具有开放式管理和广泛的生态系统一致性。
这两种协议可以共存，根据环境，每种协议可以满足不同的需求 。ACP 的设计轻便、开放且可扩展，非常适合分布式系统和现实世界中的跨组织互操作性。A2A 的自然整合可能使其成为更适合使用 Google 生态系统的用户的选择。
随着 ACP 的发展，我们正在探索加强智能体通信的新可能性。以下是一些重点关注领域：
- 身份联合：ACP 如何与身份验证系统配合使用以提高跨网络的信任？
- 访问委派：我们如何使智能体能够安全地委派任务，同时保持用户控制？
- 多注册表支持：ACP 能否支持跨不同网络的分散式智能体发现？
- 智能体共享： 如何才能更轻松地在组织之间或组织内分享和重用智能体？
- 部署： 哪些工具和模板可以简化智能体部署？
ACP 正在采用开源方式开发，因为只有直接与用户共同开发的标准才能发挥最大作用。我们欢迎开发人员、研究人员及关注 AI 智能体互操作性发展的各界组织积极参与贡献。加入我们，帮助制定这一不断发展的生成式 AI 标准。
资源
构建、部署和管理强大的 AI 助手和智能体，运用生成式 AI 实现工作流和流程自动化。
借助值得信赖的 AI 解决方案，您可以勾勒未来业务发展蓝图。
IBM Consulting AI 服务有助于重塑企业利用 AI 实现转型的方式。