为什么我们又回到了 CLI？Agent 时代 CLI 与 GUI 的优劣对比

作者：袖梨 2026-09-13

Agent 时代重新流行 CLI，并不意味着软件交互退回过去。现阶段的命令行轻量、可脚本化，能直接复用 Git、测试、构建和部署工具，也容易让多个编码 Agent 在独立目录中并行工作。但人的职责正在从逐行编写转向审查、打断、比较和编排，复杂多 Agent 工作流最终仍需要更好的 GUI。更可能的方向是 CLI 成为能力复用层，GUI 成为人机协作层。

为什么开发工具曾经从 CLI 走向 GUI

现代 IDE 把文件树、补全、调试、重构、Git 差异和插件集成到图形界面，目标是帮助人类逐行阅读和修改代码。光标、单文件焦点和侧栏导航都围绕“开发者是主要代码生产者”设计。

这套模式没有失效。只是 Agentic Coding 改变了任务分工：模型承担更多代码生产，人类花更多时间定义目标、查看进度、审查差异和处理冲突。

为什么第一批 Agent 多从终端长出来

编码 Agent 需要访问仓库、搜索文件、运行测试、查看 Git 状态并启动服务。现有开发生态已经为这些动作提供成熟命令。把 Agent 放进终端，可以立即复用工具，不必先为每项能力开发图形适配层。

命令和输出都是模型容易处理的文本。
可直接使用 shell、Git、编译器和包管理器。
容易运行在本地、服务器和容器。
脚本化成本低。
能快速组合新工作流。

CLI 是长期终点还是阶段性最优解

CLI 当前非常实用，但优势很大程度来自存量工具生态和实现速度。它允许 Agent 直接寄宿在开发环境中，因此在产品早期是自然选择。

然而，人类要同时观察多个长期任务时，纯终端容易变成大量窗口、滚动日志和难以记忆的会话。CLI 适合执行，不一定是多人、多项目、多 Agent 编排的最佳总控界面。

一套终端中心的 Agent 工具链

一种常见组合是 Git worktree、现代终端、终端复用器和终端编辑器：

Git worktree：为每个任务或分支创建独立工作目录。
Ghostty 等终端：负责字体、主题、性能和窗口体验。
Zellij 或 tmux：组织 pane、tab、布局与可恢复会话。
Neovim：进行快速人工修补和文本审查。

这四层分别解决隔离、呈现、并行会话和轻量编辑。

Git worktree 为什么适合多 Agent

多个 Agent 若共享同一工作目录，会互相覆盖文件、切换分支和构建产物。worktree 让同一仓库的不同分支位于不同目录，同时共享 Git 对象数据库。

git worktree add ../project-search feature/search
git worktree add ../project-login fix/login-test

一个 Agent 实现搜索，另一个修复登录测试，主目录可以保持稳定。每个 Agent 的当前分支、未提交变更和进程也更容易辨认。

worktree 不能自动解决什么

两个 Agent 修改同一逻辑时仍会产生合并冲突。
共享数据库、端口和缓存仍可能互相影响。
依赖安装和构建产物需要明确隔离策略。
秘密配置不能随意复制。
完成后仍需审查和安全移除工作树。

目录隔离是基础，不是完整并发治理。

终端复用器解决什么问题

Agent 任务经常伴随测试、开发服务器和日志。终端复用器可以把它们放入一个有命名的 workspace：

workspace: feature-search
  pane 1: Agent 对话与执行
  pane 2: 测试
  pane 3: 本地服务
  pane 4: 日志与 Git 状态

会话恢复能避免终端关闭后重新搭建环境，固定布局也降低任务切换成本。

终端编辑器在 Agent 工作流中的角色

当 Agent 已完成大部分实现，人类可能只想改一行配置、修正名称或查看上下文。Neovim 等工具允许在当前会话快速操作，不必切换到完整 IDE。

但大型重构、可视化调试和复杂代码导航仍可能更适合图形 IDE。终端编辑器是一种选择，不是 Agent 工作流的硬性要求。

