MCP会被Skills与CLI取代吗深度观察与分析

首页

热心网友

转载

2026-05-18

最近，关于“Skills + CLI 将取代 MCP”的讨论在社区里沸沸扬扬。自从 OpenClaw 带火了这套组合，似乎到处都能听到类似的论调。

平心而论，在本地开发 Agent 的场景下，Skills + CLI 的优势确实明显。一个 SKILL.md 文件加上一行命令，比起配置一个完整的 MCP Server，路径要直接得多。但话说回来，这种“简洁”是否放之四海而皆准？在深入参与了一些云端 Agent 产品的构建后，我发现情况要复杂得多。许多场景下，Skills + CLI 这条路根本走不通。

恰好，Anthropic 最近发布了一篇题为《Building Agents That Reach Production Systems with MCP》的博客，把这个问题剖析得非常透彻。看完之后，一个清晰的结论浮出水面：“Skills 取代 MCP”更像是一个局部观察被误读成了全局真理。

关键变量：你的 Agent 跑在哪

Skills + CLI 方案成立，有一个至关重要的前提：你的 Agent 运行在本地环境。本地有完整的文件系统、Shell 和包管理器。模型读取 SKILL.md 理解操作步骤，然后直接通过 Bash 调用 ffmpeg、kubectl 或 git，中间不需要任何协议转换。这条路确实高效。

然而，现实是越来越多的 Agent 正跑在云端。无论是嵌入 Web 应用、集成在移动端，还是作为 API 服务提供，这些场景下根本没有本地文件系统，也无法直接执行 Shell 命令。你能指望一个运行在浏览器沙箱里的 Agent 去调用本地 CLI 吗？显然不现实。

这些云端 Agent 需要连接的是什么？是数据库、内部业务系统、数据分析平台，或是像 Stripe 这样的第三方服务。它们都在远端，都需要认证，也都需要一个标准化的远程通信协议。而这，正是 MCP 设计的初衷和核心价值所在。

实际开发中就有这样的切身体会：用 Claude Code 做本地原型时，Skills + CLI 得心应手；但一旦转向构建面向用户的云端 Agent 产品，在没有沙箱环境提供文件系统和 Bash 的情况下，Skills + CLI 的方案立刻失效。此时，Skills（以非文件形式定义）配合 MCP，或者直接使用工具定义，就成了几乎唯一可行的选择。

MCP 不是在萎缩，是在加速

认为 MCP 式微的观点，可能忽略了数据。根据 Anthropic 的最新数据，MCP SDK 的月下载量已突破 3 亿次。要知道，年初这个数字还只是 1 亿，这意味着在短短四个月内增长了 3 倍。目前，Anthropic 的官方目录中收录了超过 200 个 MCP Server，每天有数百万用户在使用它们。

不仅如此，过去被社区诟病最多的 Token 占用问题，也正在被快速解决。例如，通过“工具搜索”功能，系统可以按需加载工具，而非一次性将所有工具定义塞入上下文，这能将 Token 占用降低高达 85%。

另一个例子是“代码编排”模式。Cloudflare 通过这种模式，将 2500 个 API 端点抽象为仅两个工具（搜索和执行），由 Agent 动态生成代码来调用，整套工具定义仅占用约 1000 Token。这些进展表明，MCP 面临的工程挑战并非无解，社区的优化速度远超想象。

MCP 正在长出 CLI 给不了的能力

除了修补短板，MCP 还在进化出一些全新的、从架构上就超越了 CLI 模式的能力。

首先是 MCP Apps。工具可以返回交互式 UI 组件，如图表、表单或仪表盘，并直接在对话界面中渲染。想象一下，当你让 Agent 分析数据时，它返回的不是枯燥的文字，而是一张可交互的图表。这种富交互体验，只能返回纯文本的 CLI 是无法提供的。Anthropic 透露，集成了 MCP Apps 的 Server，其用户留存率有显著提升。

其次是 Elicitation（征询）机制。工具执行可以在中途暂停，主动向用户请求更多信息。例如，Agent 帮你预订酒店，到了支付环节，MCP Server 可以弹出一个表单让你确认价格和房型，甚至引导至支付页面完成认证。这种“执行中交互”的能力，是 CLI 同步、线性的执行模式无法实现的。

最后是标准化的企业级安全能力。MCP 最新协议版本标准化了 OAuth 客户端注册，大幅简化了首次授权流程。在 Managed Agents 中引入的 Vault 机制，允许用户一次授权后，Token 便能在所有会话中安全地自动注入和刷新。反观 CLI 世界，认证通常依赖于磁盘上的凭证文件，环境一变就可能失效，在安全性和便捷性上完全无法与这套体系相提并论。

可以看到，MCP 并非在原地等待被替代，而是在向“富交互”和“企业级就绪”的方向快速进化。在这些赛道上，CLI 并无招架之力。

真正的关系：不是替代，是分工

客观来看，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 通常是更优解。完备的本地环境让 CLI 的简洁性优势得以充分发挥，无需引入额外的协议层。

对于云端 Agent（如 Web 应用、API 服务、移动端集成）：Skills + MCP 则成为最优路径。缺乏本地执行环境使得 CLI 方案失效，而 MCP 的标准化协议恰恰解决了远程连接和安全认证的难题。此外，MCP 的“一次编写，多处可用”特性（同一 Server 可被 Claude、CodeX、Cursor 等多种客户端使用），在需要对接多服务的云端场景下价值巨大。

因此，“Skills 将干掉 MCP”的论调，本质上是将“本地场景下 CLI 更简洁”这一局部正确结论，过度泛化成了全局判断。这类似于当年“80%的 App 将被取代”的预言，都是将特定场景下的趋势误读为普适规律。