AI Agent三宝“CLI、MCP、Skill”如何选

最近 IBM Technology 出了一期视频，比较 AI Agent 分别用命令行和 MCP 做同样的事，看谁表现好。结论挺有意思：简单的文件操作和 Git 命令行赢，抓渲染过的网页 MCP 赢。

但看完之后我一直在想一个问题：这两种方式好像都没覆盖到我实际用 Agent 时最依赖的那个——Skill。

今天把这三种方式放在一起聊聊。

先快速过一下这三个

CLI 就是命令行。Agent 跑 cat、grep、curl、git 这些，跟你我在终端里敲的一模一样。模型在训练时已经见过海量命令行示例，对这些命令的参数、用法烂熟于心，不需要额外说明。

MCP（Model Context Protocol）是 Anthropic 2024 年底发布的开放协议。专门的服务器对外暴露一组结构化工具，每个工具有名字、有说明、有 JSON schema。Agent 想用就调。

问题是，所有工具的 schema 在对话开始时就全塞进上下文窗口了。Martin Keen 测试的 GitHub MCP 服务器大约有 80 个工具，全部加载大概 55,000 个 token。你可能只需要其中一两个，但得把 80 个的说明书全带上。

Skill 本质上是一份操作手册。一个 markdown 文件，里面写着：什么场景下用、具体怎么操作、有哪些坑、怎么验证结果。

举个例子。我有一个 Skill 叫 youtube-subtitle-research，内容大概是这样的：去 YouTube 搜某个关键词，筛选最近 24 小时的视频，下载字幕，去重处理，然后分析内容。里面写了具体用什么命令、文件存哪个路径、日期过滤为什么要做两遍、哪个 Python 脚本处理字幕效果最好。

这些知识不是模型训练数据里的。是我自己跑过几次之后，踩了坑，总结出来的。

三者的区别

说说我的理解：

CLI — 模型脑子里已有的知识。零额外开销，但只能干命令行本身能干的事。比如 grep -n agent *.md，模型不需要任何人教就知道怎么用。

MCP — 外挂的结构化接口。适合命令行搞不定的事（渲染 JavaScript 网页、调需要认证的 API），但每个工具的 schema 都要占 token，不管你用不用。

Skill — 外挂的程序性知识。不是告诉模型”有这个工具”，而是告诉模型”这件事怎么做”。里面可以包含 CLI 命令、MCP 调用、甚至其他 Skill 的引用。按需加载，不用的时候不占空间。

打个比方。CLI 是你会开车。MCP 是车上装了全套导航系统，80 条预设路线全加载好。Skill 是副驾坐了个老司机，到了特定路口才开口说”这个路口得走辅路，主路在修”。

视频中的三个实验，Skill 能插在哪

实验一：读文件 + 搜关键词

Agent 要读一个 markdown 文件，再搜另一个文件里有没有”agent”这个词。

CLI 方案：cat notes.md + grep -n agent *.md。两条命令搞定。

MCP 方案：调文件系统服务器的 read_file 和 search_files。也完成了，但 13 个工具的 schema 全加载了，只用了 2 个。

这个场景太简单了，不需要 Skill。

实验二：Git 操作

CLI 方案：git log --oneline -10 + git status。模型对 Git 熟得很。

MCP 方案：GitHub MCP 服务器，80 个工具，55,000 token。

这个场景如果加个 Skill 呢？假设你有个 git-workflow 的 Skill，里面写着”检查状态前先 fetch 一下远程”、”如果在 feature 分支上，顺便看一眼 main 有没有新提交”、”提交信息用 conventional commit 格式”。这些是你的团队规范，不是 Git 的通用知识。模型会用 Git，但不会自动遵守你们团队的约定。

Skill 补的就是这个缺口。

实验三：抓网页

MCP 方案：调了一个带无头浏览器的 MCP 服务器，加载页面、渲染 JavaScript、转成文本。250 token，几秒钟。

CLI 方案：curl 拿到的是 Next.js 的 JavaScript 骨架，不是渲染后的内容。Agent 花了好几分钟尝试各种办法，写 Python 脚本逆向工程 Next.js 的数据格式，最后勉强搞定。2000 多 token，大量本地计算。

这个场景 MCP 赢得毫无悬念。但如果我经常要抓网页做内容分析，我会写一个 Skill：什么类型的页面用什么方式抓、碰到 SPA 怎么处理、抓回来的内容怎么清洗、存到哪个目录、文件命名规则是什么。下次 Agent 再碰到类似任务，加载这个 Skill，直接走最优路径，不用每次都重新摸索。

Skill 的真正优势：上下文按需加载

MCP 最被诟病的一点是”不管你用不用，schema 全塞进去”。80 个工具，55,000 token，对话还没开始上下文窗口已经胖了一圈。

Skill 不一样。它是按需加载的。Agent 根据当前任务判断”这个场景可能需要哪个 Skill”，然后才去读。用完就完，不常驻。

一个典型的 Skill 文件大概 2,000 到 10,000 字符。只在需要的时候出现。而且 Skill 里面可以组合着用——引用 CLI 命令、调用 MCP 工具、甚至调用其他 Skill。它不是一个新层级的工具，而是在 CLI 和 MCP 之上的”怎么做”的知识层。

Skill 的另一个好处：会进化

CLI 命令是操作系统定的，你改不了。MCP 服务器的 schema 是开发者写的，你也不太好动。

Skill 是你自己的 markdown 文件。踩了坑？加一行注意事项。发现更好的做法？改掉旧的步骤。Hermes Agent 甚至有个自动管理功能，每隔几天给你的 Skill 库做一次体检：合并重复的、删掉过时的、给每个 Skill 打分。

模型本身也会在对话结束后自动回顾，把新学到的东西更新到 Skill 里。上个月我搞 YouTube 字幕下载的时候，第一次跑日期过滤出了 bug，修好之后 Agent 自己把修法写进了 Skill。下次再跑同样的任务，直接走正确路径。

这种”经验沉淀”是 CLI 和 MCP 都做不到的。

那到底该用哪个？

不是非此即彼。但我想把范围扩大一点：

命令行能搞定的事，用命令行。零开销，模型本来就会。

命令行搞不定的事（渲染网页、调需要认证的 API、对接第三方服务），上 MCP。代价是 token，但换来的是能力边界扩展。

需要特定流程、团队规范、踩坑经验的事，用 Skill。代价是初次编写的时间，换来的是以后每次都能走最优路径。

三种方式不是竞争关系，是分层的。CLI 是地基，MCP 是扩展件，Skill 是操作手册。最好的 Agent 三个都有，根据场景自己选。

说到底，如果你的 Agent 开始逆向工程一个 JavaScript 框架就为了读一个网页，那大概率是选错了工具。如果你的 Agent 每次做同一件事都要重新摸索一遍，那大概率是缺一个 Skill。