MCP要退出历史舞台这个说法，最近在中文技术圈里确实引发了不少讨论。尤其是当有人提出“薄封装”、“删掉”这类概念时，很多刚接触Agent开发的读者会产生困惑：费了半天功夫配置的MCP，说不做就不做了？其实业内讨论的核心并不是“MCP死了”，而是“Agent连接架构正在重选”这件事。我更愿意把这轮讨论理解为一次架构选型的回归：什么场景真的需要一套标准协议，什么场景只是借了协议的名字在套用传统API调用。如果你正在做Agent开发、接入工具、设计连接方案，这轮争议值得认真了解一遍。

1. 先理清MCP具体解决什么问题

1.1 模型与工具之间的原生连接痛点

要理解“薄封装”之争，必须先回到MCP协议设计的最初动机。2024年下半年我记得很清楚，那阵子做Agent接入工具，大家大概率会走上同一条路：把某个内部API包装成一个大模型的“工具函数”，手动编写JSON Schema描述参数，把调用结果再拼回对话上下文里。单个工具还好办，一旦上了五六个工具，每个工具都有不同的鉴权方式、不同的返回结构、不同的错误码，那SDK里的工具注册代码会迅速膨胀成一块难以维护的“胶水层”。

MCP做的事情，拆开看其实就四五条：

• 它用JSON-RPC 2.0定义了客户端和服务端之间的通信规范；
• 它统一了“工具”、“资源”、“提示词模板”三类原语的暴露方式；
• 它规范了初始化握手、能力协商、请求生命周期维护；
• 它定义了stdio、SSE、Streamable HTTP等传输方式，允许本地进程和远端服务以同样方式接入；
• 它把“AI应用”和“工具提供方”解耦——工具方只要实现一套MCP Server，任何兼容MCP的Host都能直接调用，不用重复定制集成代码。

这份设计的价值在于标准化，而不是功能本身。拿生活里的例子打比方，USB-C接口干的也是同一件事：它没有让充电速度变快，但它让手机、笔记本、显示器、充电头之间的连接变得通用。MCP在Agent领域想当的，就是这个“连接标准”的角色。

1.2 MCP被“神话化”的根源

但从2024年底到2025年上半年，MCP的热度明显被市场推高了一个层级。很多团队开始把“接入MCP”本身当成一种架构正确性来宣传，仿佛不引入MCP就意味着Agent能力不完整。一些项目甚至出现了一个工具就单独起一个MCP Server进程，容器里堆着十几个轻量服务的场景。这种做法，本质上是把“标准协议”误用成了“服务拆分框架”。

这种过度使用，正是“删掉薄封装”讨论的现实背景。说句公道话，不是说MCP这个薄封装没有价值，而是当整个Agent只连接两三个内部服务时，绕一层协议引入的子进程管理、生命周期协商、传输层维护，确实可能比直接调用API还重。当一个方案的工具成本高于收益时，架构师产生“重选”的念头是正常的。

2. “薄封装”之辩：这个协议本质上是薄的

2.1 为什么被叫作“薄封装”

有朋友把MCP形容为“薄封装”，从协议层看，这个形容不算贬义。MCP本身不是一个业务逻辑平台，它不替你做鉴权、不帮你存数据、不负责服务发现，它只是给“模型调用工具”这一动作提供了一套相对统一的传输和外层表达方式。工具的具体实现仍然在Server端，大模型的能力仍然在模型端，MCP本身不产生智能。

正因为薄，它才能做到跨平台、跨模型适用。也正因为薄，它才容易被贴上“可替换”的标签。做工程的朋友都知道，越是标准化层，越容易被新的标准或者更底层的原生能力替代。换句话说，如果模型厂商都在自己的SDK里直接内置了工具调用协议，那用户确实有理由问一句：“我为什么还要在中间挂一层MCP？”

2.2 大模型发展改变了底层竞争

原生化趋势确实在加速。OpenAI在Function Calling上持续迭代，Anthropic的原生Tools API也越来越完善，各家模型厂商几乎都在做同一件事：让“大模型输出结构化工具调用”成为模型能力的一部分，而不是靠外围协议去约束。这时候模型SDK提供的函数调用接口，天然就比外部协议更贴合模型本身。

举个例子，在模型推理时输出一个工具调用，原生SDK需要的是结构化输出与多轮工具结果拼接，这些功能如果模型平台自己就能闭环完成，那接入方确实只需要做后端服务适配，不需要借助MCP。这个逻辑听上去很有道理，但实际工程里有个被忽略的细节：模型SDK的原生工具能力大多只覆盖“模型到SDK”这一小段，从SDK再到企业内部服务的那段路，原生协议并不负责。那段路才是MCP真正的存在空间。

2.3 协议薄不薄，取决于你把它放在哪一层

