Agents' Last Exam（ALE）：弥合基准测试表现与 GDP 影响差距的 Agent 评测基准

  • 关联论文：2606.05405
  • 作者：Tom
  • 更新：2026-07-29

一句话结论

Agents' Last Exam（ALE）是一个由 250+ 产业专家共建的评测基准，涵盖 13 个行业集群、55 个子领域、1000+ 任务，专注于评估 AI Agent 在长时序、具有经济价值且结果可验证的真实任务上的表现——当前主流 harness 和 backbone 配置的全流程通过率不足 1%，揭示了现有 Agent 系统与真实经济价值任务之间巨大的能力鸿沟。

解决什么真问题

AI 系统在各类基准上高歌猛进（棋类冠军、奥赛数学、编程竞赛），但经济产出的影响却出人意料地平淡。核心问题在于：现有基准测不出真实经济价值。

具体来说，广泛使用的 Agent 评测基准存在三大缺陷：

  1. 任务短视：多为单步或短流程任务，无法评估 Agent 在长周期工作流中的持续表现
  2. 结果难验证：缺乏可客观验证的成功标准，依赖 LLM-as-judge 或人工评估，引入主观偏差
  3. 与真实经济活动脱节：不映射到真实行业的真实工作流程，无法反映 GDP 相关影响

ALE 正是为解决这一"utility problem"而设计：让评测直接对标真实经济活动中的可验证工作成果。

核心方法

基准设计原则

ALE 的设计围绕三个核心原则：

┌─────────────────────────────────────────────────┐
│                  ALE 设计三原则                  │
│                                                  │
│  ① 长时序（Long Horizon）                        │
│     任务跨越多轮、多步骤、多工具调用               │
│                                                  │
│  ② 经济价值（Economically Valuable）             │
│     映射到真实行业 O*NET/SOC 2018 职业分类        │
│                                                  │
│  ③ 结果可验证（Verifiable Outcomes）             │
│     成功标准客观可测，不依赖 LLM-as-judge        │
└─────────────────────────────────────────────────┘

任务分类体系

  • 13 个行业集群（Industry Clusters）：覆盖非物理行业（non-physical industries），参照美国 O*NET / SOC 2018 职业分类体系
  • 55 个子领域（Sub-fields）：每个集群下细分为多个专业子领域
  • 1000+ 任务实例（Task Instances）：可运行的 Linux/Windows 虚拟机任务

任务实例分布在 13 个顶级域中，覆盖面积极广——涵盖了从数据处理、内容审核、商业分析到合规验证等多种真实工作场景。

开发方式

250+ 产业专家共建：任务定义和 ground truth 由真实行业从业者提供，确保任务的经济相关性和结果可验证性。这是一个 living benchmark——任务池持续扩充，随新行业和新工作流纳入而增长。

评测方式

  • 真实虚拟机环境：任务在 Linux 或 Windows 虚拟机上执行，Agent 需要像真实员工一样操作工具、读写文件、调用 API
  • 客观可验证结果：每项任务有明确的成功/失败判定标准，消除主观评分
  • 全流程评测：衡量 Agent 从任务开始到最终完成的全流程成功率，而非单步准确率

关键实验与数据

  • 当前全流程通过率：主流 harness 和 backbone 配置下，平均全流程通过率不足 1%（< 1% full pass rate）
  • 最难 tier 远未饱和（far from saturated）：即使是表现最好的配置，在最难任务上仍接近 0%
  • 行业覆盖：13 个行业集群，55 个子领域，1000+ 任务实例（持续扩充中）
  • 参与规模：250+ 产业专家共建，100+ 数据贡献者

这个 1% 的数字极具冲击力：即使是最先进的 Agent 系统，在真实经济价值任务上的成功率也低得可怜。这说明当前 Agent 评测基准与真实需求之间存在系统性高估。

亮点与局限

