Muse Spark 1.3 教程：上手开发者指南

Meta 于 2026 年 9 月 2 日发布 Muse Spark 1.3，升级说明只有一句话：改模型 ID。也就是说，它用的是同一套接口、同一套 SDK、同一套定价。

按照 Meta 的说法，这一行改动换来的是：在完成相同任务时，工具调用大约减少 20%，令牌消耗减少 25%，相较 Muse Spark 1.2。这个数字来自 Meta 自家工程师的对比，但没说具体任务，也没有方法学说明。

这种说法，恰恰是我在转述前想亲自验证的类型。 

于是我安装了 Muse Code，故意把一个真实的开源项目“搞坏”，并在两个模型上分别跑了相同的三个任务。

要跟着这篇 Muse Code 教程操作，您需要一个 Meta 开发者账号、一套您顺手的终端环境，以及用于运行 Muse Code 代理的 macOS 或 Linux。目前的测试版里，Windows 用户依然无缘。

一句话总结

• Muse Spark 1.3 是 Meta 的旗舰多模态推理模型，于 2026 年 9 月 2 日发布，具备 100 万令牌上下文窗。
• Muse Code 默认以 muse-spark-1.3-contributor 起步，这意味着除非您切换，否则 Meta 会用您的代码进行训练。训练是默认加入而非主动同意。
• 在 3 个编码任务共 6 次运行中，1.3 在 2 个任务上更便宜，在第 3 个任务上贵了 38%，整体净成本上升 12%。
• 在 1.3 占优的 2 个任务中，模型补全次数分别下降 23% 和 32%，与 Meta 的工具调用说法一致。未缓存输入在 3 个任务上均下降，但从未达到 25%。
• 命令行界面（CLI）和会话内选择器里都出现了 ultra 推理等级，但后端会以命名功能门的方式拒绝。

Muse Spark 1.3 是什么？

Muse Spark 1.3 是 Meta 超级智能实验室于 2026 年 9 月 2 日发布的旗舰多模态推理模型，面向长时智能体会话和大仓库代码工作。它可容纳 1,048,576 个令牌的上下文，接受文本、图像、视频与文件输入。

与 Muse Spark 1.2 相比，有六点变化：

• 效率。根据 Meta 的内部对比，工具调用约少 20%，令牌约少 25%。
• 协作。在模糊提示上会提出澄清问题，并在关键操作前确认。
• 单线程多任务，中途发送的消息会附着到您本意的任务上。
• 长指令跟随，在多步工作中更少丢失约束。
• 更好的校准用于不可逆操作。
• 更干净的编码风格。更少无谓回合，冗长度更低。

看起来一切都不错，但 Meta 公布的评分表是拿 max 推理的 Muse Spark 1.3 对比 xhigh 推理的 Muse Spark 1.2，而且 max 在发布时仍被门控。 

Artificial Analysis 给量产的 xhigh 变体打了 Intelligence Index 61，max 是 62。只有 1 分差距。

Matt Crabtree 已在他的 Muse Spark 1.3 发布分析 中覆盖了完整基准表、价格拆分，以及与 GPT-5.6 Sol 和 Claude Opus 5 的对比。我不重复。下面讲实际安装并让它跑起来的过程与结果。

如何访问 Muse Spark 1.3

有三条路径，适合与否取决于您在构建什么。先看表格，再跳到对应小节。

Muse Code，终端代理

Muse Code 是 Meta 的终端编码代理，macOS 与 Linux 测试版。它是运行 Muse Spark 的“安全带”，两者独立发版，所以 muse --version 并不能告诉您正在对话的是哪个模型。请在脑中分开对待。

curl -fsSL https://dev.meta.ai/install.sh | bash

这会拉取一个 230 MB 的二进制，并放到 ~/.local/bin/muse，而这并不总在每个人的 PATH 中。 

然后检查装了什么：

muse --version

在 2026 年 9 月 4 日，这给我的结果是 Muse Code 1.0.2 (1.0.2-R2040.1)。 

对于一个测试版来说，这个表述有点奇怪，因为几周前第三方工具还在将 Muse Code 记录为 0.2.1。无论拿到哪个版本，都请把它与日期一起固定下来。

作者截图。 用一行脚本安装 Muse Code，然后在 macOS 上确认版本为 1.0.2。

现在运行 muse。第一次，它打印 Not logged in. Run muse again to log in 并退出。所以您要运行两次，这种小细节会让人误以为安装坏了。

