2025 年到 2026 年间，顶级 AI 公司相继发布了一类产品：CLI 形态的 Agent 工具。

Anthropic 发布了 Claude Code，一个在终端里运行的 AI 编程助手。OpenAI 发布了 Codex CLI，Google 发布了 Gemini CLI。这一波浪潮中，几乎每家值得关注的 AI 公司都押注了命令行。

这很反直觉。命令行是 1970 年代的产物，GUI 的出现让计算机走入大众，现在移动互联网让触屏操作成为默认。按照通常的逻辑，技术的方向应该是越来越"可视化"、越来越"易用"。为什么在 AI 时代，最古老的交互形式反而卷土重来？

答案不是情怀，是工程逻辑。

GUI 对 AI 并不友好

GUI 是为人类视觉导航设计的。按钮、弹窗、拖拽、悬停效果——这些交互范式建立在人类的视觉直觉上。人类看一眼界面，扫描按钮位置，凭直觉判断下一步操作。这套机制对人类来说极其自然，几乎不需要学习成本。

但 LLM 的工作方式根本不是这样。LLM 的输入是 token，输出也是 token。它的"思考"在语言空间里发生，而不是在像素空间里。

让 AI 操控 GUI，意味着要跨越一道巨大的鸿沟：

理解成本极高。 AI 需要借助计算机视觉或 Accessibility Tree 来"看懂"界面——哪个按钮可点、哪个输入框在哪里、当前弹窗是什么意思。这不是 AI 的强项，反而是额外负担。

状态隐式且不可预测。 同一个按钮，今天可点，明天可能因为某个条件变灰。这种隐式状态对人类来说是"上下文"，对 AI 来说是不确定性——它无法可靠地推理"这个操作在什么条件下可用"。

操作不可组合。 没有办法把两个 GUI 操作用管道连起来。"搜索结果 → 过滤 → 导出"在 GUI 里是三次点击，没有办法作为一个整体传递、复用或自动化。

难以测试和验证。 AI 执行了一个 GUI 操作，怎么确认它成功了？要截图、要解析界面状态，整个反馈循环又慢又脆。

相比之下，CLI 的每个特性都像是专门为 AI 设计的。

CLI 对 AI Agent 的三大优势

可组合性

Unix 哲学的核心是："每个程序只做一件事，并把它做好；让程序能够协同工作。"

这个几十年前的设计原则，在 AI 时代焕发出新的意义。

CLI 工具通过标准输入输出串联。linkly search "React 性能优化" | head -5 可以把搜索结果传给下一个命令。linkly search "架构设计" --json | jq '.results[].doc_id' 可以提取所有文档 ID 用于后续处理。

对 AI Agent 来说，可组合性意味着可以把多个命令链接成复杂的多步骤工作流，每一步的输出都是结构化的文本，可以被下一步消费。没有 GUI 的"点击 → 等待 → 截图 → 解析"循环，只有干净的输入输出。

可预测性

每个命令的行为完全由参数决定。linkly search "数据库" --limit 10 今天执行是这个结果，明天执行（假设数据库没变）还是这个结果。没有隐式状态，没有"这个功能上次为什么好使现在又不好使"的困惑。

这对 AI 极其重要。AI 在推理一个工具时，需要建立一个心智模型：这个工具的输入是什么，输出是什么，有什么副作用。GUI 的隐式状态让这个心智模型充满不确定性。CLI 的显式参数让这个心智模型可靠而精确。

linkly read 42 --offset 80 --limit 100——这个命令的含义完全由参数决定。AI 可以精确推理它的行为，不需要猜测任何隐式上下文。

可审计性

所有 CLI 操作都是可记录的文本序列。AI 执行了什么命令、得到了什么输出，都是人类可读的文本。

这种透明性有两个好处。

对 AI 自身：可以做自我检查。"上一步 linkly search "合同模板" 返回了 0 个结果，说明关键词不对，换成 合同 范本 再试。"这种基于文本的自我纠错是 AI Agent 能够可靠工作的基础。

对人类：可以做事后审查。你可以查看 AI 运行了哪些命令、每步的输入输出是什么，整个推理链路一目了然。GUI 操作的"点了什么"很难被追溯，CLI 操作的日志天然就是审计记录。

Linkly AI CLI 的设计实践

