AI 洞察AI 应用产品思考

对 Agent 操作 GUI 说不：从 CLI-Anything 看软件交互的下一步

CLI-Anything 爆火背后的思考：GUI 是给人设计的慢接口，Agent 需要的是直接触达操作层的快通道

2026年3月24日 6 分钟阅读 莫烦

GitHub 上港大团队开源的 CLI-Anything，两周之内涨到两万多 Stars。它做的事情用一句话概括：把任何桌面软件变成命令行工具，让 AI Agent 可以直接操作。

cli-anything

一个命令行工具，为什么能引发这么大的关注？

因为 AI 要给我们干活完成任务，无非有两种方式：

  1. AI 自己看着页面操作
  2. AI 通过命令行，不用看界面，就能用命令文本操作

而现在的大模型，在文本处理上的能力远远大于图片理解的能力。所以，越来越多人意识到，给 AI 一个带界面的软件，它觉得更难用，也更难给你一个好结果。反倒是让他用代码的思维通过命令行执行软件，对它而言就简单多了。

Agent 操作界面，是一条弯路

OpenClaw 的创始人 Peter Steinberger 说过一个很精辟的判断：App 本质上是一个 Slow API。

什么意思？人需要界面，是因为可以高效利用视觉信息处理问题。但现在的 AI 更擅长文本处理，它只需要知道有一个 export 命令可以调用就能高效完成任务。所以压根不需要让 AI 像人类一样看页面。

GUI 是给人类设计的"慢接口"，而 AI Agent 需要的是直接触达操作层的"快通道"。

这也是我在上一篇文章中分享的实践：给产品加 AI 入口时，我没有让 AI 去操作前端界面，而是直接把后端 API 接给了 AI Agent。效果立竿见影——以前运营找人跑数据要半天，现在对话框里说一句话，AI 直接调接口出结果。

CLI-Anything 爆火的逻辑和这个一模一样：把 可视化界面 拿走，直接暴露底层操作能力给 Agent。

也不是一切都要 CLI 命令化

CLI-Anything 的思路是对的——分析源码，自动生成结构化的 CLI 命令，让 Agent 用确定性的方式调用软件功能。比操作 GUI 稳定得多，高效得多。

但我在项目中集成 CLI-Anything 时，我发现了现实的局限性：

1. 它需要源码，闭源商业软件走不通。

2. 它需要接口稳定，软件快速迭代时 CLI 版本很快就会脱节。

3. 它受限于预定义命令，Agent 只能做命令集里有的事，遇到新需求就得重新生成。

所以 CLI 化最适合的场景是：开源、版本稳定、操作模式固定的软件——FFmpeg、Blender、成熟的开发工具链这类。接口不怎么变，CLI 化后长期可用。

而对于迭代快、需求灵活多变的产品，转化成 CLI 可能会产生不少副作用。所以，我们决定：不是所有软件都要 CLI 化，而是根据软件的特性选择最合适的方案。

比 CLI 更灵活的方式：Scripts 方案

通常我们可以将 CLI 等可由 Agent 执行的逻辑做成一个 Agent Skill。在我们公司的实际项目中，除了 CLI 化，我们也可以直接考虑 Agent Skill 中的原生 Scripts 标准。

简单说，就是不把能力打包成固定的 CLI 命令，而是把底层的操作脚本直接放在 Skill 中的 scripts/ 目录下，让 Agent 自己去读、去理解、去组合调用。

举个例子。假设你有一个数据处理项目，CLI 化后可能生成这样的命令：

Bash
data-tool export --format csv --date-range 2026-01-01:2026-03-24
data-tool analyze --metric retention --group channel

这些命令好用，但只能做预定义好的事情。如果运营突然说"我要把导出的数据按渠道分组，再和另一张表交叉分析"，而这个组合操作没有对应的 CLI 命令，Agent 就卡住了。

Scripts 方案不一样。你提供的不是固定命令，而是一组可组合的脚本能力：

Text
scripts/
  export_data.py      # 导出数据
  analyze_metric.py   # 分析指标
  cross_join.py       # 交叉关联
  format_report.py    # 格式化报告

Agent 拿到这些脚本后，可以自己写代码把它们串起来，灵活组合成任何它需要的工作流。接口变了？Agent 直接读最新的脚本，自己适配。需求没见过？Agent 自己写一段胶水代码，把现有脚本能力拼装成新方案。

CLI 是一个"定型的工具包"——像一套固定菜单，Agent 只能点菜单上有的。Scripts 是一个"食材库"——Agent 可以自己看食材、自己搭配、自己炒菜。

这两种方式的适用场景也很清晰：

  • 软件成熟、接口稳定 → CLI 化更好。命令固化下来，调用确定、行为可控、维护成本低。
  • 项目在迭代、需求灵活 → Scripts 方案更好。Agent 自由度高，能跟上变化，覆盖面更广。

它们不是谁替代谁的关系，而是不同阶段、不同场景下的最优选择。

软件正在长出第二个入口

不管是 CLI 化、Scripts 方案，还是我之前做的"给产品加 AI 对话入口"，本质上都在做同一件事：

给软件开一个专门给 Agent 用的入口。

这意味着未来的软件设计可能会自然地分化出两条通道：

  • 人走前门：GUI，图形界面，视觉交互——感知友好，体验优先
  • Agent 走快通道：CLI / API / Scripts——效率优先，结构化调用

这不是二选一，而是双轨并行。就像一栋大楼，顾客走大堂电梯，货物走后勤通道。各走各的路，各有各的效率。

核心不是形式，而是思路的转变

CLI-Anything 的爆火，表面上是一个开源项目的成功。但更深层的信号是：整个行业正在意识到，软件和 AI Agent 之间的交互方式需要被重新设计。

别让 Agent 操作界面了，给它一个直达操作层的快通道。

这个趋势已经悄然发生。

评论

评论基于 GitHub Discussions，请先 登录 GitHub 后发表评论。