第二次运行会启动 OAuth 设备流程。它会打印一个含短代码的登录 URL，另行显示同一代码，并请您在浏览器中批准前确认两者相符。

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

然后您应当会看到如下界面： 

作者截图。Meta Model API 登陆流程，在发放凭据前确认账号信息。 

浏览器端会确认您的姓名、接受条款并收卡。请在支付页面阅读定价面板，而不是直接点过去，原因大约三十秒后就会明白。

默认层级会用您的代码训练

回到终端，会话头部会告诉您正在运行什么：

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

再读一遍模型名。贡献者（contributor）变体，被设为默认，在全新安装上，没人征询就生效。

Meta 并没有藏着掖着。披露就写在模型名下面，支付页面也把 contributor 标注为 DEFAULT，状态栏在您工作时会一直显示 muse-spark-1.3-contributor。

但这跟大多数开发者的心理预期相反，负担被倒置了。

如果您在客户仓库内打开 Muse Code 并开始工作，您已经把代码发往了一个可参与训练的端点。请在第一次提问前看状态栏，而不是之后。

作者截图。 第一次 Muse Code 会话，默认模型设为 muse-spark-1.3-contributor，下方为产品改进披露。

状态栏还显示推理力度，我这边是 high。不是 xhigh，也就是 Artificial Analysis 基准测试的那个变体。在对照任何公布数字时，请记住这一点。

选择与切换层级

运行 /model 会出现一个交互式选择器，包含四个选项及其费率。这些数字与 Meta 自家的支付页面一致：

Contributor 在输入上大约便宜 12 倍，输出便宜 21 倍。

买下这份折扣的是您的知识产权（IP）。Meta 的表述是“您的内容（包括跨会话消息）可用于产品改进”，覆盖的不止您交给它的代码。

Muse Spark 1.2 的两个变体仍在选择器里，价格完全相同，这对后面的对比很重要：既然代际之间的费率不变，那么令牌对比就是成本对比，无需归一化。

作者截图。 /model 选择器展示四个 Muse Spark 变体的缓存、输入与输出费率。

若要退出，请上箭头选到 muse-spark-1.3 并回车。头部的“Discounted tokens”提示会消失。

对于客户项目，有一个更强的选项，但不会在终端里出现。Meta 表示它已 开始接受零数据留存（zero data retention）请求，通过销售渠道处理，而非开关切换。 

留存和训练是两个独立问题，代理合同通常需要分别作答。

限流在不同层级上的机制不同，但来源说法不一。Meta 的开发者博客称贡献者层按滚动 5 小时窗口内的令牌数限流，而非请求数。1.2 发布时的媒体报道则说是每分钟 60 个请求上限，这是完全不同的机制。一个下午我跑了大约 90 个模型补全，二者都没撞上。

Meta Model API 与 OpenRouter

Meta Model API 兼容 OpenAI SDK，所以迁移只需改模型 ID，客户端代码不变。模型 ID 是 muse-spark-1.3 和 muse-spark-1.3-contributor。

OpenRouter 用的 slug 是 meta/muse-spark-1.3。这会带来代价：OpenRouter 实测吞吐约 81 token/s，而 Artificial Analysis 直连记录的是 182；前三天可用性约 92%。提供方只有 Meta，一旦出问题没有第二家可切换。

您的第一个 Muse Spark 1.3 会话

下文所有操作都针对 python-humanize/humanize，固定到提交 823ad6096。它包含 6 个模块、共 1,676 行源码，测试套件一秒内可跑完，领域无需解释。此处不修改仓库。 

这些是只读问题，用来观察代理在我交给它写入权限前，如何探索代码库。

先用两个提示感受它如何读代码，先从第一个开始： 

Map the dependency graph of this project and tell me which module has the most inbound imports.

它运行了两个命令，列出了项目结构，然后写了一个 AST 解析器，而不是直接 grep import。答案：i18n 有 4 个入向导入，细分为 i18n 4、number 2，filesize、lists、time 和 _version 各 1。

我用自己的脚本检查，得到不同数字，看起来像抓住了把柄。错的是我的脚本。它只统计了相对导入（from ._version import ...），漏掉了绝对形式（from humanize.i18n import ...），而这个包多数采用绝对导入。模型两种都处理了。

第二个提示才是真值得跑的，因为您能打分：

List every public function in src/humanize, grouped by module, with a count per module.

