Muse Spark 1.2 实测表现：基准数据、编程能力与版本选择

Muse Spark 1.2 是一款明显偏向编程与长流程任务的多模态推理模型。它在 2026 年 8 月 5 日与 Muse Code 同期发布，相比 1.1 加强了代码生成、复杂调试、代码库理解和持续数小时的智能执行任务。它的优势是 1M 上下文、较强的终端任务成绩和完整的音视频理解；不足是公开成绩高度依赖运行工具，长任务仍需人工验收，而且在 1.3 已发布后，它不再是新项目的默认首选。

图：Meta AI Research 发布 Muse Code 与 Muse Spark 1.2 的官方页面，日期为 2026 年 8 月 5 日。截图于 2026 年 9 月 23 日获取，来源：官方发布页。

Muse Spark 1.2 更新了什么？

1.2 不是一次面向普通聊天的小修小补。Meta 把它与 Muse Code 一起训练，目标是让模型适应代码读取、计划制定、工具调用、文件修改和结果验证组成的完整循环。官方将变化概括为四个方面：

• 代码生成与调试：增强跨文件修改、复杂故障定位和代码库理解；
• 长流程执行：使用计划、目标约束和上下文压缩，让任务在较长时间内保持方向；
• 工具协作：支持异步与并行调用，减少等待某一个工具返回时的空转；
• 多模态开发：可读取图片、视频、音频和 PDF，并把其中的信息转化为代码或操作步骤。

这里最关键的是“与运行工具共同训练”。同一个模型放进不同的终端智能工具，表现可能明显不同。Muse Spark 1.2 在 Muse Code 中通常更能发挥训练时形成的计划和工具习惯，换到其他兼容工具后仍可使用，但不应默认获得完全相同的结果。

官方基准测试表现

Muse Spark 1.2 首发时，Meta 公布了三项主要编程评测。下表采用首发图表中的结果，并保留测试环境差异：

在首发对比中，Muse Spark 1.2 的 Terminal-Bench 2.1 成绩高于上一代 1.1 的 76.2%，提升 6.7 个百分点；DeepSWE 1.1 则比 1.1 提升约 6.3 个百分点。这说明 1.2 的训练确实集中改善了编程智能执行能力，而不是只调整接口或命名。

但，官方当前 1.3 模型页对 1.2 的对照数据中，DeepSWE v1.1 又显示为 55.0。这个差异可能来自评测版本、运行工具或统计口径变化。文章或选型报告引用数据时，应同时写清发布日期与测试设置，不要把不同页面的分数直接拼成同一张榜单。

独立评测给出了什么信号？

Artificial Analysis 的发布评测给 Muse Spark 1.2 xhigh 档位的 Intelligence Index 打出 54 分，比 1.1 的 51 分提高 3 分。其评测还显示，模型在知识问答中更愿意放弃没有把握的回答：尝试回答的比例从 82% 降到 67%，错误编造比例从 38% 降到 28%。

这组变化有两面性。好处是模型更谨慎，少把不确定信息写成确定事实；代价是部分用户会感觉它更容易停下来、询问或拒绝继续猜测。对于代码修改和带外部工具的任务，这种克制通常比流畅但错误的输出更有价值；对于开放式创作，它可能显得不够主动。

独立评测与官方评测都指向同一结论：1.2 相比 1.1 有进步，但并没有在所有项目上领先。它的竞争力更多来自“足够强的能力、较长上下文和相对可控的使用成本”组合，而非每个榜单都拿到最高分。

具体使用时是什么感觉？

处理小任务：能力够用，但优势不明显

在单文件修改、短函数生成或普通问答中，1.2 的长流程训练不一定能体现出来。它仍会先规划再操作，在任务很简单时可能显得步骤偏多。Meta 在 1.3 发布说明中提到，新版比 1.2 少用约 20% 的工具调用和 25% 的 tokens，也从侧面说明 1.2 在部分工程任务上存在绕路和输出偏长的问题。

处理大型代码库：更适合给目标，而不是给每一步

1.2 的强项是接受目标、检查代码库、形成计划并持续修改。1,048,576 tokens 的上下文窗口能够容纳大量代码和项目说明，配合上下文压缩可在长会话中保留关键信息。具体使用时，最好先给出验收条件、不能修改的范围和测试命令，让模型自行安排过程。

但“1M 上下文”不等于把整个项目一次性塞进去就会更准确。重复日志、构建产物和无关依赖会稀释注意力。更稳妥的做法是让工具按需读取文件，同时在任务说明中列出关键模块与边界。

调用工具：在 Muse Code 内更自然

Muse Code 的事件记录会保存模型调用、工具操作、审批和文件修改，任务中断后能够继续。多个后台智能体能够并行搜索、实现和检查，这与 1.2 的训练方式匹配。对于需要分析多个互不冲突模块的工作，并行执行能够节省时间。

若多个分支会修改同一文件，仍需控制并行范围，否则可能产生冲突。工具调用成功也不代表最终实现正确，尤其是配置迁移、依赖升级和数据变更，必须运行项目自己的测试并检查差异。

多模态输入：1.2 仍有一个现实优势

Muse Spark 1.2 支持文本、图片、视频、音频和 PDF 输入。官方文档特别注明，1.3 的音频理解尚未完整支持，音频请求可能出现质量下降。所以，需要直接分析带声音视频或音频内容时，1.2 仍可能比 1.3 更合适。

官方演示中，1.2 能够读取房屋浏览视频并生成预订页面，也能把视觉布局转成网页代码。这说明它适合“看素材后制作”的任务。演示结果仍是经过选择的案例，正式项目应另外检查响应式布局、交互状态、素材许可和代码维护性。

Muse Spark 1.2 的优点

1. 面向完整开发流程训练：不只生成代码，还覆盖计划、修改、运行和检查。
2. 上下文容量大：适合长文档、大型代码库和较长的任务记录。
3. 多模态输入完整：尤其适合仍需要音频理解的工作。
4. 接口兼容性较好：可通过常见的 Responses、Chat Completions 与 Messages 形式接入。
5. 标准版数据规则清晰：官方说明标准版提示词与输出不会用于训练 Meta 模型。

需要留意的不足

1. 不再是最新版本：官方已把 1.3 设为新项目推荐版本。
2. 公开分数依赖运行环境：Muse Code、其他终端工具和裸接口结果不可直接等同。
3. 长任务成本容易被低估：多轮推理、工具返回内容和失败重试都会增加 tokens。
4. 工具调用并非结果保证：模型可能完成操作，却没有满足隐含需求或边界条件。
5. 首发数据存在口径变化：引用评测时必须保留页面日期和测试方法。

现在还值得选择 1.2 吗？

若项目主要处理音频或带声音的视频，或者现有流程已经围绕 1.2 完成验证，继续使用具有合理性。需要稳定复现旧结果时，也不应只因为出现新版本就立即切换。

新建的编程智能执行项目则应先测试 1.3。官方数据显示它在长流程、指令保持和工具效率上继续提升，并把 1.2 保留为上一版本。迁移前能够用同一批真实任务比较完成率、总 tokens、工具调用次数、人工修正时间和失败恢复能力，再决定升级。

综合来看，Muse Spark 1.2 是一次有效的工程型升级：终端任务成绩突出，多模态输入完整，长流程能力比 1.1 更成熟；它的短板也很明确，部分优势依赖 Muse Code，公开分数不能代替项目验收，执行过程比 1.3 更容易出现冗长。把它用于适合的长任务会比用来做普通聊天更能体现价值。