最近看到越来越多的声音在说“MCP 已经过时了，CLI + Skill 才是未来”。这个论调传播得很快，但我感觉这个二元对立本身就是个伪命题。MCP 确实有设计上的缺陷，Skill 在大多数场景下也确实更优雅，但把它们对立起来，营造一种”MCP 完全不能用”的氛围，是不准确的。
要聊清楚这件事，得先回到一个更本质的问题：我们围绕 AI Agent 做的这一系列工作，核心都是在做什么？
管理上下文。
保证 AI 的上下文干净、强相关。MCP、Skill、CLI，都是对这个核心问题的不同解决方案。理解了这一点，后面的讨论就不会跑偏。
MCP 到底出了什么问题
MCP 本质上是 Function Call 的标准化。它解决了一个真实的问题：之前每个 Agent 框架都有自己的工具调用协议，MCP 把这个 N×M 的对接问题简化成了 N+M。这个价值是实在的。
但它也继承了 Function Call 的核心缺陷：全量加载。只要你接入了一个 MCP Server，不管你当前的任务用不用得上，所有工具的描述都会被塞进 AI 的上下文。
MCP 的生态其实非常繁荣，常见的软件几乎都提供了 MCP 支持，但繁荣不代表质量。
不是每个实现 MCP Server 的人都能认识到全量加载的问题。于是你能看到各种臃肿的 MCP Server，一个 Server 里塞几十个 Tool，只要装上就会永久占用上下文。这就好像你让一个脑容量本来就有限的人，在干任何活之前都先背一遍一份不一定用得上的完整接口文档。
所以 MCP 是不是完全不能用？也不是。那种高频触发、工具集精简的 MCP Server，使用体验依然很好。不能因此就给协议本身判死刑。
Skill 的核心：渐进式披露
Skill 解决的问题和 MCP 一样，都是让 AI 能够获取和使用外部能力。但它在信息加载策略上做了根本性的改变：不一次性给 AI 所有信息，而是只提供索引，让 AI 按需逐层加载。
举个具体的例子。假设我们要让 AI 能操作 Notion，需要查询、搜索、新建、编辑、移动、删除等一系列能力。
用 MCP 的方式，这一堆能力的完整调用指南会在你接入的那一刻全部进入上下文。后续哪怕你在做一个完全不涉及文档的任务，这些内容也一直在那里占着位置。
用 Skill 的方式，一开始 AI 只会读到 SKILL.md 文件头里的一句话：“用于与 Notion 交互，当需要查询、搜索、编辑等文档操作时使用该 Skill。“就这一句。当 AI 判断当前任务确实需要操作文档时，才会加载 SKILL.md 的完整内容。而 SKILL.md 里我们还可以再做一层拆分：把每个功能的使用指南拆成独立文档放在 references 目录下，比如获取文档.md、搜索文档.md、编辑文档.md。SKILL.md 本身只保留描述和对这些文档的索引。现在 Notion 这样的在线文档功能越来越强大，通过 API 编辑文档的复杂度也水涨船高，而编辑和查询的使用频率又明显不同，这种拆分是非常有必要的。
这样 AI 就是一层一层地主动获取自己需要的信息，而不是被动地接收一堆可能用不上的东西。
Skill 能做的也不只是工具调用。很多时候我们用它来做「专家知识」的渐进式加载：不同领域的知识库、一套标准的工作流 SOP、甚至是写作风格指南。这些纯文本的技能同样受益于按需加载的机制。
回到本质：这些都是上下文管理的标准化
这里我们需要明确下：MCP 和 Skill 都不是什么颠覆性的新技术。
没有 MCP，我们用 Function Call 一样能做工具调用，只是每个框架各搞一套。没有 Skill，我们也可以通过一个 md 文件引用另一个 md 文件来让 AI 做渐进式读取。我之前甚至用 MCP 来实现过类似的渐进式披露效果：一个 MCP Server 里放一个专门用于加载详细使用文档和知识库的 Tool，其他几个 Tool 提供基础交互能力。先加载索引，再按需加载详情，思路是一样的。其实 MCP 协议本身也设计了 Prompt 和 Resource 的动态加载能力，通过这个能力是可以实现渐进式披露的。但大部分 Agent 工具至今只支持了 Tool 调用，MCP Server 实现了也没用。
当然即便都支持了，通过 MCP 绕路实现的渐进式披露终归不如 Skill 这样原生支持来得优雅。
它们的价值在于标准化，而不是能力本身。先有了这些实践，才总结为了标准。核心问题始终是同一个：如何保证 AI 上下文的干净和强相关性。理解了这一点，就不会陷入”谁取代谁”的无意义争论。
CLI 的复兴不是偶然
在 Skill 之外，另一个明显的趋势是 CLI 的复兴。这不是偶然的，从两个方向可以理解：
第一，AI 的训练数据里包含了大量的 shell 命令用例。CLI 对 AI 来说几乎是母语级别的工具接口，它对各种命令行工具的熟悉度是概率性地内化在模型里的。AI 天然就很会用 shell 来编排、组合、完成任务。
第二，CLI 天然支持渐进式披露。几乎所有 CLI 工具都有 --help，这就是自带的使用说明。AI 只要知道有这个 CLI 可以用，你甚至不用告诉它怎么用，它自己 --help 一下就能摸索出来。这一切简直浑然天成。
现在常见的最佳实践是：CLI 提供基础能力，Skill 作为 CLI 的简要使用文档和触发入口，两者配合使用。CLI 负责”能做什么”，Skill 负责”什么时候该用、怎么用好”。
怎么做好 Skill 和 CLI
讲完了各自的优势，再从上下文管理的角度来看看怎么把它们做好。
Skill：描述决定一切
Skill 和 AI 交互的第一步是 frontmatter 里的描述。AI 根据这一两句简短的描述来决定要不要触发这个 Skill。这个描述极为重要，写得不好，里面的内容再好、相关性再强，AI 没有选择它，什么都没有。
描述不是对 Skill 的概述，让 AI 来猜和当前任务的相关性。而是应该明确地告诉 AI：什么时候应该使用这个 Skill。“用于处理文档操作”不如”当需要查询、搜索、编辑 Notion 文档时使用”来得直接。
同时要尽量避免定位模糊、和其他 Skill 对某一任务有类似能力的情况。Skill 之间职责重叠会导致误触发，和 CLI 命令之间职责重叠导致 AI 选错是一样的问题。
其次是内容。内容应该聚焦和稳定，对于工作流类的 Skill，需要明确输入输出，而不是让 AI 自由发挥。
由此可以从两个维度来评估和迭代一个 Skill：不同任务下触发稳不稳定、输出结果质量如何。Anthropic 开源的 skill-creator 这个用来创建 Skill 的 Skill 内置了评估能力，可以用它来持续优化。
CLI：遵循最佳实践，不要创造新协议
AI 能用好 CLI 的前提是你的 CLI 工具符合最佳实践。一旦你发明了新的交互协议，训练数据里没有，AI 对 CLI 的所有先验优势就全没了。老老实实用标准的 CLI 范式，这些东西已经被验证了几十年。
--help 是 AI 做渐进式披露的关键入口，所以每一个命令、每一个子命令都必须有 --help 支持，提供清晰的使用指南。
还有一个容易被忽略的点：为返回结果提供 JSON 格式支持。AI 非常擅长使用 jq 来处理 JSON 数据，有了 JSON 输出，AI 就可以用管道把一连串工具调用串联起来，中间过程产生的临时数据不需要进入上下文，直接在管道里流转。这又回到了上下文管理的核心问题：减少不必要的信息进入上下文。我个人的习惯是提供 --format 参数来支持 json、plain、table 等不同格式的返回，满足不同场景的使用需求。
回到最开始的问题。MCP 过时了吗？没有，它在适合的场景下依然好用。Skill 也不是银弹，它只是在上下文管理上提供了更优雅的方案。这些方案之间不是互相取代的关系，而是在不同的时间点、从不同的角度，对”如何管理好 AI 的上下文”这个核心问题给出的答案。与其争论谁取代谁，不如想清楚在你的场景下，怎么把它们组合好。