#ALE Agents' Last Exam：从“会答题”到“会工作”的 Agent Benchmark

核心结论：ALE（Agents' Last Exam）不是又一个“更难的问答考试”，而是一个试图衡量 Agent 是否能完成真实职业工作流、产出可验证交付物的 benchmark。 它真正想回答的问题是：当模型从“会答题、会写代码、会点网页”走向“能不能干活”时，我们该怎么评测？

论文：Yiyou Sun et al., Agents' Last Exam, arXiv:2606.05405v2, 2026。

官网：<https://agents-last-exam.org/>。

#1. 为什么需要 ALE？Benchmark 成绩和真实生产力之间有断层

过去几年，AI 系统在很多 benchmark 上快速进步：知识问答、数学竞赛、代码竞赛、网页操作、终端任务、GitHub issue 修复等都不断刷新成绩。但一个尴尬的问题是：benchmark 胜利并没有等比例转化为真实行业里的经济生产力。

这不是说现有 benchmark 没价值，而是它们往往只覆盖了真实工作的一个切面：

ALE 的判断是：如果我们希望 Agent 真的进入法律、金融、制造、设计、医疗、科研、工程等行业，就不能只测“会不会回答这个行业的问题”，而要测：

• 能不能理解一个真实工作任务？
• 能不能在专业软件和文件系统里长期操作？
• 能不能产出可交付的文件、模型、报告、设计、仿真结果？
• 能不能通过隐藏 reference 和自动 evaluator 的检查？

换句话说，ALE 想把评测目标从 answer correctness 推向 work completion。

#2. “Last Exam” 这个名字是什么意思？

“Last Exam” 有两层含义。

第一层是 competence threshold：如果一个 Agent 能通过某个行业的 ALE 任务，它展示的不是“知道这个行业的知识”，而是能持续完成这个行业里有经济价值的工作。

第二层是 difficulty frontier：ALE 的最难档不是为了马上被刷满，而是为了保留长期 headroom。论文结果显示，当前主流 Agent 在最难档 Last-Exam 上几乎全军覆没，很多配置 full-pass rate 是 0%。

所以 ALE 更像是一个里程碑 benchmark：它不是日常快速刷榜的小测验，而是问“Agent 离真正职业级工作能力还有多远”。

#3. 数据规模与行业覆盖

论文报告的当前规模是：

• 960 个 expert-authored task workflows；
• 1,490 个 task instances；
• 13 个 top-level industry clusters；
• 55 个 subdomains；
• 250+ 行业专家参与；
• 约 150 个公开 instances，其余放入 private pool，用于防污染和滚动评测。

ALE 的领域划分不是随便拍脑袋选几个热门行业，而是参考美国职业分类体系：

• SOC 2018；
• O*NET。

它把数字化、非物理的职业工作流聚类成 13 大类和 55 个子域，覆盖工程建筑、计算与数学科学、视觉媒体艺术、商业金融、医疗健康、生命科学、物理科学、法律、心理与神经科学、农业环境、交通安全、教育信息等方向。

任务例子也非常“职业化”：

• 3D CAD modeling；
• CNC toolpath generation；
• molecular docking；
• RF circuit matching；
• chip signoff routing；
• clinical diagnostics / imaging；
• financial workbook / accounting；
• game reproduction；
• weather forecasting；
• motion retargeting；
• single-cell clustering；
• hardware verification；
• legal discovery / doctrinal legal research。

这和 OSWorld、WebArena、SWE-bench 的最大不同是：ALE 不以某类界面或某类代码仓库为中心，而以真实职业交付物为中心。

#4. 什么任务能进入 ALE？三个准入标准

ALE 对任务有三个高层要求。

#4.1 Representativeness：代表真实职业实践

任务必须来自真实专业工作，而不是为了 benchmark 临时编出来的玩具问题。

例如，建筑专家如果真实工作中通常用 SolidWorks 或 Rhino 从 2D blueprint 转 3D model，那么任务就应该围绕这些真实工具，而不是用一个更容易自动化但不符合行业实践的软件替代。

这意味着 ALE 不希望牺牲真实性来换取评测便利。

#4.2 Complexity：必须是 workflow，而不是单步 action

ALE 区分 workflow 和 action。

