Interactive Reward Agent：GUI 任务的判定权，该从截图交回环境状态

判断一个 GUI agent 有没有完成任务，长期以来只有两条路。一条是给每个任务手写校验脚本，去查文件、查配置、查数据库——准，但一个任务一份脚本，没法规模化。另一条是把执行轨迹的截图丢给 VLM，让它看图判断——能覆盖任意任务，但只能看见屏幕上显示出来的东西。

问题在于，大量任务的完成证据根本不在屏幕上。把 Impress 演示文稿导出成桌面上的 res.png，成功与否取决于那个文件存不存在、内容对不对，而不是导出对话框有没有闪过。用命令行改完 Calc 的单元格，表格视图不刷新，截图里还是旧数据。VLC 的界面模式切过去了，但设置有没有落盘进配置文件，界面不会告诉你。

Interactive Reward Agent（arXiv:2607.25904，北京理工大学 / BIGAI / 深圳北理莫斯科大学 / 清华）把这件事归结成一句话：可靠的 GUI 奖励建模主要是一个证据验证问题，不是一个视觉分类问题。方法上，它让评测器先把指令分解成一组显式的完成条件，再对每个条件主动调工具去环境里取证。321 条轨迹的 GUI-RewardBench 上准确率 86.9%，把这个评测器接进 RL 训练当奖励，OSWorld 成功率 34.0%，对照人工脚本奖励的 34.9%。

目录

1. 为什么这篇论文值得关注
2. 背景与问题定义：三种评测范式的能力边界
3. 核心思路：propose-then-verify
4. 方法拆解
5. GUI-RewardBench 是怎么造出来的
6. 实验结果与分类别表现
7. 验证代价与工具使用分布
8. 自动任务生成与人机一致性
9. 接进 RL 训练当奖励
10. 对 APP 自动化测试 / Mobile QA 的启发
11. 局限性与点评
12. 总结
13. 参考链接

为什么这篇论文值得关注

过去三天，本站连着拆了三篇路子不同但指向同一处的工作。7 月 28 日那篇把视觉状态迁移当作训练信号，7 月 29 日的 StateAct 把程序状态当作动作底座，这篇则把环境状态当作奖励 oracle。三篇的共同判断是：屏幕像素是程序状态的一次有损投影，凡是把 agent 的感知、动作或判定完全压在这层投影上的设计，都会在长程任务里付出代价。IRA 打的是最后一环，也是工程上最容易被忽略的一环——评测器错了，训练信号就是噪声，再好的 RL 算法也救不回来。

这一环之所以关键，是因为 GUI agent 领域正在大规模转向 RL 和 test-time scaling，而这两条路都要求一个能规模化的奖励源。目前主流做法是拿 VLM 当评测器（WebRL、ZeroGUI、DigiRL、DistRL 都是这个范式），论文的实验直接量出了这条路的天花板：最强的 DistRL 在 GUI-RewardBench 上准确率 78.8%，召回率只有 65.5%。也就是说，超过三分之一真正成功的轨迹被判成了失败，这些样本在 RL 里拿到零奖励。这个数字比”评测器不够准”要严重得多，它意味着当前很多基于 VLM 奖励的 GUI agent 训练管线，其实是在一个系统性偏负的信号上做优化。

背景与问题定义：三种评测范式的能力边界

论文把评测形式化得很清楚。给定任务指令 $T$、截图证据 $S_{traj} = (I_{init}, I_{final})$、以及执行后的环境状态 $S_{env}$，评测的目标是给出奖励 $r \in [0, 1]$。

脚本评测器用人工标注的任务专属校验函数 $F_T$，只吃环境状态：$r_{script} = F_T(S_{env})$。准确，但必须为每个任务单独写。

VLM 评测器用视觉语言模型 $G_\theta$，只吃截图：$r_{vlm} = G_\theta(T, S_{traj})$。跨任务通用，但看不见 $S_{env}$。

