1. 当删掉薄封装成为共识MCP到底动了谁的奶酪最近半年只要在技术社区里聊到 Agent 架构MCP 这个词几乎绕不开。但风向变得也快——前一阵子大家还在热火朝天地给各种工具套 MCP Server最近却频繁看到另一种声音MCP 就是一层薄封装直接删掉让 Agent 调 CLI 或原生 API 不香吗这个论调不是空穴来风它背后其实藏着一个很现实的工程判断当模型本身越来越聪明、工具调用能力越来越强时中间那层协议翻译到底还有没有存在的必要。先把话说清楚MCPModel Context Protocol本质上是一套让模型和外部工具、数据源之间标准化通信的协议。它的初衷非常朴素以前每接一个工具就要写一套专属的适配代码工具一多维护成本爆炸。MCP 想做的就是把这层适配抽象出来让工具提供方和模型调用方解耦。听起来很美好对吧问题就出在抽象这两个字上——抽象是有代价的而很多人低估了这个代价。我自己最早接触 MCP 是在给一个内部知识库做检索增强的场景。当时兴冲冲地搭了一个 MCP Server把文档检索、数据库查询、文件读写都包了进去。跑通的那一刻确实爽但真正上线之后问题就来了调试链路变长了一个简单的查询请求要经过模型 → MCP Client → MCP Server → 实际工具四层中间任何一层出问题排查起来都像剥洋葱。更别提延迟多一跳网络通信在高并发场景下就是实打实的成本。所以删掉薄封装这个说法我理解它真正想表达的不是MCP 一无是处而是当你的工具本身就是标准化的、模型已经能直接理解的时候再套一层 MCP 就是过度设计。这就像你明明可以直接打电话非要找个接线员转接——接线员在电话系统不发达的时候是刚需但现在呢但反过来讲MCP 也绝不是要退出历史舞台。它解决的核心问题是标准化和可发现性当你有几十上百个工具来自不同团队、不同语言、不同部署环境时一个统一的协议能让 Agent 动态发现和调用工具这个价值是 CLI 和裸 API 给不了的。关键在于你得判断自己处在哪个阶段。一句话总结这一节MCP 不是要不要用的问题而是什么时候用、用到什么程度的问题。薄封装该删就删但协议层的价值不能一棍子打死。2. 拆开看MCP、CLI、原生 API 各自的能力边界要判断该选哪条路得先把这三个东西放在同一张桌子上对比。很多人争论半天其实是在拿不同层次的东西互相比较鸡同鸭讲。我习惯用一个类比原生 API 是食材CLI 是厨房里的现成厨具MCP 是餐厅的菜单系统。食材最灵活但最费事厨具顺手但功能固定菜单系统让你不用进厨房就能点菜但多了一层传菜流程。2.1 原生 API最灵活也最重原生 API 是模型直接调用某个服务的 HTTP 接口或 SDK。它的优势是零中间层、延迟最低、控制粒度最细。比如你要让 Agent 查一下股票数据直接调东财的接口拿到 JSON 自己解析整个过程干净利落。DeepSeek、智谱、Kimi 这些大模型 API 的调用也是同理直接发请求就行。但它的代价是每个 API 的鉴权方式、参数格式、错误码、限流策略都不一样。你接十个 API就要写十套适配逻辑。而且模型得知道这个 API 的存在和用法——要么你把 API 文档塞进上下文token 哗哗地烧要么用 function calling 把每个接口定义成工具工具一多prompt 就爆炸。这就是为什么在工具数量少、调用频率高的场景下原生 API 是首选但工具一多维护成本就压不住了。2.2 CLI被严重低估的老古董CLI 这两年有点文艺复兴的意思。Codex CLI、GitLab CLI、各种命令行工具的重新流行说明大家发现了一个朴素的事实命令行是人类和机器都能理解的通用接口。一个设计良好的 CLI模型只要知道命令名和参数就能直接调用不需要额外的协议层。CLI 的最大优势是可组合性和可调试性。你可以把命令串起来可以用管道可以重定向到文件出错了直接在终端里复现。我在做批量文件处理的时候经常让 Agent 直接调 ffmpeg 的命令行比包一层 MCP 再调 ffmpeg SDK 要快得多也稳得多。而且 CLI 天然适合流式输出到文件这类操作比如把处理结果直接写进日志或数据文件。但 CLI 的短板也很明显它假设执行环境是可信的、有 shell 的。在沙盒环境、容器隔离、或者需要精细权限控制的场景下直接给 Agent 一个 shell 是危险的。另外CLI 的可发现性差——模型得预先知道有哪些命令可用不像 MCP 那样能动态查询工具列表。2.3 MCP为工具生态而生MCP 真正的价值场景是工具数量多、来源杂、需要动态发现的时候。想象一下你有一个 Agent 平台接入了文档检索、数据库、代码执行、第三方 SaaS 等几十个工具这些工具由不同团队维护随时可能增减。这时候如果没有统一协议每加一个工具就要改 Agent 的代码根本没法规模化。MCP 通过Server 注册工具 → Client 发现工具 → 模型调用工具这套机制把工具的生命周期和 Agent 解耦了。工具团队只管实现 MCP ServerAgent 侧不用改代码就能用上新工具。这是 CLI 和裸 API 做不到的。但代价就是前面说的多一层抽象多一层延迟多一层调试复杂度。而且 MCP 的生态还在演进中协议本身也在变早期采用者要承担跟着升级的成本。维度原生 APICLIMCP延迟最低低较高多一跳灵活性最高中中可发现性差差强调试难度低低高适合工具数量少10中多20权限控制需自建依赖 shell协议层可控生态成熟度高高演进中这张表不是让你照抄而是帮你建立判断框架。工具少、追求性能选 API工具中等、环境可信选 CLI工具多、要动态扩展才轮到 MCP 上场。3. 从薄封装到重架构一次真实的选型踩坑记录光讲理论没意思我拿一个自己踩过的坑来说。去年我负责给一个内部研发助手做工具接入目标是让 Agent 能查代码仓库、跑测试、读文档、查数据库。一开始我图省事全用 MCP 包了一遍结果上线两周就被现实教育了。3.1 问题一调试链路长得让人崩溃第一个坑是调试。有一次 Agent 查数据库一直返回空结果我从模型输出开始查怀疑是 prompt 问题改了半天 prompt 没用又去查 MCP Client 的日志发现 Client 发出的请求是对的再去看 MCP ServerServer 日志显示它确实收到了请求但转发给数据库的 SQL 有问题。整个过程花了两个多小时而如果直接调数据库 API我五分钟就能定位到 SQL 写错了。这就是薄封装的隐性成本它把简单问题复杂化了。每一层抽象都在增加信息损耗和排查路径长度。当你的工具逻辑本身很简单时这层封装带来的收益远小于它带来的麻烦。3.2 问题二延迟在高并发下被放大第二个坑是性能。我们内部有个场景是 Agent 批量处理工单每个工单要调三四个工具。用 MCP 之后每个工具调用多了一跳网络通信单次看着不多几十毫秒但批量场景下几百个工单并发累积延迟就很可观了。后来我们做了压测发现 MCP 层的开销占了总延迟的 30% 左右。这个数字让我重新思考MCP 的抽象价值是否值得这 30% 的性能代价对于交互式场景几十毫秒用户感知不到但对于批处理、高并发场景这就是实打实的成本。后来我们把高频、简单的工具比如查数据库、读文件改成了直接调 API 或 CLI只把那些需要动态发现、权限隔离的工具留在 MCP 里整体延迟降下来了。3.3 问题三协议升级带来的维护负担第三个坑最隐蔽MCP 协议本身在快速演进。我们接入的时候用的是某个版本过了几个月协议更新了一些字段语义变了我们的 Server 得跟着改。如果只是自己用还好但我们有好几个团队共用这套工具一升级就要协调沟通成本很高。这让我意识到采用一个还在演进的协议是要付出跟随成本的。如果你的团队没有精力持续跟进或者工具本身很稳定不需要频繁变动那这层协议带来的更多是负担而非收益。踩完这三个坑我的结论是MCP 适合工具生态场景不适合工具固定且简单场景。判断标准很简单——如果你的工具列表半年都不变一次那大概率不需要 MCP。4. Agent 连接架构重选一套可落地的决策流程踩完坑之后我总结了一套选型流程后来在几个项目里复用效果还不错。这套流程的核心不是选哪个技术而是先搞清楚自己的场景特征。4.1 第一步数清楚你的工具盘子先别急着选技术拿张纸把你要接入的工具列出来标注三个属性调用频率、逻辑复杂度、变更频率。调用频率高、逻辑简单、几乎不变的工具比如查配置、读缓存优先考虑原生 API 或 CLI别套 MCP。调用频率低、逻辑复杂、需要权限隔离的工具比如执行敏感操作可以考虑 MCP用协议层做管控。变更频繁、来源多样的工具比如第三方 SaaS 集成MCP 的动态发现能力能省不少事。我一般会画一个二维矩阵横轴是工具数量纵轴是变更频率。落在右上角多且常变的MCP 是合理选择落在左下角少且稳定的直接 API 或 CLI。4.2 第二步评估你的执行环境执行环境决定了 CLI 能不能用。如果 Agent 跑在受控的沙盒里没有完整 shell那 CLI 这条路基本堵死只能在 API 和 MCP 之间选。如果环境可信、有 shellCLI 的性价比往往最高。这里有个容易被忽略的点权限模型。原生 API 的权限靠 API Key 和接口本身的鉴权CLI 的权限靠操作系统用户和文件权限MCP 的权限可以在协议层做细粒度控制。如果你的场景对权限隔离要求高比如多租户MCP 的协议层管控是有价值的如果只是单租户内部使用那这层管控就是多余的。4.3 第三步算一笔延迟和成本的账这一步最容易被跳过但恰恰最关键。我习惯做一个简单的估算原生 API延迟 网络往返 服务处理时间CLI延迟 进程启动 命令执行时间进程启动在频繁调用时不可忽略MCP延迟 网络往返 × 2 协议序列化/反序列化 服务处理时间如果你的场景对延迟敏感比如实时交互、高并发批处理这个账必须算。我见过太多团队一开始图 MCP 的标准化上线后才发现延迟扛不住又回头重构白白浪费几个月。4.4 第四步留好混合架构的后路最重要的一条经验别指望一种方案打天下。成熟的 Agent 架构往往是混合的——高频简单工具走 API/CLI复杂多变工具走 MCP各取所长。关键是设计好统一的工具调用抽象层让上层 Agent 不用关心底层走的是哪条路。我们后来的做法是在 Agent 和具体工具之间加了一个轻量的路由层它根据工具的类型和当前负载决定这次调用走 API、CLI 还是 MCP。这个路由层很薄但让整个架构灵活了很多。工具团队也不用被迫统一到某一种接入方式各选各的最优解。5. 那些没人告诉你的实操细节与避坑清单理论讲完了说点真正干活时才会遇到的细节。这些东西文档里不会写但每一个都能让你少熬几个夜。5.1 关于 MCP Server 的状态管理陷阱MCP Server 默认是无状态的但很多工具其实是有状态的比如一个需要登录会话的数据库连接。如果你在 Server 里维护了状态就要考虑并发调用时的状态隔离问题。我踩过一次坑多个 Agent 并发调用同一个 MCP ServerServer 里共享了一个数据库连接结果事务互相干扰数据错乱。后来改成每个请求独立连接问题才解决。提示MCP Server 里任何共享的可变状态都是并发场景下的定时炸弹。要么做成无状态要么做好隔离。5.2 CLI 调用的注入风险与参数转义让 Agent 直接拼 CLI 命令最大的风险是命令注入。模型生成的参数里如果带了特殊字符比如分号、反引号、管道符可能被解释成额外的命令。我见过一个案例Agent 处理用户输入的文件名时文件名里带了; rm -rf结果……你懂的。解决办法有两个一是用参数数组而不是字符串拼接比如 Python 的subprocess.run([...])二是对参数做严格的白名单校验。千万别图省事用shellTrue拼字符串。5.3 原生 API 的上下文长度与限流双重夹击直接调大模型 API 的时候两个坑最常见上下文超限和限流。上下文超限的报错很直白比如那个经典的 maximum context length is 1048576 tokens但很多人不知道的是工具调用的返回结果也会占用上下文。如果你让 Agent 调一个返回巨量数据的 API结果全塞进上下文很容易就爆了。我的做法是在工具层做结果截断和摘要。API 返回的数据先在工具侧处理成精简格式再交给模型。限流同理工具层要做好重试和退避别让模型直接面对 429 错误。5.4 工具描述的可发现性设计不管走哪条路模型都得知道工具怎么用。MCP 靠工具描述description做发现CLI 靠 help 文档API 靠 function calling 的 schema。这里有个通用原则工具描述要写得像给新同事的交接文档——说清楚这个工具干什么、参数是什么、什么时候该用、什么时候不该用。我见过太多工具描述写得含糊其辞模型只能瞎猜调用成功率自然低。花十分钟把描述写清楚比调半天 prompt 管用得多。5.5 监控与可观测性别等出事才想起来最后一条也是最容易被忽略的给工具调用加监控。不管走 API、CLI 还是 MCP你都需要知道调用成功率、平均延迟、错误分布、哪些工具最常被调用。没有这些数据你根本没法判断架构选型对不对也没法做优化。我们后来在每个工具调用点都埋了点用统一的日志格式记录工具名、入参摘要、耗时、结果状态。这套东西搭起来不复杂但价值巨大——它让该不该删掉 MCP这种争论从拍脑袋变成了看数据。6. 回到那个问题MCP 会退出历史舞台吗聊到这儿可以正面回答标题里的问题了。我的判断是MCP 不会退出历史舞台但它的定位会从默认选项回归到特定场景的专用工具。早期大家一窝蜂上 MCP是因为它听起来标准、优雅、面向未来。但工程实践会教育每一个人没有银弹只有权衡。当工具少而简单时MCP 的抽象就是负担当工具多而杂时MCP 的标准化就是刚需。所谓删掉薄封装删的是那些本就不该存在的过度抽象而不是否定协议本身的价值。我现在的做法是默认从最简单的方案起步。能用原生 API 就用 API能用 CLI 就用 CLI只有当工具数量、变更频率、权限隔离这些维度真的到了需要协议层的程度才引入 MCP。这个顺序很重要——先简单后复杂而不是反过来。至于 Agent 连接架构的未来我个人的体会是混合架构会成为常态。API、CLI、MCP 不是互相替代的关系而是各司其职。真正考验架构能力的不是选对了哪一种而是设计好那层让它们协同工作的抽象。这层抽象要足够薄薄到不成为瓶颈又要足够清晰清晰到能统一管理。这个平衡点每个团队都得根据自己的场景去找没有标准答案。最后分享一个我一直在用的小技巧每次引入新的连接方式之前先问自己如果不用它最坏会怎样。如果答案是也没啥大不了那就别引入。技术选型里克制往往比激进更难也更值钱。