一个太窄的任务，比如“在 DaVinci 里加一个 color filter”，只是在测单步操作；而“把一只奔跑的猎豹移动到另一个赛跑视频里”则需要 tracking、rotoscoping、compositing、color matching 等多个耦合步骤，更接近真实工作。

所以 ALE 要测的是 Agent 能否完成一串有依赖关系的长时程流程，而不是能不能执行一个局部动作。

#4.3 Verifiability：必须能验证

这是 ALE 最关键的工程约束。任务输出必须能通过确定性检查，或者至少通过绑定可观察证据的 rubric 评分。

例如，“设计一个有怪物的 RPG 游戏”太主观，不适合；但“用 RPGMaker XP 复现 mota.exe”可以比较地图几何、角色属性、事件状态，以及固定操作轨迹下的世界状态，因此更适合。

ALE 的难点就在这里：既要真实，又要可自动评分。

#5. 任务构建流程：专家真实项目如何变成 benchmark？

ALE 明确说任务不能简单众包给普通工人，因为它需要专业领域知识。构建流程大致是：

1. Expert outreach：招募行业专家和 advisory committee；
2. Expert task submission：专家通过提交入口上传真实做过的项目；
3. Auto-review with agent：辅助检查任务描述、输入、输出、评测规范是否完整；
4. Task implementation：工程团队把任务转成可运行环境、assets、reference、evaluation logic；
5. QC committee review：专家委员会做最终质量控制，检查 reference 正确性、评分边界是否过窄或过宽、上下文是否充分。

一个任务提交需要五个核心组件：

• 自然语言任务描述；
• 输入文件；
• 目标软件；
• 期望交付物；
• 评测规范。

这说明 ALE 的核心工程量不只是“收集题目”，而是把真实职业项目改造成可重复执行、可自动评分的 benchmark instance。

#6. 执行环境：每个任务都是一个 VM 中的可运行实例

ALE 的任务实例由三个解耦组件构成：

1. Task Spec：一个 main.py；
2. Agent：harness + LLM；
3. Environment：虚拟机。

main.py 暴露三个生命周期函数：

• load()：声明任务描述、metadata、计算需求；
• start()：把 VM 初始化到确定状态；
• evaluate()：读取 Agent 输出，对照 reference 或 rubric，返回 0 到 1 分。

VM 目录结构也很重要：

• input/：只读输入资产，Agent 可见；
• software/：预安装专业软件；
• output/：Agent 唯一写入目标；
• reference/：隐藏 ground truth，只给 evaluator 使用。

Agent 只能看到任务描述和 metadata，通过截图、shell、鼠标键盘、文件编辑、API 调用等进行操作，最终把产物写入 output/。

这相当于把真实职业任务封装成一个可复现实验环境。

#7. 评测对象：GCUA，而不只是 CLI Agent 或 GUI Agent

ALE 提出一个关键概念：Generalist Computer-Use Agent，GCUA。

作者认为现有 Agent 常常偏科：

• CLI agents：会 shell、代码、文件、工具调用，但没有 GUI perception；
• GUI agents：会看屏幕、点鼠标、键盘操作，但 orchestration、文件系统、代码执行、长期流程能力弱。

真实职业 workflow 往往两者都要：既要操作 GUI 专业软件，也要写脚本、处理文件、查资料、跑命令、调代码。

ALE 把 Agent 能力拆成五层：

• Brain：LLM reasoning / planning；
• Eyes：GUI perception via screenshots；
• Body：orchestration and control flow；
• Hands：structured tool invocation；
• Feet：runtime substrate，比如 VM、Docker、shell。

GCUA 要五层都强。Claude Code、Codex、OpenClaw 加 GUI harness 这类系统才比较接近 ALE 要测的对象。

#8. GUI-as-Tool 与 GUI-as-SubAgent

为了让 CLI-native agents 能做 ALE，作者用了两种 GUI 扩展方式。

#8.1 GUI-as-Tool

把桌面动作暴露为普通工具，让主模型在同一个 action loop 里决定是否截图、点击、输入、拖拽等。

这是论文的主评测方式，因为它测试的是模型能否统一处理 shell 输出和视觉反馈。

#8.2 GUI-as-SubAgent

把 GUI 操作委托给一个专门的视觉语言 sub-agent。

作者主要把它用于没有原生视觉输入的模型，例如 DeepSeek V4。

这个设计说明 ALE 不只测 base model，也测 harness。但论文后续分析发现：在比较成熟的 harness 之间，模型选择造成的性能差距大约是 harness 选择的 3 倍。

