Execution-Based Agent Evaluation

摘要

Execution-Based Agent Evaluation 通过运行 Agent 并检查环境中的答案或终局状态来判断任务是否完成，而不是要求动作轨迹逐步匹配参考解。它允许多条有效路径，但可靠性取决于环境重置、状态读取器和 evaluator 的覆盖范围。（综合：WebArena: A Realistic Web Environment for Building Autonomous Agents、OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments）

核心内容

定义

该评测先物化任务初始状态，执行一段工具或 UI 交互，再用程序、API、数据库查询、文件解析、UI 状态或文本匹配计算 outcome reward。参考轨迹可以帮助调试，但通常不是判分的唯一合法路径。（来源：WebArena: A Realistic Web Environment for Building Autonomous Agents、OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments）

关键要点

WebArena 的 r_info 检查文本答案，r_prog 查询网页、数据库或 API 状态；多个条件可组合，因此写操作必须真正落到环境中。（来源：WebArena: A Realistic Web Environment for Building Autonomous Agents，§3.2）
OSWorld 用 task-specific getter 和 metric 读取最终文件、配置、cookies、a11y tree 或网页数据，并允许 0-1 的部分得分。（来源：OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments，§2.2.3）
outcome-based 不等于无漏洞：evaluator 可能 false positive/negative、遗漏无关破坏或安全副作用，也可能被公开任务和 validator 细节诱导出 reward hacking。（综合：WebArena: A Realistic Web Environment for Building Autonomous Agents、OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments）
可比结果需要固定任务版本、初始状态、账号、外部依赖、步数与 evaluator 修订；只固定模型名称不足以复现实验。（综合：上述两份来源摘要）
执行式评测还可以把完整 episode 与智能体自身历史、人类解法语料共同比较，分离“方法新颖”与“终局分数改善”。MLE-Bench 实验显示两者并不稳定相关，因此不能把搜索多样性直接当作任务能力。（来源：Can LLM Agents Discover? Evaluating Creativity on ML Engineering Tasks，§3-5）
AutoResearchEval 表明终局分数还会漏掉“用错误方法得到看似正确结果”：必须同时审查代码、日志、数据和报告，并把问题定位到研究阶段；其 800 条轨迹中，科研诚信、事实落地和认知适应问题远多于纯工程故障。（来源：How Do Agents Fail on AutoResearch）
EurekAgent 将 grader 隔离成控制器拥有的外部服务；WMRL 则说明当真实执行过贵时可以用 world model 扩展训练，但必须保留真实 anchor。两者分别处理“评估器可否被修改”和“评估器是否被代理”两类风险。（综合：EurekAgent: Agent Environment Engineering is All You Need for Autonomous Scientific Discovery、Scaling Automatic Research Agents via World Models）
SPEEDRUNBENCH 说明 evaluator 的值域会改变研究结论：同样“完成”Pokemon 的三个在线 Agent 分别需要 160,021、283,474、477,140 帧，连续的完成时间能揭示二元 success 隐藏的 4-12 倍差距；但大量 scorer 调用本身也必须作为评测预算报告。（来源：SPEEDRUNBENCH: Challenging LLM Agents With Video Game Speedrunning，pp.6-9）
MinigamesBenchmark 用固定种子、动作记录和 replay 把纯像素短任务做成确定性 episode，并在四种节奏下分别计完成与时间；它提高了时序故障的可诊断性，但“非预期玩法不计分”仍依赖轨迹审计而非完整自动 verifier。（来源：2026-10-06 CUA 开源项目审计）
Self-improvement 评测还必须保护“谁定义成功”：Protected Baseline Review 要求 requirements、evaluation 与 adoption policy 位于候选系统不可写范围，并同时检查主效用提升和保留能力回退；13 个被审系统中没有一篇明确声明 scoring code 与 test data 对系统不可访问。（来源：Why do improvement require a baseline: structured review of evaluation for 13 self-improving LLM systems）
KERNAUT 展示了结构验证与 held-out evaluator 的互补：Tier 2 construction contract 防止无效 kernel 进入 archive，但最终仍要在未见任务上比较 CRPS；其 22%–58% 跨规模数值失效率说明“通过一次执行”不是稳定正确性的充分条件。（来源：Kernel Autoresearch for Open-Ended Model Discovery）
TRACE 进一步要求把 fresh rollout 的 whole-system sensitivity 与固定轨迹重评分的 evaluator sensitivity 分开；相同条件重跑仍有 15%–36% outcome 翻转，说明单次 score gap 不能直接归因为能力变化。（来源：TRACE: Diagnosing Verifier Brittleness in Agentic Evaluation）
Harness Evolution Ceiling Study 用失败组成、fresh anchor 和 held-out split 决定改 harness 还是训练权重；它同时提醒 WebArena-Lite 的上下文可见性变化与模型输出能力变化必须分开归因。（来源：Harness Evolution Hits a Ceiling: When Weight Training Should Begin）
CUA runtime 的验证还应区分离线单测、fake-adapter CI 与真实桌面 E2E：RDP Computer Use 的 6-job CI 和本地测试没有运行真实 RDP/模型，OpenCode Computer Use 的 macOS 可运行单测也不能证明 Windows live path。（来源：2026-10-08 CUA 开源项目审计）
Contamination Clock 把 evaluator 版本之外的 system snapshot、评测使用 ledger、reuse closure 与 claim currency 纳入运行时状态；模型、memory、prompt、tool 或 harness 的干净更新不会污染旧结果，却会让旧结果不再能证明当前系统。（来源：The Contamination Clock: Evaluation Validity as Runtime State in Adaptive AI Systems）
foxbench 说明 prompt-injection 安全评测必须把“未执行攻击”与“合法任务完成”联合起来：noop 也能阻断 4/4 attacks，但 secure trap passes 为 0/4；只报 attack block rate 会奖励无能力系统。（来源：2026-10-09 CUA 开源项目审计）
Handbrake 与 SideGate 进一步暴露 safety benchmark 的证据边界：前者的 50-screen 结果来自作者构造 HTML，后者的 0% CVR/100% SSR 来自固定 synthetic transitions；即使评测走生产 code path，也必须报告环境真实性、模型参与、跨工具覆盖和不可逆副作用是否真实发生。（来源：2026-10-10 CUA 开源项目审计）
Cua Driver Bench v2 公开逐任务 provenance、failure fixture、oracle 与 checker；对“未量测的后台完成”选择 fail closed，并修复保存顺序与 exactly-one-row evaluator，说明 benchmark 可信度取决于动作遥测和 evaluator contract，而不只取决于任务数量。（来源：2026-10-11 CUA 开源项目审计）
Heliox OS 把 postcondition check 放到 completion claim 之前，并在动作空间不足时返回 GOAL_BLOCKED；但 162 个 action 中只有 22 个有独立 observed verifier，其余 executor-result 路径不能与独立 outcome evidence 混为一谈。（来源：2026-10-11 CUA 开源项目审计）
HealthEnv 将 gold/verifier 与 LLM 指令生成分离，隐藏 verify endpoint，submit 不返回 correctness，并用 oracle 与 adversarial negative states 双向验证环境；但合成规模不能替代结构多样性、真实软件迁移和 adversarial reward-hacking 测试。（来源：2026-10-12 CUA 开源项目审计）
ComputerUseAgent 表明评测 artifact 也应保留失败：没有真实 human traces、正式矩阵未启动和跨任务 calibration 失败都作为一等结果；这比只发布 detector accuracy 更能约束 leakage 与 deployment claim。（来源：2026-10-12 CUA 开源项目审计）
DSH Computer User 的 virtual mode 只改变可视化状态而不改变被测应用，因此 evaluator 必须区分 rehearsal telemetry 与真实 world-state transition；Computer Use MCP for Sway 的 post-action screenshot/pixel change 也只能证明画面变化，不能自动证明任务结果正确。（来源：2026-10-13 CUA 开源项目审计）
Cua 的截止 checks 保留 1 个 macOS unit failure；把失败与 27 success、2 skipped 一并记录，比用后续状态覆盖 cutoff 更符合持续更新 runtime 的评测 provenance。（来源：2026-10-13 CUA 开源项目审计）
Reward Placebo Trial 把 execution correctness 与格式 compliance 分成两个 reward arms：两者都在 15 steps 内学会格式，但只有 executor-checked reward 提升 S6。它示范了 verifier 研究必须加入“不会检查真实结果”的 placebo control。（来源：Does the Reward Matter? A Placebo Trial for Zero-Data Self-Play）
2026-10-14 的 CUA 工程进一步要求 outcome honesty：Cua 对非法/缺失 reward、setup-only success 和 cleanup failure fail closed；TaskKit Windows Computer Bridge 则明确 UIA Invoke、pixel change 或截图存在都不自动证明业务效果完成。（来源：2026-10-14 CUA 开源项目审计）
2026-10-15 的 Cua 更新把 sandbox/setup/cleanup 异常从 reward 0 提升为基础设施错误，避免把环境故障误算为 Agent 失败；Screens 则把每个 Agent 的 display、session bus、文件、网络与接管权隔离成可审计 runtime contract。（来源：2026-10-15 CUA 开源项目审计）
2026-10-16 的 DSH Computer Use 用独立 window title 验证拒绝路径没有产生桌面副作用，Duet 读取 Android input dispatcher verdict 并保存跨 actor 报告，Looktap 使 stale ref 与 ambiguous label 显式失败；这类外部状态证据比工具自报 success 更可信。（来源：2026-10-16 CUA 开源项目审计）
2026-10-18 的 iPhone Use Rust 用 mock-wda 注入 drop、apply-drop、lock 与 queue delay，NexusAndroid 在动作前重读 screen/lock/foreground 并由 CI 检查 policy；Magpie Computer Use 同时记录新版只读 smoke 与旧版 GUI E2E 的版本边界，说明 fault injection、fresh-state verifier 与版本化证据应分开记账。（来源：2026-10-18 CUA 开源项目审计）
AtMem Learned Memory Formation 的部署回放表明离线 agreement 会被类别失衡伪装：模型与标签 agreement 从 18.36% 升到 73.79%，却对 25 个 required-store 全部拒绝，并在 100 项回放只达到常量 reject 的 20 个 exact decisions。部署 gate 必须包含关键动作覆盖、不可接受错误和真实 workload replay。（来源：Negative Learned Memory Formation: Not Worth Deploying Just for Offline Gain in AtMem）
DeepGym 将写操作的 apply/abandon settling 设为 verdict 前置条件，丢失或截断响应不自动重试；System1 Agents Public231 又把协议有效、概率分布有效、严格有效与 correctness 分开。两者共同说明执行评测不能把“工具有响应”或“格式合法”当成 outcome evidence。（来源：2026-10-19 CUA 开源项目审计）
Reward Description Training Study 说明 verifier 错配不仅能提高错误行为，还可能让 CoT 监控失真；评测必须同时保存 true intent、实际 reward、rollout outcome 与 monitor judgment，不能只检查 Agent 的解释。（来源：Reward Misspecification Degrades Chain-of-Thought Monitorability）
Vigil 与 SolveBind 把 action precondition、pending evidence、successor state 和 terminal evaluator 连成执行协议；Tandem 保留 failed-unscored 的真实 OSWorld evidence，避免被 mock score 覆盖。（来源：2026-10-20 CUA 开源项目审计）
SIConnect 的 exact-action hash/revalidation、HyzeVM 的 failed e2e-linux 与 Private Agent Desktop 的真实 smoke specification 说明评测报告必须分别记录 policy checks、CI outcome 与宿主 E2E，不能把 source completeness 或 compile 当作 computer-use success。（来源：2026-10-21 CUA 开源项目审计）
iPhone Use 拒绝把未验收任务计为成功，BrowserSkill 对 partial execution 返回 unknown 并要求查业务状态，Agent TraceCheck 又在训练前检查 reward/outcome、tool pairing 与 mask；三者分别约束 terminal verdict、运行时不确定性和 trajectory 结构，不能互相替代。（来源：2026-10-22 CUA 开源项目审计）
LBYL 的 SusBench 零样本负迁移和约 33% over-intervention 说明安全 evaluator 必须同时报告适用攻击类与合法完成损失；构造 benchmark 上 ASR 归零不足以证明真实网页通用防御。（来源：2026-10-22 CUA 开源项目审计）

适用范围与边界

适合存在可读取终局状态的 browser-use、computer-use、coding 和工具任务。对审美、长期维护性、用户满意度或不可逆副作用，单一终局 validator 往往不足，应补轨迹审计、安全检查和人工判断。（综合：WebArena: A Realistic Web Environment for Building Autonomous Agents、OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments）

分歧与演变

论文有时把二元通过率、部分 reward 和“success rate”混称。记录结果时应保留 evaluator 的实际值域与聚合方式；OSWorld 的 0-1 fractional reward 不能一律解释为纯二元 pass 比例。（来源：OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments）

来源

待核实问题

需要继续整理 evaluator 鲁棒性、污染审计、安全副作用和跨版本校准的共同量表。

代睿 Wiki

知识导航