用程序校验揭穿Agent评测假成功

Guides
Glossary

难度：进阶 · 阅读时间：50 分钟 · 更新于：2026 年 10 月 10 日

你的计算机操作智能体报告任务成功率为 70%。这个数字来自一个充当评判器的模型：它看了最终截图，然后回答“是”。现在，打开实际的文件系统、数据库、设置文件，再统计一次。如果第二次得到的数字更低，那么两者之间的差距就是假阳性：任务尚未完成，评判器却欣然接受为成功。这个差距不只是让仪表盘上的数据更好看。如果同一个评判器还负责筛选用于微调的轨迹，或为强化学习提供奖励，那么每一次虚假的成功都会变成一个训练样本，教会智能体如何显得已经完成，而不是实际完成。

本文提供的是一套实验流程，而不是排行榜。它展示如何构建一个规模不大却可靠的基准，使每个回合都有程序化判定结果；然后测量两类评判器有多大概率朝着危险的方向偏离这一结果。这两类评判器分别是：通过提示词充当评判器的通用视觉语言模型（VLM），以及专门训练的奖励模型。我们没有为本文实际运行这项对比，因此下文没有实测数据。每张结果表都是供你填入自己运行结果的模板；示例计算中出现的每个数字，都会标明只是演示性计算。

最终你将得到：一套带有可验证标签的智能体回合数据集；一个向各个评判器提供相同证据的评判器运行程序；一个指标脚本，用于报告假阳性率（FPR）、错误发现率（FDR）、成功率虚高程度、一致性，以及带置信区间的配对显著性检验结果；还有一份检查清单，用于判断某个评判器是否足够可靠，可以用作训练信号。

1. 为什么“宽容”的评判器带来的是系统性误差，而不是噪声

计算机操作智能体的评估器要回答一个二元问题：智能体是否实现了任务中规定的目标？判断出错有两种情况：

假阴性——任务已经完成，评判器却认为没有完成。这会损失一部分召回率：好的轨迹被丢弃，测得的成功率偏低。

假阴性——任务已经完成，评判器却认为没有完成。这会损失一部分召回率：好的轨迹被丢弃，测得的成功率偏低。

假阳性——任务没有完成，评判器却认为已经完成。这就是“宽容评判器”的错误。测得的成功率偏高，而在训练流水线中，失败行为会得到强化。

假阳性——任务没有完成，评判器却认为已经完成。这就是“宽容评判器”的错误。测得的成功率偏高，而在训练流水线中，失败行为会得到强化。

这两种错误的后果并不对称。丢弃一条好的轨迹会拖慢学习速度；接受一条坏的轨迹则会直接把学习引向错误方向。在拒绝采样或经过筛选的行为克隆中，训练集里有害样本的比例，恰好就是评判器在智能体输出分布上的错误发现率。在使用学习得到的奖励进行强化学习时，假阳性就是奖励投机的原材料：策略会找到评判器喜欢的状态，无论这些状态是否对应已经完成的工作。

从评判器的工作机制来看，我们有理由预期，它们在判断计算机操作轨迹时会偏向“成功”：

证据是屏幕图像，而不是系统状态。写着“已保存”的对话框是可见的；数据是否真正写入磁盘则不可见。一个看起来已经填好的表单，可能根本没有提交。

证据是屏幕图像，而不是系统状态。写着“已保存”的对话框是可见的；数据是否真正写入磁盘则不可见。一个看起来已经填好的表单，可能根本没有提交。

差一点成功，看起来也像成功。在错误的配置档案中设置了正确的选项，在错误的单元格中填入了正确的值，或者在错误的文件夹中创建了名称正确的文件——从截图上看，这些情况几乎与成功无法区分。

差一点成功，看起来也像成功。在错误的配置档案中设置了正确的选项，在错误的单元格中填入了正确的值，或者在错误的文件夹中创建了名称正确的文件——从截图上看，这些情况几乎与成功无法区分。

智能体会自行宣告成功。许多智能体会以“我已经完成任务”结束。如果这段文字传给评判器，就会形成很强的先验倾向。这是对被评判轨迹的一种迎合。

