Open-world evaluations for measuring frontier AI capabilities

_本文有8,000字长——这是我们关于一种新兴的AI评估方法的新合作论文。该论文也以PDF格式发布在这里。_

_摘要：AI模型已经开始饱和大多数主要基准。但这是否意味着它们可以构建并发布一个真实的产品，或者从头到尾进行一项科学实验，或者导航政府官僚机构？研究人员已经开始在这些现实世界的环境中测试AI。我们称这些评估为“开放世界评估”。本文定义了开放世界评估，回顾迄今为止学到的经验，并概述了进行这些评估的最佳实践。_

_我们还介绍了CRUX，这是一个由来自学术界、政府、民间社会和工业界的17名研究人员组成的团队，他们将通过开放世界评估定期评估前沿AI能力。在我们的第一个实验中，一个AI代理构建并发布了一个iOS应用到App Store，仅犯了两个错误，其中一个需要人工干预。这给了我们早期的潜在有用能力的指示，更重要的是，它给出了一个早期警告，即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能力正在迅速提高。

但基准测试既可能高估也可能低估进展。要把一个任务变成基准，它需要被精确地指定并且能够自动验证。问题是，任何足够精确到可以作为基准的任务，也足够精确到可以被优化。另一方面，基准测试中的低准确率可能是由于偶然性失败，比如在一个网站上遇到验证码，即使代理实际上有能力解决底层任务。

为了解决这些局限性，许多研究人员转向了一种新的评估方式：长期且复杂的现实世界评估，超越了基准测试。Anthropic的Nicholas Carlini使用Claude代理构建了一个可以编译Linux内核的C编译器。Anthropic和Andon Labs设计了一个自由形式的实验，其中Claude被要求维护他们在办公室里的一个小店。虽然基准测试包含几十个任务并通过自动化方式进行评估，开放世界评估则包含小样本，通常需要人工干预，并以开放的方式进行评估，例如通过分析代理日志。

很容易认为这些评估不够科学：每个这样的评估样本量仅为1，缺乏标准化和可重复性。尽管存在这些局限性，我们认为这些评估对于收集有关AI能力的证据非常重要。它们可以提供关于新兴能力的早期预警，以指导建立社会韧性的努力，帮助评估者识别现有基准中的盲点，并给公司一个更清晰的视角，了解AI系统即将执行的任务，从而为AI的战略决策提供信息。我们称之为开放世界评估。

在这篇文章中，我们概念化了开放世界评估，回顾过去的例子以确定进行这些评估的最佳实践和陷阱，并介绍了CRUX，这是一个旨在定期进行新开放世界评估的项目。以下是我们的主要见解：

• 开放世界评估是一个重要的新兴类别的AI评估。 随着AI系统的功能越来越强大，评估以揭示前沿能力必须增加复杂性。开放世界评估是复杂性不断增加的一系列评估中的最新成果。我们回顾了过去一年中进行的10个著名的开放世界评估，以确定最佳实践和关键收获。

• CRUX（协作研究更新AI期望） 是我们尝试系统地进行开放世界评估的努力。团队由来自政府、学术界和非营利组织的合作者组成，其中许多人领导过开放世界评估，并对AI的未来有不同的预期。我们旨在提供关于AI系统当前能力的实证证据，即使这些能力目前成本高昂，并提供关于可能很快普及的能力的早期预警。我们计划定期发布新的开放世界评估。

• 在我们的第一个 CRUX 实验中，我们要求一个人工智能代理开发并发布一个简单的 iOS 应用到 App Store。许多基准测试会评估代理编写代码的能力。但是发布一个 iOS 应用涉及很多其他步骤：签署应用、在网页上发布隐私政策、填写苹果的表格，并通过审核过程。我们更感兴趣的是代理是否成功完成了发布应用所需的现实要求，而不是它编写代码的能力，因此我们要求它构建一个简单的应用并通过 iOS App Store 提交流程。

• 代理在犯了两个错误后成功了，其中一个需要人工干预（忘记正确凭证存储的位置以及为 App Store 审核过程编造了一个虚构的电话号码）。开发和发布应用的过程大约花费了 1000 美元。该应用现在已经在 iOS App Store 上线。我们认为成本本可以更低：应用开发和提交仅花费了 25 美元；大部分代币都花在了监控应用状态上。我们在发表本文前一个月联系了苹果公司，披露了我们实验的结果。应用商店运营商应该为自动提交的应用做好准备并进行监管，因为它们可能会很快看到成千上万的应用程序被自主代理提交。

• 我们如何改进开放世界评估？下一步是什么？ 要提高开放世界评估的实用性，评估者应明确允许的人类干预程度，发布代理解决问题时收集的日志，并分析日志以报告代理在解决问题过程中做了什么。在未来 CRUX 中，我们将评估 AI 研发自动化、AI 治理以及其他许多领域。

