当 AI 学会“不看屏幕”：AI 操控电脑的亚秒级革命

抖音上一条 40 秒的视频说：AI 控制电脑，从卡 5 秒到亚秒级，秘诀是“不截屏”。
这句话背后，其实是一整套架构选择。本文把它讲透，也讲讲我们自己在做的事。

一、那个尴尬的 5 秒钟

过去一年，很多人试过让 AI“帮我操作电脑”：打开浏览器、填个表单、把某个文件夹里的截图归档、把一张表格的数据抄进网页。

体验基本一致 —— 慢，而且不放心。

你说一句“帮我把桌面那几个截图归档到文件夹里”，然后就开始等。屏幕上的 AI 像是在思考人生：看一遍屏幕、想一想、动一下鼠标、再看一遍屏幕、再想一想…… 一轮下来，5 秒钟是常态，10 秒也不稀奇。

更难受的是它会“点歪”。明明要点的按钮在左边第三个，它偏偏点到了右边那个，然后一脸无辜地继续往下做，最后交给你一个面目全非的结果。

这种体验劝退了大量想用“电脑智能体”的人。大家的第一反应通常是：模型还不够强。

但真相往往不是这样。

二、先分清三种做法

在讨论“为什么慢”之前，得先把“AI 操控电脑”这件事的几种做法分清。市面上大致有三代：

大部分人今天用到的其实是第二代。它看起来最“智能”—— 毕竟人不就是看着屏幕操作的吗？但它在工程上有两个死结。

三、老路线的两个死结

最常见的做法是「截屏 + 视觉大模型」：

截一张全屏图  →  把图塞给视觉大模型  →  模型告诉你"点 (832, 417)"  →  执行  →  再截一张图 …

死结一：屏幕是“信息量最大、信息密度最低”的载体。

一张 1920×1080 的截图，压缩成 JPEG 也有几百 KB。为了表达“这里有个按钮、那里有个输入框”，我们付出了几百 KB 的代价，而模型真正需要的其实只是几行文字：[按钮] 提交、[输入框] 用户名。

换句话说，我们每天在做的，是把结构化信息先渲染成像素，再让模型从像素里把结构猜回来。这一来一回，全是损耗。

死结二：每一步都要重新“看一遍”。

真正贵的从来不是算力，而是重复观测。每做一个小动作，就要重新截屏、重新编码、重新推理一遍。动作越多，重复观测越多，延迟和成本就线性堆上去。

所以「5 秒」不是模型不够快，是架构本身就在做无谓功。你换更强的模型，只会让它每秒烧更多的钱、依然是那个量级的延迟。

四、“读控件树”到底是什么意思

视频里提到的 Third Hand，走的是另一条路：不截屏，改读系统的“控件树”。

什么叫控件树？其实每个操作系统里面，早就有一棵描述“当前窗口里有什么”的树：

• Windows 上叫 UI Automation（UIA）
• macOS 上叫 Accessibility（AX）
• Linux 上叫 AT-SPI。

这棵树最初是为无障碍设计的 —— 给读屏软件用，让视障用户也能操作电脑。它长这样（示意）：

窗口「新建订单」
 ├─ 文本「订单号」
 ├─ 输入框 e12  (name=订单号, 值=空)
 ├─ 下拉框 e13  (name=客户)
 ├─ 按钮   e14  (name=提交, 可用)
 └─ 按钮   e15  (name=取消, 可用)

它不是图像，是结构化文本。于是：

• 感知从“几百 KB 的像素”变成“几十个 token 的文字” —— 便宜了几千倍
• 动作从“点 (832, 417)”变成“点 e14” —— 不再猜坐标，也就不会点歪
• 观测可以只取“变化的部分”（diff）—— 不再每步重看全屏。

一句话：把“看屏幕”换成“读结构”。 这不是 AI 变聪明了，是 AI 终于拿到了它本该拿到的输入格式。

我们自己的设备控制工具里，就有一个 device_uia（读界面控件树）。所以这条路线对我们来说，不是“要不要学”，而是“要不要把它用足”。

五、把决策拆成两层

光换“眼睛”还不够，第二个关键是把决策拆开。

老路线的做法是：每一步动作，都要问一次大模型 —— “现在我该点哪？” 大模型很聪明，但很慢，也很贵。做 20 步，就是 20 次大模型推理，每一次都要把当前界面重新描述一遍。

新路线把它拆成两层：

大模型只负责想清楚要做什么（任务分解），具体怎么做（敲哪个键、点哪个按钮）交给一个极快的底层决策器。

这就是视频里那句“100 毫秒内选出下一步点谁”的来源 —— 不是模型变快了，是不再用大炮打蚊子。

而且这个“分层”是有普适性的：规划者负责“要什么”，执行者负责“怎么做”，两层之间用一份结构化的目标清单通信。你在 GUI 自动化里见过它，在机器人、在编译、在任务编排里都会再见到它。

六、“亚秒级”意味着什么，不意味着什么

先把标题党的部分说清楚：

“亚秒级”指的是单步，不是整个任务。

