大家好，我是二哥。

最近这两周，我一直在高强度的使用 CLI。

比如说用 OpenCLI 抓 B 站的视频数据。

比如说用飞书 CLI 直接生成词云图（数据来源于简历修改的飞书多维表格）。

AI Agent 时代——命令行又行了。

就连我们每天用的 Claude Code、Codex，执行入口几乎全都是命令行。

IntelliJ IDEA 逐渐不再成为这个时代的宠儿，就是因为他本身是为人设计的，而 AI Coding 工具天然擅长和代码直接打交道，人只管给需求就行了，也就不需要GUI了。

但命令行这玩意儿，70 年代就有了。

50 多年过去了，按理说该被各种酷炫的 GUI、低代码淘汰了才对。结果到了 2026 年，最前沿的 AI Agent 工具都在用它。

为什么？

我花了大概一周的时间，把整个脉络捋了一遍：CLI 怎么来的、为什么是这个结构、为什么现在又被选中。今天这篇就把我的思考和实测一起分享出来。

理解了这件事，对我们如何看待 Agent 这条赛道会有完全不一样的视角。

01、CLI 是为了把命令交给计算机

提到 CLI，很多小伙伴脑子里先冒出来的是黑色的命令行窗口，程序员的专属工具，觉得它对普通人很不友好。

我最早入行的时候也讨厌这玩意，那时候老师还教我们如何在记书本里写 hello world。

受够了。

CLI 是 Command-Line Interface 的缩写，中文叫“命令行界面”。在它出现之前，人和机器是怎么交互的呢？打孔卡、纸带、开关面板——你把信息送进机器，但反馈不会立刻回来，更谈不上实时交互。

直到电传打字机和终端出现，人和机器才第一次有了“输入一句话，立刻看到结果”的实时回路。

就在这个节点上，问题来了：既然能实时交互了，人到底该怎么把动作清楚地表达给机器？

最自然的办法，就是把要做的动作简化成一行命令——“命令词 + 参数 + 对象”。

rm -rf /tmp/old_files

这个结构从 70 年代到现在，几乎没变过。

CLI 负责把动作交给操作系统，由操作系统去调用底层能力。

• 把动作交出去
• 把反馈立刻拿回来
• 把多个动作连接在一起

CLI的典型代表的就是 bios 窗口，早年刷机的时候见这玩意就头疼。

后来 GUI 出现了。

按钮、窗口、图标、菜单——对普通人来说比记命令轻松得多。人天生擅长视觉识别，不擅长死记硬背。

GUI 真正解决的是降低门槛、把状态可视化、让非技术用户也能用计算机。它替代的是 CLI 的“前台位置”。

CLI 是“想清楚，再输入”；GUI 是“看得见，再操作”。前者对人来说确实不友好，但它在动作表达、结果返回、步骤串联这三件事上，无敌到寂寞。

这也是为什么到了 GUI 时代，CLI 并没有消失——git 至今主要还是跑在命令行上。

普通用户用 GUI，极客们都用 CLI。

比如说 Git、Linux。

02、Agent 时代又轮到了 CLI

AI 时代。

一边是模型侧。Anthropic 把 Agent 的执行入口落到了 CLI，做出了 Claude Code。

另一边是软件侧。平台能力开始被重新包装成命令行——飞书出了 CLI。

两边最后都落到 CLI，不是巧合。

而是因为软件世界里多了一个新的执行者：Agent。

过去的软件大致是“人通过 GUI 操作软件”。现在慢慢变成了“人提出需求，Agent 负责拆解任务、执行、修正”。

一旦执行者从“人”变成了“Agent”，CLI 就是最成熟的方案。

因为 Agent 一旦开始干活，立马会有这四个问题：

• 命令怎么到软件层
• 执行结果怎么拿回来
• 出错以后怎么修正
• 多个动作怎么连接起来

这些正是CLI擅长的。

这里有个误区——很多人会把 CLI 和 API 混为一谈。

API 是软件能力的原始接口。比如飞书把读写表格、发消息这些能力开放成 API，供其他程序调用。

飞书 CLI 是对飞书 API 的一层包装。它把鉴权、参数拼装、分页、错误处理这些复杂细节处理掉，最后对 Agent 只暴露一条命令。

我认为有三个原因，让 CLI 重回大家的视野。

第一，GUI 对人友好，对 Agent 却很别扭。人看按钮一眼就知道点哪里，Agent 要操作 GUI，得先截图、识别界面、定位元素、再模拟点击。视觉理解成本很高。

CLI 比 GUI 稳定，因为接口是文本不是界面；CLI 比 API 也更省事，因为脏活已经被 CLI 封装好了。

第二，大模型天生就会用 CLI。

这一点是结构性的优势。大模型的训练语料里，塞满了各种命令行指令。

模型不需要从零学习“怎么用命令行”，它天然就熟悉这种范式。

第三，Unix 哲学正好契合 Agent 的工作方式。

Unix 很早就把 CLI 的底层逻辑定下来了：每个程序只做一件事，程序之间的协作用文本做通用接口。

这三件事，恰好也是 Agent 最需要的。

文本是模型的母语——输入是文本命令，输出是文本或者 JSON。

每个命令只做一件事，但多个命令能连接起来形成工作流。

cat /var/log/app.log | grep ERROR | wc -l

这种“做一步、看一步、修一步”的循环，正好和 CLI 的即时反馈机制不谋而合。

03、MCP 和 CLI 什么关系

CLI 和 MCP 都站在 Agent 和底层能力之间，但处理同一件事的方式完全不一样。

