衡量前沿AI能力的开放世界评估方法
本文约 8,000 字，是我们关于一种新兴 AI 评估方式的合作论文。论文同时也发布了 PDF 版本，请点击此处查看。
摘要：AI 模型已在大多数主流基准测试上趋于饱和。但这是否意味着它们能真正构建并发布一个产品，或者端到端地完成一项科学实验，又或者应对政府机构繁琐的流程？研究者们已经开始在这样的真实场景中测试 AI。我们将这类评估称为"开放世界评估"（open-world evaluations）。本文阐述了开放世界评估的定义，综述了迄今为止积累的经验教训，并给出了开展此类评估的最佳实践。
我们还推出了 CRUX，一个由学术界、政府、民间社会和产业界 17 位研究者组成的合作项目，将定期通过开放世界评估来衡量前沿 AI 能力。在我们的首次实验中，一个 AI 智能体独立构建并在 App Store 上发布了一款 iOS 应用，仅犯了两个错误，其中一处需要人工介入。这一结果向我们展示了一个潜在有用能力的早期迹象，更重要的是，也为 AI 驱动的应用商店垃圾内容风险发出了预警（我们在论文发表前一个月向苹果披露了这一结果）。
我们计划在更多真实领域开展类似实验，以发掘早期风险预警；这将是我们在未来一年的核心实证工作之一。
作者： Sayash Kapoor、Peter Kirgis、Andrew Schwartz、Stephan Rabanser、J.J. Allaire、Rishi Bommasani、Magda Dubois、Gillian Hadfield、Andy Hall、Sara Hooker、Seth Lazar、Steve Newman、Dimitris Papailiopoulos、Shoshannah Tekofsky、Helen Toner、Cozmin Ududec、Arvind Narayanan
我们应当如何追踪和预测 AI 能力？当前 AI 社区的主流答案是基准测试。例如，METR 的时间跨度图已被政策分析师、产业领袖以及研究 AI 风险的组织用来论证 AI 能力正在快速提升。
然而，基准测试既可能高估、也可能低估进展。要把一项任务做成基准，必须给出精确定义并能自动验证。但问题在于，越是能精确定义、可被基准化的东西，也越容易被针对性地优化，让 AI 智能体在这类任务上表现优异。反过来，基准测试中准确率低，有时只是一些偶然因素造成的，比如在浏览网页时撞上验证码——即便智能体本来有能力完成底层任务。
为突破这些局限，许多研究者开始转向一种新的评估方式：篇幅更长、更贴近真实世界的"开放式"评估，它超越了传统基准测试。Anthropic 的 Nicholas Carlini 让 Claude 智能体构建了一个能编译 Linux 内核的 C 编译器。Anthropic 和 Andon Labs 还联合设计了一项开放式实验，让 Claude 负责经营他们办公室里的一家小店。传统基准由几十道题目组成、以自动化方式打分；而开放式评估样本量往往很小，常常需要人工介入，并以开放的方式进行评判，比如分析智能体的运行日志。
很容易把这些做法斥为"不科学"：每次评估的样本数只有 1，缺乏标准化，也无法复现。尽管存在这些局限，我们仍然认为这类评估对于收集 AI 能力方面的证据具有重要价值。它们可以就新出现的能力发出早期预警，从而帮助社会构建相应的韧性；也能让评估者发现现有基准中存在的盲区；同时还能让企业更清楚地了解 AI 系统很快能够胜任哪些任务，为 AI 相关的战略决策提供参考。我们把这类评估称为开放式评估。
本文将对开放式评估进行概念梳理，回顾过往的案例以总结其中的最佳实践与陷阱，并介绍 CRUX——一个旨在定期开展新型开放式评估的项目。以下是我们的主要观点：
开放世界评估是一类正在兴起的重要 AI 评估方法。随着 AI 系统能力的不断提升，用于探测前沿能力的评估也必须日益复杂。开放世界评估是这条从简到繁的评估演进路线上的最新一环。我们梳理了过去一年中开展的 10 项具有代表性的开放世界评估，旨在总结最佳实践并提炼关键启示。
CRUX（Collaborative Research for Updating AI eXpectations，意为"更新 AI 预期的协作研究"）是我们系统性开展开放世界评估的一次尝试。团队成员来自政府、学界和非营利机构，其中不少人曾主导过开放世界评估工作，并且对 AI 的未来抱有不同的预期。我们的目标是，即便成本较高，也要为 AI 系统当前的能力提供实证依据，并对可能即将广泛出现的能力发出早期预警。我们计划定期发布新的开放世界评估。
在首个 CRUX 实验中，我们让一个 AI 智能体独立开发并上架一款简单的 iOS 应用至 App Store。许多基准测试衡量的是智能体编写代码的能力。而上架一款 iOS 应用还涉及诸多其他环节：对应用进行签名、在网页上发布隐私政策、填写 Apple 的各类表单，以及通过应用审核流程。我们更关注的是智能体能否完成上架应用所需的真实世界任务，而非单纯考察其编码能力，因此我们让它构建一款简单的应用并完整走通 iOS App Store 的提交流程。
最终，智能体在两次失误后完成了任务，其中一次还需要人工介入（忘了把凭证存在哪里，还为 App Store 审核流程瞎编了一个电话号码）。整个开发和上架过程花了大约 1000 美元，目前该应用已在iOS App Store上架。我们认为成本其实可以低得多：仅应用开发和提交就只花了 25 美元，绝大部分 token 都消耗在了监控应用状态上。本文发表前一个月，我们已主动联系苹果公司披露了这次实验的结果。各应用商店运营方应当未雨绸缪、加大力度整治垃圾提交，因为未来他们很可能会面对成千上万个由智能体自主提交的应用。
如何改进开放世界评估？下一步是什么？为提升开放世界评估的价值，评估方应当明确允许何种程度的人工介入、公开发布智能体解题过程中收集的日志，并通过对日志的分析来呈现智能体的实际行为。未来的 CRUX 评估将涵盖 AI 研发自动化、AI 治理等更多领域。
开放世界评估是新兴的重要 AI 评估类别
本节我们将厘清开放世界评估的定义，并梳理该类评估的发展现状，从中提炼其优势与局限。我们将探讨开放世界评估能够弥补传统基准测试哪些盲区。我们的观点是：随着 AI 系统能力越来越强，用于激发前沿能力的评估也必须越来越复杂；开放世界评估就是这一系列日趋复杂的评估中最新的一环。与此同时，我们也会讨论开放世界评估相较于传统基准测试自身的边界所在。
我们在下文阐述了界定开放式评估的五条宽松标准（见"什么是开放式评估？"一节）。但需要指出的是，冗长复杂的基准测试任务与开放式评估之间的界限其实并不清晰。事实上，我们讨论的许多评估都运行在沙盒环境中。我们仍将它们纳入开放式评估的清单中，因为它们满足我们其他方面的标准（例如，Carlini 的 C 编译器虽然运行在沙盒中，但只包含一项长时间运行的任务，涉及人工干预，并将定性分析纳入评估环节）。
基准测试既能高估也能低估进展
对 AI 看法迥异的人们一致认为，现有的 AI 基准测试可能很快就会达到饱和。过去两年里，许多知名基准已经趋于饱和，评估者们竞相推出"下一代"基准。而这些更新后的基准中，有许多自身也已接近饱和。
这是否意味着 AI 系统很快就能解决任何任务？未必。基准分数的提升可能反映了真实的能力进步，但也可能夸大了进展：原因之一是基准的构念效度有限——它们衡量的是在狭窄任务上的准确率，而非通用能力；此外，基准也无法测试智能体在真实环境中的应变能力。
另一方面，基准也可能低估了进步——环境或基础设施中那些与所测能力并无直接关联的障碍（例如遇到 CAPTCHA）会拉低分数。
更全面的一种方式是采用准确率之外的衡量指标。例如，在我们几位作者共同撰写的一篇近期预印本中，我们指出，尽管智能体在能力指标（如平均准确率）上的提升十分显著，但在衡量可靠性的指标上进步却要缓慢得多。同样，在 SWE-bench 任务中，许多被判定为正确的智能体方案虽然能通过测试，却仍然会被项目维护者拒收。
但这仍然无法帮助我们衡量 AI 能力的上限。那些今天已经具备的能力（即便只在有利的条件下才能实现），很可能很快就会变得普及，我们必须在其普及之前提前预判。尽早发出预警，能让企业有更多时间抓住新机遇，让机构有更多时间增强韧性，也能让政策制定者更及时地应对风险。
下面我们来更详细地讨论为什么基准测试既可能高估、也可能低估能力。高估的原因包括：
基准测试与适合现代强化学习（RL）技术的任务形式高度相似。要将一项任务转化为基准测试，它必须被精确定义且可自动验证。然而，凡是足够精确到可以用来做基准测试的，也足够精确到可以被针对优化，而现代 RL 训练流程越来越呈现出与基准测试本身相似的形态。这使得任何可以通过基准测试衡量的任务都容易被迅速"刷满"。
这一现象已经在 Harbor 等领先评测平台上出现，这些平台同时也是 RL 训练平台。因此，AI 模型可以直接在这些平台收录的许多主流基准测试数据上进行训练。即使基准测试设有留出测试集，模型也可能通过训练集中与测试集极为相似的任务进行训练。所以，基准测试无法帮助我们了解模型在真实世界中的泛化表现如何。
基准测试回避现实世界的复杂性。现实任务包含各种无法完全沙盒化的不确定交互，比如应对突发情况或在开放式的环境中操作。基准测试虽然可以做一些模拟，但无法真正重现真实环境的复杂性。
基准测试还可能低估模型能力，原因如下：
激发前沿能力的成本很高。大规模、长时间运行的实验开销巨大，难以达到基准测试所依赖的样本量。例如，Anthropic 的 C 编译器实验花费约 2 万美元；下文将介绍的实验（为 CRUX #1 开发并发布一款 iOS 应用）也花费了约 1,000 美元。我们无法将这类实验重复上百次，因此每个基准任务的预算和复杂度都受到限制。
平均表现与能力上限之间存在很大差距。在基准套件中运行数十甚至上百个任务，只能量化平均水平。但当我们试图探索智能体能做什么的前沿时，目标就变成了了解最佳表现：在给予充足资源和支持以绕过偶发失败的情况下，智能体能完成什么？这对于提前预警那些可能即将普及的能力至关重要。
人工干预有助于逼近能力上限。智能体在执行真实任务时，可能会遇到策略拒绝、需要解决验证码，或陷入其他基础设施问题而卡住，这些都会拉低成绩。但这些失败与我们要测量的能力本身只是附带关系。如果由人类操作员来处理这些问题，就能让我们更准确地测出能力上限。然而，每次运行上百个基准任务都进行人工干预是不现实的。
随着 AI 能力的提升，用于测试 AI 在编码、深度研究、客服等场景表现的沙盒类评测需要精心搭建的工程化环境，才能真正对智能体构成挑战，同时避免数据污染或钻空子拿高分。例如，智能体在网页基准测试上的表现会受到遭遇 CAPTCHA 频率的影响，而非真实能力。又比如，已有研究发现 AI 智能体存在上网搜答案、利用评测漏洞、提交能通过测试却达不到生产标准的代码等问题。这凸显了我们需要转向对 AI 智能体表现的深度定性评估，以更好地理解那些被淹没在大量平均分数中的失败模式和问题解决策略。
但这些有效性威胁并不容易解决。我们可以对基准测试的日志做定性分析来应对部分问题，但即便通过日志分析发现了有效性问题，除了发布一个更新版基准（可能要花几个月），我们也几乎无计可施。开放世界评测让我们能在正式测试前进行试运行来排查问题，并在评测过程中人工介入修复发现的缺陷。1
当然，尽管存在这些局限，基准测试仍然有其价值。2 开放世界评测本身也有不足之处，我们将在后文讨论。尽管如此，我们希望这份清单能够说明传统基准测试中系统性的盲区。随着 AI 智能体越来越强大，传统基准与真实能力之间的差距会持续扩大。衡量成功的指标需要多维度，以覆盖任务目标的多元性；基准测试也需要引入关键瓶颈（人工协助）和复杂环境（互联网导航），而这些都会带来新的内部和外部有效性问题。开放世界评测提供了一种替代方案。
什么是开放世界评估？
随着评估方法与 AI 能力共同发展，评估体系逐渐形成了一个连续谱。一端是简单、自动化且可大规模扩展的方法，适合评估早期能力；另一端则更全面，但需要更多人力，随着能力提升、简单指标趋于饱和，这类方法也愈发必要。
某一领域的能力提升后，连续谱中更靠后的评估方式就变得重要，因为它们能提供简单评估无法给出的补充洞见。我们认为，这一连续谱目前大致可分为五个层级，每种方法都有自身的优势和局限：
问答基准（例如 MMLU、GPQA）：适合评估广泛的知识水平，但对前沿模型而言正逐渐趋于饱和。这类基准通常采用选择题形式，便于评分，但因此构念效度较低，因为用户很少会通过提出选择题来与模型互动。
开放式对话基准（例如 WildBench、Arena-hard-auto）：能够捕捉更细微的表现，但仍局限于单轮或短程交互。
仅看结果的智能体基准（例如 SWE-Bench、WebArena）：用于测试智能体完成真实任务的表现，但只衡量任务是否完成，而不评估完成过程。因此，这类方法存在局限。例如，大多数通过 SWE-Bench 的方案都不会被仓库维护者接受。
带日志分析的智能体基准（例如 UK AISI 交互记录分析、METR Time Horizon）：通过分析智能体日志，深入考察智能体如何成功或失败，并发现错误与奖励投机行为。但它们仍运行在沙盒环境中，任务也预先定义。
开放式评估：在真实环境中执行的长周期任务，这类任务难以给出明确定义，也无法自动评分。这种方式有助于探明能力上限，但代价是缺乏可复现性和标准化（而这两点恰好是基准测试的优势；参见局限性一节）。
有些评估介于上述光谱的不同类别之间。例如，OpenAI 的 GDPVal 是一项长周期智能体基准，由专家根据质量打分，属于人工评分；其结构与开放式评估非常相似，但主要关注输出结果本身，而不分析运行日志。与此同时，GDPVal 的结果通常使用 GDPval-AA 来报告，该方法采用 LLM 自动评分，这种评估设置则更接近仅关注结果的智能体基准。
开放式评估的做法是：让智能体在少量长周期、真实场景的任务中运行，然后通过日志分析工具对其结果进行定性评估。它们与基准测试互为补充，能够弥补基准测试的诸多不足，也可以发掘当前 AI 仍无法胜任的任务，为未来的基准测试工作指明方向。
我们给出一个粗略的分类框架，以厘清开放式评估的边界。没有任何单一维度能单独决定一项实验是否属于"开放式"，这取决于以下所有维度所呈现的整体模式。
开放性：评估是否在真实部署环境中进行（而非沙盒环境）？
复杂度/时长：该任务是否需要人类花费数天乃至数周来完成（而非几分钟或几小时）？
任务数量：这是一项独立任务，还是由少量任务组成（而非大型评估套件或基准测试）？
人类介入：为了探明能力上限，当智能体遇到障碍时，人类是否可以介入帮助（而非仅仅负责搭建环境或解决环境配置问题）？
评估方法。该评估是否主要包含深入的日志分析（而非依赖单一平均指标得出的结果）？
什么时候我们会把某件事称为"评估"，而不仅仅是让智能体去完成一项新任务？例如，Anthropic 用 AI 智能体在 Mozilla Firefox 等主流开源软件中查找安全漏洞——这算不算开放式评估？如果智能体的角色（智能体执行的部分与人类专家执行的部分，以及最终结果）有系统性、公开的记录，我们仍将其视为开放式评估。
复杂基准任务与开放式评估之间的界限也是模糊的。例如，我们下面列出的部分开放式评估是沙盒化的（如 Claude Plays Pokemon 和 Anthropic 的 C 编译器 都在沙盒环境中运行），但我们仍认为它们属于开放式评估，因为它们包含单一的、复杂的、长期运行的任务，评估过程中存在人为干预，并且以定性方式评估。
这两种评估形式也是互补的：我们可以先用开放式评估来了解哪些任务仍是智能体无法解决的，作为构建新基准的第一步；同时也可以用开放式评估来评估智能体在那些难以被基准化的、混乱的现实任务上的表现。
最后，我们并不想暗示开放式评估在理解 AI 进展方面一定比基准测试更有价值。事实上，我们在本节后面会讨论开放式评估的诸多局限性。恰恰相反，随着 AI 能力的提升，开放式评估作为一种额外的、互补的信号，其重要性日益凸显。
开放式评估的不完全概览
在过去一年中，AI 实验室、大学、非营利组织和独立团队的研究人员已开始进行开放式评估。这些评估有一个共同的模式：给一个能力较强的 AI 智能体布置一项困难的、真实的任务，并赋予较长的时间跨度，然后细致地观察和分析其行为。一些值得关注的例子：
Anthropic，Claude 玩 Pokémon（2025 年 2 月）。Anthropic 在 Twitch 上开启了一场直播，由 Claude 3.7 Sonnet 游玩《精灵宝可梦：红》。虽然这不是真实场景的部署，但相比传统基准测试，这个实验较早地把 AI 智能体放在了一个相对开放的环境中。项目虽然展示了 AI 在极少脚手架支持下使用计算机的进展，但同时也清楚地暴露出 2025 年初智能体的局限——Sonnet 3.7 曾在一个关卡卡住了近 80 个小时。3
AI Digest，AI Village（2025 年 4 月至今）。AI Village 为多个 AI 智能体分别配备独立的计算机环境，并共用一个群聊，然后给它们布置开放式真实任务，比如为慈善机构筹款、组织线下真人活动、设计文字游戏、在 Substack 上涨粉等。在 2025 年的多轮实验中，项目揭示了智能体持续存在的失败模式——幻觉、置信度校准偏差、低效循环——但同时也记录到 2025 年下半年的智能体在这些维度上有了显著改善。
Anthropic 与 Andon Labs——Project Vend（2025 年 6 月至今）。Anthropic 与 Andon Labs 合作，让一个基于 Claude 3.7 Sonnet（昵称"Claudius"）搭建的智能体在其办公室运营一家小型自动化商店。该智能体在数周内负责库存管理、定价和与顾客交互，由此暴露出在操纵行为、优先级排序和真实世界决策等方面的大量失败模式。第二阶段将实验扩展到多个地点，使用了更新的模型，并加入了由《华尔街日报》团队执行的红队测试。该智能体因规划不当、幻觉问题和过度打折几乎损失了全部营收。Anthropic 后续阶段表现更好，每周都公布正向利润，但《华尔街日报》团队仍然成功越狱了"Claudius"，使其将所有商品免费送出。Andon Labs 最近启动了该项目的第三阶段，他们让一个基于 Claude 的智能体"Luna"在旧金山获得了一家实体店三年的租约，并要求它以"店长"身份实现盈利，包括雇佣人类员工、设计品牌和进行产品选品。
Lin 与 Cursor 浏览器实验（2026 年 1 月）。Cursor 的 Wilson Lin 协调了数百个 GPT-5.2 智能体，从零开始构建一款网页浏览器，连续运行了一周。最终得到的浏览器（"FastRender"）包含超过一百万行 Rust 代码，并配有一个从零编写的渲染引擎。它能够渲染简单的网站，但远未达到可投产的水平。该项目的意义在于大规模探索了多智能体分层协同，以及当智能体连续工作数天（而非数分钟）时出现的特定失败模式。
Carlini，C 编译器（2026 年 2 月）。Anthropic 的 Nicholas Carlini 让 Claude 从零开始构建一个 C 编译器，花费了约 2 万美元的 API 成本。该智能体产出了一个能编译 Linux 内核的可工作编译器，并通过了大批标准测试套件，清晰展现了智能体的能力边界——擅长系统性代码生成和测试驱动的迭代，但在复杂优化阶段和调试细微的规范违规方面仍有困难。
Ho，"AI 离取代我的工作还有多远"（2026 年 2 月）。Epoch 研究员 Anson Ho 让 Claude Code 和 ChatGPT Atlas 自主完成 Epoch 的三项高难度工作任务：复刻一个包含 40 个参数的交互式经济模型网页界面；以 Epoch 的风格撰写一篇关于 2025 年 AI 进展的文章；将一篇文章从 Google Docs 移植到 Substack 和 Epoch 网站。该项目凸显了在知识工作任务中，格式问题和幻觉仍然是持续存在的瓶颈。
Choi，GPT 5.3 Codex 构建设计工具（2026 年 2 月）。OpenAI 的 Derrick Choi 让 GPT-5.3 Codex 自主连续运行 25 小时，生成了 35,000 行代码，从零开始构建一个"设计工具"。文章指出，该智能体在规划、记忆和验证流程方面表现出色，但未对最终产品的能力和局限进行实质性分析。
Faulkner，Next.js 重新实现（2026 年 2 月）。Cloudflare 的一名工程师使用 Claude 配合 OpenCode 发布了 vinext——基于 Vite 而非 React 的流行前端 Web 框架 Next.js 的重新实现。最初的博客文章宣传其以仅 1,100 美元的 API 成本覆盖了 Next.js 94% 的功能，但后续的分析指出，由于 Vite 和 Next.js 都严重依赖人工构建的测试和基础设施，该项目在安全性方面存在持续缺陷，且向其他软件领域的泛化能力较弱。
Papailiopoulos，"你能训练一台计算机吗"（2026 年 3 月）。Dimitris Papailiopoulos 及其合作者测试了 Claude Code 和 OpenAI Codex 能否训练一个 Transformer 使其充当通用计算机。实验包含完全自主的轮次——两个 agent 均失败并出现了奖励黑客行为——以及有人工引导的版本——Claude Code 成功完成，并展现出有意义泛化能力，包括解决训练中从未见过的多步计算问题。
Karpathy，Nanochat Autoresearch（2026 年 3 月）。Andrej Karpathy 基于已有的开源项目 nanochat（用于 GPT-2 级别的 LLM 训练）搭建了一条简易的自动化流水线，让 AI agent 以每次 5 分钟的节奏优化训练过程。agent 拥有完全的自主权，可以调整架构、超参数、优化器以及 batch size。在后续更新中，Karpathy 分享称，autoresearch 在"达到 GPT-2 所需时间"这一指标（以 8×H100 GPU 测算）上取得了进展，2 天内将该指标降低了 11%。
我们计划在 cruxevals.com 上持续汇总此类评测（以及每项评测的核心结论与局限）。AI 能力的提升让各领域的专家都能开展此类评测，亲自验证 AI 系统能否完成自己擅长的任务，由此引发了对这类评测日益增长的关注。仅在过去一周内，就涌现了大量重要的开放世界评测成果，包括 Adamczewski 等人的 MirrorCode（让 agent 重新实现大型程序）、Wen 等人发布的一组自动化对齐研究案例分析，以及 Huang 使用 Claude Code 训练模型来预测最近美国大师赛高尔夫比赛结果的实践。
开放世界评测的局限性
虽然开放世界评估有助于弥补基准测试的一些盲点，但它本身也存在不少局限。改进基准测试和投入开放世界评估之间存在真实的权衡：基准测试让评估者能掌控任务、在受控环境中进行评估，但在衡量 agent 在开放式任务上的表现时作用有限；开放世界评估为了提升任务构念效度、激发 agent 的上限能力，不得不牺牲沙箱隔离和评估者控制。具体而言，开放世界评估存在以下局限：
缺乏可复现性与标准化：基准测试之所以成功，在于它为 AI 社区提供了协调机制。研究人员可以独立开发并测试新方法，借助基准测试验证方法效果，从而获得社区关注。基准测试的文化影响如此深远，以至于 David Donoho 将其称为过去 50 年 AI/ML 社区成功的「秘诀」。而开放世界评估则放弃了这种使基准测试如此成功的可复现性与标准化。
难以比较 agent：基准测试可以对不同模型或 agent 进行相对比较。但开放世界评估通常只运行一次或寥寥数次，不同运行之间的波动可能大于不同 agent 之间的表现差异。因此，开放世界评估并不适合用来比较不同模型或 agent 的准确率。
需要领域专业知识：判断 agent 是否在开放世界评估中成功并不容易。验证 agent 的工作成果往往需要深厚的领域专业知识并耗费大量时间，尤其是当任务本身是开放式的时候。
日志分析不完整：即便使用自动化日志分析来研究开放式评估，其结果也永远不能被视为穷尽无遗的。长时任务中智能体的运行记录可达数亿个 token，彻底的人工审查实际上难以做到。而且由于这些任务中智能体的行为十分复杂，没有任何保证某轮分析能挖掘出所有值得关注的行为或错误。这一局限在传统基准测试中并不明显，因为后者的成功标准是预先定义且自动验证的。将日志公开发布以便更广泛的社区来审查，是部分缓解此问题的一种方式。
成功标准模糊：考虑到可能存在人工介入，很难将智能体本身的表现与人类给予的帮助干净地区分开来。
环境非平稳：在开放式评估中，智能体可以与互联网等开放式环境交互。4 这使得我们难以判断智能体究竟是真正具备某项能力，还是仅仅利用了从互联网（或其他开放环境）获取的信息。例如，某智能体完成了一项困难的软件工程任务，究竟是因为它确实胜任此类任务（因此也能解决全新的软件工程任务），还是因为它在网上搜索到了该具体任务的答案（面对全新任务则无能为力）？此外，随时间推移比较智能体表现也很困难：例如，互联网上的各类实现方案或提示不断累积，未沙箱化的智能体可以从中汲取。
不同利益相关方如何利用开放式评估
开放式评估虽有其局限，但有助于弥补传统基准测试的盲区。我们认为它能为多方利益相关者带来价值：
政策制定者：AI 在各领域的落地应用滞后于其能力的提升，这让各类机构有时间在 AI 系统变得更强大的过程中逐步适应。开放世界评估可以通过提前预警智能体即将能够自主、大规模执行的任务，进一步延长这一缓冲期，让机构有时间构建韧性。例如，Anthropic 近期利用 AI 发现网络安全漏洞的工作，有望推动各方加快将 AI 用于防御性网络安全建设，尤其是在关键软件基础设施领域。
AI 评估者与研究人员：开放世界评估是对基准测试的有益补充，它能够测试那些在结构上难以通过基准来衡量的能力，例如解决混乱的真实世界任务。通过分析智能体的运行日志，我们可以发现它走捷径或钻奖励机制空子的行为。反过来，也能发现智能体产生新见解或突破既有局限的地方。例如，在我们的 iOS 应用开发评估中，我们发现智能体主动调整了自己的方法以提高 token 使用效率，从而在不依赖我们任何输入或指令的情况下，大幅降低了完成任务的开销。
前沿 AI 开发者：AI 开发者应积极支持并参与外部的开放世界评估工作，包括提供模型访问权限（例如模型的预发布使用权），以及为那些评估内容可能不符合开发者服务条款（例如安全评估）的第三方设立安全港机制。由独立第三方开展的开放世界评估，有机会发现内部红队因聚焦于已知威胁模型而遗漏的问题。
新模型也在不断"刷满"基准测试。例如，Anthropic 在 Mythos Preview 系统卡中提到，该模型"在我们大量最具体、可客观打分的评估上已达到饱和"，迫使他们只能依赖噪声更大的方法来评估能力。开放世界评估则提供了一种互补途径，能够在基准测试已无法有效区分的现实场景中对模型进行压力测试。
为了推动开放世界评估生态的发展，重要的是建立共享的最佳实践，并逐步积累关于智能体能做什么、不能做什么的证据。这正是我们正在推进的新项目 CRUX 所要实现的目标。
CRUX：AI 预期迭代的协作研究
CRUX 是一个将开放世界评估落地执行的项目。我们计划定期开展开放世界评估。每次评估都将包含一项长时段的真实任务：一个理论上能够让智能体完成该任务的脚手架实现，以及对该智能体如何完成任务的详细分析。团队成员来自工业界、学术界和非营利机构，许多人都有过开放世界评估的实战经验。
除了开展评估，我们还希望建立机制，为即将广泛出现的 AI 能力提供早期预警。例如，如果 AI 智能体已经几乎能够自主开发并发布应用（这是 CRUX 首轮评估的任务，下一节将详细讨论），那么像 Apple 和 Google 这样的应用商店运营商可能很快就需要更新其政策，以应对垃圾提交的问题。5
这要求我们激发能力的上限表现——通常需要借助人工来补齐缺失的辅助能力（例如完成验证码）。开放世界评估恰好适合这种风格的评估，因为它能帮助我们深入理解 AI 系统的真实能力。
开放世界评估的另一个优势在于，我们无需在评估前构建庞大的任务集或设计复杂的环境与沙盒，因为每个任务只需执行和评估少量次数。这使我们能够定期开展新的评估。我们计划每 1-2 个月设计一次新的 CRUX 评估任务，分析结果，并公开发布对新任务的研究报告。
我们的首次评估测试的是 AI 智能体能否自主开发并发布一款 iOS 应用至 App Store；我们将在下一节展开讨论。在未来的迭代中，我们计划将评估扩展到更广泛的领域，包括 AI 研发自动化、AI 治理、复杂软件工程以及真实物理任务等。
CRUX #1：AI 智能体能否自主开发并发布一款 iOS 应用？
AI 智能体能否编写软件这一问题已被广泛研究，既有 SWE-Bench 和 Terminal Bench 这类基准测试，也有本文前面提到的 C 编译器和浏览器实验等开放式评估。智能体已经展现出了很强的编程能力（不过代码质量和可靠性方面的问题仍未得到解决）。
然而，有一个任务却较少受到评估关注，那就是智能体能否处理软件部署中非编码层面的事务，例如满足平台要求、与不受自己控制的审核系统打交道等。在本次评估中，我们让一个智能体从零开始开发一款移动应用并将其发布到 iOS App Store。
我们提示智能体开发并发布一款简单的应用到 App Store。我们主要关心的并非其软件工程能力，而是它与 Apple App Store 提交流程的交互能力。这一流程要求开发者配置签名证书和配置文件（provisioning profile）、准备截图和元数据、起草并将隐私政策托管到一个公开的 URL、填写合规问卷，以及将应用提交给 Apple 团队审核。审核人员可能因技术或政策原因拒绝应用，此时开发者需要排查问题、做出修改并重新提交。整个流程通常需要数天时间，且涉及与开发者无法掌控的系统和审核人员打交道。
智能体负责流程中的每一个步骤，但政策要求必须由人工完成的环节除外，例如注册 Apple Developer 账号以及点击发布按钮将应用正式上架。具体而言，智能体承担了编写代码、构建应用、准备元数据、起草并托管隐私政策、提交审核，以及处理各类反馈的工作。（我们为智能体提供了一台 Mac 虚拟机、一个 GitHub 账号、一个 Apple 开发者账号和一个 Gmail 账号。）
评估成功与否的标准是智能体能否将应用成功发布到 App Store。我们记录了完成任务过程中需要人工介入的次数。智能体可以选择向团队请求协助，我们每天查看一次进度。该数字越低，说明智能体表现越好。
此外，如果智能体能够自主完成这些工作（或者接近能够自主完成），这也相当于给 Apple 的审核流程提了个醒——因为智能体很快可能就能自主发布成千上万款 App。App Store 上架的应用数量已经出现了增长，但如果智能体能够完全自主地开发和发布应用，提交数量可能会急剧增加。
智能体的配置
我们使用 OpenClaw 作为智能体框架，并启用了 Claude Opus 4.6 配合 adaptive thinking。6 选择 OpenClaw 是因为它可配置性好，与浏览器集成顺畅，并且原生支持长时间运行的任务。鉴于它近期热度较高且支持多种长时间任务，我们也想评估它作为框架的能力，以便未来与其他框架进行比较。（需要说明的是，我们只是把它当作一个通用框架来使用；除了对其进行提示并赋予它对 macOS 虚拟机更深的访问权限外，并没有对 OpenClaw 的默认设置做任何改动。）
我们还想测试智能体在视觉推理和 GUI 操作任务上的表现，这些可能成为任务完成的瓶颈。根据用户的使用反馈，OpenClaw 能够在一定程度上应对这些问题，我们希望验证这一能力。
我们也认识到 OpenClaw 在实际使用中存在安全风险。但我们仍然选择使用它，因为我们希望评估能力前沿，同时意识到安全性可能是其大规模实际部署的瓶颈。
该智能体可访问一台拥有较高权限（包括 sudo、屏幕可见性、UI 控制）的 macOS 虚拟机来执行任务。我们记录了智能体的全部操作、推理链，并保存了它在解题过程中截取的屏幕截图。
应对"评测感知"问题
大模型常常能识别出自己正在被评估，并相应地调整行为，这种现象被称为"评估感知"。Anthropic、Apollo 和 OpenAI 最近的研究 表明，前沿模型正越来越多地自行检测评估场景，有时还会据此改变自身行为。
那么应当如何应对评估感知？我们认为，试图向前沿模型隐瞒评估场景越来越不可行——每一代新模型都在更好地识别测试环境。而且我们计划定期开展 CRUX 评估并公开发布评估计划，未来的智能体完全可能在执行任务的过程中接触到关于这些评估的描述。
更重要的是，评估感知带来的担忧在衡量对齐相关特性时最为突出，因为模型可能刻意改变行为。而对于能力评估来说，只要智能体完成了任务，无论它是否知道自己正在被评估，能力都已经得到了证明。
为了应对评估感知，我们明确告知智能体它正在接受评估。这样做的好处是可以清晰地传达评估的各项参数：特别是告知它评判标准包括它请求不必要的人工输入的次数，但某些类型的输入（例如解决 CAPTCHA 验证码）则完全可以委托给人类。我们担心，如果没有这样的说明，智能体可能会在该求助时也不求助，从而导致我们低估了它的真实表现。
开展试运行
在正式启动完整评估之前，我们进行了两次试运行，以检验智能体配置是否运转良好，以及识别需要改进的地方。这帮助我们发现并修复了脚手架中的若干 bug。需要说明的是，这些试运行未涉及与 Apple App Store 提交或审核流程的任何交互。
配置 OpenClaw 智能体使其拥有所有权限、能够自主开发应用，同样需要我们这边的投入。据估算，搭建智能体脚手架花费了我们约 8 人时和约 50 美元的 API 费用；其中包括配置虚拟机以确保智能体能完全掌控并执行任何操作、设置日志来监控智能体的工作，以及为智能体配置可用的邮箱账户、GitHub 账户和 Apple 开发者账户。
这一过程可能会成为智能体自主开发应用的瓶颈。但从潜在垃圾应用发布者的角度来看，只需执行一次即可。花几个小时人力和 50 美元搭建好整套流水线，对于那些想要向 App Store 提交成千上万应用的垃圾发布者来说，显然算不上瓶颈。
在试运行中，智能体主要使用了命令行和浏览器。它通过命令行生成代码、构建应用，并完成提交前的准备工作；通过浏览器登录 App Store Connect、获取证书以及填写表单。当命令行因请求权限而卡住时，它能够截取屏幕截图并模拟鼠标点击，例如点击"允许"来为自己授予权限。
最终评估
经过两次试运行后，我们启动了完整评估。智能体耗时 45 分钟开发了一款简单的呼吸训练应用，涵盖了应用开发、通过 GitHub Pages 发布隐私政策、填写 App Store 审核表单以及提交审核等环节。
我们设置了智能体在应用提交审核后，每 5 分钟检查一次应用状态。但该应用花了 10 天才通过审核，目前已上架 App Store。（为遵守 Apple 的政策，智能体在发布应用前需要获得我们团队的批准。）
该代理需要一次不必要的人工干预7：它无法找到我们之前提供给它的、用于访问 Apple 开发者账号的凭证。8此外，它在提交给 Apple 审核流程的电话号码上弄虚作假，使用了一个虚构的号码，而不是向我们询问正确的电话号码；尽管存在这个错误，App Store 审核还是通过了。9这让我们意识到有必要主动监控代理的行为，以防止此类意外行为，我们计划在未来的 CRUX 评估中实施这一措施。最终的应用程序运行良好，尽管里面有一个无法正常工作的声音开关。该代理还为 App Store 列表生成了一张带有明显格式错误的截图。
该代理最终成功发布了该应用，总成本约为 1,000 美元。应用的开发和提交成本仅约 25 美元；绝大部分 tokens 被消耗在查找更新以验证应用是否已成功通过审核上。我们认为，如果我们对脚手架进行效率优化（例如降低代理唤醒频率以检查应用状态），总成本可以大幅降低，但在本次评估中，我们倾向于设定更高的预算。10
简而言之，该智能体虽未能完全自动化完成这项任务，但已极为接近。因此，我们在结果发表前四周通知了苹果的产品安全团队，认为有必要进行一定程度的负责任披露 —— 垃圾信息发送者很快就能借助智能体向 iOS App Store 批量提交应用。
开放世界评估的启示
通过运行 CRUX 以及梳理不断增长的同类工作，我们开始梳理出使开放世界评估富有信息量的关键要素。我们预计这些认识会随时间推移而演进，但现在分享出来仍有价值，因为这类评估正受到越来越多的关注，尽早形成共同的评估规范是有益的。
明确说明你在测量什么，以及这些测量意味着什么。人们对 Anthropic 的 C 编译器项目或 Cursor 的浏览器产生截然相反的看法，一个原因就在于这两个项目并未清晰界定其测量目标。从衡量智能体能否在长时间内高效完成明确定义的任务这一角度来看，这些成果确实令人印象深刻。但从开发可直接供终端用户使用、切实有用的软件这一角度来看，它们或许就没那么亮眼了；这两个项目的 GitHub Issues 中都反映出了核心的技术问题，比如开箱即无法编译"hello world"，以及使用标准构建脚本时欢迎页面卡死。如果作者们事先明确说明他们测量的是前者而非后者，本可以澄清围绕这些项目的公开讨论。（这并非批评这些项目的作者。他们是最早开展开放世界评估的团队之一，而要预先判断外界的反应本就很难。）
例如，软件开发涉及许多非功能性需求，如质量、可靠性、可维护性等，而开发者在交付由 AI 智能体自主编码构建的应用时，可能会牺牲这些属性。对 Cursor 的浏览器和 Anthropic 编译器的诸多质疑，本质上正是对这些难以明确界定的属性未能得到满足的担忧。
设计任务时，让人工介入简单可行且有据可查。在真实任务中，智能体有时需要外部帮助，比如绕开策略拒绝、验证码或基础设施故障等。传统基准测试无法支持人机协作，但在开放世界评估中，这类人工输入有助于我们衡量能力的上限。这要求精确记录人工介入的时机、原因和方式，从而能够清楚地评估智能体的自主程度。
重视日志分析。智能体执行复杂任务时产生的日志包含的信息远多于简单的成败结果，能帮助我们发现仅看结果无法察觉的智能体行为细节。例如：智能体如何拆解问题？是否在某个环节卡住，又是如何自我修正的？它是以有条理还是随意的方式探索各种解法路径？任务中哪些环节最具挑战性？智能体是否在产出和进度上有任何失实陈述？
考虑将日志分析与实时监控相结合。事后日志分析虽有价值，但单靠它不足以捕捉所有非预期的智能体行为。以往的开放世界评估表明，拥有较高自主性的智能体有时会采取事后难以被人审查者发现的操作。例如，AI Village 开展的许多 AI 实验中，智能体出现过非预期行为，比如试图发送数百封未经请求的邮件。在我们自己的评估中，智能体曾编造了一个虚构电话号码，直到后续审查才被发现。自动化实时监控（例如部署另一个智能体持续审查主智能体的操作，并在异常或错误发生时及时标记）可以作为人工审查的有力补充。
在开放世界实验前进行试运行。在正式评估前，先测试智能体的脚手架、评估标准和基础设施，有助于发现任务中隐藏的假设条件以及脚手架本身的错误。我们在 iOS 应用开发任务前的试运行中，就在正式启动前发现了脚手架的多处问题。
衡量成本。对于许多任务来说，能力会随着预算增加而持续提升。开发者应将成本测量视为开放世界评估的首要目标，并将预算与发现一并报告。即便无法对能力上限做出总体性判断，只要能衡量部分进展，也有助于了解增加预算是否有助于推动任务完成。
发布运行日志。虽然开放世界评估难以复现，但收集并向社区广泛发布日志仍有价值。例如，外部研究者可以补充对智能体表现及失败原因的分析，并验证结果。
我们计划定期开展新的 CRUX 评估。未来的 CRUX 将涵盖更广泛的主题，包括 AI 研发任务、AI 治理、视频生成以及更具挑战性的软件工程任务等。我们计划持续更新 cruxevals.com，分享我们团队以及更广泛社区在开放世界评估方面的工作。
作者贡献与致谢
核心团队：Sayash Kapoor 和 Arvind Narayanan 提出了项目构想并设计了首个评估任务。Andrew Schwartz 主导了智能体开发并执行了评估。Peter Kirgis 主导了日志分析以及开放世界评估的文献综述。Stephan Rabanser 在任务设计、文章撰写以及对结果的分析和解读方面提供了反馈与建议。Sayash Kapoor、Peter Kirgis、Andrew Schwartz、Stephan Rabanser 和 Arvind Narayanan 共同撰写了本文。