AI 复兴了 CLI，但图形界面不会消亡

AI 兴盛以来，有许多路线争论，比如是垂类 AI vs 大而全，比如套壳vs模型，也比如 CLI（命令行） vs GUI（图形界面）、

最新的案例是，DeepSeek 给 Harness 做出了桌面版并开放下载。官网首页最醒目的按钮是「Download Desktop」，旁边展示着会话列表、插件、工作区和文件预览：用户可以让 Agent 整理文档、分析表格、修改代码，再打开结果查看。命令行并没有消失，终端和脚本仍在工具箱里，只是它们被放进了一张更大的桌面。

如果把时间拨回去年，情形可不是这样的。DeepSeek 在很长一段时间里不做产品，至少不做对 C 端用户友好的产品。每当新模型出现，只能在简陋的对话窗口里试用。

当时流行的说法是，AI 编程是对「终端」的复兴，对于很多用户来说，曾经这只是一个电脑里不怎么点开的软件，是因为 vibe coding 才打开和学着使用。

回顾 2025 年，从 2 月起，Anthropic 推出 Claude Code，让开发者直接在命令行里交代任务，模型自己搜索代码、修改文件、运行测试；同年 6 月，Google 发布 Gemini CLI。随后还出现了 Codex CLI （OpenAI 出品命令行 AI 助手），Github CLI、飞书 CLI。

那时一种颇有吸引力的判断流传开来：图形界面（GUI）是给人操作的，命令行（CLI）才是给 AI 使用的。既然未来越来越多的工作交给 Agent，为什么还要为它们画按钮？

CLI 派说对了什么

CLI 和 GUI 分别是什么：前者是纯文本指令，简单说就是靠代码和脚本行事。后者则是图形界面，鼠标、视窗、图标和菜单，这些都是图形元素。

在整个 1970 年代和 1980 年代初期，施乐公司旗下的帕罗奥托研究中心（PARC）艰苦卓绝地研究了视窗、菜单、图标和鼠标的许多早期概念。1984年，苹果电脑公司推出的低成本麦金塔电脑（Macintosh）将友好的界面带给了数以千计的个人电脑用户。

caption：选自《世界科学：图形界面的历史》

另外，CLI 在终端里运行，能天然访问整个系统文件，而 GUI 插件往往被限制在沙盒里，只能访问当前打开的文件。

对人而言，图标、窗口、菜单是把复杂功能「翻译」成人类能懂的视觉语言，但对处理文本和结构化数据的 Agent 而言，这层翻译有时反倒增加了障碍。

2025 年夏天，这种偏好已经出现在开发者自己的工作流里。Google Chrome 工程师 Addy Osmani 在一篇 Substack 长文中写道，自己越来越多地待在终端。当 Agent 能跨文件改代码、运行测试，过去占据屏幕中央的编辑器反而可能成为累赘。

「龙虾之父」Peter Steinberger 也公开过自己的配置，他从 VS Code 回到 Ghostty 终端，在屏幕上并排运行多个 Agent，把 VS Code 留作查看代码，把 Cursor 用于审阅；为让 Agent 做事，他还优先选择有 CLI 的服务。正是这段让多个 Agent 在终端里工作的试验经历，最终让红极一时的「龙虾」诞生。

CLI 的兴起并非一种复古姿态，它确实解决了 Agent 「怎样工作」的问题。

终端一个窗口，装不下十个任务

Agent 适合通过命令执行，不等于人适合通过命令管理 Agent。

即便是 Addy Osmani 也并不完全支持 GUI 已死——甚至，就在同一篇 substack 里，他写到自己用 GUI 管理多个 Agent 的经验。

Google 在 Gemini CLI 最初的公告里，也同时说明它和编辑器内的 Gemini Code Assist 共享技术；从一开始，它考虑的就是同一种能力进入多个界面。

2025 年 8 月，代码编辑器 Zed 把 Gemini CLI 接入自己的界面，Agent 在背后运行，开发者是在编辑器里跟随它的工作、查看修改差异，并决定是否接受。Zed 为此提出 Agent Client Protocol，同一个 Agent 可以保留命令行的执行能力，由图形界面负责向人呈现过程。

2026 年 2 月，OpenAI 推出 Codex 桌面版，开发者可以跨项目、长时间派发任务，并且同时运行多个 Agent。OpenAI 当时的考虑是，现有终端和 IDE 并非为这种监督方式而设计，新应用于是以项目组织任务，提供独立工作区和改动审阅，桌面端是必要的产品呈现形式。

DeepSeek Harness 的桌面版，也是进入的这个产品阶段，它把会话、插件、自动化和文件结果摆到桌面，也保留终端、脚本以及从代码启动 Web UI 的方式。用户不必先熟悉某串命令，才能看到 Agent 的工作；有需要的人仍可以继续调用命令。

GUI 从未败过

「已死」两个字喊出来很简单，GUI 与 CLI，并不总是在争夺同一个位置，甚至「Agent 使用 GUI」与「用户使用 GUI」也不是同一件事，

今年三月，Peter Steinberger 给出了他对于 CLI 和 GUI 之争的新看法。他认为 AI coding 正在转向 GUI，意开发者能更直观地完成复杂任务。

前者是机器借屏幕操作旧软件，后者是人借屏幕管理机器。把这三种关系都压缩成一场界面路线之争，便容易出现「不是东风压倒西风，便是西风压倒东风」的摇摆。

一项今年发布的研究试着让 Agent 完成 440 项桌面任务：在研究者设定的工具条件下，表现最好的 GUI Agent 完成率为 59.1%，原有 CLI 工具条件下为 48.2%；当研究者补充可供调用的命令技能，CLI Agent 升至 69.3%。这些数字不能推广成「哪种界面全面获胜」，却清楚显示：Agent 的能力，也取决于软件给了它什么入口。

研究还提醒我们一个现实条件：CLI 的优势需要软件提供足够完整、好用的命令。如果一个应用只允许命令读取文件，却把真正关键的编辑、预览和提交藏在窗口里，Agent 仍然绕不过 GUI。不同软件开放能力的程度不一样，Agent 也不可能只靠一种交互方式走遍所有场景。

从产品演变看，更值得注意的是 人所站的位置。过去的 GUI 把软件功能做成按钮，让用户亲手完成每一步；现在，Agent 可以接管其中许多步骤，界面要呈现的则是任务、进度、权限、文件差异和最终结果。原来为了「操作」设计的屏幕，正在增加「监督」的职责。

这也是那句「CLI 面向 AI，GUI 面向人类」最有用、也最容易被误读的部分， 它准确指出了机器与人偏好的接口不同，却不该被顺推为「人类界面即将过时」。恰恰因为 Agent 可以在背后执行更多命令，人更需要看得见的地方，理解它们并行的工作、追究错误发生在哪一步，以及决定哪些成果进入自己的项目。

DeepSeek 的桌面客户端无法证明 GUI 已经重新占据了多少市场，几家公司的发布也不足以宣判所有软件的未来。但它们至少让一年多前那个单向的预言变得不再成立，AI 并没有把人送进终端，反而把终端里能做的事带到了更广阔的桌面。