Agents' Last Exam 深度分析 - 2026-07-10

type

status

date

slug

summary

原始链接

论文 HTML：Agents' Last Exam

论文摘要页：arXiv:2606.05405

官网：agents-last-exam.org

GitHub 仓库：rdi-berkeley/agents-last-exam

Hugging Face 论文页：Agents' Last Exam

为什么今天选它

今天的候选里有几类方向：Agent 记忆项目、MCP 工具链、长流程软件工程评测，以及更宽口径的真实工作流评测。Agent memory 和 MCP 项目很实用，但最近《智汇AI》已经连续写过 harness、loop、skill maintenance、browser harness；再写一个单点工具容易重复。

ALE 更值得写。它在 2026 年 6 月发布，官网现在标注由 Berkeley RDI 主导，已有 300+ 行业专家参与，覆盖 55 个子行业，收集 1,500+ 个任务，目标是 5,000 个任务。GitHub 仓库显示它不只是论文，还有公开评测框架、约 150 个公开任务、运行工具和多种 agent harness 适配。它问的问题也更狠：AI Agent 到底能不能在真实电脑环境里完成有经济价值的专业工作，而不是只在短任务或问答题上拿高分。

它到底在解决什么问题

现在很多 Agent 评测偏短、偏干净、偏单一。SWE-bench 看代码修复，OSWorld 看桌面操作，Terminal-Bench 看命令行任务，WebArena 看网页操作。它们都有价值，但每个都只覆盖真实工作的一小段。真正的专业任务通常不是“点一个按钮”或“修一个小 bug”，而是要读材料、操作软件、写脚本、处理文件、反复检查，最后交付一个可验证的结果。

ALE 把任务定义成 project deliverable，也就是完整交付物。论文里说，任务来自行业专家已经做过的项目，再被改造成可运行、可评分的实例。官网现在把它定位成面向真实专业工作流的 Agent benchmark。

这张图说明 ALE 的野心。它不是只测软件工程，而是把工程与建筑、计算与数学、视觉媒体、商业金融、健康医疗、生命科学、法律、教育等都纳入同一套坐标。图里每一行是一个子领域，颜色区分已经实现的任务和待质检任务。对 Agent 来说，这意味着“会写代码”只是底座，不等于会做制造仿真、金融表格、3D 建模或脑影像分析。

核心思想：把 Agent 放进真实工作现场

ALE 的关键不是题目多，而是它把评测对象从“模型回答”换成“agent 完成工作”。一个任务实例由 main.py 定义，里面包括任务描述、输入文件、目标软件、参考答案和评分逻辑。Agent 只看到任务描述和输入，在虚拟机里操作。等它结束后，系统再放入隐藏参考答案，用 evaluate() 打分。

这张图值得仔细看。左侧是专家提交的任务材料：输入、软件、描述、评分标准和参考资产。中间的 task spec 负责三件事：load() 声明任务，start() 准备环境，evaluate() 比较输出。右侧是虚拟机，分成 input/、software/、output/、reference/ 四个区域。Agent 能写的是 output/，看不到 reference/。

这个设计解决了两个老问题。第一，Agent 不能提前从题面里偷到答案。第二，评分不是靠一句“看起来不错”，而是尽量落到文件、数值、结构、几何、图像或行为状态上。论文明确说，能用确定性评分就不用 LLM-as-judge；必须用模型判断时，也尽量把问题拆成窄的 yes/no 检查。

任务是怎么来的

ALE 的任务不是普通众包题。论文里的构建流程是：找行业专家，收集他们真实做过或熟悉的工作流，提交任务说明和材料，先做自动/人工初审，再由工程人员实现成可运行任务，最后由专家委员会质检。

这张流程图解释了为什么 ALE 比一般 benchmark 难做。专家负责真实性，工程人员负责把任务变成可复现环境，QC 委员会负责检查参考答案和评分边界。这里的成本很高，但也正因为成本高，ALE 才能触到多数短评测碰不到的问题：软件许可证、真实输入文件、领域知识、跨工具协作、长时间运行和结果审计。

它还有一个防污染设计：论文说 1,490 个任务实例里只有 150 个公开，其余保留在私有池里，并会滚动替换。这个做法不完美，但比把全部题目公开后让模型训练或产品定向优化要稳。

它怎么看 Agent

ALE 提出一个叫 Generalist Computer-Use Agent，简称 GCUA 的对象。这里的 computer-use 不是单纯 GUI agent。它需要同时有五层能力：Brain 负责推理和计划，Eyes 看 GUI，Body 做编排，Hands 调工具，Feet 是运行环境。

这张图的判断很直白：传统 CLI agent 有命令行、文件、代码执行，但缺 GUI 视觉；GUI agent 能看屏幕和点鼠标，但经常缺完整工具、运行时和长流程编排。真实工作需要两边合并。比如一个制造任务可能既要用专业桌面软件，又要写脚本处理中间文件，还要检查输出格式。

ALE 对现代 harness 的拆法也很有参考价值。它把 Claude Code、Codex、OpenClaw 这类系统抽象成一个主循环：构建上下文，调用模型，决定动作，执行工具，收集结果，必要时压缩上下文。外面再接系统提示构建器、工具系统、子 agent 和上下文压缩器。

