Agent 的毕业考·附录卷（下）：评测协议与失败分析

Agents' Last Exam：附录卷（下）

译注：本卷为《Agent 的毕业考：ALE 用 1490 个真实行业任务度量经济价值工作》（https://openqa.cn/articles/agents-last-exam-economically-valuable-zh）的附录 C–D 完整中译，含任务规格协议、评测模式全分类、证据锚定的 LLM 评审探针、GCUA harness 内部结构与 14 个桌面动作工具，以及公开子集代表性、超时分析、两级失败分类法、模型效应与 harness 效应分解、成本效率与逐任务分数热力图。参考文献与附录 A–B 见《附录卷（上）》：https://openqa.cn/articles/agents-last-exam-appendix-1-zh

附录 C 评测流水线细节

C.1 流水线架构细节

本附录展开第 3.1 节所总结、图 6 所描绘的三个解耦组件：任务规格、agent 与环境。

任务规格。 任务规格是专家提交的可执行形式。它封装构建流水线（第 2.3 节）中提供的五个要素：自然语言_描述_、_输入资产_、所需_软件_、_参考资产_（真值输出）与_评测标准_。这些被编码在一个 main.py 文件中，暴露三个生命周期函数：load() 声明任务描述、元数据与计算需求；start() 通过复制输入资产并启动所需软件，把虚拟机置入确定性的起始状态；evaluate() 对照参考或评分细则为 agent 的输出产物打分，返回 $[0,1]$ 内的归一化分数。完整协议详见附录 C.2。

agent。 agent 是被评测的系统，由 _harness_（编排中间件）与_模型_（基础模型）组成。收到由描述与关联元数据构成的任务配置后，agent 进入动作循环：它观察环境（通过截图、shell 输出或文件内容）、选择一个动作（鼠标点击、按键、shell 命令、文件编辑或 API 调用）、执行它，并重复直到决定终止。

环境。 每个任务在一台远程虚拟机内执行，该虚拟机承载所需的工业软件并暴露标准化的文件系统布局。四个目录划分工作区：input/ 包含 agent 读取的资产（例如设计文件、游戏二进制、原始数据）；software/ 存放预装应用及其依赖；output/ 是唯一可写的目标，agent 把交付物存放在此；reference/ 存储仅供评分函数使用的真值产物（执行期间 agent 无权访问该目录）。此布局强制一个干净的契约：agent 从 input/ 读取、向 output/ 写入，并对照 reference/ 比较打分。

计算环境。 所有任务实例都在 Google Cloud Platform（GCP）虚拟机上执行。默认配置为 c4-standard-4（4 vCPU，16 GB 内存）。需要 GPU 加速的任务（例如 3D 渲染、仿真）使用配备 NVIDIA L4 GPU 的 g2-standard-8 实例。少数涉及重型数值仿真的任务，按 load() 中声明的任务计算需求配置更高内存或多核资源。这些资源分配按任务确定，取决于所涉软件与工作负载。

解耦设计的保证。 解耦设计带来两项实际保证。第一，任何 agent，无论其内部架构、模型底座或工具配置如何，只要遵循动作接口（shell 命令、GUI 交互与文件 I/O），都可以在任何任务上被评测。第二，同一任务规格无需修改即可部署到不同的环境后端（云虚拟机或本地容器）。

C.2 任务规格协议

每个任务规格实现三个生命周期阶段，共同确保确定性、可复现的评测。

阶段 1：load()（初始化）。 load() 函数是纯声明式的：它返回一个结构化任务对象，包含 agent 可见的自然语言描述、元数据（文件系统路径、配置参数、任务特定常量）与计算需求（操作系统类型、硬件规格）。此阶段不建立远程连接，也不修改环境状态。它定义任务_是什么_。

阶段 2：start()（环境准备）。 start() 函数把虚拟机转变为任务的确定性起始状态。它通过一个 _session API_ 操作，该 API 提供对远程桌面的程序化访问，包括文件系统操作（创建、复制、删除）、应用管理（启动、安装）、键盘与鼠标控制以及屏幕捕获等。