IRA 的定位是把两者的可及范围合起来，同时保留 VLM 的通用性。关键设计不是”把环境状态一股脑塞进上下文”——文件系统、配置项、应用状态的组合空间太大，也不知道哪些相关——而是把证据获取本身变成评测流程的一部分：先判断该验什么，再决定去哪儿取证，最后拿取到的证据下结论。

核心思路：propose-then-verify

流程分两段。

Propose（提出条件）：VLM 不直接判断任务成没成，而是把指令翻译成一组具体的、可验证的完成条件 $\{C_i\}_{i=1}^{N}$。条件的形态是”某个文件应该存在且内容为 X”、“某个配置项的值应该是 Y”、“某个 GUI 元素应该可见”这类断言。这一步把模糊的自然语言意图转成了明确的检查清单。

Verify（逐条取证）：对每个条件 $C_i$，agent 走一个 ReAct 式的推理-动作-观察循环。第 $t$ 步，它基于条件和已积累的交互历史 $H_i^{t-1}$ 选一个工具动作：

$$a_{i,t} = \mathrm{IRA}(C_i,\ H_i^{t-1})$$

工具查询环境状态返回观察 $o_{i,t} = \mathrm{Tool}(a_{i,t},\ S_{env})$，观察追加进历史。如果证据不足或有歧义，agent 不会直接判定条件满足，而是换一个证据来源再发一次工具调用。 这是 IRA 和”一次性把观察塞给模型让它判断”的 agent-as-judge 的本质区别——取证是迭代的，上一次工具调用的结果决定下一步查什么。

积累够证据后给出二值判定 $y_i \in \{0, 1\}$，且只有当观察里存在明确的环境状态证据表明 $C_i$ 满足时才置 1，否则置 0。这条规则是 IRA 后面所有实验里”高精确率、低召回率”表现的根源。

最终奖励是条件满足比例：

$$r_{ira} = \frac{1}{N}\sum_{i=1}^{N} y_i$$

二值化时以 0.8 为阈值。这个聚合方式很朴素——所有条件等权、直接求平均——但它顺带给出了一个部分完成度信号，这在 RL 里比纯二值奖励好用。

方法拆解

三组工具

工具分三组，对应三类证据来源：

• 系统工具：execute_vm_command（执行 shell 命令查系统状态）、get_vm_file（读虚拟机文件内容）、get_terminal_output（取命令历史与输出）、get_host_file_content（读宿主机文件）、get_accessibility_tree（查界面结构、标签、角色、取值）。
• 应用工具：check_word_file / check_excel_file / check_ppt_file 这类针对具体文档格式的校验器，以及 get_ppt_xml 这样的结构提取器。
• GUI 工具：通过交互式导航暴露那些只有点进去才看得到的界面状态。

工具集不是每次都全量加载。系统工具和 GUI 工具常驻，应用工具按目标应用激活。这个设计在工程上很实在——工具描述本身要占上下文，一个评测任务通常只需要其中两三个。

这套工具集里还有写权限，这点容易被忽略。execute_vm_command 能执行任意 shell，GUI 工具会真实点击界面。论文也承认”GUI 工具或可执行命令可能造成状态迁移”。评测器能改动它正在评判的环境，这件事后面会展开说。

GUI-RewardBench 是怎么造出来的

这个 benchmark 的构造过程比结果本身更值得抄。

任务来源是 OSWorld 派生任务加人工构造任务，用 UI-TARS-1.5 和 EvoCUA-8B 跑出轨迹。关键在筛选步骤：把录下来的动作序列在多个虚拟机实例上重放，比较最终状态，只保留重放结果相对稳定的轨迹。 初始采样 327 条，各重放三次，剔除 6 条不稳定的，剩 321 条。

这一步筛掉的是”同样的动作序列在不同机器上跑出不同结果”的轨迹。没有这一步，评测器的错误和环境的不确定性就混在一起，任何准确率数字都不可信。

轨迹长度跨度很大，最短 4 步以下，最长超过 80 步。失败轨迹的失败模式也刻意做了多样化：执行错误、部分完成、产物缺失、偏好值写错，以及视觉上看着合理但状态不一致的那一类——最后这类正是截图评测器的盲区。

