几十年前的 DOS 黑屏界面，在AI时代又翻红了。

发表于 更新于

要说最近两周最火的概念，肯定是 CLI，Command Line Interface。几十年前的 DOS 黑屏界面，又翻红了。

钉钉在 3 月 17 日的发布会上宣布全面 CLI 化，为 AI 重写底层代码。飞书今天发布并开源了 feishu-cli。再往前，3 月 11 日 Perplexity CTO Denis Yarats 在 Ask 2026 大会上宣布内部弃用 MCP，转向 REST API 和 CLI。国内国外，方向出奇一致。

由 Anthropic 提出的 MCP，才短短 1 年多，就要过气了？企业内部的 MCP 都白做了吗？还有大量业务 API 没有做 MCP 化，是否还要继续？我们的系统是否要全面转向 CLI？相信很多人都跟我一样，有一脑袋问号。

一、”MCP 会把所有工具的元数据加载到上下文”——这个信息是过时的

很多文章攻击 MCP 的核心论据是：MCP 会把所有 tool schema 一次性注入上下文窗口，吃掉大量 token。最常被引用的数字是 72%——来自 Apideck 的案例，3 个 MCP server 加载约 40 个 tool，消耗了 200K 上下文中的 143K token。这个数字是真实的，但它反映的是没有做任何优化的最差情况。

这个问题已经有解了。2026 年 1 月，Anthropic 在 Claude Code 中上线了 MCP Tool Search——工具定义超过 10K token 时自动切换为按需加载，每次只拉 3-5 个相关工具。Benchmark 数据：50+ 个 tool 的场景下，token 开销从 77K 降到 8.7K，降低 85%；工具选择准确率反而从 49% 提升到 74%，因为上下文噪音少了。

拿”72% 上下文被吃掉”来判 MCP 死刑，是拿一个已经修复的 bug 当永久缺陷在批。

当然，即使差距缩小了，CLI 依然有 MCP 追不上的优势——LLM 训练数据中有大量 CLI 工具的使用案例，git、docker、aws 这些命令对模型来说是”预编译的 schema”，不需要运行时注入任何定义。CLI 对 Agent 是直觉，MCP 对 Agent 是说明书。说明书写得再好，也比不上已经内化的直觉来得快。

但这是 CLI 自身的价值，不是 MCP 的问题。

二、CLI 最大的价值是同时对人类和 Agent 友好的界面

CLI 翻红不是因为 MCP 不行，而是因为 CLI 本身有独立的、不可替代的价值。这个价值的核心，是解决了 Agent 操作企业系统时的效率问题。

没有 CLI 的时候，Agent 操作我们的系统基本有三条路，但都不够好：

  • • 直接调 REST API。 Agent 要自己拼鉴权、查 ID、构造请求体，一个”发消息”的动作可能要三步，每步都消耗 token。
  • • 走 MCP Server。 好一些，schema 描述了参数语义，但 tool 多了上下文膨胀，少了又覆盖不够。
  • • GUI 模拟。 用 Playwright 去点击界面，效率和稳定性都没法看——AI 不需要漂亮的按钮和流畅的动画。

CLI 把这三个问题全解决了。Scalekit 的 benchmark 显示，同样的任务 CLI 比 MCP 省 10-32 倍 token。鉴权和参数拼装在安装阶段就处理完了，Agent 运行时只关心业务语义。--help 就是自描述，输出 JSON 就是结构化，不需要额外的 schema 注入。

但这些还不是 CLI 最被低估的特性。CLI 最被低估的价值是：它同时对人类友好。

开发者可以在终端里直接用 CLI 调试、验证、组合命令。运维人员可以把 CLI 命令写进脚本做自动化。Agent 可以在同一个终端里调用同样的命令。人和 AI 共用一套工具，共用一套排错路径。这是 MCP 做不到的——MCP 的 tool schema 对人类来说基本不可读，调试只能靠 log。

三、企业内部的 MCP 白做了吗？

不能说是白做了。恰恰相反，做过 MCP 的系统，CLI 化的成本反而更低。

以钉钉为例。钉钉的存量 HTTP API 有上千个，是给前端开发者调的，参数命名、返回结构、鉴权方式各自为政，历史包袱很重。直接暴露给 Agent，等于让 Agent 去啃一本几百页的、风格不统一的 API 文档。

钉钉做 CLI 化的路径是：存量 HTTP API → MCP 接口层 → CLI 命令。钉钉的 DWS CLI 不硬编码任何产品命令，底层走 JSON-RPC 做传输和服务发现。后端新增一个产品，CLI 不需要改代码，注册表里加了服务描述就自动生成对应命令。

MCP 在这里的核心价值不是协议本身，而是人工筛选了哪些 API 适合暴露给 Agent，以及用什么粒度暴露。这一步的工作量才是大头——要决定上千个 API 中哪些值得暴露、参数怎么命名才能让 AI 一看就懂、返回结构怎么统一。做过 MCP 改造意味着这些脏活累活已经干完了，从 MCP 到 CLI 只是最后一公里的自动化。

但这不意味着 MCP 是 CLI 化的前置条件。如果一个系统还没做过 MCP 改造，完全没必要先绕一圈去做 MCP，再从 MCP 生成 CLI。直接从 HTTP API 筛选出 Agent 需要的子集，包一层 CLI 就行。两条路径的核心工作是一样的：决定暴露什么、怎么暴露。

四、企业内部的系统是否需要全面 CLI 化？

我认为非常有必要。

看看正在发生的事情：OpenClaw 爆火后，钉钉、飞书、微信纷纷入局，推出各自的 CLI 工具和 Agent 集成方案。Claude Code、Kiro 也都有了基于自己工具的 Claw。Claw 模式的硅基员工，正在成为新的生产力形态——7x24 小时在线，能读文档、发消息、管日程、跑流程、写代码。

这些硅基员工要干活，需要调用我们的系统。如果我们的系统没有 Agent 友好的接口，就像招了一批新员工，却不给他们门禁卡和工位——有能力但使不上劲。

反过来想，不做 CLI 化会怎样？Agent 退化回 GUI 模拟或者裸调 REST API，效率掉一个数量级不说，每次 API 变更都可能让 Agent 挂掉。你的系统对硅基员工来说就是一栋没有电梯的写字楼——能爬，但没人愿意天天爬。

好消息是，CLI 化的工具链正在快速成熟。mcp2cli 可以把已有的 MCP 接口自动转为 CLI。OpenCLI、anything-cli 这类工具也在快速迭代，降低从 HTTP API 直接生成 CLI 的门槛。

后记

CLI 的翻红逻辑，跟我在用「纯文本格式」打造AI-Friendly的研发工作流 文章是同一个逻辑——在 AI 时代，我们需要同时具备 Human-Friendly 和 Agent-Friendly 的工具。Markdown 是这样的文档格式，Gherkin 是这样的测试用例格式，CLI 是这样的系统交互界面。它们都不是什么新发明，但在 Agent 时代找到了新位置。

硅基员工要来上班了，我们得先把工位准备好。