生产环境中的 Computer Use 代理：当像素取代 API 调用时

大多数 AI agent 通过结构化 API 与世界交互 —— 干净的 JSON 输入，干净的 JSON 输出。但有一类日益增多的 agent 完全抛弃了这种约定。计算机使用 (Computer use) agent 查看截图，对所见内容进行推理，并像人类操作员一样操作鼠标和键盘。当唯一的集成界面是屏幕时，像素就变成了 API。

这听起来像是个花招，直到你意识到有多少企业软件根本没有 API。遗留的 ERP 系统、内部管理面板、专有的桌面应用程序 —— GUI 是唯一的接口。多年来，机器人流程自动化 (RPA) 通过脆弱的、基于选择器 (selector) 的脚本来处理这些问题，只要按钮移动了三个像素，脚本就会失效。计算机使用 agent 承诺了一些不同的东西：像人类一样适应 UI 变化的视觉理解能力。

但演示与生产环境之间的差距是巨大的。最优秀的 agent 在受限的 Web 任务中成功率能达到 87%，但在开放式桌面自动化中则降至 20%。一个包含 50 个步骤的工作流，如果每一步的成功率为 90%，那么最终成功完成的概率仅为 0.5%。了解这种架构在何处奏效 —— 以及在何处会遭遇灾难性的失败 —— 是决定它是一个有用的工具还是一个昂贵的截图生成器的关键。

See-Think-Act 循环

每个计算机使用 agent 都运行着同样的基本循环：捕获截图，将其发送给视觉语言模型进行推理，执行选定的操作（点击、键入、滚动），然后捕获新截图以观察结果。这个循环不断重复，直到任务完成或 agent 放弃。

延迟预算可以分解为三个阶段：

• 感知 (Perception)（截图捕获和编码）：目标低于 500ms
• 认知 (Cognition)（LLM 对图像的推理）：目标低于 2 秒
• 执行 (Execution)（操作系统级的鼠标/键盘命令）：目标低于 100ms

在实践中，认知阶段占据主导地位。云端托管的视觉模型每步操作需要 2-5 秒，这意味着一个 50 步的任务需要 2-4 分钟的纯推理时间。一个简单的文件移动操作 —— 大约 10 个离散步骤 —— 成本约 0.10 美元，耗时 30-50 秒。将其扩展到复杂的工作流，每个任务的成本将达到 1-4 美元，每张截图消耗超过 15,000 个 token。

目前出现了两种架构方法。端到端 Agent 使用单个视觉语言模型来处理整个循环 —— 输入截图和任务描述，输出动作。它们更简单，在长任务中更稳定，但决策透明度有限。组合式 Agent 将流水线拆分为不同的阶段 —— grounding 模型识别 UI 元素，规划模型决定下一步行动，执行层负责实施。这增加了可解释性，但也在组件之间引入了误差传播。

业界正在向混合模式趋同：在可用时使用结构化可访问性树 (accessibility trees) 和 DOM 解析，对于自定义 UI 和遗留系统则回退到基于视觉的推理。微软的 UFO² agent 堪称典范 —— 它将 Windows UI 自动化与基于视觉的解析相结合，因此无需切换架构即可处理标准控件和非标准界面。

没人提及的坐标缩放问题

这里有一个让每个构建第一个计算机使用 agent 的团队都会跌倒的工程细节：坐标转换。视觉模型通常接收调整为 1024×1024 像素的图像，但实际屏幕的分辨率为 1920×1080 或更高。当模型说“在 (512, 300) 处点击”时，该坐标存在于模型的图像空间中，而不是屏幕的原生分辨率。

你需要一个坐标缩放函数，在执行之前将预测的坐标映射回原生屏幕分辨率。如果搞错了这一点，每一次点击都会落在错误的地方 —— 偏差可能不大，但足以点错按钮。在映射非线性的高 DPI 显示器上，这尤其危险。

精度问题在标准分辨率下会进一步加剧。微小的 UI 元素 —— 下拉箭头、关闭按钮、切换开关 —— 在模型调整大小后的输入中仅占几个像素。研究表明存在两种截然不同的 grounding 失败：空间对齐失败，即模型识别出了正确的元素但定位不精确；以及语义对齐失败，即模型由于误解了指令而精确地点击了错误的元素。

尖端模型在整洁的界面上能达到约 90% 的 grounding 准确率。但对于包含许多细小、排列紧密的元素的密集 UI —— 想象一下电子表格工具栏或 IDE 面板 —— 仍然是一个持久的挑战。

计算机使用 Agent 真正奏效的场景

并非每个用例都能从像素级交互中受益。决策框架非常直接：

计算机使用 (Computer use) 有意义的情况：

• 目标应用程序没有 API，也没有可访问性树（遗留桌面软件、专有的内部工具）
• 你需要与频繁变化的 UI 进行交互，在这种情况下硬编码的选择器每周都会失效
• 任务本质上是视觉性的 —— 比较布局、读取图表、验证渲染输出
• 你正在构建需要验证人类实际所见内容的测试自动化

基于 API 的 Agent 更好的情况：

• 存在结构化 API（大多数现代软件都有）
• 确定性的、可重复的执行至关重要
• 成本和延迟是约束条件（基于文本的工具调用成本要低 10-100 倍）
• 工作流涉及数据转换，而不是 UI 导航

目前已具备生产就绪能力的场景：

• 用于受限信息检索任务的 Web 浏览器自动化（80-90% 成功率）
• 结合 RPA 的表单填写和数据录入（减少 70-80% 的时间）
• 回归测试和视觉差异验证
• 为残障用户提供的可访问性增强

