ALE 专家质检流程

ALE（Agents’ Last Exam）是一项面向 Agent 的基准测试，旨在评估其在真实电脑沙箱中完成长程专业任务的能力，并通过程序化验证器（verifier）对最终交付物进行验收。公开任务覆盖工程、物理科学、生命科学、医疗健康、计算与数学、商业金融、法律、教育、农业环境、交通安全、社会科学、心理与神经科学、视觉媒体等 13 个专业领域。本项目需在修复ALE-bench已有题目的基础上生产一批高质量agent数据。该项目计划分两阶段进行，第一阶段质检并修复ALE-bench的150道题目；第二阶段生产一批（1000条）高质量的agent数据。

ALE-bench质检修复pipeline

流程图

专家准入

专家筛选

选择与原数据生产专家同专业背景、熟悉相应工作流和软件的专家，承担人工质检与数据修补。记录以下人数，并按专家去重：

• 可触达：联系方式有效，专业背景符合需求。
• 已签约：已完成参与项目所需的签约手续。
• 已培训：已完成本项目培训。
• 试标合格：试做质检通过，可以承接对应领域的质检任务。
• 当周活跃：本周确认可投入时间，并实际参与质检、修补或复查。
• 有效交付：本周至少交付一份已确认的质检结果或修补后通过复查的数据。无须修补的合格任务，其质检结果同样计入。

前三项及试标合格人数记录当前累计状态，当周活跃和有效交付按周统计。有效交付人数按质检与修补工作的实际交付记录，不与最终工程入库人数混用。

签约并确认可投入时间

确认每周可投入小时、固定在线时段、请假规则，以及至少连续参与多长时间。质检、修补与复查分别考虑所需时间，避免只安排初次检查而没有时间处理后续问题。

培训

培训内容包括项目背景、ALE 任务结构、优秀与失败样例、数据合规、提交工具和质检标准。通过样例讲清楚如何判断任务能否完成、参考结果是否有依据、rubrics 是否可执行，以及如何记录问题位置和修改要求。

试做质检与反馈

沿用已确认的准入安排：先检查一道标准题并获得逐项反馈，再完成第二题或复试。通过后，可承接该领域的质检任务。这里考查的是能否识别问题、提供依据并判断修补结果，不要求重新生产一整道任务。

本阶段交付可派单专家名单，记录每位专家可承接的领域和本周可投入时间。

专家质检修补

接收待检数据

以待检任务的现有版本为依据，核对任务说明、输入、软件环境、reference、rubrics，以及已有的任务代码与评分程序。每份报告注明任务 ID 和所检查的版本，避免报告与数据不对应。

自动化质检

由混元 AI Data 工程同学实现和维护，检查文件完整性、格式、可打开性、重复度和敏感信息。

报告列出检查结果、对应文件或字段、发现的问题及可复查的证据。缺少文件或文件损坏导致后续检查无法进行时，先补齐再继续。重复度或敏感信息扫描命中由人工确认，不能只凭自动报告直接判定任务不合格。

自动化检查负责发现文件和材料问题，不能替代领域专家对专业内容的判断。官网 FAQ 同样说明自动化 Agent 审查属于参考信号，不是必须通过的独立条件。官网 FAQ

人工 peer review

由与原数据生产专家同背景的另一位专家进行人工质检，检查以下内容：

• 专业正确性：任务背景、专业概念、计算方法、参数、单位及结果是否正确。
• 任务能否完成：题面、输入和软件是否提供足够信息，是否依赖未给出的材料或无法访问的系统。
• 证据是否充分：结论能否对应到文件、数据、操作记录或运行日志。
• 评分点是否合理：每项要求能否明确判断，单位、容差、通过与失败条件是否清楚。
• reference 质量：参考结果是否来自真实运行，是否正确、完整，并与当前输入和题目版本对应。

对于多种正确解法，不因产物与 reference 外观或字节不同就判错，应检查是否满足题目规定的验收条件。无法判断时记录缺少的依据，由领域专家补齐后再复查。