我的判断是，讨论MCP薄封装有没有价值，先得分清楚连接位置。如果Agent只面向单一模型平台、工具由模型厂商内置插件市场提供，那中间层确实可有可无。但如果Agent需要连接企业内部多个异构系统、多方提供的工具、甚至跨团队协作，那MCP作为“工具能力描述层”的价值会明显超过成本。一个协议薄不薄不重要，重要的是它把“混乱”收敛到了哪一层。

3. Agent连接架构的重新选择

3.1 工具接入的主流派系

现在Agent连接工具的主流派系大概能分成四类，各有适用场景：

这四类之间并不严格互斥。实际项目里最常见的组合是“底层走传统API，中间加框架抽象，对外再暴露一个MCP Server”。问题是，当团队把这几层混在一起讨论时，很容易得出“MCP要不行了”、“MCP被原生替代”之类的片面结论。

3.2 为什么我说“删掉”更多是口号而非结论

说“删掉”很容易，但删掉之后呢？如果回到“每个工具自己写JSON Schema、自己定义调用约定”的状态，等于回到了2023年做AutoGPT时那种插件各自为战的老路。多个Agent协作场景里，工具能力的发现与调用仍然需要一个统一的描述载体。我可以接受这个载体不是MCP，甚至接受它未来被另一种协议替代，但“没有中间层”在复杂协作场景下是不成立的。

真要谈替代，行业里值得关注的是“工具服务网格化”和“模型原生上下文工程”两个方向。前者把工具调用看成微服务之间的一次RPC，用服务发现、流量治理、可观测性来支撑；后者把更多上下文直接塞进模型输入，减少“调用工具”本身的需求。这两条路都在发展，但没有哪条能短期内直接终结MCP在生态集成上的价值。

3.3 Agent框架与MCP的分工边界

很多人会把MCP和Agent框架放在一起比较，其实它们解决的不是同一层问题。Agent框架（比如LangChain、Dify、CrewAI、自研编排器）负责的是“智能体如何思考”：规划、记忆、工具调用决策、多Agent协作策略。而MCP负责的是“智能体如何触达外界工具”。框架可以通过MCP获取工具，也可以不走MCP直接调用工具SDK。MCP胜在接入统一性，框架胜在编排能力。二选一是伪命题，真正要设计的是“框架在哪个环节使用MCP”。

以我常用的架构为例：调度层由自研Agent框架负责，工具执行层分两批——内部核心服务走高性能gRPC直连，外部生态工具走MCP聚合网关。这样既保持了内部链路的低延迟，又让外部工具接入标准化。MCP在这里不是所有工具的入口，而是“生态工具的边界适配层”。

4. 摘掉“薄封装”后的工程实践

4.1 什么场景仍然值得用MCP

工程上做减法，我先说说哪些场景我会果断保留MCP。

第一类是跨团队工具共享。A团队做了个数据分析工具，B团队想在自己的Agent里直接用。如果没有统一协议，B团队得拿A团队的内网调用文档重新对接一遍；如果A团队直接发布一个MCP Server，B团队只要拿到服务地址和方法描述就能跑通。这类场景里，MCP的价值不是“薄”，而是“接口即文档”。

第二类是多模型适配。同一个Agent应用要同时接Claude、GPT、国产模型，每家的原生工具协议细节都不太一样。这时MCP作为中间语义层，能够让工具注册表和调用逻辑只维护一份。多模型切换时只是换一下模型网关配置，而不是重写工具接入代码。

第三类是本地工具集成，这也是我个人用得最多的场景。IDE插件、浏览器插件、本地脚本通过MCP的本地传输方式接入Agent开发流程，天然适合做开发辅助Agent。我自己在IDE里接代码分析工具时，就是直接跑一个本地MCP Server进程，比走网络服务更省事，也避免了云端传输代码的隐私问题。

4.2 具体落地时怎么选传输方式

MCP的传输方式分三类，选错会影响稳定性。现在官方主推的是Streamable HTTP，它把原来基于SSE的单项推送升级成了双向流式通信，更适合远端部署。本地工具推荐stdio，原因就一个：不需要处理端口暴露和CORS，子进程生命周期跟随主进程，干净利落。如果MCP Server部署在Kubernetes集群内部，走Streamable HTTP再加服务发现会更合理；如果只是个人开发机上的数据同步工具，用stdio足够了。

实际配置里有个容易踩的坑：MCP客户端（Host）初始化时会向Server发送initialize请求，协商协议版本和能力。不同版本之间如果不兼容，客户端会直接报错。所以升级MCP SDK时，最好是客户端和服务端同步升级，避免出现版本差一天、接口全对不上的尴尬。

4.3 一个轻量MCP Server的配置示例

