从困惑到理解：我关于 MCP、Skill 和 CLI 的探索之旅

技术核心定位适用场景Skill用户主动加载的提示词增强包特定场景的提示词优化，固定流程MCP模型自主调用的外部工具协议需要精细权限控制、多步状态管理CLI人与 AI 都能用的标准接口通用操作、调试透明、成本敏感MCP 不会“死”，但它正在回归到最擅长的位置：需要精细权限控制、多步状态管理、或封装复杂内部系统的场景。CLI 正在成为 AI 与外部世界交互的默认界面，因为它省钱、省心、好调试、无上限、

sbcl

480人浏览 · 2026-04-02 10:13:24

sbcl · 2026-04-02 10:13:24 发布

从困惑到理解：我关于 MCP、Skill 和 CLI 的探索之旅

前言

最近在接触 AI 编程的过程中，我遇到了几个让我困惑的问题：为什么 MCP（Model Context Protocol）会占据那么多上下文？为什么不能像 Skill 那样渐进式披露？Skill 和 MCP 到底有什么区别？为什么大家都开始做 CLI 工具甚至宣称要放弃MCP了？带着这些问题，我开始了探索之旅。

这篇文章记录了我的思考和理解，希望能帮助到有同样困惑的开发者。

一、MCP 为什么会占据大量上下文？

我的困惑

刚开始使用 Claude Desktop 配合 MCP 时，我发现对话没多久上下文就快满了。明明没聊几句，怎么 Token 消耗这么快？

探索发现

经过了解，MCP 的上下文消耗主要来自三个方面：

1. 系统提示词的隐性膨胀

MCP 客户端为了告诉模型“你能用哪些工具”，会在每次对话的系统提示词中，把所有 MCP 服务器的工具定义都塞进去。一个工具的 JSON schema 可能就占几百 Token，如果同时启用 5 个服务器，光工具列表就可能消耗 5000-15000 Token。

2. 工具调用的往返消耗

每次调用 MCP 工具，调用时的参数和返回的原始数据都会永久留在对话历史中。如果某个工具返回了超长的日志或大量数据，上下文会迅速膨胀。

3. 全量加载的设计哲学

MCP 的设计目标是要让模型拥有“完整的能力认知”，这样模型才能自主决定何时调用哪个工具。但这种“全量加载”的设计，确实带来了不小的上下文开销。

二、为什么不用类似 Skill 的渐进式披露？

我的困惑

既然 MCP 的上下文开销这么大，为什么不学 Skill 那样按需加载？用户需要什么工具，再加载什么工具，不是更合理吗？

探索发现

Skill 和 MCP 的定位不同

Skill 是为特定场景设计的，工具数量有限（通常 ≤10 个），而且是用户主动触发才加载，天然适合渐进式披露。

MCP 的目标是成为通用协议，需要在启动时告知模型“你能用哪些能力”，因为 LLM 本身是无状态的，不提前注入，模型根本不知道有哪些工具可用。

LLM 调用范式的限制

当前主流 LLM 的函数调用机制要求：所有可用工具必须在请求时完整声明。API 不支持“先告诉模型 10 个，等模型问再补充”。模型不会主动问“还有别的工具吗”。

Skill 为什么能做到渐进式披露

Skill 的本质是提示词工程 + 工作流编排：

在客户端侧做条件加载，检测到特定命令才注入相关工具
利用上下文注入而非原生 function calling
场景封闭，不需要让模型“知道所有技能”

三、Skill 和 MCP 的区别与优缺点

核心定位差异

维度	Skill	MCP
本质	提示词工程 + 工作流编排	标准化协议 + 客户端-服务器架构
目标	为特定场景封装能力包	让模型安全、统一地访问外部工具
触发方式	用户显式调用	模型根据上下文自主决定
生态范围	绑定特定客户端	跨客户端、跨模型的标准协议

Skill 的优缺点

优点：

上下文友好，只在激活时注入
用户体验直观，用户主动控制
实现简单，无需搭建服务器
高度定制，可针对场景深度优化

缺点：

无法调用外部工具（纯提示词版）
生态割裂，无法跨平台复用
扩展性受限，新增能力需客户端更新
模型自主性差，必须用户触发

MCP 的优缺点

优点：

真正的工具调用能力
生态统一，同一服务器可被多客户端使用
用户可扩展，任何人都可编写服务器
模型自主决策

缺点：

上下文开销大
复杂度高，需要运行独立进程
安全风险，需配置权限控制
延迟增加，涉及进程间通信

四、CLI vs MCP：为什么 CLI 更受欢迎？

我的困惑

我注意到飞书、钉钉、GitHub、数据库这些服务，很多都同时在提供 MCP Server 和 CLI 工具。而且 Perplexity CTO 公开表示放弃 MCP 转向 CLI，Y Combinator 总裁也说“MCP sucks”。为什么 CLI 这么受欢迎？

探索发现

CLI 的三大优势

1. 上下文成本几乎为零

MCP 启动前就要消耗 5000-15000 Token，而 CLI 模式中，AI 只需要知道命令名称，不提前注入任何 schema。命令执行后，还可以用 jq、grep 在数据进入上下文前就过滤掉大量冗余信息。

2. 可组合性更强

CLI 可以用管道组合命令，在数据进入上下文前完成过滤、转换、聚合。而 MCP 返回什么就是什么，AI 无法在调用后再用管道处理。

3. 可调试性更好

AI 执行 gh pr list，你可以在终端跑完全相同的命令。输入一致、输出一致、错误信息一致。MCP 的调用发生在对话“内部”，需要翻 JSON 传输日志才能调试。

融合方案

行业正在探索的结合方案：

MCP2CLI：把 MCP 工具“翻译”成 CLI 命令
Single-Tool MCP：只暴露一个工具，输入是 Python/JavaScript 代码，一个工具解决所有问题

五、我的总结

经过这一系列的探索，我形成了一些理解：

技术	核心定位	适用场景
Skill	用户主动加载的提示词增强包	特定场景的提示词优化，固定流程
MCP	模型自主调用的外部工具协议	需要精细权限控制、多步状态管理
CLI	人与 AI 都能用的标准接口	通用操作、调试透明、成本敏感