ALE 论文的最终 QC 重点包括参考输出正确性、评分范围合理性和上下文充分性。本项目将这些检查用于现有数据的人工质检，并在工程验收时核对修补后的实现。论文附录 B.2

记录问题与修补要求

问题清单写明任务版本、具体位置、问题描述、判断依据、对任务的影响、需要修改的内容、修改人和复查结果。例如，不能只写“reference 有问题”，应说明是哪个文件、哪一项指标与哪份输入不一致。

未发现问题的任务直接交工程验收。发现问题的任务由领域专家修补；报告无法确认的内容不得按已通过处理。

领域专家修补数据

领域专家按问题清单修改相应 bench 数据：补齐题面信息、修正输入或参数、替换损坏文件、重新生成错误的 reference、完善 rubrics 或补充真实运行证据。

涉及 rubrics 时，Agent 辅助生产专家或负责修补的领域专家撰写，专家确认专业含义、允许误差及通过和失败样例。reference 的修补必须有实际运行或原始依据支持，不能为了通过评分而直接编造结果。

代码、运行环境或自动质检程序的问题交给对应工程人员处理。领域专家负责说明正确行为和验收依据，不要求其承担代码实现。

修补后复查

修补后重新执行相关自动检查，并由人工检查修改处及受影响部分。若改动题面、输入、reference 或评分条件，复查它们是否仍相互一致；仅看修改的文字不足以判断整题是否修好。

修改人不独自确认自己修补的数据通过，应由另一位同背景专家复查。问题仍存在则继续修改；材料缺失或真实性无法确认、暂时不能修好的任务，记录原因并暂缓验收。

本阶段交付修补后的数据版本、自动质检报告、人工质检结论、修改前后差异及复查记录。

工程验收

同步材料与工程文件

工程人员核对修补后的材料是否与 task_card.json、main.py、数据文件和评分程序一致。已有工程文件只更新受到修补影响的部分；尚未完成工程实现的任务先补齐可运行结构。

检查运行环境与评分

确认软件版本、依赖及输入文件可用；使用通过样例、失败样例及评分临界值检查评分程序，确认正确结果可以通过、明确错误结果不会误过。

任务运行期间隐藏参考答案，仅在评分时由评分程序读取。完整试运行覆盖输入部署、实际操作、产物生成、评分及日志收集。Agent 没有提交输出与环境故障分别记录，不能把环境错误当成任务低分。

官方任务文档要求 load()、start()、evaluate() 完成任务声明、准备和评分，并将 reference 与执行中的 Agent 隔离。官方新增任务文档

Data 验收

Data 侧核对专家质检与复查结论、修复记录和交付材料，确认问题已有对应处理结果、材料齐全且版本一致，核对工程测试记录，确认相应修改已落实到可运行任务和评分程序；同时核对模型与运行框架、工具权限、运行预算和评分程序版本等评测配置，确认分数与产物、日志相符，并判断修复对已有评测结果的影响。

Data 侧记录验收结论。发现材料或专业问题返回领域专家修补；发现代码或环境问题由工程修复；发现评测配置或结果问题由 Data 侧核查并组织重新评测。处理后重新检查受影响部分。

Data 侧确认通过后，保存修补后的数据、代码、环境配置、评测配置及验收记录，更新入库版本及验收 manifest。保留修改前后对应关系，便于解释历史评测结果。

如果修改涉及评分规则或会改变评测结果，旧分数不能直接当作新版本成绩；相应结果需要基于修补后的版本重新计算或运行。

质检和修补内容对应哪些 ALE 文件

任务说明

检查任务目标、约束和交付要求。修补对应公开卡片中的 taskPrompt、agentMustDo，以及 main.py 中实际交给 Agent 的任务 description，避免只改卡片而运行题面仍旧。

输入材料

检查文件是否完整、可读、与题面一致。修补对应 inputFiles[]、实际 input/ 文件，以及 start() 使用的路径和部署逻辑。

软件环境

检查精确版本、依赖和运行条件。修补对应 software、相关 vm 配置、环境文件及初始化逻辑。卡片列出软件名称不等于软件已经可以运行。

reference

