什么是MCP（模型上下文协议）？

The Model Context Protocol (MCP), introduced by Anthropic，定义一个标准化界面，用于向大语言模型（LLMS）提供结构化的实时上下文。

核心功能

上下文数据注入
MCP使您可以将外部资源（例如文件，数据库行或API响应）从提示或工作记忆中删除。所有这些都来自标准化的界面，因此您的LLM可以保持轻巧和干净。

功能路由和调用
MCP还使模型动态呼叫工具。您可以注册功能searchCustomerData或者generateReport，LLM可以按需调用它们。这就像让您对工具箱的AI访问，但没有将工具纳入模型本身。

及时编排
MCP并没有用任何可能的细节来填充提示，而是帮助组装重要的上下文。想想模块化，即时及时的构建 - 更聪明的上下文，更少的令牌，更好的输出。

实施特征

• 通过基于JSON的功能描述符在HTTP上运行
• 设计为模型 - 敏捷 - 任何具有兼容运行时的LLM都可以利用符合MCP的服务器
• 与API网关和企业身份验证标准兼容（例如OAuth2，MTLS）

工程用例

内部API的LLM集成： 启用对结构化业务数据的安全，只读或交互式访问，而无需公开原始端点。

企业代理： 为自主代理配备诸如Salesforce，SAP或内部知识库之类的工具的运行时上下文。

动态提示构建： 根据用户会话，系统状态或任务管道逻辑裁缝提示

什么是ACP（代理通信协议）？

The Agent Communication Protocol (ACP) is an open standard originally proposed by BeeAI and IBM在同一本地或边缘环境中运行的AI代理之间的结构化通信，发现和协调。

与面向云的协议（例如A2A或MCP等上下文路由协议）不同，ACP是为本地优先的，实时的代理编排设计的，其在共享运行时内部部署的代理部署，并在跨代理中进行紧密集成。

协议设计与体系结构

ACP定义了一个分散的代理环境，其中：

• 每个代理商都使用本地广播/发现层宣传其身份，功能和状态。
• 代理通过事件驱动的消息传递，通常使用本地总线或IPC（过程间通信）系统进行通信。
• 运行时控制器（可选）可以协调代理行为，汇总遥测和执行执行策略。

ACP代理通常用具有共享通信基板的轻巧，无状态服务或容器运行。

实施特征

• 专为低延迟环境（例如本地编排，机器人技术，离线边缘AI）而设计
• 可以通过GRPC，Zeromq或自定义运行时总线实现
• 强调本地主权 - 无需云依赖或外部服务注册
• 支持自动任务路由的功能打字和语义描述符

工程用例

• Edge设备上的多代理编排（例如，无人机，物联网簇或机器人舰队）

• 本地优先的LLM系统协调模型调用，传感器输入和操作执行

• 自主运行时环境代理必须在没有集中云基础架构的情况下进行协调

简而言之，ACP为模块化AI系统提供了一个运行时 - 本地协议层 - 优先考虑低延迟协调，弹性和合成性。这是对隐私敏感，自主或边缘优先部署的自然拟合，在云领先协议不切实际的情况下。

什么是A2A（代理到代理协议）？

The Agent-to-Agent (A2A) Protocol, introduced by Google,是使AI代理能够在异质系统上进行交流，协作和委派任务的跨平台规范。

https://google.github.io/

与ACP的本地优先焦点或MCP的工具集成层不同，A2A解决了水平互操作性 - 标准化来自不同供应商或运行时间的代理如何可以在开放网络上交换功能并协调工作流程。

协议概述

A2A定义了基于HTTP的通信模型，其中代理被视为可互操作的服务。每个代理都会公开“代理卡” - 一个机器可读的JSON描述符，详细介绍其身份，功能，端点和身份验证要求。

代理使用此信息来：

• 以编程方式互相发现
• 协商任务和角色
• 交换消息，数据和流传输更新

A2A原则上是运输层的不可知论，但目前指定HTTPS上的JSON-RPC 2.0是其相互作用的核心机制。

