软件的下一个用户不是人类，而是 Agent

"Today's Software Serves Humans. Tomorrow's Users will be Agents." ------ CLI-Anything

阅读时长 : ~10 min | 难度 : 进阶 | 前置知识: 对 AI Agent（如 Claude Code、Cursor）有基本了解，了解 CLI 的基本概念

读完本文你将:

能够清晰阐述软件界面从 GUI → API → CLI → Agent-Native 的演进逻辑，以及为什么 CLI 是当前 Agent 与软件交互的最佳协议
理解 CLI-Anything 项目的 7 阶段流水线如何让 AI Agent 自动将任意 GUI 软件转化为可编程工具
获得一个判断框架：面对"让 Agent 操控软件"这个需求，什么时候该用 GUI Agent、什么时候该用 MCP、什么时候该用 CLI

TL;DR: AI Agent 正在成为软件的新用户，但今天 99% 的软件是为人类设计的 GUI 程序。CLI-Anything 提出了一条务实的路径：用 AI Agent 分析软件源码，自动生成生产级 CLI，让 Agent 通过结构化命令操控 GIMP、Blender、LibreOffice 等专业软件------不是模拟点击，不是重新造轮子，而是直接调用真实软件后端。这种"Agent-Native"的思路，可能比 GUI Agent 和 MCP 更接近未来软件生态的实际样貌。

为什么聊这个

前段时间，我在用 Cursor 做一个数据可视化项目时，想让 Agent 帮我批量处理一些 SVG 图表------调整颜色、导出 PNG、统一尺寸。Cursor 能轻松帮我写代码，但当我说"帮我用 Inkscape 打开这个 SVG 并导出 300dpi 的 PNG"时，它就懵了。

这个场景让我意识到一个根本性问题：AI Agent 越来越强大，但它们几乎无法使用人类的专业软件。

GIMP、Blender、LibreOffice、Audacity------这些工具承载了人类几十年的创意和生产力积累，但它们是为鼠标和键盘设计的。Agent 无法点击菜单、无法拖拽滑块、无法在弹窗里做选择。这不是 Agent 的问题，而是软件的接口形态不匹配。

就在这个时候，我遇到了 CLI-Anything 这个项目。它的思路简洁而大胆：用一条命令，把任意 GUI 软件变成 Agent 可以操控的 CLI。不是模拟鼠标点击，不是重写一遍软件，而是真正调用 GIMP 的 Script-Fu、Blender 的 bpy、LibreOffice 的 headless 模式------把人类的专业工具原封不动地交到 Agent 手中。

这篇文章，我想从这个项目出发，聊一聊一个更大的话题：软件的"用户"正在发生代际更替，而我们的软件架构还没有准备好。

软件界面的四次进化

回顾一下软件与用户交互方式的演变，你会发现一条清晰的主线：

第一代：CLI（1970s-1980s） --- 最早的软件界面就是命令行。ls、grep、gcc。这个时代的软件天然对机器友好，因为输入输出都是结构化文本。

第二代：GUI（1984-至今） --- Macintosh 和 Windows 让普通人也能使用计算机。但从机器的角度看，GUI 是一次"倒退"------它把结构化的操作编码成了像素和坐标。

第三代：API / SDK（2000s-至今） --- Web 时代催生了 REST API、GraphQL、SDK。但 API 通常只覆盖软件功能的一个子集，且每个软件的设计千差万别。

第四代：Agent-Native（2024-） --- 软件的"用户"不再只是人类，还包括 AI Agent。Agent-Native 的软件需要满足：可发现性 （Agent 能自主了解软件能力）、结构化 I/O （机器可解析）、可组合性 （操作可自由串联）、确定性（相同输入 → 相同输出）。

有趣的是，这四个特性在第一代 CLI 里就已经具备了。历史画了一个圈，CLI 从起点变成了终点。

Agent 操控软件：当前的三条路

在"让 Agent 操控软件"这个赛道上，目前有三种主流方案，各有优劣：

路径一：GUI Agent（截图 + 点击）

以 Anthropic 的 computer-use 和各种 RPA 方案为代表。Agent 通过截图理解屏幕，然后模拟鼠标点击。

优势：不需要软件做任何改造，理论上能操控一切 GUI 程序。

劣势：脆弱（UI 变化就失败）、慢（每次需要截图+视觉推理）、昂贵（图像理解消耗大量 token）、不确定性高、难以验证操作结果。

路径二：MCP / Function Calling

MCP 和 Function Calling 让 Agent 通过结构化的函数调用与工具交互。每个工具封装为一个函数。

优势：结构化、确定性好、无视觉理解成本。

