--- title: "工具的进化论：当 MCP 遇见 CLI，一场关于\"上下文\"的温柔革命 | 行开心的颠倒世界" description: "MCP 协议的\"上下文爆炸\"问题催生了 Skill+CLI 这条更轻量的路线：不把所有工具定义塞进提示词，而是用 CLI 按需调用，以 OpenClaw 为代表的社区实践正在证明这种方式的价值，MCP 与 CLI 未来会混合共存、各司其职。" canonical: "https://xingkaixin.me/posts/mcp-cli-skill-evolution/" language: "zh-CN" --- # 工具的进化论：当 MCP 遇见 CLI，一场关于"上下文"的温柔革命 MCP 协议的"上下文爆炸"问题催生了 Skill+CLI 这条更轻量的路线：不把所有工具定义塞进提示词，而是用 CLI 按需调用，以 OpenClaw 为代表的社区实践正在证明这种方式的价值，MCP 与 CLI 未来会混合共存、各司其职。 2026年3月16日·2,317 字·7 分钟 [MCP](https://xingkaixin.me/tags/MCP/)[CLI](https://xingkaixin.me/tags/CLI/)[AI工具](https://xingkaixin.me/tags/AI%E5%B7%A5%E5%85%B7/)[Agent](https://xingkaixin.me/tags/Agent/) ![工具的进化论：当 MCP 遇见 CLI，一场关于"上下文"的温柔革命](https://xingkaixin.me/cover/mcp-cli-skill-evolution.webp) ## 一、故事的开始：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 则从工程实践的角度切入。这些方法并不冲突，反而在相互借鉴、相互融合。 作为开发者，我们可能得放下”路线之争”的执念，根据实际场景选最合适的工具。上下文资源有限，得省着点用。 毕竟，工具的终极目的不是炫技，而是让我们的生活更简单一点。 ## 版权声明 作者 XingKaiXin 标题 工具的进化论：当 MCP 遇见 CLI，一场关于"上下文"的温柔革命 发布时间 2026年3月16日 文章链接 [https://xingkaixin.me/posts/mcp-cli-skill-evolution/](https://xingkaixin.me/posts/mcp-cli-skill-evolution/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 导览 展开导览