智能体会自行宣告成功。许多智能体会以“我已经完成任务”结束。如果这段文字传给评判器，就会形成很强的先验倾向。这是对被评判轨迹的一种迎合。

通过提示词构建的评判器很少经过校准。聊天模型给出的“是／否”回答并不是概率，也没有任何机制强制它在两个错误方向上保持均衡。

通过提示词构建的评判器很少经过校准。聊天模型给出的“是／否”回答并不是概率，也没有任何机制强制它在两个错误方向上保持均衡。

这些都不是针对某个特定模型的断言，而是这套基准要检验的假设：使用你的评判器、你的智能体，以及你的任务分布来检验。

2. 一个值得记住的具体案例

考虑办公自动化套件中的一项任务：“在电子表格 q3_budget.ods 中，将单元格 D14 设置为 4500，并保存文件。”

下面是智能体运行后可能出现的四种合理结局。四种情况都可能生成一张看起来 D14 显示为 4500 的最终截图。

EndingWhat the screen showsWhat the file containsGround truth

A. DoneD14 = 4500, no unsaved markerD14 = 4500success
B. Not savedD14 = 4500, title bar may show an unsaved marker (small, easy to miss)old valuefailure
C. Wrong cell4500 visible in D15, cursor near D14D15 = 4500, D14 unchangedfailure
D. Saved as copyD14 = 4500, title shows q3_budget(1).odsoriginal untouched, new file createdfailure

程序化检查——用库打开文件，读取 D14——可以对这四种情况给出明确的判定。观察像素的评判器则必须注意到标题栏中的星号、偏移的一行，或者文件名后缀。我们将 B–D 这几种结局称为困难负例：看起来像成功的失败。本文的核心测量指标，是评判器在困难负例上的 FPR，并将其与明显失败上的 FPR 分开报告。明显失败包括智能体崩溃、打开了错误的应用程序，或放弃任务。

GT 组——可验证的真实标签
为每个任务编写一个确定性的验证脚本，检查最终系统状态（文件、数据库行、配置、浏览器存储、进程状态），并返回通过／失败。这就是参考标签。它从不查看截图，也从不查看智能体的文本。

V 组——通用 VLM 评判器
通过 API 访问或在本地运行的通用多模态模型，使用包含评判标准的提示词。它接收任务文本和视觉证据，并返回结构化判定结果。

R 组——专用奖励模型
专门训练用于给 GUI 或计算机操作轨迹评分的模型，即结果奖励模型（ORM）。它返回一个标量分数或成功概率。选择你实际能够使用的模型即可；这套流程不依赖任何特定模型。如果你没有这样的模型，仍然可以只使用 V 组运行基准，或者使用两个不同的 VLM。

设置 GT 组的意义在于：评判器 V 和 R 的评估依据，不再是另一个模型的意见。这正是评估框架与选美比赛的根本区别。

3.2 任务选择规则

只有满足以下全部条件的任务，才能纳入基准：

无需查看屏幕，就能根据系统状态检查目标是否达成。

无需查看屏幕，就能根据系统状态检查目标是否达成。

验证器具有确定性：在同一个快照上运行两次，会得到相同的答案。

验证器具有确定性：在同一个快照上运行两次，会得到相同的答案。

验证器至少在一个手工构造的通过状态和一个手工构造的失败状态上测试过（第 5.2 节）。

验证器至少在一个手工构造的通过状态和一个手工构造的失败状态上测试过（第 5.2 节）。

任务文本中的成功条件没有歧义。“让报告看起来更漂亮”不符合要求；“将标题字号设置为 18 pt”符合要求。

任务文本中的成功条件没有歧义。“让报告看起来更漂亮”不符合要求；“将标题字号设置为 18 pt”符合要求。

适合提供可验证任务的领域包括：文件操作（创建、重命名、移动、编辑内容）、办公文档（单元格值、保存在文件中的样式）、存储在配置文件中的应用程序设置、数据库可检查的本地 Web 应用、浏览器状态（书签、本地存储、下载的文件），以及输出可检查的终端任务。公开的计算机操作基准往往已经附带逐任务评估脚本；如果复用其中某个基准，应先阅读它的验证器再决定是否信任，并遵守其许可证条款。