#9. 评分方式：如何避免“LLM judge 泛滥”？

ALE 的输出非常异构：CAM toolpaths、financial workbooks、3D meshes、game world states、rendered screenshots、structured filings、free-text reports 等都可能出现。

它没有强行统一成一个 metric，而是使用多种 artifact mode：

• exact / hashed values；
• structured numeric / tabular fields with tolerance；
• geometric surface / point-cloud distance；
• visual appearance checks；
• behavioral world state under fixed trajectory；
• free-text rubric scoring。

组合方式主要有两类。

#9.1 Gate-and-score

先过一个 binary gate，再算连续分数。

例如文件能不能 parse、toolpath 有没有 collision、输出格式是否正确。如果 gate 失败，即便其他部分有一点接近，也直接 0 分。

这很像真实工作：CAD 文件打不开、代码跑不起来、表格格式错了，后面的“看起来努力了”没有意义。

#9.2 Checklist / per-file score averaging

多个二元检查或多个文件分数求平均，得到细粒度 partial score。

#9.3 LLM judge 只做窄 probe

ALE 明确说：能不用 LLM judge 就不用。

如果一个任务只能靠“问模型结果看起来对不对”，QC 会拒绝或重构任务，让它暴露可检查 artifact。

少数必须用视觉/文本判断的任务，也不是让 LLM 做整体主观评分，而是用 narrow, evidence-anchored yes/no probes。

例如游戏复现任务不是问“这个游戏复现得好吗？”，而是问：

• 第一张图是否显示 RPGMakerXP；
• 地图布局是否和原始游戏一致；
• 玩家状态是否一致。

然后用代码聚合这些 yes/no 结果。

这比一般 holistic LLM-as-judge 更可靠，但仍不是完美方案，因为视觉 probe 本身仍可能受 judge 模型误差影响。

#10. 三个难度层级

ALE 的公开评测成本很高：单个任务跑 frontier agent 平均约 3 到 10 美元，耗时几十分钟到数小时。因此它分成三档。

#10.1 Near-Term

• 67 tasks；
• 当前 frontier agents 能部分完成；
• top pass rate 接近 40%；
• 适合短期 leaderboard 和快速迭代。

#10.2 Full-Spectrum

• 55 tasks；
• 每个子域至少一个任务；
• 用于广覆盖综合评测。

#10.3 Last-Exam

• 38 tasks；
• 最难任务；
• 大多数 Agent full-pass 为 0%；
• 用于长期 milestone，而不是日常刷榜。

这个分层很合理：如果全是超难任务，研究者无法快速定位进展；如果全是 near-term，又很快饱和。

#11. 主要实验结果：当前 Agent 离“会工作”还很远

论文最重要的结论是：ALE 远未饱和。

#11.1 最强配置也过不了最难档

论文中较强的 mainstream 配置之一是 Codex + GPT-5.5：

• Near-Term pass：约 38.1%；
• Full-Spectrum pass：约 22.7%；
• Last-Exam pass：约 0.0%；
• Overall pass：约 24.0%。

另一强配置 ALE-Claw + GPT-5.5：

• Near-Term pass：约 32.8%；
• Full-Spectrum pass：约 23.6%；
• Last-Exam pass：约 2.6%；
• Overall pass：约 23.0%。

这说明即使是最强 Agent，在真实长时程职业任务上也非常不稳。

#11.2 ALE-CLI 明显难于 Terminal-Bench

论文特别比较了 ALE-CLI 和 Terminal-Bench。

Codex + GPT-5.5 在 Terminal-Bench 上可以达到 82%，但在 ALE-CLI 上只有：

• Overall pass：23.3%；
• Near-Term：37.2%；
• Full-Spectrum：19.0%；
• Last-Exam：0.0%。

这说明问题不是“会不会用终端”这么简单。真实 workflow 里的领域知识、任务理解、产物约束、长时程规划都更难。

#11.3 固定 harness 看模型：模型差异仍然很大

在固定 OpenClaw + GUI-as-Tool 的模型比较中，论文给出的 overall pass 大致是：

这些是论文设定下的模型名和版本，时间点是 2026 年，不应和现实产品版本简单对应。

#11.4 Harness 有影响，但模型影响更大

论文分析发现：