按验证类型划分：产物验证类 192 条（要检查生成的文档、表格、演示文稿、图片、PDF），隐藏状态类 89 条（要查应用偏好、配置文件、默认处理程序、系统设置），可见状态类只有 40 条（截图就能判）。这个 40:281 的比例本身就是论文论点的量化表达。

评测协议有一处处理得很谨慎：虽然轨迹经过稳定性筛选，但评测仍在活的桌面环境里跑，UI 漂移、应用异步行为、网络波动、重放误差都可能让状态偏离原始记录。所以每次评测跑完后都会执行任务专属校验脚本，用它的输出作为该次运行的 ground truth，再算 TP/FP/TN/FN。这样比较的是”每个评测器对它实际检查过的那个环境状态判得准不准”。

代价是不同方法的正负样本总数会有微小差异——交互式评测器可能改动它检查的环境。论文明说了这一点，是诚实的做法，但也意味着表 1 里各行的分母并不完全相同。

实验结果与分类别表现

主结果很干净。四个被动 VLM 评测器最强的 DistRL 是 78.8% 准确率 / 76.7% F1，三个 IRA 变体全部在 85.0% 以上、F1 全部在 83.9% 以上。IRA + GPT-5.5 拿到 86.9% / 84.9%。

几个值得单独看的数字：

WebRL 的 47.0% 准确率配 100% 精确率、0.6% 召回率——321 条里只判对了 1 个成功。这不是”稍微差一点”，是完全失效。WebRL 是为 web 任务设计的，搬到桌面环境上直接退化成”全判失败”。这提醒一件事：VLM 评测器的泛化能力和它的训练域强绑定，跨域迁移时可能不是性能下降而是崩塌。

IRA 三个后端表现接近，开源的 Qwen3.6-35B-A3B 拿到 85.0%，和 GPT-5.4 的 85.4% 基本持平，而且召回率 79.6% 是三者最高。论文的解读是 IRA 降低了对后端泛化能力的依赖——给不同模型同一套取证与验证流程，开源和闭源后端都能当合格评测器。这个结论对工程落地很关键，意味着这套框架不必绑定在最贵的模型上。

召回率仍然是短板。IRA + GPT-5.5 的召回率 77.6%，34 个假阴性。精确率 93.7% 对召回率 77.6% 的不对称，直接来自那条”只有明确证据才置 1”的规则。作为回归测试的 oracle，这个偏向是可接受甚至可取的；作为 RL 奖励，它意味着约五分之一的成功轨迹拿零奖励。

分类别看更有信息量。提升最大的正是证据藏在环境状态里的那几类：VLC 从 DistRL 的 57.9% 到 IRA-GPT5.5 的 89.5%，GIMP 从 79.4% 到 97.1%，LibreOffice Writer 从 50.0% 到 71.9%，多应用工作流从 71.4% 到 89.3%。

但这张图也暴露了几处不那么漂亮的地方：LibreOffice Impress 上 DistRL 是 80.0%，IRA-GPT5.4 只有 74.0%，IRA-GPT5.5 78.0%，三个 IRA 变体没一个赢过最强的被动评测器。 OS 类别上 IRA-GPT5.5 的 89.3% 也低于 DigiRL / DistRL 的 92.9%。Writer 类别虽然相对提升大，但 71.9% 的绝对值是 IRA 所有类别里最低的，且三个后端数字完全一样（71.9 / 71.9 / 71.9），说明瓶颈不在后端能力，而在这一类任务的条件提出环节。

定性例子把机制讲得很直白。Calc 那个任务通过命令行完成更新，但表格视图没刷新，VLM 从过时截图判失败，IRA 去读表格文件验证了更新后的值。VLC 那个任务截图只显示当前界面模式，确认不了设置是否保存，IRA 定位到配置文件读了存储值。

消融：交互权限本身不够，得有结构

这是全文最有价值的消融。三档设置：VLM-only（只给指令和前后截图）、GUI-only（额外允许与环境交互）、完整 IRA（propose-then-verify + 三组工具）。