人的工作发生了怎样的变化

传统开发界面假设人正在编辑一个文件。多 Agent 场景中，人更像调度者：

把父需求拆成多个可并行任务。
选择每个任务的上下文和权限。
查看进度、测试和阻塞。
在错误方向扩大前打断。
比较多个方案。
审查差异并决定合并顺序。

这种工作需要任务视图，而不只是文件视图。

现有 IDE 边栏为什么容易失配

把 Agent 聊天塞进 IDE 侧栏，可以帮助单一任务，但多任务时会挤压代码空间。传统 diff 也通常围绕“我刚改了这些行”，不一定能展示多个 Agent、多个分支和多轮验证的整体状态。

当任务持续数小时并含多个子任务时，用户需要的不是更多聊天标签，而是层级、状态、依赖和风险。

CLI 的人机交互优势是什么

启动快，几乎没有界面层负担。
日志与命令位于同一时间线。
键盘操作高效。
适合远程服务器和无图形环境。
容易用脚本批量创建会话。

对于熟悉终端的开发者和少量并行任务，这些优势足以让 CLI 成为当前高效选择。

纯 CLI 的人机交互上限在哪里

当三个模块分别包含 Web、移动端和服务端任务，每个任务又有 Agent、测试和日志时，终端窗口数量会迅速增长。即使使用 pane 和 tab，用户仍要记忆每个位置代表什么。

跨任务状态不易汇总。
大规模 diff 的视觉比较较弱。
通知、审批和风险容易埋在滚屏中。
依赖关系难以直观看见。
长期任务的历史和工件分散。

Agent 专用 GUI 应该长什么样

Agent GUI 不应只是把终端输出放进漂亮窗口。它需要围绕审查和编排重新设计：

项目、父任务和子任务的层级树。
每个任务独立工作区和分支。
运行、等待、需要输入、失败和完成状态。
测试、构建和部署结果摘要。
可展开的原始日志。
按文件、任务和风险组织的 diff。
一键打断、继续、重试和重新分派。

GUI 如何替代终端工具链的一部分

定制 GUI 可以自动创建 worktree，为每个 Agent 建立独立任务页，内置多个终端面板，提供代码 diff、文件预览和状态仪表板。用户不再需要记住每个 pane 位于哪里。

底层仍可能调用 Git 和其他 CLI。GUI 替代的是人工组织成本，不是把成熟命令全部重写。

为什么“CLI 杀死 GUI”不成立

CLI 与 GUI 服务不同层次。厂商同时 CLI、桌面应用、Web、IDE 扩展和浏览器控制，说明实际需求是多入口协同。

极客身份或流行口号不能代替工作流评估。工具选择应看任务规模、人员技能、审查需求和运行环境。

CLI 最持久的价值是什么

CLI 的长期优势是工具复用和自动化接口。编译器、测试框架、Git、容器和云平台已经提供大量命令。Agent 可以通过统一进程模型调用它们，也能把命令封装进 Skills 或脚本。

即使未来用户主要停留在 GUI，底层任务仍可能由 CLI 执行。

GUI 最持久的价值是什么

GUI 擅长让人看见复杂度：

并排比较多个候选实现。
用颜色和层级呈现状态。
预览网页、图片、文档和幻灯片。
对 diff 添加行内评论。
查看任务依赖和时间线。
用明确控件完成审批。

这些能力正对应人类在 Agent 时代增加的监督责任。

CLI、Skills 与 MCP 怎样分工

CLI 暴露本地可执行能力；Skill 可以把说明、脚本和参考资料组织成模型按需读取的工作方法；MCP 则提供结构化工具和资源协议。

三者可以组合：Skill 教 Agent 何时调用某个 CLI，CLI 也可以启动 stdio MCP 服务，GUI 再展示 MCP 工具的结果和审批状态。

一个合理的分层架构

GUI：任务树、状态、diff、预览、审批
  ↓
