MCP 还是 Skills？AI 智能体工具扩展方案怎么选

作者：彭明航（青云制作）

如果你跟我一样在折腾 AI 智能体，迟早会遇到一个灵魂拷问：给 Agent 装工具，到底用 MCP 还是 Skills？

这俩看起来都在干同一件事 —— 让 AI 能干更多活。但实际上定位、架构和使用场景完全不同。这篇文章聊聊我的理解和选型思路。

一、MCP 是什么

MCP（Model Context Protocol）是 Anthropic 在 2024 年底开源的一套协议规范，你可以把它理解成 AI 世界的 USB-C 接口。它的核心思想很简单：如果每个 AI 应用都自己去对接数据库、API、文件系统，那代码得写死。干脆定一个标准协议，工具提供方按协议暴露能力，AI 宿主按协议调用，大家解耦。

技术上，MCP 是一个客户端-服务端架构，底层走 JSON-RPC 2.0。一个 MCP Server 可以暴露三类东西：

Tools：模型可以调用的函数，比如查数据库、发邮件、读文件
Resources：模型可以读取的数据，比如文档、知识库、实时行情
Prompts：预定义的提示词模板

传输层支持两种方式：stdio（本地进程通信）和 HTTP+SSE（远程调用）。你可以在本地启动一个 MCP Server 进程，也可以连一个跑在云端的服务。

关键特性：动态发现。Agent 启动时连上 MCP Server，Server 会把自己有什么能力全报给 Agent，不需要提前配置。这意味着换一个 MCP Server，Agent 就能获得完全不同的能力，而 Agent 本身的代码一行不用改。

目前 MCP 的生态发展很快，社区贡献了上千个 Server，覆盖数据库、搜索引擎、浏览器自动化、云服务等各种场景。

二、Skills 是什么

Skills 是另一种工具扩展思路，以 Hermes Agent 和 Cursor 的 skill 机制为代表。它的核心是 Markdown 文件 + 目录约定。

一个 Skill 本质上是一个文件夹，里面包含：

SKILL.md：YAML 头信息 + Markdown 正文，描述这个 Skill 是干什么的、什么时候触发、具体怎么干活
scripts/：可以直接执行的 Python/Bash 脚本
references/：按需加载的参考文档，比如 API 文档、数据库 Schema
assets/：模板文件、图片等静态资源

Skills 采用渐进式加载。Agent 启动时只加载每个 Skill 的元数据（名称 + 描述，总共几十个词），当用户的请求触发了某个 Skill 时，才加载完整的 Markdown 指令。如果指令里引用了某个参考文档，再按需读取。这套机制保证了即使装了几十个 Skills，也不会撑爆上下文窗口。

Skills 的本质是什么？把领域知识和工作流程写进了系统提示词里。它不跑独立进程，没有网络通信，就是 Agent 在思考时多了一段"按这个手册来干活"的指令。脚本虽然可以执行，但也是 Agent 决策后临时调用，不是常驻服务。

三、核心差异对比

我把两者的差异拆成几个维度讲清楚。

3.1 协议 vs 文件

这是最根本的区别。

MCP 是一套协议。定义了客户端和服务端之间怎么握手机制、传输什么消息、是什么格式。加入一个 MCP Server 需要支持 JSON-RPC、实现标准的生命周期方法（initialize、tools/list、tools/call 等）。
Skills 是一套文件约定。它没有协议层，没有消息格式，就是 Agent 启动时扫描某个目录下的 Markdown 文件，把内容拼进系统提示词。

打个比方：MCP 是 USB 协议，Skills 是产品说明书。插 USB 设备能直接工作，看说明书能知道怎么手动操作。

3.2 动态 vs 静态

MCP 的能力是动态获取的。Agent 连上 Server 后，Server 可根据实际连接的数据源动态生成工具列表。比如数据库 MCP Server 自动根据表结构暴露查询工具。Server 端更新，Agent 端自动获得新能力。
Skills 的能力是静态定义的。能干什么全写在 Markdown 里，想加新功能得改文件。好处是直观可控，坏处是无法根据运行时状态动态变化。

3.3 部署方式

MCP Server 是独立进程。你需要启动一个 Server 进程（Python、Node、Go 都行），配置好传输方式，然后 Agent 连上它。这意味着有进程管理、端口管理、依赖管理的额外成本。一个 Server 挂了，对应的工具就不能用了。
Skills 就是文件。丢到指定目录，Agent 启动时自动加载。没有进程要维护，没有网络要调试，git clone 下来就能用。部署成本几乎为零。

3.4 状态管理

MCP Server 可以维护状态。因为它是一个长生命周期的进程，可以在内存里缓存数据库连接、保持登录会话、维护 WebSocket 连接。这对于需要持久化上下文的场景（比如连续多轮操作同一份数据）很重要。
Skills 无状态。脚本执行完就结束了，下次调用重新来。虽然简单，但很多场景下也够用。

3.5 共享与复用

MCP 天然支持跨 Agent 共享。同一个 Server 可被多个 Agent 同时连接，甚至可以部署成云服务团队共用。
Skills 更适合个体复用。通过 git 仓库分享，每个 Agent 各自加载副本。好处是隔离性好，互不影响；坏处是没法集中管理和热更新。

3.6 上手成本

MCP 门槛高。你得理解 JSON-RPC、实现协议接口、处理双向通信。虽然官方有 SDK，但调试一个 MCP Server 比调一个脚本复杂不少。
Skills 门槛极低。会写 Markdown 就能创建 Skill，五分钟出活。复杂一点的场景配上 Python 脚本也够用。

四、选型建议

没有银弹，只有适合的方案。我给几个具体的选型思路：

选 MCP 的场景

需要实时数据。比如实时股价、天气、数据库查询——数据在变化，每次调用都要拿到最新结果。MCP Server 保持连接，比每次启动脚本效率高得多。
需要维护状态。比如浏览器自动化（需要保持页面会话）、数据库连接池、WebSocket 长连接。这些东西 Skill 脚本很难做。
需要跨 Agent 共享。你有多个 Agent 实例跑在不同地方，但它们都要用同一个工具集。部署一个中心化的 MCP Server，比每个 Agent 都维护一套脚本省心。
生态已经有现成的。你想接 GitHub、Notion、Slack，社区已经有高质量的 MCP Server，直接装就能用，不需要自己从头写 Skill。
需要动态工具生成。工具的列表和参数取决于运行时的状态，MCP 的 list_tools 可以在每次查询时动态返回，Skill 做不到。

选 Skills 的场景

领域知识和工作流程。比如"写一篇符合某公司风格的周报"、“按某套规范做代码审查”。这些是知识，不是工具接口，写成 Skill 就是最好的形式。
快速原型和实验。有个想法想试试，写个 Skill Markdown 十分钟搞定。用 MCP 的话光搭框架就得半天。
静态参考文档。API 文档、数据库 Schema、公司政策——这些东西最适合放在 Skill 的 references 目录下，Agent 按需读取，不占上下文。
单人单机场景。你就在本地用一个 Agent，不需要考虑分布式，Skills 简单够用。
git 驱动的工作流。你的工具配置需要版本管理、Code Review、CI/CD，Skills 作为纯文本文件天然兼容这些。