Meta发布Muse Code与Muse Spark 1.2：59%跑分之外，终端Agent开始挑战24小时任务

终端编码 Agent 协调多个常驻后台 Agent 并在中断后恢复任务的概念画面 — Muse Code 的核心卖点不是一次生成更多代码，而是让多个后台 Agent 持续协作，并用本地事件日志保存长任务状态。图片由 AI 生成。

终端里的一项任务跑了几个小时，中途进程崩溃。通常，AI 编程 Agent 要重新扫描仓库、重建上下文，再猜一次自己做到哪里。Meta 新发布的 Muse Code 想把这段“失忆时间”删掉：每次模型调用、工具执行、审批和代码修改都写进本地事件日志，重启后从中断点恢复。

Meta Superintelligence Labs 于 2026 年 8 月 5 日正式发布 Muse Code beta 版和 Muse Spark 1.2。前者是一款面向 macOS 与 Linux 的终端编码 Agent，后者是与这套编码环境共同训练的新模型。Muse Code 可以规划修改、编写代码、运行验证，并让多个专职后台 Agent 在整个会话中保持活跃。

表面上，这是 Meta 对 Claude Code、OpenAI Codex 和 Grok Build 的跟进；真正的变化是 Meta 不再只卖一个可接入其他框架的模型 API，而是开始控制模型外面的 Agent 运行时。常驻子 Agent、本地事件日志、审批式计划与长达 24 小时的实验，说明竞争焦点正在从“谁单次回答更会写代码”转向“谁能把一次软件工程任务可靠地跑到底”。

Muse Code不是聊天框换皮，而是一套可恢复的终端运行时

Muse Code 的主循环旁边有一组异步后台 Agent。Meta 的设计不是遇到子任务时临时创建一个 Agent、完成后立即销毁，而是让这些专职角色在会话期间持续存在。它们可以继续调查下一步、保留已经收集的信息，并自行判断何时把结果汇报给主 Agent。

这解决的是长任务里的重复劳动。一个临时 Agent 每次启动都要重新理解仓库结构、测试约定和当前故障；常驻 Agent 则能保留工作状态。Meta 声称，这可以降低多步骤任务的延迟和人工引导需求。不过，这仍是厂商对自家系统的描述，公开公告没有给出“常驻”相对“按需创建”在真实仓库中的独立成本与成功率对照。

更有工程意味的是本地追加式事件日志。Muse Code 把模型调用、工具运行、用户审批与编辑记录为单一事实来源，因此运行时可以重放状态，进程崩溃后不必从零开始。它不是把模型变得不会犯错，而是让系统知道错误发生前做过什么。对于几小时甚至跨工作日的任务，可恢复性往往比一轮回答快几秒更有价值。

三个内置技能，把“先想、质疑、再执行”放进默认流程

Muse Code beta 随附三个默认技能。/plan 把任务拆成需要审批的计划；/grill 对计划进行压力测试，追问其中的假设和薄弱点；/goal 则围绕指定目标持续推进，直到达到成功条件。

这组命令透露出 Meta 对 Agent 可靠性的判断：模型能力还不足以让“收到需求后直接改仓库”成为所有任务的默认选项。计划要能被人审阅，计划本身也需要被另一个过程挑错，执行结果还要用测试或其他条件验证。自动化越长，早期误解造成的返工半径越大，审批点就越重要。

开发团队真正需要检查的，不是命令名是否新鲜，而是审批能否覆盖高风险动作：删除文件、修改依赖、访问网络、读取凭据、推送代码与触发部署。Meta 公告确认事件日志会记录 approval，却没有在公开文章中完整列出默认沙箱、权限隔离和企业策略控制。beta 阶段仍应从低权限仓库与可回滚分支开始。

Muse Spark 1.2与Agent共同训练，Meta开始优化“模型＋脚手架”整体

Muse Spark 1.2 是针对编码的更新，Meta 称其加强了代码生成、复杂调试、代码库理解和端到端开发流程。与单独训练模型再塞进任意客户端不同，Meta 把模型和 Muse Code 共同训练：训练数据包含运行时轨迹，训练配方也针对目标保持、上下文压缩、子 Agent 与工具集做了优化。

这点比版本号更重要。Agent 的成绩从来不只由模型决定，还取决于它能看到什么文件、如何调用工具、何时压缩上下文、能走多少步，以及测试失败后是否继续。Meta 把这些脚手架行为放进训练过程，目的是让 Muse Spark 1.2 在自家运行时里发挥得更好。

代价是可移植性可能下降。一个模型在 Muse Code 中表现突出，不代表放进 OpenCode、Cursor 或企业自研 Agent 后仍保持同样结果；反过来，其他模型也可能在不同 harness 中追上。采购者应把评测对象写成“模型版本＋Agent 版本＋推理配置＋工具权限”，而不是只记住 Muse Spark 1.2 这个名字。

DeepSWE 1.1拿到59%，但这是特定系统的单项成绩

Meta 发布页展示的 DeepSWE 1.1 图表中，Muse Spark 1.2 与 Muse Code 组合取得 59%。同一对比里，Grok Build 4.5 为 54%，Gemini 3.6 Flash 为 49%。从该项测试看，Meta 的新组合领先 5 个和 10 个百分点；Muse Spark 1.1 此前的公开结果为 53.3%，因此 1.2 在长周期软件工程任务上出现了可见提升。