核心组件

代理卡：JSON文档描述了代理的功能，端点，支持的消息类型，auth方法和运行时元数据。

A2A客户端/服务器接口：每个代理可以用作客户端（任务启动程序），服务器（任务执行程序）或两者兼而有之，从而实现动态任务路由和协商。

消息和工件交换：支持具有上下文，流量输出（通过SSE）和持久文物（例如，文件，知识块）的多部分任务。

用户体验谈判：代理可以调整消息格式，内容粒度和可视化以匹配下游代理能力。

安全体系结构

• OAuth 2.0和基于API密钥的授权
• 功能范围的终点 - 代理仅揭示声明交互所需的功能
• 代理可以在“不透明”模式下运行 - 隐藏内部逻辑，同时揭示可呼出的服务

实施特征

• 设计：建立在HTTP，JSON-RPC和标准网络安全性上的网络本地。
• 模型 - 敏捷：与实现协议的任何代理系统（LLM或其他）一起工作
• 支持任务流和与轻量级有效载荷的多转弯合作

工程用例

➀跨平台代理生态系统，来自不同团队或供应商的代理需要安全地进行互操作

➁分布式代理编排在云本地AI环境中

➂多代理协作框架，例如跨越多个系统的企业AI工作流（例如CRM，HR，IT代理）

协议并排比较

互补还是竞争？

A2A + MCP

A2A和MCP并没有互相战斗 - 他们正在解决代理AI难题的完全不同的部分，并且它们实际上很好地融合在一起。

https://google.github.io/

将MCP视为使AI代理插入世界的协议。它使他们可以访问文件，API，数据库 - 基本上，他们需要做一些有用的事情所需的所有结构化上下文。无论是提取实时销售数据还是生成自定义报告，MCP都可以处理与工具和数据的连接。

现在在A2A上分层。这是代理商开始合作的地方。 A2A为他们提供了共同的语言和一组规则，可以互相发现，委派任务并协商他们将如何一起工作 - 即使它们是由不同的供应商构建或在不同平台上运行的。

因此，这是一种思考它的简单方法：
MCP将AI连接到工具。
A2A将AI连接到其他AI。

它们共同形成了建立智能，协作系统的强大模块化基础。

那ACP呢？

然后是ACP，完全采用了不同的方法。这全都与本地第一代理协调有关 - 无需云。 ACP不使用HTTP和基于Web的发现，而是使代理可以在共享运行时在共享运行时找到和交谈。

这非常适合以下情况：

• 您的带宽有限或需要低延迟（例如机器人或设备助手），
• 隐私很重要，您想让一切脱机，
• 或者您要在从互联网切断的环境中部署（例如工厂地板，边缘节点）。

ACP并没有试图与A2A竞争 - 它只是填补了不同的利基市场。但是在某些设置中，尤其是在严格控制的环境中，ACP可能会完全替换A2A，因为它跳过了网络本地协议的开销，而只是在本地完成了工作。

收敛还是碎片？

随着越来越多的团队采用这些协议，一些可能的未来正在形成。

最好的情况？ 我们看到融合。想象一下一个统一的代理平台，其中A2A处理代理之间的来回，MCP管理工具和数据的访问，以及ACP风格的Runtimes插入边缘或离线场景。一切都可以正常工作，开发人员可以在顶部建立，而不必担心哪种协议在幕后做什么。
最坏的情况 碎片。不同的供应商推出了自己的A2A或MCP的口味，我们最终遇到了一团糟 - 就像Web Services的早期一样，当时没有很多胶水代码，什么也没有与其他人交谈。
中间地面？ 开源工具和中间件可以节省一天。这些项目将位于代理和协议之间，将差异抽象并为开发人员提供干净，统一的API - 同时根据代理的何处和方式在引擎盖下翻译。

简而言之：我们还早。但是，现在我们如何构建和采用这些标准将塑造AI代理是否成为一个凝聚力的生态系统，还是孤岛拼凑而成。