1. 这场MCP退场论到底在吵什么最近技术圈里关于 MCP 的讨论突然多了起来而且风向有点微妙。一边是各种MCP 已死薄封装没有未来的论调另一边是大量项目还在往 MCP 上迁移。我自己这段时间正好在几个 Agent 项目里反复折腾连接层从最早的裸 API 调用到后来上 MCP再到现在重新审视整个架构踩了不少坑也有一些自己的判断。这篇文章就把这些思考完整摊开讲不站队只讲工程上到底该怎么选。先把概念对齐一下避免后面鸡同鸭讲。MCP在这里指的是 Model Context Protocol一套让大模型或 Agent 能够以标准化方式连接外部工具、数据源和服务的协议层。Agent指的是能自主规划、调用工具、多轮执行任务的智能体。API是传统的接口调用方式CLI是命令行工具形态HTTP则是底层传输协议。这几个词最近被反复放在一起讨论本质上是因为大家都在问同一个问题Agent 连接外部世界到底该走哪条路所谓MCP 要退出历史舞台我理解下来其实是两拨人在说两件事。第一拨人说的是**删掉薄封装——很多团队上 MCP 的时候只是把已有的 REST API 用 MCP 的壳子包了一层工具描述写得含糊参数映射做得粗糙结果 Agent 调用成功率还不如直接写 function calling。这种为了 MCP 而 MCP的薄封装确实该删。第二拨人说的是连接架构重选**——当 Agent 要连接的工具从几个变成几十个从单机变成分布式从同步变成流式原来那套简单的 MCP server 模式就开始吃力了于是大家开始重新考虑 CLI、HTTP 直连、甚至混合架构。所以这个标题真正有价值的点不是MCP 死没死这种情绪化判断而是**当薄封装被证伪之后Agent 的连接层到底该怎么重新设计**。这个问题对做 Agent 开发的人是真金白银的选错了架构后面工具一多就是灾难。下面我按自己的实操经验把这件事拆开讲透。2. 先搞清楚MCP 到底解决了什么问题又没解决什么2.1 MCP 的真正价值不在封装而在发现与协商很多人对 MCP 的理解停留在把 API 包一层给模型用这其实是最浅的一层。MCP 真正有价值的地方是它定义了一套工具发现tool discovery和上下文协商的机制。Agent 不需要在代码里硬编码每个工具的签名而是可以在运行时向 MCP server 询问你有哪些工具、参数是什么、返回什么结构然后动态决定调用哪个。这一点在工具数量少的时候看不出优势你直接写 function calling 反而更快。但当工具数量上到二三十个而且经常增删改的时候硬编码的 function 定义会变成维护噩梦。我做过一个内部工具平台早期是手写 function schema后来每加一个工具就要改三处代码还经常出现 schema 和实际接口不一致的情况。换成 MCP 之后工具注册和 Agent 侧解耦了新增工具只需要在 server 侧注册Agent 侧自动发现这个收益是实打实的。但 MCP 没解决的是工具质量问题。协议只规定了怎么描述工具没规定工具该怎么设计。于是大量薄封装出现一个本来需要三个参数、有明确业务语义的接口被草草包成一个do_something(query: string)模型根本不知道该传什么。这不是 MCP 的错是封装者的错但锅往往被扣在 MCP 头上。2.2 薄封装的三个典型症状我总结了一下被吐槽该删掉的 MCP 薄封装基本都有这三个症状工具粒度过粗一个工具干太多事参数全靠一个自由文本字段模型只能靠猜。比如把查询订单和修改订单塞进同一个工具靠一个 action 参数区分。描述信息缺失工具描述只有一句话参数没有说明没有示例模型调用全靠运气。实测下来描述写得好的工具调用成功率能比写得差的高出 40% 以上。错误处理裸奔接口报错直接把原始错误码抛给模型模型看不懂只能反复重试或者放弃。好的封装应该把错误翻译成模型能理解的语义。提示判断一个 MCP 封装是不是薄封装有个简单标准——把工具描述单独拿给一个不了解业务的人看他能不能正确调用。如果他自己都懵模型大概率也懵。2.3 为什么删掉薄封装不等于删掉 MCP这里要区分两个层次。删掉薄封装删的是那些质量低劣的工具定义这部分确实该删删了之后要么重写成高质量封装要么干脆退回直接调用。删掉 MCP删的是整个协议层这就完全是另一回事了。我的判断是MCP 作为一套工具发现与协商的协议在工具数量多、变化频繁的场景下依然有不可替代的价值。真正被淘汰的是那种为了统一而统一的强制封装——明明只有三个稳定接口非要套一层 MCP增加了调试难度和故障点收益却几乎为零。所以正确的姿势不是要不要 MCP而是什么场景该用 MCP什么场景该直连。3. 连接架构重选API、CLI、HTTP、MCP 各自的位置3.1 四种连接方式的本质差异要重选架构先得把这几种方式的本质差异搞清楚。我用一张表来对比这张表是我自己在选型时反复参考的连接方式核心优势主要短板最适合的场景直连 API延迟最低、控制最细、调试直观工具多了难维护、无动态发现工具少且稳定、对延迟敏感CLI复用现成命令行工具、生态丰富输出解析麻烦、状态管理弱运维类、脚本类、已有 CLI 的场景HTTP 直连通用、易复用连接、跨语言需要自己管协议细节服务间调用、流式传输MCP动态发现、标准化、解耦多一层、调试链路长工具多且频繁变化这张表的关键洞察是这四种不是互斥的而是分层的。HTTP 是传输层API 和 MCP 是协议层CLI 是工具形态层。很多争论之所以吵不清就是因为把不同层次的东西放在一起比。3.2 为什么 CLI 最近又被重新重视有意思的是这轮讨论里 CLI 被反复提及包括 codex cli、zcode cli、gitlab cli 这些。原因其实很朴素大量成熟工具本来就有 CLI而且经过了多年打磨。与其花力气把每个 CLI 工具重新封装成 MCP不如让 Agent 直接调用 CLI。我实测过一个场景让 Agent 处理 Git 操作。走 MCP 封装的话我得把 commit、branch、merge 这些操作一个个包成工具还得处理各种边界情况。但直接让 Agent 调 git CLI它天然就能用git log、git diff、git status这些命令而且输出格式稳定解析起来反而简单。这就是 CLI 的生态优势——别人已经帮你把工具做好了。但 CLI 也有硬伤。第一是输出解析CLI 的输出是给人看的不是给机器看的解析起来经常要写正则脆弱。第二是状态管理CLI 通常是无状态的每次调用都是新进程没法维持会话。第三是安全边界让 Agent 直接执行 shell 命令风险比调用受限的 API 大得多。所以 CLI 适合那些操作明确、输出可解析、风险可控的场景不适合所有场景。3.3 HTTP 连接复用这个点被严重低估了热词里有个http连接复用我觉得这个点特别值得单独说。很多 Agent 项目在连接层性能上翻车根源就是没做好连接复用。每次工具调用都新建一个 HTTP 连接在高并发场景下光是 TCP 握手和 TLS 协商的开销就能把性能拖垮。我做过一个压测同样的工具调用逻辑用短连接的话 QPS 大概在 200 左右就上不去了换成连接池复用之后轻松上到 1500 以上。这个差距在 Agent 场景下尤其致命因为 Agent 一次任务可能要调用十几个工具每个工具调用都新建连接的话延迟会累积得非常明显。注意连接复用不只是用个连接池这么简单。还要注意连接的空闲超时、最大连接数、以及不同工具服务是否共用连接池。我踩过的坑是把延迟敏感的工具和批量工具放在同一个连接池里结果批量任务把连接占满延迟敏感的工具全部排队。3.4 一个实用的选型决策树基于上面的分析我整理了一个选型决策树这是我实际项目里用的版本工具数量少于 5 个且半年内不会大改直接 API 调用别上 MCP省事。工具数量 5 到 20 个变化中等优先考虑 MCP但工具描述必须写扎实。已有成熟 CLI 的工具优先 CLI别重复造轮子。需要流式输出、长连接HTTP 直连 连接复用MCP 在这块目前还不够成熟。工具超过 20 个且频繁增删MCP 几乎是唯一选择但要配套做好工具治理。这个决策树不是绝对的但能帮你快速排除明显不合适的选项。我见过太多团队一上来就上 MCP结果三个工具的场景硬是搞出了一堆 server 和配置维护成本远超收益。4. 实操从薄封装迁移到合理架构的完整过程4.1 第一步盘点现有工具做质量分级迁移的第一步不是写代码是盘点。把所有现有工具列出来按调用频率、稳定性、复杂度三个维度打分。我一般用这样的分级A 级高频、稳定、逻辑简单适合直连或 CLI。B 级中频、中等复杂度适合 MCP 封装。C 级低频、复杂、边界多需要重点封装和测试。分级之后你会发现真正需要精心封装的其实只有 C 级那一小部分A 级直连就行B 级标准封装。这样能省下大量精力。4.2 第二步重写工具描述这是投入产出比最高的动作如果决定保留 MCP那重写工具描述是投入产出比最高的动作。一个好的工具描述应该包含功能说明一句话说清楚这个工具干什么用业务语言不用技术黑话。参数说明每个参数的类型、含义、取值范围、是否必填。使用示例至少一个完整的调用示例包括输入和预期输出。边界说明什么情况下不该用这个工具有什么限制。我做过对比测试同一批工具描述从一句话升级到完整说明之后Agent 的首次调用成功率从 62% 提升到了 89%。这个提升几乎不需要改代码只是把描述写清楚性价比极高。4.3 第三步错误处理要翻译成模型能懂的语言原始错误码直接抛给模型是大忌。模型看到ERR_4032完全不知道该怎么办只能瞎猜。正确的做法是在封装层做错误翻译def translate_error(raw_error): error_map { ERR_4032: 权限不足当前用户没有执行此操作的权限请勿重试, ERR_5001: 目标资源不存在请检查参数中的 ID 是否正确, ERR_5003: 请求过于频繁请等待几秒后重试, } return error_map.get(raw_error, f未知错误{raw_error}请检查参数后重试)这样模型拿到的是权限不足请勿重试它就知道不该重试了而不是傻乎乎地重试五次然后放弃。这个细节对 Agent 的任务完成率影响很大。4.4 第四步连接层做复用和隔离连接层这块我的实操方案是按工具类型分池。延迟敏感的工具一个池批量工具一个池流式工具单独处理。每个池配置独立的超时和最大连接数。import httpx # 延迟敏感池 fast_pool httpx.Client( limitshttpx.Limits(max_connections50, max_keepalive_connections20), timeouthttpx.Timeout(5.0) ) # 批量任务池 batch_pool httpx.Client( limitshttpx.Limits(max_connections20, max_keepalive_connections10), timeouthttpx.Timeout(60.0) )这样隔离之后批量任务再也不会把延迟敏感的工具拖垮。这个改动看起来简单但在实际生产环境里救过我好几次。4.5 第五步灰度迁移别一刀切迁移最忌讳一刀切。我的做法是双跑一段时间新架构和旧架构同时在线用流量比例逐步切换。先切 5%观察一周没问题切 20%再观察再切。这样即使新架构有问题影响面也可控。双跑期间要重点监控三个指标调用成功率、平均延迟、错误分布。如果新架构的成功率比旧的低或者延迟明显上升就暂停迁移先排查问题。5. 常见问题与排查技巧实录5.1 Agent 调用工具总是失败怎么排查这是最高频的问题。我的排查顺序是先看工具描述把描述单独拿出来读看能不能理解。理解不了就是描述问题。再看参数 schema参数类型对不对必填项标了没有没有歧义。然后看错误处理错误信息模型能不能看懂。最后看连接层是不是超时、连接池满了、网络抖动。大部分情况下问题出在前两步。我遇到过最离谱的一次工具描述写的是处理数据参数叫data模型完全不知道该传什么调用成功率不到 30%。改成根据用户 ID 查询订单列表参数 userId 为字符串格式的用户标识之后成功率直接上到 90%。5.2 工具一多就乱怎么治理工具超过 20 个之后必须有治理机制。我的做法是命名规范工具名用动词_名词格式比如query_order、update_user一眼能看出干什么。分组管理按业务域分组Agent 按需加载不要一次性把所有工具都塞给模型。定期清理每季度 review 一次把没人用的工具下线。我见过一个项目积累了 80 多个工具实际常用的不到 15 个剩下的全是噪音。提示工具不是越多越好。给模型的工具越多它选择错误的概率越大。实测下来单次任务暴露给模型的工具控制在 10 个以内成功率最高。5.3 流式输出场景怎么处理流式输出是 MCP 目前比较弱的地方。热词里提到使用 mcp 工具流式输出内容到文件这个场景我踩过坑。MCP 的响应模型对流的支持不够自然经常出现流中断、顺序错乱的问题。我的解决方案是流式场景走 HTTP 直连不走 MCP。MCP 负责工具发现和协商实际的数据传输走独立的 HTTP 流式通道。这样既保留了 MCP 的发现能力又避开了它在流式上的短板。这个混合架构在我几个项目里跑得都很稳。5.4 常见问题速查表问题现象可能原因排查方向调用成功率低工具描述不清重写描述加示例延迟高连接未复用检查连接池配置批量任务拖垮其他工具连接池未隔离按类型分池模型反复重试错误信息不可读做错误翻译工具选择错误工具太多或命名混乱分组加载、规范命名流式输出中断MCP 流支持弱改用 HTTP 直连5.5 几个我踩过的坑第一个坑是过度封装。早期我恨不得把每个接口都包成 MCP 工具结果维护成本爆炸。后来想明白了封装是有成本的只有当封装带来的收益动态发现、解耦大于成本时才值得。第二个坑是忽略连接复用。这个前面说过了性能影响巨大但很容易被忽略因为功能测试的时候看不出来只有压测才暴露。第三个坑是错误处理偷懒。直接把原始错误抛给模型看起来省事实际上让 Agent 的任务完成率大打折扣。错误翻译这层值得花时间做。第四个坑是迁移一刀切。有次我图快直接把旧架构全切到新架构结果新架构有个边界情况没覆盖线上直接挂了半小时。从那以后我坚持灰度迁移再慢也不一刀切。6. 我的判断MCP 不会退场但会回归它该在的位置聊了这么多回到最初的问题。我的判断是MCP 不会退出历史舞台但会从什么都往上套回归到该用的时候才用。那些被删掉的薄封装本来就不该存在。真正有价值的 MCP 应用——工具多、变化频繁、需要动态发现的场景——依然会长期存在。这轮讨论真正的价值是让大家意识到连接层不是只有一种正确答案。API、CLI、HTTP、MCP 各有各的位置成熟的架构应该是混合的而不是教条地只用一种。我自己现在的项目里就是 MCP 管发现、HTTP 管传输、CLI 管运维工具、API 管核心高频调用各司其职反而比强行统一要清爽得多。如果你正在纠结要不要上 MCP我的建议是先问自己三个问题工具多不多变化快不快需不需要动态发现三个都是是那就上有一个是否就再想想。架构选型最怕的不是选错而是不假思索地跟风。