Meta的Muse Wonder建模引争议 亚历山大·王辩护遭马斯克补刀

Meta 刚发布的 Muse Wonder，没想到因为一盏熔岩灯，在开发者社区引发了一场关于 AI 模型跑分的争论。

10 月 12 日，Meta 推出 Muse Wonder 和 Muse Wonder Full，主打 Coding Agent、工具调用和长任务执行能力。官方公布的成绩相当亮眼，Wonder Full 在 SWE-Marathon 上拿到 57.5 分，DeepSWE 1.1 达到 79.0 分，已经能够与同期的前沿模型展开竞争。

然而，开发者社区 BridgeMind 随后安排了一项 3D 编程测试，要求 Muse Wonder 制作一盏具有透明玻璃外壳、动态熔岩和光照效果的熔岩灯。

结果模型只生成了一个红色圆柱体。

BridgeMind 随即质疑 Muse Wonder 存在严重的 Benchmaxxing，也就是针对 Benchmark 进行大量优化，成绩看着漂亮，碰上陌生任务却露了怯。

连马斯克也忍不住下场，在相关帖子下意味深长地回了一句 Hmm。短短一个词，虽然没有明确表态，却让这场围绕 Meta 新模型的刷分争议又添了几分戏剧性。

Meta 首席 AI 官 Alexandr Wang 很快回应，团队确实没有针对 3D 演示游戏进行显式训练，事后看来或许应该补充相关训练，但他仍然希望开发者实际体验 Muse Wonder 的 Coding 能力。

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

但高分模型在陌生任务中遭遇如此明显的失败，依然让人好奇：当前大模型的训练方法究竟在强化哪些能力，Agent Benchmark 又能在多大程度上反映模型的实际水平？

Muse Wonder 的表现，与当前大模型越来越依赖 Post-training 提升任务能力的技术路线有关。

在 Pre-training 阶段，模型通过大规模数据学习语言、代码、空间关系和其他通用知识。进入 Post-training 后，训练会进一步塑造模型的行为策略，尤其是通过强化学习，让它在特定任务环境中形成更稳定的执行能力。

Coding Agent 很适合这类训练。例如，给模型一个存在 Bug 的代码仓库，要求它定位问题、修改文件并运行测试。

整个过程可以通过编译结果、单元测试和功能检查获得相对明确的反馈。强化学习系统据此判断哪些操作有效，持续强化能够提高任务成功率的行为。

训练规模扩大后，模型逐渐学会一套复杂的软件工程策略，包括如何缩小搜索范围、选择工具、处理报错，以及在多轮修改中维护任务状态。

Meta 在官方技术文章中提到，Muse Wonder 接受了多样化长任务训练，并引入 Active Focus，使模型能够在遭遇阻碍后尝试其他方案、恢复执行并继续推进任务。

但这类训练依赖一个关键条件：环境必须能够向模型提供有用的反馈。熔岩灯恰好打破了传统 Coding Agent 熟悉的反馈方式。

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

这些代码即使能够正常执行，画面仍然可能完全错误。例如，透明材质的参数配置不当，玻璃就可能变成不透明的实体，熔岩形状缺少连续变化机制，内部效果就可能退化为静态色块。编译器和单元测试很难直接判断这些视觉问题。

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

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

Alexandr Wang 承认没有针对 3D 演示进行显式训练，至少说明这一任务没有获得与重点 Coding 场景相同的训练投入。

Muse Wonder 的争议还有一层容易被忽略的问题：今天的 Agent Benchmark，已经无法简单理解为给语言模型出题。

以 SWE-Marathon 为例，它考察的是持续性软件工程任务。模型需要在代码仓库中执行多个操作，读取文件、调用终端、修改代码，并通过测试验证结果。

这类任务的完成率，除了依赖底层模型，还会受到 Harness 的直接影响。Harness 是围绕模型构建的执行框架，负责组织工具接口、管理上下文、保存任务状态，以及处理执行过程中的异常。

例如，一个 Agent 正在修复复杂的软件问题，连续运行测试后产生了数千行终端日志。如果系统将全部日志直接追加到上下文中，模型可能逐渐失去对原始需求和关键错误的把握。

设计更完善的 Harness 可以自动提取重要报错、压缩无效信息，并维护当前修改进度。当任务执行时间延长，这种上下文管理能力会直接影响系统能否持续工作。

错误恢复机制同样如此。假设 Agent 已经修改了多个文件，却在后续测试中发现早期修改存在问题。如果执行系统能够保留检查点、定位引入错误的步骤，并局部回滚，就有机会避免重新执行整条任务链。

此外，推理预算也会影响成绩。允许 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 产品，完整执行系统的表现本身就具有工程价值。

对于实际开发者而言，Agent 能否稳定处理长任务，往往比单轮生成代码的质量更有意义。问题在于，当各种系统配置被压缩成排行榜上的一个分数时，外部很难判断成绩增长究竟来自模型推理能力、执行框架优化，还是更充足的计算资源。

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

有意思的是，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，换一个未曾接触过的代码仓库，仍然属于相近的软件工程任务。如果进一步更换编程框架、引入陌生 API，模型就需要重新理解工具环境。

而制作 3D 熔岩灯，除了软件开发，还引入了空间建模、材质渲染和视觉质量判断。它对能力组合提出了更大的变化。

因此，分布外泛化不能只用一个综合平均分来描述。不同任务之间的距离、需要补充的知识，以及评价结果的方法，均会影响模型表现。

判断模型是否存在严重的 Benchmark 过拟合，也需要系统性实验。单个熔岩灯失败只能说明模型没有完成当前任务，无法直接证明它针对公开题库进行了过度优化。

更合理的方法，是在相同执行条件下逐步改变任务分布。例如，先测试模型能否修复陌生仓库中的 Bug，再要求它使用未见过的 API 构建程序，随后加入缺少明确测试脚本的视觉开发任务。

这样既可以观察模型在软件工程内部的能力迁移，也能检查它跨越任务类型时出现的性能变化。

评测还可以进一步改变环境约束，例如临时替换工具接口、引入新的错误信息，或者要求 Agent 自行设计验证程序。这些设置能够检验模型面对陌生条件时，是否具备阅读文档、建立方案、验证假设和修正错误的能力。 

对于熔岩灯这样的任务，除了检查最终画面，还应该记录模型是否主动使用截图工具、能否识别材质与几何错误，以及在获得反馈后是否能够作出有效修改。

相比单纯统计成功率，这类执行轨迹更有助于判断 Agent 的能力缺口，也能够区分知识不足、工具错误和反馈机制失效等不同原因。

随着公开 Benchmark 越来越成熟，模型研发会持续利用已知任务结构改进训练方法。动态任务、隐藏测试以及更完整的执行过程评估，将成为补充固定排行榜的重要手段。

Muse Wonder 的熔岩灯失败，无法抹去它在软件工程任务上的进步，也不足以证明 Meta 存在严重刷分行为。

但开发者确实需要重新理解今天的 Agent 成绩。当 Post-training、工具系统和推理预算共同参与能力提升，排行榜上的高分，反映的是一套特定条件下的任务完成表现。它对模型选型具有参考意义，但使用场景越复杂，单一分数能够提供的信息就越有限。

未来的 Agent 研发仍然会继续强化 Coding、工具调用和长任务执行，但当模型逐渐能够承担独立的软件工程工作时，它需要处理的问题会不断超出既有训练任务的范围。

届时，能否识别陌生环境中的问题、自行建立有效的验证方法，并通过反馈持续修正执行策略，将直接影响 Agent 可以承担多大范围的实际工作。

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