Muse Wonder熔岩灯翻车：Agent高分背后的Benchmaxxing疑云

Meta 在 10 月 12 日推出编程 Agent 模型 Muse Wonder 与 Muse Wonder Full，官方成绩单相当漂亮：Wonder Full 在 SWE-Marathon 拿到 57.5 分，DeepSWE 1.1 达到 79.0 分。但开发者社区 BridgeMind 只用了一道 3D 编程题——制作一盏带透明玻璃外壳、动态熔岩和光照效果的熔岩灯——就让这款新模型翻了车：它只生成了一个红色圆柱体。

这场看似"整活"的测试，迅速演变成关于 Agent Benchmark 究竟能否反映真实能力的争论，连马斯克也在相关帖子下留下一句意味深长的"Hmm"。

一盏熔岩灯，为什么能击穿高分模型

红色圆柱体背后的任务难度

从程序实现看，熔岩灯涉及三维几何、透明材质、光照计算与动态形变。以 Three.js 为例，模型需要构造玻璃灯罩、为内部熔岩生成不规则几何形态，再通过时间变量或噪声函数驱动形状变化。

关键技术难点在于：这类代码即使能正常执行，画面仍可能完全错误。透明材质参数配置不当，玻璃会变成不透明实体；熔岩缺少连续变化机制，内部效果会退化为静态色块。编译器和单元测试很难直接判断这些视觉层面的缺陷。

换句话说，Agent 需要一套视觉反馈机制：渲染截图、识别画面偏差、再把视觉问题转换成代码修改。单纯增加工具调用次数或延长推理时间，替代不了这一环节。

官方承认的 3D 短板

一个容易被忽略的前提是：熔岩灯测试针对的是普通版 Muse Wonder，而 Meta 公布的部分突出成绩来自 Wonder Full，两者存在能力差异。同时，Meta 官方 Model Card 已明确承认，视觉与空间推理（尤其是 3D 任务）属于 Muse Wonder 的已知短板。

Meta 首席 AI 官 Alexandr Wang 回应称，团队确实没有针对 3D 演示游戏进行显式训练，事后看来或许应该补充相关训练，但他仍希望开发者实际体验 Muse Wonder 的 Coding 能力。这番辩护随即被马斯克的"Hmm"补了一刀。

Three.js 是一个基于 WebGL 的 JavaScript 3D 图形库，开发者通过它可以在浏览器中创建交互式三维场景。Three.js 提供场景图、相机、几何体、材质、光源等核心抽象，并封装了底层的图形 API 调用。在熔岩灯任务中，模型需要组合 THREE.MeshPhysicalMaterial（用于玻璃的透射与折射）、THREE.PointLight（模拟内部光源）以及基于顶点着色器或噪声函数的几何体动态变形。这些组件的参数空间大、视觉效果难以通过代码静态推断，因此对缺乏视觉反馈的 Agent 构成显著挑战。

Model Card 是模型发布方随模型一同提供的标准化说明文档，通常包含模型能力描述、预期用途、已知局限、训练数据概况和伦理考量。Meta 在 Muse Wonder 的 Model Card 中明确列出视觉与空间推理（尤其是 3D 任务）为已知短板，这意味着该局限在发布前已被识别。Model Card 的作用在于为下游开发者提供选型参考，但实际中容易被排行榜分数掩盖，熔岩灯测试恰好将这一纸面声明转化为可感知的失败案例。

奖励机制决定了模型擅长什么

Muse Wonder 的表现与当前大模型越来越依赖 Post-training 的技术路线直接相关。Pre-training 阶段，模型通过大规模数据学习语言、代码、空间关系等通用知识；进入 Post-training 后，强化学习会进一步塑造模型的行为策略。

Coding Agent 特别适合这类训练：给模型一个存在 Bug 的代码仓库，要求它定位问题、修改文件并运行测试，整个过程的编译结果、单元测试和功能检查都能提供相对明确的反馈。训练规模扩大后，模型逐渐学会缩小搜索范围、选择工具、处理报错，以及在多轮修改中维护任务状态。

Meta 在技术文章中提到的 Active Focus 机制，正是让模型在遭遇阻碍后尝试其他方案、恢复执行并继续推进任务。但这类训练依赖一个关键条件：环境必须能向模型提供有用的反馈。熔岩灯恰好打破了传统 Coding Agent 熟悉的反馈方式——它需要的是视觉判断，而非编译器判断。

模型为何退化成红色圆柱体，仍需完整执行轨迹才能定论。可能是没有建立正确的空间结构，可能是图形工具使用不当，也可能是生成错误后缺少有效的视觉检查。

Agent 高分早已不只是模型能力

Harness 与推理预算的隐形加成

今天的 Agent Benchmark 已经无法简单理解为给语言模型出题。以 SWE-Marathon 为例，模型需要在代码仓库中执行多步操作，完成率除了依赖底层模型，还受 Harness 的直接影响。

Harness 是围绕模型构建的执行框架，负责组织工具接口、管理上下文、保存任务状态、处理异常。设想 Agent 连续运行测试产生数千行终端日志，如果全部追加到上下文，模型会逐渐失去对原始需求和关键错误的把握；而设计完善的 Harness 能自动提取重要报错、压缩无效信息、维护修改进度。