劣势：需要逐个适配（每个软件都要写 MCP Server）、覆盖面有限（通常只暴露一小部分功能）、维护成本高、大多无状态。

路径三：CLI-Anything（源码分析 → 自动生成 CLI）

CLI-Anything 选了一条不同的路：让 AI Agent 分析软件源码，自动生成一个生产级 CLI。

优势：自动化（Agent 自主完成）、全功能覆盖（通过源码分析）、调用真实软件（不是 toy implementation）、有状态（Session + Undo/Redo）、双模式（REPL + 子命令）。

劣势：需要源码、依赖强模型、首次生成后可能需要多次 refine。

一张表说清三条路的取舍

维度	GUI Agent	MCP / Function Calling	CLI-Anything
改造成本	零	中（需写 MCP Server）	低（Agent 自动生成）
功能覆盖	理论上 100%	通常 10-30%	可迭代到 70-90%
调用速度	慢（视觉推理）	快	快
确定性	低	高	高
Token 成本	高（图像理解）	低	低
状态管理	依赖 GUI 状态	通常无状态	内置 Session
适用场景	无源码、临时使用	有明确 API 的服务	有源码的专业软件

这三条路并非互斥，而是互补。GUI Agent 是兜底方案，MCP 适合云服务，CLI-Anything 适合有源码的桌面/专业软件。

CLI-Anything 的核心设计

CLI-Anything 最打动我的设计理念，浓缩成一句话：我们不重新实现软件，我们为软件建造一座 Agent 可通行的桥。

"Use the Real Software" 哲学

这是整个项目的第一原则，也是它与大多数 AI 工具包装器的根本区别：

举个例子，如果你要做一个"让 Agent 能处理图片"的工具，最常见的做法是用 Pillow 重新实现一个简化版：

python 复制代码

# 常见做法：用 Pillow 重新实现，只有 GIMP 1% 的功能
from PIL import Image, ImageFilter
img = Image.open("photo.jpg")
img = img.filter(ImageFilter.GaussianBlur(radius=5))
img.save("output.jpg")

CLI-Anything 的做法完全不同：

python 复制代码

# CLI-Anything：生成中间文件，交给真实 GIMP 引擎处理
def apply_filter(project, filter_name, **params):
    script = build_script_fu(project, filter_name, params)
    subprocess.run(["gimp", "-i", "-b", script])

它不替代 GIMP，它成为 GIMP 的命令行代言人。 每一个生成的 CLI 背后都是真正的专业软件引擎在工作：LibreOffice 的 --headless 模式、Blender 的 --background --python、Shotcut/Kdenlive 的 melt 渲染器。

7 阶段自动化流水线

CLI-Anything 的另一个核心创新是全自动构建流水线。你只需要给它一个软件的源码路径：

bash 复制代码

/cli-anything ./gimp

Agent 会自主完成从分析到发布的全过程：

每个阶段的关键产出：

Phase 1 源码分析 --- 找到后端引擎（如 GIMP 的 GEGL + Script-Fu），映射 GUI 操作到 API 调用
Phase 2 架构设计 --- 设计命令分组、状态模型、输出格式（--json for agents）
Phase 3 代码实现 --- 基于 Click 框架生成完整 CLI，包括 REPL 模式、JSON 输出、Session 持久化
Phase 4 测试规划 --- 先写 TEST.md（plan before code）
Phase 5 测试编写 --- 四层测试：Unit → E2E（中间文件）→ E2E（真实软件）→ CLI Subprocess
Phase 6 文档更新 --- 测试结果追加到 TEST.md
Phase 7 发布安装 --- pip install -e . 安装到 PATH，Agent 通过 which 发现并使用

这个流水线已经在 11 个专业软件 上验证通过，产出了 1,508 个测试，100% 通过率。

HARNESS.md：Agent 可执行的 SOP

CLI-Anything 最让我佩服的设计之一是它的 HARNESS.md------一份经过 11 个 harness 实战检验的方法论规范。这份文档的读者不是人类，而是 AI Agent。

它编码了很多只有做过的人才会知道的经验：

Rendering Gap：GUI 应用在渲染时才应用特效。如果 CLI 操作了项目文件但用简化工具导出，所有特效会被静默丢弃
Filter Translation 陷阱 ：ffmpeg 不允许同一个滤镜出现两次。亮度+饱和度（都映射到 eq=）必须合并
Timecode 精度 ：29.97fps 用 int() 会截断丢帧，必须用 round()
输出验证 ：不能信 exit code 0。要验证 magic bytes（%PDF-）、ZIP 结构、像素分析、Audio RMS 值

