Meta 于 10 月 12 日发布 Muse Wonder 与 Muse Wonder Full 两款模型，主打 Coding Agent、工具调用和长任务执行能力，官方公布的成绩可与同期前沿模型竞争。但开发者社区随后进行的一项 3D 编程测试中，Muse Wonder 未能生成预期的熔岩灯效果，只输出一个红色圆柱体，围绕模型跑分的争论由此展开。
据雷峰网报道，Meta 公布的数据显示，Wonder Full 在 SWE-Marathon 上获得 57.5 分，在 DeepSWE 1.1 上达到 79.0 分。开发者社区 BridgeMind 安排了一项 3D 编程测试，要求 Muse Wonder 制作一盏带有透明玻璃外壳、动态熔岩和光照效果的熔岩灯，模型最终只生成了一个红色圆柱体。BridgeMind 据此质疑 Muse Wonder 存在严重的 Benchmaxxing，即针对基准测试进行大量优化，成绩亮眼却在陌生任务中表现不佳。
马斯克在相关帖子下回复了一句“Hmm”，未作明确表态。Meta 首席 AI 官 Alexandr Wang 随后回应称，团队确实没有针对 3D 演示游戏进行显式训练，事后看来或许应该补充相关训练，但他希望开发者实际体验 Muse Wonder 的 Coding 能力。
这场争论有一个前提：熔岩灯测试针对的是普通版 Muse Wonder，而 Meta 公布的部分突出成绩来自 Wonder Full，两者存在能力差异。Meta 官方 Model Card 已明确承认，视觉与空间推理尤其是 3D 任务，属于 Muse Wonder 的已知短板。
Muse Wonder 的表现与当前大模型依赖 Post-training 提升任务能力的路线有关。据雷峰网报道，在 Pre-training 阶段，模型通过大规模数据学习语言、代码、空间关系等通用知识；进入 Post-training 后，强化学习让模型在特定任务环境中形成更稳定的执行能力。Coding Agent 很适合这类训练，因为编译结果、单元测试和功能检查能提供相对明确的反馈。Meta 在技术文章中提到，Muse Wonder 接受了多样化长任务训练，并引入 Active Focus，使模型在遇到阻碍后尝试其他方案、恢复执行并继续推进任务。但熔岩灯涉及三维几何、透明材质、光照计算和动态形变，这些代码即使能够执行，画面也可能完全错误，编译器和单元测试很难判断视觉问题。Agent 因此还需要一套视觉反馈机制，通过渲染截图识别画面偏差，再把视觉问题转换成代码修改。
Agent 基准测试的成绩也不只取决于语言模型本身。以 SWE-Marathon 为例，模型需要在代码仓库中读取文件、调用终端、修改代码并通过测试验证结果，完成率会受到 Harness 的直接影响。Harness 负责组织工具接口、管理上下文、保存任务状态和处理异常，上下文管理和错误恢复机制都会影响长任务能否持续。Meta 官方 Model Card 说明，在该项评测中，GPT-6 Astra 和 Claude Fable 5.1 分别使用 Codex 与 Claude Code 执行系统，因此并非统一 Harness 条件下的受控比较；Muse Wonder Full 的 57.5 分还使用了 xhigh 推理档位。
Meta 在 Muse Wonder 官方技术文章中专门设置了 Capabilities That Generalize 章节。据雷峰网报道，Meta 指出，两个模型即使在常见基准测试中取得相似成绩，处理陌生任务的能力仍可能存在较大差距。团队将测试任务分为 Post-training 重点优化的 In-distribution 任务和未做针对性优化的 Out-of-distribution 任务，并比较 Muse Spark 1.3 与 Muse Wonder Full 在不同推理预算下的表现变化。Meta 公布的实验结果显示，Wonder Full 在陌生任务上的表现相比前代模型的对应趋势有所提升，Meta 认为这与更强的基础模型有关。
有观点认为，单个熔岩灯失败只能说明模型没有完成当前任务，无法直接证明其针对公开题库过度优化。更合理的判断方式是在相同执行条件下逐步改变任务分布，例如先测试模型能否修复陌生仓库中的 Bug，再要求它使用未见过的 API 构建程序，随后加入缺少明确测试脚本的视觉开发任务。对于熔岩灯这类任务，除了检查最终画面，还应记录模型是否主动使用截图工具、能否识别材质与几何错误，以及获得反馈后能否作出有效修改。