Muse Spark 1.3：长任务协作的下一步

更新重点是持续协作

2026年9月2日，Meta 宣布 Muse Spark 1.3 发布，并在 Muse Code 与 Meta Model API 提供 max reasoning。公告强调长任务执行、复杂指令遵循，以及在同一条长对话里区分多个任务的能力。Meta 还称，新版本更主动地澄清模糊要求，在受阻时寻求帮助，并在重要操作前请求确认。官方发布公告

这些表述指向一个很实际的问题：用户很少从头到尾保持最初的要求不变。整理报告时可能追加一份材料，写代码时可能临时缩小范围。能否正确理解这些补充，并继续完成原来的目标，是衡量助手是否适合长任务的重要角度。这里说的是评估方向，不能把发布声明直接当作已验证的日常表现。

排行榜背后仍有运行条件

Meta 同时公开了评估方法说明。文件表明，结果涉及不同智能体框架与推理设置，部分对比数据来自官方排行榜或模型供应商报告。文档也承认，对第三方模型采用的提示词、工具与运行环境，不一定体现其经过专门优化后的最佳表现。官方评估方法

因此，读榜单时值得先问：比较的是模型本身，还是模型加上工具和执行框架之后的系统？这并不使成绩失去参考价值，但会影响结论适用范围。一个工程任务包含检索、编辑、运行和验证，任何环节发生变化，都可能改变最后的结果。

用一次中途调整检验长任务

如果要试用这类模型，我建议设计一项规模不大的完整任务，例如根据几份公开材料制作简报。先写明篇幅、来源和交付格式；任务开始后，再追加一条合理限制，观察它是否保留原要求，并准确处理新增条件。

验收时除了检查最终文件，还可以对照三个问题：新限制有没有执行，原本必须保留的内容有没有遗漏，模型是否把尚未完成的步骤说成已经完成。这种方法能把“协作感”转成可核查的行为，减少只凭语气流畅判断能力的偏差。

也可以重复同一个任务几次，记录需要人工纠正的位置。一次成功演示无法说明长期稳定性，多次遇到同类问题则值得追查。本文没有对 Muse Spark 1.3 进行实际测评，以上为基于其发布方向提出的测试建议；访问权限与产品可用范围仍应以具体账户为准。

本文由 AI 协助检索与撰写，经来源核对后整理发布。链接所载信息可能继续更新；文中日期指事件日期，本文发布于 2026 年 9 月 17 日。