PAPER DEEP DIVE
混合计算机使用：面向通用智能体的程序化、语义与视觉统一接口
该论文提出混合计算机使用接口 HCU，在同一智能体上下文中统一代码与命令行、无障碍语义树和截图鼠标键盘三类交互通道。HCU 通过紧凑观察、最多 64 步批量动作、等待步骤、动作后差异和跨通道目标/布局守卫减少往返并阻止过期输入；在 OSWorld 2.0、OSWorld 1.0、WeaveBench、macOS 与 Windows 基准上同时改善任务表现或交互效率。
一句话总结
HCU 不再强迫智能体像人一样只看截图、点鼠标，而是把代码、终端、无障碍树和视觉界面放进同一任务上下文，并在每次输入前重新核验目标是否仍然有效。
研究背景：截图式接口把人的工作方式强加给模型
计算机使用智能体的主流接口长期围绕“观察屏幕、定位控件、移动鼠标、敲击键盘”展开。这个范式覆盖范围广，也与人类使用桌面软件的方式一致，但它把大量本来可以由程序直接完成的工作重新压缩成像素理解与坐标操作。模型明明可以读取字段值、批量修改文件或调用命令行，却经常要先在截图中找到输入框，再把语义意图翻译成一次低带宽的点击。
当任务从 OSWorld 1.0 中的单应用操作延伸到 OSWorld 2.0 的长时程专业软件工作流，这种接口成本会被放大。一个任务可能跨越表格、浏览器、文档、文件系统和对话框，任何一次截图刷新都意味着新的视觉解释、目标定位和状态判断。交互轮次越多，错误越容易累积，模型也越难在有限步数内维持长程一致性。
论文把现代桌面能力归纳成三条互补通道。程序通道通过代码、Shell 和文件工具直接处理数据；语义通道通过无障碍接口读取控件角色、名称、状态与支持动作；视觉通道通过截图、缩放、鼠标和键盘处理只能从像素判断的内容。关键问题不是三选一，而是怎样让同一模型在同一上下文中自由切换，并且不让旧观察误导新动作。
已有混合系统已经在程序与视觉之间建立连接，但很多设计仍把语义树当作坐标定位的辅助材料，或者用独立规划器、子智能体把任务拆成固定职责。HCU 的出发点更直接：把三通道作为同样面向模型的原生工具暴露出来，不增加新的规划层，也不要求模型重新训练。
这一选择使论文更像一项接口研究，而不是新模型研究。它关注信息如何被观察、目标如何被引用、动作如何被批处理、反馈如何返回，以及当另一条通道改变桌面后，旧截图或旧元素引用还能否被信任。对于 Agent Harness 而言，这些正是决定同一基础模型能否稳定完成长任务的系统级变量。
预备知识：三通道分别解决什么问题
程序通道的优势是确定性、可组合和低成本。文件可以被脚本一次处理，批量数据可以用代码变换，命令行可以检查真实产物。它不依赖控件是否被无障碍树暴露，也不要求模型精确描述坐标；但它无法天然处理没有脚本接口、只能通过图形界面操作的软件。
语义通道来自桌面应用为辅助技术提供的无障碍树。树中的元素通常带有角色、名称、值、状态和可执行动作。相比截图，它显式区分按钮、复选框、输入框、选中的标签页等内容，也允许模型用稳定引用而不是坐标描述目标。其边界同样明显：应用可以少暴露或不暴露属性，自绘控件可能没有对应元素，虚拟列表中的项目也可能在滚动到可见区域前不存在。
视觉通道提供最终的事实来源。截图能展示布局、渲染结果、自绘内容以及无障碍树没有描述的错误提示，却很难证明控件身份。两个外形相同的按钮可能在语义上完全不同，窗口移动后同一个坐标也可能落到别的控件上。HCU 因此没有把视觉当成“最后兜底”，而是把它与语义、程序一起放在模型可主动选择的动作空间中。
论文使用“可组合”来描述语义交互，而不是简单罗列点击、输入等原子工具。模型可以在一次调用中给出多个已知动作和等待条件，由接口按顺序执行、检查并返回状态差异。这个设计把执行、验证和后续观察压缩进一次往返，是后续效率提升的主要来源之一。
方法详解：统一通道，而不是另造一个智能体
1. 三通道共享同一桌面与同一任务上下文
HCU 通过模型上下文协议增加两个桌面工具：无障碍工具读取语义树并发起引用寻址动作，图形工具获取截图、缩放并发送鼠标键盘输入。程序工具仍由宿主智能体本身提供。三条通道作用于同一台计算机，也把结果返回到同一个模型上下文，因此模型可以在一次决策中根据已有证据选择继续、换通道或停止。
接口没有内建规划器、子智能体或循环控制器。GPT-6 Astra 在 Codex 中运行，Claude Opus 5 在 Claude Code 中运行；HCU 只替换桌面交互面，不替换宿主 Harness 的推理循环。这一点让实验能够比较“接口变化”本身，而不是把收益归因于某个额外编排器。
flowchart LR
T[Task] --> H[Existing agent harness]
H --> P[Programmatic tools]
H --> S[Semantic AX MCP]
H --> V[Visual GUI MCP]
P --> C[Shared desktop state]
S --> TG[Target guard]
V --> LG[Layout guard]
TG --> A[Batched actions and waits]
LG --> A
A --> E[Effect report and AX diff]
E --> H
C --> TG
C --> LG
图中最重要的不是三条分支，而是从实时桌面状态重新进入两个守卫的边。每次动作前都重新读取目标或布局，而不是把前一轮截图当成永远有效的世界模型。这使通道切换不再是隐式风险，而是一个有明确前置条件的操作。
2. 紧凑无障碍视图与稳定目标引用
原始无障碍树往往包含大量结构包装节点，直接返回给模型会占据不必要的上下文。HCU 保留完整记录用于身份确认和状态比较，却向模型展示去掉包装、压缩重复内容后的紧凑视图。目标引用在压缩前就绑定到具体元素，因此视图变短不会改变引用所指的对象。
当目标没有出现在紧凑视图中时，模型可以使用查找或限定范围的观察取回它。这个分层设计同时照顾了上下文预算与可恢复性：首屏看到的是适合决策的摘要，需要精确定位时仍能回到完整记录。
动作批处理支持最多 64 个有序步骤。等待步骤不发送输入，而是等待窗口、目标引用、文本、查询结果或界面稳定等条件。等待可以放在动作之间，阻止后续步骤在错误状态上执行；也可以放在批次最后，作为最终状态检查。一次批次内所有等待共享 60 秒预算，避免长时阻塞。
如果动作失败、等待超时或窗口连续性丢失，批次会停止并说明停在哪一步。模型得到的是可继续利用的执行证据，而不是一个模糊的“调用失败”。这比让模型重复整批动作更安全，也减少了为了确认某一步是否生效而额外发起的观察调用。
3. 执行前守卫把“旧证据”变成显式拒绝
跨通道切换的核心风险是证据失效。无障碍动作可能打开一个覆盖旧截图坐标的对话框，图形动作也可能替换掉某个语义引用。HCU 不试图猜测相似目标，也不偷偷把动作重定向到另一个看起来相同的控件，而是在每个动作前验证它依赖的目标或布局。
对语义动作，接口先解析引用对应的实时目标，再检查元素身份以及该动作要求的能力。若目标缺失、有歧义、已被替换或无法执行相应动作，就拒绝输入。形式化地写，只有当实时目标不是空值且目标支持该动作时，守卫才允许执行：
$$\mathrm{ok}_{AX}=(t\neq\bot)\land\mathrm{CanExecute}(a,t)$$
这里的 $a$ 是请求动作，$t$ 是从实时无障碍状态解析出的目标，$\bot$ 表示身份无法确认。公式表达的重点不是数学复杂度，而是失败关闭：身份不确定时不输入，模型会拿到新的证据和明确的过期引用错误。
对图形坐标动作，接口比较当前桌面与截图租约对应的布局，包括桌面边界、可见顶层窗口、叠放顺序、活动窗口和坐标点所在窗口。只有截图所依据的布局仍然匹配，坐标才被视为可用：
$$\mathrm{ok}_{GUI}=(F\neq\bot)\land(\mathrm{LiveLayout}()=F.\mathrm{layout})$$
其中 $F$ 是坐标所依赖的截图帧。若布局变化，整批受影响输入不会发送，接口返回新截图让模型重新判断。这个设计承认“近似布局”不足以证明坐标安全，也避免模型在窗口已经移动时继续执行一串点击。
4. 动作后反馈：效果摘要与差异，而不是只报告“已发送”
HCU 默认在无障碍动作后返回逐目标效果摘要、窗口变化和相对于最近一次有效观察的语义差异。模型还可以明确要求截图、仅返回执行证据或完整观察。把差异和动作结果一起返回，意味着模型经常不需要再额外观察一次，就能决定下一步。
接口区分三种状态：已知没有送达输入、输入可能送达但效果未知、以及有证据支持的局部变化。这样的区分很关键。无障碍接口报告“动作已调用”并不等于目标状态已经改变，鼠标输入被系统接收也不等于任务产物已经保存。HCU 只陈述当前证据能够支持的部分，剩余判断交回模型。
这套反馈契约与批次配合后，形成“执行、等待、检查、继续”的闭环。模型可以把选择复选框、等待其进入选中状态、再填写下一个字段放在同一批里，而不是每一步都往返一次。长任务中的节省来自减少模型响应次数，也来自减少重复解释相同界面的成本。
5. 技能提示减少接口约定错误
仅暴露工具并不足以让模型正确使用。HCU 附带一份技能说明，重点覆盖通道能力、批量组合、引用使用、验证与恢复。它不提供任务答案，而是解释哪些证据可以证明保存成功、何时应该重新观察、过期引用后怎样刷新，以及参数不符合工具模式时怎样修复。
论文把技能看作接口的一部分。实验显示，加入技能后，无障碍与图形调用因参数畸形被拒绝的比例从 17.37% 降至 1.36%；发生连续同类参数错误的 task-run 比例从 44.69% 降至 0.37%。这些数字说明，很多看似模型能力不足的问题，实际来自动作空间与执行契约没有被清晰解释。
技能还改变了动作结构。多动作无障碍批次、查找目标和使用批次内检查的次数上升，额外观察次数下降。模型开始把 HCU 当作可组合执行环境，而不是三个彼此独立的按钮集合。
6. 官方实现中的两道守卫
论文方法可以在公开仓库中直接对应到源码。第一处是 Linux 无障碍目标的实时解析。代码在解析不到当前节点时返回 stale_element_ref，并明确说明没有发送输入，要求模型刷新语义状态：
node = record.pop("_resolvedNode", None)
if node is None:
node = find_element_at_snapshot_path_with_bounds(
app, record, matched_bounds)
if node is None:
raise OperationFailure(
"stale_element_ref reason=live_semantic_record_changed_before_input "
"no input was emitted; refresh AX mode=observe/find and use the "
"newly returned public ref.",
failure_code="stale_element_ref",
failure_phase="precondition",
input_events_emitted=False,
)
return node来源：computer-use/native/linux/provider/element_resolver.py:488-500。这段实现把“身份变化”视为前置条件失败，而不是临时网络错误；返回字段还区分 dispatched 为零和没有输入事件，便于上层模型正确恢复。
第二处是图形坐标批次的布局守卫。当当前截图帧与发起坐标时记录的帧不一致，并且坐标在新布局中不再有效时，实现返回 stale_gui_frame，同时保证没有动作被派发：
reference_layout = _published_layouts.get(frame_id) if frame_id else None
if frame_id and frame_guarded_actions:
if (current_capture.frame_id != frame_id
and not coordinates_still_valid(
reference_layout, capture_layout(current_capture), validated)):
return {
"ok": False,
"error": "The desktop layout changed since the screenshot used "
"for coordinates. No actions were dispatched and no input "
"events were emitted.",
"failureCode": "stale_gui_frame",
"failurePhase": "precondition",
"dispatched": 0,
"input_events_emitted": False,
"snapshot": encode_evidence(current_capture),
}来源：computer-use/native/linux/provider/gui_dispatch.py:572-591。代码与论文 Algorithm 1 的风险模型一致：旧截图只能作为坐标租约，租约失效后必须让模型重新看见桌面。
图 13：HCU 的工具面通过 MCP 与不同平台原生后端相连，守卫位于真正输入之前。
图 17：论文展示的跨通道状态与动作守卫。新的桌面状态会同时约束语义目标和视觉坐标。
图 18：Writer 布局变化后的拒绝案例。系统返回新证据，而不是把旧坐标重定向到相似位置。
实验分析：主要收益是成功率，同时显著压缩交互成本
主实验在 OSWorld 2.0 的 108 个任务上进行，使用 500 步上限，并以 Partial 表示平均任务得分、Binary 表示完全成功率。GPT-6 Astra 的匹配对比最直接：CUA Driver 得到 68.82% Partial 和 31.50% Binary，HCU 达到 72.37% 和 32.40%。HCU 的 Partial 提升 3.55 点，同时工具调用减少 29.81%，Steps 减少 9.57%，平均时间减少 21.00%，成本几乎不变。
这说明增益不能简单归因于“做了更多操作”。HCU 反而少发模型响应、少调用工具、少花时间。更合理的解释是每次桌面调用携带了更多有效信息：紧凑语义视图降低观察负担，批次减少往返，差异反馈让模型少做纯确认操作，守卫则减少把输入发送给错误对象后的重试。
| 系统与模型 | Partial | Binary | 输出 token / 任务 | 成本 / 任务 |
|---|---|---|---|---|
| CUA Driver / GPT-6 Astra | 68.82% | 31.50% | 25.8K | USD 10.05 |
| HCU / GPT-6 Astra | 72.37% | 32.40% | 25.4K | USD 10.03 |
| HCU / Claude Opus 5 | 72.06% | 35.19% | 118.29K | USD 22.67 |
Claude Opus 5 的结果给出了另一层证据。HCU 在该模型上达到 72.06% Partial 和 35.19% Binary，相比官方排行榜的 68.31% Partial、31.43% Binary 分别提高 3.75 和 3.76 点，同时成本从 USD 28.43 降到 USD 22.67，下降 20.26%。接口没有绑定某一家模型的动作习惯，却在两个不同 Harness 中都改善了同一组指标。
OSWorld 1.0 的跨模型实验更能说明稳健性。论文用 GPT-5.4、Claude Opus 5.5、Gemini 3.8 Flash 和 Grok 4.7 在各自 Harness 中比较 HCU 与 CUA Driver。四个模型的平均结果多出 6.48 分，Steps 少 17%，成本低 30%。这些数字不应被理解为所有任务都同幅受益，但至少说明收益不依赖单一模型或单一代理框架。
| 指标 | CUA Driver | 发布版 HCU | 相对变化 |
|---|---|---|---|
| 任务得分 | 62.47% | 70.13% | +7.66 点 |
| Steps | 40.58 | 24.92 | -38.6% |
| 输入 token | 2,174.5K | 717.7K | -67.0% |
| 执行时间 | 499 秒 | 296 秒 | -40.7% |
| 成本 | USD 0.983 | USD 0.402 | -59.1% |
发布版相对评估版还提升了 4.36 分，同时减少 12.4% Steps 和 20.2% 成本。论文把这部分变化归因于界面细化，包括统一等待步骤、把批次上限提高到 64、为结果增加公共错误码、图形缩放、逐目标效果报告和 Linux 逐点布局检查。它提醒我们，Harness 版本差异足以改变同一模型在同一基准上的表现。
WeaveBench 的长时程混合任务提供了跨基准验证。HCU 在全部 114 个任务上得到 53.25%，CUA Driver 为 46.37%，官方 OpenClaw 为 43.84%。HCU 同时把高分任务数从 CUA Driver 的 12 个提高到 24 个，工具调用少 17.6%，输入 token 少 48.6%，单任务成本低 46.3%。
跨操作系统的结果说明其三通道抽象并不依赖 Linux 特有实现。macOS 的 28 个强依赖图形界面的任务中，HCU 完成 25 个，CUA Driver 完成 24 个，HCU 的平均时间从 876.0 秒降到 544.5 秒，成本从 USD 1.4899 降到 USD 0.7245。Windows Agent Arena 的 111 个任务中，得分从 71.89% 提高到 80.86%，平均步骤从 24.45 降到 17.35，总成本从 USD 73.00 降到 USD 36.06。
| 基准 | CUA Driver | HCU | HCU 的成本变化 |
|---|---|---|---|
| WeaveBench，114 任务 | 46.37% | 53.25% | -46.3% / 任务 |
| MacAgentBench UI 子集，28 任务 | 24/28 | 25/28 | -51.4% / 任务 |
| Windows Agent Arena，111 任务 | 71.89% | 80.86% | -50.6% / 总成本 |
消融给出了更细的设计判断。去掉无障碍通道后，GPT-5.4 三次运行的均值为 62.79%，完整 HCU 为 65.59%，而且在每一次单独运行中完整系统都领先，说明语义通道是稳定的成功增益来源。去掉技能后均值为 64.00%，也低于完整系统，但波动更大。
图形通道的结论需要谨慎。去掉图形后均值为 66.08% ± 1.66%，表面上甚至高于完整 HCU 的 65.59% ± 0.61%，但三次运行之间差异符号并不稳定；同时图形通道持续让 Steps 减少 12.45%。因此更准确的解释是：在这组任务中，图形通道的主要贡献是交互效率和视觉证据，而不是可以稳定测量的精度提升。把所有增益都归因于“三通道一定同时提升准确率”会过度解读。
为什么它对通用智能体架构重要
HCU 的核心贡献是把计算机使用从单一感官问题改成接口设计问题。模型能力固定时，系统可以通过调整可观察对象、可执行动作和反馈粒度，显著改变任务成本。无障碍树让模型看到软件结构，代码让模型绕过重复劳动，截图则提供无法从语义结构证明的视觉结果。三者的价值来自互补，而不是简单叠加。
论文的一处关键观察是不同模型会以不同比例分配通道。资源分析中，Claude 的 Steps 比 GPT-5.4 多约 3.3 倍，图形与程序调用分别高约 1.5 倍和 1.7 倍，语义调用高 3.1 倍。相同接口面对不同模型时，模型会形成不同的执行风格。因此只看总 Steps 会掩盖交互结构，比较 Harness 时必须同时观察通道分布、成功率和产物验证。
守卫机制也提供了一个可迁移的安全边界。智能体并不是因为“模型认为目标没变”就可以继续操作，而要由接口重新确认身份和布局。这个原则可以扩展到数据库事务、浏览器 DOM 引用、机器人末端执行器目标以及其他带有时效证据的系统：旧观察需要租约，租约失效后必须重新取得现实状态。
对于机器人系统，HCU 的三通道结构与具身智能的分层控制有相似之处。代码对应任务级编排与确定性数据处理，语义结构对应已知对象与可执行操作，视觉对应开放场景中的证据与异常。真正可复用的思想不是照搬桌面工具，而是让高层模型自由组合不同抽象层，同时在每个动作边界验证前置条件。
还需要区分“动作成功”与“任务完成”。HCU 明确不在所有步骤后自动证明最终产物，而是让模型根据文件、语义状态、界面差异和视觉证据综合判断。这避免了把输入事件误当成业务结果，也为后续接入更严格的验收器留下空间。
局限与独立判断
作者明确承认，无障碍覆盖由应用决定。自绘内容可能没有可访问元素，一个可访问对象也不一定与一个可见控件一一对应，虚拟化列表中的项目可能直到渲染后才出现。因此语义通道无法完整代表屏幕内容，这也是 HCU 保留视觉观察和截图请求的原因。
作者还指出，无障碍动作被调用并不证明目标状态已经改变。接口只能报告执行与局部可观察差异，不能证明像素结果、持久文件内容或任务整体完成。反过来，图形通道能证明屏幕看起来发生了变化，却不能单独证明语义身份、数据持久性或业务约束已经满足。跨通道证据需要模型主动组合。
论文中的模型偏好差异也构成限制。不同基础模型对图形动作词汇、批次大小和观察粒度有明显偏好，同一套工具定义无法消除模型自身的调用习惯。GUI 动作空间替换实验中，Claude Opus 5.5 在 Claude 风格动作空间下提高 0.82 点，GPT-5.4 在默认 GPT 风格下高 2.03 点。这意味着 Harness 设计仍需要针对模型调优，不能把接口视为完全中性的能力注入。
从工程角度看，HCU 的安全边界仍依赖本地 provider、桌面身份、布局租约和窗口连续性。论文主要验证单人、隔离桌面中的任务完成，没有系统回答多用户并发、恶意应用伪造无障碍身份、敏感输入脱敏、权限最小化和撤销等问题。若直接进入真实企业桌面，这些都需要独立治理。
另一个可继续验证的问题是长任务的标准化验证。当前反馈偏向局部动作效果和状态差异，模型仍要自行判断最终文件是否正确、格式是否满足要求、多个应用之间是否一致。未来可以把外部验收脚本、数据库查询或应用原生 API 作为可调用证据接入同一 Harness，让完成判定从“屏幕看起来对”升级为“产物可验证”。
结论
HCU 没有提出全新的基础模型，而是重新设计了智能体与计算机之间的接触面。它把程序、语义和视觉放在同一上下文中，用紧凑观察降低上下文成本，用批次和等待降低往返次数，用动作后差异减少确认步骤，再以目标守卫和布局守卫处理跨通道证据失效。
实验结果表明，这种接口在 OSWorld 2.0、OSWorld 1.0、WeaveBench、macOS 子集和 Windows Agent Arena 上都改善了任务表现或交互效率，并能在 Codex、Claude Code、Gemini CLI 和 Grok Build 等不同宿主中工作。最值得带走的结论不是某个单独分数，而是：当模型足够强时，系统不应把人的操作方式固定成唯一动作空间。
对 Agientry 的 Harness 方向而言，这篇论文提供了一套可落地的设计原则：把任务上下文、工具契约、状态证据、失败语义和恢复路径一起设计；不要让模型在“看不见的状态”上继续输入；把效率视为成功率之外的一等指标。只有三者共同改善，长时程智能体才真正具备实用价值。
论文的资源状态也已明确：官方实现已公开，采用 MIT 许可，并带有架构文档、MCP 工具定义、技能说明以及 Linux、macOS、Windows 原生后端。站点后续若要复用其接口思想，应先在自己的任务轨迹上复现守卫与反馈契约，再决定哪些工具面可以进入生产环境。
