ENZOMEGA.
Clipping 微信公众号

MCP、CLI 与 SKILLS：它们不是替代关系，而是 AI 工具调用体系的三层分工

by 独行者 木子李 原文 ↗
Created: 2026-05-27
#公众号文章

公众号名称：堆栈future

作者名称：独行者 木子李

发布时间：2026-03-28 16:23

最近一段时间，关于 “MCP 和 CLI 到底谁更适合 Agent” 的讨论越来越多。看多了之后，我的判断反而越来越简单：把 MCP 和 CLI 放进“二选一”的框架里，本身就是一个错位问题。 它们解决的根本不是同一层的问题。MCP 更接近“能力如何被标准化暴露”，CLI 更接近“能力如何被调用”；而 SKILLS 处理的，则是“为了完成任务，应该在什么时候、以什么顺序调用哪些能力”。换句话说，三者不是竞争关系，而是一个完整 AI 工具调用体系里的三个层次。

如果一定要先给一个结论，我会这样概括：MCP 负责标准化能力暴露，CLI 负责调用入口与渐进式发现，SKILLS 负责任务流程与工具编排。 真正缺的，不是“再选一个协议”，而是补齐能力层和任务层之间的“调用层”。

​

一、先把三个概念摆正：它们根本不在同一层

先看 MCP。按照官方定义，Model Context Protocol 是一个开放协议，用来把 AI 应用连接到外部系统，包括数据源、工具和工作流。它的核心价值不是“替模型做决策”，而是让外部能力以统一方式被发现、描述和调用。这和 OpenAPI 做的事情有点像：OpenAPI 也是通过标准化的接口描述，让人和机器在不看源代码的情况下理解一个服务能做什么。两者的共同点在于，它们都属于“能力面”的基础设施。

再看 CLI。CLI 的强项从来不是“标准化世界”，而是“给能力一个稳定、可操作、可组合的入口”。以 GitHub CLI 为例，gh 把 GitHub 的 issue、pr、repo、workflow 等概念带到了终端，用户可以先 gh 看顶级命令，再进入 gh pr、gh issue，最后带参数执行具体操作。这种交互天然支持渐进式发现：先看总览，再看子命令，再看参数，再执行。它解决的是“怎么用”的问题，而不是“怎么定义”的问题。

最后是 SKILLS。OpenAI 对 Skills 的定义很直接：它是可复用、可分享的工作流，可以告诉 ChatGPT 如何更好、更稳定地完成某类任务。一个 Skill 可以打包指令、示例，甚至代码，并且系统可以在合适的时候自动调用一个或多个 Skills。也就是说，Skills 的职责不是暴露原子能力，而是把任务目标、操作规则、调用顺序、输出格式这些高层约束组织起来。它属于“任务面”。

所以，从架构视角看，三者各自回答的是三个不同问题：

  • • MCP：我有哪些能力可以被标准化暴露？

  • • CLI：这些能力该如何被人或 Agent 调用？

  • • SKILLS：为了完成一个任务，能力应该如何组合和编排？

二、为什么大家会误以为 “CLI 比 MCP 更好”

之所以会出现 “CLI Is All You Need” 这类观点，我觉得并不奇怪。因为今天很多 Agent 框架对 MCP 的使用方式，确实把它的短板暴露得太明显了。

第一，很多系统会在一开始就把所有工具 schema 一次性塞进上下文。MCP 本身强调标准化能力暴露，但如果宿主应用把全部工具描述都直接注入上下文，token 很快会被工具定义吃掉。Anthropic 近期专门写过一篇文章谈这个问题：当连接的工具越来越多时，提前加载所有工具定义、再把中间结果不断塞回上下文，会显著拖慢 Agent，并增加成本。他们给出的做法是引入代码执行来减少上下文开销，实测可把相关开销降低到非常大幅度。这里暴露出来的问题，不是“MCP 不能用”，而是“工具调用机制太粗暴”。

第二，很多工具调用结果直接回填对话上下文，缺少一个中间处理层。于是每次调用不仅消耗 token，还把原始结果原封不动堆进推理链条里，导致系统越来越重，也越来越缺乏组合性。模型既要理解工具 schema，又要吞掉中间结果，还要在同一个上下文里维持任务计划，这当然容易失控。这个问题也不是 MCP 独有，而是“把能力暴露层直接等同于调用层”带来的后果。