它回答总计 20 个：filesize 1、i18n 5、lists 1、number 8、time 5。全部正确。然后它还未被要求地补充说，i18n.get_translation 名义上是公开函数，但没出现在 i18n.__all__ 中，该变量只导出了其他四个。也正确。

这次会话 8 个回合花了 $0.01。

Meta 没怎么提的那个推理等级

muse --help 有如下文档：

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

会话内的 /effort 选择器提供了七个中的六个，去掉了 none。 

作者截图。 /effort 选择器列出了六个可选推理等级，high 标注为当前。

两处都列出了一个名为 ultra 的等级，但任何 Meta 公告里都没出现。Meta 的公开表态是 max 推理“将在完成额外安全测试后不久推出”。

于是我请求了它：

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

存在一个命名功能门 ultra_reasoning_effort，目前是关闭状态。能力已经做了，服务端的开关是关的。这比“等待安全测试”更具体，而且它出现在一条包含“tbh”的警告里。

两个实用点：客户端在 CLI 与选择器里都展示了后端不会提供的等级；并且它会静默降级到 xhigh，只在 stderr 打一行提示，在脚本或 CI 日志里很容易被刷过去。您会以为自己跑的是配置 A，而实际是配置 B。

然后我试了一个文档里从未出现过的值：

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

没有任何警告。它运行并返回了 ok。所以，一个未文档化的值能悄无声息地通过校验，而一个有文档的被门控；而且您从输出无法判断实际服务的是哪个力度。

作者截图。请求 ultra 会返回功能门关闭并静默降级到 xhigh，而未文档的 max 则毫无提示地通过。

如果您在意运行的是哪个推理等级，请显式设置并阅读 stderr。不要假定传入的旗标就是被采用的旗标。

Muse Spark 1.3 的效率说法站得住吗？

测试方法如下：取一个开源仓库，回滚一个真实的修复提交，使测试套件确实失败；然后在两个模型上用相同提示和相同参数跑三个编码任务。

这三个任务不同于上面的探索会话。每个都会写代码。

回滚提交 823ad6096 的源码部分，同时保留其测试，会留下 6 个失败用例，这是初始状态：

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

每次运行都用相同命令形状，只改模型 ID 和提示：

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

任务 1，修 Bug。 

成败是二元的：6 个测试要么全过，要么不过。 

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

任务 2，小特性。

留有足够空间让两个模型在范围上意见不一，事实证明这点很关键。

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

任务 3，重构。

三者中最重，涉及多个文件。

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

三个任务串行运行，中间不复位，因此任务 2 和 3 都建立在模型此前产物之上。两个模型走的路径相同。

令牌统计来自 ~/.local/share/muse/sessions/ 的会话日志，每次模型补全统计一次。六次运行全部通过测试。

再看差值，负数表示 1.3 用得更少：

诚实解读结果

三项中有两项更便宜，模型补全次数分别少 23% 和 32%。这与 Meta 的工具调用说法完全对得上。然后重构相反：补全次数多 70%，成本多 38%。

三个任务合计，1.3 比 1.2 贵了 12%之多。因此，效率说法是真实的，但依赖任务，一句标题数字会把这种差异彻底抹平。

未缓存输入在每项任务上分别下降 19%、22% 和 5%。从未达到 25%。 

Meta 没说它统计的是哪类令牌，而答案会因您统计输入、输出、未缓存还是总量而差很多。

缓存命中率在 88% 到 97% 间，并随任务长度上升。如果只报原始输入令牌而不区分缓存与未缓存，意义几乎为零，因为重构的 418 万输入其本质是 10.9 万新上下文加 407 万次重读，后者按五十分之一费率计费。

为何重构不算纯粹的失利

在给它判“低效”之前，先看看 1.3 在这个任务上实际做了什么。

它逐块、以编程方式验证了每个移动的代码段与原始版本字节级一致。 

它在两个新文件上跑了 --doctest-modules。它在 /tmp 的一次性目录里测试了导入解析。然后还指出了两点没人要求的内容：humanize.scientific 这个函数与新子模块同名而形成遮蔽；以及一个 naturaldelta 的 doctest 在原始仓库上同样失败，因此该失败不归因于本次变更。

Muse Spark 1.2 复制了一个辅助函数以回避循环导入，然后继续。1.3 则直接导入并解释了为何不会成环。

在这种设计下，“烧了更多令牌”和“做得更彻底”是分不开的。诚实的说法是，1.3 花得更多，也交付得更多，是否划算取决于您是否需要这些额外的严谨性。

