Theo 测试 Meta Muse Code：速度快、价格低，表现却不均衡

我很欣赏 Meta 的许多软件贡献，从 React、React Native 到 Llama 开放权重模型都是如此。不过，AI 行业已经大幅领先 Meta，而 Muse 模型此前大多只能通过网页界面体验。现在，Meta 发布了面向编程的模型和配套终端 agent。

Muse Code 是一款测试版终端编程 agent，由 Muse Spark 1.2 驱动。Meta 公布的基准测试并没有让它在所有项目上领先，但模型只要速度快、实用且价格低，仍然可能很有价值。我会亲自测试模型和工具，看看定价以及实际使用中的问题。

Meta 将它描述为能够在大型代码库中规划修改、编写代码并验证结果的 agent。Meta 处理大型代码库的经验值得关注：它长期投入内部工具，包括基于 Mercurial 的工作流和堆叠式代码变更，甚至改造过语言来改善代码库的使用体验。

图表显示 Spark 1.2 相比 1.1 有明显提升。在展示的 Terminal Bench 对比中，它略低于 Opus 5，略高于 GPT-5.6 Terra；在 Deep SWE 上，它落后于前两者，但高于 Grok 4.5。我对 Meta 内部基准和它选择的比较对象仍持谨慎态度。

Meta 表示，专门的后台 agent 会在会话期间保留上下文，大任务则可以分给隔离工作树中的多个子 agent。它还介绍了一个长时间运行的内核优化实验，以及用于记录模型调用、工具运行和编辑的本地事件日志，以便审计和恢复中断的任务。

视频拍摄时，标准档每百万 token 的价格为输入 1.25 美元、缓存输入 0.15 美元、输出 4.25 美元。Contributor 档对应价格为 0.10、0.002 和 0.20 美元；定价页写明该档数据用于改进产品。享受折扣也意味着需要考虑数据使用方式。

Artificial Analysis 的对比将 Spark 1.2 的智能指数评为 54，高于之前的版本，按标准价格估算每个任务约 0.40 美元。Theo 估计 Contributor 档能大幅降低任务成本；实际费用仍取决于输入、缓存输入和输出 token 的比例。

基准还显示幻觉率下降，同时模型的作答率也下降了。这些数据值得参考，但不能把基准分数当成保证：在这次测试的后半段，模型就曾自信地沿着错误目标展开调查。实际体验需要和汇总数据一起看。

这个模型没有开放权重。考虑到 Meta 的资源，它落后于较早发布的开放权重竞争模型让我失望。不过，基准排名本身不能决定模型是否实用：我尝试合并其他领先模型写出的代码时，实际体验也未必与排名一致。

在我查看的 Artificial Analysis 对比中，Spark 每个任务大约输出 3 万个 token，Fable 5 约 3.6 万，GPT-5.6 Sol 约 1.7 万。这些数字取决于测试任务，但为比较成本和模型行为提供了另一个维度。

OpenRouter 的测量显示 Spark 输出速度很高：平均约每秒 191 个 token，中位数约 162 个，峰值更高。这些数字取决于服务商和测试条件，不过在实际编程会话中，我确实感受到了它的速度。

我在开源的 T3 Code 仓库中打开 Muse Code，使用 Contributor 档请求架构概览。它不到 30 秒就给出了结果。接着我提出更难的问题：事件溯源设计是否可能导致跨平台问题、额外带宽消耗或延迟。

这个 CLI 读取了我在 Claude Code 中配置的 skills 和个人规则，这是一种有意思的兼容方式。我让它用 HTML 总结事件溯源调查结果，它找到了相关 skill；分析提到了快照、负载大小以及跨线程耦合的全局序列等问题。

为了对比，我让 Fable 和 DeepSeek V4 Flash 做类似调查，再让模型互相比较结果。Muse 不到一分钟就给出了反馈和 HTML 页面；其他运行耗时更长。速度很突出，但更重要的问题是结论是否准确。

Fable 的对比认为 Muse 在某些方面覆盖更广，但整体上更认可自己的调查，认为它在准确性和根因分析上更好。DeepSeek 则对 Muse 更为肯定。这些都是模型自己的判断，不是独立的事实验证，因此我把它们当作线索，而不是最终评测。

我还让模型把自己的小鱼游戏分别重做成 2D 和 3D 版本。2D 版本约两分半完成，3D 版本不到五分钟。相对于我之前的一些测试，这个速度很惊人，但最初的 3D 版本控制功能出了问题。

2D 游戏虽然粗糙，却有不错的动画、阴影和对比度。这种视觉风格与我见过的其他模型结果有些不同。3D 版本很快修复了一部分鼠标控制，但鱼倒着游，垂直视角仍然有问题。

后续修复纠正了鱼的游动方向，但仍留下其他交互问题，包括按键功能冲突。模型完成修改的速度很快，也能做一些有用的润色；这并不意味着用户不亲自试玩就能确认结果完整可靠。

我又在一个对比网站上查看了几套生成设计。有些滚动效果、分区布局和漂浮细节很讨喜，但也有熟悉的模板痕迹、过多文字，以及我不喜欢的风格选择。总体而言，这些设计有自己的特点，即便不一定符合我的全部喜好。

