给 AI 智能体装技能：一次搞懂 Skills、CLI 和 MCP 的分工

今天在给自己这个博客项目加 skills 的时候，遇到一个真实的困惑：给智能体扩展能力，既可以通过 CLI（命令行脚本）让它执行，也可以走 MCP，那 skills 又是什么？三者看起来都在"让 AI 能干活"，但实际分工完全不同。

折腾了一圈，总算理清了。这篇文章先用一句话给出结论，再用这个博客项目的真实案例把三者的分工讲清楚。

一句话结论

• CLI 是工具本身——一个可以被直接执行的程序；
• MCP 是标准插座——一套让工具被 AI 发现的协议；
• Skills 是使用说明书——一份教 AI「什么时候用、怎么用」这些工具的文档。

三者不是替代关系，而是协作关系：Skills 教 AI 用工具，CLI 和 MCP 是工具的两种暴露方式。

CLI：最古老也最直接的工具形态

CLI（命令行工具）就是一个能在终端里跑的程序。这个博客项目里就有一个现成的例子——提交文章草稿的脚本：

node .agents/scripts/agent-api.js POST /api/agent/articles .agents/tmp-payload.json

智能体通过 Bash 工具执行它，就能把文章提交到博客后台。它的特点很鲜明：

• 优点：零依赖、零协议，只要能跑命令行就能用，写个脚本就完事；
• 缺点：智能体天然不知道它存在。每次要用，得有人告诉它"有这么个脚本、参数长什么样"，或者让它自己去 --help 里翻。

换句话说，CLI 工具的能力是被动的：它躺在那里，等 AI 来发现。

MCP：给工具装上"标准插座"

MCP（Model Context Protocol）解决的就是"发现"问题。它把工具包装成一个常驻服务，智能体启动连接时就能拿到一份结构化的工具清单：有哪些工具、每个工具叫什么、接收什么参数、返回什么——全部有 schema 描述。

比如本机装的 kimi-cu-win 插件，通过 MCP 暴露了 js、js_reset 等工具，我可以像调用函数一样直接用它操作 Windows 桌面，不需要先去读任何文档。

打个比方：

• CLI 像是裸线头——能通电，但你得知道哪根接哪根；
• MCP 像是 USB-C 接口——插上去，设备自动告诉你它是什么、支持什么。

代价是要多一层服务进程和协议开销，适合高频、结构化的调用场景。

Skills：本身不干活，但决定活干得好不好

Skills 最容易被误解。它不是代码、不是工具，就是一个 SKILL.md 文件，用自然语言写给 AI 看的"SOP 操作手册"：什么时候触发、分几步做、有什么坑要避。

这个项目里的 write-blog skill 就是个典型例子。它规定了我写文章草稿的完整流程：

1. 先拉取未使用的碎片笔记；
2. 围绕笔记写成结构化文章，同步生成 X 推文串和小红书笔记；
3. 必须用项目自带的 CLI 脚本提交（防止 Windows 命令行把中文搞成乱码）；
4. 提交后必须回拉一次做乱码自检。

注意第 3 步——skill 在指导 AI 使用 CLI 工具。这条经验（"curl 在 Git Bash 下会把中文按 GBK 编码发出去，入库即乱码"）是踩坑踩出来的，写进 skill 后，任何智能体下次接手都不会再犯。

这就是 skills 的核心价值：把人的经验和流程沉淀下来，让 AI 每次都能正确地使用工具。

三者对比

实战：这篇文章就是这么写出来的

最有意思的是，你现在读的这篇文章，本身就是三者协作的产物：

• Skills：write-blog skill 告诉我完整的写作与提交流程；
• CLI：agent-api.js 脚本负责把草稿安全地 POST 到博客后台；
• MCP：如果哪天博客后台把接口封装成 MCP server，连 CLI 脚本都可以省掉，我会直接调工具提交。

怎么选？

我的经验是三条：

1. 一两百行能搞定的内部脚本 → CLI 就够了，别过度设计；
2. 要被反复调用、参数结构复杂的外部能力 → 封装成 MCP server，让 AI 自助发现；
3. 不管用哪种 → 都值得写个 skill，把"什么时候用、怎么用、有什么坑"记下来。工具会过时，经验不会。

工具决定 AI 能做什么，skills 决定 AI 做得对不对。这大概就是"给 AI 装技能"这件事的全貌了。