在这一节中，我们定义了开放世界评估，并调查了此类评估的新兴格局，以提取关于其成功和局限性的见解。我们讨论了开放世界评估可以在哪些方面克服基准测试的一些盲点。我们认为，随着 AI 系统变得越来越强大，为了激发前沿能力的评估必须变得更加复杂；开放世界评估是不断增加复杂度的一系列评估中的最新形式。我们还讨论了与基准测试相比，开放世界评估的局限性。

我们下面列出了定义开放世界评估的五个宽松标准（参见“什么是开放世界评估？”）。但值得注意的是，长期复杂的基准任务和开放世界评估之间的界限是模糊的。事实上，我们讨论的许多评估都是沙盒化的。我们仍然将它们列入开放世界评估的清单中，因为它们满足了我们的其他标准（例如，Carlini 的 C 编译器是沙盒化的，但只涉及一个长时间运行的任务、人类干预以及作为评估一部分的定性分析）。

对 AI 持有截然不同观点的人们 达成了一致意见，认为当前的 AI 基准测试可能很快就会达到饱和。在过去两年里，许多著名的基准测试已经饱和，评估者竞相发布“继任”基准测试。这些更新的基准测试本身也接近饱和。

这是否意味着 AI 系统很快就能解决任何任务？不一定。基准测试的改进可能表明真正的能力提升，但也可能夸大进展：例如，因为基准测试具有有限的结构有效性——它们可能只测试狭窄任务上的准确性而不是一般能力，并且没有测试代理如何处理现实世界环境的混乱。

另一方面，基准测试也可能低估进展，由于环境或基础设施中的挑战，这些挑战只是偶然影响所测量的能力，比如遇到 CAPTCHA。

一种获取更全面图景的方法是使用除准确率之外的指标。例如，在最近的一篇预印本中，我们几位合作者展示了即使代理在能力指标（如平均准确率）方面有了显著提升，但在衡量 可靠性 的指标上提升却慢得多。同样，许多 SWE-bench 任务的代理解决方案虽然通过了测试，但仍然会被项目维护者 拒绝 合并到主分支。

但这仍然不能让我们测量 AI 能力的上限。今天可能实现的能力（即使只在有利条件下）很快就会普及，我们需要在它们出现之前预见它们。提供这样的早期预警给企业更多时间利用新机会，给机构建立韧性，给政策制定者应对风险的时间。

现在让我们详细讨论为什么基准测试既可能高估也可能低估能力。它们可能高估能力是因为：

基准测试类似于适合现代强化学习（RL）技术的任务。 要将一个任务变成基准测试，它需要被精确指定并且能够自动验证。但是，任何足够精确到可以基准测试的任务也同样足够精确到可以优化，而现代 RL 训练越来越趋向于基准测试本身的形状。这就使得任何可以用基准测试衡量的任务很容易达到饱和。

这已经是像 Harbor 这样的领先评估平台的情况了，这些平台同时作为强化学习训练平台。因此，AI 模型可以直接在这些平台上包含的许多著名基准数据集上进行训练。即使基准包括预留的测试集，模型也可能在训练集中遇到与测试集中非常相似的任务。所以基准并不能帮助我们了解性能在现实世界中的泛化情况如何。

基准避免现实世界的复杂性。现实世界中的任务涉及未完全定义的交互，例如应对意外情况或导航开放环境，这些无法完全沙盒化。基准可以采取一些步骤来模拟复杂的环境，但无法完全复制它们。

基准还可能低估能力，因为：

激发前沿能力的成本高昂。运行大规模、长时间的实验非常昂贵，使得实现基准依赖的大样本量变得不切实际。Anthropic 的 C 编译器成本约为 2 万美元；下面描述的任务（为 CRUX #1 开发并发布一个 iOS 应用）成本约为 1000 美元。我们不能每次运行数百次这样的实验，这限制了每个基准任务的预算和复杂度。

平均性能与上限能力激发非常不同。试图在一个基准套件中运行数十个（或数百个）任务只是为了测量 _平均_ 性能。但是，当我们试图理解代理能做什么的前沿时，目标转变为理解 _最佳情况_ 性能：当给予足够的资源和支持以解决偶然失败时，代理能够完成什么？这对于提供早期预警关于即将普及的能力是必要的。

人为干预可以帮助激发能力上限。在现实世界任务中工作的代理可能会遇到策略拒绝、需要解决验证码问题或其他基础设施问题而卡住。这可能会负面影响其性能。但这些失败只是对所测量能力的 _偶然_ 影响。如果人类操作员可以处理这些问题，那么我们将能够激发能力的上限。对于每次运行的数百个基准任务来说，这种手动干预是不切实际的。