为了进行更难的测试，我打开隔离工作树，让 Muse 调查如何将 Muse Code 接入 T3 Code，作为一个模型提供方。我希望它检查现有代码库、可用文档、可能的 SDK 和类似 ACP 的集成方式，并把调查拆给多个子 agent。

终端实时显示语音转文字的体验出乎意料地好，Muse 也迅速启动了专门的子 agent。但随后它们遇到了限速。工具既然围绕并行工作设计，API 限制却妨碍工作顺利推进，就会让人沮丧。

仪表盘显示，到目前为止包括游戏重做和代码库审查在内，大约花了 0.13 美元，不过我不确定计费统计是否实时。Contributor 档很便宜，但限速较低，提交的数据也可用于改进产品。

集成调查一开始就走偏了：agent 假定我说的是 Antigravity，并围绕错误对象展开研究。受到追问后，它承认自己没有核实这个假设。我不得不告诉它，Muse 就是它当前运行的 CLI。

纠正目标后，agent 报告称可用的集成接口有限：它没有找到开源 CLI、公开 SDK 或现成的 ACP 接入方式。我又让 Fable 独立调查并审阅 Muse 的计划。生成页面的一部分布局也出了问题，这再次提醒我们要检查产物本身。

Fable 给出了计划反馈，我把反馈交回 Muse，它很快更新了方案。我喜欢让第二个模型评议第一个模型的工作；快速、低价的模型让这样的循环更实用，尤其适合后台任务和分类。

我还让 GPT-5.6 Sol 比较两份独立生成的集成计划。此时 Muse 一侧的规划费用约为 0.40 美元，而 Fable 和 Opus 的调查及审阅接近 32 美元。这些是我分别运行的任务，并非对完全相同工作量进行的受控成本比较。

并行子 agent 再次触发限速。我从 Contributor 切换到价格更高的档位，仍然遇到限制。工具本身感觉简洁且比较成熟，但在按 token 计费的服务上反复遭遇限速尤其令人烦恼。

Sol 在这次比较中给 Muse 的方案打了 4.8 分、给 Fable 的方案打了 7 分，认为前者在贴合仓库和 API、端到端完整性方面较弱。这只是另一个模型按权重给出的判断，并非客观测量，但它强化了我的顾虑：不经审查，我不愿把大范围改动交给低价模型。

谁会使用这个模型？Meta 员工、喜欢尝试新东西的人，以及重视速度和低成本的人，都可能有理由试试。不过切换计费档位后，约十分钟的工作就让我的费用从 0.40 美元涨到 5.32 美元，说明选择的档位和具体工作量都很重要。

agent 为 T3 Code 做出了 Muse 集成，于是我启动开发服务器进行测试。这项探索性工作文档有限，任务本身并不容易。模型添加了界面选项，却没有在设置中正确添加提供方；在我的测试中，这个集成无法工作。

这个失败让我不愿轻易信任它完成漫长复杂的工作。它似乎善于组织子 agent、避免彼此冲突，却不那么擅长把复杂任务从头到尾做好。对于需要合并的代码，我可能更愿意等待速度较慢、但更有可能做对的模型。

CLI 本身是这次发布中最让我印象深刻的部分之一：虽然它不是我最喜欢的工具框架，但使用起来稳定、成熟。Meta 也提供了通过其他工具使用模型的方式。我仍希望 Muse Code 自身能更开放，便于集成。

我又给它一个测试：审查 T3 Code 中我打开的 pull request，分类哪些需要更多工作、哪些可能可以合并，并给出优先级和置信度。它遇到了 GitHub API 错误，但设法绕过，并在大约四分钟内完成了初步审查。

审查页面包含可点击的 PR 链接、合并状态和置信度分数，布局也很易读。这是有价值的代码周边分析工作。我不会让模型自行合并修改，但低成本概览可以帮助我决定先看哪里。

我把审查范围扩大到过去五天有更新的开放 PR。工具启动了许多子 agent，我预计又会遇到限速。即便如此，这类大范围并行分类仍可能从速度和价格中获益，之后再由人核实细节。

目前，这更像是一个供爱好者尝试的模型：它生成的结果风格不同，但我不会把它设为所有编程工作的默认选择。它的强项和弱项与我常用的模型不同，这正是它有意思的地方。我也希望 CLI 能够开源。

不到五分钟，扩大后的审查就索引并检查了 222 个 pull request；我估计 Contributor 档成本约为 0.10 美元。页面把大量工作整理成了便于查看的形式。这对初步分拣很有价值，但并不能证明 222 条判断都正确。

这个低价依赖 Contributor 档及其数据使用条款；Theo 估计标准档的成本会高得多。即便如此，这次结果仍提示了 PR 分类、摘要、标题生成和日志探索等用途，前提是重要结论和合并决策由人核实。

我不认为 Spark 能在所有任务中取代最强的模型，这次测试也有明显的起伏。不过，速度、价格和独特的表现让它值得尝试。我能想象自己用它整理工作，从大量信息中找出值得关注的线索。