Muse Code 对比 Muse Spark 1.1：Meta 的 6.7 分升级实际上在衡量什么

先做减法。Meta 为其终端编码智能体 Muse Code（2026 年 8 月 5 日发布）制作的发布演示文稿显示，Muse Code 在 Terminal-Bench 2.1 上取得了 82.9% 的成绩，并称这比 Muse Spark 1.1（阅读本文的大多数人已经在为这款模型付费）高出 6.7 个百分点。用 82.9 减去 6.7，得到 76.2——这不是 Meta 公布的数字，但恰好就是公开的 Terminal-Bench 2.1 排行榜上 Muse Spark 1.1 在 xhigh effort 下的得分，该成绩于 7 月提交，由普林斯顿大学的 mini-SWE-agent 测试框架运行得出。

这种巧合是这次比较中最有用的事实，因为 mini-SWE-agent 是一个刻意保持极简的脚手架——只有几百行代码，没有持久化的子代理，没有事件日志，也没有规划能力。Meta 的 82.9% 是Muse Spark 1.2运行于一个 Meta 与模型共同训练的专用代理之中的结果。如果这 6.7 个百分点的差距就体现在这两行之间，那么主打的代际提升就是模型升级和代理框架升级捆绑在同一个数字中，而 Meta 没有发布任何能区分两者的内容。

Meta 并未说明其 1.1 基线使用了哪种测试框架，因此这一匹配只是暗示性的，而非确证。但它重新框定了当前通过 API 调用 Muse Spark 1.1 的人所面临的决定——这才是这场对比的诚实版本：你不是在两个模型之间做选择。你是在一个由你自己驱动的模型和一个替你驱动更新模型的智能体之间做选择，而这两者中只有其中一个被 Meta 以外的机构评估过。

这些不属于同一类别，规格表上也是这么说的。

围绕这一配对的困惑，有一半来自于把 Muse Code 当作模型发布版。它不是。它是一个 CLI，而它调用的是 Muse Spark 1.2。

• 它是什么 — Muse Code 是一款终端代理，可通过一行命令安装（curl -fsSL https://dev.meta.ai/install.sh | bash）；Muse Spark 1.1 是一个模型端点，你可以从自己的代码、自己的代理框架或任何接受自定义基础 URL 的 CLI 中调用它。

• 底层模型 — Muse Code 运行 Muse Spark 1.2，它与代理共同训练；Muse Spark 1.1 是七月版本，仍在提供服务，也仍在列表中。

• 运行环境 — Muse Code 仅支持 macOS 和 Linux，仅限终端，无图形界面，无 IDE 扩展；Muse Spark 1.1 可在任何支持 HTTPS 的环境运行，包括 Windows。

• 输入Muse Code 接收代码仓库和提示词；Muse Spark 1.1 可在单个 1,048,576 token 的上下文中接受文本、图像、视频、音频和 PDF 文档，并返回文本。

• 状态 — Muse Code 目前为公开测试版，并已如此标注；Muse Spark 1.1 自 2026 年 7 月起已全面上线，正在承载真实的生产流量。

• 标价——两者均通过 Meta Model API 计费，标准层级下每百万输入 token 收费 1.25 美元，缓存输入 0.15 美元，输出 4.25 美元。费率卡是相同的费率卡。

最后一行是最让人意外的，它推翻了一个显而易见的假设。采用 Muse Code 的每 token 成本并不高于你当前运行所用的。它所付出的代价是以其他“货币”来衡量的——平台支持、延迟、模态，以及在低价档位上，你的源代码。这四个维度才是真正值得争论的。

它们产生分歧的基准测试，在连接测试工具的情况下进行解读。

Meta 发布了相对于 Muse Spark 1.1 的两个代际增量：在 Terminal-Bench 2.1 上 +6.7 分，在 DeepSWE 1.1 上 +6.3 分。两者均为厂商自行报告，均来自以图片形式发布的图表，没有附带方法论说明，且均未经第三方复现。将它们剔除后，Meta 所隐含的 1.1 基线大约为 76.2% 和 53.0%。