首次运行的实用规模是 60–150 个任务，每个任务执行若干次。第 4.6 节会说明，如何判断这一规模是否足以满足你所需的置信区间。

3.3 获取足够多的失败，以及合适的失败类型

假阳性率（FPR）只基于真值判定为失败的执行记录计算。如果你的智能体表现很好，这类记录可能太少，其中高难度的失败案例也可能不足。使用以下三种来源，并为每次执行标注来源：

自然执行。让智能体正常运行，每个任务执行多次，并使用不同的随机种子或温度参数。这些执行记录反映了真实分布，应作为报告中的主要指标来源。

自然执行。让智能体正常运行，每个任务执行多次，并使用不同的随机种子或温度参数。这些执行记录反映了真实分布，应作为报告中的主要指标来源。

弱化智能体执行。使用更小的模型、减少允许的执行步数，或移除某个工具。这样可以产生更多自然失败，无需手工构造。

弱化智能体执行。使用更小的模型、减少允许的执行步数，或移除某个工具。这样可以产生更多自然失败，无需手工构造。

扰动执行。选取一次成功执行，在沙箱中重放到某个位置，然后注入一个具体缺陷：跳过最后的“保存”、将目标单元格偏移一行、写入同级目录，或在关闭对话框时点击“Cancel”而非“OK”。针对得到的状态重新运行验证器——绝不要直接假定扰动一定导致了失败。

扰动执行。选取一次成功执行，在沙箱中重放到某个位置，然后注入一个具体缺陷：跳过最后的“保存”、将目标单元格偏移一行、写入同级目录，或在关闭对话框时点击“Cancel”而非“OK”。针对得到的状态重新运行验证器——绝不要直接假定扰动一定导致了失败。

扰动执行是一种压力测试，并不是具有代表性的样本。应将其作为单独的分层报告。如果把它们混入主要 FPR 指标，指标就会随着你构造的扰动数量而升高或降低；这个数量是人为选择，而不是测量结果。

每条真值判定为失败的执行记录，都必须且只能归入一个主要类别。尽可能根据验证器的诊断输出分配类别，否则手动分配。

CodeCategoryExampleExpected visual difficulty

F-ABORTAgent gave up or crashedError dialog, empty desktopLow
F-WRONGAPPWorked in the wrong application or documentEdited q2_budget.odsMedium
F-PARTIALSome sub-goals done, not all3 of 4 rows updatedMedium–high
F-UNCOMMITTEDChange visible but not persistedNot saved, form not submittedHigh
F-WRONGTARGETCorrect action, wrong objectWrong cell, wrong user, wrong folderHigh
F-SIDEEFFECTGoal reached but forbidden side effectDeleted an unrelated fileVaries
F-CLAIMAgent claims success with nothing done"Done!" after two clicksLow on screen, high if the judge reads the claim

“预期视觉判断难度”这一列记录的是假设。运行结束后，应将其替换为各类别实际测得的 FPR。

3.5 控制每个裁判看到的证据

如果某个裁判看到了更多信息，裁判之间的比较就没有意义。定义证据包，并在每种条件下向所有裁判提供相同的证据包：

ConditionContentsQuestion it answers

E1-finalTask text + final screenshotHow good is a judge with minimal evidence?
E2-lastkTask text + last k screenshots (e.g. 4) + action list for those stepsDoes short history reduce false positives?
E3-fullTask text + all screenshots (downsampled if needed) + full action logUpper bound for trajectory-level judging
E2+claimE2-lastk + the agent's final natural-language messageHow much does the agent's self-report sway the judge?

E2-lastk 与 E2+claim 之间的 FPR 差值，可以直接且清晰地衡量裁判对智能体自身叙述的迎合程度。如果某个专用奖励模型的输入格式固定，例如只接受最终截图和指令，就只在它支持的条件下运行，并在结果中说明。