阶段 3：evaluate()（评分）。 agent 终止后，evaluate() 函数从远程环境取回 agent 的输出产物，对照规格中定义的参考资产或评分细则标准打分。函数返回 $[0,1]$ 内的归一化分数。具体的评测方法学（基于交付物的提取与基于里程碑的报告、评分细则比较与参考匹配，以及防范捷径解的反作弊溯源门槛）在第 3.3 节总结，并在附录 C.3 详述。

C.3 评测模式：完整分类法与实例演练

本附录展开第 3.3 节。我们记录：(i) 评分代码在哪里运行，(ii) 任务作者在比较步骤中可选择的产物模式，(iii) 基准中观测到的分数组合模式，以及 (iv) 支撑 LLM-as-judge 评测的辅助层。全文引用了具体任务实现，读者可查阅完整源码。

#### C.3.1 执行位置

主机侧评分（默认）。 harness 用 session.read_file 或 session.read_bytes 把 agent 的产物从虚拟机拉取下来，然后在主机 Python 进程中运行评分代码。只要 (a) 产物小到足以传输且 (b) 评分工具可在虚拟机外使用，这就是默认方式。示例：

• • finance/equity_research_summary 读取生成的 LibreOffice 工作簿字节，并对照清单调用 score_workbook_bytes。

• • cybersecurity/snake_crackme 读取一个 flag 文件，规范化文本，并把每个候选的 SHA-256 与期望摘要比较。

• • photography/raw_photo_processing 对照参考清单比较导出的文件对。

优先使用主机侧评分，因为评分代码更容易被审查、纳入版本控制，并可离线对保存的轨迹重跑。

虚拟机侧验证器。 当产物需要无法合理迁出虚拟机的软件时（CAD/CAM 内核、无头 3D 渲染器、厂商授权引擎、超大几何），evaluate() 把 tasks/<task>/scripts/ 下的逐任务脚本上传到虚拟机的临时目录，并用 session.run_command 调用它；脚本在 stdout 打印 JSON 结果，主机将其解析为分数。示例：

• • manufacturing/gcode 上传 check_collision.py、simulate_agent.py 与 verify_stl.py，驱动 PowerMill 的 COM API 做碰撞检测与毛坯仿真，然后对照隐藏的参考 STL 为所得 STL 曲面打分。

• • finance/sec_10k_financial_parsing 上传 score_outputs.py，使用虚拟机的 Python 环境对照多文件参考清单为解析后的申报文件打分。

契约是统一的：虚拟机侧验证器严格通过其 stdout JSON 与主机通信，绝不写入 output/。

#### C.3.2 产物模式

每个任务工作流作者为比较步骤选择下列模式中的一种或多种。表 3 总结了各模式与代表性任务工作流。

表 3：任务工作流作者可用的评测模式。大多数 ALE 任务工作流组合两种或更多模式（例如行为门槛加几何评分）。

精确/哈希值。 交付物是一个短字符串（一个 flag、一个解析出的答案、一个标识符）。评分是规范化后的字节相等或哈希相等。因为答案很小而搜索空间很大，这种模式在网络安全与一部分数学任务工作流中占主导。

结构化表格/数值。 交付物是一张表或多字段记录（工作簿单元格、财务申报的行项目、标定参数）。参考是 (字段, 值, 容差) 元组的清单；每个字段在容差内得分并聚合。这种模式在金融、会计与临床数据标准任务工作流中占主导。

几何/空间。 交付物是 3D 网格、点云或任何空间嵌入的产物。评分使用曲面距离函数（例如 gcode 中取 10,000 个曲面样本对照参考 STL 打分，每个「阈值内占比」区间给分）。

视觉外观。 交付物的正确性最自然的判断方式是人眼（渲染场景、重新调色的照片、UI 截图）。主机把 agent 图像与参考图像并排、附上评分细则问题，调用视觉 LLM 评审。

行为/世界状态。 交付物是 agent 编辑之后交互系统的状态。评分在固定轨迹下重放系统并转储可比较的状态（游戏地图、仿真日志、NPC 事件）。

自由文本/语义。 交付物是一份书面报告。评分是一组是/否或分级的子标准构成的评分细则，由 LLM 评审评估。

