1. 从「删掉薄封装」说起MCP 到底在解决什么问题最近圈子里关于 MCP 的讨论突然多了起来起因是不少团队在复盘自己的 Agent 项目时发现当初为了接工具而引入的那层 MCP 封装现在看起来越来越像一块鸡肋。有人直接把它删了换成更直接的 API 调用或者 CLI 桥接跑下来效果反而更稳。于是就有了那个很扎眼的问题MCP 是不是要退出历史舞台了先把结论放前面MCP 不会消失但「把 MCP 当成万能胶水」的用法确实在退场。这两件事必须分开看混在一起谈就容易得出极端结论。MCP 全称 Model Context Protocol本质是一套让模型和外部工具、数据源之间对话的协议规范。它要解决的核心痛点很具体在没有统一协议之前每接一个工具就要写一套适配代码工具 A 用函数调用工具 B 用 HTTP 接口工具 C 只能走命令行Agent 侧要维护一堆分支逻辑。MCP 想做的事情就是把这些差异收敛到一层标准接口上让 Agent 只需要认识一种「说话方式」。这个思路本身没有问题问题出在落地时的抽象层级选择。很多团队一开始就把 MCP 当成唯一的接入层所有工具无论轻重都往 MCP Server 里塞结果就是一个本来三行代码就能调通的 API被包成了一个需要启动进程、维护连接、处理握手协议的 MCP 服务。这就是所谓的「薄封装」——封装带来的复杂度超过了它挡住的复杂度。我见过一个很典型的例子某个团队要接一个内部查询接口接口本身就是一个 GET 请求带 token。他们花了大概两天时间写了一个 MCP Server又花了一天调试连接稳定性最后发现直接用 SDK 里的 HTTP 工具调用十分钟就能跑通。这不是 MCP 的错是选型时没有判断「这个工具值不值得走 MCP」。所以这一轮讨论的真正价值不是宣判 MCP 死刑而是逼着大家重新想清楚一件事Agent 的连接架构到底该怎么分层。哪些走 MCP哪些走原生 API哪些走 CLI哪些干脆内联进代码这个决策才是核心。2. Agent 连接架构的四种形态与选型逻辑2.1 API、SDK、CLI、MCP 各自的位置要谈重选先把四个选项摆清楚。这四个词在热搜里反复出现但很多人对它们的边界其实是模糊的。API是最底层的契约就是一组约定好的请求和响应格式。它不关心谁调用、怎么调用只负责「你给我什么我还你什么」。SDK是 API 的语言级封装把 HTTP 细节、鉴权、重试、序列化都包好让你用熟悉的语言直接调方法。CLI是面向人的命令行入口但因为它本质上是「可执行的确定性程序」所以特别适合被 Agent 当成工具来调用。MCP则是面向模型的协议层它定义的是「模型如何发现工具、描述工具、调用工具」。把这四者画成一条线从下到上是API → SDK → CLI → MCP。越往上抽象越高对模型越友好但引入的中间层也越多。选型的本质就是判断你的场景需要多高的抽象。2.2 什么工具适合走 MCP我的经验是满足下面两三个条件的工具走 MCP 是划算的工具数量多且会动态变化比如一个平台有几十个能力今天加一个明天改一个用 MCP 做统一注册Agent 侧不用改代码就能发现新工具。需要跨多个 Agent 或客户端复用同一个工具能力既要给桌面端 Agent 用又要给服务端 Agent 用MCP 作为中间层能省掉重复适配。工具有状态或需要长连接比如浏览器自动化、数据库会话这类MCP Server 可以维护连接生命周期比每次调用都重建要高效。工具本身复杂需要描述性元数据参数多、有枚举、有依赖关系MCP 的 schema 描述能让模型更准确地调用。反过来下面这些情况就别硬上 MCP工具就一个简单接口参数固定调用频率也不高。工具已经有成熟的 SDK直接调方法比走协议更直接。工具是本地命令行程序CLI 调用已经足够确定。团队没有精力维护 MCP Server 的进程管理和错误处理。2.3 「删掉薄封装」背后的判断标准所谓薄封装就是封装层做的事情几乎等于它挡住的复杂度。判断标准很简单如果去掉这层封装调用方的代码量没有明显增加那这层封装就是多余的。举个具体的对比。假设要调用一个文本摘要接口走 MCP 的路径大概是启动 MCP Server 进程 → 建立连接 → 模型发现工具 → 构造符合 schema 的参数 → 发送请求 → 处理协议层错误 → 解析结果。中间任何一环出问题排查起来都要跨层。走 SDK 的路径是导入 SDK → 初始化客户端 → 调用方法 → 拿到结果。出错就是标准的异常堆栈清晰。当工具只有一个、参数简单、调用不频繁时后者的总成本明显更低。这就是为什么很多团队在项目跑顺之后会把那些「为了统一而统一」的 MCP 封装拆掉换回直接调用。但要注意拆封装不等于否定 MCP。拆掉的是那些不该走 MCP 的工具留下的是真正需要协议层的部分。一个健康的架构往往是 MCP、SDK、CLI 混用的各管各的。3. 实操如何判断一个工具该走哪条路3.1 一张决策表帮你快速定位与其凭感觉不如用一张表把判断标准化。下面这张表是我在实际项目里反复用过的按顺序问自己几个问题基本能定位到合适的接入方式。判断维度倾向 MCP倾向 SDK/API倾向 CLI工具数量多且动态少且固定中等偏本地调用方数量多客户端复用单一调用方本地 Agent参数复杂度高需 schema 描述中低低命令行参数状态需求需要长连接/会话无状态进程内状态维护成本承受度高低中错误处理要求需要协议层统一标准异常即可退出码判断用的时候从上往下问如果前几行都指向 MCP那基本可以确定如果大部分指向 SDK 或 CLI就别硬套 MCP。3.2 一个真实的重构案例我之前参与过一个 Agent 项目最初的设计是「万物皆 MCP」。团队花了大概三周把七八个工具全部包成了 MCP Server包括一个简单的天气查询、一个内部文档搜索、一个代码执行沙箱。跑了一个月之后问题开始暴露天气查询的 MCP Server 偶尔会因为进程重启导致连接断开Agent 侧要处理重连逻辑。文档搜索本身有成熟的 SDK走 MCP 之后反而丢掉了 SDK 自带的分页和缓存能力。代码执行沙箱确实需要 MCP因为它要维护一个长期运行的隔离环境。重构的时候我们做了三件事天气查询直接改成 SDK 调用删掉 MCP Server代码从两百多行降到三十行。文档搜索改回 SDK但保留一个轻量的 MCP 包装只用于向模型暴露「有哪些搜索能力」。代码执行沙箱继续走 MCP因为它的状态管理和隔离需求是真实存在的。重构后整体代码量减少了约四成故障率明显下降。这个案例说明的不是 MCP 没用而是MCP 应该用在它真正产生价值的地方。3.3 参数与配置的取舍细节在具体配置层面有几个容易被忽略的点。超时设置。走 MCP 时超时要在协议层和工具层各设一次两层超时要协调否则会出现「工具已经返回但协议层还在等」的假死。走 SDK 时通常只需要设一次。我的习惯是 MCP 层超时略大于工具层留出协议开销的余量。鉴权传递。MCP 的鉴权有两种模式一种是 MCP Server 自己持有凭证Agent 不感知另一种是 Agent 把凭证透传给 Server。前者更安全但灵活性差后者灵活但凭证会经过更多环节。涉及敏感凭证时优先选前者。错误语义。MCP 的错误码和 HTTP 错误码不是一一对应的映射时容易丢信息。比如一个 401 在 MCP 层可能被统一成「未授权」但具体是 token 过期还是权限不足就分不清了。这时候要么在 MCP Server 里保留原始错误信息要么干脆这个工具不走 MCP。提示任何涉及凭证透传的设计都要先确认凭证不会出现在日志、错误信息和模型上下文里。这是最容易被忽略的安全细节。4. 常见问题与排查技巧实录4.1 连接类问题的排查顺序MCP 相关的报错里连接问题占了大头。我整理了一个排查顺序基本能覆盖八成情况。第一步确认 MCP Server 进程是否真的起来了。很多时候报「连接失败」其实是 Server 根本没启动或者启动后立刻退出了。看进程列表和启动日志是最快的判断。第二步确认连接地址和端口。MCP 支持多种传输方式本地进程用标准输入输出远程用网络传输。地址写错、端口被占用、防火墙拦截都会表现为连接失败。第三步确认握手是否完成。MCP 有初始化握手流程如果 Server 版本和客户端不兼容握手会失败。这时候看日志里的协议版本号对比两端是否一致。第四步确认鉴权。如果前面都正常但还是连不上大概率是 token 问题。token 过期、格式错误、权限不足都会在这一步暴露。4.2 工具调用返回异常的定位方法工具能连上但调用返回异常排查思路和连接问题完全不同。先看是协议层异常还是工具层异常。协议层异常通常是参数不符合 schema、方法名拼错、返回格式不合法。工具层异常是工具本身执行失败比如接口返回 500、命令行退出码非零。区分方法很简单看错误信息里有没有协议相关的关键词。如果错误提到 schema、method、invalid params那是协议层如果提到具体的业务错误、HTTP 状态码、退出码那是工具层。协议层异常优先检查 schema 定义和实际传参是否一致。我遇到过好几次是 schema 里写了枚举值但模型传了一个枚举外的值协议层直接拒绝。这种问题在 SDK 调用里不会出现因为类型系统会提前拦住。工具层异常就回到工具本身的调试。把同样的参数用 CLI 或 SDK 手动跑一遍看是否复现。如果手动跑正常、走 MCP 异常那问题在封装层如果手动跑也异常那问题在工具本身。4.3 高频问题速查表现象可能原因排查动作连接超时Server 未启动/端口占用查进程、查端口握手失败协议版本不匹配对比两端版本号鉴权失败token 过期/格式错重新签发、检查格式参数被拒schema 与实际不符核对 schema 定义调用无响应超时设置不合理检查两层超时配置结果解析失败返回格式不合法抓原始返回内容频繁断连进程不稳定查 Server 日志、资源占用4.4 几个踩过的坑坑一把 MCP 当成服务发现用。有团队想让 MCP 动态发现工具结果工具列表一变Agent 侧的行为就不稳定。工具发现是 MCP 的能力之一但不代表所有工具都该动态发现。固定的工具直接写死更稳。坑二忽略进程生命周期。MCP Server 是独立进程它的启动、重启、退出都需要管理。很多团队只写了启动逻辑没写异常退出后的重启结果 Server 挂了之后 Agent 一直报连接失败。坑三在 MCP 层做业务逻辑。MCP 层应该只做协议转换业务逻辑放在工具本身。把业务逻辑塞进 MCP Server会导致这层越来越重最后又变成一个需要维护的「大泥球」。坑四凭证管理混乱。多个 MCP Server 各自持有凭证凭证轮换时要一个个改。建议把凭证管理集中到一处MCP Server 从统一的地方读取。5. 重选架构时的落地建议5.1 从最小可用集开始不要一上来就设计一套完整的连接架构。先挑两三个最核心的工具用最简单的方式接进去跑通之后再逐步扩展。扩展的过程中你会自然发现哪些工具需要 MCP哪些不需要。这个思路的好处是架构是「长」出来的不是「设计」出来的。设计出来的架构往往过度抽象长出来的架构更贴合实际需求。5.2 给每层定一个清晰的职责我的习惯是给每一层定一条不可逾越的边界API/SDK 层只负责和外部系统通信不做任何面向模型的适配。CLI 层只负责把确定性操作暴露成命令不做状态管理。MCP 层只负责协议转换和工具描述不做业务逻辑。Agent 层只负责决策和编排不直接处理底层通信细节。边界清晰之后任何一层出问题都能快速定位也不会出现「这个逻辑到底该放哪」的纠结。5.3 保留退路无论选哪种接入方式都要保证能相对容易地换掉。具体做法是在 Agent 和工具之间留一个薄薄的适配层Agent 只依赖这个适配层的接口不直接依赖具体的接入方式。这样将来从 MCP 换成 SDK或者反过来改动都局限在适配层。这个适配层不要做太多事它的存在意义就是「隔离变化」。做多了就又变成薄封装了得不偿失。5.4 监控与可观测性连接架构重选之后监控要跟着调整。MCP 层要监控连接数、握手成功率、协议错误率SDK 层要监控调用延迟、错误码分布CLI 层要监控退出码和耗时。这些指标分开看才能快速判断问题出在哪一层。我个人的体会是架构的复杂度应该和问题的复杂度匹配。工具简单接入就简单工具复杂才值得上协议层。MCP 不是银弹也不是包袱它只是一个工具。用对了地方它省事用错了地方它添乱。这一轮「删掉薄封装」的讨论本质上是在帮大家找回这个判断力。最后再分享一个小技巧每次引入一个新的接入方式之前先问自己「如果不用它最坏会怎样」。如果答案是「也没什么大不了」那就不用。这个习惯帮我省掉了不少过度设计的功夫。