现在，将 Meta 的 82.9% 与它未引用的榜单放在一起。截至撰写本文时，公开的 Terminal-Bench 2.1 榜单显示，Claude Code 搭配Claude Fable 5达到 83.8% ± 1.2%，Codex 搭配GPT-5.5达到 83.1% ± 1.1%，Terminus 2 搭配 Claude Fable 5 达到 80.4%，Cursor CLI 搭配Grok 4.5达到 79.3%，mini-SWE-agent 搭配 Muse Spark 1.1 以 76.2% 位列第八。Muse Code 自称的 82.9% 将位列第三——低于两个在 Meta 的演示文档中完全未出现的 agent-模型组合，而 Meta 的演示文档反而比较的是Claude Opus 5达到 86.7%，GPT-5.6 Terra在最大努力下的单独运行中，与 Grok 4.5 分别达到 81.8% 和 81.6%。

两块榜单，同一项基准测试，数字却对不上——如果再看看 Artificial Analysis，还会看到完全不同的第三种尺度；其对 Terminal-Bench v2.1 的独立评测显示，GPT-5.6 Sol 的最高得分接近 89.5%，而公开排行榜的天花板为 83.8%。这些相关方都没有撒谎。Terminal-Bench 上的一行记录，是测试框架、模型、推理努力设置和算力配额的组合得分；其中任何一项发生变化，结果产生的波动都超过 Meta 所宣称的一代模型之间的全部差距。

这就是为什么公共榜单上值得关注的数字不是准确率一栏，而是成本一栏。Muse Spark 1.1 以 76.2% 的准确率完成测试，成本为 $198.05。Claude Code 搭配 Claude Fable 5 以 $552.67 获得了 83.8% 的准确率，而 Codex 搭配 GPT-5.5 则支付了 $2,059.19，获得 83.1% 的准确率。也就是说，前者多花了 2.8 倍的钱换来 7.6 个百分点的准确率提升，后者则大约是 10 倍——这是在同一个操作者、同一批任务、同一套规则下测得的，正是 Meta 的图表无法提供的公平对比。该榜单还会对通过钻环境空子完成的任务扣分；Muse Spark 1.1 的提交没有任何扣分，而 Cursor CLI 的 Grok 4.5 运行则被扣了 9 个百分点。

Meta没有公布其82.9%的成本数字。

Muse Spark 1.1 已经能做到而 Muse Code 无法做到的事情

Muse Code 的卖点在于，一个协同训练的智能体胜过“外部模型之上的通用包装器”——这是 Meta 的原话，也是 Meta 的主张，但尚未经任何其他人验证。这是一个合理的说法。它同时也瞄准了一个 Muse Spark 1.1 专门为填补而构建的缺口。

Muse Spark 1.1 原生支持模型上下文协议，无需外部框架即可自行处理 MCP 连接，在内部协调主代理与子代理角色，并能零样本泛化到新工具和自定义技能。Meta 自己公布的首发数据是工具使用数据：MCP Atlas 上为 88.1（用于规模化工具使用）——高于其报告的 Claude Opus 4.8 的 82.2 和 GPT-5.5 的 75.3——以及在 JobBench 上的 54.7。所有数据均为厂商自报，全部来自七月，无一经过独立复现。但观点依然成立：1.1 不是那种被人强行挂接代理的聊天模型。把它放入 OpenCode、Cline 或任何支持自定义端点的 CLI，你今天就能拥有一个代理。

此外，还有一切Muse Code在结构上无法触及的东西。{{1}}Muse Spark 1.1可以在一个上下文窗口内对图像、视频、音频和PDF进行推理。{{/1}}终端编码代理用不上这种能力，也没有办法将其暴露出来。如果你的工作负载是将设计稿转化为组件、将一通客服电话转录并分类，或者将一份400页的规格书与实现交叉比对，那么更新的东西反而是能力较弱的那一个——而{{2}}Meta对1.2代的定位从“混合媒体上的多模态深度研究”转向了多文件重构和整个代码库的生成，{{/2}}而且没有任何人发布过1.2版本的视频或音频成果。

