工具的进化论：当 MCP 遇见 CLI，一场关于"上下文"的温柔革命

工具的进化论：当 MCP 遇见 CLI，一场关于”上下文”的温柔革命

一、故事的开始：2024年11月

我第一次听说 MCP，是在 2024 年 11 月底的一个下午。

那时候 Anthropic 刚刚开源了这个叫 “Model Context Protocol” 的东西，野心很大——他们想给 AI 助手和数据系统之间搭一座通用桥梁。简单来说，就是不想每接入一个新工具就写一堆定制化代码。

刚看到 MCP 时，我真的觉得这想法很聪明。以后不管是查数据库、调 API、还是操作文件系统，都用同一套协议，不用每接入一个新工具就重新搞一遍，多省事儿啊。

但现实很快给我上了一课。

二、工具越多，脑子越乱

MCP 的核心设计是这样的：每个 MCP 服务器都会把自己的”能力清单”（tools/list）暴露给主机，包括每个工具的描述、参数格式等等。然后主机把这些信息塞进 AI 的”系统提示词”里，让模型知道”我能做什么”。

但用着用着就发现不对劲了。

刚开始接入一两个 MCP 服务器时还挺顺手的，界面响应快，工具调用也准。等我加到第 5 个、第 10 个服务器时，就开始不对劲了——AI 助手反应变慢了，有时候明明有现成的工具它却不用，或者用错工具。

后来才搞明白，这叫”上下文爆炸”。

原来每个 MCP 服务器的工具定义都要占用 token。实测下来，一个工具定义平均要150-200 token，这意味着启用10个包含30个工具的服务器，上下文负担就可能增加4000-6000 token。我在社区里见过一个用户的实测数据：21 个工具，占了 3500 个 token。再举个例子：如果一个 MCP 服务器有 10 个工具，每个工具定义约 200 token，那么启用 10 个这样的服务器，上下文负担就会增加 20,000 token（10个服务器 × 10个工具 × 200 token）。听起来不多？但如果是多轮对话，每轮都得带着这些”能力清单”，成本可就上去了。

更麻烦的是，就算某个工具在当前任务里完全用不到，它的定义也得在上下文里待着，就像带着一堆根本不会穿的衣服出门。相比之下，CLI方案只需要一个通用的”执行命令”指令（约200 token），在多轮对话里这个差距就很明显了。

三、Skill 的出现：给工具包穿上马甲

这时候 Skill 这个概念开始进入大家的视野。

Skill 到底是什么？简单来说，它是”工具的工具”——不直接提供能力，而是教 AI “在什么时候、怎么用”某些能力。

Skill 有个很好的设计叫”渐进式加载”。平时只把 Skill 的名称和简介放在上下文里，等 AI 决定要用某个 Skill 了，才把完整的指令加载进来。这就好比只带一张购物清单出门，需要买什么再详细看说明。

OpenAI 的 Codex、Anthropic 的 Claude Code 都开始支持 Skill。有意思的是，Skill 很快分化出了两条不同的路线。

四、两条路线的分野：MCP 派 vs CLI 派

第一条路线是 skill+mcp。

这条路走得比较规矩：MCP 服务器提供结构化的工具接口，Skill 负责编排这些工具的执行流程。比如你要部署一个服务，Skill 会告诉你”先调用 A 工具的创建接口，再调用 B 工具的配置接口”。

这条路线的优势是规范、安全、有明确的授权边界。但代价也很明显——你还是要和那一堆工具定义打交道，上下文负担依然存在。

第二条路线是 skill+cli。

这条路线更野，也更接地气。它不依赖 MCP 服务器，而是直接调用本地已经存在的命令行工具——git、aws、kubectl、gh 等等。

Claude Code 的官方文档里有句话我记得很清楚：优先使用 CLI，因为它们比 MCP 服务器更”上下文友好”。

为什么？因为 CLI 不需要在系统提示词里塞进一大段工具定义，你只需要告诉 AI “你可以用 bash 执行命令”，然后具体要用什么命令、什么参数，AI 根据实际情况实时决定。

简单来说：MCP 派像是带着一本厚厚的说明书，把所有功能都列得清清楚楚；CLI 派则像是只带了一张纸条，上面写着”有问题随时问我”。