GPT-5.4 和 GPT-5.5 在 GUI-only 下精确率和召回率都涨，说明主动检查确实能挖出截图里没有的证据。但 Qwen3.6 是反的——精确率涨了，召回率暴跌。 原因是 GUI-only 验证要求后端自己规划交互、定位界面元素、从错误中恢复、解释结果状态；这些步骤不可靠的时候，“没找到证据”会被误当成”任务失败的证据”。

完整 IRA 设置在三个后端上都改善了精确率-召回率权衡，并且逆转了 Qwen3.6 在 GUI-only 下的退化。结论是：交互权限本身不构成能力，把交互变成结构化验证才行。 IRA 先定义完成条件，再针对每个条件选工具取证，减少了对开放式 GUI 探索的依赖——而开放式 GUI 探索恰恰是小模型最容易翻车的地方。

这个发现对任何想给评测器加工具的团队都直接适用：别只给工具，先给检查清单。

验证代价与工具使用分布

成本这张表必须看清楚。VLM 评测器每任务约 3K token，IRA 的中位数是 14.9K–25.9K，均值是 59.5K–139.1K。

中位数和均值差 4–5 倍，说明分布是重尾的。多数评测三步之内搞定，少数评测会把 token 预算炸掉一个数量级。GPT 后端平均 3.3 步，Qwen3.6 要 8.20 步。在 RL 训练场景下要评上万条 rollout，这条重尾就是实打实的账单和墙钟时间，必须配步数上限和 token 上限。

工具使用分布解释了成本差异的来源。GPT-5.5 有 83.4% 的调用是 execute_vm_command，GUI 工具只占 6.4%，每任务平均 2.34 次工具调用。Qwen3.6 的 execute_vm_command 只占 45.9%，GUI 工具占 50.5%，每任务 7.31 次。

强后端倾向于选少数几个决定性的命令行检查，弱后端靠更广的交互式探索去凑。 这个对比很有工程价值：如果要把这套东西落到成本敏感的环境里，与其换更大的模型，不如把”什么条件该用什么工具查”的映射写进提示词或做成路由，把 GUI 探索压到最后手段。

自动任务生成与人机一致性

IRA 不只是个评测器，论文顺手用它解锁了一条任务生成链路：把已验证任务按初始环境配置（config 字段）分组，同组任务共享同一个起始环境，再让语言模型基于该配置生成可行的指令变体。

生成了 855 个任务，覆盖 9 类应用。但”平均每配置任务数”这一列暴露了多样性的真实情况：整体均值 4.9，Thunderbird 却是 54.0——54 个任务全出自同一份邮件配置（那份配置里预置了收件箱邮件、文件夹、附件、账户设置以及可写的偏好、过滤器、联系人数据）。这些任务的目标不同，起始环境完全相同。所以 855 这个数字对应的独立环境配置大约只有 175 个，任务多样性没有数字看起来那么大。

从 855 个任务里随机抽 100 个，用 Qwen3.6 驱动的 GUI agent 执行，GPT-5.5 版 IRA 判定，人工独立标注作参考。整体一致率 94.0%，Cohen’s κ = 0.84。

分类别看，LibreOffice 是最弱的一档：35 个样本、85.7% 一致率、κ = 0.62。而它恰恰是样本量最大的类别。其余类别多数是 100.0%，但样本量都在 8–19 之间，κ = 1.00 这种值在这个量级上说明力有限。Chrome 那行 κ 标 N/A，通常意味着该类别里人工标注全是同一个类别，kappa 无法计算。

混淆矩阵把 IRA 的性格刻画得很清楚：人工标成功 29 个，IRA 认同 23 个、判失败 6 个；人工标失败 71 个，IRA 一个都没误判成成功。零假阳性、六假阴性。

这个不对称是设计规则的直接产物，也是这套评测器最重要的行为特征。它宁可漏判成功，绝不放过失败。 但这里也有一处需要打折的地方：100 个样本里只有 29 个正样本，负样本占了 71%。在这样的分布下，一个偏保守的评测器天然容易拿到高一致率。94.0% 这个数字的说服力，比在正负均衡集上拿到同样数字要弱一些。