检查真实来源、正确性和与输入的对应关系。修补对应参考资产、referenceFiles[] 描述和评分程序读取的参考路径；卡片中的路径不能直接当作 Agent 可访问的答案路径。

rubrics

检查判定条件、单位、容差及通过和失败样例。修补对应卡片 evaluation 摘要，以及 evaluate() 和相关评分脚本。没有统一必填的 rubrics 顶层字段，不能只更新自然语言说明而不核对实际评分逻辑。

质检与修补记录

任务版本、问题清单、修补差异、自动报告、人工复查结论和验收 manifest 用于本项目交付追溯，不将这些管理记录当作 ALE 统一要求的卡片字段。

ALE 数据生产 pipeline

流程图

专家准入

谁参与：专家运营（AI data）与各领域专家。

专家筛选与人数记录

筛选具备真实专业经历、熟悉相关软件和工作流的专家，分别记录以下人数，并按专家去重。

• 可触达：联系方式有效，专业背景符合需求。
• 已签约：已完成项目签约与材料使用约定。
• 已培训：已完成项目培训。
• 试标合格：标准题及反馈后的第二题或复试通过，可承接对应领域的任务。
• 当周活跃：本周确认可投入时间，并实际参与生产、提交或返修。
• 有效交付：本周至少有一道任务通过内容验收。

前四项记录当前累计状态，后两项按周统计。有效交付人数与最终工程入库数量分开记录，避免把工程排队误算为专家未交付。

签约并确认时间

确认每周可投入小时、固定在线时段、请假规则和最小连续参与周期。安排任务时同时考虑生产与返修时间，人工质检也需有对应专家和时间安排。

培训

培训覆盖项目背景、ALE 任务结构、优秀与失败样例、数据合规、提交工具和质检标准。重点说明任务信息如何写完整、reference 如何提供真实依据、评分点如何明确判断。

试标与反馈

先完成一道标准题，收到逐项反馈后再完成第二题或复试。通过后，可承接该领域的任务，并确认本周可投入时间。

交给生产环节：可派单专家名单、可承接领域、可投入时间、培训与试标记录。

任务生产与质检

ALE简述

ALE（Agents’ Last Exam）是一个让 Agent 在真实电脑沙箱中完成长程专业工作，并通过程序 verifier 验收最终交付物的基准测试。公开任务覆盖工程、物理科学、生命科学、医疗健康、计算与数学、商业金融、法律、教育、农业环境、交通安全、社会科学、心理与神经科学、视觉媒体等 13 个行业领域及 other 类目。

ALE的任务拆解

可以把 ALE 理解成一套“任务包 + 电脑环境 + Agent + 验收程序”组成的职业能力考试。下面以 business_finance/ar_full_300 为例说明 benchmark 中的 Task 结构。

1. 每个任务都有独立的 taskId

这道题的标识是：

business_finance/ar_full_300

它由两部分组成：

business_finance / ar_full_300
领域目录        任务名称

• business_finance：商业与金融领域
• ar_full_300：300 份年度报告完整抽取任务

taskId 同时对应官方仓库路径为 ar_full_300。

2. task_card 是任务说明

每道任务都有一个 task_card.json，用于描述任务的信息。这道题的部分 task card 信息：

{
  "taskId": "business_finance/ar_full_300",
  "title": "Annual Report Full Extraction (300 files)",
  "category": "business_finance",
  "software": ["Google Chrome", "Python"]
}

主要字段包括：

• taskId：唯一任务标识
• title：任务标题
• summary：任务摘要
• taskPrompt：Agent 真正收到的详细指令
• agentMustDo：必须完成的关键步骤
• inputFiles：Agent 可见的输入文件
• software：可使用的软件
• evaluation：公开的评分规则说明
• vm：沙箱机器配置
• taxonomy：所属行业和专业子领域
• requiredSystemPackages：环境必须预装的软件包

通过 task card，我们可以了解到这道题的基本信息。