很多朋友问过MCP Server到底怎么写。其实核心逻辑很直接：实现initialize、tools/list、tools/call三个方法，就能被普通MCP客户端识别。后面的扩展能力都是锦上添花。我用Python的FastMCP库给你看一个最小可跑的例子：

from fastmcp import FastMCP mcp = FastMCP("demo-server") @mcp.tool() def get_user_info(user_id: str) -> dict: """根据用户ID查询基本信息""" return {"user_id": user_id, "name": "示例用户"} if __name__ == "__main__": mcp.run(transport="stdio")

这个Server启动以后，任何支持stdio传输的MCP Host都能识别到get_user_info工具。如果你在Claude Desktop或者自研Host里配置了这个Server的启动命令，模型就能在对话中直接调用它。就这么简单——薄归薄，接起来确实快。

5. 真实项目中的连接架构选择：案例拆解

5.1 从一个多工具Agent看连接方式演进

我在2025年初重构过一个内部数据分析Agent，它的连接方式演变很有代表性。第一版是纯原生SDK版，直接按OpenAI Function Calling接入数据查询API，当时只有两个工具，跑起来很顺畅。后来团队想把代码库检索、指标监控、内部文档问答都接进去，问题开始冒出：不同工具要配不同的鉴权Header、返回结构也不统一，工具注册表膨胀到难以维护。

第二版引入了MCP聚合网关。团队把每个数据源封装成独立的MCP Server，网关负责统一注册和调用分发。改造之后的收益很直接：新增一个数据源时，只要开发对应的MCP Server，并在网关配置里加一行注册项，业务层面基本零改动。模型侧的感知变化不大，因为网关对外暴露的工具描述是统一维护的。这个过程中，我们发现“薄封装”的价值不在于技术复杂度，而在于“接入心智”的统一。团队不再需要为每个数据源写一套胶水代码，只需要理解MCP的接入范式。

5.2 从开发到上线的常见问题实录

这轮重构踩过的坑，我列几个典型的，给后来人参考：

• 鉴权边界不清晰。MCP协议本身不定义鉴权细节，所以当外部工具通过MCP网关接入时，鉴权逻辑还是得在网关层或者服务端自建。我们一开始把鉴权放进了MCP Server内部，导致每个Server都要维护一套密钥逻辑，重复且易泄漏。后来统一改成网关层注入临时凭证，Server内部不再感知用户身份，清爽很多。
• 子进程崩溃无人处理。用stdio方式启动本地MCP Server时，如果Server进程崩溃，Host可能还挂着，但工具调用已经全部超时。后来我们在运行脚本外层加了守护逻辑，检测进程退出码后自动重启，并在日志里打印异常堆栈。
• 工具名冲突。多个MCP Server同时注册同名的工具时，有些Host会直接覆盖，有些会报错。最好在工具命名上强制加前缀，比如code_retrieve、metrics_query，别指望框架帮你规避。
• 结构化输出的识别率问题。模型调用工具时偶尔会生成不符合Schema的参数，这时候不要全丢给模型重试。在网关层做一次轻度参数补全和类型强转，能显著提高调用成功率。说白了，MCP给的是“通路”，但路上的交通规则还得自己定。

在第4和第5节之间，我想特别强调的是：讨论MCP存废问题时，大部分人混淆了两个概念——“协议层标准”和“产品层封装”。MCP作为协议层标准，短期内没有明显对手；而产品层那些过度封装、重复封装的做法，确实到了该清理的时候。删掉的是不合理的封装，不是封装的必要性。

6. 讨论之外的实操建议

先说结论：MCP短时间内退出不了历史舞台，但它的定位正在从“万能连接层”收敛为“生态边界连接层”。单一模型、单一工具链的应用，确实可以完全不用MCP；跨模型、多工具方协作的系统，MCP仍然是最省力的标准基石。架构选型不是跟风选“新”，而是看你的系统边界到底断在哪里。

如果是从零开始做一个Agent项目，我的建议是先别急着搭MCP基础设施。第一步用平台原生工具调用把主流程跑通，确认工具数量确实超过三个、接入方不止一个团队之后，再引入MCP聚合层。过早引入标准，容易把简单问题复杂化；过晚引入标准，后面再重构集成层会肉疼。

最后分享一个我个人常用的判断标准：当你需要跟别人描述“我这个Agent能连哪些工具”时，如果答案是“我需要在代码里一个个适配”，说明你缺一个统一连接层；如果答案是“我只要注册一个工具描述就行”，说明连接架构已经合格了。MCP是不是最优解，见仁见智，但“连接规范化”这件事，在Agent从demo走向生产的过程中，是躲不开的。踩过几次工具接入的坑之后，你会跟我一样明白：真正值钱的不是协议本身，而是协议帮你省下的那些对接时间。