五、OpenClaw：社区的选择

在 CLI 派里面，OpenClaw 算是一个典型的代表。

这是个开源项目，做的是”自托管 AI 网关”。我比较喜欢它对 Skill 的工程化管理方式。

OpenClaw 把 Skill 分成了三层：bundled（内置）、managed/local（本地管理）、workspace（工作区级别）。它还做了件挺有用的事——计算每个 Skill 对上下文的占用。

根据他们的文档，加载 Skill 列表时会在系统提示词里注入一个紧凑的 XML 格式列表，每个 Skill 都有固定的字符开销。这就像是给上下文成本做了一张明细账单，让你心里有数。

更重要的是，OpenClaw 虽然支持 MCP，但把它放在了”可选的工具提供层”，而 Skill 和 CLI 才是主要的编排方式。这种设计选择本身就说明了社区的倾向。

六、为什么 skill+cli 越来越香？

以OpenClaw为代表的skill+cli方案在社区中迅速走红，这背后有几个关键原因：

第一，DevOps 生态的惯性。

云原生时代的工程师都习惯用命令行工具。kubectl、docker、terraform 这些工具用了十几年了，文档全、社区活跃、行为稳定。用 Skill 包装一下就能给 AI 用，何必再套一层 MCP 的壳子？OpenClaw正是看到了这一点，通过Skill层直接调用这些成熟工具，省了不少事。

第二，上下文成本的倒逼。

实际上，每个 MCP 服务器的工具定义都会进入上下文，即使它处于空闲状态。而 CLI 方案只需要几条通用的执行指令，就能调用无数外部工具。OpenClaw内置的上下文成本计算功能，就是为了让开发者清楚地看到每个Skill的token开销。

第三，灵活性与可控性。

CLI 的输出是文本，AI 可以直接阅读、分析、总结。而 MCP 的输出是结构化的 JSON，虽然规范，但往往需要额外的解析步骤。在很多场景下，“可读性”比”结构化”更重要。OpenClaw为此设计了沙箱执行环境，既保持了CLI的灵活性，又通过权限控制降低了安全风险。

当然，skill+cli 也有它的软肋——安全。

执行任意命令的风险显然高于调用结构化的 API。这也是为什么 OpenClaw 强调要在沙箱里运行 CLI 命令，并且需要严格的权限控制。

从OpenClaw的工程实践来看，skill+cli方案不仅理论上可行，更在实际应用中证明了它的价值——在控制上下文成本的同时，充分利用现有工具生态。

七、MCP 的未来：不是消亡，而是进化

虽然 skill+cli 有不少优势，但我觉得 MCP 不会就这么消失。它也在不断进化。

从协议规范的更新来看，MCP 社区也在积极回应”上下文爆炸”的批评：

按需加载：Claude Code 已经引入了 tool search 机制，当工具定义超过一定比例时，会启用搜索模式，只加载相关工具的描述。

任务异步化：2025 年 11 月的规范版本引入了 tasks 概念，允许把耗时操作异步化，减少上下文回灌的压力。

分层架构：新的规范版本在授权、安全、传输层都做了大量改进，OAuth 2.1、scope 升级、SSE 流重连等机制让 MCP 更适合生产环境。

我的预测是，未来会出现一种”混合模式”：

• CLI 负责”常用、轻量、低风险”的操作——比如代码提交、日志查询、配置检查；
• MCP 负责”需要授权、需要结构化交互、需要资源订阅”的场景——比如访问企业 SaaS、操作数据库、调用第三方 API。

两者不是非此即彼，而是各司其职。

八、写在最后：一场关于”连接”的持续探索

回顾这一年多的发展，MCP、Skill、OpenClaw 的出现和演进，其实都在回答同一个问题：如何让 AI 更好地连接外部世界？

MCP 想用协议标准化来解决，Skill 用的是知识封装的方法，OpenClaw 则从工程实践的角度切入。这些方法并不冲突，反而在相互借鉴、相互融合。

作为开发者，我们可能得放下”路线之争”的执念，根据实际场景选最合适的工具。上下文资源有限，得省着点用。

毕竟，工具的终极目的不是炫技，而是让我们的生活更简单一点。