Agent 侧的协议生态：MCP、ACP、A2A 各管什么
数据截至 2026-07，价格与限额以各官网为准。
MCP、ACP、A2A 不是三个互相抢地盘的竞品，它们连的根本不是同一种东西——MCP 解决的是”agent 怎么调用外部工具和数据源”，另外两个缩写指向的是”agent 怎么跟宿主客户端说话”和”agent 怎么跟另一个 agent 说话”。真正需要你现在就投入工程成本去对齐的只有一层，剩下两层更多是先看清问题边界、别急着押注。
一个很常见的误解是：既然都叫协议，那总得选一个，选错了要重构。这个焦虑在选框架时成立，在选这三者时不太成立。它们的关系更接近网络分层——你不会纠结”用 HTTP 还是用 TCP”，因为它们本来就在不同高度上。下面按”这一层到底连的是什么”把三者拆开讲，并且把哪些是能查到一手规范的、哪些只能以各自官方文档当前版本为准，明确区分开。
先把问题分层：一个 agent 要连的三种东西
拿掉所有缩写，一个跑在生产里的 agent 至少要跟三类对象打交道：
- 工具和数据源：查数据库、调内部 API、读文件、跑一次搜索。这一层的核心难题是”能力发现”——agent 事先并不知道对面有哪些工具、每个工具要什么参数、返回什么结构，需要一套标准让它问出来。
- 宿主客户端：agent 跑在某个 IDE、某个聊天界面、某个桌面应用里，需要往界面上推进度、要一次用户确认、渲染一个交互式的结果。这一层的难题是 UI 契约和会话生命周期。
- 另一个 agent：把一个子任务交给别的团队、别的公司做的 agent，对方是黑盒，你只知道它声称能干什么。这一层的难题是身份、授权、任务状态同步和结果可验证。
三类需求的技术形态差别很大，硬要用一套协议全兜住，只会兜出一个谁都不好实现的巨型规范。所以生态自然分叉成了几套东西，这是分工，不是内耗。
MCP 管的是第一层，而且是目前最实在的一层
MCP（Model Context Protocol）解决的是上面第一类问题：让模型/agent 用统一的方式发现并调用外部工具与数据源，不用为每个数据源写一遍胶水代码。这一层现在最值得投入，理由不是它”更先进”，而是它已经跨过了”只有提出方自己在用”的阶段。
几条可以确认的背景：2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，从一家公司的规范变成厂商中立、社区治理的标准；OpenAI、Google、Microsoft、AWS 都已经把它接进了各自的 agent 栈。按官方与行业公开资料的口径，生产环境中的公开 MCP server 超过一万个，SDK 月下载量超过 9,700 万——这类数字是汇总口径而非精确统计，看趋势就够了，不必当成可引用的精确指标。
对工程选型来说，这些背景意味着一件很具体的事：你为一个数据源写的 MCP server，不只服务于某一家的客户端。这是”投入不容易打水漂”的判断依据，比任何架构美感都实在。基础概念可以先看MCP 是什么？为什么说它是 AI 的 USB 接口。
2026-07-28 这版规范，把 MCP 的边界又重新划了一次
值得注意的是，MCP 自己也在收缩边界，而不是往外扩。2026 年 7 月 28 日发布的新规范，官方称是自协议发布以来最大的一次修订，兑现了 2026 年路线图。六块变化里，有三块直接影响你怎么理解”MCP 管到哪儿为止”：
一、协议内核变成无状态的。 这一处由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，落地了此前 “The Future of MCP Transports” 里的计划。协议层不再要求会话追踪，直接的工程结果是：以前需要粘性会话、共享 session 存储、网关做深度包检测才能跑起来的远程 server，现在可以直接放在普通轮询负载均衡后面，按 Mcp-Method 头路由。
这里要防一个理解偏差：无状态说的是协议层不再要求会话追踪，不等于”MCP 里不能有状态了”。应用层自己怎么存上下文、怎么做会话，是另一回事，规范没有禁止。这个点展开在MCP 变成无状态了：粘性会话和共享 session 存储可以撤了。
二、Tasks 被移出核心协议。 用于长时间运行操作的 Tasks 特性从核心挪到了 extension。这个动作的信号意义大于功能本身——核心协议在往”薄”的方向走，把可选能力交给 Extensions 框架，你也可以自建 extension，和官方认可的 extension 并存。
三、授权向真实 OAuth 部署靠拢。 另有 6 个 SEP 让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署，其中包括要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。这条对跨 agent、跨组织的调用尤其关键——身份和签发方校验是分布式信任的地基。
代价也得说清楚：这是一次破坏性变更。维护者 David Soria Parra 称这是自加入授权以来最实质的变更，他的原话是 “A lot of things that made MCP are gone.”。新版本的 server 可能无法与旧 client 协同，反之亦然；官方给旧版本留了 12 个月的弃用窗口。也就是说，如果你手上有跑着的 MCP 集成，接下来要做的不是研究另外两个协议，而是先把版本兼容排期定下来，可以对照新旧 MCP 版本不兼容怎么办：12 个月弃用窗口怎么用。
另外，找 server 别再靠翻仓库和收藏夹了：官方 MCP Registry（registry.modelcontextprotocol.io）提供 server 发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织社区驱动维护。路线图上还有 MCP Server Cards——通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用真的连上去就能知道这个 server 能干什么。
另外两层：ACP 和 A2A 想解决什么
这里必须先说一句诚实话：本文对 MCP 的描述有官方博客与规范文档作依据，而对 ACP、A2A 这两个缩写，我不打算复述具体的版本号、发布日期、维护方归属和网址——这类信息变动快，写错了比不写危害更大。以各自官方规范文档的当前版本为准。能有把握说的是它们所处的层，以及为什么这层的问题和 MCP 不是一回事。
A2A 这个方向对应的是 agent 与 agent 之间的通信。 场景是：你的 agent 需要把一个子任务委托给另一个不受你控制的 agent，对方可能属于另一个部门甚至另一家公司。这时候要解决的问题清单跟调用工具完全不同——对方的能力怎么声明和发现、任务是长时运行的所以状态怎么同步、双方的身份怎么互认、结果出了问题责任怎么界定。它更像企业间的接口对接，而不是函数调用。
ACP 这个方向对应的是 agent 与承载它的客户端之间的通信。 也就是 agent 跑在编辑器或某个应用里时，怎么往界面推送中间过程、怎么请求一次用户确认、怎么渲染一个可交互的结果，而不是只吐一段文本。
再提醒一个实际的坑：ACP 这三个字母在不同项目里被用来指过不止一种东西。看到这个缩写，第一件事是确认它出自谁、指向哪份规范，而不是默认跟你上次读到的是同一个。这不是学究式的挑刺——协议名撞车导致的选型误会，在这个阶段是真实存在的风险。
怎么判断你现在该投哪一层
给一个可以直接照着走的判断顺序：
- 你的 agent 需要读写外部系统吗？ 需要就先做 MCP 这一层，这是当前投入产出比最确定的部分。先把内部那几个高频数据源包成 server，别一上来就追求覆盖全部系统。
- 你的 agent 有没有自己的宿主界面？ 如果你只是做后台任务、没有交互界面，客户端协议这一层暂时可以完全不看。如果你在做 IDE 插件或桌面应用，也建议先用宿主自带的机制跑通，等规范稳定再考虑抽象。
- 你有没有真实的跨组织 agent 协作需求？ 注意是”真实的”——大多数团队所谓的多 agent，其实是同一个进程里的几个角色，那是框架内部的调度问题，用不上跨 agent 协议，可以参考主流 AI Agent 框架对比：LangGraph/LlamaIndex/Coze。只有当对面的 agent 确实不由你部署、不由你升级时，这一层才成立。
多数团队走完第一条就够用很久了。把第二、三层当成”知道有这么回事，出现需求时再回来看”，比现在就抽象一套自研中间层要划算。
三层同时用的时候，工程上注意什么
如果你确实到了三层都要碰的阶段，有几个容易翻车的点：
- 鉴权别混成一锅。 agent 调工具的凭据、agent 代表用户行事的凭据、agent 之间互认的凭据，是三套不同的东西。MCP 这次把
iss校验写进要求，就是在提醒这件事——凭据用错层，出问题时根本查不出是谁授权的。 - 版本协商要留日志。 破坏性变更已经发生过一次，以后还会有。握手阶段双方各自报了什么版本、最终协商到哪个，这些必须落在日志里，否则线上出现”某些客户端能用、某些不能用”时，你只能靠猜。
- 能力发现别写死。 把对面有哪些工具硬编码进代码，等于放弃了这套协议最大的价值。用注册表和元数据发现机制拿，别在代码里维护一份手抄清单。
- 失败要能降级。 跨 agent 调用天然更慢更不稳，超时和不可用是常态而非异常。设计的时候就要想好这一步失败了整个任务怎么继续，而不是让用户看到一个卡死的界面。
诚实说局限
几点必须讲明：第一，这个领域的中文资料覆盖非常薄，很多中文教程还停留在更早的版本，甚至有站点仍把旧版本列为当前稳定版——遇到与官方博客口径不一致的二手资料，一律以官方为准。第二，本文对 MCP 的具体条目有一手依据，对另外两个方向只描述问题域，不给规范细节，请自行核对各自官方文档。第三，生态规模的数字是公开资料汇总口径，不是审计过的统计。第四，涉及海外厂商的服务时，这几家官方并未把中国大陆列为受支持地区，注册、控制台与端点都在境外，具体以各自官网当前的地区政策页为准；本文不提供也不背书任何第三方中转渠道。
小结
一，这三类协议是分层关系不是竞争关系，分别对应 agent 连工具、连宿主客户端、连其他 agent。二，MCP 是目前唯一值得立刻投入工程成本的一层，它已经完成治理中立化，主流厂商都接了。三，2026-07-28 的新规范把核心做薄了——无状态内核、Tasks 移出核心、授权加固，同时也带来了破坏性变更，旧版本有 12 个月弃用窗口，手上有存量集成的应当先排兼容而不是追新概念。四，另外两层先理解问题边界，具体规范以各自官方文档当前版本为准，尤其留意缩写撞名。五，真到了三层并用的时候，最先出问题的通常是鉴权分层和版本协商日志，这两件事值得提前做。