真正的非对称性恰恰相反：它是一种运行时属性，而不是一种能力。Muse Code 会把每次模型调用、工具运行、审批和编辑都追加到本地事件日志中，Meta 称这让会话可以精确重放且重启安全——即使崩溃，代理也会从停止的地方继续，而不是重新推导上下文。它的后台代理会跨整个会话持续存在，而不是为每个子任务创建后再销毁。Meta 的证据只有一个案例研究：一次在 NVIDIA Hopper 硬件上优化 GPU 内核的运行，持续24小时、涉及超过1000次工具调用。他们没有公布任何加速数字，所以时长本身就是其宣称的成果。如果你曾因为框架在第300步时忘记了自己在做什么，而丢掉了一场九小时的迁移，那正是你真正需要的东西，而模型里再多的 MCP 支持也给不了你。

标价相同，直到你读到第二档。

由于标准层级在双方是一致的，这场对比中的定价争论完全集中在Meta随Muse Code一同引入的层级上。贡献者层级定价为每百万输入token 0.10美元，缓存输入0.002美元，输出0.20美元——输入便宜12.5倍，输出便宜21倍，缓存输入便宜75倍——以此换取明确许可，允许使用你的提示和补全内容来训练未来的Meta模型。Meta表示，标准层级的流量不会以这种方式使用。

运行一个真实的智能体步骤——60,000 个 token 的仓库上下文输入，3,000 个 token 的计划与补丁输出——那么一千步的成本是：标准层级冷启动为 $87.75，仓库上下文命中缓存为 $21.75，贡献者层级冷启动为 $6.60，贡献者层级缓存预热为 $0.72。Meta 自己 24 小时的内核运行，在保护你代码的层级上接近九十美元，而在不保护的层级上不到一美元。

这不是计费选择。编码代理的提示词就是你的代码库——内部 API、解释变通方案为何存在的注释、你的测试夹具碰巧包含的任何内容。在开源代码树上，贡献者层级带来的收入几乎等于白捡的钱。而在私有代码库上，这是一个披着折扣外衣的数据许可决策，应该摆在负责数据处理审批的人面前，而不是盯着云账单的人面前。Meta 将折扣设定为 12 倍，因为数据对 Meta 来说至少值这么多。

坚持使用 Muse Spark 1.1 可以完全回避这个问题，但值得确切了解这样做的代价是什么、代价在哪里。Muse Spark 1.1 在 OrcaRouter 目录中的价格为 $1.25 和 $4.25——与 Meta 的标价分毫不差，因为我们加价 0%，直接传递供应商定价；这也是为什么 Meta 一调整费率，我们这边当天就会反映，而不是等到一个合同周期之后。我们针对它的七天生产遥测数据显示，p50 首令牌延迟为 1.84 秒，p95 为 6.00 秒，这比任何基准测试框架给你的预期都要有用得多。Muse Spark 1.2 并不在我们的目录中；它由 Meta 直接提供，没有其他渠道，因此在这个对比中，较新的那一方目前恰好只有一个供应商，并且从结构上就不存在故障转移路径。如果你正在评估它，这种单一供应商风险敞口本身就是你评估的一部分。

发射报道中没人提及的延迟权衡

Artificial Analysis 独立测量了各模型在最大推理努力下的表现，测得 Muse Spark 1.1 的首token延迟为 2.90秒，而 Muse Spark 1.2 的为 26.12秒。输出速度从每秒213.5个token降至165个token。所换来的是智能指数提升3分（从51分到54分），以及排名从185个模型中的第22位跃升至第13位。

把它当作通用模型版本来读，这是一笔糟糕的交易——九倍的等待，只换来三个百分点的提升。把它当作编码智能体的引擎来读，它显然是正确的选择：等待十二个文件重构完成的人，不会注意到二十六秒的规划时间；而等待聊天补全的人，却会对这段时间感受得一清二楚。这是对这种对比中每一方各自面向谁最清晰的说明，而且这一结果是第三方测量得出的，而非Meta自行宣称的。

这也意味着，即使你只关心代码，切换也不是免费的。你原本指向 Muse Spark 1.1 的任何交互式功能——内联补全、审查机器人、覆盖文档的聊天界面——在付出巨大努力迁移到 1.2 代之后，都会实质上变得更糟。这次升级是有针对性的，而针对性是有方向的。