错误恢复机制同理：若 Agent 修改多个文件后发现早期修改有问题，能保留检查点、定位引入错误的步骤并局部回滚的系统，就有机会避免重跑整条任务链。推理预算也会影响成绩——更多 Token、更多工具调用、多个候选方案意味着更大的搜索空间和纠错机会，代价是更高的运行成本。

Meta 官方 Model Card 对此有明确说明：在 SWE-Marathon 评测中，GPT-6 Astra 和 Claude Fable 5.1 分别使用 Codex 与 Claude Code 执行系统，因此该项目并非统一 Harness 条件下的受控比较；Muse Wonder Full 的 57.5 分还使用了 xhigh 推理档位。

这些配置差异不会自动使成绩失效，却会影响成绩的解释方式。比较基础模型的推理与规划能力，需要尽量统一工具环境、Harness 和推理预算；但若比较的是可投入生产的 Coding Agent 产品，完整执行系统的表现本身就有工程价值。问题在于，当各种系统配置被压缩成排行榜上的一个分数时，外部很难判断增长来自模型推理能力、执行框架优化，还是更充足的计算资源。

SWE-Marathon 是一个面向软件工程任务的 Agent 评测基准，要求模型在真实代码仓库中完成多步骤的缺陷修复或功能开发。与单轮代码生成不同，SWE-Marathon 的任务通常需要 Agent 自行探索仓库结构、定位问题文件、修改代码并运行测试验证。评测记录任务完成率，但完成率高度依赖 Agent 所搭载的执行框架（Harness）和推理预算配置。因此，SWE-Marathon 的分数更适合比较完整 Agent 系统的工程表现，而非孤立地衡量基础模型的推理能力。

评测需要更完整的执行信息

这要求 Agent 评测提供更详细的执行数据，包括任务完成率、Token 消耗、工具调用次数、运行时间以及失败恢复情况。否则相近的 Benchmark 成绩，可能对应完全不同的工程体验。

Meta 自己也在研究 Benchmaxxing

有意思的是，Muse Wonder 官方技术文章专门设置了"Capabilities That Generalize"章节，讨论的恰好是 Benchmaxxing 背后的问题。Meta 指出，两个模型即使在常见 Benchmark 中取得相似成绩，处理陌生任务的能力仍可能存在较大差距。

为研究这一现象，团队将测试任务划分为两类：Post-training 重点优化的 In-distribution 任务，以及没有针对性优化的 Out-of-distribution 任务，并比较 Muse Spark 1.3 与 Muse Wonder Full 在不同推理预算下的表现变化。按照 Meta 公布的实验结果，Wonder Full 在陌生任务上的表现相比前代模型的对应趋势有所提升，Meta 认为这与更强的基础模型有关——基础能力的改善使 Post-training 收益能更有效地迁移到其他任务。

但这里存在一个评测设计问题：陌生任务究竟陌生到什么程度？对于长期训练代码修复的 Agent，换一个未曾接触的代码仓库，仍属于相近的软件工程任务；而制作 3D 熔岩灯，除了软件开发，还引入了空间建模、材质渲染和视觉质量判断，对能力组合提出了更大的变化。

分布外泛化不能只用一个综合平均分来描述。不同任务之间的距离、需要补充的知识、以及评价结果的方法，均会影响模型表现。判断模型是否存在严重的 Benchmark 过拟合，也需要系统性实验——单个熔岩灯失败只能说明模型没完成当前任务，无法直接证明它针对公开题库进行了过度优化。

更合理的方法是逐步改变任务分布：先测试模型能否修复陌生仓库中的 Bug，再要求它使用未见过的 API 构建程序，随后加入缺少明确测试脚本的视觉开发任务。这样既能观察软件工程内部的能力迁移，也能检查跨越任务类型时的性能变化。评测还可进一步改变环境约束，例如临时替换工具接口、引入新的错误信息，或要求 Agent 自行设计验证程序，以检验它阅读文档、建立方案、验证假设和修正错误的能力。

Benchmaxxing 指模型开发者针对公开 Benchmark 进行过度优化，使分数提升但真实泛化能力未同步改善的现象。常见手段包括在训练数据中混入 Benchmark 相似题目、针对评测格式调整 Post-training 策略，或为评测配置更充裕的推理预算和更优的 Harness。Benchmaxxing 本身不一定是刻意作弊，但会使排行榜分数与模型在陌生任务上的表现脱节。识别 Benchmaxxing 需要分布外测试和任务距离的系统性设计，单一失败案例不足以定性。

高分之外，仍需看清能力边界

熔岩灯失败无法抹去 Muse Wonder 在软件工程任务上的进步，也不足以证明 Meta 存在严重刷分行为。但开发者确实需要重新理解今天的 Agent 成绩：当 Post-training、工具系统和推理预算共同参与能力提升，排行榜上的高分反映的是一套特定条件下的任务完成表现。它对模型选型有参考意义，但使用场景越复杂，单一分数能提供的信息就越有限。

未来的 Agent 研发仍会强化 Coding、工具调用和长任务执行。但当模型逐渐承担独立的软件工程工作时，它需要处理的问题会不断超出既有训练任务的范围。能否识别陌生环境中的问题、自行建立有效的验证方法、通过反馈持续修正执行策略，将直接影响 Agent 能承担多大范围的实际工作。

一盏熔岩灯没有给出 Muse Wonder 的完整能力答案，却提供了一个具体的提醒：模型在熟悉任务中取得的成绩，与它在未知环境中能独立完成的工作，仍然需要分别检验。