其中需要特别说明，taskId 表示的是任务的唯一标识，variant 表示它的具体实例。在官方文档 published_task.json 中，会存在 variant，比如这道题的 variant 是 “base”。其他任务可能有多个实例。例如 engineering/mold-flow 可以有多个不同模具项目，但官方只选择其中部分 variant 对外发布。因此 ALE 中需要注意，任务定义不等于具体的任务实例。

3. Agent 操作 OS 沙箱

在这道题的 task card vm 字段中，snapshot 字段为 cpu-free，代表这道题运行在 Windows 沙箱中。

当前 ALE 的 vm.snapshot 共有 5 种逻辑值：

• cpu-free-ubuntu
• cpu-free
• cpu-license
• gpu-free
• gpu-license

可以按三个维度理解：

• 是否需要 GPU
• 是否需要授权软件镜像
• Linux 或 Windows

另外，该环境还提供：Windows 文件系统、Google Chrome、Python、任务输入目录、可写的输出目录。

相比于其他的评测，ALE 相当于让 Agent 获得一台电脑，并在限定时间内完成任务。这道题的超时时间是 7200 秒，超时时间其实隐含了部分执行任务的轨迹限制，比如该题需要下载 300 份年报并进行处理，如果使用纯 GUI 操作浏览器极有可能超时。

4. Agent 收到的是一个具体任务

这道题要求 Agent：

1. 读取 300 份年报名单；
2. 从东方财富下载对应 PDF；
3. 保留正确的原始文件名；
4. 解析年报；
5. 提取核心技术人员信息；
6. 合并不同年度的薪酬和持股数据；
7. 生成一个结构严格的 Excel。

ALE 不规定 Agent 必须使用哪一种方法。它可以：

• 操作 Chrome 或使用 playwright，甚至 request、selenium、urllib3 等等
• 编写 Python 或其他编程语言
• 运行 Shell 或 PowerShell
• 使用 PDF 解析库或纯 GUI 查找

Benchmark 主要检查最终结果，而不是强制一条固定操作路线。

5. 输入的目录只读，输出目录只写

ALE 通常把任务文件组织成：

base/
├── input/      Agent 可见、只读输入
├── software/   任务提供的软件入口
├── output/     Agent 必须写入的交付目录
└── reference/  隐藏的打分参考，仅评分阶段使用，执行 sandbox 中不一定存在

这道题必须生成两类交付物：

base\output\downloads\          # 300 份正确年报
base\output\final_dataset.xlsx  # 提取并合并后的人员数据

6. main.py 是可执行的任务定义

除了 task card，每道正式任务通常还有一个 main.py。它定义三个关键阶段：

load()

把任务注册到 ALE runner：加载任务提示、设置 variant、声明电脑环境、建立任务 metadata。

start()

在 Agent 开始前布置沙箱：创建目录、注入可见输入、准备软件入口、确定输出位置、保持 reference 隐藏。

evaluate()

Agent 结束后运行评分程序：检查 300 份 PDF、读取最终 Excel、加载隐藏 reference、计算最终 [0,1] 分数。

7. Reference 验收依据

这道题的 task card 的 referenceFiles 中没有公开列出文件，但评分阶段实际使用两个隐藏文件：

reference/file_manifest.json
记录正确 PDF 的：
- 文件名
- 文件大小
- MD5

reference/data_samples.json
保存用于抽查的正确数据：
- 人员识别码
- 列名
- 正确值
- 匹配方式

这些 reference 在 Agent 工作期间不可见。

8. 使用 verifier 检查最终结果

这道题使用一个共享的评分器：tasks/business_finance/_shared/finance/finance_evaluation.py

评分分为 2 部分：

文件完整性：50 分

每份 PDF 依次检查：

文件存在 → 大小误差不超过 5% → MD5 完全一致

每错一份扣 5 分。

数据准确性：50 分

对比标准答案 final_dataset.xlsx：

1. 使用识别码查找对应人员；
2. 读取指定字段；
3. 与隐藏正确值比较。

数值允许的误差是 <0.01。

9. 一道题的完整运行流程

