你让 AI 整理一批文件、填完表格，再把结果写进另一个应用。只会模仿人点击鼠标的智能体，往往要截一次屏、想一步、点一下，再重新观察。步骤多，界面稍有变化就容易卡住。OpenGCUA 想换一种方式：让模型自己判断何时看屏幕、何时运行命令，以及能否直接写一段程序把多个操作连起来。
这不只是给旧式电脑智能体多装几个工具。OpenGCUA 试图重新划分模型与运行框架之间的职责，并逐步开放模型、系统、执行轨迹和评测组成的完整技术栈。不过要先说清：这是项目的首个版本，尚未发布训练好的模型；目前开放的是实现与 prompts（给模型规定任务和工具用法的提示文本）、八个模型的评测 trajectories（模型从观察到操作的完整执行记录），以及初步版真实设备 harness 和跨设备 SDK。本文数字均来自项目论文的作者报告，尚无独立信源复核。
不再规定 AI 只能怎么用电脑
电脑操作智能体（Computer-Use Agent）接收一个目标，观察电脑状态，再点击、输入或运行命令。过去常见的做法主要依赖 GUI——也就是人眼看到的窗口、菜单和按钮。GUI 几乎处处可用，但操作慢，也容易受界面变化影响。程序化接口则能用命令、无障碍接口或 API 直接处理软件，通常更精确，却不一定随处可用。
OpenGCUA 把“通用”定义为三项选择都交给模型：看什么、怎么做，以及怎样组织工作。
看什么，可以是截图、Accessibility Tree（无障碍树，把窗口里的按钮、文字和状态表示成结构化信息）、命令输出或 API 返回值。怎么做，可以是点击坐标、操作无障碍元素、运行 shell 命令，或者写一段混合这些动作的程序。怎样组织，则包括维护计划、记录进度，以及决定哪些旧观察还值得留在上下文里。
区别在于，系统不再预先规定每一步必须截屏，也不强迫模型始终走同一种入口。就像人处理文件时不会坚持打开几十个窗口逐项复制：能用命令批量完成时就用命令，必须辨认界面时再看屏幕。
关键变化是让模型写程序
OpenGCUA 的核心能力是 code execution，也就是代码执行。传统的批量 GUI 操作，只能提前列出一串已经决定好的点击；第一下点完后出现什么，后面的动作无法临场调整。程序却能使用条件、循环和变量：如果弹窗出现就关闭；对每一行重复填写；最后检查页面是否显示“已保存”。中间结果可以直接决定下一步，不必每执行一个小动作都重新调用模型。
论文归纳了五类常见用法。程序可以把 GUI 操作和文件检查接在一起；循环访问多个目标；根据运行结果选择分支；整理多张局部截图供模型判断；也可以在修改文件后验证预期内容发生了变化、其他内容保持不变。它的分工很明确：程序负责可以写成规则的操作与检查，模型负责选择方案，以及判断那些仍需视觉理解的证据。
作者在 OSWorld-v2 的拆分实验中报告：在同样具备 GUI 和 shell 权限时，允许模型把 GUI 操作写进程序，相比批量 GUI+CLI 基线，八模型均值的 partial score（任务部分完成度得分）增加 6.1 分，每项任务的步骤数减少 14.8%。这说明收益不只来自“多给一个命令行”，程序内部的循环、分支和验证也发挥了作用。
框架少做决定，模型多做决定
另一个设计叫 harness-to-model decision transfer，可以理解为“把运行框架的部分决定权交还模型”。Harness 是承接模型和电脑环境的运行框架。许多系统会固定规定每一步之后都截图、保留哪些历史记录，以及如何标记任务进度。OpenGCUA 则让模型按需请求截图，并用 todo 记录待办、已经改动但尚未验证的内容，以及自称已经验证的结果。每段程序运行前，模型还要写一句 intent，说明这一步准备做什么。
这样做的直接好处是少塞无用信息。若命令输出已经回答了问题，新截图可能只是重复占用上下文。论文报告称，仅采用按需观察，就让两个模型的 prompt cache hit rate（重复提示内容被缓存复用的比例）分别提高 10.5 和 14.4 个百分点，同时没有降低任务得分。部分历史清理仍由 harness 负责，因此这并非把所有控制权一次性交给模型，而是逐项转移。
八个模型都受益，但别把数字读得太满
作者在 OSWorld-v2 的 82 项离线任务上评测八个模型。相比已经支持批量动作的纯 GUI 基线，完整 OpenGCUA 配置让八个模型的 partial score 全部提高，跨模型均值从 45.3 升至 64.9，增加 19.6 分；每项任务的步骤数按各模型相对降幅平均减少 53.0%。完整任务成功率也在八个模型上全部上升。
高基线模型同样获得改善。作者报告，GPT-6 Astra 的得分从 67.1 升至 75.7，步骤数从每项任务 102.1 降至 33.5。GLM-5.3-Flash 和 DeepSeek-V4.1-Flash 的得分增幅分别达到 35.2 和 29.8 分。八个模型中有六个减少了输出 token；但 GPT-6 Astra 虽然步骤明显变少，输出 token 总量大致相同。这提醒我们：调用次数更少，不等于生成成本或总耗时必然同比下降。
真正的野心在真实设备和跨设备
基准环境通常比用户自己的电脑整齐。真实机器可能需要与用户共享控制，还会遇到后台窗口等情况。OpenGCUA 因此发布了初步版 real-device harness，用来研究这些基准没有充分覆盖的问题。
在该框架的四项真实 macOS 任务中，作者挑选的部分 Qwen3.8-Max 运行记录使用的 reasoning tokens（模型内部推理所消耗的 token）是 GPT-6 Astra 的 19.4 倍，总输出 token 为 5.7 倍。案例分析把差距指向简单操作上的过度推理、对真实设备条件适应困难，以及代码执行能力差异。但这是少量任务中的选择性样本，不能外推成两个模型的普遍效率结论。
项目还给出初步版 cross-device SDK——一套让开发者以统一方式控制电脑、浏览器和手机的编程接口。每次操作都明确绑定到设备、应用、窗口或标签页，并把视觉与无障碍接口保留为不同的观察和操作方式。一段程序因此可以协调多台设备，而不必为每种终端重写整套逻辑。
为什么值得关注
OpenGCUA 最重要的判断，是电脑智能体的竞争正在从“谁更会看截图和点按钮”，转向“谁更会选择工具、编排程序并管理自己的工作状态”。如果研究者能看到 prompts、实现和完整执行轨迹，就更容易判断能力究竟来自模型、工具权限，还是运行框架替模型做出的决定。
它也提供了一套较清楚的公共研究问题：什么时候该看屏幕，什么时候该读结构化状态；哪些检查适合写进程序，哪些仍要模型判断；真实电脑上的效率差距究竟来自哪里。这些问题比单个排行榜分数更接近电脑智能体能否真正工作的核心。
局限与未知
- “fully open stack”目前仍是项目方向，不是已经完成的状态。首个版本没有训练好的模型，real-device harness 和 cross-device SDK 也只是初步版本。
- 论文没有为主要汇总结果提供逐项方差、重复次数或统计显著性。19.6 分和 53.0%应视为作者在既定评测配置下的报告值。
- 四项 macOS 任务中的 19.4 倍来自部分被选中的运行记录；不同模型的 reasoning tokens 也未必能直接横向比较。