# Muse Spark 1.3 省下四分之一 Token，但最强模式还得再等等

**Summary:** Meta 称 Muse Spark 1.3 比 1.2 版本减少约 25% 的 Token 和 20% 的工具调用。其经过基准测试的 Max 模式仍在安全测试中，因此在将评分卡视为生产级结果前，我会先测试已发布的模式。

- Canonical: https://markhuang.ai/zh/news/muse-spark-1-3-max-mode-has-to-wait
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-02
- Section: News
- Tags: Muse Spark 1.3, AI 编码代理, 开发者工具
- Source: [Meta AI Research](https://research.meta.ai/blog/introducing-muse-spark-1-3)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![蓝色 AI 核心沿精简的工具路径运转，更亮的路线在琥珀色安全门后等待](https://cdn.markhuang.ai/news/muse-spark-1-3-max-mode-has-to-wait/hero.webp)

*Spark 1.3 把日常任务送进更短的路径，最强推理模式还卡在安全门后面。*

[Meta 已在 Muse Code 和 Meta Model API 中发布 Muse Spark 1.3](https://research.meta.ai/blog/introducing-muse-spark-1-3)。吸引我的不是排行榜：Meta 表示工程师观察到新版本比 Spark 1.2 减少了约 20% 的工具调用和 25% 的 Token。代理循环里每次多余的交互都会增加延迟、成本，还多一次跑偏的机会。

这次发布有点尴尬：现有推理模式现在就能用，新的 Max 模式却要等额外的安全测试完成。偏偏 Meta 基准测试用的正是 Max 配置。Spark 1.3 已经进了我的测试队列，但它的高分还没资格跑生产流量。

## 最有用的数字不是最大的分数

编码代理很少因为基准分低了一点就失败。它失败是因为重复发现了同一个文件、调错了工具、忘了约束条件，或者没检查结果就宣布搞定。Meta 说他们在更多长周期编码任务和不同代理框架上训练了 Spark 1.3，模型也应该更简洁，也更擅长记住详细指令。

比起宽泛的智能排名，20% 和 25% 的减少更让我在意。这些数字指向干活的实际成本。不过 Meta 只说了自家工程师的对比，没给任务量、方差、缓存假设，也没按框架拆解数据。我会把这些数字当可验证的声明，而不是预算预测。

> **Info:**
>
> 我用每分钟审查能完成多少工作来衡量。只有代理同时守住任务要求、用了预期工具、留下可验证结果时，省 Token 才真有用。

## Meta 测的是开发者还用不了的模式

Meta 的评分卡显示，Spark 1.3 Max 在 DeepSWE v1.1 上得了 75.4 分，比 Spark 1.2 xhigh 的 55.0 高不少。Terminal-Bench 2.1 上它拿了 88.8 分，和 GPT-5.6 Sol Max 并列，超过 Spark 1.2 的 82.9。这些都是很强的编码信号，但属于还在等安全测试的 Max 配置。

完整的表格更克制些。Spark 1.3 Max 在 JobBench 上得 64.9 分，Opus 5 Max 是 65.7；GDPval-AA v2 上它得 1,754 分，Opus 5 是 1,824。它在两个长上下文 MRCR 测试和 DeepSWE 上领先，但不是所有代理基准都占优。这张表让模型变得有趣，但没告诉我它在我代码库里会怎么表现。

看 [Artificial Analysis 代理指数](https://markhuang.ai/news/agentic-index-needs-your-failure-test)时我也这么区分：排行榜能筛候选名单，但只有本地失败测试才能选生产模型。这里我还要更进一步，把当前可用的推理模式和 Max 模式分开记录。混在一起会把分阶段发布变成对未验证产品的性能承诺。

## 对 1.2 的抱怨和发布说明严丝合缝

Spark 1.2 的公开讨论褒贬不一。[OpenCode 讨论](https://www.reddit.com/r/opencodeCLI/comments/1vvmnjj/muse_spark_is_infuriating/)里，开发者抱怨多余的 Python 脚本、爱走捷径，还有提示词写得不够严格就表现糟糕。同一线程里也有人说换个框架或自定义系统提示就好多了。另一篇[初体验帖子](https://www.reddit.com/r/opencodeCLI/comments/1vsjcyo/muse_spark_12_my_initial_impressions_compared_to/)说 1.2 干活靠谱，但也指出了缓存命中率的问题。

用户反馈定不了模型质量，尤其框架和流量负载还不一样。但这些反馈告诉我该测什么。Spark 1.3 明确承诺减少多余交互、更好地保留指令细节、代码风格更干净、用户打断长对话时路由更准，也更懂得何时该求助。这读起来像是在回应真实的工作流痛点，而不是又一个“能解更难题”的空话。

如果这些改进是真的，监督长任务的开发者会被打扰得少些。但“在多种框架上训练过”不保证在我自己的工具定义或权限提示下表现一样。Meta 早前的[Spark 1.1 发布](https://research.meta.ai/blog/introducing-muse-spark-meta-model-api)已经吹过规划、委派、上下文压缩和百万 Token 上下文窗口。1.3 得证明这些能力能更可靠地一起干活。

## 安全延迟本身就是产品的一部分

我很高兴 Meta 没把 Max 的延迟糊弄成脚注。一个能干大事的更强代理需要的不只是拒绝分数。Meta 说 1.3 在不可逆操作上校准得更好，对提示注入抵抗力更强，但公告没公布这两点的定量证据。

这个遗漏很关键，因为 Meta 八月披露过，一个预发布的 Spark 1.1 模型[在配置错误的网络安全评估中利用了真实网站](https://research.meta.ai/blog/addressing-third-party-testing-misconfiguration-muse-spark-1-1)。Meta 说模型以为那网站是目标，改了它的数据库。公司查了上万条活动记录，没发现其他例子。代理的判断修不好破损的边界。

所以我也不会把“Max 快来了”当发布日期。额外安全测试可能发现模型问题、框架问题，或者两者都有。我之前就说过，一旦有能力的代理能碰互联网，[网络安全评估就是生产基础设施](https://markhuang.ai/news/claude-cyber-eval-test-harness-risk)。在模型和环境跨过这道坎之前，等着才是对的状态。

## 我先跑便宜的实验

对可用的 Spark 1.3 模式，我会用一小批真实代码库任务，固定权限跑多次。记录完成情况、工具调用、Token、耗时、人工干预、违反约束、尝试不可逆操作这些指标。和同一框架下的 Spark 1.2 对比轨迹，能直接验证 Meta 的效率声明。

开发者真能调 Max 前，我不会把它放进比较。等它上线，单独开个通道跑同样测试。高分或许值得在困难迁移或长调试里多花点推理。但也可能花更多时间证明常规模式早就知道的事。

Spark 1.3 最有戏的地方反而是 Meta 最不起眼的承诺：在乱糟糟的活里少调用、少用 Token。这能让代理的监督成本更低。Max 基准是个有用的预告，但我今天的决定很简单：测已发布的模型，等没上线模式的证据。