为什么 AI Agent 都选了终端？

2025 年 2 月，Anthropic 发布了 Claude Code——一个运行在终端里的 AI 编程 Agent。

没有精美的 GUI，没有可视化的文件树，没有拖拽式的工作流编辑器。就是一个终端窗口，你打字，它回应。

51 天后，OpenAI 发布了 Codex CLI。再之后，Google 发布 Gemini CLI，Block 发布 Goose，Sourcegraph 发布 Amp。开源社区同步爆发——Aider 拿到 39K Stars，OpenCode 突破 103K Stars。

一个新品类几乎在一夜之间成型：终端原生 AI 编程 Agent。

问题来了：我们已经有了 VS Code、JetBrains、Cursor 这些经过数十年打磨的 IDE，拥有语法高亮、调试器、重构工具和数以千计的插件。为什么在 2025 年，最前沿的 AI 工具反而选择了 1960 年代的界面？

这篇文章回答这个问题。

什么是 CLI

先说基础。CLI（Command Line Interface，命令行界面）是一种基于文本的人机交互方式——你输入命令，系统返回文本结果。

它有几个核心特征：

• 文本进，文本出：输入是字符串，输出也是字符串
• 管道组合：通过 | 把多个命令串联，前一个的输出成为后一个的输入
• 标准流：每个程序都有 stdin（输入）、stdout（输出）、stderr（错误）三条标准通道
• 可脚本化：命令可以写入脚本文件，实现自动化执行

这套设计源自 1970 年代的 Unix 哲学。Doug McIlroy 的经典表述：

编写只做一件事并做好它的程序。编写能协同工作的程序。编写处理文本流的程序，因为那是通用接口。

50 年前的设计理念，和今天 AI Agent 的需求完美对齐。

接下来逐个拆解原因。

原因一：文本是 LLM 和 CLI 的共同母语

这是最根本的原因。

大语言模型从本质上就是一个「文本进、文本出」的系统。而软件开发的几乎所有产物——源代码、编译错误、测试结果、Git diff、堆栈跟踪、文档——全部是文本。

Dong Liang 在 Claude Code and The Rise of CLI 中写道：

AI 需要推理代码的每一个工件，都已经以它原生处理的媒介存在。无需翻译。

一位前 Manus 后端负责人在技术文章中进一步总结：

Unix 在 50 年前做了一个决定：一切皆文本流。LLM 在 50 年后做了几乎同样的决定：一切皆 token。这两个决定从完全不同的起点出发，汇聚在同一个接口模型上。CLI 对 LLM 来说不是「可用的」接口——而是天然契合的接口。

反观 GUI 的情况：它产生视觉输出——窗口、按钮、渲染后的页面状态。AI 与 GUI 交互必须通过计算机视觉解释屏幕，然后模拟鼠标点击和键盘操作。这个过程脆弱、缓慢，且对布局变化高度敏感。

文本流是 LLM 最高效、最可靠的 I/O 方式。而 CLI 恰好就是文本流的接口。

原因二：50 年 Unix 基础设施的免费继承

CLI Agent 天然继承了整个 Unix 工具链，无需任何额外集成工作：

# 把 git diff 通过管道传给 AI 做代码审查
git diff HEAD~1 | claude "review these changes for bugs"

# 把错误日志传给 AI 诊断
cat error.log | claude "diagnose and fix"

# 把 AI 输出通过 jq 做结构化处理
claude --print "list all API endpoints" | jq '.endpoints[]'

这种组合能力不是 AI 工具开发者构建的，而是 Unix 系统 50 年积累下来的。管道、重定向、进程间通信、文件系统抽象——所有这些基础设施都可以直接使用。

Zylos Research 的行业报告一语中的：

终端是为长时间运行的进程、并行会话、可脚本化的工作流、管道 I/O 和可组合的工具而构建的。这些特性恰好与自主 Agent 的需求精确对齐。

IDE 插件呢？它在 IDE 的扩展 API 内运行。对代码智能来说够用，但结构性地不适合编排 shell 命令、管理进程、或在 CI 管道中无头运行。

一个 CLI Agent 天生就能做这些事。一个 IDE 插件需要额外搭建一整套基础设施才行。

原因三：94% 的 Token 开销节省

这不只是架构优雅的问题，还有实实在在的成本差异。

Blake Crosley 在 The CLI Thesis（Hacker News 一周内 1,638 积分）中对比了结构化工具调用（如 MCP）与 CLI 方式的 token 开销：

为什么差距这么大？因为结构化工具协议在每次对话中都要注入完整的工具 schema。如果你注册了 84 个工具，光 schema 描述就在 Agent 做任何事之前消耗了 15,540 个 token。

而 CLI 调用不需要 schema——模型已经从训练数据中学会了标准命令行工具的用法。grep、git、npm——这些命令的语法和语义已经内化在模型权重里了。

按每天 100 次操作计算，选择 CLI 方式每月可节省约 $228。这在个人开发者层面是可观的，在企业级部署中就是决定性的差距。

原因四：Agent 的自主闭环

一个 AI 编程 Agent 不只需要读写代码，它还需要验证自己的工作。

在终端中，Agent 可以直接执行命令来形成完整的自主闭环：