选择 Agent
↓
创建 Windows VM
↓
加载 business_finance/ar_full_300
↓
注入 file_list.txt 和软件
↓
向 Agent 发送 taskPrompt
↓
Agent 使用 Chrome、Python 和文件系统工作
↓
Agent 写入 downloads/ 和 final_dataset.xlsx
↓
Agent 结束
↓
挂载隐藏 reference
↓
运行文件和数据 verifier
↓
得到 0～1 分数
↓
保存轨迹、日志、成本、时间和交付物

10. 同分布题目构造

ar_full_300 在已经公布的 157 题中还有一题 Plus 版本 ar_full_1500。使用同一个共享评分模块，包括美股的 sec_10k_financial_parsing 及 ff5_public_reconstruction。从公开数据源（特别是 PDF 及复杂类型文件）中批量获取数据再进行重新组织是 ALE 考察的一个方向，基于此可以设计大量同分布任务。

ALE的专家标注

基于 ALE 的任务拆解，专家需要提供的数据：

• 真实工作：不是为了测试软件而设计操作，而是有明确的业务结合目标。
• 有连续逻辑链条：至少包含“获取/准备材料 → 处理数据/操作软件/等操作 → 输出/验证结果”。
• 有明确的交付品：例如报告、office 文件、模型文件、流程文件、系统 log、配置结果等。
• 结果能被检查：可以根据交付品或系统状态判断任务是否完成。
• 不依赖专家额外信息：题目本身应说明背景、输入来源、处理目标和完成标准，而不是多轮交互后补充。
• 强绑定一个专业软件：在真实业务场景转换题目的过程中绑定一个专业软件，如果不使用软件，大概率无法完成该任务。

1. 任务概要

• 题目的场景和目标
• 题目为什么有经济价值
• 行业类目
• 题目难度自评

2. 涉及的专业软件

• 描述需涉及的专业软件，说明为什么真实专业人士做这个任务需要这些工具；
• 涉及到的辅助软件

3. 任务 prompt

• 任务背景：说明这个任务发生在什么业务/专业场景中，完成后会产生什么实际作用。
• 你的任务：用自然语言说明接到任务的具体要完成说明。
• 可见输入：列出完成任务时可以看到的文件、数据、网页来源、系统上下文或业务规则等等。
• 需要使用的软件/工具
• 交付要求：说明最终必须交付哪些文件、系统状态、报告、模型、配置结果或结构化数据。
• 关键约束：说明必须保留什么、不能修改什么、必须遵循哪些规则、单位/口径/时间范围是什么。
• 完成标准：说明什么情况下可以认为任务完成。

4. 输入数据包

本任务需要的全部起始材料。每个提交的任务必须提供完成任务所需的初始资料，包括文件、数据、网页来源、业务背景或系统上下文。资料数量无硬性规定，但必须满足：该任务领域对应的专业人士在不额外询问其他内容的情况下能够依据此展开工作；且这些资料足以支持最终结果被复现和验证。初始资料包可以是一份文件，也可以是多份文件、数据表、图片、视频、配置文件、项目目录等。

数据包清单需写明：文件/文件夹名称、文件格式、文件作用、关键字段或内容说明、数据来源、是否可公开/是否脱敏、是否必须使用。

5. Reference

任务成果：自己完成这个长程任务，所交付的结果（交付物能够被还原为字节、字段、几何、系统状态或可执行行为等）。

确定性答案：专家从交付品中抽取出的、唯一稳定、可复现、可机器对比的确定性答案值（无需说明怎么评分、权重多少、失败边界等，只需要说明：正确的可复现答案是多少）。确定性答案需要满足：做对任务后不会产生变化；能在交付物中被定位；有明确正确值；不依赖主观评价；不会只是专家个人臆断。建议包含以下内容：

• 交付物答案清单：用于说明最终应该有哪些交付物，以及哪几个文件名/格式最适宜答案。
• 固定字段答案：这是最核心的确定性答案，用于写“某个文件、某个字段，正确值是多少”。
• 固定集合答案：用于写“必须包含哪些稳定项”，但不涉及权重和评分。例如 BPMN、Excel sheet、数据库表、报告章节、图层、骨骼名称、CSV 枚举值等。
• 固定数值答案：用于财务、数据分析、科学计算、日志统计等任务，专家把稳定数值写出来。
• 允许变体答案：有些任务做对后可能存在多个等价答案。专家需要明确哪些是允许变体，避免工程化的过拟合单一专家成品。