接进 RL 训练当奖励

三档设置：A 用 OSWorld 任务 + 人工脚本奖励，B 用同样任务但把脚本换成 IRA，C 用自动生成任务 + IRA（这批任务根本没有校验脚本）。RL 方法采用 DART，IRA 后端是 Qwen3.6-35B-A3B。

结果是 34.9% / 34.0% / 33.5%。

论文的解读是 IRA 能替代脚本奖励，并且能把没有校验脚本的生成任务转化成有效的训练监督——设置 C 只比脚本设置低 1.4 个百分点。

这个解读方向没错，但需要冷静看：三档结果的差距（1.4 个百分点）小到无法排除训练随机性，论文没有报告多种子的方差。 更关键的是，设置 C 证明的是”用生成任务训练不会变差”，不是”生成任务带来了额外收益”。真正能支撑”IRA 解锁了规模化训练数据”这个论点的实验，应该是 A + C 的组合训练超过 A 单独训练——这个实验没做。

不过反过来说，能做到”不掉点”本身就有价值。人工写校验脚本是 GUI agent RL 里最贵的一环，能用一个通用评测器换掉它而不损失性能，工程意义是实打实的。

对 APP 自动化测试 / Mobile QA 的启发

这篇论文的方法论几乎可以原样搬到移动端自动化测试上，而且移动端的收益可能比桌面端更大。

断言生成与断言执行应该拆开

现在的 Appium / Maestro / XCUITest 用例，断言是硬编码在脚本里的：assertTrue(element.isDisplayed())、assertEquals(text, "已保存")。写用例的人在写的那一刻就要同时想清楚”该验什么”和”怎么验”，这两件事耦合在一起，导致断言普遍写得浅——因为深层验证要写的代码太多。

IRA 的 propose-then-verify 把这两件事拆开了。先从自然语言用例描述生成一组完成条件，再由执行层决定每个条件用什么手段去验。 落到 Android 上，条件”用户的深色模式偏好已保存”对应的验证手段可以是读 SharedPreferences XML、可以是 adb shell settings get secure ui_night_mode、也可以是查应用私有 SQLite。用例作者只需要写清楚要验什么。

移动端的”环境状态”比桌面端更丰富

Android 侧现成的只读取证通道很多，且大多数比 GUI 探索便宜得多：