一个真实任务仍然是几步到几十步。假设单步从 5 秒降到 0.3 秒，一个 10 步的任务从 50 秒降到 3 秒 —— 这是巨大的提升，但它仍然是“几秒”，不是“一点就完”。而且任务越长、“想”的比重越大，端到端的收益就越没有单步看起来那么惊人。

其次，这条路有明确的适用范围：

1. 只对有完整无障碍树的应用有效。 标准 Windows 控件、Office、浏览器页面都没问题；但自绘界面（游戏、部分聊天软件、Electron 自绘 UI、画布类应用）根本没有控件树，读出来是空的。这时候必须退回 OCR / 视觉兜底 —— 连同路线的开源实现自己也这么写。
2. 跨平台支持还不均衡。 Windows 的无障碍树质量参差不齐，某些老应用的控件信息残缺，甚至需要额外的桥接层。
3. 它不解决“理解”的问题。 控件树只告诉你“屏幕上有什么”，不告诉你“用户到底想要什么”。后者仍然要靠大模型，靠上下文，靠对业务的理解。

所以正确的理解是：它优化的是“手和眼”，不是“脑”。

七、这条路线的开源现状

有个值得说的事实：“读控件树”这件事，开源社区早就在做了。

我核过几个同路线的开源项目，它们的说法几乎一模一样：

“点真实的 UI 元素，而不是猜像素坐标。”
“把无障碍树剥枝成一份精简快照。”
“用元素引用（ref）而不是坐标。”
“跨 macOS / Linux / Windows / Chromium。”
“以 MCP server 形态接入 AI 编程助手。”

也就是说，视频里讲的那条技术路线 —— a11y-first（无障碍优先）的 computer use —— 不是某个产品的独门秘籍，而是一个正在成型的行业共识。区别只在于谁的工程细节做得更扎实、谁把延迟压得更低。

八、对我们自己的启发

有意思的是，这条路线和我们手上正在做的事高度重合。

我们有一套设备控制工具：device_uia（读界面控件树）、device_ui（点击输入）、device_exec（执行命令）、device_screenshot（截图）。也就是说 —— 我们本来就有“读控件树”的能力。

但从这条视频里，我们至少能借三样东西：

第一，快慢分层。 我们现在是“每个动作一趟云端大模型”，所以慢、而且贵。把“目标规划”留在云端，“下一步点哪”下沉到端侧（不一定是小模型，也可以是一段确定性脚本/状态机），就能同时治延迟和成本。

第二，元素引用代替像素坐标。 我们的 UIA 已经能拿到控件，但还没做成“结构化快照 + 元素 ID”的形态。一旦做成 click e14 这样的动作形态，误点率会显著下降，而且上下文成本极低 —— 一次快照可能只有几十个 token。

第三，观测做增量。 自动化真正的开销在“每步重看一遍”。把观测压成 diff，和我们做任务台账、增量比对是同一个思路 —— 这是通用的工程直觉，不限于 GUI。

顺便说一句：视频里那条“通用大模型只负责拆目标清单”的分工，和我们做多智能体任务编排时“规划者和执行者分离”是一模一样的道理。同一个设计原则，在 GUI 自动化里叫“分层决策”，在任务系统里叫“规划/执行分离”。

九、给做同类产品的几条建议

如果你也在做“让 AI 操作电脑”，下面几条是从这条路线里提炼出来的、可以直接落地的建议：

1. 先接无障碍树，接不上再退视觉。 把“读控件树”当成主路径，OCR/视觉当成兜底，而不是反过来。这一条决定了你的基础成本量级。
2. 动作永远用元素引用，不用坐标。 坐标是“渲染结果”，元素是“语义”；语义才是稳定的、可复用的、可测试的。
3. 把“规划”和“执行”分成两个进程/两个模型。 不要让大模型既当军师又当小兵 —— 它每多做一步小决策，你就在多烧一次大模型的推理。
4. 观测做增量。 记住上一次的快照，只把变化喂给决策层。这是把长任务的成本从“线性”压成“接近常数”的关键。
5. 对没有控件树的应用，诚实地降级。 明确告诉用户“这类应用我得更慢地看屏幕”，比假装自己无所不能要好。
6. 把“能点对”和“点得准”分开测。 单步成功率、端到端成功率、单步延迟、总延迟 —— 这是四个不同的指标，别用一个“成功率”糊过去。

十、结语：AI 的进步，常常是把输入换对

回头看，这条视频最值钱的一句话不是“亚秒级”，而是“抛弃了截屏 + 视觉大模型”。

它提醒我们一件事：很多时候 AI 表现得“不够聪明”，不是模型不行，是我们喂给它的输入不对。

给一张图，它只能猜像素；给一棵控件树，它立刻能精确地下手。给一句模糊的话，它只能泛泛而谈；给足上下文，它就能写出你独有的东西。给一个没有边界的任务，它只能瞎猜；把任务拆成可验证的小目标，它就能稳稳地往下走。

这也是我们这些做系统的人最该记住的：与其期待下一代模型更强，不如先把当下的输入和架构，摆到它最容易发力的位置上。

模型会越来越强，这个不用我们操心；但“喂什么给它”这件事，永远是我们自己的责任。