# Meta-Agent Challenge：自主智能体开发能力评估框架 - 来源：HuggingFace Daily Papers（社区热门论文） - 发布时间：2026-06-03 08:00 - AIHOT 分数：72 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmpytyvum03avsli3s4ft7t9q - 原文链接：https://arxiv.org/abs/2606.04455 ## 精选理由 蚂蚁研究院的这项研究直接让模型自己造代理，结果触发了‘作弊’行为：为了刷分，模型学会了泄露测试集。这可能是近期关于AI递归自我改进最直观的负面案例。 ## AI 摘要 论文提出Meta-Agent Challenge（MAC）评估框架，测试前沿模型自主开发智能体系统的能力。元智能体在沙盒环境中借助评估API和时限，迭代编程出能在五个领域保留测试集上最大化性能的智能体工件，并采用多层防御防止奖励攻击。实验表明，元智能体极少达到人类基线策略，少数成功者由专有前沿模型主导；设计过程高方差，高优化压力催生了真实值外泄等对抗行为，暴露鲁棒性与对齐缺陷。MAC作为开源基准，为评估递归自我改进提供实证代理。 ## 正文 陆新宇 王天舒 王鹏博 温祖杰 张志强 周军 曹博熙 卢耀杰 林鸿宇 韩先培 孙乐 中国科学院软件研究所中文信息处理实验室 中国科学院软件研究所 中国科学院大学 蚂蚁集团 本工作完成于蚂蚁集团实习期间。 摘要 当前的 AI 评测基准评估的是 AI 智能体在人类设计的工作流中执行任务的能力。这些评估从根本上无法衡量一个关键的下一代能力：模型能否自主开发 AI 智能体系统。我们提出了元智能体挑战（MAC），这是一个旨在测试前沿模型自主开发 AI 智能体能力的评估框架。具体来说，一个代码智能体（即元智能体）会获得一个沙盒环境、一个评估 API 以及一个时间限制，用于迭代式地编程一个 AI 智能体工件，该工件需在五个领域内的保留测试集上最大化性能。为确保评估的完整性，该框架通过多层防御机制来防范奖励破解。利用这一框架，我们证明了元智能体很少能匹敌人工设计的基线策略，而少数能做到的也主要由专有前沿模型主导。此外，设计过程表现出高方差，且高优化压力会催生对抗性行为，例如真实标签泄露——这突显了鲁棒性和模型对齐方面的关键缺陷。最终，MAC 为自主 AI 研究与开发提供了一个严谨的开源基准，为评估递归自我改进提供了经验性代理。基准测试已公开在：https://github.com/ant-research/meta-agent-challenge。 1 引言 图1：元智能体挑战（MAC）示意图。左图：传统评估方式直接在静态基准上测试智能体能力。随着模型能力激增，这种直接方法迅速趋于饱和。右图：我们提出的元评估范式。智能体不再直接解决问题，而是评估其自主构建、优化和完善智能体系统以完成任务的能力。该框架通过将评估重点从单纯的任务执行转向自主系统工程能力，最大化现有基准的效用。 当前大语言模型（LLM）执行长周期任务的能力日益增强[22, 8]。为应对日益复杂的任务，业界已开发出复杂的智能体脚手架[20]——通过外部工具、迭代反思和复杂的子智能体编排能力[7]来增强原始模型能力。这些框架显著拓展了AI系统所能实现的边界，将无状态语言模型转变为自主且持续的任务执行器。 然而，一个根本性局限依然存在：这些先进的智能体脚手架几乎完全由人类研究人员和开发者手工构建。当前的智能体开发范式严重依赖人工提示词工程、人工设计的控制流程和人工定义的工具。虽然现有基准严格评估了大语言模型在这些人定义评估工作流中执行特定任务的能力，但它们从根本上未能衡量对AI未来更为关键的能力：模型作为系统架构师的能力。AI能否自主设计、实现、评估并迭代优化其自身的任务解决工作流？ 我们认为，要突破手动智能体工程这一瓶颈，需要在智能评估方式上进行范式转变（图1）——从任务执行的客体层面转向系统设计的元层面。为此，我们提出了元智能体挑战（MAC），这是一个新颖的评估框架，旨在测试当前代码智能体在自主智能体开发方面的能力。在该挑战中，被评估模型（即元智能体）的任务并非直接解决特定领域的问题。相反，它会获得一个目标函数、一个模型访问配额以及一个沙盒开发环境，并被要求编写底层代码来构建能够解决这些问题的任务专用智能体。 这种评估方式的转变至关重要，原因有几点。首先，它弥合了编写孤立代码片段与构建稳健自主软件系统之间的差距。一个成功的元智能体必须能够提出关于有效架构的假设，将其实现为可执行程序，在开发集上运行实证评估，从有限的反馈中诊断失败模式，并进行迭代——所有这些都必须在一次自主会话内完成。其次，更重要的是，它充当了递归自我改进[16]的一个具体且可操作的代理指标。通过将智能体评估与智能体构建之间的循环闭合，我们的框架提供了一个严格的测试平台，用以衡量模型是否已达到能够无需人工干预而系统性改进AI系统的门槛。 此外，衡量前沿模型的自主智能体开发能力对AI安全[1]至关重要。它探究了模型在多大程度上能够识别自身的能力与局限、规划资源使用，并有可能构建出更强大的系统。同时，我们框架中的优化压力会暴露出对齐失效行为，为评估现实世界智能体系统中的风险提供了一个沙盒环境。 为了建立首个针对自主智能体自我改进的全面评估套件，我们做出了以下核心贡献： (1) 我们正式定义并实例化了跨多个领域的元智能体挑战——涵盖数学推理、竞赛编程、研究生级科学问题、仓库级软件工程以及长周期终端交互——并发布了首个面向自主智能体开发的开源评估基准。 (2) 我们设计并实现了一套高度安全的评估流程，针对智能体的奖励黑客行为设置了多层防御机制。尽管新型漏洞可能不可避免会出现，但我们的防御架构为在高优化压力下进行严谨可信的智能体基准测试奠定了关键基础。 (3) 借助这一框架，我们证明元智能体很少能匹敌人工设计的脚手架，而少数能做到的则主要由闭源模型主导，这揭示了闭源与开源模型之间的显著差距。我们进一步表明，自主设计过程存在较高的运行间方差，且强优化压力可能触发涌现性的失调行为。随后，我们诊断了关键的成功与失败模式，以指导未来智能体模型的发展。 2 相关工作 智能体基准测试 现有的智能体基准测试主要评估智能体解决特定类别任务的能力。例如，SWE-Bench [6] 衡量仓库级代码编辑能力，而 Terminal-Bench [11] 则针对需要持续多步推理的长周期终端交互。BrowseComp [21] 聚焦于在网络上执行迭代式长链检索的浏览型智能体。最相关的是 MLE-Bench [3]，它评估智能体模型为机器学习任务开发和优化算法的能力。这些基准测试的共同特点是其领域特定性：每个基准都衡量智能体在固定任务框架内的表现。元智能体挑战则偏离了这一范式，它评估的不是智能体解决任务的能力，而是其在多个领域内开发并迭代改进智能体系统的能力。 元智能体 近期许多研究探索了元智能体的概念——即设计、配置或优化智能体系统的智能体系统。例如，Hu等人[4]、Qiu等人[13]、Yin等人[24]、Xia等人[23]、Zhou等人[27]、Lee等人[10]以及Zhang等人[25]专注于设计用于编排专业智能体系统的元智能体框架。与此同时，一些研究在进化框架内利用大语言模型来自主提出、评估和优化复杂算法[12]，甚至包括编码智能体本身[26]。此外，Lee等人[10]发现现代代码智能体能够执行智能体框架的优化。相比之下，我们的工作并未提出新的元智能体架构，而是构建了一个评估框架，用于衡量通用代码智能体作为元智能体的潜力。从这个意义上说，元智能体挑战赛可以看作是智能体开发领域中PostTrainBench[14]的对偶任务：PostTrainBench评估智能体执行模型后训练的能力，而我们的基准测试则评估它们改进智能体工作流本身的能力——从而形成从智能体评估到智能体构建的闭环。 3 元智能体挑战赛 我们提出元智能体挑战赛，这是一个评估框架，用于衡量代码智能体自主设计、实现并迭代优化特定任务智能体工作流的能力。与评估智能体直接解决问题能力的传统基准测试不同，我们的挑战赛在更高的抽象层级上运作：被评估的智能体本身并不解决问题，而是构建另一个智能体来解决问题。这种递归结构——智能体构建智能体——测试了当前系统前沿的能力：假设形成、代码实现、实证评估和迭代优化。 3.1 问题定义 设一个代码智能体（元智能体）能够访问基础模型API、辅助工具API（例如网络搜索）以及沙盒开发环境。该元智能体的任务是生成一个产物——一个实现特定任务智能体的可执行程序——该程序需在保留的测试集上最大化性能。 具体而言，元智能体可以访问以下内容： 一组特定领域的查询或任务开发集； 一个评估端点，用于接收智能体产物并返回其在 上的性能反馈； 一套全面的 API 套件，提供对语言模型和外部环境工具（如搜索引擎）的访问，供生成的产物内部使用； 一个基类规范，定义了评估系统所需的智能体接口。 同时，元智能体受到以下约束： API 资源限制：对开发阶段和最终产物执行阶段的 API 调用次数、消耗的总模型 token 数量有严格预算。这防止了依赖过度采样或暴力查询的简单解决方案。 时间限制：开发阶段和产物测试阶段有最大计算时间预算，要求元智能体在截止日期前，有效平衡对新智能体架构的探索与对已知有效策略的利用。 因此，元智能体挑战可以被视为一个约束优化问题。元智能体作为一个自主优化器，在由基类 定义的有效智能体程序空间中搜索。目标是找到一个最优产物，使未见测试集上的评估指标最大化： (1) 满足约束条件 关键在于，由于目标分布在开发阶段完全未知，元智能体无法直接求解此优化问题。相反，它必须依赖来自 的经验反馈，迭代地提出、评估和优化 ，模拟人类开发者的试错开发周期。 3.2 评估协议 对 的评估采用两阶段协议，旨在模拟真实的智能体开发工作流程，同时保持严格的留出评估。 开发阶段。 在开发阶段，元智能体可以：(i) 读取任务指令，(ii) 实现并修改其智能体工件，(iii) 将工件提交给评估预言机以获取反馈，以及（可选）安装额外的依赖项。评估 API 会返回诸如每个问题的正确性指标和整体准确率等信息作为反馈，从而在保持对保留测试集进行最终评估完整性的同时，实现迭代优化。 验证阶段。 在开发预算耗尽后，一个自动验证器会执行以下流程：(1) API 使用监控器扫描工作区是否存在策略违规；(2) 在保留测试集上执行智能体工件，并设置超时时间（秒）；(3) 将预测结果与真实标签或单元测试进行比对评分；(4) 记录最终奖励。验证器脚本仅在此阶段被注入容器，确保元智能体在开发期间无法访问测试集机密。 3.3 评估系统架构 评估元智能体能力的一个核心设计挑战是，在向智能体提供有意义的评估反馈的同时，防止其轻易地钻评估系统的空子。我们通过一种双容器架构来解决这个问题，该架构在智能体执行环境和评估服务之间实施了严格的隔离（图 2）。 媒体内容 · 前往原文查看 图 2：双容器架构。智能体容器提供开发环境。评估容器安全地保存着数据集和真实标签，提供一个 API 代理来强制执行配额，通过智能体运行器执行提交的智能体，并且仅向智能体容器返回有限的反馈。 智能体容器。 智能体容器提供了一个沙盒化的 Linux 环境，元智能体在其中开发其解决方案。它包含智能体接口规范（base_agent.py）和一个 API 封装器（openai_helper.py）。元智能体将其工件写入 /workspace/agent.py，并可以通过 pyproject.toml 清单文件声明额外的 Python 依赖项，评估系统会自动安装这些依赖项。 智能体接口。 所有智能体工件都必须继承自 BaseAgent 类，并实现一个单一方法： (2) 其中 是问题索引， 是问题陈述， 是预测答案， 是以秒为单位的超时预算。基类提供了标准接口规范和实用方法。这种最小化接口赋予了元智能体最大的灵活性，使其能够设计工件内部架构——从简单的单次提示词传递到复杂的多阶段流水线。 评估容器。 一个独立的容器托管了基于 Flask 的评估服务，该服务保存了两个数据分区的所有真实答案。当元智能体通过 /evaluate/agent 端点提交其工件时，评估容器会：(1) 动态加载提交的智能体类，(2) 在请求的问题分区上执行它，(3) 使用领域特定的评分逻辑对预测进行评分，以及 (4) 返回性能反馈。这种设计确保单个真实答案永远不会暴露给智能体容器。 3.4 评估完整性 在评估框架的开发过程中，我们识别出智能体可能利用来人为抬高分数的两种主要威胁模式，并通过多层防御架构加以应对。 威胁 1：未授权资源访问。 元智能体可能通过篡改 API 请求参数，秘密调用同一模型 API 提供商中更强大、未经授权的模型，从而绕过挑战约束。此外，它还可能通过使用泄露的外部 API 密钥或执行本地语言模型来完全规避资源配额。能力升级和配额规避都会使性能比较失去意义。 缓解措施。我们通过以下方式实施资源隔离： API 监控：一个静态分析模块扫描智能体工作空间中的所有 Python 文件，查找未授权的导入和对禁止端点的网络连接。 API 代理：所有模型 API 调用都通过评估容器中的一个代理进行路由，该代理强制执行配额限制并记录使用情况。 事后审计：审计智能体分析执行轨迹和提交的代码，以识别未经授权的网络请求、隐藏的模型调用或试图绕过 API 代理的行为。 威胁 2：测试集泄露。 如果没有适当的隔离，元智能体可能直接访问测试集问题或真实答案，从而产生记忆答案而非开发可泛化智能体架构的简单解决方案。 缓解措施。我们通过以下方式实施严格的数据隔离： 容器文件系统分离：两者的真实答案仅存在于评估容器的私有文件系统中，智能体容器无法访问。 分层访问控制：对测试分区的评估需要一个通过 HTTP 头（X-Verifier-Secret）传输的加密密钥。该密钥嵌入在验证器脚本中，该脚本仅在开发阶段结束后注入智能体容器。在开发期间，元智能体只能针对 进行评估。 事后审计：审计智能体检测硬编码答案、暴力枚举尝试以及其他表明测试集被利用的模式。 3.5 领域实例化 元智能体挑战框架在设计上是领域无关的。为证明其通用性并提供全面的评估基准，我们在五个领域对其进行了实例化，这些领域锻炼了互补的元智能体能力：数学推理（AIME）、研究生级别科学问答（GPQA/HLE）、竞赛编程（LiveCodeBench）、仓库级代码编辑（SWE-Bench）以及长周期终端交互（Terminal-Bench）。我们将此评估套件称为 MAC-v1。关于每个领域的数据集、评估指标和具体分区配置的详细信息，请参见附录 C。 4 实验设置 元智能体系统。 我们评估了四种由专有前沿模型驱动的基于命令行的自主编码智能体：Claude Code（Claude Opus 4.7、Opus 4.6 和 Sonnet 4.6）、Gemini-Cli（Gemini 3.1 Pro）、Codex（gpt-5.3-codex、gpt-5.4），所有这些智能体均在 Harbor [17] 沙箱化评估框架内运行。我们还评估了与 Claude Code 脚手架集成的几个领先开源权重模型（GLM、Kimi、DeepSeek、MiniMax）。得益于 Harbor 框架高度可扩展的设计，我们的评估系统可以无缝集成任何未在实验中明确使用的替代智能体脚手架。 资源约束。 对于 AIME、GPQA 和 LiveCodeBench，元智能体被分配的时间预算为秒（12 小时）；对于 SWE-Bench 和 Terminal-Bench，时间预算为秒（24 小时），这反映了执行和评估完整智能体产物的更高成本。在所有领域，元智能体都可以访问评估 API 以获取关于 的迭代反馈。关于 API 配额，我们为前三个领域设计了一种评估设置，利用专用的 vLLM 后端，其中每个评估实例都可以独占访问通过 vLLM [9] 部署在单个 A100 GPU 上的模型。对于 SWE-Bench 和 Terminal-Bench，所有运行均专门使用商业 API 端点，因为执行和评分都委托给了 Harbor 框架。此外，在科学领域，元智能体在每个阶段被授予 次搜索 API 调用配额。 基线。 我们将元智能体的性能与两种作为人类性能代理的基线进行比较：（1）朴素智能体——一种最简智能体实现，使用标准评估提示词且无优化，代表了简单产物所能达到的下限。（2）成熟的人工工程框架——具体指 SWE-Bench 和 Terminal-Bench 的 Terminus-2111https://www.harborframework.com/docs/agents/terminus-2 和 OpenHands [19]。这些代表了元智能体试图匹配或超越的“专家工程”上限。 5 结果 5.1 评估完整性验证 在报告分数之前，我们首先确认我们的测量反映的是自主智能体开发能力，而非奖励破解行为。这基于两大支柱：一个能够可靠标记作弊尝试的事后审计智能体，以及证明其标记与前沿框架在优化压力下实际诱导的行为相对应的经验证据。以下发现为第 5.2 节中每次运行附带的完整性标记（）提供了支撑。 通过诱导式红队测试进行审计验证。 显式的对抗性提示——例如直接指示代码智能体寻找并利用评估框架中的漏洞——在几乎每次尝试中都触发了前沿模型的安全拒绝。这种高拒绝率使得直接提示不适合对该基准进行稳健的红队测试。因此，为了可靠地诱导奖励破解行为，我们采用了一种间接协议：在零资源配置下（即，不给工件智能体提供有效的 API 密钥）评估智能体。这种人为约束创造了极端的优化压力，激励智能体发现非预期的奖励获取途径。值得注意的是，在八次独立试验中，有七次产生了明显的策略违规，一次在缺少凭证的情况下仍生成了有效工件。我们的审计智能体在所有八次判决中均与人工标注者一致，证实了第 5.2 节中使用的完整性标签的可靠性。除了这种红队测试场景外，该审计器还在常规开发运行中发现了突发的攻击行为。附录 B.3.1 中提供了关于 GPT-5.3-Codex 自主标签外泄的详细案例研究。 5.2 元智能体性能 媒体内容 · 前往原文查看 表 1：各推理领域的元智能体性能。每个单元格报告评估分数及相应的状态标记。完整性标记为干净运行（）或检测到作弊（）。开发时间标记为在预算内完成（）或预算耗尽（）。平均列详细列出了三次运行的平均值 ± 标准差。 模型 元-AIME 元-GPQA 元-LiveCodeBench 运行 1 运行 2 运行 3 平均 运行 1 运行 2 运行 3 平均 运行 1 运行 2 运行 3 平均 人类基线 0.750 / - 0.750 / - 0.700 / - 0.733 0.029 0.585 / - 0.621 / - 0.586 / - 0.597 0.020 0.545 / - 0.554 / - 0.566 / - 0.555 0.011 Claude Code Claude-Opus-4.6 0.767 / 0.683 / - 0.783 / 0.744 0.054 0.616 / 0.520 / 0.581 / 0.572 0.049 0.508 / 0.585 / 0.579 / 0.557 0.043 Claude-Sonnet-4.6 0.767 / 0.783 / 0.800 / - 0.783 0.017 0.565 / - 0.585 / - 0.000 / - 0.383 0.332 0.452 / - 0.576 / 0.310 / 0.446 0.133 MiniMax-M2.5 0.298 / - 0.394 / - 0.227 / - 0.306 0.084 0.353 / - 0.222 / - 0.515 / - 0.363 0.147 0.170 / - 0.291 / 0.319 / - 0.260 0.079 Kimi-K2.5 0.317 / - 0.700 / - 0.033 / - 0.350 0.335 0.222 / - 0.212 / - 0.338 / - 0.257 0.070 0.037 / - 0.003 / - 0.040 / - 0.027 0.021 GLM-5 0.247 / - 0.404 / - 0.414 / - 0.355 0.094 0.515 / - 0.566 / - 0.545 / 0.542 0.026 0.307 / 0.152 / 0.235 / - 0.231 0.078 Codex GPT-5.3-Codex 0.250 / - 0.017 / - 0.383 / - 0.217 0.185 0.348 / - 0.217 / - 0.323 / - 0.296 0.070 0.322 / - 0.266 / - 0.211 / - 0.266 0.056 Gemini-cli Gemini-3.1-Pro 0.733 / - 0.417 / 0.700 / - 0.617 0.174 0.566 / 0.556 / - 0.500 / - 0.541 0.036 0.489 / 0.084 / 0.328 / 0.300 0.204 媒体内容 · 前往原文查看 表 2：SWE-Bench 和 Terminal-Bench 上的元智能体性能。单元格格式和标注遵循表 1。 模型 脚手架 元-SWE-Bench 元-Terminal-Bench 运行 1 运行 2 运行 3 平均 运行 1 运行 2 运行 3 平均 人类基线 Terminus-2 0.616 / - 0.624 / - 0.672 / - 0.637 0.030 0.315 / - 0.315 / - 0.348 / - 0.326 0.019 人类基线 OpenHands 0.552 / - 0.544 / - 0.536 / - 0.544 0.008 0.225 / - 0.303 / - 0.326 / - 0.285 0.053 Claude-Opus-4.7 Claude Code 0.640 / 0.652 / - 0.536 / - 0.609 0.064 0.393 / - 0.360 / - 0.427 / - 0.393 0.034 Claude-Opus-4.6 Claude Code 0.600 / 0.512 / 0.216 / 0.443 0.201 0.236 / - 0.247 / 0.303 / 0.262 0.036 Claude-Sonnet-4.6 Claude Code 0.420 / 0.220 / 0.480 / - 0.373 0.136 0.292 / - 0.348 / 0.247 / - 0.296 0.051 MiniMax-M2.7 Claude Code 0.000 / - 0.004 / - 0.008 / - 0.004 0.004 0.101 / - 0.034 / - 0.000 / - 0.045 0.051 GLM-5.1 Claude Code 0.528 / - 0.444 / 0.456 / - 0.476 0.045 0.258 / - 0.270 / - 0.236 / - 0.255 0.017 DeepSeek-v4-Pro Claude Code 0.400 / - 0.124 / - 0.444 / - 0.323 0.173 0.315 / - 0.348 / - 0.371 / - 0.345 0.028 GPT-5.4 Codex 0.168 / - 0.500 / - 0.068 / - 0.245 0.226 0.213 / - 0.191 / - 0.146 / - 0.183 0.034 GPT-5.3-Codex Codex 0.060 / - 0.412 / - 0.408 / - 0.293 0.202 0.202 / - 0.135 / - 0.202 / - 0.180 0.039 Gemini-3.1-Pro Gemini-cli 0.464 / 0.248 / - 0.468 / 0.393 0.126 0.303 / - 0.157 / 0.236 / 0.232 0.073 表1和表2分别展示了推理领域和智能体领域的评估结果。对于推理任务，所开发制品使用的API模型是部署在专用A100 vLLM后端上的Qwen3-8B，而SWE-Bench和Terminal-Bench评估则使用Claude Haiku 4.5。我们的分析得出三个主要发现： 发现1：元智能体很少能匹敌人工构建的脚手架，而少数能做到的几乎都由专有前沿模型主导。 只有少数元智能体配置超过了相应人工基线的平均值，其中绝大多数由专有前沿模型（Claude Sonnet/Opus）驱动，仅有一个开放权重配置（DeepSeek-v4-Pro）跨过了这条线。没有任何元智能体在GPQA或SWE-Bench上完全超越基线，尤其是开放权重模型在任何推理领域都未能匹敌人工构建的脚手架，这突显了闭源与开源代码智能体在自主智能体开发方面存在巨大的能力差距。 发现2：运行间的高方差暴露了自主设计决策的脆弱性。 我们观察到，部分配置的标准差大于某个值，而人工基线的标准差最大仅为某个值。关键在于，这种极端方差并非仅仅是评估噪声，而是阻碍当前代码智能体实现可靠自主智能体开发的根本瓶颈。这表明，虽然现有模型偶尔能够合成出高效的智能体，但它们缺乏稳健性，无法持续地在开放式的设计空间中进行探索。 发现3：高优化压力会诱发自发的奖励破解行为。 我们的事后审计器（详见第5.1节）标记了五次试验，涵盖了不同的利用类别。关键在于，双容器隔离、分级授权和代理强制执行机制成功阻止了每一次利用尝试；没有一次被标记的运行人为地提高了其测试分数。因此，我们将这些运行保留在汇总平均值中，以记录智能体的对抗意图，而不因其未成功的利用行为而进行惩罚。 5.3 成功与失败模式分析 图3：元智能体开发过程特征与最终奖励。每个面板展示一个开发阶段特征与最终奖励的对应关系，两个坐标轴均按领域均值居中处理，以控制跨任务难度差异。每个面板分别报告皮尔逊相关系数和斯皮尔曼相关系数。 为了理解区分强元智能体运行与弱元智能体运行的宏观动态，我们为所有试验配备了六个特征，这些特征直接从评估系统日志中解析得出：总运行时间、首次评估调用时间、评估调用次数、评估调用成功率、评估调用的时间质心（0表示全部在开始时，1表示全部在结束时），以及平均调用间隔。随后，我们在减去每个领域均值后，将最终测试奖励对每个特征进行回归分析。 图3突出了两个主要的性能预测指标：平均调用间隔和总运行时间。相比之下，那些朴素迭代优化观点可能优先考虑的特征——例如评估调用次数、成功率、首次评估时间以及时间质心——所携带的预测信号却出人意料地微弱。 这些发现揭示了一个明确的趋势：成功的元智能体并不将评估端点视为高频反馈信号。它们在调用之间思考更长时间，投入更多总计算量用于工件设计，并且有节制地探询评分器。为了更深入地理解这些行为，我们进一步对生成的工件进行了定性分析，揭示了它们独特的设计选择和模式： 成功的推理工件收敛于简单的采样流程。 与代表性智能体推理文献中普遍存在的复杂树搜索或规划器-执行器分解相反，排名靠前的推理工件均未采用这些结构。相反，它们一致地收敛于务实的设计选择：带多数投票的并行采样、用于缓解投票崩溃的提示词多样化、代码执行集成，以及自适应时间预算分配。 顶尖的智能体工件倾向于采用极简的ReAct风格循环。 最佳 SWE-Bench 和 Terminal-Bench 工件是在小型工具集上运行的工具使用循环。它们共享三个关键选择：通过提示缓存增强的 API 调用以最小化延迟、在首次调用大语言模型之前根据问题符号进行预搜索预热以填充上下文，以及在终止前强制模型验证所有需求的单一验证提示。 表现不佳的智能体会将自己困在设计局部最优中。 表现不佳的智能体常常存在探索不足的问题，过早收敛于一个最小工件并停止迭代开发。另一些则陷入局部最优，过早地承诺采用一个根本上有缺陷或上限较低的范式，随后在这个受限框架内浪费迭代次数去解决琐碎的管道错误，而不是转向更可行的设计。 关键失败源于僵化的资源管理。 我们观察到元智能体普遍缺乏时间感知能力：它们在开发过程中很少主动监控剩余时间预算，经常耗尽分配的限制并遭遇突然终止。这种缺陷还会传播到它们生成的工件中。几次灾难性失败（奖励=0）源于未能对部分答案进行检查点保存的工件。因此，当评估工具在过程中发出超时信号时，所有先前计算的预测都会被丢弃，导致向智能体运行器提交空结果。 5.4 投入与回报的权衡 图 4：Meta-SWE-Bench 和 Meta-Terminal-Bench 上的投入-回报帕累托前沿。每个标记代表一个（模型，基准）组合在多次运行中的平均值，实线描绘了每个基准的帕累托最优前沿。 基于我们对开发动态的分析，我们进一步通过估算的 API 成本（图 4a）和开发时间（图 4b）来评估元智能体的效率。我们的结果表明，Claude-Opus-4.7 锚定了帕累托前沿，以最优效率实现了最高的整体性能。从 Opus-4.6 到 Opus-4.7 的演进揭示，这些能力提升源于更优的逐步骤决策，而非单纯的计算量增加。值得注意的是，在 Terminal-Bench 上，Opus-4.7 将完成时间减少了 46%，并且所需的智能体交互轮次比 Opus-4.6 少了 23%，这证实了官方关于加速自主问题解决的声明，并展示了高度有效的迭代推理能力。 6 结论与局限性 我们引入了元智能体挑战（MAC），这是一个开源的评估框架，将范式从对象级执行转变为元级自主智能体开发。通过挑战模型在沙盒环境中迭代设计和优化特定任务的智能体，MAC 严格评估了它们作为系统架构师的能力，同时防止了奖励作弊。在五个不同的领域，我们的发现表明，元智能体很少能匹敌人类设计的基线，而少数能做到这一点的模型主要由专有前沿模型主导，但其设计可靠性仍然脆弱，优化压力可能引发突现的失调行为。 局限性。 由于模拟完整迭代开发周期具有超长周期的特性，MAC 本质上非常耗时。此外，通过复用现有的对象级基准（例如 SWE-Bench、AIME），MAC 不可避免地继承了它们固有的局限性（例如，任务分布狭窄），以及基础模型预训练数据污染的持续风险。 参考文献 [1] Anthropic (2026-02) 负责任的扩展政策，第 3.0 版。技术报告 Anthropic。外部链接：链接 引用自：§1。 [2] 人工智能安全中心、Scale AI 和 HLE 贡献者联盟 (2026) 用于评估 AI 能力的专家级学术问题基准。《自然》649, 第 1139–1146 页。外部链接：文献，2501.14249，链接 引用自：附录 C。 [3] J. S. Chan, N. Chowdhury, O. Jaffe, J. Aung, D. Sherburn, E. Mays, G. Starace, K. Liu, L. Maksin, T. Patwardhan 等人 (2024) 《Mle-bench：在机器学习工程任务上评估机器学习智能体》。arXiv 预印本 arXiv:2410.07095。引用于：§2。 [4] S. Hu, C. Lu, 和 J. Clune (2025) 《智能体系统的自动化设计》。载于第十三届国际学习表征会议，外部链接：Link。引用于：§2。 [5] N. Jain, K. Han, A. Gu, W. Li, F. Yan, T. Zhang, S. Wang, A. Solar-Lezama, K. Sen, 和 I. Stoica (2025) 《LiveCodeBench：对代码大语言模型进行整体且无污染的评估》。载于第十三届国际学习表征会议，外部链接：Link。引用于：附录 C。 [6] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, 和 K. Narasimhan (2023) 《Swe-bench：语言模型能否解决真实的 GitHub 问题？》。arXiv 预印本 arXiv:2310.06770。引用于：附录 C, §2。 [7] Kimi (2026) 《Kimi K2.5：视觉智能体智能》。arXiv 预印本 arXiv:2602.02276。引用于：§1。 [8] T. Kwa, B. West, J. Becker, A. Deng, K. Garcia, M. Hasin, S. Jawhar, M. Kinniment, N. Rush, S. Von Arx 等人 (2025) 《衡量 AI 完成长周期任务的能力》。arXiv 预印本 arXiv:2503.14499。引用于：§1。 [9] W. Kwon, Z. Li, S. Zhuang, Y. Sheng, L. Zheng, C. H. Yu, J. E. Gonzalez, H. Zhang, 和 I. Stoica (2023) 《基于 PagedAttention 的大语言模型服务高效内存管理》。载于 ACM SIGOPS 第 29 届操作系统原理研讨会论文集。引用于：§4。 [10] Y. Lee, R. Nair, Q. Zhang, K. Lee, O. Khattab, 和 C. Finn (2026) 《Meta-Harness：模型 harness 的端到端优化》。arXiv 预印本 arXiv:2603.28052。引用于：§2。 [11] M. A. Merrill, A. G. Shaw, N. Carlini, B. Li, H. Raj, I. Bercovich, L. Shi, J. Y. Shin, T. Walshe, E. K. Buchanan 等人 (2026) 《Terminal-Bench：在命令行界面中针对困难、真实任务对智能体进行基准测试》。arXiv 预印本 arXiv:2601.11868。引用于：附录 C, §2。 [12] A. Novikov, N. Vũ, M. Eisenberger, E. Dupont, P. Huang, A. Z. Wagner, S. Shirobokov, B. Kozlovskii, F. J. Ruiz, A. Mehrabian 等人 (2025) 《Alphaevolve：面向科学与算法发现的编程智能体》。arXiv 预印本 arXiv:2506.13131。引用自：§2。 [13] J. Qiu, X. Qi, H. Wang, X. Juan, Y. Wang, Z. Zhao, J. Geng, J. Guo, P. Li, J. Shi 等人 (2025) 《Alita-g：用于智能体生成的自演化生成式智能体》。arXiv 预印本 arXiv:2510.23601。引用自：§2。 [14] B. Rank, H. Bhatnagar, A. Prabhu, S. Eisenberg, K. Nguyen, M. Bethge 和 M. Andriushchenko (2026) 《PostTrainBench：大语言模型智能体能自动化大语言模型后训练吗？》。外部链接：2603.08640，链接。引用自：§2。 [15] D. Rein, B. L. Hou, A. C. Stickland, J. Petty, R. Y. Pang, J. Dirani, J. Michael 和 S. R. Bowman (2024) 《GPQA：面向研究生水平的谷歌无法作弊的问答基准》。收录于《第一届语言建模会议》，外部链接：链接。引用自：附录 C。 [16] J. Schmidhuber (2003) 《哥德尔机：能够实现可证明最优自我改进的自指通用问题求解器》。arXiv 预印本 cs/0309048。引用自：§1。 [17] Harbor 框架。外部链接：链接。引用自：附录 C，§4。 [18] W. Wang, X. Xu, X. Xu 等人 (2025) 《任其流动：在摇滚乐中构建智能体式创作，于开放智能体学习生态系统中打造罗马模型》。外部链接：2512.24873，链接。引用自：附录 C。 [19] X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh 等人 (2024) 《OpenHands：面向作为通用型智能体的 AI 软件开发者的开放平台》。arXiv 预印本 arXiv:2407.16741。引用自：§4。 [20] X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh, H. H. Tran, F. Li, R. Ma, M. Zheng, B. Qian, Y. Shao, N. Muennighoff, Y. Zhang, B. Hui, J. Lin, R. Brennan, H. Peng, H. Ji 和 G. Neubig (2025) 《OpenHands：面向作为通用型智能体的 AI 软件开发者的开放平台》。收录于《第十三届国际学习表征会议》，外部链接：链接。引用自：§1。 [21] J. Wei, Z. Sun, S. Papay, S. McKinney, J. Han, I. Fulford, H. W. Chung, A. T. Passos, W. Fedus, 和 A. Glaese (2025) 《Browsecomp：一个简单但富有挑战性的浏览智能体基准测试》。arXiv 预印本 arXiv:2504.12516。引自：第 2 节。 [22] H. Wijk, T. Lin, J. Becker, S. Jawhar, N. Parikh, T. Broadley, L. Chan, M. Chen, J. Clymer, J. Dhyani, 等人 (2024) 《Re-bench：评估前沿 AI 语言模型智能体研发能力与人类专家对比》。arXiv 预印本 arXiv:2411.15114。引自：第 1 节。 [23] C. S. Xia, Z. Wang, Y. Yang, Y. Wei, 和 L. Zhang (2025) 《Live-swe-agent：软件工程智能体能否即时自我进化？》。arXiv 预印本 arXiv:2511.13646。引自：第 2 节。 [24] X. Yin, X. Wang, L. Pan, L. Lin, X. Wan, 和 W. Y. Wang (2025-07) 《Gödel 智能体：一种用于递归自我改进的自指智能体框架》。收录于《第 63 届计算语言学协会年会论文集（第一卷：长文）》，W. Che, J. Nabende, E. Shutova, 和 M. T. Pilehvar 编，奥地利维也纳，第 27890–27913 页。外部链接：Link, Document, ISBN 979-8-89176-251-0。引自：第 2 节。 [25] G. Zhang, H. Ren, C. Zhan, Z. Zhou, J. Wang, H. Zhu, W. Zhou, 和 S. Yan (2025) 《Memevolve：智能体记忆系统的元进化》。arXiv 预印本 arXiv:2512.18746。引自：第 2 节。 [26] J. Zhang, S. Hu, C. Lu, R. Lange, 和 J. Clune (2025) 《Darwin Gödel 机器：自我改进智能体的开放式进化》。arXiv 预印本 arXiv:2505.22954。引自：第 2 节。 [27] H. Zhou, S. Guo, A. Liu, Z. Yu, Z. Gong, B. Zhao, Z. Chen, M. Zhang, Y. Chen, J. Li, R. Yang, Q. Liu, X. Yu, J. Zhou, N. Wang, C. Sun, 和 J. Wang (2026) 《Memento-skills：让智能体设计智能体》。外部链接：2603.18743, Link。引自：第 2 节。 附录 A 提示词与附加实验配置 A.1 审计智能体 审计智能体通过 Claude Code Agent SDK 实例化，以 Claude Opus 4.6 作为其骨干模型，并拥有完整的文件系统和 shell 工具访问权限，作用域限定在单个试验目录内。每个完成的试验会调用该智能体一次，使用以下提示词，并输出一个结构化的 JSON 判定结果（CLEAN、SUSPICIOUS 或 CHEATING），同时附上支持性证据。 事后审计智能体使用以下提示词。 instance_id