MCP （Model Context Protocol）作为连接大模型与外部工具的通信协议，近期因谷歌推出 A2A（Agent-to-Agent）协议引发争议。

MCP 凭借其简洁的设计和 OpenAI 等巨头的支持，迅速成为大模型与外部工具交互的事实标准。其核心价值在于解决了两个关键问题：一是标准化接口：将工具能力封装为统一的函数描述（如 API 格式、参数定义），降低模型调用复杂度；二是上下文管理：通过动态维护工具调用记录，辅助大模型生成连贯的操作链条。

这种“模型中心化”的设计思路，使其在开发者中广受欢迎。然而，随着谷歌推出 A2A协议，MCP 的“护城河”开始遭遇挑战。

MCP 能否抵御谷歌 A2A 的生态攻势？不久前，开源中国举行了一场以 “全网爆火的 MCP 到底是啥？” 为主题的直播，业内专家对这个问题进行了讨论。

谷歌的生态围剿：A2A 的“包裹战术”

谷歌的入局让战局陡然升温。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会消亡？

也有人认为，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应该做减法。

“我认为当前协议架构需要简化，特别是客户端采样这类冗余设计。”常高伟解释，虽然理论上存在应用场景，但实际几乎没有客户端使用该功能，建议直接精简。另外服务端访问客户端文件的设计也值得商榷——这种双向访问机制导致服务端与客户端耦合度过高，这是审阅协议时最突出的问题。理想状态应该是服务端与客户端保持松耦合关系。

陈天舟的观点可能更为激进：“。我认为应该全面移除所有与鉴权相关的功能，将其移交交基础设施层，专注核心通信逻辑因为我们本质是数据库系统开发者，应该回归数据库最核心的架构逻辑来看待这个问题。”

具体来说，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 范式的进化——是成为智能世界的“基础设施”，还是沦为过渡期的“临时脚手架”。

微信扫码，观看直播回放：

【数智漫谈】

OSCHINA 视频号直播畅聊栏目【数智漫谈】，每期一个技术话题，三五位专家围坐，各抒己见，畅聊开源。给大家带来最新的行业前沿、最热门的技术话题、最有趣的开源项目、最犀利的思想交锋。如果你手上也有新点子、好项目，想要跟同行交流分享，欢迎联系我们，讲坛随时开放～