电脑用AI看得懂屏幕变化吗？一个新Benchmark测出明显短板

用模型操作计算机（CUA）时，场景是这样的：模型发一条指令——点击按钮、拖拽文件、切换窗口——然后等着，拿到下一帧截图，再决定下一步。流程看起来没问题，实际用起来，模型经常像在梦游。

它点了保存，但对话框根本没弹出来，它以为弹出来了，接着往下走。或者界面已经变了，它还在对着上一帧的坐标做推理。翻日志，模型根本没意识到屏幕没有变化。

问题在于，现有评测只看两件事：最终任务有没有完成（端到端），以及单帧的定位准不准（grounding）。中间那个关键环节——模型能不能判断一次操作之后屏幕到底发生了什么变化——几乎没人测。

最近 arXiv 上有一篇论文就在捅这个窟窿。几位研究者提出的 Desktop-Delta Bench（DDB），是一个专门测试模型是否理解 GUI 状态变化的离线步级基准。

为什么需要专门测"变化"

CUA 的工作流本质上是一个异步循环：推理 → 执行远程输入 → 应用渲染 → 截图反馈。这四个环节不是同步的。截图的到达可能延迟、被遮挡、只闪了一下就没、或者根本没变。如果模型不能判断"这次操作之后画面变了没有、变的是什么"，它就会把过时的观测当成有效进展，一路错下去。

DDB 抓了三个失效维度：状态验证（画面真的变了吗）、来源追踪（变化是由我的操作引起的吗）、上下文感知控制（当前画面是否需要调整策略）。派 Agent 去干活，得知道它有没有在假装干活。

2,013 个人工验证的用例

DDB 构建了 2,013 条人工验证的测试实例，基于跨约 15 个 Linux 应用、50 个任务域的多应用操作轨迹。它设了两类任务：

• 时序排序（463 条）：给 3 帧截图，判断先后顺序。其中 105 条带了一条跨轨迹的干扰帧——需要判断哪一帧不属于当前任务。这是为了防模型"猜顺序"。
• 前后配对（1,550 条）：给出操作前和操作后的截图，标注做了什么操作（5 类动作 + 附带 payload）。

论文测了 8 个闭源和开源模型系列，结果不算好看。

时序任务上，最佳非干扰精确匹配率 65.1%，带干扰帧的精确匹配率 65.7%。加了任务上下文之后，干扰帧识别提升了 6.9 个百分点，但非干扰的精确匹配反而掉了 2.2 个百分点——任务上下文让模型更倾向于直接抄 A-B-C 的呈现顺序。错误分析证实了这一点：模型在故意"抄顺序"而不是理解因果。

单动作任务上，模型能定位动作比推断动作类型容易得多。点击的 F1 达到 0.96，拖拽只有 0.76。但被识别出来的拖拽，定位倒还不错。

更麻烦的是，放进多帧时间线里，模型对"这帧是在操作前还是操作后"的判断也就六成五的水平。

这个基准补了什么

当前主流的计算机用评测，包括 OSWorld、AndroidWorld、WebArena 这些，都是端到端打分：任务有没有完成。它们不问"第 3 步之后的截图对不对"。单帧 grounding 评测又只看"目标元素在不在、框得准不准"，不看因果链条。

DDB 插在中间。它直接问：给定前一帧和后一帧，模型能不能还原那次操作的因果作用？这个能力恰恰是 Agent 做状态验证、失败恢复、操作确认的前提。如果连"点了之后屏幕变没变"都判断不了，长任务推理里每一步都在盲走。

论文用的是 Linux 桌面和原生多应用轨迹，不是 Web 沙箱也不是模拟器。这意味着它直接触及真实桌面环境的杂乱——弹窗覆盖、窗口未响应、渲染延迟——这些在干净沙箱里是不存在的噪音。Agent 要想在真实个人电脑上干活，必须在这些噪音里认出真正的状态变化。

2,013 条不算大基准，50 个任务域也有限。但它打中的是一个之前没人定义清楚的评测缺口。如果正在搭桌面 Agent，或者让模型操作浏览器之外的本地应用，这个缺口迟早要面对。

论文附了 PDF，DOI pending，具体模型得分和实验设置在正文里。做 CUA 的人翻一下那几张表格，就能看到自己用的模型在"判断屏幕变了没"这件事上到底有几分。