MCP 真的会被 Skills + CLI 干掉吗？聊聊我的观察
公众号名称：三元同学
作者名称：三元同学
发布时间：2026-04-24 09:53
最近这段时间 Skills + CLI 的声量太大了。OpenClaw 带火了这套组合之后，社区里铺天盖地都是”MCP 要被取代了”的论调。
说实话，我之前也觉得 Skills + CLI 确实比 MCP 更简洁、更高效。在本地跑 Agent 的场景下，一个 SKILL.md + 一行 CLI 命令，比配一个 MCP Server 简单太多了。
但现在我得承认，我之前说的太武断了。因为在我做一些 Agent 产品的过程，我发现遇到的场景很多时候并不适合用 Skills + CLI，至于为什么，后文会展开讲。
碰巧，最近 Anthropic 发了一篇博客——《Building Agents That Reach Production Systems with MCP》，把这个问题说得很透。看完之后我觉得”Skills 取代 MCP”这个暴论，确实站不住脚了。
关键变量：你的 Agent 跑在哪
Skills + CLI 能干掉 MCP 的前提是什么？是你的 Agent 跑在本地。
本地环境有文件系统、有 Shell、有包管理器。模型读一个 SKILL.md 知道该怎么做，然后直接 Bash 调 ffmpeg、kubectl、git，不需要中间加一层协议。这条路确实比 MCP 更直接。
但现实是，越来越多的 Agent 跑在云上。
Web 应用里嵌的 Agent、移动端 Agent、API 服务型 Agent——这些场景下没有本地文件系统，没有 Shell 可以调。你能让一个跑在浏览器里的 Agent 去执行 CLI 命令吗？一般情况下是做不到的。
而这些 Agent 需要连接的是什么？数据库、内部系统、数据分析平台、Stripe 平台等等。全都在云上，全都需要认证，全都需要标准化的远程协议。
MCP 就是干这个的。
我自己在做 Agent 产品的时候就遇到了这个问题。本地开发用 Claude Code，Skills + CLI 非常方便，但一旦面对自己要做的云端 Agent 产品，在没有使用沙箱的情况下，没有文件系统和 Bash 命令的执行环境，那么 Skills + CLI 就走不通了，只能选择别的方案，而 Skills(非文件形式) + MCP/纯纯的 tool 就成了不二之选了。
MCP 不是在萎缩，是在加速
Anthropic 官方的数据显示：
MCP SDK 月下载量已经突破 3 亿，年初还只有 1 亿，4 个月涨了 3 倍。Anthropic 目录里有 200 多个 MCP Server，每天有几百万人在用。
而且之前大家吐槽 MCP 最多的 Token 占用问题，也在被快速解决：
Tool Search——工具多了不全塞上下文，按需搜索加载，Token 占用降了 85%。
至于 Tool Search 究竟是什么样的作用机制，怎么设计才不会影响 Claude 的 Prompt Cache，我在 Agent 系统课程里面已经详细拆解了，如果你想系统掌握，可以加我微信 sanyuan0704，备注 “agent 系统学习” 即可。
Code Orchestration——Cloudflare 2500 个 API 端点只暴露 2 个工具（搜索 + 执行），Agent 自己写代码调用，整套工具定义只占 1000 token。
说了这么多，我真正想表达的是，MCP 的工程问题不是无解的，社区在持续优化，而且速度很快。
MCP 正在长出 CLI 给不了的能力
除了修复已有的问题，MCP 还在长出一些全新的能力，这些能力是 Skills + CLI 从架构上就做不到的。
MCP Apps——工具可以返回交互式 UI。图表、表单、仪表盘，直接在对话里渲染出来。你让 Agent 查一个数据，它不是给你吐一堆文字，而是直接画一张图表出来。CLI 能返回的只有文本，这种富交互体验它给不了。Anthropic 说，接入了 MCP Apps 的 Server，用户留存率明显更高。
Elicitation——工具执行到一半可以暂停，主动向用户要信息。比如 Agent 在帮你订酒店，执行到付款环节，MCP Server 可以弹出一个表单让你确认价格和房型，或者直接跳转到支付页面完成认证。这种”中途交互”的能力，CLI 的同步执行模式是做不到的。
OAuth 和 Vault——MCP 最新的协议版本标准化了 OAuth 客户端注册（CIMD），用户首次授权更快，重复授权更少。Managed Agents 里还加了 Vault 机制，注册一次 OAuth token，后面所有 Session 自动注入和刷新。这整套认证体系，CLI 世界里完全没有对应物——CLI 的认证靠的是磁盘上的 credential 文件，换个环境就废掉了。
你看，MCP 不是在原地等着被取代，它在往”富交互”和”企业级安全”的方向进化。这些方向上，CLI 是打不过 MCP 的。
真正的关系：不是替代，是分工
客观来讲，MCP 和 Skills 这两者是分工关系：
Skills 负责”知道怎么做”——最佳实践、使用指南、常见坑有哪些。
MCP 负责”能做到”——连接外部系统、执行远程操作、处理认证。
你告诉模型”用 Supabase 的时候查询优化要注意这些点”，这是 Skills 干的事。你让模型真的去连 Supabase 执行 SQL，这是 MCP 干的事。
Anthropic 博客里推荐的模式也是这样：MCP Server 捆绑发布 Skills。Canva、Notion、Sentry 已经在这么做了——MCP Server 提供 API 能力，配套的 Skills 提供最佳实践和使用指南，两个一起给 Agent。
用人话说就是：MCP 是手，Skills 是脑子里的经验。手和经验不是替代关系，是配合关系。
Anthropic 官方也透出一个信息：MCP 社区正在开发一个新的扩展方式，允许 MCP Server 直接分发 Skills。也就是说，以后你接入一个 MCP Server，不只是获得了工具调用能力，还自动获得了配套的最佳实践——知识和能力打包在一起走。
这才是最终的形态。
不同场景，不同选择
不同的场景对应的选择不同：
本地 Agent（Claude Code、OpenClaw 这种）——Skills + CLI 确实是更优解。有完整的文件系统和 Shell，不需要加一层协议。这个场景下 CLI 的简洁性是实打实的优势。
云端 Agent（Web 应用、API 服务、移动端）——Skills + MCP 是最优解。没有本地环境，必须走远程协议。而且云端 Agent 通常需要对接多个第三方服务，MCP 的标准化在这里价值巨大——一个 Server 写好，Claude、CodeX、Cursor 全都能用。
所以”Skills 干掉 MCP”本质上是把一个局部结论（本地场景下 CLI 比 MCP 简洁）当成了全局结论。这跟之前”80% 的 App 要消失”是一个逻辑——拿一个特定场景下的正确观察，过度泛化成了普遍判断。
我的看法
技术圈喜欢搞”A 干掉 B”的叙事。Skills 干掉 MCP、CLI 干掉 GUI、Agent 干掉 App——每个都听着很过瘾，但每个仔细想想都站不住。
实际上大部分技术演进不是替代，是分层。新东西出来不是把旧东西干掉了，而是各自找到了自己最合适的位置。
Skills + CLI 在本地场景下确实更简洁，这个我百分百同意。但说 MCP 要被取代呢？拿数据来说，月下载 3 亿、增速 3 倍、Anthropic 自己的新产品（Managed Agents、Cowork）全在往上面押注——你还觉得 MCP 会死掉吗？
与其考虑怎么站队，不如想清楚你的 Agent 跑在哪、需要连什么、用户在什么环境下用。答案自然就出来了。
你在做的 Agent 项目里，用的是 Skills + CLI 还是 MCP？还是两者都用了？评论区可以来聊聊哈。
Original 三元同学 三元同学