可执行产物。 交付物是一个程序、模型或流水线。评分让产物在保留测试集或神谕上运行，并聚合逐实例的正确性。

#### C.3.3 分数组合模式

逐模式分数通过四种模式之一组合为最终的 $[0,1]$ 值：

门槛-评分（Gate-and-score）。 一个失败即强制 $0$ 分的硬性前置条件，随后是一个连续分数。用于防止表面接近的产物进行奖励攻击。典型例子：在 manufacturing/gcode 中，PowerMill 碰撞/过切门槛必须先通过，才给几何相似度分；否则无论仿真毛坯模型与参考多么接近，该任务工作流都得 $0$ 分。

加权评分细则。 专家定义的多个子指标加权和，例如 gcode 对 agent 与参考 STL 之间曲面距离分布的

$$\text{score}=0.70\cdot\mathrm{frac\_within}(0.3\,\text{mm})+0.30\cdot\mathrm{frac\_within}(2.0\,\text{mm})$$

权重是任务规格的一部分，并在第 2.3 节的 QC 阶段被评审。

二元检查表平均。 交付物由 $N$ 个独立的是/否问题评判，分数取均值。game/mota_reproduction 任务工作流在一组视觉 LLM 探针（引擎识别、角色精灵存在、地图布局匹配）上使用这一模式。

成对文件聚合。 当交付物是一个文件目录、需与参考目录匹配时，辅助函数 utils.evaluation.collect_matching_files 把每个 agent 文件与其参考配对，对每一对运行同一评分函数，并返回均值。

#### C.3.4 评审类型与 LLM 评审辅助层

默认避免 LLM 评审。 只要存在确定性替代方案，ALE 就刻意抑制 LLM-as-judge 的使用。每个被接收任务工作流的常设规则是：如果交付物可以归约为字节、字段、几何、世界状态或可执行行为，评分代码必须基于这些信号运作，而不是模型对结果的整体意见。一个提议「问 GPT-4 结果看起来对不对」的任务会在第 2.3 节的 QC 阶段被拒绝，要么被重新工程化以暴露可检查的产物，要么被舍弃。这样强制执行有三个原因：(i) 评审模型在不同版本间漂移，会悄无声息地重排 agent 名次；(ii) 通用的「这看起来对吗？」提示过于宽松，无法区分近似正确与正确——而这恰恰是基准最需要分辨 agent 的区域；(iii) 确定性评审可由任何拥有产物的人离线对保存的轨迹重跑，没有 API 成本。

LLM 评审不可避免时。 一小部分任务工作流没有客观的基于代码的参考，主要是创作或感知类交付物，例如渲染场景、音乐制作会话、UV 映射纹理与动画预览。对这些情况，ALE 使用 utils/evaluation.py 中的辅助层：

• • llm_vision_yes_no_judge：对 (agent 图像, 参考图像) 对提出单个针对性是/否视觉问题。

• • llm_vision_binary_questions_sync / llm_vision_binary_checklist_judge：一组独立的是/否探针，最终分数为比例值。

• • llm_vision_judge / llm_vision_json_judge：对一小组固定字段的分级或 JSON 结构化评分细则。

针对性探针，而非通用评审。 ALE 的 LLM 评审工作流最重要的一个性质是：提示词_从不_要求模型抽象地为产物打分。每个提示都是一个狭窄的、证据锚定的是/否探针，由任务作者参照 (a) 工作流使用的具体软件与 (b) 作者在试点 agent 运行中观测到的失败模式编写。模型每次只被问一个结构紧凑的问题；分数由代码从这些答案组合而成。以下是当前任务工作流中逐字使用的探针：

• • game/mota_reproduction（重放时引擎与状态检查）：

• – 「第一张图是否显示该游戏使用 RPGMakerXP 开发？可以通过游戏窗口左上角是否有『橙色太阳状圆形』来识别。」（门槛）

• – 「第一张图是否显示与原游戏相同的地图布局？」

• – 「第一张图是否显示与原游戏相同的玩家状态？」

• • audio/timbre_synthesis（证明 agent 确实使用了 DAW）：

