操作电脑的 agent

大多数 agent 调用 API，而操作电脑的 agent 摆弄的是图形界面：截屏、决定点哪里、点击、再截屏。

它的吸引力在于通用。任何有屏幕的软件都能自动化，包括那些没有 API、也永远不会有 API 的老系统。

代价是每件事都更难——感知、精度、安全，比起调 API 全都退了一个档次。

循环

结构上和 agent 循环一模一样，只是把屏幕当成环境：

1. 截屏当前状态
2. 由视觉模型解读画面，决定一个动作
3. 执行——按坐标点击、输入文字、滚动、按键
4. 再截屏，观察结果
5. 重复

工具都是原子操作：click(x, y)、type(text)、scroll(direction)、key(combo)。

难的是第 2 步给出的坐标要准。模型必须在图像里把目标定位得足够精确才点得中，而精确的空间推理是公认的弱项——patch 很难把细小的 UI 元素一个个区分开。

为什么它不可靠

坐标精度。 差二十个像素就点错了控件。小目标、密集的工具栏、挨在一起的按钮，都是它出错的地方。

截屏成本。 每一张都吃掉大量上下文——往往比好几页文字还多。二十步的任务会攒下二十张截图，既贵，又很快把窗口填满。多数系统只留最近的几张图，把更早的步骤压成摘要。

时序。 页面是异步加载的。拿过期的截图做动作，是长期存在的风险；而要判断界面什么时候才算稳定下来，确实很难。

状态不明。 点击生效了吗？窗口后面是不是弹了个对话框？agent 只看得到像素，拿不到应用的状态。

失效叠加。 可靠性会向下叠加，而这里每一步的可靠性又比调 API 更低。长时间的 GUI 任务经常失败。

有 API 就用 API

这一点值得直说，因为最常见的错误就是没这么做：软件有 API，就用 API。它更快、更便宜、更可靠，还能写测试。

操作电脑这套办法，是留给没有别的选择的时候——老旧的内部工具、桌面应用、横跨好几个互不相通的应用的流程。

具体到网页上的活儿，通过浏览器自己的自动化接口来驱动——读 DOM、用选择器——比截图加点击可靠得多。语义结构胜过像素。只有 DOM 用不了的时候才动视觉方案，比如 canvas 渲染的界面。

安全模型

这一节要格外小心，因为暴露面比看上去大。

能控制屏幕的 agent 权限很宽。 屏幕上显示的一切它都看得见，任何能点的东西它都点得到。想给它划定范围并不容易，不像一把权限受限的 API key。

每一块屏幕都是不可信输入。 一张网页、一封邮件，或者显示在屏幕上的文档，都可能含有长得像指令的文字。agent 读的是像素，分不清哪句是你的指令、哪句是它正在看的内容里的文字。这就是提示注入，攻击面很宽，而且没有干净的防御手段。

后果常常不可逆。 提交表单、发出消息、确认付款。GUI 操作没有 git revert 可用。

于是下面这些不是建议，而是硬性要求：

• 在隔离环境里运行——用专门的 VM 或容器，不要用已经登录了生产环境的那台机器
• 把凭据权限收到最窄；默认那块屏幕上够得着的东西，agent 都够得着
• 有后果的动作必须先确认——提交、付款、删除、发送
• 把每次截屏和每个动作都记进日志，以便审计；这是你唯一的记录
• 做方案时，任何会浏览开放网络的 agent 都按已被攻陷来对待

今天能用在哪儿

填表，用在不互通的系统之间。

提取数据，用在没有导出功能的界面上。

UI 测试——走一遍应用，验证该出现的东西有没有出现；这类任务天然可逆。

打通老系统——在某个老内部工具里走一条窄而明确的路径。

共同点是：任务短、定义明确、可逆。开放式地操作电脑，目前大体上还是演示。

要点回顾

• 截屏 → 决策 → 点击 → 截屏。兼容一切，每一步的可靠性却很低。
• 反复出现的失效来自坐标精度、截屏的上下文成本和时序。
• 有 API 就用 API；网页上的活儿，DOM 自动化胜过像素。
• 每一块屏幕都是不可信输入，而提示注入在这里没有干净的防御手段。
• 硬性要求：隔离环境、凭据权限最窄、有后果的动作先确认、完整日志。
• 适用于短、明确、可逆的任务。

下一篇： 人在回路的设计