LinklyAI 是我们自己开发的本地搜索引擎和知识库创建软件。在设计 Linkly AI 的 CLI 工具时，我们从一开始就把 AI Agent 当作主要用户之一来考虑。

4个精心设计的核心命令

Linkly AI CLI 的核心命令只有四个：

linkly search <query>                          # 搜索文档，返回结构化列表
linkly outline <doc_id>                        # 查看文档大纲
linkly read <doc_id> [--offset N] [--limit N]  # 精确读取指定行范围
linkly grep <pattern>                          # 全文正则搜索

这四个命令完全符合 Unix 哲学：每个只做一件事，有明确的输入输出契约。AI Agent 可以把它们任意组合成复杂的检索流程。

一个典型的 Agent 工作流如下：

# Agent 先确认工具可用
which linkly && linkly status

# 搜索文档
linkly search "React hooks 性能" --json

# 查看感兴趣文档的大纲，定位目标章节
linkly outline 42

# 精准读取目标章节
linkly read 42 --offset 80 --limit 100

每一步的输出都是结构化文本，可以直接被 AI 消费和推理。没有任何 GUI 操作，没有任何视觉解析的负担。

与管道等进行组合

CLI 的另一个优势是可以和系统中其他命令自由组合，带来超出单个工具能力边界的新能力。

过滤和提取：--json 输出可以直接接 jq 提取字段，结果再传给下一个工具：

# 搜索文档，只取 doc_id 列表，再批量获取大纲
linkly search "数据库设计" --json | jq -r '.results[].doc_id' | xargs -I{} linkly outline {}

与 grep 组合做二次过滤：先用语义搜索缩小范围，再用精确关键词过滤：

linkly search "架构设计" | grep -i "微服务\|分布式"

统计和分析：配合 wc、sort、uniq 等做文档统计：

# 统计知识库里有多少篇 PDF
linkly search "" --json | jq '.results[].type' | sort | uniq -c

与脚本结合：在 shell 脚本里批量处理，自动化重复任务：

# 把所有搜索到的文档大纲导出到一个文件
linkly search "产品设计" --json \
  | jq -r '.results[].doc_id' \
  | while read id; do linkly outline "$id"; done \
  > all-outlines.txt

GUI 工具无法参与这些组合。CLI 工具的输出是文本流，天然可以被任何其他工具消费，这让整个系统的能力远大于各个工具的简单相加。

CLI 也是最简单的 MCP 桥接方式

CLI 和 MCP 并不是对立的。linkly mcp 一条命令可以把 CLI 变成一个 stdio MCP 服务器，供任何支持 MCP 的 AI 客户端使用：

{
  "mcpServers": {
    "linkly-ai": {
      "command": "linkly",
      "args": ["mcp"]
    }
  }
}

这比直接配置 HTTP MCP Server 简单得多——用户不需要知道端口号，不需要手写 JSON 里的 URL，只需要告诉 AI 客户端"运行这个命令"。

CLI 成了 MCP 生态的入场券，对用户几乎零配置摩擦。

更宏观的趋势

Claude Code 选择优先发布 CLI 形态而不是 IDE 插件，这个决定背后有清晰的工程逻辑：IDE 插件受限于宿主环境，CLI 工具可以在任何有终端的地方运行，可以被任何 Agent 调用，可以和任何其他工具组合。

这揭示了一个更根本的规律：AI Agent 调用工具的本质，就是在执行命令。工具调用（function call / tool use）从语义上就是 CLI——给定名称和参数，返回结果。CLI 工具天然就是 Agent 可以调用的函数，不需要任何转换层。

"Terminal as the new IDE"这个说法早在 AI 兴起之前就有人提过，但在 AI 时代它获得了全新的含义。不只是"在终端里写代码"，而是"Agent 通过终端与世界交互"。

过去，CLI 是技术人员的专属工具。未来，CLI 可能会成为 Agent 的通用语言——人类通过自然语言和 Agent 对话，Agent 通过 CLI 和系统交互。

小结

GUI 的地位不会受到太大影响，它仍然是人类直接操作计算机的最佳界面。但当你的 AI 工具需要调用另一个工具时，CLI 是最自然的桥梁，会有更多的软件为了顺应 Agent 习惯推出更多的 CLI 工具。

想试试在终端里搜索你的文档？看看这两篇文章：不离开终端，让 AI 搜索你的文档 和 一行命令，让 30+ AI 工具读取本地文件。