这是一种新的知识沉淀方式：不是写给人看的 wiki，而是写给 Agent 执行的 SOP。

看个实际的例子

Agent 通过 CLI-Anything 生成的 CLI 能做什么？以 LibreOffice 为例：

bash 复制代码

# 创建一个 Writer 文档
$ cli-anything-libreoffice document new -o report.json --type writer
✓ Created Writer document: report.json

# 添加标题和表格
$ cli-anything-libreoffice --project report.json writer add-heading \
    -t "Q1 Report" --level 1
$ cli-anything-libreoffice --project report.json writer add-table \
    --rows 4 --cols 3

# 导出为真正的 PDF（调用 LibreOffice headless 引擎）
$ cli-anything-libreoffice --project report.json export render \
    output.pdf -p pdf --overwrite
✓ Exported: output.pdf (42,831 bytes) via libreoffice-headless

# JSON 模式，方便 Agent 解析
$ cli-anything-libreoffice --json document info --project report.json
{
  "name": "Q1 Report",
  "type": "writer",
  "pages": 1,
  "elements": 2,
  "modified": true
}

注意 export 步骤：CLI 先生成合法的 ODF 文件，然后调用 libreoffice --headless --convert-to pdf 做真正的渲染。产出的 PDF 和你在 GUI 中导出的完全一致------因为就是同一个引擎。

这个思路的深远影响

CLI-Anything 是一个具体的项目，但它背后的思路有更广泛的含义。

Agent 的能力边界被重新定义

如果 Agent 能操控 GIMP、Blender、Audacity、LibreOffice，它的能力就从"文字处理"扩展到了"全领域生产力"：

一个 Agent 可以完成这样的端到端工作流：读取需求文档 → 用 Blender 建模渲染 → 用 GIMP 后处理 → 用 LibreOffice 生成手册 → 用 Inkscape 制作图标。每一步都调用真正的专业软件，而不是用一个 AI 模型勉强输出。

软件的价值公式变了

传统：软件价值 = 功能 × 用户体验。GUI 做得好，用户就多。

Agent 时代：软件价值 = 功能 × Agent 可及性 。一个功能强大但只有 GUI 的软件，在 Agent 生态中的价值可能不如一个功能稍弱但提供了完善 CLI 的软件。CLI / API 不再是"给开发者用的附属品"，它们可能是软件在 Agent 时代的生命线。

GUI Agent 可能不是终局

很多人对 GUI Agent 抱有很高期望。但 CLI-Anything 提供了一个反思角度：如果有更好的接口，为什么要走最慢、最贵、最不可靠的路？

截图+点击是 GUI Agent 不得不走的弯路，因为大多数软件只提供了 GUI。但如果我们能用 AI 快速为软件生成 CLI，那"让 Agent 学会点击"可能从一开始就不是正确的问题。正确的问题是：怎样最快地让软件有一个 Agent 友好的接口。

局限性与冷思考

客观来说，CLI-Anything 的方案也有其边界：

依赖源码：对闭源商业软件（Photoshop、Premiere）走不通。这也是 GUI Agent 仍有价值的原因
模型能力要求高：需要前沿模型才能可靠生成。弱模型可能产出不完整的结果
需要迭代 ：一次 /cli-anything 通常无法覆盖全部功能，需要多次 /refine
生态碎片化：已适配 5 个 Agent 平台（Claude Code、OpenCode、OpenClaw、Codex、Qodercli），每个平台集成方式不同

这些是真实的限制，但更像是"当前的工程挑战"而非"根本性的方向问题"。

总结与思考

回到最初的问题：软件的下一个用户是谁？

CLI-Anything 用 11 个专业软件和 1,508 个测试给出了一个具体的回答：Agent 正在成为软件的新用户，而 CLI 是当前最务实的 Agent-Software 接口。

核心要点：

CLI 是 Agent 时代的"万能接口" --- 结构化、可组合、自描述、确定性
不要重新发明轮子 --- 真正的价值在于让 Agent 操控真实的专业软件引擎
SOP 可以编码为 Agent 可执行的知识 --- HARNESS.md 模式展示了一种新的经验沉淀方式

对软件开发者，我的建议是：现在就开始考虑你的软件的 Agent 可及性。你的软件有没有 headless 模式？核心操作能不能通过命令行完成？输出能不能结构化为 JSON？这些看似简单的问题，可能决定了你的软件在 Agent 时代的竞争力。

未来几年，我们很可能会看到一波"软件 Agent-Native 化"的浪潮。CLI-Anything 提供了一条可行的路径，而它代表的思想------让现有软件适应新的用户（Agent），而不是从零开始为 Agent 重建一切------可能比任何具体的技术方案都更有价值。