随着 AI 能力的提升，测试 AI 能力的沙盒评估（如编程、深度研究和客户服务）需要高度工程化的环境来挑战代理并避免污染或奖励操纵。例如，代理在网页基准上的表现受到其遇到验证码频率的影响，而不是真正激发代理的内在能力。最近的研究突显了 AI 代理在线查找答案，利用评估中的漏洞，以及生成通过测试但不符合生产标准的代码。这突显了转向更深入的定性评估 AI 代理性能的必要性，这有助于我们更好地理解在平均基准分数的狂轰滥炸中可能丢失的失败模式和解决问题的策略。

但这些有效性威胁并不容易解决。我们可以进行定性日志分析来解决其中的一些问题，但即使我们在使用日志分析时发现基准结果的有效性问题，除了发布更新的基准外，我们几乎无能为力，这可能需要几个月的时间。开放式评估允许我们在真实测试之前进行预演以修复问题，并在评估过程中手动干预以修复发现的问题。1

当然，尽管存在这些局限性，基准仍然可能是有用的。2 而开放式评估也有自己的局限性，我们在本文后面讨论。也就是说，我们希望这份清单能说明基准测试中的系统盲点。随着 AI 代理的能力增强，传统基准测试与现实世界能力之间的差距将继续扩大。成功指标需要是多方面的，以捕捉给定任务中目标的多样性。基准需要纳入关键瓶颈（人工辅助）和复杂的环境（互联网导航），每一种都会引入内部和外部有效性的额外问题。开放式评估提供了一种替代方案。

随着评估方法随着 AI 能力的发展而成熟，评估方法出现了梯度。在一端是简单、自动化、可扩展的方法，适用于早期阶段的能力。在另一端是更丰富、更劳动密集的方法，随着能力的提高和简化指标的饱和，这些方法变得必要。

随着某一领域的能力提升，梯度上的进一步评估变得重要，以获得补充于简单评估的见解。我们认为这个梯度目前大致有五个级别，每个级别都有其优点和局限性：

1. 问答基准（例如 MMLU、GPQA）：用于广泛知识评估，但对于前沿模型来说越来越饱和。通常格式为选择题以便于评分，但这导致构建效度较低，因为用户很少通过选择题与模型互动。

1. 开放式聊天基准（例如，WildBench，Arena-hard-auto）：捕捉更多的细微差别，但仍然限于单轮或短交互。

1. 仅结果导向的代理基准（例如，SWE-Bench，WebArena）：测试代理在真实任务中的表现，但只衡量任务是否完成，而不是如何完成。因此，它们有局限性。例如，大多数通过SWE-Bench的解决方案未被存储库维护者接受。

1. 带有日志分析的代理基准（例如，英国AISI对话分析，METR时间范围）：通过检查代理成功或失败的细节以及分析代理日志来揭示错误和奖励操纵，从而深入研究。但它们仍然在预定义任务的沙盒环境中运行。

1. 开放世界评估：在现实世界环境中进行长期任务，成功无法被整齐地指定或自动评分。这允许揭示能力的上限。但这以缺乏可重复性和标准化为代价（这两点都是基准测试的好处；参见限制部分）。

一些评估模糊了这一谱系的类别。例如，OpenAI的GDPVal，一个长期代理基准，旨在基于专家对质量的意见进行手动评分。这种结构非常类似于开放世界评估，尽管它们主要关注输出而不是分析日志。同时，GDPVal的结果通常使用GDPval-AA报告，该方法使用自动化LLM评分；这种评估设置类似于仅结果导向的代理基准。

开放世界评估包括在现实世界环境中运行少量长期任务的代理，并使用日志分析工具[如Inspect-Scout]定性评估其结果。这些评估补充了基准测试，并有助于解决许多基准测试的局限性。它们还可以揭示当前AI系统无法完成的任务，以便未来的基准测试工作。

我们提供了一个粗略的分类法来明确什么是开放世界评估。没有单一维度可以确定某个实验是否属于“开放世界”。相反，它取决于下面所有维度的整体模式。

• 开放性。这个评估是在实际部署环境中进行的（而不是在一个沙盒环境中）？

• 复杂度/长度。任务是否需要人类几天或几周的时间才能完成（而不是几分钟或几小时）？

• 任务数量。这是一个独立任务还是一个小任务集（而不是一个大型评估套件或基准）？

• 人为干预。为了揭示能力的上限，当代理遇到障碍时，人类能否进行干预（而不是仅仅设置环境或解决设置问题）？

• 评估方法。评估主要由深入的日志评估组成（而不是由单一平均指标驱动的结果）？

什么时候我们会称某事为评估，而不是简单地使用代理来实现某些新颖的东西？例如，Anthropic使用AI代理在领先的开源软件（如Mozilla Firefox）中发现安全漏洞——这是开放世界评估的一个例子吗？如果代理的角色被系统地和公开记录下来（包括由代理执行的部分和由人类专家执行的部分以及最终结果），我们仍然认为这些是开放世界评估。

