AREX Feed Article
Alexandr Wang 称 Muse Wonder Full 在 VulcanBench 上「整体相当有竞争力」，但确实更慢
10 月 17 日 19:28 UTC（北京时间 10 月 18 日 3:28），Meta 首席 AI 官 在 X 上回应编码 agent（智能体）基准 VulcanBench 的结果时，Muse Wonder Full 在 VulcanBench 上「与 Astra、Opus 5.5 和 Sol 6.1 相比整体相当有竞争力」，但「确实更慢」，并称团队正在处理这一点。
在 Wang 发帖前约两小时，发布这组结果的 VulcanBench 作者 Morgan Linton 在里贴出两张表，一张综合准确率，一张每任务耗时。他的结论更直接：Muse Wonder Full 比 Opus 5.5 慢不少，比 GPT-6.1 Sol 慢得多，比 GPT-6 Astra 慢得多；按当时的数据，他会选 Opus 5.5 或 Sol，因为「你能以更快、更便宜的方式得到相同或更好的准确率」。
Wang 的帖文与 VulcanBench 的评测口径
Wang 的帖文只有两行：一行给出对象，一行给出判断。它没有说明 VulcanBench 的版本、由谁运行、跑了多少任务，也没有说明「更慢」指的是首 token 延迟、吞吐，还是完成一个任务的总耗时。帖文也没有给出差距幅度或改进时间表。
VulcanBench 的给出了评测口径和结果。这个基准测试的是编码 agent 重建 23 个退役遗留程序的能力：每个任务给一个二进制程序、一份规格说明和一个 issue（问题单），程序的实际行为在若干处偏离规格，隐藏测试检查重写是否还原了这些行为。Muse Wonder Full 的这些运行在 Muse Code 里完成：单任务上限 3 小时，一次只跑一个任务。代码质量由评委按统一评分细则打分。
Muse Wonder Full 是 Meta 在 10 月 12 日的 Muse Wonder 系列中的 Full 版本，只通过 Muse Code 订阅提供。Meta 在发布时称该系列是「迄今最强」的模型；这套基准只测 23 个编码任务，不是 Meta 发布时强调的个人助理、法律、金融等场景的完整评测。
Muse 在 Medium 档的四者中排第二，耗时 27.3 分钟
VulcanBench 的完整结果页显示，Muse Wonder Full（muse-wonder-full-1.0）在 Muse Code 的四个 effort（推理投入）档位各跑 23 个任务，合计 92 次运行，从 10 月 13 日 20:31 UTC 持续到 10 月 17 日 16:11 UTC。综合得分在 Low 档是 86.95，Medium 档 88.27，High 档 88.19，Extra-high 档 87.59；四个档位的标准误在 0.95～1.16 之间，彼此的差距落在误差范围内。得分最高的 Medium 档在 Frontier v4 总榜的 67 个「模型×档位」列中排第 23，夹在 GPT-6.1 Sol 的 Max 档（88.35）和 High 档（88.23）之间。
综合得分不是单纯的正确率：50% 来自隐藏测试的功能正确性，8.5% 来自 lint（代码静态检查）与复杂度，8.5% 来自安全，33% 来自评委的代码质量评分。
Wang 帖中的 Astra、Opus 5.5、Sol 6.1，在 VulcanBench 的里写作 GPT-6 Astra、Claude Opus 5.5、GPT-6.1 Sol。Medium 是 Muse Wonder Full 得分最高的档位：
| 模型（Medium 档） | 综合得分 | 每任务耗时 | 每任务成本（估算） |
|---|---|---|---|
| Muse Wonder Full | 88.27 | 27.3 分钟 | $4.09 |
| Claude Opus 5.5 | 90.86 | 18.6 分钟 | $2.84 |
| GPT-6.1 Sol | 86.40 | 10.6 分钟 | $0.40 |
| GPT-6 Astra | 87.73 | 3.8 分钟 | $1.48 |
四者的评委不同，跨模型比较要留出余量。
它落后 Claude Opus 5.5 约 2.6 分，领先 GPT-6 Astra 约 0.5 分、GPT-6.1 Sol 约 1.9 分；每任务 27.3 分钟的耗时分别是 Opus 的 1.5 倍、Astra 的 7.2 倍、Sol 的 2.6 倍，估算成本 $4.09 也高于 Opus 的 $2.84、Astra 的 $1.48 和 Sol 的 $0.40。
所以「整体有竞争力」这句话，在 Low 和 Medium 档基本成立：Low 档四个模型挤在 86.2～87.4 之间，Muse 排第二；Medium 档 Muse 排在 Opus 之后、Astra 和 Sol 之前。到 High 档，它和 Sol（88.23）、Astra（88.16）几乎同分，仍落后 Opus（91.11）；Extra-high 档它掉到第四，排在 Opus（90.68）、Astra（89.16）和 Sol（88.78）之后。
Muse Wonder Full 没有公开的 API（应用程序接口）单价，成本是按 Muse Wonder 1.0 的列表价从 token（词元）用量估算的，不是账单。
Muse 的慢来自更多调用和更长推理
VulcanBench 的拆开了 Low 档的每任务耗时。同样 23 个任务，GPT-6.1 Sol 平均 6.3 分钟，Muse 约 27 分钟，是 4.3 倍；但单步耗时只差 1.3 倍（19.8 秒对 15.4 秒）。差距主要来自次数：Muse 每个任务平均 65.8 次模型调用，Sol 22.2 次（按工具步骤估算），约 3 倍；输出 68.0k token，Sol 6.8k，10 倍；其中推理 token 38.3k 对 1.4k，约 27 倍。Muse 80% 的时间花在模型调用上，每次调用等待首 token 的中位数是 5.8 秒；调用次数一多，这项固定开销就被放大。
Linton 在时给出的解释是，Muse Wonder Full「非常准确，但想得太多」，因此用了更多 token、花了更多时间。VulcanBench 列出的首要原因是「约 3 倍的往返」：Muse 常在一次调用里写脚本，下一次调用再运行；它每个任务要跑约 26 次遗留程序来测试单个窄假设，Sol 只跑约 7 次；代码修改约 19 次对 7 次。
评委、超时和本地负载都在影响这份成绩
评委是一个限制。Muse 的代码质量由 Claude Opus 5.5 和 GPT-6.1 Sol 打分，另外三个模型由 Muse Spark 1.3 和 Grok 4.6 打分；两套评委没有校准，VulcanBench 明确说跨模型差一两个点不能当排序。Muse Spark 是 Meta 的模型，因此被排除在 Muse 的评委之外；Opus 5.5 既是评委，也是被比较的模型。
评委之间也不一致。Low 档的代码质量，Opus 5.5 给 59 分，Sol 给 76 分，相差 17 分；综合得分取两人的平均。如果只算一个评委，Muse 的 Low 档综合分会是 85.0 或 88.9。
超时还让两个档位多了一套更低的分数。High 档的 paddockcore 和 Extra-high 档的 depotcore 都撞上 3 小时上限，没有留下可评的代码；按「超时记 0」重算，High 和 Extra-high 分别从 88.19 和 87.59 降到 84.36 和 83.78。同一档位因此有两个分数，取决于怎么处理超时。
运行环境也会影响耗时。基准任务一次只跑一个，但机器上同时还有别的本地任务：Medium 有 9 个、High 有 14 个、Extra-high 有 5 个任务与其他本地任务重叠。Extra-high 的 depotcore 那 180 分钟里有 145 分钟重叠，VulcanBench 认为这次超时可能有一部分来自本地负载，并计划在 10 月 19 日配额重置后补跑一次干净的测试。每个任务每个档位只跑一次，运行框架也不同：Muse 用 Muse Code，Opus 用 Claude Code，Sol 和 Astra 用 Codex。
因此，这里说的「更慢」是 Muse Code 里的每任务墙钟耗时，包含等待、生成、工具调用和框架开销，不是单纯的 API 延迟或吞吐。
配额用尽后，Meta 发布了 Muse Code 1.4.9
基准从 10 月 13 日持续到 10 月 17 日，将近四天。Muse Code 的每周额度在 Medium 档第 21 个任务时用完。Linton 在 10 月 15 日的里说，他升级到每月 200 美元的套餐，仍没能跑完两个完整的 effort 档位；作为对比，在每月 100 美元的套餐上，他能把 Astra 的每个档位都跑完。他同时称 Meta 团队在帮忙，并称 Meta 已承认低档位似乎存在问题、正在排查。
之后，据 VulcanBench 的完整结果页，Meta 重置了额度，并发布了更省 token 的 Muse Code 1.4.9；Medium 的最后两个任务和 High、Extra-high 全部在 1.4.9 上跑完。High 档还有一次 snapcore 因 API 连接中断作废，随后重跑。这些改动让同一次基准横跨了两个 Muse Code 版本：Medium 档 21 个任务跑在 1.4.6 上，2 个跑在 1.4.9 上。
可见回复更关心速度
Linton 在 Wang 的帖文下：「谢谢分享，也恭喜，显然你和团队投入了大量工作。」但在可见的回复中，速度被反复提起。@annanidev ：「速度才是难的部分，祝顺利。」@i_mika_el ：「分数看起来够接近了。更慢大概是用户最容易注意到的。」这些是用户回复，不是 Meta 或 VulcanBench 的数据。
Linton 自己在 10 月 17 日晚些时候的里，把四者概括为：Astra 快但贵，Sol 又快又便宜，Opus 在准确率上领先，Muse Wonder 准确但贵且慢。在这轮 Muse Wonder Full 基准的语境下，他写道，按现有数据他不会把 Muse Wonder 用于编码，也不确定这是不是 Meta 的目标市场；如果团队能解决每任务的时间和成本，它完全可能成为一个可用于日常编码任务的模型。
VulcanBench 的页面称，补跑安排在 10 月 19 日配额重置之后。这次补跑要分清的是，depotcore 的 180 分钟里有多少属于模型，有多少属于同时跑着别的任务的本地 Mac。