• – 「这张图是否显示 (a) 一个软件合成器/VST 插件界面，带有可见参数如振荡器、滤波器、包络、LFO 或效果器，或 (b) 一个 DAW（例如 Cubase、Ableton、FL Studio、Logic、Reaper）的编排/钢琴卷帘/混音器视图，其中包含一个或多个带音频或 MIDI 片段的轨道？」（门槛）

• – 「这张截图是否提供了用户确实在该项目上工作过的证据，例如一个包含多条带音频或 MIDI 片段轨道的 DAW 编排、一个已录入音符的钢琴卷帘，或一个旋钮/滑杆明显不全在默认/初始位置的合成器插件？」

• • game/uv_reproduction（UV 映射产物对照固定参考的检查）：

• – 「纹理的摆放与朝向是否正确到足以通过？」

• – 「候选是否足够好地保留了参考的材质外观与调色板，从而通过？」

• – 「明显的 UV 接缝、拉伸或纹理瑕疵是否少到足以让结果通过？」

• • game/high_to_low_modeling（减面正确性）：

• – 「候选是否足够好地保留了高模的整体形状，从而通过？」

• – 「候选是否在各采样视角下足够好地保留了主要轮廓，从而通过？」

• – 「候选是否实现了有意义的低模减面，而不是实际上又提交了一遍高模？」

• – 「明显的视觉瑕疵或形状塌陷是否少到足以让结果通过？」

• • game/object_generation（缺失几何修复）：

• – 「缺失几何是否修复得足够好，从而通过？」

• – 「部件的摆放与对齐是否正确到足以通过？」

• – 「整个物体是否足够连贯、完整，从而通过？」

• – 「最终材质外观是否可接受到足以通过？」

• • game/skeletal_animation_reproduction（重放自一致性）：

• – 「提交的预览是否与参考身体动作匹配到足以通过？」

• – 「从 final.blend 渲染的重放是否与提交的预览一致到足以通过？」

• – 「可见的骨架状态与姿态是否足够自然、无破损，从而通过？」

这些探针中反复出现三种模式。(1) 每个问题只针对一个可识别的产物（角落里的一个圆形、DAW 中的一条轨道、一条 UV 接缝、一个轮廓、一个姿态），而不是「交付物好不好」的整体印象。(2) 许多探针写成门槛，即一个二元前置条件，必须在其余评分细则被检查之前成立，因此一张无关截图或一个占位文件在任何质量判断被问及之前就得了 $0$ 分。(3) 其余探针措辞为「……足以通过？」而非分级偏好，这把模型转变为对照固定参考的「相同 vs. 不同」比较器，而非自由形式的质量神谕。这些惯例合在一起，把 LLM 的负担限制在一组领域专家可以从同一张图像复现的决定上，并把 LLM 排除在整合者角色之外：整合（加权、把关与跨实例聚合）始终在代码中进行。

#### C.3.5 评审类型的经验分布

为把「默认基于代码、仅在不可避免时用 LLM」的设计选择具体化，我们报告任务工作流层面评审类型与执行位置的实际分布。表 4 中的比例是通过对开源参考任务树中每个 main.py 及其随附 scripts/ 目录的静态分析得到的，扫描其中对 utils/evaluation.py 中 LLM 评审辅助函数的直接调用，以及对上传的 Python 验证器使用 session.run_command 的情况。

(a) 每个任务工作流的评审类型。

(b) 评分代码的执行位置。

表 4：ALE 参考任务树中开源任务工作流的评审类型与执行位置分布。

在 LLM 评审子集内。 视觉锚定的原语占主导：最常用的辅助函数是 llm_vision_judge、llm_vision_binary_checklist_judge、llm_vision_binary_questions_sync 与 llm_vision_yes_no_judge。其余辅助函数（llm_multimodal_binary_questions_sync、llm_multimodal_text、llm_multimodal_json、llm_vision_json_judge，以及视频评分细则的 gemini_video_json_judge）各自只出现在少数几个任务工作流中。辅助函数可以在单个任务工作流内共现。对视觉辅助函数的集中反映了一个事实：LLM 评审被保留给交付物是渲染场景、照片、截图或短视频、且没有客观代码参考的情形。