亮点： - 真实经济价值映射：首次将 Agent 评测直接对标 GDP 相关的工作活动，而非抽象能力基准 - 高度可信的评测设计：250+ 专家共建 + 客观可验证结果，避免了 LLM-as-judge 的系统性偏差 - Living benchmark 机制：任务池持续扩充，确保评测跟上真实经济发展 - 行业分类体系完整：O*NET / SOC 2018 的映射使评测具备职业有效性，而非人工构造任务

局限： - 当前阶段以 Linux/Windows VM 为主：物理世界的任务（如机器人操控、传感器交互）尚不在评测范围内 - < 1% 的全流程通过率既是亮点也是挑战：说明 ALE 任务难度极高，早期研究者可能难以从中学到有用的能力诊断信息 - 非物理行业局限：主要覆盖白领认知任务，对蓝领体力劳动场景覆盖不足 - 评测基础设施要求高：需要真实 VM 环境、可验证结果定义、专家共建机制——普通研究团队难以独立复现

对工程落地的启发

  1. 基准优化 ≠ 真实能力：Agent 在 GAIA、WebArena 等学术基准上的优秀表现，并不能外推到真实经济价值任务。ALE 揭示了这一转移的代价——即使在学术基准上表现良好的 Agent，在真实任务上仍可能 < 1% 通过率。不要用学术基准作为采购或部署决策的唯一依据。

  2. 长程任务的可验证性设计：对于自研 Agent 系统，参考 ALE 的结果验证方式（客观可测的最终状态）来设计内部评测，而非依赖人工判断或 LLM-as-judge。

  3. 行业专家共建的必要性：高质量 Agent 评测必须引入领域专家。通用 Agent 评测（如 MINT-Bench、AgentBoard）缺乏领域纵深，难以捕捉真实经济场景中的关键失败模式。

  4. < 1% 是行业机会：极低的基线性能意味着巨大的改进空间。对 Agent 系统供应商而言，ALE 应该成为核心对标基准而非刷榜目标——谁先在 ALE 上实现 10%+ 全流程通过率，谁就掌握了真实经济场景的入场券。

  5. Living benchmark 的工程实践：ALE 的持续扩充模式值得借鉴——任务定义和 ground truth 应该随真实工作流演化，而非一次性构建静态评测集。

与同方向工作的关系

  • vs. WebArena / GAIA / Mint-Bench：这些是学术评测，任务来自人工构造或自动化生成；ALE 的任务是 250+ 产业专家共建的真实性任务，且映射到真实职业分类，生态有效性更高。
  • vs. SWE-Bench（软件工程）：SWE-Bench 聚焦编程任务，是 ALE 覆盖的软件工程子领域的基础，但 ALE 覆盖更广（13 个行业集群，不只是编程）。
  • vs. OS-World（操作系统评测）：OS-World 专注于操作系统级任务验证；ALE 吸收了 OS-World 等工作的评测基础设施思路，但扩展到了多行业、多工作流。
  • vs. 传统经济影响评估：传统经济学使用 GDP 分解、技能任务匹配等宏观方法；ALE 以 agent 评测为微观切口，试图在任务级别建立"AI 能力 → 经济产出"的映射。

适合谁读

  • Agent 系统评测工程师：需要设计或使用真实能力评测基准的从业者
  • AI 战略 / 产品经理：评估 Agent 系统真实落地价值的决策者（警惕学术基准高估）
  • 产业 AI 落地团队：关注 Agent 系统在特定行业真实工作流中表现的研究者
  • AI Policy 制定者：理解 AI 对劳动力市场真实影响的宏观经济政策研究者
  • Benchmark 设计者：参考 ALE 的专家共建机制和客观验证设计

不确定处：各行业任务的具体难度分布、harness 配置细节（backbone 模型、工具集）、评测的 API 调用成本等全文细节需读原论文确认；目前仅获得 abstract 和 introduction 部分信息。

工程落地与核查（Jay）