这组数字必须带着口径阅读。DeepSWE 1.1 评估的是长周期软件工程能力，最终分数同时受到模型、Agent harness、推理预算、工具、重试策略和测试环境影响。Meta 在方法报告中把 DeepSWE、Terminal-Bench 2.1 与内部编码基准分开列出，说明 59% 不能外推为“所有编码任务领先”。

Google 自己公布的 Gemini 3.6 Flash 模型卡也给出 49% 的 DeepSWE 1.1 结果，但在 Terminal-Bench 2.1、MLE-Bench 和多模态任务上还有另外的成绩。一个 Agent 能解决更多长期仓库问题，不等于它生成小函数更快、成本更低，或在前端、数据科学与安全修复上都更强。TOPSTIP 的判断是：59% 足以让 Muse Code 进入候选名单，还不足以让团队跳过内部仓库测试。

24小时和1000次工具调用，证明的是耐力，不是普遍可靠性

Meta 还展示了一项 GPU 内核优化案例。Muse Spark 1.2 在 Muse Code 环境中连续进行写代码、编译、性能分析和迭代，累计超过 1,000 次工具调用，最长运行 24 小时。测试对象包括 NVIDIA Hopper GPU 上的 KDA 与 MLA 内核，并限制模型不能直接导入 FLA 等第三方内核库来包装现成实现。

这个案例说明系统可以维持很长的工具链，并在一个可自动测量性能的目标上不断搜索改进。它很适合展示常驻 Agent、状态恢复和目标保持。与此同时，GPU 内核优化有明确的数值反馈，和需求模糊、测试不完整、需要产品判断的日常应用开发并不相同。

因此，“最多运行 24 小时”不能写成“可独立完成任何一天长度的开发项目”。时间越长，错误路径消耗的 token、算力和工程时间也越多。企业更应该关注单位可接受变更的成本、人工审查时间、回归缺陷与中断恢复成功率，而不只是最长连续运行纪录。

Meta从模型供应商走向编码入口，直接碰上Claude Code与Codex

Muse Spark 1.1 发布时，Meta 的主要角色还是模型 API 供应商：开发者可以把它接入 OpenCode 等现有框架。Muse Code 上线后，Meta 开始提供模型、终端交互、子 Agent 调度、上下文压缩、技能与运行日志的完整组合。这让它第一次在开发者每天打开的入口上，正面遇到 Claude Code 和 Codex。

拥有运行时也能反过来改善模型。Meta 可以观察哪些工具轨迹成功、哪些计划反复失败，再把筛选后的轨迹用于训练后续版本。官方称，Muse Spark 1.1 曾用于生成困难编码环境和指令遵循模板，并参与评估候选解答，形成训练 Muse Spark 1.2 的可扩展数据。这是一个自我改进循环，但“模型给模型出题和评分”也需要防止评价偏好被放大。

对竞争对手而言，压力不只来自 59% 的分数。真正难复制的是模型与产品之间的数据回路：Agent 获得真实任务，运行时记录过程，训练团队再利用高质量轨迹改进模型。谁拥有开发者入口，谁就更容易积累这种数据；谁只有 API，谁就看不到任务最后是否真的通过审查。

开放范围扩大了，价格与数据条款仍要在账户内核对

Meta 公告称 Muse Spark 1.2 当天进入 Muse Code 与 Meta Model API，并获得“扩大的全球访问范围”；Muse Code 安装说明明确列出 macOS 和 Linux。公开发布文章没有给出完整国家名单、硬件要求，也没有列出 Muse Spark 1.2 的全部计费档位。开发者门户的详细模型与额度页面需要登录，因此可用性和实际价格应以账户所在地看到的控制台为准。

这也是报道不能沿用 Muse Spark 1.1 数字的原因。即使两个版本可能共享某些价格，发布页没有明示就不应把旧价写成 1.2 的确定事实。社区提到的低价 Contributor 档还涉及允许训练使用提示词与输出的条件；在 Meta 公开文档无法匿名核验完整条款前，企业不应只凭社交帖子选择数据处理模式。

安装脚本、代码访问权限和模型数据政策同样需要分别审查。终端 Agent 能读取仓库、运行命令并修改文件，权限天然高于普通聊天机器人。团队应限制可访问目录，保护环境变量和生产凭据，要求所有变更进入独立分支，并把最终测试与代码评审留给人类或独立流水线。

终端Agent的下一场比赛，是把长任务做完且留下证据

Muse Code 的产品信号很明确：2026 年的编码 Agent 已经不满足于回答问题、补一个函数或生成一次提交。常驻后台 Agent、可恢复事件日志、计划质询和长周期目标，让软件开发自动化更像一套有状态的执行系统。

但“能持续运行”只是第一道门槛。下一阶段需要比较的是：中断后恢复的状态是否准确，多个 Agent 是否重复改同一文件，审批能否真正阻断危险操作，长任务的成本是否可控，以及生成的代码能否经得住人类评审。Muse Code beta 给出了一个具体架构，也把这些问题带到了 Meta 面前。

对于开发者，59% 的 DeepSWE 1.1 可以成为试用理由，却不该成为迁移理由。更可靠的决定方式，是拿一组已经解决、拥有完整测试和评审记录的内部问题，让 Muse Code、Claude Code、Codex 与现有流程在相同权限和预算下重跑。最后选择的不是跑分最高的名字，而是最稳定地产生可合并代码、同时留下清晰证据的系统。

资料来源

-=||=-收藏赞 (0)