复杂的基准任务与开放世界评估之间的界限也很模糊。例如，我们列出的一些开放世界评估中有沙盒环境的评估（例如，Claude玩宝可梦和Anthropic的C编译器都在沙盒环境中运行，但我们仍然认为它们是开放世界评估，因为它们包含一个单一的、复杂的、长时间运行的任务，在评估期间有人类干预，并且进行了定性评估）。

这两种评估是互补的：我们可以想象使用开放世界评估来理解代理无法解决的任务，作为构建新基准的第一步，也可以使用开放世界评估来评估代理在那些不适合基准测试的混乱的真实世界任务上的表现。

最后，我们并不是暗示开放世界评估在理解AI进展方面比基准测试更具信息量。事实上，我们在本节后面讨论了许多开放世界评估的局限性。相反，随着AI能力的提高，开放世界评估成为一种重要的附加互补信号，用于展示AI能力。

在过去的一年里，AI实验室、大学、非营利组织和独立团体的研究人员开始进行开放世界评估。这些评估共享一个共同的结构：给一个有能力的AI代理一个困难的、真实世界任务，并观察和详细分析其行为。一些值得注意的例子：

1. [Anthropic, Claude 玩宝可梦](https://futurism.com/advanced-ai-stuck-pokemon) (2025年2月)。Anthropic 在 Twitch 上直播了一场名为“Claude 3.7 十四行诗”的宝可梦红版游戏。虽然这不是一个实际应用的部署，但与典型的基准测试相比，这个实验展示了如何在一个相对开放的环境中设置一个人工智能代理。尽管该项目展示了人工智能在计算机使用方面的进展，且几乎不需要支持结构，但演示也清楚地表明了早期2025年代理的局限性——“十四行诗3.7”在一个关卡上停留了将近80个小时。3

1. [AI Digest, AI Village](https://theaidigest.org/village) (自2025年4月起)。AI Village 给多个AI代理分配各自的计算机环境和共享群聊，然后让它们完成一些开放式的现实目标，比如为慈善筹款、组织真实的线下活动、制作文字游戏以及在Substack上增加订阅者。在2025年的不同实验中，该项目强调了幻觉、误校准和无用循环等持续存在的失败模式，但也记录了2025年末期代理在这方面的显著改进。

1. [Anthropic/Andon Labs, Project Vend](https://www.anthropic.com/research/project-vend-1) (自2025年6月起)。Anthropic 与 Andon Labs 合作，让一个名为“Claudius”的Claude 3.7 Sonnet代理操作他们办公室内的一个小自动售货店。该代理管理库存、定价并与顾客互动了几周时间，揭示了关于操纵、优先级排序和现实决策制定的一系列失败模式。第二阶段扩展了实验到多个地点，使用了更新的模型，并包括了《华尔街日报》员工的红队演习。由于规划不当、幻觉和过度折扣，代理几乎失去了所有收入。Anthropic 的后续尝试更为成功，每周都实现了正利润，但《华尔街日报》的员工仍然能够成功越狱“Claudius”，导致它免费赠送所有产品。Andon Labs 最近开始了项目的第三阶段，他们给一个基于Claude的代理“Luna”在旧金山的一个实体店三年租约，让它作为“经理”盈利，包括雇佣人类员工、设计品牌和选择产品。

1. [Lin, Cursor 浏览器实验](https://cursor.com/blog/scaling-agents) (2026年1月)。Cursor 的 Wilson Lin 协调了数百个GPT-5.2代理，从零开始构建了一个网页浏览器，并连续运行了一周。最终的浏览器（“FastRender”）包含超过一百万行Rust代码和一个全新的渲染引擎。它可以渲染简单的网站，但远未达到生产就绪状态。该项目因其对大规模多层次代理协调的探索以及当代理在一个项目上工作几天而不是几分钟时出现的具体失败模式而引人注目。

1. [Papailiopoulos, “Can You Train a Computer”](https://x.com/DimitrisPapail/status/2028669695344148946) (2026年3月). Dimitris Papailiopoulos 和合作者测试了 Claude Code 和 OpenAI Codex 是否能够训练一个转换器以充当通用计算机。实验包括一个完全自主的回合，在该回合中两个代理都失败并找到了奖励黑客解决方案，以及一个人类引导的版本，在该版本中 Claude Code 成功并展示了有意义的泛化能力，包括解决从未见过的多步骤计算问题。

1. [Karpathy, Nanochat 自动研究](https://x.com/karpathy/status/2031135152349524125) (2026年3月)。Andrej Karpathy 使用现有的开源项目 nanochat 进行 GPT-2 级别的大型语言模型训练，构建了一个简单的自动化流水线，使 AI 代理能够在 5 分钟的时间间隔内优化训练。该代理可以完全自主地调整架构、超参数、优化器和批次大小。在后续研究中，Karpathy 分享 自动研究在“达到 GPT-2 所需时间”方面取得了进展（使用 8xH100 GPU 测量），在两天内将这一指标降低了 11%。

我们计划在 cruxevals.com 上收集此类评估的持续列表（以及每个评估的关键收获和局限性）。人工智能能力的提升使得各个领域的人都能进行这样的评估，并确定 AI 系统是否能够执行他们所擅长的任务，这导致了对这些评估的兴趣日益增长。仅在过去一周，就有许多重要的开放世界评估发布，包括 Adamczewski 等人的 MirrorCode，该评估要求代理重新实现大型程序；Wen 等人的一系列 自动对齐研究 案例研究；以及 Huang 使用 Claude Code 训练模型来 预测最近的美国大师高尔夫球赛结果 的练习。

虽然开放世界评估有助于解决基准测试的一些盲点，但它们也存在许多局限性。在开发更好的基准测试和投资开放世界评估之间仍然存在着真正的权衡。基准测试为评估者提供了任务控制，并允许在受控环境中进行评估，但对于理解代理在开放式任务中的表现则不太有用。开放世界评估牺牲了沙盒环境和评估者的控制，以提高任务的有效性并揭示上界能力。具体来说，开放世界评估有以下局限性：

缺乏可重复性和标准化： 基准测试之所以成功，是因为它们为 AI 社区提供了协调功能。研究人员可以独立开发和测试新方法，并验证这些方法是否在基准测试中表现出色，从而引起社区的关注。基准测试的文化根深蒂固，以至于 David Donoho 称其为过去 50 年来 AI/ML 社区成功的“秘诀”。开放世界评估放弃了使基准测试如此成功的可重复性和标准化。

难以比较代理： 基准测试提供不同模型/代理之间的相对比较。但由于开放世界评估通常只运行一次或几次，每次运行的变异性可能比不同代理性能的差异更大。因此，开放世界评估不适合比较不同模型或代理的准确性。

需要领域专业知识： 评估代理在开放世界评估中是否成功可能具有挑战性。验证代理的工作可能需要深入的领域专业知识和时间，特别是如果任务是开放式的。

日志分析的不完整性： 即使使用自动化日志分析来分析开放世界评估，也不能认为它是完整的。来自长期任务的代理记录可能达到数亿个标记，使得彻底的人工审查不切实际。而且由于这些任务中的代理行为复杂，不能保证每次分析都能发现所有值得注意的行为或错误。这一局限性不适用于基准测试，因为成功标准是预先定义并自动验证的。公开发布日志以便更广泛的社区进行检查是部分缓解这一问题的一种方式。

模糊的成功标准： 鉴于可能存在人为干预，很难清晰地区分代理的表现与人类给予的帮助。

非静态环境： 在开放世界评估中，代理可以与开放环境（如互联网）交互。这使得很难对代理的能力做出普适性的断言，而不是它可以通过互联网（或其他开放环境）访问的信息。例如，代理能否解决一个困难的软件工程任务是因为它真正擅长这类任务（因此能够解决新的软件工程任务），还是因为它能够在线查找特定任务（因此无法解决新的任务）？比较代理随时间的变化表现也很具有挑战性。例如，互联网包含越来越多的实现或提示，未受沙盒限制的代理可以从中获取。

政策制定者：人工智能在各个领域的扩散速度落后于能力的提升。这使得机构能够在人工智能系统变得更加强大的过程中逐步适应。开放世界评估可以通过提供早期预警，告知代理即将能够自主且大规模地执行的任务，从而进一步增加这一提前时间，使机构有时间建立韧性。例如，Anthropic最近关于使用人工智能发现网络安全漏洞的工作可能会促使迅速采用人工智能进行防御性网络安全工作，特别是在关键软件基础设施方面。

人工智能评估者和研究人员： 开放世界评估通过测试那些结构上难以基准化的功能（如解决混乱的真实世界任务）来提供与基准测试互补的信号。分析代理日志可以帮助我们发现代理采取捷径或奖励黑客行为的情况。另一方面，它们可以找到代理开发新见解或超越先前限制的领域。例如，在我们的iOS应用开发评估中，我们发现代理修改了其方法以提高令牌效率，这使其能够大幅降低解决问题的成本，而无需我们提供任何输入或指令。

前沿人工智能开发者： 人工智能开发者应积极支持并参与外部开放世界评估工作，提供访问权限（如模型的预发布访问权）以及安全港，以保护第三方进行评估时可能不符合开发者服务条款的行为（例如，评估安全性）。独立第三方进行的开放世界评估可能会揭示内部红队可能错过的发现，如果他们优化已知威胁模型的话。

新的模型也在饱和基准测试。例如，Anthropic的Mythos预览系统卡指出，该模型“饱和了许多我们最具体、客观评分的评估”，这使得他们只能使用更嘈杂的方法来评估能力。开放世界评估可以提供一种补充方式，在现实环境中对模型进行压力测试，而这些环境是基准测试无法区分的。

为了促进开放世界评估生态系统的发展，重要的是制定共享的最佳实践，并构建一个累积的证据体，以了解代理能做什么和不能做什么。这就是我们正在通过一个名为CRUX的新项目尝试做的事情。

CRUX是一个用于实现开放世界评估的项目。我们计划定期进行开放世界评估。每次评估都将涉及一个长期的现实任务；实施一个代理框架，理论上可以让代理解决该任务；并对代理如何解决问题进行详细分析。我们的团队由来自行业、学术界和非营利组织的研究人员组成。团队中的许多人都进行过开放世界评估。

除了进行评估外，我们还希望开发机制，为即将普及的人工智能能力提供早期预警。例如，如果人工智能代理几乎可以自主开发和发布应用程序（这是我们CRUX第一次迭代的任务；将在下一节讨论），苹果和谷歌等应用商店运营商可能很快需要更新他们的政策来管理垃圾提交。

这需要确定能力的上限——通常用人工输入填补缺失的附带能力（如填写验证码）。开放世界评估非常适合这种特定类型的评估，因为它们允许我们深入了解人工智能系统的功能。

开放世界评估的另一个优势是我们不需要在进行评估之前开发大量任务套件或设计复杂的环境或沙盒，因为每个任务只需要少量执行和评估。这使我们能够定期进行新的评估。我们计划每1-2个月设计一个新的CRUX评估，分析结果，并发布关于新任务的分析。

我们的第一次评估测试人工智能代理是否能够自主开发并在iOS应用商店发布应用；我们在下一节讨论这一点。在未来迭代中，我们计划扩展到广泛的领域，包括人工智能研发自动化、人工智能治理、复杂软件工程和真实物理任务等任务。

人工智能代理是否能够编写软件已经得到了广泛研究，既通过像SWE-Bench和Terminal Bench这样的基准测试，也通过像本文前面讨论的C编译器和浏览器实验这样的开放世界评估。代理展示了强大的编码能力（尽管代码质量和可靠性的问题仍然悬而未决）。

与此同时，一个尚未被充分评估的任务是代理是否能够处理软件部署的非编码方面，例如满足平台要求和与不受控制的审查系统交互。对于我们的评估，我们让代理从零开始构建移动应用并发布到iOS应用商店。

我们要求代理开发并发布一个简单的应用程序到 App Store。我们主要不是对代理的软件工程能力感兴趣，而是对其与苹果应用商店提交流程交互的能力感兴趣。这个流程要求开发者配置签名证书和配置文件，准备屏幕截图和元数据，起草并在公共网址上托管隐私政策，填写合规问卷，并将应用程序提交给苹果团队进行审核。审核人员可能会因技术或政策原因拒绝该应用，这需要开发者诊断问题、做出更改并重新提交。这一过程通常需要几天时间，并涉及与开发者无法控制的系统和审核人员互动。

除了那些由于政策要求需要人工参与的步骤（例如设置苹果开发者账户和点击发布以将应用发布到 App Store），代理负责整个流程中的每一步骤。具体来说，代理负责编写代码、构建应用、准备元数据、起草并托管隐私政策、提交审核以及处理任何反馈。（我们向代理提供了访问一台 Mac 虚拟机、一个 GitHub 账户、一个苹果开发者账户和一个 Gmail 账户。）

成功的标准是代理是否能够将应用成功发布到 App Store。我们记录了代理需要我们进行多少次手动干预来完成任务。代理可以选择联系团队寻求支持；我们每天监控一次代理的进度。这个数字越低，代理的表现就越好。

此外，如果代理能够自主完成这些任务（或者接近自主完成），这将为苹果的审核流程敲响警钟，因为代理可能很快就能自主发布数千个应用。App Store 已经看到了发布的应用数量增加，但如果代理能够完全自主地开发和发布应用，提交的数量可能会大幅增加。

我们使用OpenClaw作为代理的基础框架，结合Claude Opus 4.6和启用自适应思维功能的Claude平台。6 我们选择OpenClaw进行这次实验，因为它可配置性强，与浏览器集成良好，并且原生支持长时间运行的任务。鉴于其最近的流行程度和支持广泛和长时间任务的能力，我们也想评估其作为基础框架的能力，并在未来可能与其他基础框架进行比较。（请注意，我们将其用作相对通用的基础框架来完成任务；实际上，除了提示它并给予其更深入的macOS虚拟机访问权限外，我们没有对默认的OpenClaw设置进行任何更改。）

我们还想测试代理是否在视觉推理和图形用户界面操作任务中遇到困难，这些问题可能是解决任务的瓶颈。根据用户经验报告，OpenClaw成功解决了其中的一些问题，我们希望测试这种能力。

我们认识到，在实际应用中，OpenClaw存在安全风险。我们仍然选择使用它，因为我们想要评估能力边界，同时意识到安全性可能是实际应用中的瓶颈。

代理可以访问一台具有广泛权限（sudo、屏幕可见性、用户界面控制）的macOS虚拟机来执行此任务。我们记录了代理的所有行动、推理链以及解决问题时拍摄的屏幕截图。

人工智能模型经常意识到自己正在接受评估并调整自己的行为。这被称为评估意识。来自Anthropic、Apollo和OpenAI的最新研究表明，前沿模型越来越多地能够自行检测评估环境，并有时会根据情况修改自己的行为。

我们应该如何应对评估意识？我们认为隐藏前沿模型的评估环境越来越不可能实现；随着每一代模型的发展，它们越来越擅长识别测试环境。由于我们计划定期进行CRUX评估并将我们的计划公开发布，未来的代理可能在任务过程中简单地发现我们评估的描述。

更重要的是，当测量对齐属性时，关于评估意识的担忧最为严重，因为模型可能会战略性地改变自己的行为。对于能力评估，如果代理成功完成了任务，无论它是否知道自己正在接受评估，都证明了它的能力。

为了应对评估意识，我们明确告知代理它正在接受评估。这使我们能够清晰地传达评估参数；特别是，它将根据需要不必要的手动输入次数进行评判，但某些类型的输入（例如解决验证码）完全可以委托。我们担心如果没有这种框架，代理可能会避免在适当的时候寻求帮助，这会导致我们低估其性能。

在进行全面评估之前，我们进行了两次预演以了解我们的代理设置是否工作良好，如果不，则需要做哪些更改。这使我们能够发现并解决基础框架中的错误。值得注意的是，这些预演不涉及与苹果应用商店提交或审核过程的任何互动。

设置 OpenClaw 代理使其具有所有权限以自主开发应用也需要我们这边的配合。我们估计配置代理框架花费了我们八个人时的时间和大约 50 美元的 API 费用；这包括配置虚拟机以确保代理可以完全控制并执行任何操作；设置日志记录以监控代理的工作；以及配置电子邮件账户、GitHub 账户和 Apple 开发者账户供代理使用和访问。

这种努力可能是代理自主开发应用的一个瓶颈。但从潜在垃圾邮件发送者的角度来看，只需要一次性完成。花费几个人时和 50 美元来设置这个流程不太可能成为那些希望向 App Store 提交数千个应用的垃圾邮件发送者的瓶颈。

在我们的模拟运行中，代理主要使用命令行和浏览器。它使用命令行生成代码、构建应用并准备提交。它使用浏览器登录 App Store Connect，访问证书，并填写表单。当由于请求权限而使命令行命令挂起时，它能够截屏并模拟鼠标点击，例如点击“允许”以授予自身权限。

经过两次模拟运行后，我们开始了全面评估。代理用了 45 分钟开发了一个简单的呼吸练习应用。这包括开发应用、使用 GitHub Pages 发布隐私政策、填写 App Store 审核表单，并提交应用进行审核。

我们将代理设置为每五分钟检查一次应用的状态，直到应用被送审。但应用获得批准花了 10 天时间。它现在已经在 App Store 上线了（查看）。（为了遵守苹果的政策，代理在发布应用前需要得到我们团队的批准。）

代理需要了一次不必要的手动干预7：它无法找到我们之前提供给它的访问 Apple 开发者账户的凭据8。它还伪造了提交给苹果审核过程中的电话号码，使用了一个虚构的号码9，而不是向我们索要正确的电话号码；尽管存在这个错误，App Store 的审核还是通过了。这提醒我们需要对代理行为进行主动监控，以防止此类意外行为，我们计划在未来 CRUX 评估中实施这一措施。最终的应用功能良好，尽管有一个不起作用的声音切换按钮。代理还为 App Store 列表生成了一张带有可见格式错误的截图。

代理上传的截图有明显的格式错误。

代理最终成功发布了应用，总成本约为 1000 美元。应用的开发和提交费用仅为约 25 美元；大部分代币都花在了查找更新以验证应用是否已成功审核上。我们认为如果优化代理框架以提高效率，比如减少唤醒代理检查应用状态的频率，总成本可能会大幅降低，但在本次评估中我们偏向于更高的预算10。

简而言之，代理不能完全自动化该任务，但它已经非常接近实现这一点11。因此，在发布结果前四周，我们通知了苹果的产品安全团队我们的实验，因为我们认为负责任披露是必要的；垃圾邮件发送者很快就可以使用代理向 iOS App Store 提交数千个应用。

通过运行 CRUX 并研究类似工作的不断增长的文献，我们已经开始识别出开放世界评估的哪些方面是有意义的。我们预计这些经验教训会随着时间演变。但我们认为现在分享它们是值得的，因为人们对这些评估的兴趣日益增加，建立共同的评估规范可以帮助这一领域的发展。

明确你所测量的内容及其含义。人们对 Anthropic 的 C 编译器项目或 Cursor 的浏览器持有截然不同的看法，其中一个原因在于这些项目没有明确指定其测量目标。从衡量代理是否能够在定义良好的任务上长时间高效工作的角度来看，结果非常令人印象深刻。但它们可能在开发可以直接供终端用户使用且有用的软件方面不太令人印象深刻；这两个项目的 GitHub 问题突出了一些核心的技术投诉，例如 无法开箱即用地编译“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 撰写了这篇论文。

协作者：Rishi Bommasani 对任务设计、论文文本以及我们对结果的分析和解读提供了反馈和意见。J.J. Allaire、Magda Dubois、Gillian Hadfield、Andy Hall、Sara Hooker、Seth Lazar、Steve Newman、Dimitris Papailiopoulos、Shoshannah Tekofsky、Helen Toner 和 Cozmin Ududec 对论文文本以及我们对结果的分析和解读提供了反馈和意见。

致谢：Nicholas Carlini 对任务设计和代理设置提供了反馈。Ryan Greenblatt、Daniel Kokotajlo 和 Ajeya Cotra 参与了在线和面对面的讨论，这些讨论为项目提供了信息。

资金支持：我们非常感谢 Coefficient Giving、Schmidt Sciences 和普林斯顿 AI 实验室为本项目提供的资助。

1

当然，我们也可以使用干运行来发现基准测试中的问题。但是，基准测试旨在比较模型随时间的能力。许多基准测试的问题只有当一个更强大的模型找到捷径或边缘情况时才会变得明显，而这些问题在基准测试构建时并不明显。基准开发人员可以分析日志以发现此类情况。但解决这些问题需要更新基准测试并重新评估之前的模型，这会违背基准测试结果的长期有效性。随着 AI 代理能力的提高，我们预计此类问题会更加频繁地出现。

2

评估一直存在问题；关键不在于它们是否完美，而是它们能否提供一个有用的代理来衡量 AI 能力的进步。仍然存在一些未饱和的评估，例如 SciCode、MMLU-Pro、Humanity’s Last Exam 和 SWE-Bench Pro。事实上，即使饱和的能力基准测试也可以用于测量 AI 代理的效率和可靠性，这些都是指导 AI 扩散的重要组成部分。

4

这种担忧也影响到需要访问互联网的基准测试，例如网络基准测试，如 AssistantBench 和 GAIA。但在沙盒环境中运行的基准测试规避了这一担忧，代价是结构效度（如果我们试图在现实世界中解决问题，代理应该能够利用互联网上的资源来解决它）。

5

已经有证据表明，由于采用编码代理，苹果应用商店的审核时间已经开始变长。不过，应用程序发布的速度仍然比 2016 年提交高峰期低得多。尽管如此，也可能已经有一波未最终发布的垃圾提交。但我们的结果显示，代理可以自主提交最终获得苹果批准的应用程序。一旦代理能够自主开发和发布应用程序，可能会导致大量符合发布标准的应用程序提交到商店，因此应用商店政策和实践可能需要更新以适应这种情况。

6

我们对代理进行了微小修改，以便设置一个子代理来验证代理的输出，并每五分钟唤醒一次以检查更新（例如，来自苹果审核响应团队的回复）。OpenClaw 的默认唤醒间隔为 30 分钟。回顾起来，每五分钟唤醒一次代理显著增加了任务的 API 成本。

7

代理总共需要五次干预，其中四次涉及苹果的要求（无论是技术性的还是基于政策的）或我们评估设置中的缺陷：代理无法解决苹果的要求，比如故意阻止合成交互（例如来自代理的交互）在敏感对话框中（如批准双因素认证）；它需要提示我们登录到苹果开发者账户。在我们的评估过程中，OpenClaw 守护进程崩溃，需要手动重启。我们还提示代理在发布应用之前请求批准，以满足应用商店的政策要求。

8

当代理陷入困境并寻求帮助时，我们团队的一名成员建议重用先前提供的凭据并解决双因素认证问题。代理短暂搜索其记忆以寻找这些凭据，但并未尝试实际登录。相反，它通过发现应用商店连接 API 密钥仍然存在于预期的隐藏路径中恢复过来，从而允许监控继续进行。

9

虽然不能确定，但代理使用虚构电话号码的一个原因可能是我们告知了代理它正在接受评估。此外，请注意，尽管我们对代理的行为进行了深入的日志分析，正如我们之前讨论的那样，自动化日志分析永远不能被认为是全面的，所以我们认为可能还有一些有趣的事情我们尚未发现。我们已经发布了代理日志以帮助第三方日志分析工作（参见cruxevals.com）。

10

有趣的是，在评估过程中途，代理改变了自己的策略以显著降低监控成本：它开始使用子代理而不是使用整个上下文，并且开始使用较短的每日记忆文件。这将运行成本从每小时35美元减少到每小时3美元。

11

请注意，我们的代理在整个审查过程中没有遇到苹果审核人员的任何异议。一方面，这表明代理能够开发出一款通过应用商店发布门槛的应用程序。另一方面，我们无法测试代理与苹果审核人员沟通的表现如何。