Meta 在 10 月 12 日 推出 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，即针对基准测试大量优化，成绩好看但遇到陌生任务就露怯。

马斯克也在相关帖子下回复了一个词 Hmm，虽未明确表态，却让争议更添戏剧性。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 场景相同的训练投入。

Agent 高分已包含模型之外的系统能力

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 成绩可能对应完全不同的工程体验。

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，换一个未曾接触过的代码仓库，仍然属于相近的软件工程任务。如果进一步更换编程框架、引入陌生 API，模型就需要重新理解工具环境。而制作 3D 熔岩灯，除了软件开发，还引入了空间建模、材质渲染和视觉质量判断，对能力组合提出了更大的变化。因此，分布外泛化不能只用一个综合平均分来描述。不同任务之间的距离、需要补充的知识以及评价结果的方法，均会影响模型表现。

判断模型是否存在严重的 Benchmark 过拟合，也需要系统性实验。单个熔岩灯失败只能说明模型没有完成当前任务，无法直接证明它针对公开题库进行了过度优化。更合理的方法，是在相同执行条件下逐步改变任务分布。例如，先测试模型能否修复陌生仓库中的 Bug，再要求它使用未见过的 API 构建程序，随后加入缺少明确测试脚本的视觉开发任务。这样既可以观察模型在软件工程内部的能力迁移，也能检查它跨越任务类型时出现的性能变化。评测还可以进一步改变环境约束，例如临时替换工具接口、引入新的错误信息，或者要求 Agent 自行设计验证程序。这些设置能够检验模型面对陌生条件时，是否具备阅读文档、建立方案、验证假设和修正错误的能力。对于熔岩灯这样的任务，除了检查最终画面，还应该记录模型是否主动使用截图工具、能否识别材质与几何错误，以及在获得反馈后是否能够作出有效修改。相比单纯统计成功率，这类执行轨迹更有助于判断 Agent 的能力缺口，也能够区分知识不足、工具错误和反馈机制失效等不同原因。

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

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

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

未来的 Agent 研发仍会继续强化 Coding、工具调用和长任务执行，但当模型逐渐能够承担独立的软件工程工作时，它需要处理的问题会不断超出既有训练任务的范围。届时，能否识别陌生环境中的问题、自行建立有效的验证方法，并通过反馈持续修正执行策略，将直接影响 Agent 可以承担多大范围的实际工作。一盏熔岩灯没有给出 Muse Wonder 的完整能力答案，却提供了一个具体的提醒：模型在熟悉任务中取得的成绩，与它在未知环境中能够独立完成的工作，仍然需要分别检验。