反方：让 agent 去点屏幕，是在逼它模仿人的感知局限

前三篇都建立在同一个前提上：agent 通过图形界面操作产品 —— 截图、定位、点击。

CLI-Anything 说这个前提本身就是错的。

它的核心指控是一句话：GUI agent 的做法，是在逼 agent 模仿人的感知局限，而不是发挥它在结构化数据处理和程序化控制上的长处。

三条指控

一、交互本身很脆。 原文点名的是像素级交互、时序依赖、基于坐标的动作 —— 界面一变就全断。

这条我有第一手数据可以印证，而且比它说的更细。我拿一个视觉模型在真实截图上量坐标，报出来的位置恒定偏左约 16%：报 638，真值 760；报 487，真值 578。比值稳定在 0.84 附近，反推 1519 × 0.841 ≈ 1280 —— 模型内部把图缩到 1280 宽再报坐标。

把 x 除以 0.841 之后，四个控件全部落在 2–3 像素内。模型的定位其实是准的，错的是坐标空间的换算。

这恰恰坐实了「脆」这个指控的一半：一层不显眼的分辨率换算，就能让全部点击系统性偏移，而且不报错。 执行框架的模型适配层就是干这个的，可它意味着每换一个模型都要重新对一次坐标系。

二、被迫模仿人。 人看屏幕是因为人没有别的接口。agent 有 —— 它可以直接读结构化数据、可以精确调用函数。让它去看一张位图再猜哪儿能点，是把它按在人的能力边界里。

三、有损的翻译。 从「界面的语义」到「一张位图」再到「一个坐标」，每一步都在丢信息。而丢掉的那部分（这个按钮是什么、点了会发生什么）恰恰是判断该不该点的依据。

把应用改造成命令行 harness：保留功能，但暴露为 AI 原生交互优化的机器可读协议。它们做了一个叫 CLI-Hub 的平台来实现这个想法。

「agent-native」这个词的意思是：接口按 LLM 的工作方式设计，而不是按人的感知方式设计 —— 确定性执行、程序化控制，而不是截图理解。

先说力量：它把一个大家默认接受的前提翻出来质疑了，而且理由站得住。GUI 自动化这条路之所以流行，很大程度上是因为「产品已经有 GUI 了」，而不是因为 GUI 是最适合 agent 的接口。这是路径依赖，不是设计选择。

再说空缺，而且这一条必须说清楚：那篇的摘要里没有任何 GUI 与 CLI 的性能对比数字。 它是一个理论论证加一个平台，不是一次对照实验。

这让它的地位很特别：论证有说服力，但没有证据。 一篇主张「换条路」的文章，最该给的恰恰是「换了之后好多少」，而这个数没有。

所以正确的读法是：把它当成一个该被认真考虑的假设，而不是一个已经被证明的结论。

抛开那篇没给的对比，这个问题本身值得回答。我的判断是分三种情况：

该走 CLI / API 的：

必须走 GUI 的：

两者都要的： 这可能是多数真实项目的答案。用 API 铺数据和前置条件（快、稳、便宜），用 GUI 验最后那一两步用户真正看见的东西。把「造场景」和「验现象」分开，前者走程序，后者走界面。

我在做的是从需求生成可运行的 UI 测试，走的是 GUI 这条路。读完这篇我不打算换路，但有两处要改：

一、成本账要按这条路的真实数字记。 实测一次视觉调用 85–90 秒，一条四步用例十六分钟。如果同样的验证能在 API 层做，那就是几百倍的差距。这个差距大到必须在设计时就分流，而不是等跑不动了再说。

二、把「这一步为什么必须走界面」变成一个显式判断。 现在我的用例里每一步都走界面，因为那是唯一的执行方式。按上面那个三分法，其中相当一部分（登录、造数据）本可以走程序。每一步都走界面，等于把最贵的手段用在了最不需要它的地方。

它的替代方案有个明显的前提：你能改那个应用。 把应用改造成 CLI harness，意味着你有权限、有时间、有意愿去改产品本身。做测试的人经常没有这个权限 —— 被测系统是别人的，你只能从外面碰它。这个前提那篇没有强调，但它决定了这条路对多少人可行。

「机器可读协议」也会漂。 CLI 和 API 一样会改版本、改参数、改语义。它比像素坐标稳，但不是不变的。把脆弱性从坐标转移到协议，是降低而不是消除。

这一篇我只读了摘要级的材料。 平台的具体设计、CLI-Hub 怎么做转换、有没有实际案例，我没有深入。所以上面对它的评价只针对它的论点，不针对它的实现。

四篇的共同点是它们都在降低期望。这不是坏事 —— 一个最好成绩 26.4%、自愈会作弊、成本高两个数量级的方向，值得做，但不值得用「马上就能替代人工测试」的话去描述它。