MCP 最近这波“退出历史舞台”的论调来得比我想象中猛。年初还在说“万物皆可 MCP”现在风向一转各路 Agent 框架开始高调宣称“删掉薄封装”“回归原生工具调用”标题里“重选连接架构”几个字更是戳中了整个行业对 MCP 的集体焦虑。先说结论MCP 没有死它只是从“信仰”变成了“选项”。这半年我大概接了十几个 Agent 项目的连接层重构从最早全员拥抱 MCP 到后来一部分团队悄悄拆掉 MCP过程中的踩坑和思考都挺典型的。这篇就围绕“为什么 MCP 会被质疑”、“薄封装到底删了什么”、“Agent 连接架构到底该怎么选”这条线把今年看到的技术变化拆一拆给还在观望的团队一些可落地的参考。1. “删掉薄封装”背后MCP 的信任危机是怎么来的1.1 从“救世主”到“过度设计”的半年转折先回到 2024 年底到 2025 年初的场景。当时 MCPModel Context Protocol几乎是 LLM 应用圈的顶流话题各家 SDK 争先恐后地内置 MCP 客户端支持服务端框架像雨后春笋一样冒出来。做什么都提 MCP好像不用你就落后了。转折点出现在 2025 年春季那波 Anthropic Agent SDK 的更新。公告里直接把话挑明了大概意思是Agent SDK 里不再把 MCP 当作一等公民转向优先支持原生工具调用。理由是 MCP 这种“通用标准”对单 Agent 场景来说过度抽象带宽和序列化开销、协议适配成本、调试复杂度都成了实际拖后腿的东西。这条消息叠加社区里陆续出现的一些讨论——比如“把 MCP 从项目里删掉之后延迟降了 60%”“本来就不需要薄封装直接函数调用就行”——于是“MCP 要凉”的呼声就起来了。但我说句实话那类“删除后性能暴增”的帖子很多犯了同一个错误把不该归因给协议的延迟归因给了协议。举个例子有个团队找我排查 Agent 响应慢的问题一查发现他们在 MCP server 外面又包了一层 HTTP 网关模型一次 tool call 要多走两台机器。这就好比外卖慢不怪骑手不怪路况怪外卖平台用的接单协议有问题。真正需要反思的是架构分层是不是太厚了而不是协议本身该不该死。1.2 薄封装的本质是“约定”被异化成“中间层”了“薄封装”三个字在标题里反复出现我对这个词的理解要从两个层面看。第一层是 Claude 官方的原意。它们提出 Agent 应该少一点复杂抽象直接调用模型能力的核心函数、用少量工具定义完成编排不要为了“架构漂亮”去堆一堆无意义的分层封装。这是非常务实的工程取向尤其是单 Agent 场景少一层封装就少一层故障点、少一层调试黑盒。第二层才是被社区放大甚至异化的“删掉薄封装”。很多团队把 MCP 直接等同于那层“多余的薄封装”总觉得去掉之后 Agent 就轻装了。但 MCP 的本职工作是“服务解耦的标准化协议”不是“性能优化组件”。它的薄是相对业务逻辑而言的不是相对裸函数而言的。在不同场景下它可能恰好是帮助你快速接上异构工具的那一层最小协议胶水也可能是确实让你多跑一遍序列化、多写一堆适配代码的纯负担。评判标准还是看你的 Agent 形态和连接目标。所以真正要问的问题不是“MCP 要不要退出”而是“你的场景里那一层薄封装到底解决了什么问题还是反过来创造了问题”。2. Agent 连接架构的核心拆解为什么选型不能只盯 MCP2.1 Agent 连接的本质把“能说”变成“能干活”先把概念捋清楚不然大家都被热词带着跑。Agent 项目的核心从来不是模型本身有多聪明而是模型能不能严谨、可控地调用外部能力查数据库、写文件、调 API、控制浏览器、操作代码仓库。这一整套“模型如何触达工具”的链路就是我们说的 Agent 连接架构。当前主流的连接架构就四类各有各的适用范围原生工具调用Function Calling直接把工具以 JSON Schema 形式塞给模型模型在回复里输出参数代码侧执行后把结果回填。OpenAI、DeepSeek、Kimi 这些走这条路的最多。MCP 协议对接模型侧通过 MCP 客户端按协议发现工具、调用工具服务端可以是本地进程、远程服务或云端 API统一封装。语义化工具层RAG 风格工具发现面向超大规模工具集合先用向量检索召回最相关的工具描述再交给模型做精确调用。Agent 编排框架自带抽象LangChain、Spring AI、Dify、Coze 这类框架各自封装了工具注册、调用、记忆、编排逻辑对开发者隐藏很多细节。所以你会发现把选择收缩成“用 MCP 还是不用 MCP”本身就是伪命题。除非你的工具集只有三五个否则你最终都会落到某种架构组合上MCP 只是其中一条连接路径。2.2 MCP 解决了什么一套协议解决“工具接口标准化”难题有段时间我用 MCP 用得特别上头因为生活中几类问题它确实解决得很漂亮。第一个是工具接口碎片化问题。不用 MCP 的时候每接一个工具要单独写一套 JSON Schema 请求参数组装 鉴权逻辑 错误映射。接了 MCP 之后server 统一暴露工具描述和调用入口客户端按协议做发现和调用两边约定的复杂度从“点对点协商”变成“服务器和客户端都遵守同一份协议”。第二个是服务能力去模型化。MCP server 是对任何模型通用的只要这套模型能理解 JSON 工具定义它就能通过同一套 MCP server 去操作同一类资源。项目里我常把数据查询、DevOps 操作这类通用能力做成 MCP server任何项目来对接都是同一套配置不用为每个项目重写一遍工具适配层。第三个是安全边界统一管控。MCP 的权限提示、能力声明、作用域隔离逻辑统一放在协议层比在业务代码里到处塞一坨一坨的校验逻辑清晰得多。像最近社区里讨论很热的 Agent 安全议题MCP 至少给了你一个集中做服务器白名单、工具调用审计的抓手而不是把安全规则散落在十几个工具的各自实现里。但换来的是什么协议开销、调试成本、多一层抽象这就直接对应了开头的争议。所以 MCP 不是不好是它只适合出现在“跨团队、跨语言、跨系统的标准接口”那一层你把它当作万能胶水到处贴那它反过来就会成为性能黑洞和复杂度旋涡。2.3 “删掉薄封装”的真实收益哪些架构简化是合理的既然很多人提到“删掉薄封装”那我们来盘点一下哪些删法在工程上是站得住的。首先剔除那些“为了 MCP 而 MCP”的中间层。我见过有团队把自己内部的一个 Python 函数包成 MCP server然后又用另一套框架引入 MCP 客户端来调它同一台机器上绕了一个大圈纯序列化开销肉眼可见地拖慢了首 token 时间。这种场景直接原生函数调用就行了。所谓薄封装说的是工具调用本身要轻不是说任何工具都必须拆成服务。其次用 MCP 只负责“对外能力接入”对内一律用原生调用。这是比较健康的架构分层思路。对外接了外部系统、平台工具MCP 做协议标准化对内那些内部函数、内部服务直接函数调用或本地 RPC不额外套协议。这样既保留了 MCP 的优势又不让它成为每一条调用链路上的必需路径。第三能走流式的走流式能少序列化的少序列化。MCP 在文本工具、内容生成、文件处理这类场景下有天然的流式输出优势。实测下来MCP 流式输出和原生 SSE 直出的差距主要来自协议消息格式变换而不是传输管道本身优化空间更多在“跳过不必要的 JSON 重编码”而不是“删掉 MCP”。3. 实操复盘我从“全员 MCP”到“按需 MCP”的连接层改造全记录3.1 背景与选型逻辑什么项目值得用 MCP什么项目不值得我自己手上这套 Agent 平台最早是全 MCP 架构当时理由是工具集横跨数据库查询、内部文档检索、外部 API 调用、前端截图验证、代码仓库操作五个大域而且以后还要持续扩展确实适合统一协议。但跑了两个月就发现了问题。一是内部几个高频工具的调用耗时里MCP 层的协议耗时占比接近 20%虽不算灾难但长期跑在关键链路上很膈应。二是随着工具越来越多MCP server 的管理成本和客户端侧工具发现逻辑的复杂度明显上升团队新同学快速上手变得困难。当时做了一次架构选型复盘核心判断标准列了三项判断维度走 MCP 的条件走原生/直连的条件工具规模工具数 20或跨团队共同维护工具数 10且高度内聚调用频率低频外部集成、生态对接高频内部调用、性能敏感链路异构程度多语言、多系统、多方维护单一语言栈、单一代码仓库按这个标准把现有工具重新划了一遍结果很清晰内部检索类、数据库查询类保留 MCP server 形式因为要对接多个上层 Agent前端操作和代码仓库这类高频内部能力直接下沉为原生工具调用。改造完成后高频链路的工具调用耗时直接降了约三分之一而多 Agent 复用能力时依然保持协议一致性没有出现东一块西一块的适配散乱。3.2 改造步骤怎么平稳地从“全 MCP”切换到“混合连接”这个改造做下来有几个步骤值得分享出来给同样在折腾的团队参考。第一步是画调用频次热力表和延迟拆分。先按 Agent 实际运行日志统计每个工具被调用的次数再分层拆耗时网络传输多少、MCP 协议解析多少、业务执行多少、结果返回多少。这一步能帮你看清楚那些抱怨“MCP 慢”的问题里真正的瓶颈是不是协议层。第二步是盘点工具跨系统复用情况。内部工具如果只有一个 Agent 用、调用又密那么原生工具调用就是最佳选择。内部工具如果被多个 Agent 用、甚至以后要开放给外部团队那还是统一 MCP server 更有价值。我当时把数据库查询、内部搜索这类通用服务保留在 MCP 上因为它们同时被 Session Agent、数据分析 Agent、运维 Agent 三边调用只要做一次协议适配三边都受益。第三步是原生工具接入要补齐的配套能力。直接把函数暴露给模型听起来简单但缺了权限控制、参数校验、上下文记录就容易出事故。我在原生工具层加了一份极简的函数级中间件负责统一 Schema 生成、调用审计、异常归一化。它不再是一个协议标准而是每个工具函数自己带上元数据描述模型侧按描述直接驱动。第四步才是真正“删掉薄封装”。把高频路径上的 MCP 调用替换为原生函数分发同时保留 MCP 客户端作为横向能力接入的组件。代码层面我用了一个适配器模式所有工具都统一实现一个 Tool 接口底层可能是 MCP 调用也可能是原生函数调用上层 Agent 无感知。这样既解决了性能问题也保住了扩展性。3.3 “拆”和“留”的判断标准给那些正在纠结的团队很多团队卡在“到底要不要拆”这个问题上我给一个比较直接的判断框架。先问三个问题这个工具同时被几个 Agent 或团队使用这个工具调用是否处于用户感知的响应关键路径上你对这个工具的调用频次和延迟要求是不是远高于一般工具如果三个回答分别是“多个”“是”“高”那这个工具放在 MCP 上会很拧巴。它需要高频高性能但作为共享能力它又不得不走协议层。这种矛盾我通常会建议在协议之外加一条“本地直连短路”同一个进程内或同一台机器上用函数直接调用不经过网络和协议层。协议保留只是为了暴露给外部和跨语言侧使用。如果回答是“单个”“是”“高”那想都不用想直接原生工具调用不要试图用协议解决性能问题。如果回答是“多个”“否”“不必苛刻”那 MCP 就很适合它帮你省了对接成本还统一了管理。这套标准落实到代码层之后架构从“全 MCP”变成了“MCP 只做连接高速公路”内部高频使用原生函数直连作为快车道整体连接架构反而比之前更清晰。直白点说删掉薄封装的精髓不是“不用协议”而是“让每一层协议只服务于它该服务的场景”。3.4 当代 Agent 框架怎么处理连接层几个主流方案对比再聊聊框架视角。我实际用过几套不同的 Agent 方案它们的连接层思路正好代表了这波架构重选的几个方向。Anthropic Agent SDK带头“弱化 MCP”。原生工具调用是第一入口MCP 是可选组件。它的核心观点是大多数 Agent 场景下模型直接定义工具、代码直接执行比走一层标准协议更爽利。这里特别值得注意的是它所说的“deprecating MCP support”实际指的是 Agent SDK 不再像早期版本那样把 MCP 当作核心架构而并不是 MCP 协议本身停止发展。LangChain / LangGraph框架层级抽象较重MCP 被当作连接器选项之一但官方文档现在更强调“定义工具函数 动态路由”而不是强迫走 MCP。换句话说框架本身对协议无偏好谁顺用谁。Spring AIJava 系 Agent 项目的另一大选择。Spring AI 里同时支持 MCP 和原生函数回调社区也相应出现了 RuoYi-Vue-Pro 这类前后端快速开发框架合并 MCP 功能的案例。对它来说MCP 更多是作为“外部功能接入插件”的存在而不是每个方法都要走统一协议。自研轻量 Agent 框架很多团队在 LangChain 之外自建一套极简 Agent 框架主要就是“模型推理 工具注册 调用循环”。这类框架最容易做到“删掉薄封装”没有多余抽象工具就是函数模型想调哪个调哪个。选哪套方案没有标准答案关键看团队的工程底子和对“抽象”的容忍度。喜欢轻装简行、快速迭代的建议直接自研或原生工具团队大、工具多、要多个 Agent 共享能力那 MCP 作为标准件还是值得保留的。3.5 实操过程中容易踩的坑工具定义、记忆机制和并发这轮改造里被问得最多的问题集中在三个点上工具定义怎么写、Agent 记忆怎么管、并发怎么扛。一并放到这里说。工具定义最容易踩的坑是“描述写得太抽象”。模型是靠工具描述和参数说明决定调不调用它的所以描述写得含糊、参数名称怪异、示例缺失都会直接降低调用准确率。我的经验是每条工具描述至少包含三块这个工具做什么、什么场景下用、典型输入输出示例。写完之后拿两三个 query 实测一把看模型选工具选得准不准不准就迭代描述。这个环节比很多框架配置都管用。Agent 记忆机制是另一个大头。MCP 也好原生工具也好都只是连接层记忆是更上层的东西。我看过的很多项目失败在“没有记忆机制就敢上马 Agent”。记忆至少分三层短期上下文当前会话里模型能看到的信息、工作记忆跨多轮对话保留的任务状态、长期记忆跨会话的偏好、历史结论。简单做法是短期上下文直接塞进 message history工作记忆用状态文件或数据库持久化长期记忆靠定期摘要甚至用嵌入做向量检索召回。这块做得好不好直接决定 Agent 对话是“失忆儿童”还是“靠谱助理”。并发这块典型的问法就是“AI Agent 怎么扛并发”。首先要分清楚面向哪一侧并发模型调用侧并发、工具执行侧并发、还是用户请求侧并发。模型调用侧通常用异步任务队列把请求压给模型 API同时做请求合并或缓存工具执行侧靠连接池控制资源像数据库连接池、HTTP 连接池都要做好用户请求侧就是无状态服务加水平扩容。如果还想再进一步可以对工具调用按批处理优化即将多个小工具调用合并成一个大请求走并行执行而非串行实测在多数场景下能有效缩短整体完成时间。4. 常见问题与排查实录连接层出问题怎么快速定位4.1 典型故障场景MCP 连不上、工具超时、模型选错工具这几个问题几乎每个 Agent 项目都会遇到把我踩过的坑和排查思路整理一遍。MCP 连不上的典型表现是客户端报 timeout 或 connection refused。排查顺序一般是先 telnet 通不通服务端口再看 server 进程日志是否正常启动最后确认客户端配置里的 server name 与 server 端声明是否一致。项目里最容易忽略的就是 server name 不匹配因为 MCP 客户端配置项多经常有人复制粘贴没改名字导致找不到 server。工具调用超时通常不是工具本身慢而是资源被卡住。比如数据库连接池用完、HTTP 客户端连接复用失效、目标服务限流。我建议统一给每个工具调用加上超时和重试策略并对调用日志做耗时分桶统计。日志里如果发现 p99 明显高于 p50多半有慢请求堆积在某个依赖上优先排查这个依赖的并发限制。模型选错工具的常见根因是工具描述不够精准、重叠。我有一次搞了三个工具分别是“查询用户信息”“查询用户订单”“查询用户余额”结果模型经常把“查余额”调成“查订单”。后来把描述改得更具区分度比如“在用户咨询余额时使用注意余额不等于订单金额”准确率立刻上来了。4.2 从“MCP 报错”到“Agent 行为异常”的快速定位路线Agent 项目调试比传统接口调试难一个量级因为错误可能是模型理解错了、工具调用参数错了、外部服务崩了甚至只是上下文太长截断导致状态丢了。我的排查路线分三步走。第一步先看模型侧输出日志确认它真实发出的是哪个工具调用、参数是什么、意图是什么。很多“Agent 行为异常”在这一步就能定位不是代码 bug是模型理解偏了。第二步看工具侧执行日志确认调用是否被执行、执行结果状态、耗时长短。这步能定位“工具有没有出问题”以及问题是否在业务逻辑层。第三步回到 Agent 的上下文管理。看看是不是关键信息被截断、丢失或者历史记录被压缩后把必要状态弄丢了。这块最难查所以我在项目里会在上下文中注入一个“关键状态标记”每次生成总结时把重要的非结构化信息剥出来存到结构化字段里避免被模型“遗忘”。4.3 性能优化实录从 5 秒到 1 秒的几板斧分享一个真实优化案例。早期有个 Agent 工具调用链路整体耗时接近 5 秒用户根本等不起。排查之后发现四个主要问题一是 MCP server 每次调用都要重新初始化连接改成连接复用之后直接减少 1 秒多。二是工具返回结果太大模型上下文拼接了重复信息加了一层结果裁剪逻辑只保留关键字段最后模型处理都快了不少。三是多工具场景逐个串行调用改造为并行调用之后两三个工具的耗时叠加变成最大耗时。四是把模型从大模型换成了同系列更快的小模型只用于工具选择环节大幅降低了决策延迟。四板斧下去整体耗时从 5 秒压到 1 秒左右。这轮的体会是连接层的“慢”很少是协议本身的锅绝大多数瓶颈出现在资源复用、结果传输和上下文拼接这些细节里。先把这些问题清掉再谈要不要删协议不然很可能是把有用的标准化能力当成了替罪羊。5. 技术选型之外这波争论背后的行业思考5.1 为什么“技术方案”会变成“技术信仰”说实话MCP 从一开始就不止是技术协议它承载了很多人对“Agent 互联网”的想象。MCP 被寄予厚望能让所有 AI 应用无缝地连接所有服务这种“万物互联”愿景天然吸引人。可现实是标准协议只有在“没有一家独大、各家都愿意遵守规则”的生态里才最有价值。现在各家模型能力和 Agent 框架差异还很大靠一个协议框架包住所有人现阶段并不现实。所以我对 MCP 的判断是它作为互操作性标准还会有生命力但作为“贯穿所有 Agent 调用的唯一真相”的时代已经过去了。不是协议死了是过度神化的阶段过去了。5.2 技术演进里“删”有时候比“加”更健康回顾这几年 LLM 应用层的演化你会发现一个有意思的规律每隔半年到一年都会有一波“减去一层”的运动。LangChain 火的时候一堆人用它后来大家发现“没有魔法”反而退回去写更朴素的代码。现在类似的事情发生在 MCP 上。这个“加一层再减一层”的循环本质上是大家在通过实践校准抽象层的合理位置。工程世界里“引入”某种技术往往很容易因为新东西总是自带光环。但真正检验一个团队功力的是你有没有能力判断何时该“减”、何时该“留”。MCP 这波没有彻底退场但对一部分场景而言它确实退居二线了。这不是坏事它说明 Agent 工程本身在走向成熟我们已经在认真衡量每个抽象层“配得上”多少复杂度。说回到实操角度最后给读者和团队几个不落俗套的建议如果你们的 Agent 工具集还不到十个别引入 MCP直接原生函数调用把时间花在打磨工具描述和记忆机制上。如果你们有多个 Agent 要复用同一批能力或者想对接外部生态保留 MCP 作为标准件但一定要给高频调用做“本地直连短路”。删掉薄封装的时候记得删的不是和 MCP 有关的一切而是那些另有合理实现的重复抽象层。任何一次架构重选都要拿数据说话先分层拆耗时再决定要不要动协议层不要被热搜词带跑。我个人的体会是判断连接架构选得对不对最核心的指标就一个你的 Agent 是不是在最少的抽象层之下稳定地把事情完成了。MCP 也好原生工具也好都不过是抵达这个目标的路径。在真实业务里能跑通、能维护、能扩展的那条路就是最适合你们项目的那条路。