Agent 编排层：上下文、计划、权限、恢复
  ↓
Tool 层：MCP、结构化 API、Skills
  ↓
执行层：CLI、Git、测试、构建、浏览器
  ↓
权威状态：文件系统、仓库、数据库、远端服务

每一层都有清楚职责，用户界面不需要了解所有命令细节，执行层也不负责完整人机体验。

如何管理多个 Agent 的工作区

每个任务分配唯一名称和目标。
涉及代码时创建独立 worktree 或隔离目录。
分配独立端口、临时数据库和缓存路径。
记录基线分支与依赖任务。
定期汇总状态，不混合原始日志。
完成后运行测试和人工审查。
按依赖顺序合并。

怎样避免终端会话失控

给 session、tab 和 pane 命名。
一个 pane 只承担一种长期职责。
开发服务输出与 Agent 对话分开。
将关键结果写入结构化工件。
为长期进程保存 PID 或可查询句柄。
关闭前确认任务与进程终态。

滚屏不是状态管理。重要结论需要进入任务记录或持久文件。

审查多 Agent 代码需要什么

审查界面应从任务目标出发，而不是只展示所有改动：

这项改动满足了哪个要求。
涉及哪些文件与行为。
运行了哪些验证。
还有哪些风险和未覆盖路径。
是否与其他 Agent 修改冲突。
哪些外部副作用已经发生。

GUI 可以提供摘要和跳转，原始 CLI 日志则作为证据展开。

什么时候优先选择 CLI

单个或少量编码任务。
需要远程服务器或容器环境。
现有工作流高度脚本化。
需要组合大量开发命令。
团队成员熟悉终端。
任务以文本和代码为主。

什么时候优先选择 GUI

需要同时坚控多个 Agent 和项目。
大量工作是 diff 审查与审批。
涉及网页、图像、文档或可视化结果。
需要团队协作、评论和通知。
用户不应直接接触 shell 权限。
长期任务需要清晰状态与历史。

混合工作流怎样落地

在 GUI 中创建任务并确定权限。
编排层自动创建 worktree 和运行环境。
Agent 通过 CLI 或 MCP 完成实施。
GUI 汇总测试、日志和 diff。
人类在可视化界面审查并提出修改。
Agent 根据反馈继续执行。
合并前由权威状态和测试完成最终验证。

常见误区有哪些

使用 CLI 就代表效率更高

如果窗口混乱、任务串线和日志不可追溯，CLI 只是把管理成本转移给用户。

GUI 只是给新手使用

大型系统的状态、依赖和差异需要视觉组织，经验丰富的工程师同样受益。

多开终端等于多 Agent 编排

真正的编排还需要任务依赖、权限、状态、恢复、工件和合并策略。

worktree 能隔离所有资源

它只隔离 Git 工作目录。端口、数据库、容器、缓存和凭据仍需单独处理。

未来 GUI 会淘汰 CLI

GUI 可能成为人的主入口，但成熟 CLI 仍是底层复用、脚本和 Agent 工具的重要接口。

评估工具的检查清单

能否为任务隔离代码和运行环境。
能否查看多个 Agent 的实时状态。
能否从摘要下钻到原始证据。
能否安全打断、恢复和重新分派。
是否提供清晰 diff 与测试结果。
是否支持视觉工件预览。
底层命令是否可审计和复现。
权限是否按任务最小化。
是否处理 worktree 之外的资源冲突。
团队成员能否长期舒适使用。

总结

我们回到 CLI，是因为现有命令行生态让 Agent 能最快复用 Git、测试、构建和部署能力，也容易用 worktree 与终端会话组织并行任务。这是当前务实选择，却不代表人类未来必须一直面对滚动终端。当工作重点转向审查和编排，专为 Agent 设计的 GUI 更适合展示任务层级、状态、diff、测试和视觉结果。长期分工很可能是：CLI 留在稳定的工具复用与执行层，GUI 回到人机交互和监督层，两者通过 Agent 编排、Skills、MCP 和结构化状态连接。