这张图把很多产品里藏着的结构画出来了。真正的 Agent 能力不只来自模型本身，还来自工具面、上下文管理、子任务分派、GUI 桥接和退出条件。ALE 用 GUI-as-Tool 把截图、点击、输入、滚动等桌面操作暴露为普通工具，让同一个主循环同时处理 shell 输出和视觉反馈。论文在实验部分提到，统一的 CUA MCP bridge 暴露了 14 个桌面动作工具。

实验结果说明了什么

论文主表里，最强 mainstream 配置 Codex + GPT-5.5 的总体 full pass rate 是 26.2%。在最难的 Last-Exam 层，它只有 8.6% pass。Claude Code + Opus 4.7 在 Last-Exam 层是 0.0%。这不是说这些系统没用，而是说明它们离“稳定完成真实专业工作”还差得很远。

更有意思的是，短任务成绩和 ALE 成绩差距很大。论文指出，Codex + GPT-5.5 在 Terminal-Bench 上能到 82%，但在 ALE-CLI 这个 Linux-only 子集上总体只有约 25% 左右。也就是说，命令行能力很强，不等于能完成更长、更杂、更接近行业现场的任务。

这张图给产品团队一个不太舒服但很有用的结论：在这些 well-engineered harness 之间切换，带来的分数差距大约是 5 到 6 个百分点；固定 harness 换模型，差距约 18 个百分点。我的理解是，现阶段模型底座仍然决定上限，但 harness 决定同一个模型能不能稳定地把能力用出来。两者不是替代关系。

论文还做了失败分类。Claude Code + Opus 4.7 的失败里，Approach 错误占 47%，Understanding 错误占 31%，Execution 错误占 22%。换句话说，很多失败不是鼠标没点准，也不是脚本崩了，而是 agent 没真正理解专业任务，或者一开始就选错了路线。它常常用脚本绕开专业软件，结果做出来的东西不符合行业语义。

新在哪里，哪些只是包装

真正新的地方有三点。

第一，ALE 把“真实专业工作流”变成了可执行评测单元。它不是只描述任务，而是要求每个任务能启动环境、隐藏参考、收集输出、自动评分。

第二，它把 CLI agent 和 GUI agent 放到同一个评测面上。过去这两类系统经常分开比，ALE 明确说真实工作需要 GCUA，也就是 shell、文件、浏览器、GUI 和专业软件一起用。

第三，它重视评测可审计性。每次运行会留下统一轨迹、原始日志、评分结果和产物。这个设计对开发 Agent 很重要，因为失败原因不能只靠一句“模型不行”。你需要知道它是没看懂、计划错、工具用错、文件写错，还是环境卡住。

包装成分也有。Brain/Eyes/Body/Hands/Feet 这个五层分类方便传播，但本质上仍是能力分层，不是新的运行机制。GUI-as-Tool 也不是全新概念，很多 agent 产品早就在做桌面动作工具化。ALE 的价值不在这些名词，而在它把这些组件放进一个可复现、可比较、可追踪的评测系统里。

对产品和研发有什么启发

做 Agent 产品时，不要只盯“工具数量”。ALE 暗示真正重要的是任务闭环：输入是什么，输出写到哪里，成功怎么判定，失败能不能复盘。

内部评测也该从 demo 任务升级到交付物任务。一个好任务最好有真实输入、明确输出目录、隐藏参考、自动评分和运行日志。哪怕规模很小，也比一组“让 agent 帮我做某事”的主观测试更有用。

对需要 GUI 的产品，不要把 GUI 当成最后补上的插件。ALE 的结果显示，很多任务明明需要图形软件，agent 却倾向于退回 Bash 或脚本。这可能是训练数据偏差，也可能是 harness 的工具成本设计问题。产品上要让 agent 明白什么时候必须进入专业软件，什么时候可以用代码替代。

对长流程任务，memory 不是万能药。论文里的 ALE-Claw 省掉了长期记忆和用户偏好管理，但在单任务评测里仍能接近其他 harness。这说明在单次交付里，更优先的是上下文压缩、动作循环、工具可靠性和评分反馈。长期记忆要解决跨任务连续性，不能拿来替代任务内的严谨流程。

风险和局限

ALE 很强，但不能直接等同于真实企业生产力。

第一，任务虽然来自专家，但被改造成了评测实例。真实工作里还有沟通、权限、审批、组织偏好和不断变化的目标，这些很难完全放进 benchmark。

第二，私有任务池能降低污染，但也会带来透明度问题。外部研究者很难完全确认私有集的覆盖、难度和评分一致性，只能依赖公开子集和论文分析。

第三，自动评分会偏向可度量产物。法律建议、战略判断、设计品味、客户沟通这类高价值工作，仍然很难只靠确定性脚本评分。

第四，成本不低。论文提到单个 frontier agent 跑一个 ALE 任务平均要花 3 到 10 美元，耗时从几十分钟到数小时。对于普通团队，ALE 更像里程碑评测，不适合每天大规模回归。

第五，它测的是“能不能完成任务”，不是“该不该让 agent 做这个任务”。安全、责任边界、人类审批和业务风险还需要另一套机制。

今日沉淀

Agent 评测要从“答对”转向“交付对”。

真实任务需要 CLI、GUI、文件、专业软件和评分器一起设计。

Harness 的价值在闭环，不在工具清单长短。

失败复盘要分清没看懂、路线错、执行差和环境问题。

模型决定上限，harness 决定能力能不能稳定落地。