读取代码 → 分析问题 → 修改代码 → 运行测试 → 检查结果 → 继续迭代

具体来说：

• 运行测试：pytest tests/ -v 直接看哪些用例通过、哪些失败
• 执行构建：npm run build 检查是否有编译错误
• 查看日志：tail -f app.log 追踪运行时行为
• 版本控制：git diff、git commit、git push 完成完整的代码提交流程
• 代码检查：eslint --fix、ruff check 自动修复风格问题

这个闭环对 Agent 的自主能力至关重要。它不是「写完代码交给人类去验证」，而是自己写、自己跑、自己改、自己确认。

GUI 工具很难提供这种完整的循环——你能想象 AI 通过模拟鼠标点击来运行 VS Code 里的测试套件吗？

原因五：编辑器无关，去除锁定

CLI Agent 不关心你用什么编辑器：

CLI Agent 直接在文件系统上操作。你可以用 Vim、Emacs、VS Code、IntelliJ、Sublime Text——Agent 不在乎。它只需要读文件、写文件、执行命令。

这意味着：

• 不被厂商锁定：你的工作流不依赖某个特定编辑器
• 全代码库感知：不受 IDE 的「当前打开文件」限制，可以扫描整个项目
• 远程开发：通过 SSH 在任何服务器上运行，无需安装 IDE

一个 Claude Code 用户可以 SSH 到生产服务器，在上面直接运行 Agent 排查问题。这对 IDE 插件来说是不可能的场景。

原因六：无头运行——CI/CD 的天然公民

这是 GUI 工具结构性无法提供的能力。

CLI Agent 可以在没有人类在场的情况下运行：

# GitHub Actions 中自动代码审查
- name: AI Code Review
  run: |
    git diff ${{ github.event.pull_request.base.sha }} | \
    claude --print "review for bugs and security issues"

• 自动化代码审查：每个 PR 自动触发
• 自动化测试生成：检测到新代码自动补测试
• 定时维护任务：通过 cron job 执行依赖更新、安全扫描
• 后台长任务：用 --print 非交互模式运行复杂重构

Anthropic 的数据显示，Claude Code 使团队的部署频率提高了 7.6 倍。这种规模化提升正是来自无头运行能力——Agent 不需要有人盯着屏幕。

Claude Code 的设计哲学：少搭脚手架，多信模型

Anthropic 工程师 Boris Cherny 在 Y Combinator 技术分享中透露了几个关键设计决策，有助于理解「为什么是终端」。

「6 个月法则」：

永远不要为今天的模型构建，要为 6 个月后的模型构建。复杂的 UI 包装器和硬编码的启发式规则往往被下一代模型淘汰。

这解释了为什么 Claude Code 的工具集极度精简——只有 8 个核心工具：

当你选择了终端作为界面，你就自然地远离了过度工程化。因为终端的约束就是：文本进、文本出、命令执行。在这个约束下，你要么把能力给模型，要么不给。没有中间那一层「看起来很智能但其实在给模型帮倒忙」的脚手架。

还有一个有趣的内部故事：当团队试图隐藏终端输出以「美化」用户体验时，内部工程师「起义」了——他们要求保留原始 bash 输出的透明性，以维持对 Agent 行为的精确操控。

透明性是终端的默认属性，而 GUI 需要刻意设计才能做到。

逆向信号：GUI 工具也在拥抱终端

一个更能说明问题的趋势是——连以 GUI 为卖点的工具都在加强 CLI 能力：

• Cursor：2026 年 1 月发布 Cursor CLI，支持 Agent Mode（--mode=plan），甚至推出了 Background Agents——不需要打开笔记本就能运行
• Windsurf：Cascade Agent 越来越多地在终端中执行命令和测试
• GitHub Copilot：从 IDE 补全起步，后来也推出了 CLI 版本

当 GUI-first 的工具纷纷补上 CLI 能力时，这本身就是对「终端是 Agent 原生界面」最好的证明。

2026 年的实际开发模式正在变成：

终端 Agent 做重活（架构重构、大规模代码迁移），IDE Agent 做日常编码，偶尔用自主 Agent 做可委派的独立任务。

不是非此即彼，而是各取所长。但当涉及「自主」和「重活」时，终端是毫无争议的主场。

行业全景：CLI-First AI Agent

最后整理一下当前的主要玩家：

几乎所有头部 AI 实验室和开发者工具公司都在押注这个方向。

不是怀旧，是架构的必然

回到开头的问题：为什么最前沿的 AI 工具选择了最古老的界面？

Lewis C. Lin 提出了一个简洁的框架——每个计算时代都有它的主导界面：

终端的回归不是技术的倒退，而是需求的回归。当交互的主体从人类变成 AI 时，人类友好的视觉界面反而成了阻碍——AI 不需要按钮、不需要语法高亮、不需要拖拽交互。它需要的是：文本流、命令执行、管道组合。

而这些，正是终端 50 年来一直在做的事。

Dong Liang 的一段话是最好的总结：

这从来不是关于界面的问题——而是关于兼容性。Unix 被设计为机器对机器的系统：文本进、文本出、设计上可组合、约定上确定性。CLI 不是 AI 的退步，而是它的原生环境——而这个环境已经等待了五十年。

终端没有变。变的是，终于有了真正能用好它的使用者。