6. 关键动作

完成任务中需要完成哪些关键动作，请整理为一个 Markdown 或 TXT 文档。

• 完成这个任务的整体规划是什么
• 本任务高难度的环节有哪些，完成思路是什么，应该怎样来操作
• 必须完成哪些中间处理
• 哪些动作缺失会导致任务失败

7. 评分表

判断完成这项任务需要对任务成果设计的所有检查项（评分表的检查项可复用关键标准答案的内容），需写明：检查项本身的内容（标准答案、关键字段、容差、失败边界和可观察证据）；每项检查项本身的客观硬性标准是什么。

必须绑定可观察证据。rubric 不能是“整体感觉”。它要求 rubric 绑定 observable artifacts。

比如不是问：“这个动画好不好？”而是拆成：

• 是否匹配参考身体动作
• final.blend 渲染结果是否和提交 preview 一致
• 骨骼姿态是否明显断裂
• 是否包含指定骨骼命名

其他要求：

• 每项检查项的阈值是什么（超过某个边界，本项就被判失败）
• 每项检查项需结构化，固定需检查的字段或值，不要只说明“需注明来源/需参考 xxx”这样无法稳定客观评分的内容
• 评分表需要完整，需覆盖任务的所有要求
• 每个检查项在这个任务中的优先级（重要性），需分为以下：

1 关键项：核心交付物缺失、计算表不可读、主要输入没被用、关键结果缺失等。
2 高权重项：有效空间、图谱流型、池型、尺寸等。
3 普通项：过程说明、来源标注、格式规范等。
4 辅助项：文案完整性、表格美观度等。

8. 本项任务的环境依赖

OS（操作系统）、所需的软件、代码执行依赖、是否需要 GPU、是否需要付费软件（license）。

专家ALE的任务要求

任务是否真实、是否有足够上下文、能否被工程师复现、专家提供的 ground truth 是否正确、Rubric 质量、是否存在版权/隐私/合规风险。

1. 客观性

所有任务必须能被客观评价“做没做对”，而不是“做没做好”。

必须是所有检查项都具备单独客观可判的任务（通过和不通过都能被写死，例如“这个数据等于 1200（不是 1200 就不对）”属于客观可判；“这个数据需要符合 xxx 的定义”不属于客观可判）。如果存在必要检查项无法被客观判断，那么这个任务就不能被提供。

所有的任务都需要提供完整的任务所需上下文，不能存在信息的遗漏。

2. 高难度

任务完成需要专业知识（专业资深从业者才具备的），尤其鼓励在涉及本行业/领域的一些计算口径、指标、阈值等数值方面的专业知识；

任务需要真实软件或工具链（在软件操作和工具操作上需要具备操作难度，不能只是基础操作，需要和本专业本身联系上）；需要多步长期规划（任务必须是 workflow 工作流，不是独立 action）；

不应只是一两个按钮操作；不应只靠语言问答完成；经常需要跨工具、跨文件、跨步骤；涉及需要较长时间才能完成的任务，工程量大、耗时较长；鼓励任务要求涉及对产出格式进行强约束，并在检查项中对其进行严格检查（尤其是在一些字段、参数等比较细节的点上，对交付格式进行强约束）。

专家设计任务时，可以从下面这些“人类工作动作”里选择组合，不要求每道题全部覆盖，但一条任务最好至少包含 2 类以上动作：

3. 真实性

这个任务是一个真实专业人士真正会做的完整工作流。

例如：（CAD）不是“新建一个圆”，而是“根据二维图纸完成三维建模”。

任务应该对标真实经济活动（人们愿意付费来获取任务成果）。

任务所依赖的专业软件是完成任务本身自然需要的工具，并不是强行指定必须使用某种软件，或者软件仅发挥不影响任务核心的作用；而是在真实工作场景中，该软件也是最贴合此类任务工作流需求的专业工具，绕开它会偏离任务设计。