• adb shell dumpsys activity / package / notification / audio / window——查栈、权限、通知、音频焦点、窗口状态
• /data/data/<pkg>/shared_prefs/*.xml 与私有 SQLite——查持久化偏好与本地数据
• content query --uri——查 ContentProvider 暴露的数据
• uiautomator dump（或 Accessibility 节点树）——查界面结构而不是像素，对应 IRA 的 get_accessibility_tree
• logcat 过滤特定 tag——查埋点是否上报、异常是否抛出
• 文件系统检查——对应 IRA 的产物验证类，导出的图片、下载的文件、生成的日志

iOS 侧受限一些，但 xcrun simctl 系列、应用容器目录、NSUserDefaults plist、os_log 也覆盖了大部分场景。

截图-only 的 oracle 在移动端失效得比桌面端更快：动画未结束、列表懒加载占位、图片异步加载、WebView 渲染延迟、深色模式、多机型分辨率与刘海屏适配——这些都会让”截图看着对”和”状态真的对”分离。IRA 的 Calc 案例（命令行改了数据但视图没刷新）在移动端的对应物，是”本地数据库已写入但列表页没有 notifyDataSetChanged”，这类缺陷截图评测器判不出来，而它恰恰是真实缺陷。

保守偏置在回归测试里是优点，在 RL 里是缺陷

IRA 零假阳性、六假阴性的性格，在回归测试场景下是正确的取向：宁可把成功判成失败让人复核，也不要放过真实缺陷。 一个把失败判成通过的自动化测试比没有测试更危险，因为它给了虚假的安全感。

但同一套规则拿去做 RL 奖励就有害了——五分之一的成功轨迹拿零奖励，模型会学到扭曲的信号。如果要把这套思路同时用在测试和训练两个场景，判定规则需要分开配置：测试场景保持”证据不足即判失败”，训练场景应该引入”证据不足”这个第三态，把它从奖励计算里排除掉，而不是当作零。

验证器不能污染被测状态

IRA 的工具集里 execute_vm_command 和 GUI 工具都能改环境，论文也承认这会导致各方法的正负样本总数出现差异。移动端上这个风险更高：GUI 探索会改变 Activity 栈、触发页面埋点、消耗一次性弹窗、污染本地缓存。

落地时应该定死优先级：只读工具（dumpsys / 文件读取 / 节点树 dump）优先，GUI 交互作为最后手段，且 GUI 探索前后做状态快照对比，把探索本身造成的状态变更从判定依据里剔除。CI 里更稳妥的做法是把验证阶段跑在被测流程结束后的一个隔离快照上。

重放稳定性筛选是必须抄的一步

GUI-RewardBench 构造时”重放三次、剔除不稳定轨迹”这一步，是移动端做轨迹评测集时最该照搬的实践。移动端的不确定性来源比桌面端多——网络、推送、系统弹窗、后台回收、动画时序——不先把不稳定用例筛掉，后面所有的 oracle 准确率数字都在测环境噪声。

成本要设硬上限

中位数 15K token、均值 60K 的重尾分布，映射到 CI 里就是”多数用例几秒判完，少数用例卡住把流水线拖垮”。必须配步数上限和 token 上限，超限直接标记为”无法判定”交人工，而不是让它继续探索。 另外，GPT 后端 2.34 次工具调用对 Qwen3.6 的 7.31 次这个对比说明，把”什么条件用什么工具”做成显式路由，比换更大的模型更划算。

可复现的落地路径

如果要在自己的回归集上验证这套思路，建议按这个顺序：

1. 先在现有回归集上量一遍 VLM-only 评测器的召回率。如果它接近论文里 65% 的水平，说明有三分之一的通过用例被误判——这个数字本身就足以推动投入。
2. 按验证类型给用例打标：可见状态 / 隐藏状态 / 产物验证。论文的 40:89:192 分布提示，真正需要环境取证的用例占绝大多数。
3. 用现有的硬编码断言当 ground truth，去对齐生成的完成条件。这一步能直接量出条件提出环节的质量，而不用先建人工标注流程。
4. 从只读工具做起，先不给 GUI 交互权限。论文的消融显示 GUI-only 在弱后端上会让召回率暴跌，先把结构化验证的收益吃干净。

局限性与点评

真正的贡献

把评测重新定义成取证问题，并给出了量化证据。 40:281 的可见/不可见证据比例、DistRL 65.5% 的召回率、GUI-only 消融里 Qwen3.6 的召回率暴跌，这三组数字合起来构成了一个完整论证：截图评测器的问题不是模型不够强，是它看不见需要看见的东西。

证明了结构比权限重要。 GUI-only 与完整 IRA 的对比是全文最有迁移价值的发现。给评测器工具而不给它检查清单，在弱后端上会适得其反。这个结论对所有”给 agent 加工具”的设计都适用。

降低了对后端的依赖。 开源 Qwen3.6-35B-A3B 在这个框架下和 GPT-5.4 打平，召回率还更高。这意味着这套评测器可以自部署，不必把训练管线的奖励环节绑在外部 API 上——对需要大规模评估 rollout 的 RL 场景，这是成本上的关键差别。

重放稳定性筛选。 327 → 321 这个筛选步骤看着不起眼，但它是这个 benchmark 所有数字可信的前提。

可能被高估的部分

RL 实验的说服力有限。 34.9 / 34.0 / 33.5 三个数字，差距在单种子实验的噪声范围内，论文没报方差。设置 C 证明的是”不掉点”而非”有增益”，缺少 A+C 组合训练超过 A 的关键对照。

“855 个生成任务”的多样性被数字放大了。 Thunderbird 一份配置生出 54 个任务，整体 855 个任务背后大约只有 175 个独立环境配置。这些任务在指令层面不同，在环境层面高度同质，用作 RL 训练数据时的实际覆盖度要打折。

人机一致性实验的样本分布偏斜。 100 个样本里 71 个负样本，一个保守评测器在这个分布上天然占便宜。最大的类别 LibreOffice 只有 85.7% 一致率、κ = 0.62，其余类别 κ = 1.00 建立在 8–19 个样本上。

评测器改动被测环境这件事没有量化。 论文承认交互式评测器可能改变它检查的环境，并因此导致各方法的正负样本总数不同，但没有报告这种改动发生的频率和幅度。对一个要被用作 RL 奖励源的组件来说，这是需要量化的风险项，不是脚注。

77.6% 的召回率是没解决的问题。 精确率 93.7% 很漂亮，但作为训练信号，34 个假阴性意味着系统性的负偏。论文对此没有提出缓解方案。

评测范围限于 Ubuntu 桌面。 移动端的验证特征差异很大——沙箱限制更严、系统工具受权限约束、跨应用状态更难访问。方法论可迁移，但数字不可外推。

失败案例揭示的真问题

这张图是全文最诚实的部分。三个失败案例全部来自条件提出错误，而不是取证不足：

• 任务要求增强保护，IRA 提出的条件只检查了标准保护，于是错判为成功
• 任务要求深色模式，IRA 把”Solarized Dark”理解得过于字面，拒绝了一个有效的深色状态
• 任务要求水平镜像图片，IRA 从历史操作记录推断完成，没有验证翻转后的图片是否保存（gimp_mirror_unsaved 这个案例里 IRA 给了 1.00，真值是 0.00）

这说明 IRA 的瓶颈已经从”取不到证据”转移到”不知道该取什么证据”。 用户指令本身是模糊的，会省略语义等价物的可接受范围、会省略持久化要求。这一层不是加工具能解决的，需要在指令意图和完成条件之间做更好的对齐。

对移动端测试来说，这条经验直接对应一个已知痛点：用例描述里的隐含期望。“修改头像”隐含了”退出重进后头像还在”，“添加到购物车”隐含了”角标数字 +1”。这些隐含条件人工写断言时会凭经验带进去，自动生成条件时会漏。可行的缓解是把这类领域约定沉淀成条件模板库，在条件提出环节强制注入——比如凡是涉及编辑操作的条件集，必须包含一条持久化检查。

总结

IRA 的核心主张——GUI 奖励建模是证据验证问题而非视觉分类问题——由三组数据支撑：GUI-RewardBench 上 281/321 的任务需要环境状态证据、最强被动评测器召回率只有 65.5%、完整 IRA 在三个后端上都改善了精确率-召回率权衡且逆转了弱后端在纯 GUI 探索下的退化。

propose-then-verify 这个结构的价值大于它的具体实现。把”该验什么”和”怎么验”拆成两个阶段，让第一阶段吃 VLM 的通用性、第二阶段吃工具的确定性，这个模式可以直接搬到任何需要判定”任务是否完成”的自动化场景——移动端回归测试是最直接的一个。

要打折的部分也清楚：RL 那组实验差距太小且缺方差，生成任务的多样性被数字放大了，人机一致性建立在偏斜的样本分布上，77.6% 的召回率作为训练信号仍然偏保守。失败案例分析指出的方向更值得跟进——瓶颈已经不在取证能力，而在把模糊指令翻译成正确完成条件这一层。

对做 APP 自动化测试的团队，最该立刻做的一件事是量一下现有 oracle 的召回率。如果你的通过判定依赖截图或浅层 UI 断言，论文里 65.5% 这个数字大概率就是你的真实水位。

参考链接

• 论文：Interactive Reward Agent: GUI Task Evaluation via Environment-State Verification (arXiv:2607.25904)
• 项目页：InteractiveRewardAgent-OfficialRepo
• 相关阅读：StateAct：把 Computer-Use Agent 的主循环从『看屏幕』换成『读状态』之后
• 相关阅读：OSWorld 2.0：把长程 computer-use 的评测单元换成真实工作流