CriticGUI
多模态 LLM 能否成为 GUI 智能体可靠的 Critic？
CriticGUI 评估多模态 LLM 能否正确判断 GUI 动作的结果，并解释原因。核心是以状态感知与指令理解为依据的 Critic 能力，而非动作生成。
为什么 Critic 必须观察状态
计划描述的是预期步骤，不能保证界面实际如何变化。打开对话框可能带来显著变化，选中输入框却可能只改变一个细小标记。下一步指令必须以真正到达的界面状态为依据。
到底评判哪一级动作？
Critic 接收分层指令、动作代码和视觉证据，输出成败标签及原因。一个语义原子动作可以包含多个物理操作，并不一定等于一次点击。
添加内容为“Draft”的水印。
输入“Draft”并应用水印。
将焦点放到水印文本输入框。
判断当前指令，而不是整项任务。 即使水印尚未生成，成功选中输入框也意味着当前步骤完成。
有推进与已完成，是两个问题。 聚焦输入框可以完成当前原子指令，但水印子任务仍未完成。评估必须明确判断哪一层目标。笔记中，我进一步考虑将 helpful 与 complete 分开；这属于标签设计上的探索，不是下文结果已经验证的新增指标。
标注过程中发现了什么
逐条标注轨迹后，我发现一些看似合理的判断，仍然可能没有理解真正的任务。
细微变化可能是决定性证据
选择链接编辑工具时，文档主体可能几乎不变。工具模式、指针形态和局部界面线索，比前后两张图整体上是否相似更重要。
标签判对了，原因仍然可能错
在链接框选的标注笔记中，我将失败归因于没有完整覆盖目标文字。模型也判断失败，但理由是最终截图里看不到矩形——此时界面实际上已经打开了 Create Link 对话框。标签与标注一致，解释却依据了另一种对证据的理解。框选过程中的几何信息，未必还保留在最终截图中。
标签一致，不代表解释忠实于实际过程。 这是标注中的定性发现，并非单独完成的解释质量量化评测。
操作执行成功，也可能违背用户目标
另一个任务要求调整 PDF 页面的顺序，界面却进入了删除确认框。点击 OK 确实成功删除了一页，页数从三页变为两页，但偏离了用户目标。此时应该取消错误操作。Critic 需要识别这种冲突，不能把局部操作执行成功当成任务成功。
围绕一个原子动作构建样本
每条样本将一个原子指令与对应代码、前后截图和视频片段对齐。图中样本检查是否在签名输入框中输入了“GUICritic”，标签和解释针对这一局部结果，而不是整个签名流程是否完成。
为什么引入 Human Demonstration？
Agent 探索能够提供自然发生的成功与失败，但也受到执行它的 MLLM 能力限制。面对困难任务，agent 可能还没有到达我们希望评估的关键状态，就已经执行失败。只收集它能够完成的过程，会限制任务的多样性与复杂性，也容易让评估过度贴近数据采集模型自身的行为范围。
人工演示用来扩展这些难以覆盖的状态和交互。 人可以完成复杂流程、保留细微的中间状态变化，并引入可控错误。两种来源相互补充：agent 探索提供自然行为，人工采集让困难案例更容易到达和复现。Agent 部分参考 WorldGUI，人工演示工具整理在 CriticGUI 仓库。
执行困难与判断困难并不是同一件事。 Agent 采集可能卡在一个状态，反复产生重复或关联较弱的样本。人工演示让我们能够到达后续状态，设计细微对照，包括那些容易操作、却难以判断是否真正达标的交互。
从人工校正的计划到 Critic 样本
- 生成计划草稿。 MLLM 根据用户 query 和初始界面提出操作流程，也可以结合教程视频或转写文本。
- 人工修订并固定计划。 修正操作顺序与界面细节，拆分非原子操作，保持高层目标 → 低层子任务 → 原子交互三层结构。人工审核后的版本才作为 ground-truth plan。
- 逐条执行与录制。 演示者同时看到三层上下文，按最细的 atomic instruction 执行，保存输入事件与视觉证据。一个语义上的原子交互可以包含多次物理按键或鼠标事件。
- 构造受控负例。 恢复对应的起始状态，在同一条目标指令下人为改变执行方式，单独录制扰动版本并记录偏差，而不是直接给成功录像换一个标签。
- 审核判断与原因。 根据实际结果标注成功或失败，并将解释、计划、动作表示、截图与视频一起保存。试图制造错误不代表一定失败，标签应以观察到的结果为准。
发布的工具负责计划结构校验、分步骤录制、独立变体与已审核样本导出；计划校正、状态恢复和扰动设计仍由人完成。
如何构造有信息量的对照
构造笔记重点探索了在两个位置引入难度：动作前的状态，以及动作本身。以下是研究设计选项；发布的录制工具支持独立尝试与人工审核，并不自动实现全部增强方式。
| 改变什么？ | 例子 | 检验什么？ |
|---|---|---|
| 起始状态 | 前置条件未满足、步骤部分完成，或目标已经满足。 | 动作在当前状态下是否合适、是否必要。 |
| 动作或结果 | 点到相邻错误目标、文字未全选、放置位置偏移。 | 结果是否真正满足指令要求。 |
| 指令与动作配对 | 将相邻步骤与不同指令重新配对。 | 证据是否符合目标步骤；需重新审核标签。 |
状态是相对于指令而言的：屏幕没变，可能是操作无效，也可能任务本来已经完成，或者观察遗漏了细微变化。重复操作和重新配对并不自动构成负例。
纠错要从错误发生后的实际状态出发。 只有原动作的前置条件仍成立时，才能复用正确演示中的代码。同时，原子交互是语义单位：一次拖拽可以包含移动、按下、移动和释放等多个事件。
实验发现
初始数据集包含 56 个任务的 540 条样本（266 条成功、274 条失败），覆盖 Acrobat、PowerPoint、Word、Windows Settings 与网页任务。GPT-4o 的结果如下：
| 指标 | 报告结果 |
|---|---|
| Accuracy | 73.3% |
| Balanced accuracy | 73.9% |
| True positive rate | 84.9% |
| True negative rate | 63.0% |
识别失败比识别成功更困难。错误分析发现，模型容易过度依赖最终截图、遗漏状态变化，以及混淆原子步骤进展与整项任务完成。
还有哪些边界
这是一个小规模离线基准，初步实验以 GPT-4o 为中心，不能直接代表当前所有模型，也不能证明接入 Critic 就会提升在线智能体的成功率。
论文提出用 BERTScore 比较解释，但分类结果表并不能证明解释忠实于事实。扩大模型覆盖，并直接核验原因是否符合视觉证据，是后续需要补充的部分。
设计如何演变
早期笔记尝试围绕屏幕更新来划分计划，后来我将两个问题分开：计划应保留语义上的目标和子任务，执行阶段则决定什么时候重新观察界面。固定计划不能替代对实际状态的判断。
我还探索过统一 Step Check 与 Actor Critic、多轮自我修正，以及从视频识别原子操作。这些在笔记中仍是研究方向，本文不将其写成已经训练完成的模型或验证过的在线提升。