在虚拟机侧子集内。 虚拟机侧任务工作流由那些离开机上软件栈就无法打分的行业主导：CAD/CAM（PowerMill、SolidWorks）、授权金融工作簿与无头 3D 渲染。契约是统一的：tasks/<task-workflow>/scripts/ 下的逐任务工作流验证器由 evaluate() 上传到虚拟机的临时目录，经 session.run_command 执行，其 JSON stdout 在主机侧被解析回分数。

组合模式。 静态分析估计发现，绝大多数 evaluate() 主体都包含至少两个先于连续评分路径的 early return $[0.0]$ 位点，与 C.3.3 节的门槛-评分模式一致。形如 $a\cdot x+b\cdot y$ 的显式加权评分细则表达式只出现在一小部分 main.py 文件中；在大多数任务工作流中，加权被编码在 scripts/ 下的逐任务工作流评分脚本内部（上面的静态计数捕捉不到），因此这是加权聚合真实流行度的下界。

#### C.3.6 参考隔离与稳健性

参考隔离。 reference/ 目录位于 agent 工作区之外，且不通过任何非评测调用者会调用的 session API 暴露。大多数 evaluate() 实现以一个完整性检查开始：列出每个所需参考路径，若任一路径缺失则提前返回 $0.0$。这既防止配置错误的运行悄悄产生虚高分数，又把参考契约与评分逻辑记录在同一个文件中。

输出存在性与形状检查。 各工作流一致把「未产生输出」或「输出形状错误」视为 $0$ 分而非崩溃，因此超时或拒绝执行的 agent 仍会得到一个定义明确的数字。

确定性。 基于代码的评审在构造上就是确定性的。对 LLM 评审的任务工作流，我们把评审模型与提示词随结果一并记录，并确保任何分数都可以从 agent 保存的产物重新推导。

#### C.3.7 工作流与任务实例

单个任务工作流（一个 main.py）暴露一组_任务实例_，在代码库中编码为 VARIANTS 元组列表：每个实例带有实例特定配置，但共享同一个 evaluate()。例如，manufacturing/gcode 任务工作流声明 18 个工件实例，每个指向一个不同的空白 PowerMill 项目，但都由同一条「先碰撞门槛、后 STL」流水线打分。逐实例分数平均为任务工作流分数，任务工作流分数平均为行业分数，行业分数聚合为第 4 节报告的集群级结果。当前 ALE 发布共包含 960 个任务工作流与 1,490 个任务实例。

C.4 agent harness 内部结构

本附录详述第 3.2 节介绍的 agent harness 的内部结构。此处描述的架构在宏观层面为主流 harness 实现所共享，例如 Claude Code [4]、Codex [33] 与 OpenClaw，并在我们自己的原生实现中被忠实复现。

主 agent 循环。 harness 运行一个六阶段控制循环：0 _初始化_配置系统提示词与工具绑定；1 _上下文构建_组装当前会话状态；2 _LLM 调用_查询基础模型；3 _决策_把模型输出路由到最终交付或工具调用；4 _收集工具结果_采集执行结果；5 _溢出检查_评估累积上下文是否超过压缩阈值。若未超过，循环返回阶段 1；否则在下一轮迭代前触发上下文压缩。当模型选择交付而非行动时，循环终止。

系统提示词构建器。 初始化时，harness 从模块化组件构建系统提示词：_身份_（agent 人格）、_记忆_（持久跨会话状态）、_工具指引_（每个工具的使用惯例）、_运行时_（环境元数据）、_行为规则_（安全与策略约束）与_技能_（领域特定能力）。这些组件通常通过 CLAUDE.md 或 AGENTS.md 等配置文件编写。

工具系统。 harness 暴露统一的工具接口，模型按名称调用：文件操作（read、write、glob、grep）、shell 执行、网页搜索与抓取，以及子 agent 管理（spawn、list、wait、terminate）。每个工具返回结构化结果，追加到会话上下文。