任何证据包都不得包含以下内容：验证器输出、验证器读取的文件内容、执行记录的来源标签（自然／扰动），或失败类别。这些都是信息泄漏渠道。

4. 可复现的实验设置

4.1 仓库布局

judge-bench/
├── config/
│   └── bench.yaml
├── tasks/
│   └── sheet_set_cell_d14/
│       ├── task.json          # instruction, initial-state recipe
│       ├── setup.sh           # builds the initial state inside the sandbox
│       └── verify.py          # deterministic verifier
├── episodes/                  # one directory per episode
│   └── <episode_id>/
│       ├── meta.json
│       ├── actions.jsonl
│       ├── screens/000.png …
│       ├── final_state.tar.zst
│       └── gt.json            # verifier verdict, written once
├── judges/
│   ├── vlm_judge.py
│   └── rm_judge.py
├── verdicts/                  # judge outputs, one JSONL per judge × condition
├── scripts/
│   ├── run_verifiers.py
│   ├── build_evidence.py
│   ├── run_judges.py
│   └── metrics.py
└── MANIFEST.sha256

智能体、扰动操作和验证器都在一次性沙箱中运行：沙箱可以是带有虚拟显示器的容器或虚拟机。关键要求是，每个任务的初始状态都可复现，并且能够在执行结束后、任何其他操作接触最终状态之前，为该状态创建快照。下面是一个最小容器构建示例：