举个例子，我们要“从飞书多维表格里拉一批记录”。

CLI 路径：Agent 需要先知道有什么命令，然后生成一行字符串：

lark-cli base records list --table xxx

然后把结果以文本（通常是 JSON）形式返回回来。Agent 读取文本，决定下一步。

如果 Agent 不知道有 lark-cli 这个工具，这条路是没办法走通的。

MCP 路径：协议主动告诉 Agent 有什么能力。

Agent 不需要提前知道任何命令。MCP Server 会主动把自己的能力清单推给 Agent。

Agent 看到清单，选一个工具，填好参数，发起调用。它不需要知道底下跑的是 lark-cli 还是直接调了飞书 API——MCP 把这些细节屏蔽了。

CLI 的两个强项

第一个是管道组合。

比如“读日志，找出错误行，统计一共多少条”这个任务。

CLI 模式下，Agent 写一行命令，三步操作通过管道接在一起，一次调用就搞定。

cat app.log | grep ERROR | wc -l

MCP 模式下呢？同样的事得分三步——先调 read_file 拿文件，再调 search_text 筛错误行，最后调 count_lines 统计。三次调用，每次都要选工具、填参数。

效率差一截。

第二个是上下文更节省。

大模型的训练数据里，CLI 是最密集的工具使用范式。

模型不需要从零学习，它已经见过无数遍了。

而 MCP 的工具 schema 是 2024 年才出现的新东西。更关键的是，MCP 需要把工具描述注入 Agent 的上下文窗口——Agent 还没开始干活，窗口就先被占掉一块。

虽然延迟加载（deferred tools）这种方案能缓解这个问题，但还是没办法和 CLI 比，因为 CLI “不需要注入、天然就会”是结构性的优势。

MCP 的两个强项

第一个是不限于文本。

CLI 的管道是文本流。文本进、文本出，这是 Unix 50 年前定下的规矩。

对于日志、代码、配置文件这些纯文本，CLI 非常高效。

但如果 Agent 要处理一张图片、一段音频、一个结构化的数据库查询结果呢？文本管道就成了瓶颈。你没法把一张 PNG 通过管道传给下一个命令。

MCP 的结构化调用没这个限制。它可以传递 JSON 结构、二进制数据、带类型的返回值。处理多种内容类型的场景，MCP 天然更合适。

第二个是参数验证。

CLI 里一切都是字符串。Agent 拼出来的命令参数对不对，只有执行了才知道。拼错了参数格式，命令就报错；更糟的是如果输入里藏着恶意内容，Agent 可能拼出一条危险命令——这就是注入风险。

MCP 在调用之前就能拦住这些问题。每个工具的参数都有类型定义（字符串、数字、必填/可选），协议层会在执行前校验。

填错了当场报错，不会带到执行环节。

拿 Claude Code 举例。它的内置能力（运行命令、读写文件、搜索代码）全走 CLI 路径。外接服务（GitHub、数据库、第三方平台）走 MCP。

04、CLI 在被重新设计

第一条线：把已有 CLI 更好地暴露给 Agent

这个方向围绕已有的 CLI 做两件事：

给 Agent 一个统一入口，不用它满世界找命令；把执行结果整理成 Agent 看得懂、能决策的样子。

这样一来，CLI 就不再是“你知道命令才能用”的专家工具，开始变成一个能配合 Agent 持续循环工作的工作台。

第二条线：把网页和平台能力翻译成 CLI

OpenCLI 抓的是这个。

它处理的不是“已有 CLI 怎么被发现”，而是“原本没有 CLI 的平台，怎么变成 CLI”。

我自己测过一次，效果挺惊艳的。以前我想从 B 站抓某个 UP 主的视频列表，得自己写爬虫、处理反爬、解析 HTML，麻烦得要死。

现在用 OpenCLI 一行命令就出来了。

更关键的是，它不光提供命令，还提供机器可读的发现方式。这意味着它在解决第二个问题的同时，也顺带缓解了第一个问题——命令不再只是写给人看的，也开始写给 Agent 看。

这意味着 CLI 不再只代表本地电脑上的能力，也开始代表网页平台和远程服务。

今天的 CLI：

• 工具型 CLI：git、docker、GitHub CLI
• 平台型 CLI：飞书 CLI、OpenCLI
• Agent 型 CLI：Claude Code、Codex CLI、Gemini CLI

ending

第一，技术不是线性进步的，是螺旋上升的。

我们以为 GUI 干掉了 CLI，结果 50 年后 CLI 又回来了。同样的事在历史上发生过太多次——以为函数式编程死了，结果 React 又把它捡回来；以为单体架构过时了，结果微服务卷不动后大家又回归单体。

不是技术在倒退，是需求在变化。CLI 没有变，是 Agent 重新激活了它。

第二，Agent 不是颠覆，是接入。

很多人一聊到 Agent 就觉得是革命，要把现有的一切推倒重来。

但实际上，Agent 只是帮我们扩大了能力边界，在人和软件之间加了一个中间件。

第三，软件世界正在为 Agent 而设计。

以前我们做产品，第一个想到的用户画像是“普通用户”。然后我们会问：他们能看懂这个按钮吗？操作流畅吗？有学习成本吗？

现在多了一个用户：Agent。

它不会看图标，但能读 JSON。它不会拖拽，但能拼命令。它不会被花哨的动画打动，但会被稳定的 stdout/stderr 取悦。

如果你的产品只为人设计，Agent 就只能在外面观望。

如果你的产品同时为 Agent 设计，它就能成为 Agent 工作流里的一个可调度节点——这是完全不同的市场位置。