GUI-as-Tool：CUA MCP 桥。 GUI-as-Tool 模式通过一个 MCP 服务器扩展工具系统，暴露 14 个桌面动作工具，该服务器封装运行在虚拟机上的 CUA（Computer-Use Agent）HTTP API。表 5 列出完整的工具面。

表 5：GUI-as-Tool：经 CUA MCP 桥暴露的 14 个桌面动作工具。

#### C.4.1 工具面与术语

工具分类法与各 agent 的可用性。 工具名称在不同 harness 之间不一致，因此图 9 的分析在聚合前把原始工具调用映射到一个共同分类法。_Bash_ 表示直接的 shell 或终端执行，包括名为 Bash、bash、shell、exec、run_shell_command、terminal、Execute、bash_command 与 execute_code 的工具。_File_ 表示直接的文件系统工具，如 Read、Write、Edit、Glob、Grep、read_file、write_file、edit_file、patch 与 list_directory。_GUI_ 表示表 5 中的 CUA 桌面动作面，包括封装器特定名称如 mcp__cua__click、cua___screenshot 与 mcp_cua_key。_Web_ 表示浏览器或检索工具，如 WebSearch、WebFetch、web_search、web_fetch、webSearch、webFetch 与 browser_navigate。_规划/委派_表示显式的规划、任务跟踪、记忆或子 agent 工具，如 TodoWrite、task、think、delegate、subagents 与 memory_get。_其他_收纳不属于前述各组的过程、会话、完成或 harness 内部实用工具。最后，_Azure desktop_ 指用于 Windows GUI 任务执行的托管 Windows 远程桌面后端；它是执行底座，不是模型提供方，也不是单独的工具类。

子 agent。 复杂任务受益于委派。harness 可以派生专门的子 agent（可访问所有工具的 _General_ 子 agent、限于只读操作的 _Explore_ 子 agent 等），它们在隔离的上下文窗口中运行，并把汇总结果返回父循环。这一机制支持并行探索并限制上下文消耗。

上下文管理器。 长程专业任务经常产生超出模型限制的上下文。上下文管理器实现三层压缩策略：(1) _微压缩_就地清除过时的工具结果；(2) _基于 LLM 的摘要_把较旧的会话片段压缩为结构化检查点；(3) _截断_强制执行上下文窗口硬限制（例如 400K 或 1M token）。这种分级方法在保留长程规划状态的同时保住近期细节。

ALE-Claw 与 OpenClaw。 OpenClaw 是一个个人 AI 助手，有两个主要组件：用户交互运行时与 agent 循环。对于 ALE-Claw，我们移除了那些让长寿命、多用户 AI 助手在生产环境中存活的组件：定时提示子系统（包括 cron 与心跳）、多通道网关、技能系统，以及带生命周期钩子的插件框架。解决单个基准任务不需要这些组件。这一简化把系统提示词减少了约 65%。

agent 循环在原理上与图 8 的设计相似：它接收任务指令，把指令变成一系列工具调用与观察，直到任务完成。OpenClaw 最初用 TypeScript 开发 [36]，这使其难以直接适配 CUA 框架。为解决此问题，我们用 Python 重写了 agent 循环，并添加了少量 CUA 特定适配：一个与 CUA 原生 GUI 面匹配的复合 computer-use 工具，以及一个视觉驱动的 GUI 子 agent delegate_gui——它在 OpenClaw 中没有对应物。我们近乎逐字保留了 OpenClaw 承重的上下文管理原语。

ALE-Claw 本身也有独立价值。通过隔离 OpenClaw 的 agent 循环并移植到 Python，我们让这一设计对更广泛的 Python 研究生态、特别是对 CUA 框架变得可用——原版 TypeScript 实现无法直接插入其中。Python 移植还支持对 agent harness 做动态消融。组件可以就地替换或移除，由此产生的性能变化可以直接测量；这种工作流对原版 TypeScript 运行时是不可行的。作为一个具体的未来方向，ALE-Claw 可以作为固定脚手架，在同一任务套件上对不同 GUI 模型做基准测试。

附录 D 扩展实验结果与分析

D.1 公开子集的代表性