事实核查

  • ✅ "250+ 产业专家共建"：原文表述，arXiv 原文摘要中明确提及"with 250+ domain expert practitioners"，可信度高。
  • ✅ "1000+ 任务实例"：原文数据，与摘要一致。
  • ✅ "全流程通过率不足 1%"：原文明确数据，是核心贡献点。⚠️ 注意：这是"主流 harness 和 backbone 配置"下的均值，实际分布中可能存在个别配置或任务子集明显高于 1% 的情况，不可误解为所有任务、所有模型都 < 1%。
  • ✅ "O*NET / SOC 2018 职业分类体系"：可验证的美国劳工部标准职业分类，映射到非物理行业（non-physical industries）逻辑自洽。
  • ⚠️ "Living benchmark"：原文是否明确提出此机制，需读全文确认。若任务池扩充机制未经验证，"持续扩充"的可信度存疑。
  • ⚠️ "13 个行业集群 / 55 个子领域"：具体分布和边界定义需读全文确认，尤其是各行业集群的覆盖比例是否均衡。

可读性精修

  • 用词统一建议：全文混用"Agent"和"AI Agent"，建议统一为"AI Agent"或"Agent"（全文保持一致）。当前混用情况示例："AI 系统"→"Agent 系统"，但其他段落又用"AI Agent"，建议统一。
  • "utility problem"：建议保留英文原词，或括号注"效益问题"，因为这是领域专用术语，中文直译会失准。
  • "Living benchmark"：建议保留英文或加括号"持续迭代的评测基准"。
  • 逻辑连贯性：第一句"高歌猛进"与第三段"utility problem"之间跳跃略大，建议在"utility problem"前补充一句过渡。

工程落地：实际系统怎么用、坑在哪

1. 如何将 ALE 融入实际研发流程

ALE 的真实价值不在于"刷分"，而在于诊断能力缺口。工程团队可以：

  • 分行业选择子集：ALE 的 13 个行业集群覆盖差异极大，不必全量跑。按自己业务所属的行业子集优先测试（例如：数据处理集群 vs. 合规验证集群）。
  • 设置内部基线：用当前主力模型跑 ALE 对应子集，得到自己的 < 1% 基线。每次架构/Prompt/工具链迭代后复测，观察提升幅度。
  • 将 ALE 作为"集成测试"而非"单元测试"：不要用 ALE 单次结果做决策，用多次统计（均值、分布）判断改进方向。

2. 关键工程坑

  • 坑1：VM 环境差异导致结果不可比。ALE 的 Linux/Windows 虚拟机任务对环境配置敏感。不同 harness 的工具版本、文件系统状态、API mock 方式均会影响通过率。实测前需严格对齐环境，否则复现 < 1% 的意义不大。
  • 坑2：< 1% 不代表"完全不能用"。全流程通过率是严格指标，实际业务中往往不需要"全流程"，而是分段评估（如只测"文件读写成功"）。建议工程团队设计自己的分段评测体系，而非盲目对标 ALE 全流程。
  • 坑3：任务定义依赖于专家共识，存在隐性偏见。250+ 专家共建意味着任务定义反映了当前行业的最佳实践，但这本身也是一种偏见。随着 AI 能力提升，"正确答案"可能发生变化，但 ALE 的 ground truth 更新频率未知。
  • 坑4：API 调用成本极高。1000+ 任务 × 全流程多次重试 × 主流 backbone 模型，评测成本可能是中小企业难以承受的。建议先跑小样本（10-20 任务）做快速诊断，再决定是否投入全量。

3. 实际复现建议

第一步：明确业务领域 → 选定 ALE 行业子集
第二步：在原论文/官方 repo 确认 harness 部署方式（是否开源？）
第三步：先跑 10-20 条任务，统计通过率（不计全流程，计分段成功率）
第四步：针对失败任务做根因分析（工具调用错误？长程规划失败？上下文遗忘？）
第五步：将分段诊断结果反馈到 Prompt 设计/工具定义/记忆系统优化

4. 与现有 SOTA 的关系要动态看

ALE 的 < 1% 并不意味着其他基准（如 GAIA、WebArena）没有价值——这些基准测的是不同维度。工程团队应建立多维评测矩阵：GAIA 测语言理解，WebArena 测网页操作，ALE 测真实经济任务。三者互补，而非替代关系。