就在近期，飞书正式开源了其 CLI 工具。不少人认为，这标志着一个清晰的趋势：主流厂商正在积极拥抱一个由 AI Agent 主导的未来，主动将自家业务改造为随时可被 Agent 调用的服务。也有人认为，这预示着工作与效率类 Agent 的落地进入新阶段，通用 AI 助理正逐渐突破传统数字世界的桎梏。
这个趋势背后，是开发者社区和 AI 从业者们对软件接口形态改造的强烈意愿。嘉宾 Yuhao 正是这一思潮的实践者之一。作为港大博士，师从黄超老师，他长期专注于 GUI/CUA 方向，代表作包括 Aria-UI、GTA1、UltraCUA 等，工作覆盖 Agent 模型训练、数据、环境和测评的多个方面。近期，他将重心转向了一个新项目：CLI-Anything。
这个项目在开源社区引发了热烈反响，不到两周就收获了超过 2 万颗星标，这本身就是一个强烈的市场信号。
本次对话，我们深入探讨了：
- 如何划分现有软件服务的“四个象限”，理解 Mock、CLI-Anything、GUI Automation 和官方 API 的定位。
- 判断一个服务是否适合进行 CLI 化改造的标准。
- 当软件本身不开放 CLI 时，如何对其进行改造，这与 Hack 软件有何本质区别。
这些话题与近期 Anthropic、Kapathy 反复提及的 Harness 哲学紧密相连。在“LLM 即 Agent”的当下，我们应如何设计 Harness，又该如何思考软件与 Agent 的互动关系？
Yuhao 的出发点很直接：让 AI Agent 能够接管人类在各行各业中的工作流，无论是局部辅助，还是端到端的全流程自动化。他的核心观点是，即使现有软件尚未准备好进行原生 CLI 改造，至少可以提供一套外部可触达的接口和更易用的改造工具。
这一宏大命题背后，还涉及哪些数据能让模型再次受益、自我进化 (Self-eval) 的挑战，以及软件未来的形态。今天或许是讨论 CLI-Anything 的最佳时机，我们有理由相信，半年到一年内，将会有越来越多的服务像飞书一样，主动开放其 CLI 端口——一个由 Agent 无缝驱动软件的未来，正变得越来越触手可及。
目录：
一、为什么从 GUI 转向 CLI
二、四个象限：理解软件与 Agent 的交互方式
三、哪些服务适合 CLI？哪些不适合？
四、CLI Anything 的工程实践：7 步流程与 Harness 哲学
五、REPL 与 Subcommand：有状态交互的价值
六、为什么 Agent 还不能驾驭复杂黑盒
七、从 OSWorld 看一个有意思的对称性
八、自进化与 Eval 的难题
九、软件的未来
一、为什么从 GUI 转向 CLI
两年前，GUI Agent 曾是一个极具吸引力的方向。理论上，只要模型能像人一样操作屏幕，就能接管几乎所有为人设计的软件，而无需软件主动开放任何接口。
然而，经过长时间实践，Yuhao 清晰地看到了 GUI Agent 的几个根本性瓶颈。
第一是脆弱性。 GUI Agent 高度依赖屏幕“定位”和“规划”能力，而这两者在模型中深度耦合，难以单独提升。你可能很容易把模型的定位能力训练得更好，但一旦想让它的规划能力更强，几乎无从定位问题根源——很多时候是“世界知识”不足，而这种知识又很难在不同软件间迁移。
第二是稳定性差。 对于那些需要高频、稳定执行的任务，GUI Agent 是一个灾难性的方案：窗口布局改变、设备更换、软件更新，都会带来显著的适配问题。
第三是整个过程更像黑箱。 多模态的规划与定位耦合在一起，使得模型训练变得难以控制和调试。
与此同时，代码生成的“飞轮”越转越快，模型能力日益强大，Harness 的概念也越来越热。Yuhao 判断：CLI 作为一种更底层、更稳定的接口形式，现在正是将软件迁移给 Agent 使用的合适时机。
二、四个象限：理解软件与 Agent 的交互方式
在深入探讨 CLI-Anything 之前，有必要先梳理几种主流的软件交互方式。Yuhao 用了一个四象限框架来理解这件事。
- 上下轴 是交互层面的区分：上方是基于 GUI 的方案，下方是基于编码或命令行的方案。
- 左右轴 则是一个有趣的划分——是否掌握源代码。左侧（Mock 软件和 CLI-Anything）都要求对源码有较强的掌控力；右侧（GUI Automation 和官方 API）则是在不拥有源码的情况下使用软件。
这四个象限分别是：
- GUI Automation：让模型直接操作真实的 GUI 界面，进行点击、拖拽、截图。优点是通用性极强，理论上所有给人用的软件都能操作；缺点就是上文所述的那些瓶颈。
- Mock 软件：构建一个仿真的假软件环境，专门用来训练 GUI Agent。这条路在大厂的多模态 Agent 团队中较为流行，本质上是承认真实软件的 API 接口不够友好，因此用仿真环境替代。
- 官方 API：厂商主动将服务暴露给外部调用，稳定、高效、原生。但这依赖于厂商的意愿，且 API 文档往往是零散的，需要额外做“渐进式披露”的工程处理。如今，越来越多的厂商开始进行 CLI 改造。
- CLI-Anything：Yuhao 将其定位为与官方 API 同侧，但更进一步——在软件现有接口不足时，主动扫描软件、理解其后端逻辑，然后为其生成一套完备的 CLI 接口。社区已有实践：例如，有人将 Google Notebook LM 包装成了 CLI 格式（完全基于 Google 暴露的官方接口），也有人包装了 Zoom（基于 Zoom 官方的底层 API）。
此外，还有一条平行路线，是基于 Web 或 Electron 应用的自动化测试技术来包装商业软件，例如将小红书、淘宝、视频网站的前端接口扫描出来再封装成 CLI。这条路能覆盖更多商业服务，适应性强，但天然受制于厂商——如果厂商主动修改接口来屏蔽这种方式，稳定性就会受影响。
CLI-Anything 选择了更底层的路线，从源码或真实后端入手，转换出的接口稳定性更高，不会随时间推移出现大的变动。
CLI 相比于普通 API 的一个关键优势在于：Unix 几十年前定下的规范让 CLI 天然具备“渐进式披露”的结构——有 help 命令、有分层子命令、有标准化的输出格式，Agent 可以非常自然地用它来探索和操作软件。
三、哪些服务适合 CLI？哪些不适合？
Yuhao 提出了一个分类标准，依据并非技术实现，而是服务交付的后果。
第一类：私有数据驱动的服务
这类服务的核心价值在于积累了大量的用户私有数据，例如 Boss 直聘（工作信息）、小红书（真实探店体验）、Twitter。无论是人还是 Agent，使用这些服务本质上都是在消费其沉淀的私有数据。这类服务的 CLI 化价值在于让 Agent 能更高效地检索和利用这些数据。
第二类：触发物理世界交付的服务
美团、Uber、顺丰这类服务，数字端的操作其实很简单——往数据库写入一条记录并广播。但其重头戏在于“最后一公里”：一个物理实体真实地为你送来外卖、叫来车、送达包裹。CLI 只能完成前半段，后半段依然需要物理世界的介入。
第三类：需要法人或真实主体背书的服务
这类服务在数字层面可完全自动化，但现实世界的合规框架要求背后必须有一个真实存在的法人或个人作为责任主体。银行转账、投行报告、合同签署均属此类。Agent 可以完成大部分工作，但那个“最后需要人存在”的护城河依然存在。
第四类：依赖积淀已久的专业黑盒的服务
这是 Yuhao 认为最容易被忽视的一类。让 Agent 处理视频，最后它可能还是会调用 FFmpeg；让它做 3D 设计，它依然离不开 Blender 的渲染引擎；CAD 软件底层有几十年积累的几何求解器，Agent 没必要从头重写。这类“暗箱算力”是过往软件工程师沉淀的护城河，Agent 正在无感地利用它们。
四、CLI Anything 的工程实践：7 步流程与 Harness 哲学
Yuhao 设计了一个 7 步的流程，但他强调整个框架刻意做得很通用——本质上只做两件事。
第一件事：拆解软件，搭建完备的 CLI 接口
让 Agent 自适应地找到软件真正的“后端”，理解其底层数据组织方式。例如，LibreOffice 的底层其实是一系列 XML 文件，只要能完整操作这些 XML，就能复现所有人类在 GUI 上能做的事。找到这个“中间形式”后，再基于它搭建一套完备的、有状态的 CLI 接口。
第二件事：做完整的端到端测试
不仅要做单元测试，端到端测试的比例要与单元测试持平。这是为了保证交付的接口真能满足人类使用该软件的完整预期。
在 Harness 的哲学上，Yuhao 的取向很清晰：不过度干预，不做太强的预设，让 Agent 自己去探索细节。
他提到社区里有一些 Pull Request 建议跳过超过 100KB 的文件，或者对读取文件的 Token 数量加硬限制。Yuhao 将这些 PR 全部打回了，因为他认为这些是模型当前的局限，而非 Harness 本身应该编码的偏见——换一个更强的模型，这些问题可能就不存在了。
关于 Harness 的层次，Yuhao 将其分为三层：
- 最底层是 Prompt。最近大家习惯将 Prompt Engineering 和 Harness Engineering 分开讲，但他的观察是，Claude Code 本身的系统提示词就有七八千字，这一层是基础，不容忽视。他提到 X 上有一个实验：只给模型一段很通用的 Harness 提示词，仅提供 Python 和 bash 两个工具，在 SWE-bench 上也能拿到接近 90% 的分数。
- 中间层是工具集设计。原则是：工具数量尽量少，工具间的功能重叠尽量小，但加起来覆盖的操作空间要尽量大。Unix 文件加字节流的设计，加上网络搜索，其实已能构成相当完备的工具集。此外，让 Agent 主动向用户提问的能力也很重要——很多时候指令本身是模糊的，Agent 提问能帮助厘清需求。
- 更高层是工程范式，例如渐进式披露、丢弃 RAG 让 Agent 自己决定如何搜索等。这些是更哲学层面的东西，由 Claude Code 的 Foundation Engineer 在推动，大家跟进即可。
五、REPL 与 Subcommand：有状态交互的价值
CLI-Anything 的核心交互形式是 REPL。Yuhao 说一开始设计时并不知道这个概念，只是想给任何软件都做出“Claude Code 那种感觉”的交互，后来才发现这就是 REPL。
REPL 最大的价值在于“带状态”。 打开一个会话后，所有操作默认都与此会话关联，无需每次都重新指定上下文。许多专业软件本就如此工作——你打开一个项目，在其中持续编辑，最后以其自有格式存档。
而 REPL 中的状态展示也很有价值。就像 Claude Code 会在下方列出哪些子代理在运行、执行什么任务，剪辑软件可以直接列出当前时间线上的滤镜，让 Agent 无需每次都 list 一遍再确认。
相比之下，Subcommand 更适合做单点操作——一次渲染、一次保存。若要在其中完成所有复杂工作，需要手动指定每一步的状态，不如 REPL 直接。两者并非替代关系，而是各有适用场景。
六、为什么 Agent 还不能驾驭复杂黑盒
一个自然的问题是：编码 Agent 已经如此强大，为何仍难驾驭 Blender、AutoCAD 这类复杂软件？
Yuhao 从三个层面解释：
- 预训练数据的占比问题。人类发展至今，大型专业软件的开源代码本就远少于普通代码。游戏引擎、CAD 软件——能叫得出名字的开源项目屈指可数，Agent 学习的来源极为有限。
- 软件本身的 Agent-Friendliness 问题。大多数专业软件的开放程度有限，其 API 是以原始代码实现的形式开放给模型学习，而非以“如何操作它”的轨迹形式。两者间存在明显差距。
- 训练目标的问题。目前 Agent 的训练目标并非“解构和重建这些黑盒”，从黑盒中获得奖励的路径更长、更不直观，这造成了当前的瓶颈。
在审查了许多软件后端后，Yuhao 发现一个规律：CLI-Anything 能成功落地的案例，往往是后端本身设计得足够优秀的软件。LibreOffice 用 XML 作为中间格式，GIMP 和 Blender 都以 Python 作为连接底层 C 编译产物的脚本层——这些都是清晰、可被 Agent 接管的接口。
反面例子则是那种将状态直接存储在前端 UI 组件里的耦合架构。处理这种情况，需要先解耦前后端，工作量巨大。商业软件中也有此问题，处理方式是让 Agent 重新 Hack 一套新的 CLI 接口，同时将状态从组件中解绑。
七、从 OSWorld 看一个有意思的对称性
在 GUI Agent 社区工作多年后，Yuhao 注意到了一个有点别扭的地方。
OSWorld 是一个 GUI Agent 评测框架。它的检查器，即评判 Agent 是否完成任务的逻辑，本身是用代码实现的——Agent 是否生成了正确的 Word 文档、PPT、视频，都是通过将这些产物转换成代码来判断的。
这让 Yuhao 联想到 Jason Wei 和姚顺雨讨论的“验证不对称性”概念：有些任务验证起来容易，但生成起来难。Jason Wei 在 BrowseComp 这个基准测试中运用了这个思路。
OSWorld 里其实也有类似结构，只是方向反了过来。既然 Agent 能通过编码来验证产物，那么从另一侧看，它其实也可以直接从编码来创建这个产物——这正是 CLI-Anything 在做的事。
这引出一个更深的问题：对于 GUI Agent 的训练，这种“人为制造不对称性”是否必要？Yuhao 觉得自己也未完全想通。制造不对称性确实能显著提升 Agent 在某一侧的能力，但这是否是最长远的路径，还有待观察。
他认为 GUI 和 CLI 两条线完全可以并行发展。在数字世界里，两者的产物格式可以双向流动——Agent 生成一半的，人类可在 GUI 里继续编辑；人类做到一半的，Agent 可在 CLI 里接着完成。这种双向等价是 CLI-Anything 在设计上刻意追求的。
他还提到社区的一个有趣需求：希望 Agent 在用 CLI 操作时，能同时将渲染结果实时投射到显示器上供人监看。这种“内存级别的旁路渲染”让人类在不干扰 Agent 工作流的情况下了解当前状态，也是 GUI 理解能力未来的一个应用方向。
八、自进化与 Eval 的难题
Yuhao 提到他最近在与 OpenClaw-RL 的作者交流，这个方向让他觉得很有潜力——在小规模上也能工作，梯度不会爆炸，确实能学到一些风格上的改变。
他的判断是：权重层面的进化绝对值得持续追求，这可能占据了模型成就的 60%~70%，剩下的才是 Prompt 和 Harness 的工程。
但 Self-evolution 最难的地方在于 Eval。如果沿用传统学术标准，就不可避免地需要引入人类评审或更强模型来做判断，而自进化的核心正是要绕开这个。风格上的改变容易识别，行为模式和能力层面的深层改变则很难量化。
Yuhao 提到 Lei Li 发表的观点——对编码 Agent 最好的试金石不是 SWE-bench，而是将其放到 Claude Code 里实际使用半小时到一小时。他非常认同，认为这本质上是一种用户 A/B 测试。只是目前工业界头部团队才能真正实践，学术界如何更方便地获取这种资源，是推动领域发展的重要问题。
九、软件的未来
CLI-Anything 接下来会如何发展？
Yuhao 的短期预期是：许多工作会像编码一样，在一两年内变成“氛围工作”。剪辑师、CAD 工程师、设计师会逐渐接过 CLI 产出的中间产物继续工作。随着模型能力增强、CLI-Anything 更完善，这条自动化链条会越来越长，直至整个工作流都可在 CLI 内完成。这与 Anthropic 近期发布的研究方向一致：AI 在许多行业的承载力其实已经很高，只是覆盖率还没跟上，而 CLI-Anything 正是推动覆盖率提升的关键角色。
对于软件服务商而言，CLI-Anything 提供了一套相对温和的迁移路径——无需大幅改动现有系统，成本不高，却能将自家软件接入 Agent 的工作流。Yuhao 认为这比 MCP 更加朴素，门槛更低，因此对服务商有一定吸引力。
他也提出一个更激进的设想：如果将 CLI-Anything 与 AI OS 的概念结合，专门构建一个 Agent-Friendly 的平台，所有安装的软件都以 CLI 形式暴露接口，证明其能产出与人类等价的专业产物，然后推动更多生态和工作流迁移进来，影响会更大，风险也更大。
那么，AI 会“吃掉”软件吗？
Yuhao 的答案是肯定的。他的出发点很直接：语言加多模态是人类最自然的交互介质，这本身就足以击穿许多底层需求。但他同时强调，软件和服务本身不会消失。FFmpeg、游戏引擎、CAD 求解器这些底层工具依然是不可或缺的基础设施，只是它们的入口将被 AI 统一替代。软件是越来越好的服务工具，而 AI 正在成为所有这些工具的统一入口。
这个过程是一种熵减吗？AI 改造各行各业，本质上是在将混乱、碎片化的工作流和服务整合成更有序、更可操作的形式。而 CLI，是实现这一目标的可行且可靠的手段。我们对这个未来持乐观态度。
发表于 3 小时前
|
查看: 3|
回复: 0
