上章讲到Skill 可以告诉 Agent，一件事情应该按照什么步骤去做、需要参考哪些资料，最后又该怎么检查结果。但如果 Agent 不只是“知道应该怎么做”，而是真的要去调用一个具体的软件呢？
大家应该多多少少都刷到过类似的演示：让 AI 直接创建飞书文档、读取微信读书里的划线和笔记、控制设计软件修改页面，甚至帮你点一杯咖啡。
这些事情以前往往需要我们自己打开软件，一个个点击，或者先把资料复制出来，再粘贴给 AI。现在却变成了，你只需要在对话框里说一句话，AI 就可以自己去读取信息、调用功能，甚至真的创建一份文档、一个任务或者一笔订单。
那么问题来了：AI 为什么突然可以调用这么多软件了？
因为进入大AI 时代了，现在越来越多的软件，都在主动把自己的部分能力开放给 AI，大家经常看到的 MCP 和 CLI CLI，就是其中两种很常见的入口。
可以先粗略理解成：这些软件开发了一些权限，专门留给AI可以直接调用。
那么还是经典三个问题：
MCP 和 CLI 到底是什么？
它们之间有什么区别？
普通人能用到哪些，又该怎么选择？
MCP 和 CLI 到底是什么？
先讲 MCP。
MCP 的全称是 Model Context Protocol，中文一般翻译成“模型上下文协议”。它最早由 Anthropic 在 2024 年提出并开源。
MCP 官方对它的定义是一种开放协议，用来让大语言模型应用连接外部的数据源和工具。
这句话听起来还是有点抽象。再翻译成大白话，其实可以先把 MCP 理解成：一套专门给 AI 连接和调用外部能力的公开规则。
这里最重要的不是“MCP 能连接某一个软件”，而是它规定了一种相对统一的方式，让外面的工具把自己的能力告诉 AI。
比如一个接入了高德地图的MCP 以后，它可以告诉 Agent：” 我这里有“搜索”“查天气”“查询地点”“创建任务”这些工具；这个工具是干什么的，你调用它的时候需要给我哪些信息；执行完以后我又会返回什么。“。
在 MCP 里，一个工具本身就会带有名称、功能描述和参数结构。Agent 因此不只是“知道有一个接口”，而是可以先理解这个工具能干什么、什么时候应该使用、调用时要传什么信息，再结合当前任务自己选择和调用。MCP 官方把这种 Tools 直接定义为可以被模型发现和调用的能力。
比如你对一个 Agent 说： “帮我看看深圳明天会不会下雨，再推荐几个适合下午去的地方。”
如果它连接了相应的天气、地图 MCP，Agent 可以先判断这个任务需要“查询天气”和“地点搜索”，再分别调用对应工具，把得到的结果组合起来回答你。
所以 MCP 最核心的一点并不是“它自己会执行很多事情”，而是： 外部服务可以按照一套统一格式，把自己的能力描述给 AI；AI 理解以后，再自己组合和调用这些能力。
这也是为什么 MCP 特别适合 Agent。
以前每一种工具都有自己的接口和说明方式；MCP 出现以后，大家至少可以按照相近的规则告诉 Agent：“我有什么工具、这个工具怎么用。”
严格来说，MCP 不只有 Tools，还可以提供其他类型的信息。不过对于普通人理解“AI 为什么突然能调用各种软件”这个问题，就先理解 Tools，也就是工具调用这一部分就够了。
然后再说 CLI。
CLI 的全称是 Command Line Interface，中文叫“命令行界面”。
它和 MCP 最大的区别之一就是：CLI 并非是 AI 时代的新技术，它已经在计算机里存在很多年了。
平时我们操作一个软件，最熟悉的方式是用鼠标点击按钮；CLI 则是把这些操作变成一条条文字命令。你输入一条命令，电脑或者软件就按照命令去做。
所以 CLI 可以先非常简单地理解成：不用点按钮，直接通过命令告诉软件做什么。
以前这些命令主要是程序员、运维人员或者自动化脚本在用。而现在 Agent 本身越来越擅长操作电脑、运行终端，它自然也可以直接使用 CLI。
这里就可以拿飞书来举例。
飞书现在提供了官方 lark-cli，而且它的定位非常明确：不仅是给人用，也是专门给 AI Agent 使用的，目前已经覆盖消息、文档、多维表格、日历、邮箱、任务、会议等等
假如你想让 Agent： “帮我新建一份飞书周报，把我今天整理好的内容放进去。”
以前，你需要自己打开飞书，找到文档、新建、复制文字、粘贴进去，有了飞书 CLI 以后，这些操作可以被表示成一条命令。比如飞书有专门用于创建文档的命令，Agent 只需要知道要创建什么、内容是什么，就可以自己在后台运行对应命令，飞书再把创建好的文档结果返回回来。
然后使用流程大概是：你说人话 → Agent 理解你的任务 → Agent 自己生成并执行飞书 CLI 命令 → 飞书完成操作 → Agent 把结果告诉你。
如果你是有在用飞书的，那么飞书的CLI是很好的一个可以马上跟练实操的案例，具体的一些使用可以看看飞书官方的文档：飞书CLI安装与使用指南：让AI Agent真正接入飞书！
所以现在 CLI 又重新变得特别重要，不是因为大家突然开始喜欢命令行窗口了，而是因为：
对于 Agent 来说，文字命令本身就是一种非常直接的操作软件的方式。
不过在讲MCP和CLI区别之前，有一件事得先说清楚。
不管是 MCP 还是 CLI，Agent 最后要做的判断动作，其实是同一件事：要不要调用、调用谁、填什么参数。
这个判断能力，不是 MCP 给的，也不是 CLI 给的，
是模型自己就会——业内管它叫 Tool Use，也叫 Function Calling。
MCP 和 CLI 的区别，只是在"怎么把工具信息喂给这个判断能力"
这一步不一样。
MCP 和 CLI 有什么区别？
看到这里你可能会觉得： 等一下，MCP 和 CLI 不都是让 AI 去调用软件或工具吗？
对，从最终效果来看，它们确实可能完成非常相似的事情。
AI 可以通过 MCP 查数据、创建任务；也可以通过 CLI 查数据、创建任务。真正的区别，不在于"一个能做，一个不能做"，而是：软件用什么方式把自己的能力交给 Agent。
不过在讲区别之前，有一件事得先说清楚。
不管是 MCP 还是 CLI，Agent 最后要做的那个判断动作，其实完全是同一件事：
要不要调用一个工具、调用哪一个、传什么参数进去。
这个判断能力，不是 MCP 给的，也不是 CLI 给的。是模型自己就会——业内管这个能力叫 Tool Use，也叫 Function Calling。
说白了就是：模型看到一个工具的名字和说明以后，自己判断"这个任务用得上它"，然后自己填好参数，生成一份"调用申请"。
注意，是申请，不是执行。模型自己从来不会真的去跑这个工具。它生成完申请之后，真正动手执行的，是你的程序，或者是对方的服务器。执行完了，结果再喂回去给模型，模型才接着往下说话。
所以 MCP 和 CLI 真正的差别，其实只是发生在"申请"这一步之前：软件用什么方式，把工具的信息喂给模型，让模型能做出这个判断。
这也是为什么前面说，MCP 和 CLI 最终效果可能一样，过程却不同——因为它们只是换了一种方式，去支撑同一个判断动作。
CLI 更像是软件给 Agent 一套可以直接执行的文字口令。Agent 需要知道有什么程序、有哪些命令，再生成一条正确的命令执行。
MCP 更像是软件按照统一规则给 Agent 一张结构化的工具菜单。Agent 可以先发现："这里有哪些工具？每个工具干什么？分别需要哪些参数？"再根据当前任务选择其中一个调用。
举个非常简单的例子。
假如一个软件都可以完成“搜索资料”：
CLI 的思路更像：软件告诉你，有一条 search 命令，后面跟关键词就能搜索。
Agent 决定搜索什么之后，直接生成并执行这条命令。
MCP 的思路更像：
软件告诉 Agent：我这里有一个叫“搜索”的工具，它可以搜索资料，需要提供一个“关键词”参数。
Agent 看到工具说明以后，再决定什么时候调用，并把关键词填进去。
最后结果可能完全一样，但是中间的逻辑不同。
| 对比 | MCP | CLI |
|---|---|---|
| 本质 | AI 应用连接外部能力的一套开放协议 | 用文字命令操作程序的一种传统接口 |
| 软件怎样提供能力 | 把能力描述成结构化工具 | 提供一条条命令 |
| Agent 怎么理解 | 可以直接看到工具名称、描述和参数 | 需要知道命令，或通过帮助文档、Skill 等了解 |
| Agent 怎么执行 | 选择 Tool 并传入参数 | 生成命令并在终端执行 |
| 最初为谁设计 | 主要面向 AI 应用与工具连接 | 最初给人和脚本使用，现在 Agent 也非常适合 |
| 常见优势 | 标准化、工具发现方便 | 直接、成熟，特别适合本地和批量操作 |
所以千万不要把 MCP 和 CLI 理解成“上层和底层”，或者“联网的叫 MCP、本地的叫 CLI”。
MCP 也可以调用本地工具，CLI 也完全可以操作云端的软件。比如飞书 CLI 最后操作的就是云端飞书服务。
它们真正的区别还是那句话：MCP 给 Agent 一套结构化工具，CLI 给 Agent 一套可以执行的命令。
而且它们并不互相排斥。
像 Claude Code、Codex 这类本来就能操作终端的 Agent，可以大量调用各种 CLI，同时也完全可以连接 MCP。一个软件也可以同时提供 MCP 和 CLI，让不同的 Agent 自己选择更适合的入口。
真正用的时候，MCP、CLI 和 Skill 到底该怎么选？
讲到这里，可能还有一个更现实的问题。
因为我们真正去使用这些服务时，往往不是只看到一个入口。
有一些平台会同时给你 MCP、CLI，甚至还会再放一个 Skill。这时候对于普通人来说反而更懵了：我只是想让 AI 用一下这个软件，为什么一下有三个东西？到底装哪个？
这里我以知乎的搜索接入为例子
知乎数据开放平台现在已经把搜索、知乎直答、热榜这些能力开放给 AI，官方公开介绍里支持 Skills、API、MCP 等不同调用方式；近期知乎也推出了面向 Agent 使用的 Zhihu CLI，并配套提供 Skill，让 Agent 可以完成安装、配置，再调用 CLI 搜索知乎、看热榜、调用直答或者读取自己的知乎数据。
甚至瑞幸都有AI 开放平台上线时直接写明支持 MCP、CLI、Skill 多种接入方式：MCP 用来把点单服务接给 AI，CLI 可以通过命令调用来点咖啡！（虽然很鸡肋）
所以你以后很可能会越来越频繁地看到各种软件都会开放起 MCP、CLI、Skill，就是跟上 AI 时代，让 Agent 也能进行部分操作
那么对于我们普通用户而言，这三个形式怎么选择呢？
| 接入方式 | 可以先怎么理解 |
|---|---|
| MCP | 把软件的一组结构化工具接给 Agent |
| CLI | 把软件的一组命令交给 Agent 执行 |
| Skill | 把这个软件应该怎么用、什么时候用、按照什么步骤用，教给 Agent |
但这里有个很重要的点：这三个东西看起来并排放在官网上，并不代表技术上也是完全平级的三条路。
尤其是 Skill。
上一篇我们讲过，Skill 更像一份给 Agent 看的说明书和工作流程。它本身不一定负责连接软件，底下仍然可能继续调用 MCP、CLI、API，甚至直接运行脚本。
知乎的例子就非常典型。
你安装它的 Skill 以后，并不是说 Skill 突然变成了另一套“知乎接口”。更像是你把一份知乎操作指南交给 Agent：这里告诉 Agent CLI 怎么安装、怎么认证、搜索知乎应该调用什么命令、遇到不同任务该怎么处理，最后真正去拿知乎数据的，仍然是底下的 CLI 和开放平台能力。
如果官方已经把 Skill 做得很完整，而你用的 Codex、Claude Code、WorkBuddy 这类 Agent 又支持 Skill，那么直接装官方 Skill，很多时候反而最省事。因为你不用自己研究“这一条命令怎么写”“这个 MCP 工具什么时候该用”，Skill 已经把这些经验告诉 Agent 了。
大白话来说就是：Skill更适合普通用户，利用Agent使用
像微信读书官方就只出了skill的形式
（不过这里微信的用到的不是mcp也不是cli，而是API的形式，api就是咱们下篇要讲到，这里就不展开了）
但这并不意味着：Skill 一定比 MCP 或 CLI 更强。
它更多解决的是“怎么用”，比较适合使用通用Agent进行调用
真正决定 Agent 能做多少事情的，还是 Skill 底下接了什么能力。
所以回到最开始的问题：如果一个平台真的同时提供 MCP、CLI 和 Skill，我们到底该怎么选？
其实没有一个绝对的优先级，但对于普通用户来说，可以先按照一个比较简单的思路判断。
如果官方已经提供了完整的 Skill，可以先从 Skill 开始
尤其是你本来就在用 Codex、Claude Code、WorkBuddy 这类支持 Skill 的通用 Agent，官方 Skill 往往已经帮你把安装、认证、调用方式，甚至具体任务应该怎么做都准备好了。你只需要安装好，然后直接跟 Agent 说人话就行。
如果没有 Skill，再看 MCP 和 CLI。
如果你使用的 Agent 本身就能够操作终端，而且这个软件已经提供了成熟的 CLI，我会更建议优先试 CLI。
因为现在的通用 Agent 本来就很擅长执行命令，你并不需要自己去学那些命令，只需要把 CLI 安装好，剩下的基本都可以交给 Agent。
比如你想搜索知乎、创建飞书文档，或者调用其他已经提供 CLI 的服务，你还是直接告诉 Agent“我要做什么”，它自己去生成并执行对应的命令。
这也是为什么我觉得 CLI 在 Agent 时代反而重新变得很有价值：以前 CLI 需要人学命令，现在命令可以让 Agent 自己学、自己执行。
而如果这个服务没有成熟的 CLI，或者你使用的 AI 本身不方便操作终端，但支持 MCP，那么就直接用 MCP。MCP 本来就是为 AI 调用外部工具设计的，接好以后，Agent 可以直接看到这里有哪些工具、每个工具能干什么，再自己选择调用。
所以普通用户其实不用纠结哪个技术更高级，大概可以记成：有完整官方 Skill，先试 Skill；没有 Skill，Agent 能很好地操作终端、CLI 又成熟，就优先试 CLI；否则就看 MCP。
如果 MCP 和 CLI 两边都支持，而且能做的事情也差不多，那就更简单了：哪个官方更推荐、哪个在你当前的 Agent 里更容易安装和授权，就用哪个。
说到底，MCP、CLI 和 Skill 解决的，都是 Agent 怎么更好地使用外部工具和软件能力，这个问题仅此而已。