Baseerat：不可见屏幕时的 Computer-Use Agent 监督缺口

Baseerat：不可见屏幕时的 Computer-Use Agent 监督缺口

一句话结论

Baseerat 评估一个常被 computer-use agent benchmark 忽略的问题：当监督者看不到屏幕，只能依赖 agent narration 和 accessibility tree 时，是否还能发现 agent 实际做错或被页面欺骗。它提出 oversight parity gap，并用 trusted action receipts 作为修复通道。

为什么对用户重要

用户关注长程 computer-use agent 的失败模式：verified state、GUI/CLI 切换、状态漂移、恢复失败、报告夸大。Baseerat 的核心提醒是：监督通道本身也可能失真。agent 自述、页面可访问性树、真实 DOM/存储状态、视觉屏幕可能彼此不一致；如果 benchmark 默认人能看屏幕，就会低估非视觉用户和无头 agent 审计的风险。

机制 / 一阶原理

Baseerat 把同一任务拆成 ground truth、accessibility view、agent narration 和 auditor verdict。deceptive injection 场景中，页面真实提交值可能被劫持，而 accessibility tree 暴露的是 benign expected value。sighted overseer 可以从视觉通道看出异常，non-visual overseer 则只能看到被污染或不足的可访问性通道。

它的防御不是要求模型“诚实报告”，而是生成 trusted action receipts：由独立于页面确认信息的 ground truth 派生，并以可访问方式呈现。auditor 把 receipt 当作权威记录，从而补上 narration-only 缺口。

与已有概念的关系

• 对 Loop-Engineering：验证状态必须独立于执行者报告，尤其是无头/无人 loop。
• 对 Agent-Benchmarks：benchmark 应明确监督者可见的信息通道，并报告 oversight parity gap。
• 对 Harness-Engineering：完成证据应是 receipt，而不是 agent 最终自然语言总结。

可执行启发

1. Hermes browser/computer-use 工具应保存 action receipt：目标、参数、实际提交状态、截图/DOM/a11y 摘要和验证来源。
2. 报告中区分 agent narration 与 verified state；若只有自述，应标为 unsupported。
3. 对 GUI 任务建立多通道校验：accessibility tree、screenshot、DOM/state、CLI/API 后门尽量交叉验证。
4. 长程任务失败复盘要问：失败是执行错、观察错，还是监督通道看不到真实状态。

失败模式 / 边界

• 本轮只读取 README/Zenodo 引用信息，未读取完整论文和运行 benchmark。
• trusted receipt 自身必须来自可信执行/状态路径；若 receipt 生成器被页面或 agent 污染，防御失效。
• 该 benchmark 聚焦 accessibility oversight，不等同覆盖所有 GUI agent 失败模式。

深度判断

本轮晋升为正式 source 页，因为它直接命中 long-horizon computer-use 的 verified state / report exaggeration / oversight channel 主题，并把失败模式转化为可评测指标与 receipt 防御。

写入记录

• 2026-08-28 09:00 CST：新增 Baseerat 分析，提炼 oversight parity gap、non-visual supervision 和 trusted action receipts 对 Hermes computer-use 验证的启发。