Anthropic 推出了模型上下文协议（MCP），这是一个为大型语言模型提供实时结构化上下文的标准接口。

💡 看看我之前写的关于_MCP的文章哦。💡

https://modelcontextprotocol.io/

上下文数据注入功能
MCP 让你可以将外部资源——如文件、数据库行或 API 响应——直接注入提示或工作内存。这一切都通过一个统一的接口实现，这样你的大语言模型就能保持简洁和轻便。

功能路由及调用
MCP还允许模型动态调用工具，就像给AI提供了一个工具箱。你可以注册诸如searchCustomerData或generateReport之类的功能，LLM可以根据需要调用这些功能。但没有把这些工具硬编码进模型本身。

提示组合
与其在提示中塞满各种可能的细节，MCP 只组装出真正需要的关键上下文。这样可以实现模块化、即时构建提示——更智能的上下文，更少的 token（令牌），更优秀的输出结果。

• 支持通过 HTTP(S) 协议，并使用基于 JSON 的功能描述符
• 设计为不依赖于特定模型 — 任何兼容运行时的大型语言模型都可以使用符合 MCP 标准的服务器
• 兼容 API 网关和企业认证标准，如 OAuth2 和 mTLS

➀将LLM（大型语言模型）集成到内部API中: 这样可以以安全、只读或交互的方式访问结构化的业务信息，而不直接暴露原始接口。

企业代理角色：为自主代理程序配备来自Salesforce、SAP或内部知识库的运行时环境。

➂ 动态构建提示: 根据用户会话、系统状态或任务流程逻辑要求来动态构建提示

代理通信协议（ACP），是由BeeAI和IBM最初提出的一个开放标准，旨在实现同一本地或边缘环境中的AI代理之间的结构化通信、发现及合作。

与面向云的协议（如A2A）或上下文路由协议（如MCP）不同，ACP旨在实时的代理调度，具有最小的网络负担，并且在部署在共享运行时中的代理之间实现紧密协同。本地优先，这种设计确保了在最小网络负担下，实现部署在共享运行时中的代理之间的紧密协同。

ACP定义了一个去中心化的代理人环境，其中，

• 每个代理通过本地广播/发现层发布其身份、能力及状态。
• 代理通过事件驱动的消息传递进行通信，通常使用本地消息总线或进程间通信 (IPC) 系统。
• 可选的运行时控制器可以协调代理行动，聚合遥测，并执行策略。

ACP代理程序通常作为轻量级、无状态的服务或容器运行，并共享一个通信基础层。

• 设计用于低延迟场景（如本地编排、机器人、离线边缘AI）
• 可以通过gRPC、ZeroMQ或自定义运行时总线实现
• 强调本地主权，无需依赖云或注册外部服务
• 支持能力类型和语义描述符，以自动进行任务路由

在边缘计算设备上的多代理编排（例如，无人机、物联网集群、机器人舰队等）

本地优先的大规模语言模型系统协调着模型调用、传感器的数据输入和动作的执行

➂ 自主运行环境，其中智能体无需集中式云支持就能自我协调

简而言之，ACP 为运行时提供了一个本地协议层，侧重于模块化AI系统中的低延迟协调、弹性和可组合性。它非常适合注重隐私、自主性和边缘计算优先的部署，在这些情况下，云端优先的协议难以实施。

由 Google 引入的 Agent-to-Agent (A2A) 协议，是一种跨平台标准，旨在让 AI 智能代理能够在不同系统间进行沟通、合作和任务分配。

访问 Google 的 GitHub 页面: 谷歌GitHub主页: https://google.github.io/

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

A2A定义了一个基于HTTP的通信模型，其中代理被视作可互操作的服务。每个代理都会公开一个“代理卡片”——一个机器可读的JSON描述文件，详细说明其身份、功能特性、端点和认证需求。

工作人员利用这些信息来进行操作：

• 互相发现，通过编程方式
• 讨论任务分工
• 交流信息、数据和实时消息

A2A在设计上原则上是传输层无关的，但目前采用JSON-RPC 2.0 over HTTPS作为其交互的主要方式。

代理卡信息
描述代理的功能和端点、支持的消息类型和认证方式、以及运行时的元数据的 JSON 文档。

A2A 客户端/服务器界面
每个代理可以作为任务发起方（任务发起者）、任务执行方（任务执行者）或者两者皆是，从而实现动态的任务分配和协商。

消息与资源交换
支持多部分任务及其上下文、流式输出（通过Server-Sent Events）和持久化资源（例如文件和知识片段）。

用户体验调整
代理可以调整消息格式、内容粒度和可视化，来适应下游代理的能力。

• OAuth 2.0 和基于 API 密钥的授权
• 功能限定的端点 — 代理仅暴露所需功能以实现声明的交互
• 代理可以运行在“黑盒”模式下 — 隐藏内部逻辑，同时展示可调用的服务

• 专为 Web 设计：构建在 HTTP、JSON-RPC 和标准的 Web 安全机制之上
• 可与任何支持该协议的代理系统（如大语言模型等）配合使用
• 支持 任务流处理 和轻量级交互的多轮协作

➀ 跨平台代理生态体系，其中来自不同团队或供应商的代理需要安全地互相协作

➋ 分布式代理协调 在云原生 AI 环境中（例如：Vertex AI、LangChain、HuggingFace Agents）

➂ 多代理协作框架（如涉及CRM、HR和IT代理的企业AI流程），横跨多个系统，例如CRM、HR和IT代理。

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，因为它跳过了 web 原生协议的复杂步骤，直接在本地搞定任务。

随着更多团队采用这些协议，几种可能的未来形态正在逐渐浮现。

最好的情况是？ 最好的情况是我们能实现技术的融合。想象一下，有一个统一的代理平台，A2A 负责代理之间的沟通，MCP 管理对工具和数据的访问，而 ACP 风格的运行时则可以应用于边缘或离线情况。所有的一切都能顺畅运行，开发人员可以在此基础上构建，无需担心背后用了哪种协议。

最坏的情况？ 最糟糕的情况是，事情变得支离破碎。不同的供应商各自推广他们自己的A2A或MCP，导致一个混乱的局面——就像早期的Web服务一样，各不相通，需要大量胶水代码才能实现通信。

中间地带？ 开源工具和中间件可能会成为救星。这些项目将位于代理和协议之间，根据代理运行的位置和方式来翻译，抽象这些差异，为开发人员提供一个干净统一的API接口。

简而言之：我们才刚刚开始。但我们现在如何构建和采用这些标准的制定和采用，会影响AI代理是形成一个统一的生态系统还是各自为政的孤岛。

如果你不知道从哪里开始着手，或者如何将所有内容整合在一起，Addepto 的团队可以提供帮助。我们已经帮助公司从“我们如何使用这个？”到快速建立完全运行的代理生态系统。你也可以通过我的 LinkedIn 联系我。
[MCP]：模型上下文协议（Model Context Protocol）
[LLM]：大型语言模型（Large Language Model）
[RAG]：检索增强生成（Retrieval-Augmented Generation）
[SSE]：服务器发送事件（Server-Sent Events）