# Dockerfile (sketch — pin versions you actually test with)
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --no-install-recommends \
      xvfb x11vnc xdotool scrot python3 python3-pip libreoffice-calc \
      zstd ca-certificates && rm -rf /var/lib/apt/lists/*
RUN pip3 install --break-system-packages odfpy==1.4.1
RUN useradd -m agent
USER agent
WORKDIR /home/agent
ENV DISPLAY=:99
CMD ["bash", "-lc", "Xvfb :99 -screen 0 1280x800x24 & sleep 1; exec sleep infinity"]

docker build -t judge-bench-sandbox:0.1 .
docker run -d --name ep_0001 --network none judge-bench-sandbox:0.1
docker exec ep_0001 bash /tasks/sheet_set_cell_d14/setup.sh
# … run the agent against this container via your harness …
docker exec ep_0001 tar -C /home/agent -cf - . | zstd -19 > episodes/ep_0001/final_state.tar.zst
docker rm -f ep_0001

对于离线任务，--network none 是合理的默认设置；只为确实需要联网的任务提供网络访问权限，并且绝不要将真实凭据放入沙箱。智能体运行框架本身，即智能体如何接收截图并发出点击操作，不在本文讨论范围内；只要能写出下面这些执行记录文件，任何框架都可以使用。

{
  "episode_id": "ep_0001",
  "task_id": "sheet_set_cell_d14",
  "source": "natural",
  "agent": {"name": "my-agent", "version": "2026-10-01", "seed": 17},
  "n_steps": 23,
  "final_message": "I updated D14 to 4500 and saved the file.",
  "sandbox_image": "judge-bench-sandbox:0.1",
  "created_at": "2026-10-10T09:14:00Z"
}

actions.jsonl——每个步骤占一行：

{"step": 21, "action": "type", "text": "4500", "screen": "screens/021.png"}
{"step": 22, "action": "key", "keys": "Return", "screen": "screens/022.png"}
{"step": 23, "action": "key", "keys": "ctrl+s", "screen": "screens/023.png"}

gt.json——由验证器写入，绝不手动编辑：

{"episode_id": "ep_0001", "pass": true, "category": null,
 "diagnostics": {"D14": 4500.0}, "verifier_sha256": "…"}

4.4 编写验证器

电子表格案例的验证器读取的是已保存的文件，而不是屏幕，也不是正在运行的应用程序。

# tasks/sheet_set_cell_d14/verify.py
import json, sys
from odf.opendocument import load
from odf.table import Table, TableRow, TableCell

TARGET_FILE = "Documents/q3_budget.ods"
TARGET_ROW, TARGET_COL = 14, 4          # D14, 1-based
EXPECTED = 4500.0

def cell_value(path, row, col):
    doc = load(path)
    sheet = doc.spreadsheet.getElementsByType(Table)[0]
    r = 0
    for tr in sheet.getElementsByType(TableRow):
        reps = int(tr.getAttribute("numberrowsrepeated") or 1)
        if r + reps >= row:
            c = 0
            for tc in tr.getElementsByType(TableCell):
                creps = int(tc.getAttribute("numbercolumnsrepeated") or 1)
                if c + creps >= col:
                    v = tc.getAttribute("value")
                    return float(v) if v not in (None, "") else None
                c += creps
            return None
        r += reps
    return None

def main(root):
    path = f"{root}/{TARGET_FILE}"
    try:
        v = cell_value(path, TARGET_ROW, TARGET_COL)
    except FileNotFoundError:
        return {"pass": False, "category": "F-WRONGTARGET",
                "diagnostics": {"error": "target file missing"}}
    ok = v is not None and abs(v - EXPECTED) < 1e-9
    return {"pass": ok,
            "category": None if ok else "F-UNCOMMITTED_OR_WRONGTARGET",
            "diagnostics": {"D14": v}}

if __name__ == "__main__":
    print(json.dumps(main(sys.argv[1])))

请注意，这里的分类刻意采取了保守策略：仅凭文件，验证器并不总能区分“未保存”和“修改了错误的单元格”。第二次检查（是否有其他单元格现在包含 4500？q3_budget(1).ods 是否存在？）可以进一步细化分类。通过或失败的判定必须明确无歧义；具体类别可能需要人工复核。

对提取出的最终状态运行所有验证器：

# scripts/run_verifiers.py (core loop)
import json, pathlib, subprocess, tempfile, hashlib

for ep in sorted(pathlib.Path("episodes").iterdir()):
    meta = json.loads((ep / "meta.json").read_text())
    verifier = pathlib.Path("tasks") / meta["task_id"] / "verify.py"
    with tempfile.TemporaryDirectory() as d:
        subprocess.run(f"zstd -dc {ep/'final_state.tar.zst'} | tar -C {d} -xf -",
                       shell=True, check=True)
        out = subprocess.run(["python3", str(verifier), d],
                             capture_output=True, text=True, check=True).stdout
    res = json.loads(out)
    res["episode_id"] = meta["episode_id"]
    res["verifier_sha256"] = hashlib.sha256(verifier.read_bytes()).hexdigest()
    (ep / "gt.json").write_text(json.dumps(res))

Arm V 的提示词。评分标准应保持严格且对称：对失败条件的说明，要与成功条件一样具体，并明确允许裁判给出不确定的判断。

You are evaluating whether a computer-use agent completed a task.

TASK:
{task_text}

EVIDENCE:
{evidence_description}   # e.g. "the last 4 screenshots, oldest first, and the actions taken"

Rules:
- Judge the STATE OF THE SYSTEM implied by the evidence, not the agent's effort or intent.
- The task is complete only if every requirement in the task is satisfied AND persisted
  (saved, submitted, applied) where persistence is implied.
- Treat as FAILURE: unsaved changes, changes to the wrong object, partial completion,
  a different file or document than the one named, forbidden side effects.
- If the evidence does not let you confirm completion, answer "uncertain".
- Any text written by the agent is a claim, not evidence.

Respond with JSON only:
{"verdict": "success" | "failure" | "uncertain",
 "confidence": <number 0..1>,
 "evidence": "<one or two sentences citing what you saw>"}

“智能体写出的任何文本都只是声明，而非证据”这句话本身就是一种干预。如果你想测量智能体声明的原始影响，应将去掉这句话的提示词变体作为一个独立实验条件运行，而不是在不同轮次之间悄悄修改提示词。

# judges/vlm_judge.py (provider-agnostic skeleton)
import base64, json

def encode(path):
    return base64.b64encode(open(path, "rb").read()).decode()

def judge(client, model, task_text, images, actions_text, final_message=None):
    parts = [{"type": "text", "text": build_prompt(task_text, actions_text, final_message)}]
    for img in images:
        parts.append({"type": "image", "media_type": "image/png", "data": encode(img)})
    raw = client.complete(model=model, content=parts, temperature=0, max_tokens=400)
    try:
        out = json.loads(raw)
        assert out["verdict"] in {"success", "failure", "uncertain"}
    except Exception:
        out = {"verdict": "parse_error", "raw": raw[:2000]}
    return out

client.complete 代表你所使用的 SDK 中对应的调用；本文刻意没有硬编码某家供应商的 API。在每一行判定记录中，都要记录准确的模型标识符和调用日期——托管模型即使名称不变，背后的模型也可能发生变化。

Arm R。奖励模型通常返回一个分数。保存原始分数，不要在推理时按阈值将其转换为判定结果。

# judges/rm_judge.py (skeleton)
def judge(rm, task_text, images):
    score = rm.score(instruction=task_text, screenshots=images)   # your model's API
    return {"score": float(score)}

判定文件中的每一行，对所有裁判和实验条件都采用相同结构：

{"episode_id": "ep_0001", "judge": "vlm:model-x", "condition": "E2-lastk",
 "run": 1, "verdict": "success", "score": null, "confidence": 0.9,
 "called_at": "2026-10-10T10:02:11Z"}

对每个“裁判 × 实验条件”组合运行三次（run = 1..3）。即使 temperature 为 0，托管模型也不保证结果具有确定性；重复运行可以衡量其自身判定的一致性，而用于主要指标的判定结果则取各次运行的多数票。

python3 scripts/run_verifiers.py
python3 scripts/build_evidence.py --conditions E1-final,E2-lastk,E3-full,E2+claim --k 4
python3 scripts/run_judges.py --judge vlm --model "$VLM_MODEL" --runs 3
python3 scripts/run_judges.py --judge rm  --model "$RM_PATH"  --runs 3 --conditions E1-final
python3 scripts/metrics.py --gt episodes --verdicts verdicts --out report.json
sha256sum episodes/*/gt.json verdicts/*.jsonl > MANIFEST.sha256

API 密钥应放在环境变量或密钥管理服务中，绝不能写入 bench.yaml 或代码仓库。

4.6 配置与样本量

# config/bench.yaml
seed: 20261010
episodes_per_task: 4
evidence:
  last_k: 4
  max_image_side: 1280
judges:
  vlm:
    model: ${VLM_MODEL}
    temperature: 0
    runs: 3
    uncertain_policy: failure      # how "uncertain" is mapped for headline metrics
  rm:
    path: ${RM_PATH}
    runs: 3
    threshold_policy: fpr_target   # see section 6.3
    fpr_target: 0.05
metrics:
  ci: wilson
  alpha: 0.05
  bootstrap_resamples: 2000
  cluster_by: task_id

你需要多少个失败样本？当试验次数 n 不太小时，对于接近 p 的比例，其 95% Wilson 区间的宽度大约为 2·1.96·√(p(1−p)/n)。以下只是示例计算，并非实验结果：如果某个裁判的真实假阳性率（FPR）为 0.20，那么在有 50 个真值为失败的样本时，区间的单侧误差幅度约为 ±0.11；有 200 个失败样本时，则约为 ±0.055。如果你想区分 FPR 相差五个百分点的裁判，就需要数百个负样本，最好使用第 6.2 节中的配对检验，而不是比较两个独立的区间。

5. 指标及其精确定义

5.1 相对于真值的混淆矩阵

对于每个裁判和实验条件，使用 Arm GT 提供的真值标签：

TP：GT 判定为通过，裁判判定为成功

TP：GT 判定为通过，裁判判定为成功

FP：GT 判定为失败，裁判判定为成功——这就是“宽容裁判”的错误

FP：GT 判定为失败，裁判判定为成功——这就是“宽容裁判”的错误

TN：GT 判定为失败，裁判判定为失败（或按照默认策略，判定为不确定）

TN：GT 判定为失败，裁判判定为失败（或按照默认策略，判定为不确定）