技术圈每隔几个月就会上演一轮“XX已死”的戏码这次的主角轮到了MCPModel Context Protocol模型上下文协议。起因并不陌生越来越多的Agent开发者开始抱怨MCP server的调试链路太长——工具逻辑就几步非要包一层JSON-RPC与其维护这些“薄封装”不如直接在代码里调原生函数。再加上有人在社交平台上略带情绪地喊出“删掉薄封装”一股“Agent连接架构要推倒重来”的讨论迅速蔓延连带着A2A、原生函数调用、纯HTTP API这些方案都被重新摆上台面。作为一个从function calling时代一路做到现在的开发者我理解这种情绪但并不认同“MCP是薄封装”这个判断。这一轮争议里真正的关键词不是“薄”而是Agent连接架构到底该怎么选。这篇文章我会拆一下MCP被集火的真实原因、它真正的价值所在以及在做架构重选时哪些因素才真正影响你的技术决策。1. “删掉薄封装”的呼声到底是从哪里冒出来的1.1 开发者口中“薄封装”的三宗罪为什么这么多人觉得MCP是“薄封装”我总结下来大家真正不满的点集中在三个地方。第一是协议层“看起来没干活”。MCP本身基于JSON-RPC 2.0定义了一组方法initialize做握手tools/list列工具tools/call调用工具。对一个内部工具来说这确实只是把原本的一次HTTP调用或本地函数调用改成了另一套消息格式。如果工具本身就3个函数、2个参数MCP这层封装的边际价值确实小得可怜。很多人的第一反应是这不就是我给HTTP接口加了一个壳吗是的单看一次调用它确实就是这个壳。第二是调试链路变长。以前直接在Agent代码里调函数报错就是Python/TypeScript的堆栈IDE里单步就能跟进去。换成MCP之后一条调用要穿过Agent框架、MCP client SDK、传输层stdio或HTTP、MCP server进程最后才到你的工具逻辑。任何一个环节出问题日志相互不统一排查起来非常痛苦。我在自己的项目里就遇到过stdio传输模式下server进程直接退出client端只报一句“connection closed”没有任何上下文查了好久发现是某个依赖在初始化时崩溃了。第三是生态质量参差。MCP火起来之后大量“hello world”级别的server涌现工具列表倒是写得很全但错误处理、超时重试、流式输出、鉴权基本没有。接入这样的serverAgent在一个场景下跑得通换一个场景就莫名其妙失效。这种体验积累下来很容易让人得出“还是别用MCP了”的结论。1.2 一个经常被混淆的点MCP是软件协议重点在互操作讨论过程中我发现很多人其实混淆了一个基础问题——MCP是软件协议还是硬件协议还有人问“MCP 是软件协议、硬件协议那个概念叫什么来着”。这个问题的答案很简单MCP是应用层软件协议和硬件总线协议是两个完全不同的概念。MCP做的不是“传输”它定义的是两个软件组件之间如何进行发现、协商与调用类似于LSP语言服务器协议在编辑器与语言工具之间做的事情。类比一下硬件协议好比USB接口规定了针脚和电平软件协议更像两个系统之间约定的报文格式和交互流程USB接口解决的是“物理上怎么插得上”MCP解决的是“逻辑上怎么对得上话”。这个区别特别重要。它意味着MCP追求的目标是互操作性同一个工具描述一次所有支持MCP的Client都能用而不是某个单一传输通道。如果你只看单次调用的链路MCP确实是“薄”的但如果你看的是跨系统、跨框架的连接它提供的是一个共同语言。协议的价值从来不在单次调用的复杂度而在覆盖面的广度。1.3 为什么现在才吵起来从“拥塞”到“疲劳”还有一个时间线上的背景。MCP最早在2024年11月由Anthropic开源2024年12月发布1.0版本随后迅速成为Agent工具接入的事实标准。短短一年之内各个框架、IDE、Agent平台都在拥抱它。事情一旦成为热门就会进入反噬期期待过高的用户开始回来找毛病质疑的声音自然集中爆发。加上OpenAI系的Codex等产品对MCP支持并不算积极有些用户甚至遇到“codex无法找到mcp”“无法发送消息显示更新agent沙盒”这类问题进一步放大了负面体验。简单说现在的争议不完全来自“协议不好用”还来自“协议在快速普及过程中暴露了大量工程质量问题”。这两件事不能划等号。2. MCP的价值不在“薄”在于它把连接变成了一条标准轨道2.1 回看function calling时代每个Agent都在重复写“工具适配层”在MCP出现之前Agent接工具是怎么做的以2023年OpenAI推出function calling之后那段时期为例。每个Agent框架都要自己定义一套工具接入方式。开发者想让自家工具被Agent调用得给OpenAI写一套JSON Schema塞进system prompt想支持LangChain又得继承它的Tool基类重写run方法想给AutoGPT或自研Agent用又得再写一遍工具封装。工具一旦多起来每次请求还要把所有工具定义全量塞进上下文token开销大Agent也容易在选择工具时犯迷糊。这个问题本质上是工具方和Agent方之间缺少一个稳定的“中间协议”。大家各自在两端造适配器适配器又只在自己的框架里成立。每次出一个新Agent框架之前的工作就折一次。我相信不少人都经历过这种“为三个框架适配同一把螺丝刀”的无聊劳动。2.2 MCP标准化的六个关键能力MCP做的事情是把这段“各自适配”变成了“统一接入”。它定位在AgentClient和工具Server之间定义了几个关键接口initialize协商协议版本、能力声明。tools/list工具发现Client启动时获取可用工具清单和参数Schema。tools/call工具调用带参数、可流式返回。resources/list与resources/read读取文件、数据库表、URL等资源。prompts/list获取可复用的提示词模板。认证与采样OAuth 2.1、LLM sampling处理鉴权和“让工具调用另一个模型”的场景。以tools/call为例一次MCP调用本质上就是这样一个JSON-RPC消息{ jsonrpc: 2.0, id: 1, method: tools/call, params: { name: query_stock, arguments: { symbol: 600519 } } }这些接口单独拿出来都平平无奇但组合在一起就形成了一套完整的最小互联模型。工具方只需要实现一次之后无论Claude Desktop、Cursor、自研Agent还是IDE插件只要对方支持MCP协议就能直接接入。这一点是MCP真正的护城河也是“生态大于单点性能”的典型案例。你可以把它想象成充电器标准一个充电头虽然比“直接用导线接电池”多了一层但这层让所有设备都能共用同一个头。2.3 生态端的选择已经回答了“该不该用”看看过去一年里围绕MCP长出来的实际应用就能理解为什么“薄封装”批评没有动摇社区Playwright MCP和Browser Use MCP这类浏览器自动化工具虽然定位相近但都选择保留MCP接入方式。原因很简单浏览器操作能力要被不止一个Agent产品复用。社区里也经常有人问“browser use mcp跟playwright mcp有什么区别”但没人质疑它们为什么都走MCP。同花顺MCP、量化领域的各类数据MCP把行情、数据查询能力标准化接入Agent避免每个Agent单独对接一遍。游戏内存分析领域有Cheat Engine桥接MCP的教程Unity有Unity MCP安全测试场景有Trae IDE搭载Burp Suite MCP Server这类玩法。还有IDE生态通义灵码通过MCP连接Oracle数据库蓝湖通过MCP接入CodexCursor内核直接支持MCP。更典型的是一些开源项目比如ruoyi-vue-pro这种企业级后台框架也开始把MCP功能直接合并进标准模块。这说明MCP已经不是“某个AI公司的私有协议”而是成了通用基础设施层。这些例子的共同特征是什么都是“一个工具能力被多种客户端消费”。只要这个特征存在直接写业务函数、直接暴露REST API都无法替代MCP提供的通用接入层。删掉薄封装容易删完之后你得为每个客户端重新写一遍薄封装。3. Agent连接架构重选四个真实方向各有各的适用位置“重选”不是非此即彼的站队问题。我把目前讨论里真正有价值的几个方向梳理一下每个方向都对应一类场景选错了才是问题。3.1 方向A同进程函数调用最彻底的“删薄封装”如果你只有一个Agent代码库、工具就是项目里的几个函数、没有其他客户端会复用那同进程函数调用确实是正确答案。新一代Agent框架基本都有工具装饰器一个函数标注一下agent就能自动发现、生成参数Schema、做类型校验。比如tool def query_stock(symbol: str) - dict: 查询股票行情 ...这个过程无需网络请求、没有进程开销、调试就是IDE里的堆栈回溯。我写日常自动化脚本时就经常这么做——几十行代码定义两个函数框架一注册就行。这种情况下硬上MCP等于给自己制造维护负担要管理server生命周期、要处理传输层、要写一套无关业务的状态管理。这是“为了标准而标准”没必要。3.2 方向BHTTP API 各框架自带Tool Use不加中间协议很多工具方现在的形态是服务已经提供了REST/HTTP API客户端则各自用OpenAI function calling或Anthropic tool use做适配。这种方案优点很明显没有额外一层协议API本身可复用调试可以直接用curl看结果。缺点同样明显工具schema、认证方式、分页结构等细节每个客户端框架都要单独适配一次。所以这个方向更适合“只有一两个固定客户端”的场景。比如你的Agent只跑在自研后端里前端固定调用同一个服务那完全不需要引入MCP。它和MCP方案的区别我列成一个表格更直观维度直接HTTP API function callingMCP接入标准化程度客户端各写各的适配统一协议一次接入多客户端复用每新增一个框架都要重写已有生态直接复用调试便利性curl直接测链路短链路长需查多层日志Schema维护分散在各客户端代码里集中在server统一维护协议演进负担依赖框架自带Tool Use演进依赖MCP规范与客户端支持这个表基本就是“选型时的天平”左边赢在简单右边赢在通用。没有绝对优劣只有匹配不匹配。3.3 方向CA2AAgent-to-Agent和MCP不在同一个层次“Agent连接架构重选”讨论里另一个常被提到的名字是A2A协议。Google在2025年主导推动。很多人把A2A和MCP对立起来这是一个误区。MCP解决的是“Agent到工具”工具是被调用的资源Agent是调用方。A2A解决的是“Agent到Agent”两个能力对等的Agent进行任务委托、结果回传和状态协商。它们处于不同的抽象层次可以共存。一套完整的Agent架构里很可能是上层用A2A做多Agent编排下层用MCP让各个Agent去碰具体工具。这和“harness和agent区别”是同一类分层问题——执行环境和决策主体要分开看连接协议同样要分层次看。你会因为有了高速公路就不修连接服务区的匝道吗不会。A2A和MCP就是这样的关系。3.4 方向D保留MCP但换成网关与分层模型在实际落地中保留MCP但改变使用方式往往比彻底删除更有效。我现在见过几类演化模式聚合式网关一个MCP Server同时暴露多个内部服务通过名称空间或路由前缀区分。对外是一个server对内聚合了十几个工具。标准分层边缘层负责认证、限流、日志协议层继续用MCP业务层无感。混合接入高延迟低频场景用MCP低延迟高频场景直接用函数调用。Agent框架中通过路由规则决定走哪条链路。这种“MCP当现成的JSON-RPC网关用”的做法本质上是把MCP从“工具接入协议”升级成了“工具编排基础设施”。我了解的不少自研Agent平台包括Hermes Agent这类桌面端工具都采用了这种分层思路接口层保持MCP兼容底层统一走自己的服务调度。这样既照顾了生态又不被协议绑死。4. 实战选型什么时候我用MCP什么时候我劝你别用4.1 先问三个灵魂问题选型不要看风向要看自己的连接图。我给团队内部做方案评审时通常会让大家先回答三个问题这个工具会被多少个客户端消费只被一个Agent消费优先函数调用或直接API会被多个Agent、IDE、自动化脚本消费优先MCP。工具方对协议演进敏感吗工具经常要改参数、加功能MCP的tools/list动态发现能力可以省去客户端代码更新。你能承受调试MCP栈的维护成本吗没有专职工程兜底MCP server出了故障会阻塞业务。这三个问题的答案组合起来基本决定你选左边还是右边。我把四个方向总结进一张选型矩阵表场景特征推荐方案理由单一代码库、内部函数、无复用诉求同进程函数调用延迟最低调试最直接工具已有稳定REST API、客户端固定HTTP API function calling少一层协议维护成本低需要跨Agent、跨IDE、跨框架复用MCP一次接入生态复用多Agent协作、任务委托A2A可叠加MCP解决Agent间互操作工具众多、团队规范要求统一入口MCP网关/分层认证、限流、治理集中化4.2 我经历的一次正向转化函数调用改成MCP后收益其实很大这里讲一段个人经历。之前做一个面向咨询团队的数据问答Agent最开始所有工具都是Python函数直接注册一切顺利。后来团队新来的分析师用起了其他Agent工具问能不能接入同一批数据查询能力。我当时的第一个想法是“给那个工具写一个适配器就行”结果发现它需要的适配方式和我现在的框架完全不同——数据结构要重排、schema要重写、错误信息格式也不同。工作量不大但很烦。后来我把这批数据查询能力整理成一个MCP server提供统一schema和错误约定。之后再接入新框架只需要配置URL和token半小时内就能跑通。这个项目是我对MCP态度转变的直接原因单次调用的成本确实多了几毫秒但“接下一个客户端”的成本从几天变成半小时。这也解释了为什么“ai agent怎么扛并发”这类问题会在MCP场景里反复出现——server侧性能和稳定性才是MCP好用与否的关键变量。4.3 另一段反向教训为标准化强行MCP换来一地鸡毛反过来我也踩过坑。有个内部监控脚本只有我自己在使用工具逻辑就三四个函数。为了“统一架构”我硬写了一个MCP server还在里面加入了resources、prompts这些其实用不到的能力。结果两周后脚本逻辑要求变动我得先改server、再改client一次简单变更变成了两处操作。最后我果断删掉MCP恢复直接函数调用事情一下子清爽了。这段经历之后的结论是MCP不是“更好”或“更差”它只是“更通用”。通用性只有在你需要跨接的时候才有价值否则它就是一个徒增复杂度的中间人。删掉薄封装这件事本身没有错错的是把“删掉”当成一种政治正确而不是一种基于场景的工程决策。5. MCP会不会退出历史舞台我的判断比“凉了”复杂一些5.1 协议的历史经验没被淘汰的只是被放进了合适的位置回看计算机协议史很少有一种协议被完全淘汰。SOAP没有消亡只是从主流Web服务场景退回到企业级集成场景CORBA在今天仍然活跃在部分通信和国防系统中。REST很流行但gRPC、GraphQL也在各自的生态位活得很好。协议的结局通常不是“死亡”而是“降级”——从“被所有人谈论”变成“在合适的场景里被合适的人使用”。MCP现在处于每轮技术浪潮都会经历的阶段炒作峰值已过、质疑开始涌现、真实价值被工程问题掩盖。把它和“退出历史舞台”放在一起说早了。真正值得关注的不是它会不会死而是它会在哪一层活下来。5.2 未来几个绕不开的演进点协议版本演进MCP 1.x时代还带着早期设计的影子未来大概率会对resources、prompts、sampling这些低频功能做简化让协议更专注“工具发现和调用”。网关与代理成熟一批MCP Gateway、Proxy产品正在把server质量参差的问题收敛到基础架构层。到那时候你接入MCP的体验可能会接近“请求打到API网关”的稳定度。与A2A形成分层普及Agent-to-Tool用MCPAgent-to-Agent用A2A这个分层会越来越清晰。大厂态度会决定速度OpenAI、Google、Anthropic对MCP的支持程度会影响它在不同生态里的渗透率。但协议的生命力从来不是单一大厂决定的社区实践往往更持久。5.3 给正在做架构选型的人几条实操建议基于我自己的开发经验给几个可落地的建议先画清楚连接图再谈协议。你的Agent会连接到哪些工具哪些工具会被多个Agent复用这张图决定你是用MCP还是直接函数调用。别让“趋势”替你回答这个问题。学协议思想比背协议接口重要。MCP的核心思想是“连接标准化、复用最大化”这套思想在A2A和未来任何连接协议中都会复用。就算哪天MCP真的被替代你掌握的这个思想也不会过期。预留替换空间。MCP client端做一个薄适配层server端保证工具逻辑不依赖MCP数据结构这样将来无论MCP怎么演变你都能平滑切换。最后别被“薄封装”这种标签带着走。标签只能定义已有事物不能定义你面对的场景。我现在的习惯是先把工具逻辑写清楚再问一遍自己谁会复用这个工具如果答案只有自己的代码就不碰MCP如果答案里有多方接入的可能就认真搭MCP server。这个判断做完所谓的“退不退出历史舞台”其实已经不影响你的日常开发了。