2026 年 9 月 2 日，Meta 超级智能实验室（MSL）发布了 Muse Spark 1.3——这是 4 月 Muse Spark 系列首秀之后的第三个版本，官方口径是"迄今最强"，并声称其编程能力已经超过 GPT-5.6 Sol。与模型一并开放的是付费 Muse API，开发者从发布当天起就能接入。
这篇文章不复述发布会。我们只解决三个实际问题：怎么快速试到这个模型、API 怎么接进现有代码、以及 1.3 版最值得关注的新能力——单会话并行多工作流——怎么用在真实项目里。
一、先看清楚：1.3 相比 1.2 改了什么
升级点集中在"干活效率"上，而不是单纯刷榜：
| 维度 | Muse Spark 1.2 | Muse Spark 1.3 |
|---|---|---|
| Token 消耗 | 基准 | 减少约 25% |
| 编码任务工具调用次数 | 基准 | 减少约 20% |
| 多任务处理 | 一个任务一个会话 | 单会话内并行推进多个工作流 |
| 安全性 | 常规防护 | 增强对抗性输入与提示注入防护 |
| 上下文 | 100 万 Token | 100 万 Token（不变） |
| 代码风格 | 偶有多余迭代 | 不必要的代码迭代减少，输出更简洁 |
几个点值得展开说：
- Token 降 25% 是真金白银。 对按量计费的 API 用户来说，同等任务量直接省四分之一的账单，这比跑分涨几个点更有体感。
- 工具调用减少 20% 意味着 Agent 循环更短。 如果你的应用是"模型 + 工具调用"的 Agent 架构，调用次数变少既省钱也降低出错环节。
- 提示注入防护加强对把模型暴露给终端用户的产品很重要——这是今年多家厂商被自家 Agent 攻破仓库之后，行业共同的补课方向。
需要提醒：Muse Spark 系列是 Meta 的闭源旗舰，权重不开放，只运行在 Meta 自有云上。想要开源权重请出门左转看 8 月开源的 Muse Glimmer（用 Spark 蒸馏出来的小模型）。
二、第一步：网页版先试手感
不花钱的验证路径：
- 打开 Meta AI 助手（meta.ai 或 Meta AI App），登录 Meta 账号；
- 新模型正逐步整合进 Meta AI 助手、Instagram 和 Facebook，网页版通常会在发布后几天内全量——如果模型选择器里还没有 1.3，等一两天再看；
- 用一道你熟悉的真实编码题测试，建议选"需要多步工具调用"的任务（比如让它读一个仓库结构再改 bug），重点观察两件事：它调了几次工具、中间有没有多余的来回。
建议拿同一个 prompt 在 1.2（如果还能选）和你正在用的模型上各跑一遍。官方宣称的"编程超 GPT-5.6 Sol"是否在你的任务分布上成立，只有自己的 case 说了算。
三、API 接入：付费 Muse API 上手
Muse API 是这次开放的重点。整体接入思路与主流大模型 API 一致（具体端点地址、鉴权方式和价格以 Meta 开发者后台为准，以下代码演示通用接法）：
# 1. 在 Meta 开发者后台创建应用，开通 Muse API，拿到 API Key
# 2. 推荐用 OpenAI 兼容客户端接，迁移成本最低
pip install openai
from openai import OpenAI
client = OpenAI(
api_key="YOUR_MUSE_API_KEY",
base_url="https://<meta-muse-api-endpoint>/v1", # 以后台文档为准
)
resp = client.chat.completions.create(
model="muse-spark-1.3",
messages=[
{"role": "system", "content": "你是一个资深后端工程师，输出直接可用的代码。"},
{"role": "user", "content": "用 FastAPI 写一个带重试和限流的 webhook 接收端"},
],
)
print(resp.choices[0].message.content)
接入时三个务实建议：
- 把模型名抽成配置项。 1.3 这个迭代速度，大概率很快有 1.4，模型名写死在代码里每次升级都要改代码。
- 先小流量灰度。 拿生产流量的 5% 对比现有模型，盯两个指标：任务完成率和每次任务平均 Token 数。
- 留意数据合规。 模型只跑在 Meta 自有云上，涉及敏感代码或用户数据的场景，先过一遍你们的数据出境与合规要求再接。
四、杀手级新能力：单会话并行多工作流
1.3 最值得关注的变化不是跑分，而是支持在同一会话里同时推进多个工作流，无需分开会话。
以前用 Agent 做复杂任务，标准做法是开多个会话/多个 Agent 实例各管一摊，上下文互不通气，合并阶段全靠人。1.3 的思路是让模型自己维护多条并行的任务线，共享同一份上下文。一个可以直接试的场景——代码库大扫除：
prompt 示例：
这个仓库要做三件事，请并行推进，最后给我一份汇总：
1) 把 src/api 下所有 fetch 调用统一加上超时与重试；
2) 检查 package.json 里已废弃的依赖并给出替换建议；
3) 为 utils/ 目录补齐缺失的单测。
每个工作流完成后先汇报改动摘要，等我确认再给出 diff。
实测时建议盯着两点：各工作流之间是否串味（比如把工作流 1 的改动带进工作流 3 的上下文），以及它是否会擅自合并你明确要求分开交付的改动。这类并行能力是新的，行为边界需要在自己的项目里摸一遍再放量。
五、注意事项与常见问题
Q：Muse Spark 1.3 能本地部署吗？ 不能。闭源、只在 Meta 云上运行，没有本地部署选项。需要本地可控的方案，考虑开源的 Muse Glimmer 或其他开源模型。
Q：值得现在就把生产流量切过去吗？ 不建议一步到位。正确的姿势是：网页版试手感 → API 小流量灰度 → 对比任务完成率和成本 → 再决定是否扩量。"编程超 GPT-5.6 Sol"是官方口径，在你的任务上未必成立。
Q：提示注入防护加强了，是不是可以把 Agent 权限放开一点？ 恰恰相反。防护加强说明厂商自己也承认这块是软肋。Agent 的工具白名单、沙箱隔离、最小权限这些基本功一个都不能省——今年 AI Agent 攻陷官方仓库的事故已经给全行业上过课了。
Q：Token 降 25% 是否意味着账单直接打七五折？ 方向对，但别简单线性折算。工具调用次数也变了，提示注入防护可能带来额外的系统侧开销，最终以你自己的灰度数据为准。
小结
Muse Spark 1.3 是一次务实的迭代：Token 省 25%、工具调用少 20%、单会话并行多工作流，再加一层提示注入防护。它没有开源权重，但付费 Muse API 让普通开发者第一次能直接把 Meta 的最强模型接进自己的应用。建议按"网页试 → API 灰度 → 数据说话"三步走，别被跑分和通稿带节奏——在模型能力趋同的 2026 年下半年，谁帮你把活干完、账单更薄，谁就是好模型。