Meta在8月5日的官方博客里同时抛出两个名字:编程工具Muse Code和升级版模型Muse Spark 1.2。按官方说法,这次更新的重点是把训练算力大幅砸向编程任务,让模型在长程、跨文件、整仓库级别的编码任务上更稳定,并且模型和工具是"co-trained"(联合训练)出来的组合,不是简单拼接。独立评测者Simon Willison用他惯用的"鹈鹕骑自行车"SVG测试跑了一下1.2版本,结论是比7月9日发布的1.1版本"有微小但实质的改进"。
这个判断本身很克制,也几乎是目前外界能拿到的唯一独立观察。
Meta补上的是长程工具调用这块拼图
过去一年,主流实验室比拼的重点已经从单纯的模型智能挪到了长序列agentic工具调用——模型能不能在一次长会话里持续、可靠地调用终端、文件系统、代码执行环境,完成一连串有依赖关系的任务。Anthropic的Claude Code、OpenAI的Codex CLI、Google的Gemini CLI都是这个逻辑下的产物:模型不再单独卖,而是和一套专门适配的工具链打包交付。
Meta这次把Muse Code(工具/harness)和Muse Spark 1.2(底层模型)绑在一起发布,走的是同一条路。官方博客里提到的rejection sampled harness轨迹、针对goals、compaction、subagents的方案优化,本质上都是在给"模型+工具"这套组合调参,而不是单独优化模型本身。这说明行业共识已经很清楚:光有聪明的模型不够,还要有配套的工具链才能把长程任务跑通。
官方说了很多,外界能验证的几乎为零
问题出在这里:Claude Code、Codex CLI、Gemini CLI这几年积累了大量独立评测、真实使用报告和社区issue,遇到bug、遇到上下文丢失、遇到定价争议,开发者社区都在Hacker News、GitHub上吵得很热闹。Muse Code和Muse Spark 1.2却几乎找不到这类外部痕迹——没有可核实的benchmark分数,没有公开定价和可用范围,也没有独立开发者晒出的真实使用体验。
验证还没跟上发布的速度
Meta博客里的"显著提高训练算力""co-trained以确保最佳性能",都是厂商自陈,读者目前只能选择信或不信,拿不到第三方核实的依据。Willison的鹈鹕SVG测试之所以有价值,恰恰是因为它是这个信息真空里唯一可复现、可横向比较的独立观察——哪怕它测的只是一张插画,而不是真正的编程能力。
- 风险.目前没有任何数据能说明Muse Code在repository级真实任务上打不打得过Claude Code或Codex CLI,开发者选型只能靠等。
开发者该等什么信号
对已经在用Claude Code或Codex CLI的团队来说,现在没有理由为了Muse Code换工具——没有基准,没有定价,连能不能用都不清楚。真正值得盯的,是Meta后续会不会公开可复现的SWE-bench一类跑分,以及产品是否大规模开放后,Hacker News和GitHub上会不会出现第一批真实使用报告。
- 结论.厂商自陈和独立验证之间,眼下还有一段没人填的空白。
在这段空白填上之前,"co-trained""长程任务训练"这些说法,更适合当作Meta的自我定位,而不是可以直接拿来做决策的证据。