这时候 CLI 看起来就很美。因为 CLI 通常有三个天然优势：第一，它支持逐层发现；第二，它把执行放在上下文之外；第三，它天然可组合，比如管道、脚本、子进程、退出码。这些优势会让人产生一种感觉：CLI 本身比 MCP 更适合 Agent。 但更准确的说法是：CLI 看起来更适合今天很多 Agent，不是因为它替代了能力层，而是因为它顺手提供了一个更像样的“调用层”。

​

三、真正缺的不是新协议，而是“调用层”

我越来越倾向于把今天 AI 工具体系的问题，理解为“中间层缺失”问题。

如果只看 MCP，你得到的是一套标准化暴露出来的能力集合。它非常适合做发现、描述和互操作。官方文档也明确把数据源、工具、工作流都纳入了可连接对象。也正因为 schema 暴露是协议的一部分，能力发现路径会更稳定，描述字段通常也更完整，更适合模型对齐。

如果只看 CLI，你得到的是一个很好用的调用入口。它尤其适合单次执行、渐进式探索、脚本化封装，以及面向终端用户的交互。GitHub CLI 能流行，很大程度也来自这种体验：命令结构、帮助信息、子命令体系，都是人和模型都容易掌握的“调用语法”。

但 Agent 真正需要的，不只是“有能力”和“能调用”，而是在任务执行过程中，按需披露能力、选择入口、管理状态、清洗结果、支持组合。这就是我说的调用层。它应该位于能力面和任务面之间，完成几件事：

  • • 渐进式披露能力，而不是一次性注入所有 schema。

  • • 为原始能力生成稳定调用入口，而不是让每个任务都直接面对底层协议。

  • • 处理返回结果，而不是把每个原始结果都无脑塞回对话上下文。

  • • 提供组合性，让多个能力可以围绕任务目标被串起来。

这些能力，本质上不是 MCP 的职责，也不是 SKILL 的职责，而是一个独立 runtime 或调用层该承担的职责。

​

四、用一张图看懂三者分工

这张图里，MCP 和 CLI 并列出现，但它们不是同义词。MCP 更像标准化接口描述和连接协议，CLI 更像人机共用的调用界面。调用层既可以把 MCP 暴露出来的工具转译成渐进式 CLI，也可以直接调用已有 CLI，甚至可以同时管理 daemon、长连接和短命令执行。SKILLS 则站在更高一层，把“这个任务应该怎么做”表达出来。

五、为什么我认为 MCP 仍然是最适合 Agent 的能力暴露协议之一

我并不认同“CLI 胜出就意味着 MCP 失效”。

原因很简单。Agent 世界真正稀缺的，是可被机器稳定理解的能力描述。MCP 在这方面有明显优势：它是为 AI 应用连接外部系统而设计的开放协议，schema 暴露是协议的一部分；而且官方把“工具、数据源、工作流”都纳入统一模型，这意味着宿主系统在能力发现和工具解释上更容易形成稳定路径。相比之下，CLI 的帮助信息质量参差不齐，参数语义也不总是足够结构化。

还有一个经常被忽略的点：大家爱拿 gh 和 GitHub 的 MCP 方案比，但这个对比并不总是公平。gh 已经存在很多年，文档丰富，命令模式稳定，互联网上有大量教程、博客、issue 和脚本，模型天然更容易学会使用它。这是“语料红利”，不完全是“形式优势”。如果你今天做一个全新的服务，再给它造一个 CLI，它并不会自动获得这种模型友好度。没有一个通用调用层和统一能力描述，你最后还是会回到老问题：每个服务维护一套自己的 CLI，接口一变就要跟着改，用户还要承担安装、升级和权限管理成本。

​

六、SKILLS 为什么也不能省

很多人讨论 MCP 和 CLI 时，会漏掉 SKILLS。这恰恰是今天很多 Agent 系统缺乏稳定性的另一个原因。

Skill 不是“再包装一层 prompt”这么简单。按照 OpenAI 的定义，Skill 是可复用的工作流，它可以包含指令、示例和代码，并在合适的时候被自动使用。这个定义很关键，因为它说明 Skill 的本质不是暴露能力，而是固化任务经验：什么时候该用哪类工具，什么情况下先搜索再计算，遇到长文档先抽取再总结，哪些结果要过滤，输出要遵循什么格式。

