1. 编程能力——少跑几轮才是真省钱
Muse Spark 1.3 在编程上的改动,我最关注的是任务执行效率。
Meta 给出的数字很直接:
- 工具调用减少约 20%
- 完成相同任务的 token 消耗减少约 25%
- 输出更短,无效轮次更少
复杂编程任务不是输入一句话,然后等代码出来。
模型通常要先找文件、读代码、调用工具、修改、检查,再根据结果继续下一轮。中间每多绕一次,都会多花时间和 token。
所以相比“回答更聪明了”,我更愿意看它到底少做了多少没必要的事。
DeepSWE v1.1 中,Muse Spark 1.3 得分 75.4,GPT 5.6 Sol 是 73.0,Opus 5 是 74.0。
Terminal-Bench 2.1 上,1.3 得到 88.8。
这些 benchmark 能证明它的编码能力已经处在很高的位置,但更有价值的还是任务链变短。
如果一个 Agent 原本要来回调十几次工具才能解决问题,现在能少掉两三次,那就是实打实的时间和调用费。
2. Agent 能力——别把一个误解执行到底
Agent 这块比单纯的代码生成更值得看。
Meta 提到,1.3 遇到模糊指令时,更倾向于先确认,而不是自己补全缺失条件继续往下做。长任务里碰到障碍时,也更愿意停下来请求用户介入。
听起来有点保守,但 Agent 就应该适当保守。
普通聊天理解错一句话,大不了重问一次。Agent 如果第一步理解错了,后面可能会继续查文件、改代码、跑工具,十几步之后才发现方向从一开始就错了。
这种“自信地一路错下去”,才是长任务最麻烦的地方。
MRCR 长上下文测试里,1.3 的变化也很明显:
- 256K–512K:98.5,1.2 为 66.3
- 512K–1M:98.1,1.2 为 55.5
我觉得这组数字比“支持 100 万 token”这个规格本身更有看头。
上下文开到 100 万并不等于真的能用好 100 万。真正难的是内容越来越长之后,模型还能不能记得前面发生了什么,别突然开始丢线索。
从这组结果看,1.3 至少在这个问题上往前走了一大步。
3. 多模态和长上下文
Muse Spark 1.3 可以输入文本、图片、视频、音频和 PDF,输出只有文本。
上下文窗口是 100 万 tokens,大约相当于 75 万个英文单词。
对普通聊天来说,这个数字有点夸张。
但放到代码仓库、多文件任务或者长文档里就很好理解:以前要自己挑文件、裁代码、反复补背景,现在可以少做很多整理工作。
这部分我反而不会吹太多。
窗口大只是“能放进去”,能不能在几十万 token 里稳定找到真正相关的信息,才决定它好不好用。MRCR 的成绩上升,至少比单纯写一个“1M context”更有说服力。
4. 和 Muse Spark 1.2 比,变化到底有多大
1.2 是 8 月 5 日发布的,1.3 在 9 月 2 日上线,中间不到一个月。
按版本号看,我原本会把它当成一次小更新。
但 1.3 的改动其实很集中:编程任务少跑几步,长上下文稳定很多,Agent 遇到不确定情况也没那么喜欢硬着头皮往下冲。
Terminal-Bench 2.1 从 82.9 升到 88.8,MRCR 的长上下文成绩提升更大。
至于工具调用和 token 消耗,就不再把同样的 20% 和 25% 重复列一次了。前面已经够说明问题。
这些数字大多还是 Meta 自己给出的。
Artificial Analysis 的独立测试支持 1.3 比 1.2 更强这个方向,但我不会因为几张 benchmark 表就直接下结论说它“领先所有模型”。
真正在开发里值得观察的是另一件事:
一个复杂任务跑完之后,它到底少浪费了多少步骤。
这也是 1.3 给我留下最深的印象。
评论(0)