Skills 与 MCP 之争：LLM 工具调用的两种哲学

Mon, 08 Jun 2026 20:57:54 +0800

先说结论：Skills 优于 MCP 不是技术上的碾压，是设计哲学上的胜利。Skills 把 LLM 当成协作对象，MCP 把 LLM 当成函数调用器。这两种思维带来的体验差距，在过去一年里被不断放大。

一、LLM 友好度：Prompt 原生 vs 协议中介

LLM 最自然的交互方式是什么？是文本。给它一段描述，它理解意图，然后输出结果。

Skills 的设计就基于这个事实。一个 Skill 就是一个结构化的 prompt 模板，定义输入、约束行为、规范输出格式。LLM 不需要额外的解析层，不需要理解复杂的协议框架。你告诉它"调用 Skill X，参数是 Y"，它就知道该怎么做。

MCP 相反。它要求 LLM 通过一个标准化的协议层与工具交互。LLM 需要先理解 JSON-RPC 的调用格式，管理工具列表的上下文，处理 response 的结构化解析。这些对开发者来说不算什么，但对 LLM 而言，每次调用都多了一层认知开销。

说具体点。 写一个 Skills 的调用指令，和写一段自然语言描述几乎没有区别。MCP 的调用需要构建完整的 JSON-RPC request body。前者是"帮我把这个文件翻译成英文"，后者是 {"jsonrpc":"2.0","method":"tools/call","params":{"name":"translate","arguments":{"text":"...","target":"en"}}}。

这个差距在短上下文场景下尤其明显。每次调用 MCP 工具，光协议开销就占掉几十个 token。如果你的上下文窗口只有 4K，这一点点差异可能就决定能不能塞下完整的对话历史。而 Skills 的 overhead 几乎可以忽略，因为它不需要额外的协议层。

二、能力覆盖：文本协议的天花板

MCP 的标准化是它的最大优势，也是最大限制。

标准化让所有 MCP 服务器遵循同一套接口规范。好处是客户端可以通用，坏处是你只能做协议能表达的事情。MCP 定义的工具调用范式是 request-response，这天然不适合流式输出、长周期任务、或者需要 LLM 主动发起多轮交互的场景。

Skills 没有这个限制。因为 Skills 就是文本描述，它可以表达任何东西：

流式输出：Skill 可以定义输出格式为流式 token
多轮交互：Skill 可以包含子步骤，每个步骤依赖前一步的结果
条件分支：Skill 可以根据中间结果决定下一步行为
并行执行：Skill 可以同时调用多个子能力

这些不是协议扩展，而是文本定义加上宿主工具的执行引擎支持带来的灵活性。MCP 想做同样的事，就得不断扩展协议规范——而协议规范的演进速度，大家都懂。

三、易用性：零配置 vs 部署成本

用过 MCP 的人应该知道我在说什么。

要跑一个 MCP 工具，你需要：搭建 MCP 服务器、配置传输层（stdio 或 SSE）、处理认证、管理工具注册、处理错误码。每个工具都是一个独立服务。虽然 Anthropic 的 Claude Desktop 简化了本地场景的配置，但一旦涉及远程工具、多工具编排、动态工具发现，复杂度直线上升。

Skills 的体验完全不同。大多数 AI 编程工具的 Skill 体系就是一个文件。写一个 markdown 文件定义 Skill，放到指定目录，就能用了。不需要服务器，不需要配置，不需要部署。

举个例子。 我的 WriteCraft 项目里有 30 多个 Skill，全部是 markdown 文件。新增一个 Skill 只需要 5 分钟，写个定义文件放进去就行。换成 MCP，虽然一个服务器可以暴露多个工具，但每个新场景往往需要维护一个独立的 MCP 服务器实例，从配置传输层到处理认证，复杂度比写一个 markdown 文件高得多。

四、演进速度：文本驱动 vs 协议驱动

这是最关键的区别。

MCP 的演进受制于协议规范本身。虽然 MCP 支持服务器端自定义 capabilities 扩展点，不用每次都改核心规范，但真正的新能力（比如流式传输、长周期任务）仍然需要协议级别的支持。想加一个这种级别的新特性？先讨论 spec、写 RFC、社区 review、发版、等客户端适配、等服务端实现。一套流程下来，半年过去了。而且每次协议变更都意味着所有实现者要同步更新——这不是技术问题，是治理问题。

Skills 的演进速度取决于你写 prompt 的速度。想加一个新能力？写一个 Skill 文件。想改一个能力？改几行描述。没有版本号、没有兼容性矩阵、没有迁移指南。

说到这里，我倒想起一个问题：如果我们今天回头看三年前的 AI 编程工具，还有几个协议活到了现在？

这听起来不够"工程化"。但现实是，在 LLM 能力还在高速迭代的当下，一个下午能迭代 10 个版本的方案，就是比半年发一个版本的方案有竞争力。

五、这不是非此即彼

我并不是说 MCP 没有价值。标准化协议在生态互通、跨平台工具共享、安全边界等场景有不可替代的优势。Anthropic 推 MCP 的出发点，给 AI 工具一个通用接口标准，本身是对的。

Skills 也有明显的短板：它是各工具私有的，无法跨工具复用；没有统一的安全边界和权限模型——一个 Skill 文件可以要求 LLM 执行任意操作，缺少 MCP 那套标准化的审计和认证机制。如果需要在多工具间共享工具链，或者对安全性有严格要求，MCP 的结构性优势就会体现出来。

问题在于时机。当 LLM 的能力和边界还在剧烈变化时，过早标准化等于给演进速度上了锁。Skills 的"松散耦合 + prompt 驱动"模式，恰好适合这个阶段——快速试错、快速迭代，不好用的方案自然被淘汰。

等到 LLM 的能力趋于稳定，工具调用的模式基本定型，那时候再谈标准化也不迟。而到那时，MCP 积累的实践经验反而会让它成为一个更好的协议。

但那是未来的事。今天，Skills 就是更好用的方案。