图 11：公开子集代表性。Claude Code + Opus 4.7 在公开子集 (xx) 与完整任务池 (yy) 上逐分类法集群的通过率。点大小 $\propto$ 每集群任务实例总数。强相关性（$r=0.89$）确认公开子集具有代表性。

为验证公开子集尽管规模有限（第 2.3 节）仍能代表更广泛的基准，我们在完整任务池上运行了 Claude Code + Opus 4.7。完整任务池产生更高的通过率。差距的产生是因为公开集包含完整的末考层，而私有池中近期层任务占比更高。图 11 比较了公开子集与完整任务池上逐分类法集群的通过率。两轴强相关（Pearson $r=0.89$，$p<0.001$），表明公开子集忠实地反映了跨领域的完整池难度。大多数集群位于对角线上方，因为私有池中较易任务占比更高，抬升了每个集群的完整池通过率。

D.2 超时分析

ALE 评测对每次运行使用五小时墙钟上限。当一次运行达到上限时，harness 停止 agent，常规评测器对输出目录中已存在的产物打分。在用于表 1 的运行中，3.8% 的被评测运行达到上限。达到上限的运行平均分为 20.7，而更早结束的运行为 33.2。

表 6：按难度层的超时频率。分数是与表 1 相同的 0 到 100 归一化分均值。

表 7：按 harness 的超时频率（仅含至少一次运行达到上限的 harness）。

D.3 失败分类法归类

本附录记录图 9 中失败根因分类法背后的两阶段流水线。

#### D.3.1 阶段 1：轨迹分析

对每个失败任务，一个 LLM（OpenAI Codex）获得对完整运行产物目录的访问权，包括 agent 交互日志（interaction_log.json）、运行元数据（run_result.json、agent_result.json）、评测输出（debug/eval/result.json）与事件轨迹（events.jsonl）。该 LLM 被提示产出一张结构化的 Markdown _分析卡片_，含五个必备小节：

1. 结论：一句话裁定、一个总体判断（成功/部分成功/失败），以及最重要的单一问题。

2. 任务描述：用平实语言解释任务要求什么，包括关键约束与运行时元数据。

3. agent 做对了什么：正确的行为，并给出指向具体日志条目的证据指针。

4. agent 做错了什么：观测到的错误，并给出证据指针。提示词要求把已确认的错误与不确定或推断的原因分开。

5. 评分：最终分数、原始分数明细（如有）、推断的评测标准，以及一个置信度评级。

分析卡片中的每个论断都必须引用具体的产物文件与字段作为证据。提示词禁止阅读完整转录（transcript.jsonl）以控制生成成本；交互日志已提供足够的行为摘要。

#### D.3.2 阶段 2：分类法归类

随后使用 GPT-4o（温度 0）把每张分析卡片归入一个两级失败分类法。分类提示词定义了以下层级：

• • 理解（Understanding）：agent 缺乏知识或编造信息。

• – _领域知识缺口_：agent 的错误可追溯到缺失的专业知识。提示词指示：「领域专家会避免这个错误吗？如果会，归入此类。」

• – _幻觉/编造_：agent 发明数据或结果，而不是计算它们。

• • 方法（Approach）：agent 理解领域但选错了计划。

• – _策略错误_：agent 违反明确的任务约束，或选择了不能归因于领域无知的根本性错误方法。

• – _不完整/放弃_：agent 提前停止或未能产出所需交付物。

• • 执行（Execution）：方法合理但实现有缺陷。

• – _实现缺陷_：逻辑错误、计算失误或数据处理 bug。

• – _输出格式错误_：输出的格式、位置或结构错误。

• • 基础设施（Infrastructure）：与 agent 能力无关的外部约束。

• – _GUI/浏览器故障_：GUI 或浏览器交互因工具问题失败。

• – _超时/资源_：agent 耗尽时间或计算资源。

#### D.3.3 分布

近一半（47%）的可归类失败源于方法错误：策略错误（30%）或过早放弃（17%）。理解失败占 31%，以领域知识缺口为主（25%），较小比例（6%）涉及幻觉或数据编造。其余 22% 是执行错误：输出格式不匹配（10%）、实现缺陷（8%）与 GUI 交互故障（4%）。超时与资源耗尽案例被排除在此分解之外，因为它们反映环境约束而非 agent 推理失败；其流行度在附录 D.2 中单独分析。