仍处于研究阶段的场景：

• 开放式桌面操作系统自动化（OSWorld 基准测试中成功率为 20%，而人类基准为 72%）
• 涉及多个应用程序的跨应用工作流
• 任何涉及金融交易或不可逆操作的工作流
• 移动端自动化（设备和操作系统版本极度碎片化）

诚实的评估是：目前的 agent 交付了大约 70% 的能力，而生产系统需要 99.9% 以上的可靠性。对于高风险工作流中的无人值守部署来说，这一差距太大了。目前最适合的场景是人类监管下的重复性视觉任务自动化，在这些任务中，偶然的失败是可以恢复的。

导致生产环境部署失败的五种模式

计算机操作智能体的失败方式是基于 API 的智能体从未遇到过的。在投入使用这种架构之前，理解这些失败模式至关重要。

1. 时序错位。 智能体在 UI 完成渲染之前就进行了点击。页面加载、动画或异步数据获取意味着智能体进行推理时的截图与现实不再匹配。模型点击的是按钮 曾经 所在的位置，而不是它 现在 所在的位置。生产系统需要在操作之间建立显式的“等待稳定状态”逻辑。

2. 级联错误累积。 多步骤任务中的每一步都有很小的失败概率。在一个每步准确率为 95% 的 50 步工作流中，正确完成整个任务的概率仅为 7.7%。更糟的是，智能体通常无法意识到自己犯了错，因此后续操作会加剧原始错误，而不是纠正它。

3. 意外的模态框干扰。 Cookie 同意横幅、系统通知、更新提示、CAPTCHA 验证——任何不属于任务描述的意外 UI 元素都会使智能体偏离轨道。强大的智能体需要中断处理逻辑，以便关闭或绕过计划外的模态框。

4. 长周期下的状态去同步。 在执行长时间任务时，智能体对应用状态的内部模型会与现实发生偏差。它可能“记得”三步前填过一个表单字段，但没有验证该值在页面跳转后是否依然存在。这是困扰所有长时间运行智能体的陈旧世界模型问题，而视觉状态比 API 响应更难验证，这进一步放大了该问题。

5. 分辨率和渲染差异。 在 1920×1080 截图上训练或测试的智能体，部署到具有不同分辨率、DPI 缩放、字体渲染或深色模式设置的机器上时可能会失败。UI 元素的位置会发生偏移，文本换行方式会不同，图标渲染的大小也会改变。这是基于 API 的智能体不存在的部署移植性问题。

不容忽视的安全攻击面

让 AI 智能体在真实的操作系统上控制鼠标和键盘，与让其访问精选的 API 端点，在安全层面上有着本质的不同。其攻击面是整个桌面环境。

最近的研究发现，91% 已发布的计算机操作智能体“技能”都存在某种形式的提示词注入漏洞，在某些智能体编程环境中，执行恶意命令的攻击成功率高达 84%。一种新型攻击——语义级 UI 元素注入——通过在截图中覆盖看似无害但具有对抗性的 UI 元素来误导智能体的视觉定位，使攻击成功率比随机注入提高了 4.4 倍。

沙箱化是不可逾越的底线。部署方案分为几个等级：

• 轻量级沙箱 (Docker + VNC)：启动快，但操作系统功能支持有限
• 重量级沙箱 (VirtualBox/QEMU)：完整的操作系统模拟，但耗费资源
• 云原生沙箱 (托管基础设施)：将隔离的复杂性外包

如果没有隔离，智能体可能会误删文件、通过浏览器会话窃取数据，或与预定范围之外的应用进行交互。其原则与任何智能体安全原则一致：沙箱深度应与智能体操作的爆炸半径相匹配。对于计算机操作智能体，爆炸半径就是“坐在那台电脑前的人能做的任何事情”。

生产部署应实施分层操作权限：

• 静默（只读操作，如截图）：无需审批
• 记录（写入操作，如键入文本）：执行但进行审计
• 确认（关键操作，如提交表单）：需要人工审批
• 阻断（凭据输入、金融交易）：绝不允许自主执行

混合驱动的未来

最务实的生产架构不会在计算机操作和基于 API 的智能体之间做二选一，而是将它们分层结合。混合 OS 访问模式会优先尝试 API 调用，失败后回退到无障碍树 (Accessibility Tree) 导航，只有在结构化接口不可用时才求助于基于视觉的计算机操作。

这反映了传统 RPA 的演进过程。纯基于选择器的自动化为结构化工作节省了 30–40% 的成本。在此基础上增加 AI 驱动的视觉理解，可以处理那些脆弱脚本无法触及的非结构化边缘案例——手写发票、动态合同、非标准界面。

趋势很明显：随着视觉语言模型在定位准确度和推理速度上的提升，计算机操作智能体优于脚本自动化的任务领域将会扩大。但在可预见的未来，架构仍将保持混合状态。只要 API 存在，它们就会更快、更便宜、更可靠。计算机操作则是用来填补 API 不存在的空白。

给评估该技术的团队的实用建议：从沙箱环境中一个范围狭窄、可恢复的任务开始。测量每一步的成功率，并根据预期的任务长度进行累乘，从而得出真实的端到端可靠性数据。如果数学上可行且配有人工监督处理失败，那就上线。如果你需要长流程的无人值守可靠性，请再等等——技术还未达到那个水平，假装已经达到会让你付出比它原本要取代的人工流程更高的代价。