摘要：MCP （Model Context Protocol）作为连接大模型与外部工具的通信协议，近期因谷歌推出 A2A（Agent-to-Agent）协议引发争议。
OSCHINA
MCP （Model Context Protocol）作为连接大模型与外部工具的通信协议，近期因谷歌推出 A2A（Agent-to-Agent）协议引发争议。
谷歌新发布的A2A协议，要吃掉MCP？
MCP 凭借其简洁的设计和 OpenAI 等巨头的支持，迅速成为大模型与外部工具交互的事实标准。其核心价值在于解决了两个关键问题：一是标准化接口：将工具能力封装为统一的函数描述（如 API 格式、参数定义），降低模型调用复杂度；二是上下文管理：通过动态维护工具调用记录，辅助大模型生成连贯的操作链条。
这种 “模型中心化” 的设计思路，使其在开发者中广受欢迎。然而，随着谷歌推出 A2A 协议，MCP 的 “护城河” 开始遭遇挑战。
MCP 能否抵御谷歌 A2A 的生态攻势？不久前，开源中国举行了一场以 “全网爆火的 MCP 到底是啥？” 为主题的直播，业内专家对这个问题进行了讨论。
谷歌的入局让战局陡然升温。A2A 出现之后，MCP 自身的定位成为关键：它是想变成 A2A 体系下的附属品，还是说它也想升到和 A2A 平级的位置？
A2A 协议直指智能体（Agent）间的高阶协作场景。Bytebase 联合创始人兼 CEO 陈天舟认为，如果 MCP 想上升到 A2A 层面，胜算很小，因为必须这要有应用场景支撑。“MCP 背后的公司 Anthropic 主要做模型基础设施层，本身没有应用。但谷歌不一样，A2A 发布时候，就把应用层厂商都集中起来了，生态优势很大。” 根据公开信息，A2A 首批合作企业包括 Salesforce、SAP、ServiceNow、MongoDB、Intuit、Workday、德勤、埃森哲等全球顶级企业应用平台，覆盖金融、零售、医疗、供应链等多个领域。
陈天舟指出，现在 A2A 和 MCP 的关系，有点像当年云原生时代谷歌经历的 K8s 和 Docker 的关系。而 A2A 的野心，类似 Kubernetes 对 Docker 的替代路径 —— 先兼容 MCP，再通过上层生态完成 “包裹式替代”。“不过，谷歌应该吸取了当年对 Docker 反应太慢的教训，这次对 MCP 反应很快 —— 它用更接近应用层的抽象协议把 MCP 包裹起来了。现在这种情况下 MCP 如果不集中精力巩固地位，反而继续突围的话，下一步可能真的会被谷歌这个协议体系收编。”
智能体通信协议 ANP 作者常高伟认为，长远来看，如果未来所有工具都实现智能体化，那么 A2A 可能直接绕开 MCP 的交互场景，逐渐侵占 MCP 的份额。MCP 甚至有可能被彻底干掉。
Gitee 私有云产品总监林靖靖对 MCP 的未来持悲观态度。他认为，MCP 目前的作用是连接大模型和工具，但随着 A2A 协议的出现和工具智能化、Agent 化的发展，MCP 可能会被取代。“大模型的交互方式可能会变化，上下文处理可能不再集中在 MCP，未来 Agent 可能直接通过 "上下文封装 + 预处理" 与大模型交互，而无需经过 MCP 的 "任务标识触发" 机制。
这就导致 MCP 的战略困境面临两难选择：如果收缩战线专注大模型交互优化，很可能被 A2A 协议架空；如果冒险拓展 Agent 间交互场景，这需极高投入且成效存疑。“结果就是可能哪个方向都没吃透，最终被边缘化。” 林靖靖如此预测。
Gitee 公有云技术负责人罗雅新则看好 MCP 作为 “USB 式标准” 长期存在，因其解决了工具调用的标准化问题。他认为，MCP 和 A2A 是解决不同场景的方案：前者是基础连接标准，后者是生态交互协议，二者可以并存发展。“无论 Agent 如何进化，要减少幻觉就必须与现实世界交互，获取事实数据。通过 MCP 这种标准化协议实现数据调用，既便利又可复用，各个 Agent 都能采用统一方式接入。MCP 只要持续解决关键问题（比如传输效率这类基础能力提升），就有长期存在的价值，就像 USB 历经多代升级仍保持核心价值。当然未来可能出现更好的协议替代它，但设备互联的场景需求不会消失。这本质上不是生态构建，而是协议标准的建立。”
现在的问题是，虽然 MCP 已集成主流工具扩展能力，但存在明显局限。罗雅新解释，当使用超过 40-60 个 context 时，系统就开始崩溃，有些客户端甚至直接限制数量。这导致人为筛选 context 时面临困境：面对海量 MCP 接口，用户根本不知道哪些该喂给模型，而模型自身也缺乏主动发现和筛选能力。不过如果进化到 Agent 间交互，协议层 —— 比如谷歌发布的 A2A 协议，应该能解决这个问题。
“Agent 间交互，这才是真正的生态问题”。罗雅新认为，每个 Agent 都有特定业务场景和商业诉求，是否与其他 Agent 协作需要市场博弈。A2A 协议现阶段可能不是爆发时机，更像是提前布局。当单个 Agent 无法满足用户完整需求时，自然会产生交互需求，生态才会逐步成型。
也有人认为，MCP 面临的最大危机，可能不是 A2A ，而是 AI 不断发展，具备一定程度智能后，已经不需要任何协议。
“长远来看，MCP 这类协议终将消失。” 陈天舟认为，现阶段之所以需要 MCP，本质上是因为当前智能体的认知能力有限。“当 AI 发展到足够智能的阶段，除了原始数据资源本身，所有中间层的协议规范都会失去存在价值—— 足够强大的智能体完全可以自主理解数据。我们不再需要像绘制地图、编写说明书那样，通过数据加工来指导智能体获取信息。考虑到 AI 的发展速度，或许根本不需要三到五年，这类过渡性协议就会退出历史舞台。”
作为数据库从业者，Pigsty 作者冯若航注意到，微软 CEO Satya Nadella 在不久前的演讲中也提到类似趋势：未来应用范式可能是 Agent 直接对 Database 进行 CRUD 操作。如果智能体真能实现原生数据理解能力，中间协议层确实可能被绕过 —— 最终形态将是 Agent 与 Database 的直接对话。
字节跳动技术专家刘康认为，MCP 能否繁荣不取决于它自身的表现，而是取决于 Agent 范式本身能否成功。若三到五年后 Agent 未成主流，MCP 仍会是工具层的最优解。
“当前 MCP 受关注的根本原因，是整个行业注意力转移到了 Agent 范式 —— 前几年大家聚焦预训练模型，现在应用层开发者开始转向 Agent 架构。但关键在于，Agent 能否真正形成繁荣生态？这个命题本身仍然存疑。
“我们不得不思考：这个范式未来是否会被新范式取代？现阶段 MCP 协议的热度完全依赖于大家对 Agent 范式的预期。至于三五年后的发展，时间跨度其实非常微妙。如果用最乐观的 AI 发展视角来看，届时可能已经实现 AGI（通用人工智能）—— 如果真到那个阶段，MCP 是否存在根本无关紧要，就像今天我们不再关心 CPU 总线协议的具体实现。“
回到现阶段，高常伟认为，Agent 协议正确的技术路线确实是工具化 ——MCP 完全契合当前发展需求。下一步无论是 A2A 还是 ANP 协议，本质上都是为未来布局。目前智能体生态尚不成熟，通信协议都处于早期研究阶段。但正因如此，现在正是制定标准协议的关键窗口期。
“至于更远期的未来，当 AI 发展到高级阶段，人类设计的协议可能反而成为限制 —— 也许智能体自主协商的协议会更高效，就像牛津大学提出的自然语言协商协议。让每个 Agent 暴露自然语言接口，通过对话协商交互协议。这种动态协议机制正是 ANP 框架支持的演进方向，是未来的主流。”
在技术上，大家一致认为 MCP 应该做减法。
“我认为当前协议架构需要简化，特别是客户端采样这类冗余设计。” 常高伟解释，虽然理论上存在应用场景，但实际几乎没有客户端使用该功能，建议直接精简。另外服务端访问客户端文件的设计也值得商榷 —— 这种双向访问机制导致服务端与客户端耦合度过高，这是审阅协议时最突出的问题。理想状态应该是服务端与客户端保持松耦合关系。
陈天舟的观点可能更为激进：“。我认为应该全面移除所有与鉴权相关的功能，将其移交交基础设施层，专注核心通信逻辑因为我们本质是数据库系统开发者，应该回归数据库最核心的架构逻辑来看待这个问题。”
具体来说，MCP 当前的核心任务应该是明确定义关系型数据库的基础函数集，并基于这些关系函数构建类 SQL 的标准语法体系。但需要澄清的是，鉴权机制本就不属于 SQL 层的职责范畴，而是应该由数据库管理系统（DBMS）承担的基础设施功能。现阶段需要聚焦于关系型数据库最核心的组件。
“需要重点构建的是关系函数集与 SQL 语法体系这两大支柱，除此之外的附加功能都应该被精简。从当前架构评估，建议保留三个核心模块：现有的资源定义工具、查询解析器、执行引擎，同时必须完善路由功能，即可构建出符合数据库本质的最小化核心架构。
而在建生态这个方向上，要做加法，从解决 "工具发现难"" 开发者动力弱 ""分发渠道散" 这三大问题入手。
模型如何自主发现执行任务所需的 context？当前已经出现的 MCP 工具市场（marketplace）或许能提供解决方案。但接下来的问题是，这些资源应该直接开放给模型调用，还是需要人工筛选？罗雅新观点是：最终应该建立 Agent 可直接调用的注册中心（registry），让智能体能自主发现所需的 context 资源或 MCP 服务节点。这才是作为终端用户真正需要的技术实现路径。
刘康认为，从生态发展角度观察，MCP 协议落地的关键在于降低接入门槛。作为开发者，最期待的是更完善的开发工具链 —— 当前协议设计明显偏向模型所有者（Model Owner），资源提供方（Tool Developer）的接入收益相对滞后。虽然长期看双方都能获益，但以模型为中心的架构天然会导致资源侧动力不足。
因此，要推动 MCP 社区繁荣，必须解决工具开发者的核心痛点：提供极简转换工具，比如将现有 REST API 一键迁移为 MCP 接口的自动化方案。只有让资源拥有者以最小成本接入协议，才能真正激发生态活力。这本质上是在模型中心和技术普惠之间寻找平衡点，而开发体验的优化正是破局关键。
林靖靖指出，从当前 MCP 的分发机制来看，最关键的缺失是统一的 "应用商店" 角色。目前各家 MCP 工具 / 客户端都在构建自己的 marketplace。“开发者开发完 MCP 客户端后，不得不面对多平台分发的困境 —— 需要同时在十几个渠道部署维护，这种碎片化状态严重制约生态发展。应该要有一个聚合平台。至于该平台由谁来主导，不论是云服务商、还是模型厂商，亦或是代码托管平台都有机会尝试。现阶段正处于格局未定的窗口期。不过，最终可能通过市场竞争自然筛选出用户信任度最高的平台。”
所有协议都是时代的产物。这场关于 MCP 的争论，或许正是 AI 技术从 “工具时代” 迈向 “智能体时代” 的序章。短期来看，MCP 需警惕谷歌的 “生态降维打击”，在工具层构筑技术壁垒；长期来看，协议的价值终将取决于能否顺应 Agent 范式的进化 —— 是成为智能世界的 “基础设施”，还是沦为过渡期的 “临时脚手架”。
来源：opendotnet