你实际上应该运行哪一个

如果你的工作不涉及代码仓库，请继续使用 Muse Spark 1.1。 多模态流水线、长上下文分析、混合媒体研究、任何交互式工作、任何在 Windows 上的工作、任何已经通过 MCP 接入且运行正常的工作。Muse Code 的发布并未改进这些方面，而延迟测量至少会让其中之一变得更糟。

如果您的失败模式是持续时间，请试试 Muse Code。Monorepo 迁移、依赖升级、长达一周的重构——这些工作目前需要您全程盯守，因为代理会失去头绪。事件日志和持久后台代理正是针对这一点，而在运行时间最长的情况下，基准测试差几分影响最小。测试版，在一次性克隆仓库上，在您不介意丢失的仓库上。

如果你想在模型之间做决定，那就做个诚实的实验吧。保持你的测试框架不变，把底层的 Muse Spark 1.1 换成 Muse Spark 1.2。这样就能分离出 Meta 图表中捆绑的唯一变量，也只有这样才能弄清联合训练溢价是真实存在的，还是说 1.2 只是一个无论放在哪里都表现称职的编码模型。通过单一网关，这不过是改个字符串的事，而不是一次采购流程——Muse Spark 1.1、Claude Opus 5、GPT-5.6 Terra、Grok 4.5 和 Claude Fable 5 都共用一个 OrcaRouter 密钥，按标价计费，并在各个提供商之间自动故障转移，所以保留这组对比模型不会让你多花一分钱。Muse Spark 1.2 是个例外，必须从 Meta 获取。

在安装任何东西之前值得提出的问题

我可以让 Muse Code 指向 Muse Spark 1.1 而不是 1.2 吗？

Meta 的发布材料并未说明这一点，而且这两者作为联合训练的配对发布，这本身就说明这种用法既不受支持，也并无用处。不过反向用法倒是记录得很清楚：Muse Spark 1.1 可以在任何接受自定义端点的代理中运行，而如今大多数人正是这样把它作为代理来用的。如果你的目标是进行受控对比，运行 1.1 和 1.2 在你的测试框架中，而不是试图改造 Meta 的那套。

贡献者等级是否也适用于 Muse Spark 1.1？

Meta 随着 Muse Code 和 Muse Spark 1.2 的发布引入了两层结构，其公布的价目表将贡献者定价与该版本挂钩。在 Meta 另有说明之前，假设 12 倍折扣是 1.2 代的优惠，并对任何 1.1 工作负载按 $1.25 和 $4.25 定价。如果你使用 OrcaRouter，按定义你采用的就是标价，因此不存在可选择加入或退出的数据共享层级。

那么，6.7分的说法是错的吗？

不——它既未经审计也定义不清，这是两回事。Meta 很可能是在与 Muse Code 类似的测试框架中运行其 1.1 基线的；若是如此，这一提升就是纯粹的模型对模型结果。但没有公布任何方法论，隐含的基线恰好落在一个极简第三方脚手架的分数上，而且同一个基准由不同的人运行会得出三种不同的标度。把 +6.7 当作方向性参考就好，在围绕它制定计划之前先自己跑出一个数字。

什么能解决这个问题？

一次提交即可。如果 Meta 按照所有人提交时所用的相同规则，将 Muse Code 放到公开的 Terminal-Bench 2.1 排行榜上——不修改超时时间或资源，成本列填写完整，hack 扣分照常执行——那么 82.9% 就能与 Muse Spark 1.1 名字旁的 76.2% 以及榜首的 83.8% 相提并论，整个争论一个下午就能解决。在那之前，这场对决中唯一经过独立验证的数字属于那个较旧的模型，而这个数字表明：Muse Spark 1.1 以不到两百美元的成本，在一个小到可以一口气读完的脚手架内，解决了 Terminal-Bench 2.1 中四分之三的任务。

第二件值得关注的事情范围更窄，而且来得更快：Artificial Analysis 是否会像为 1.1 代那样，为 1.2 代发布编码和智能体子分数。智能体性能是 1.1 已发布维度中明显最弱的一项。这正是 Meta 声称已经修复的指标，也正是 Meta 之外尚未有人测量过的指标。