D.4 模型效应与 harness 效应

图 12：模型选择 vs. harness 选择。每个点是一个配置；竖直括线显示总体通过率的完整范围。在固定 harness（OpenClaw，12 个模型）下更换底座模型产生 16.8 个百分点的分布跨度，约为固定底座下更换 harness 所观测跨度（4.9–7.2 个百分点）的 3 倍。

表 1 引出的一个自然问题是：性能差异主要由基础模型的选择还是 agent harness 的选择驱动。图 12 把这两个因素分离。在固定的 OpenClaw harness 下，更换底座模型产生 16.8 个百分点的总体通过率跨度（从 Grok 4.3 的 4.3% 到 GPT-5.5 的 21.1%）。在固定底座下，更换 harness 产生的跨度小得多：底座为 GPT-5.5 时为 4.9 个百分点（五个 harness，19.1–24.0%），底座为 Claude Opus 4.7 时为 7.2 个百分点（三个 harness，13.2–20.4%）。

这一模式在两种底座选择下都一致：在本文评测的有竞争力的 harness 中，提示策略、工具路由与上下文管理上的工程差异只占总体性能变化的一小部分。主导因素是基础模型的推理与领域知识，这与第 4.2 节的失败分析一致——理解与方法错误（都根植于模型能力）构成失败的多数。

D.5 成本、时间与 token 效率

图 13：主流 agent harness 的性能 vs. 资源消耗。每个气泡代表表 1 中的一个 harness–底座配置；气泡面积与 token 总消耗成正比。(a) 总体平均分 vs. API 总成本（有成本数据的配置）。(b) 总体平均分 vs. 总墙钟时间（全部 16 个配置）。理想工作点是每个子图的左上角（高分、低资源使用）。

图 13 可视化了表 1 中 16 个主流 harness–底座配置的性能与资源消耗之间的关系。三点观察浮现。

成本与性能只有微弱相关。 在子图 (a) 中，搭载 GPT-5.5 的 ALE-Claw 以 $326 的 API 总成本取得最高总体平均分（45.8%），而同一 harness 搭配 Opus 4.7 花费 3.6 倍（$1 164），得分却低 5.3 个百分点（40.5%）。搭载 Composer 2.5 的 Cursor 是最节俭的配置，以 $87 达到 38.5%；而搭载 Fable 5 的 Claude Code 花费 $2 402——所有配置中最高——得分仅为相当的 40.5%。这一分布表明更高的花费并不可靠地转化为更好的结果；底座模型与任务分布的契合度以及 harness 的 token 效率共同决定成本-性能权衡。

时间效率差异巨大。 子图 (b) 揭示墙钟时间与得分在很大程度上解耦。ALE-Claw（GPT-5.5）以约 51 小时的总墙钟时间取得最高分，而 Claude Code（Opus 4.8）需要 466 小时，得分却更低（37.2%）。Droid（Opus 4.6）是最快的配置（24 小时），但只得 25.7%。这一差异反映了各 harness 在逐任务超时行为、重试策略与动作循环并行度上的不同。

token 消耗不能预测性能。 两个子图中的气泡大小显示，token 密集的配置未必得分更高。ALE-Claw（Opus 4.7）消耗 1 373M token，得分却略低于消耗 460M token 的 Cursor（Opus 4.7）（40.5% vs. 41.8%）。反过来，Cursor（GPT-5.5）只用 160M token 就达到 39.6%，表明简洁的工具使用与高效的上下文管理可以弥补原始 token 量的不足。

D.6 逐任务实例得分热力图

图 14–16 展示每个被评测 agent 系统下每个任务实例的平均分。行按跨所有系统的平均分降序排列；列按 harness 分组，并在每组内按平均分降序排列。任务实例标签按分类法领域着色（图例内嵌）。灰色单元格表示缺失的运行。

图 14：逐任务实例得分：近期层（67 个任务实例）。

图 15：逐任务实例得分：全谱层（55 个任务实例）。

图 16：逐任务实例得分：末考层（38 个任务实例）。