如果没有 Skill 层，Agent 往往只能在“看到一堆工具 schema”之后临场即兴发挥。这会带来两个问题：第一，决策不稳定；第二，流程不可复用。你今天写一个研究助理，明天写一个网页测试 Agent，后天写一个客服 Agent，如果都只靠底层工具自己现推理，那你每次都在重复发明流程。Skill 的意义，是把“面向任务的调用模式”抽象出来，让同样的任务结构可以在不同能力集上复用。

​

七、一个更合理的三层模型

如果让我给今天的 AI 工具调用体系画一个更完整的架构，我会这样定义：

这个模型下：

  • • 能力层解决的是“如何以统一方式描述工具和服务”。

  • • 调用层解决的是“如何让 Agent 不必一次吞下所有能力，而是按需发现、按需调用、按需组合”。

  • • SKILLS 层解决的是“围绕任务形成可复用的决策与流程模板”。

我认为接下来几年，真正会拉开差距的，不是谁先发明了新协议，而是谁把这三层拼装得更合理。Anthropic 近期对 MCP 上下文开销问题的处理，其实已经在朝“补调用层”这个方向走：不是否定 MCP，而是承认单纯把所有工具定义和结果都放进上下文会出问题，然后用更高效的执行方式去削减成本。

​

八、什么时候选 MCP，什么时候直接上 CLI，什么时候该写 SKILL

如果要落到技术决策，我会给一个很务实的判断框架。

第一种情况，你有一个远程服务，希望 Agent 能稳定发现其能力、理解参数、保持跨宿主的一致性。这时优先考虑 MCP 或类似 OpenAPI 这种标准化描述方式。标准化能力暴露，会让后续接入、迁移和自动化更省力。

第二种情况，你有一个本地程序，或者一个需要持续交互状态的工具，比如要维持会话、缓存或长连接。MCP 的 stdio 或长连接方式通常会更干净，因为它能把状态ful交互放在协议层处理，而不是逼你把复杂状态塞进一次次短命令里。MCP 官方规范和配套说明本来就是围绕宿主、客户端与服务器之间的持续交互设计的。

第三种情况，如果只是一次性命令、脚本化任务、明确输入明确输出，而且并不需要复杂状态管理，那么直接 CLI 就够了。CLI 的优势在于简单、直观、可测试、可组合，不需要为了轻量任务强行上协议层。GitHub CLI 这类工具就是很好的例子。

第四种情况，只要你的目标不再是“调用一个工具”，而是“完成一类重复任务”，就应该写 Skill。Skill 不是替代底层能力，而是把任务目标、顺序、约束、判断条件和输出规范收敛成可复用模板。这样你的 Agent 才不会每次都从 schema 和命令帮助信息开始即兴发挥。

​

九、别再问“谁取代谁”，该问“哪一层还缺”

今天谈 AI 工具调用体系，我越来越不愿意用“协议战争”的语言。因为很多争论其实都把不同层的问题混到了一起：拿调用体验去否定能力协议，或者拿能力标准去替代任务流程。

更合理的思路应该是：

  • • 用 MCP 这类协议，把能力标准化暴露出来。

  • • 用 CLI 或类似运行时，把调用入口做成渐进式、可组合、可管理的形式。

  • • 用 SKILLS，把任务流程沉淀为可复用的经验。

这三层各司其职，才是 Agent 真正能规模化的前提。OpenAPI 在 API 世界的价值，从来不是“替人写业务逻辑”，而是把能力描述标准化；CLI 在终端世界的价值，也从来不是“发明服务能力”，而是给人一个稳定入口；Skills 在今天的 AI 产品里，则是在补“任务方法论”这块缺失的拼图。

​

十、结语

去年大家一窝蜂吹 MCP，我觉得有点过；现在又一窝蜂踩它，我还是觉得踩过了。MCP 没有解决一切，但它解决的是“能力如何被机器稳定理解”这个很底层的问题。CLI 也没有取代 MCP，但它提醒了我们：能力被暴露出来，不等于能力就能被高效调用。 而 Skills 则进一步提醒我们：高效调用，也不等于任务就能被稳定完成。

所以我更愿意把这三者理解为一个递进关系：

MCP 定义能力，CLI 组织调用，SKILLS 固化流程。

这不是谁替代谁的问题，而是 AI 工具调用体系终于开始从“只有能力层”，走向“能力、调用、任务”三层分工的问题。真正的突破，未必来自某个单一协议，而更可能来自这三层之间终于被拼起来。

Original 独行者 木子李 堆栈future

内容效果不满意？点此反馈

输入关键词开始搜索