特性任务则呈现相反模式，也是 Meta 所谓“更少冗长”的最清晰例子。Muse Spark 1.2 发明了没人要的参数别名 max_items、n 和 max_len，并写了 28 个测试。 

Muse Spark 1.3 写了一个带合理默认值的签名和 20 个测试，输出令牌减少 54%。

我无法控制的因素

四点，如实交代不可少。

1. Muse Code 在中途从 1.0.2 自更新到 1.0.3，因此六次运行的“安全带”并非完全一致。 
2. 任务 2 与 3 都从各自模型先前产物出发，而非字节级相同的树，因为序列是无复位运行。
3. 每个单元都是一次试验，未测量常见的次次差异。 
4. 我全程使用的是贡献者层级，模型相同，数据条款不同。

这些都不改变结果的方向性。但这意味着 12% 的总体差异，作为信号强度，不如每格做三次重复那么扎实。

Mose Spark 1.3 最佳实践与故障排查

一些我第一天就希望知道的事。

为协作行为而提问

Muse Spark 1.3 会在含糊提示上提出澄清问题，因此过度细化的提示会关闭一个您正在付费购买的能力。如果您花了两年时间学习把所有指令预先塞满，这会有点反直觉。

不过，范围依然重要。“把 number.py 拆开”会让模型去猜边界、导入更新、何为完成。我实际用的版本把这三点写清楚了：

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

还有一件值得知道的小事。我的重构提示写的是 number.py is 571 lines。实际是 567。两个模型都在未被要求的情况下纠正了我，1.3 在开头句就指出。我的数字来自测量仓库最新而非固定的提交。

控制成本

把提示中稳定的部分放在前面以便可缓存。在 88% 到 97% 的命中率下，您的缓存行为对账单的影响远大于模型选择。

三个任务在贡献者层合计 $0.034。在标准层做同样的工作要 $0.91，差 27 倍。这就是层级决策换算成钱：三分钱对九毛钱。

如果通过 OpenRouter，网页搜索单独计费，每 1,000 次调用 $2.50。

什么时候不该选 Muse Spark 1.3

• 未公开推理轨迹。您能看到它做了什么而非为什么，这会让糟糕的重构更难调试。
• Max 推理被门控，因此每个标题基准数字背后的配置目前不可用。
• 闭源权重。不可自部署、不可微调。Meta 的路线图提到“ Muse Spark 开源权重发布”，但无版本、日期或许可信息。
• 唯一提供方。当 Meta 的端点退化时，没有可路由的去处。

常见问题与修复

• muse: command not found 在全新安装后出现。 脚本安装到 ~/.local/bin/muse，这并不在每个 shell 的 PATH 中。
• Not logged in. Run muse again to log in。字面意思。第一次 muse 退出，第二次开始登录。
• 您在贡献者层级却不是您选的。那是默认。打开任何私有内容前，先看状态栏并运行 /model。
• ultra 推理静默变成 xhigh。 功能门是关的。别只信传入的旗标，读 stderr。
• Muse Code 在会话中途自更新。 我的是从 1.0.2 到 1.0.3。如果您要做任何测量，请固定并记录版本。

一件没有复现的事

有报道说，欧盟用户在 1.3 发布后仍被服务到 Muse Spark 1.1。我在荷兰跑完了所有内容，始终拿到 1.3。那些报道涉及的是 Meta.ai（面向消费者的助手），似乎不适用于 Muse Code 或 Model API。两次不同的发布节奏。

结语

Meta 的效率说法在我的三个任务中有两个成立，第三个相反，整体来看成本上升 12%。在 1.3 占优的任务中，工具调用减少 23% 和 32% 这点相当扎实。令牌侧完全取决于您统计哪类令牌。

如果您已经在用 Meta Model API 或 Muse Code，更换模型 ID 只需一分钟，例行工作大概率会更划算。如果是为生产级智能体做新选型，被门控的 max 变体与缺失的推理轨迹，是可以让人再等等的具体理由。

我真正会据此行动的并非效率数字，而是：Muse Code 默认把您放在可训练层；以及一个有文档的推理等级在您请求时会静默降级。这两者都是一行即可检查、也很容易忽略的点。

请在您自己的工作负载上做对比。我的三个任务不是您的三个任务，它们之间的差异比模型之间的差异更大。

要看完整的基准，Matt 的 Muse Spark 1.3 发布分析 有表格。要建立自行评估此类模型的能力，请从我们的 AI Agent Fundamentals 技能路径开始。