• 固定 GPT-5.5，换 harness，overall pass spread 约 4.9 个百分点；
• 固定 Claude Opus 4.7，换 harness，spread 约 7.2 个百分点；
• 固定 OpenClaw，换模型，spread 约 16.8 个百分点。

结论是：在比较成熟的 GCUA harness 里，foundation model 的能力差异仍然是主要因素。

但这不等于 harness 不重要。GUI 接入、context compaction、工具调度、sub-agent、长任务恢复等能力仍然会决定 Agent 是否能把模型能力转化为行动能力。

#12. 失败分析：Agent 主要不是“手笨”，而是“不会工作”

论文对 Claude Code + Opus 4.7 的失败任务做 root-cause taxonomy，结论很值得注意：

• Understanding + Approach failures 合计约占四分之三；
• dominant bottleneck 是 domain knowledge / task understanding / strategy；
• 不是纯 execution capability。

人话说，Agent 很多时候不是不会点鼠标、不会写文件，而是不知道这个行业任务到底该怎么做。

它会倾向于：

• 用 ad-hoc script 替代专业软件；
• 用通用代码思路硬解专业任务；
• 没理解交付物标准；
• 没有领域 workflow sense；
• 没有长期 plan 和中间验证。

论文还观察到：虽然约 34% 的 public task instances 把图形软件作为 primary tool，但大多数 Agent 的 GUI 使用比例偏低，常常试图通过 Bash/CLI 绕开 GUI。

这说明当前 coding agents 的训练分布和工具偏好，可能让它们天然倾向“脚本化一切”。但很多专业任务并不能这样解决。

#13. ALE 真正重要的地方

我觉得 ALE 的价值不只是“又出了一个更难榜单”，而是它把 Agent 评测推进到了一个更接近真实生产力的位置。

过去 Agent benchmark 常见问题是：

1. 任务太短，测不到长期状态管理；
2. 领域太窄，代码、网页、桌面 app 占据多数；
3. 验证太弱，要么 exact match 太玩具，要么 human/LLM judge 太主观；
4. 经济意义不清楚，榜单提升不等于能替代或增强真实工作；
5. 环境太人工，不是专家真实工作流。

ALE 的贡献就是把这些矛盾放在一起处理。它不完美，但方向很清晰：从“会交互”走向“会交付”。

尤其对 LLM Agent、code agent、self-evolving agent 研究来说，ALE 暴露了一个关键问题：

当前 Agent 的主要瓶颈不是“会不会调用工具”，而是“有没有形成职业级任务状态、领域 workflow、长期规划和可验证中间目标”。

这和 long-horizon agent trajectory、model-based RL、latent task state、context compression、self-evolving code agent 都直接相关。

#14. 对 Agent 研究的启发

#14.1 Agent 需要职业 workflow world model

ALE 任务不是孤立动作，而是 workflow。

一个强 Agent 需要知道：

• 这个领域通常怎么做；
• 哪些中间产物必须先生成；
• 哪些软件适合做哪一步；
• 什么输出才算交付物；
• 怎样自己验证是否接近 reference。

这比普通 tool use 难很多。它需要某种 workflow-level world model。

#14.2 需要 decision-sufficient context，而不是无限上下文

ALE 长任务会产生大量截图、shell 输出、文件、错误日志、中间产物。简单把上下文拉长不够，Agent 需要压缩成：

• 当前任务目标；
• 已完成 milestone；
• 当前 artifact 状态；
• 失败尝试；
• 约束和评分线索；
• 下一步最有价值动作。

这正好对应通用上下文压缩器和 latent task state 的研究问题。

#14.3 需要 process supervision，而不只是 final reward

ALE 的最终 evaluate() 可以给 0 到 1 分，但如果用来训练 Agent，final reward 太稀疏。

更可行的是构建：

• milestone-level evaluator；
• artifact validator；
• self-check scripts；
• domain-specific process reward；
• trajectory repair / critique data。

这对 agentic RL 很重要。

#14.4 需要 model-based RL / imagined workflow

真实 ALE run 很贵：单任务几美元到十美元，耗时几十分钟到几小时。

如果要基于 ALE 训练 Agent，不可能只靠在线试错。更可能需要：

• 从专家 workflow 中学 transition model；
• 模拟中间 artifact 状态；
• 学会预测某个动作是否让最终交付物更接近目标；
• 在 latent space 里做 rollout / planning；
• 用 evaluator 反推 task-state value。

这和 Dreamer for LLM Agent 或 model-based agent RL 非常接近。

#14.5 GUI 使用不足说明训练分布偏了

论文观察到 Agent 偏向 Bash/CLI 替代 GUI。这个现象可以引出很好的研究问题：

• Agent 为什么不愿意用 GUI？
• 是视觉 grounding 弱？
• 是 GUI action space credit assignment 难？
• 是训练数据里 shell/code 轨迹太多？
• 能否通过 workflow demonstrations 纠正工具选择偏差？
• 能否学习“什么时候必须用专业软件，什么时候可以脚本化”？

这其实是 tool policy / modality routing 问题。

#15. 局限与风险

ALE 很有价值，但也有明显限制。

#15.1 成本高，复现门槛高

每个任务需要 VM、软件、reference、evaluation scripts。很多专业软件可能有授权、系统依赖、GUI 稳定性问题。普通研究组很难完整复现私有池评测。

#15.2 自动验证仍可能被钻空子

只要是自动评分，就可能出现 benchmark hacking。Agent 可能学会满足 evaluator，而不是真正完成工作。ALE 用 private rolling pool 缓解，但不能完全解决。

#15.3 专家任务质量不均

不同领域专家提交的任务粒度、清晰度、reference 质量、评分边界可能差异很大。QC 能过滤一部分，但大规模专家任务天然有异质性。

#15.4 领域覆盖广不等于分布均衡

虽然 55 子域都有覆盖，但任务数量分布明显不均。Full-Spectrum 每子域至少一题，但一题未必代表整个子域。

#15.5 LLM judge 仍存在

虽然 ALE 尽量避免 LLM judge，但视觉、媒体、自由文本任务中仍有窄 probe。窄 probe 比 holistic judge 好，但 judge 模型偏差、视觉误判、prompt 敏感性仍会影响分数。

#15.6 “经济价值”不是直接测 GDP impact

ALE 说要连接 GDP-relevant impact，但 benchmark 任务通过率和真实经济部署之间还有组织、责任、成本、法规、信任、集成等因素。它比传统 benchmark 更近，但不是最终答案。

#16. 最值得关注的研究问题

如果把 ALE 当成未来 Agent 研究的试金石，我觉得最值得挖的问题是：

1. Agent workflow representation：如何让模型内部形成可迁移的职业 workflow 表示，而不是每个任务临场乱试？
2. Long-horizon state abstraction：如何把数小时任务轨迹压缩成 decision-sufficient latent state？
3. Tool modality routing：Agent 如何学会什么时候用 GUI、什么时候用 shell、什么时候用代码、什么时候用专业软件？
4. Evaluator-aware but not evaluator-hacking training：如何利用 evaluate() 和 milestone checks 训练 Agent，同时避免只学会钻 evaluator 空子？
5. Model-based agent RL：能否学习“动作 -> artifact 状态 -> evaluator score”的世界模型，在低成本 imagined rollout 中训练策略？
6. Domain knowledge acquisition for agents：当前失败主要是理解和方法错误，那么 Agent 需要的是更强 base model，还是可检索 workflow memory，还是专家 demonstration？
7. Self-evolving agent on ALE-like tasks：Agent 能否在失败后自动总结领域技能、写脚本、构建 validators、更新 workflow library，下次同类任务更强？

#17. 总结

ALE 的核心价值是：把 Agent evaluation 从“交互能力”推进到“职业交付能力”。

它测的不是模型是否聪明地回答问题，而是一个完整 Agent 系统能否在真实软件环境中，经过长时程操作，产出可验证、有经济意义的结果。

当前结果说明：

• frontier agents 远未饱和；
• 最难档 Last-Exam 几乎全军覆没；
• ALE-CLI 明显难于 Terminal-Bench；
• 失败主因更多是任务理解、领域知识和策略，而不是纯工具执行；
• 模型能力差异目前比 harness 差异更大；
• Agent 仍明显偏向 CLI/Bash，GUI 和专业软件使用不足。

我个人判断：ALE 会成为 Agent 研究里很有代表性的“真实工作流评测”方向，但它更适合作为 milestone benchmark，而不是日常快速开发 benchmark。 对研究来说，它最有启发的地方是暴露了 Agent 从“会用工具”到“会工作”的断层。