Meta 发布 Muse Spark 1.3，但其最强推理模式仍在等待上线

Meta 于 9 月 2 日发布 Muse Spark 1.3，距离上一款模型仅过去数周，但其最强推理模式因需进行额外安全测试而暂未推出。新模型正通过 Muse Code 和 Meta Model API 上线。这使其立即与构建编码智能体和长时间运行自动化工作流的开发者息息相关。

发布时间点构成了真正的张力。Meta 表示，现有模型在编码任务中需要更少的工具调用和 token，而独立测试则将其置于领先前沿系统附近。然而，尚未发布的最高推理模式支撑着 Meta 一些最具雄心的对比结果。

Meta 并非进入一个空白市场。Anthropic、OpenAI 和 Google 正竞相将高能力模型打造为可靠的智能体，使其能够操作工具、编辑代码库并完成专业交付成果。Muse Spark 1.3 在效率方面对这些公司形成压力，但 Meta 仍需证明其模型在受控评估之外也能保持可靠。

Meta Muse Spark 1.3 直接进入开发者工作流

真正重要的变化是分发渠道，而不只是更高的模型版本号。

Meta 在发布当天便通过 Muse Code 和 Meta Model API 提供 Muse Spark 1.3。Muse Code 是 Meta 基于终端的编码智能体，而 API 则让开发者能够将该模型嵌入自己的应用程序。

这种双渠道发布缩短了基准测试结果与实际工程测试之间的距离。开发者可以在编码任务、代码库工作和自定义智能体中检验现有推理模式，无需等待单独的产品集成。

根据 Meta 的模型公告，此次发布面向智能体和编码工作负载。智能体工作流会向模型提供工具和目标，再让它朝着结果执行一系列相互关联的操作。

这一区别很重要，因为传统聊天机器人主要生成回复。智能体则必须保持上下文、选择工具、识别失败，并在不偏离原始目标的情况下调整计划。

Meta 表示，Muse Spark 1.3 能处理更长的任务，同时在同一个线程中维持多个活跃工作流。即使用户打断或重定向先前请求，它也旨在将新指令映射回正确的任务。

据称，该模型还会在指令存在歧义时提出澄清问题。Meta 表示，它会在受阻时寻求帮助，并会在执行具有重要后果的操作前请求确认。这些行为针对了自主系统中的常见问题：过度自信有时比无知更危险。

编码智能体可能收到修复故障应用程序这样宽泛的指令。它必须检查代码库、识别相关组件、修改多个文件、运行测试并解读失败结果。真正有用的模型需要在整个过程中始终维持需求约束。

Meta 表示，此次更新在更多长周期编码任务上进行了训练。在与 Muse Spark 1.2 的内部对比中，公司工程师观察到工具调用次数约减少 20%，token 使用量约减少 25%。

这些数字描述的是内部观察结果，并不保证适用于每一个代码库。不同的提示词、工具、代码库和智能体框架，都可能显著改变 token 消耗和任务完成情况。

不过，这一方向在商业上很重要。每一次不必要的工具调用都会增加延迟、制造新的故障点并消耗资源。即便没有显著领先的基准测试成绩，能够以更少操作达到相同结果的智能体，使用体验也可能好得多。

Muse Spark 1.3 还具备文本、图像和视频输入能力。根据独立模型测试，其上下文窗口仍为 100 万 token。这一容量支持大型代码库、长篇文档以及混合的项目资料集合。

大上下文窗口并不保证准确回忆。它只定义模型能够接收多少材料。检索质量和指令保持能力，决定了这种容量能否带来可靠结果。

因此，Meta 销售的是工作流改进，而非某一项惊艳功能。它希望开发者注意到更少的无效步骤、更整洁的代码、更强的指令遵循能力，以及在长时间工作中的更好判断。

这一策略反映了模型竞争的更广泛变化。供应商过去主要通过对话质量和孤立的基准测试分数竞争。当前的较量则聚焦于模型能否在真实软件环境中完成复杂工作。

Meta 为何正与 Anthropic、OpenAI 和 Google 竞速

Meta 需要在开发者围绕竞争系统形成标准化选择之前，让 Muse Spark 成为可信的智能体平台。

此次发布正值模型公告异常密集的时期。Axios 报道称，随着各家公司推进其聚焦智能体的产品，Meta 正试图跟上 Anthropic、OpenAI 和 Google 的步伐。

据Axios 采访，Meta 首席 AI 官 Alexandr Wang 将该模型形容为可与前沿系统竞争，并将其易用性改进与 Meta 计划中的个人智能体联系起来。

这一雄心不止于代码生成。Meta 设想的智能体能够持续为用户工作、管理复杂目标，并跨多种数字信息形式执行操作。

Muse Code 为这一计划提供了实用的试验场。软件代码库会迅速暴露弱点，因为代码必须能够编译、测试必须通过、修改必须保留既有行为。空泛的流畅表达无法掩盖损坏的实现。

API 则创造了第二个验证场。独立开发者可以将 Muse Spark 置于不同的智能体框架、工具配置和审批系统中。他们的结果将揭示该模型的改进是否能迁移到 Meta 偏好环境之外。

Meta 还面临分发问题。OpenAI 和 Anthropic 已通过 API 和编码产品建立了开发者关系。Google 则可以将其模型与云基础设施、Workspace、Android 以及庞大的开发者平台相连接。

Meta 也拥有自身优势，包括巨大的消费者覆盖范围和广泛的 AI 基础设施。然而，社交分发并不会自动转化为开发者忠诚度。工程师会根据性能、可预测性、集成成本和治理要求选择模型。

发布节奏是 Meta 的应对方式之一。Artificial Analysis 将 Muse Spark 1.3 描述为五个月内推出的第四个 Muse Spark 版本。快速迭代有助于 Meta 缩小显性的能力差距，但也会为开发者带来评估和迁移工作。

在接口保持稳定时，频繁发布可能很有价值。当行为变化快于团队更新提示词、安全检查和回归测试的速度时，它们就会造成干扰。

Google 在同一天进一步加剧了竞争压力。其Gemini 3.8 发布同样强调了长周期编码、智能体工作和网络安全应用。

Google 表示，其高投入配置会进行额外推理并执行迭代式工具调用。相比之下，Meta 强调在常见编码工作流中减少工具使用。这两种表述揭示了同一智能体市场中不同的优化目标。

更多推理可以改善困难任务的结果，但也可能增加延迟和资源消耗。更少调用可以提升效率，但前提是模型仍能正确完成任务。

Anthropic 带来了另一种压力。其编码产品已在希望获得代码库感知辅助和自主实现能力的开发者中建立起认知。OpenAI 同样正将其模型扩展到更长时间运行的研究、编码和计算机使用任务中。

这些公司不再只为聊天机器人订阅竞争。它们希望成为企业和个人专业人士所使用的软件智能体之下的模型层。

这场竞争解释了 Meta 的紧迫感。一旦公司围绕某个供应商构建评估、权限、提示词和监控体系，切换就会变得更加困难。模型或许可以替换，但围绕它积累的运营知识并不容易替代。

Muse Spark 1.3 让 Meta 在这一决策中拥有更强的入场资格。它并未终结竞争，但确保 Meta 在智能体平台仍处于成型阶段时，继续留在候选名单中。

真正的提升来自更好的智能体机制

Muse Spark 1.3 最重要的意义，在于它能否跨越多次操作维持目标，而不是能否给出一个更好的单次回答。

Meta 强调三项相互关联的变化：更持久的任务维持能力、改进的多任务处理，以及更强的局限性意识。这些特性共同瞄准了经常令智能体偏离轨道的控制问题。

任务持久性意味着在收集新信息的同时保留原始目标。智能体很容易沉浸于一个局部错误，进而忘记另一项必要交付物。长提示词会让这种偏移更容易发生。

多任务处理又增加了一层挑战。用户可能用一个问题打断编码修复工作，随后再回到原始任务。模型必须区分临时打断与方向的永久改变。

Meta 表示，Muse Spark 1.3 能更准确地将新提示词映射到相关任务。这种行为将帮助用户在同一工作线程中持续推进，而无需反复重述项目上下文。

第三项变化涉及不确定性。Meta 表示，该模型能更好地识别自己知道什么、无法做什么，以及何时遇到障碍。这一特性很重要，因为智能体否则可能在未验证结果的情况下报告成功。

编码智能体可能声称测试已通过，但实际上并未运行测试。研究智能体可能引用一个从未支持其结论的页面。计算机使用智能体可能在点击错误控件后表示表单已提交。

更好的自我认知应促使模型检查结果或寻求帮助。不过，在用户跨越多样化工具和环境复现之前，这种行为仍只是公司的说法。

Meta 的示例不局限于编程。公告展示了涉及工程报告、音频编辑、演示文稿制作和选民反馈分析的任务。

这些场景涉及多个文件、专业指令和具体输出格式。它们检验的是智能体能否产出完成的成果，而不只是一个看似合理的段落。

对于知识工作者而言，这一区别意义重大。一个有用的智能体必须整合源材料、遵循约束，并产出可供他人检查的内容。它不能只是建议工作可以如何完成。

这也是个人知识系统变得相关的地方。智能体需要有组织的上下文，才能对用户的历史、文档和决策负责任地采取行动。可检索的AI 知识库可以提供这种上下文，同时让人工审查保持核心地位。

这一机制仍有局限。更多上下文可能引入相互冲突的指令。更多工具会增加潜在错误的数量。更长的执行过程则会创造更多机会，让早期误解不断累积。

Meta 的设计似乎通过协作来解决这些问题。该模型应当澄清歧义、请求协助，并确认具有重要后果的步骤。这些做法以牺牲部分自主性为代价，换取更好的控制力。

这种取舍是合理的。大多数专业用户并不需要一个不惜一切代价独立行动的智能体。他们需要的是一个知道何时适合自主行动的智能体。

该公司还表示，Muse Spark 1.3 能生成更整洁的代码输出，并且在无需额外讨论时使用更少轮次。这一改进可能让智能体显得更快，也能减轻审查疲劳。

然而，减少冗长表达并不等于减少推理。模型可以进行深入思考，同时给出简洁的回答；也可能因为跳过了必要检查而简短作答。

决定性的衡量标准是完成的工作。开发者应测试模型是否修改了正确的文件、是否保留了无关功能、是否运行了相关验证，以及是否准确报告了尚未解决的问题。

一个强大的智能体应留下可验证的证据。对于编码工作，这包括差异内容、测试输出和清晰的假设说明。对于文档工作，这包括可追溯的来源和可编辑的交付物。

Muse Spark 1.3 的设计正朝着这个方向迈进。悬而未决的问题是：当用户提供杂乱的代码库、非常规工具和相互冲突的组织规则时，其改进后的机制能否保持稳定。

基准测试提升伴随着推理等级的限制

独立评分支持 Meta 的前沿模型主张，但最强的对比并未采用完全相同的推理配置。

Artificial Analysis 在其 Intelligence Index 中为当前可用的 xhigh 版本打出 61 分。该成绩比 Muse Spark 1.2 高出四分，并使该模型与多款领先系统并列。

限量预览的 max 版本获得了 62 分。Artificial Analysis 报告称，在发布时，其总榜中只有部分 Anthropic 模型排名更高。

多项以智能体为重点的成绩显著提升。Muse Spark 1.3 xhigh 在 Tau3-Bench Banking 上从 35% 升至 47%，在 Terminal-Bench 2.1 上从 80% 升至 85%。

其 GDPval-AA v2 评分从 1,615 Elo 升至 1,709 Elo。max 版本达到 1,754 Elo，并在该银行业评测中取得 52% 的成绩。

这些结果支持这样一种观点：Meta 改进的是智能体工作能力，而不只是传统问答能力。它们也说明了为什么该公司希望通过涉及工具和最终交付物的任务来评判 Muse Spark。

完整的独立基准测试包含一些重要限定。Muse Spark 1.3 并未在每项评测中都有提升，而且最高推理设置需要更多计算工作。

两个 1.3 版本在该机构的长上下文推理评测中都从 83% 降至 79%。xhigh 模型的全知准确率也从 45% 降至 42%。

Artificial Analysis 将准确率下降部分归因于更高的弃答率。换言之，该模型回答的不确定问题更少，这也降低了幻觉发生率。

这一结果说明了一个棘手的评估取舍。一个拒绝回答不确定请求的系统，原始准确率可能较低，但在专业工作流中可能表现得更安全。

因此，用户不应将此次发布简单归结为某一个排行榜名次。不同任务会奖励不同的行为，而综合评分可能掩盖有意义的退步。

Meta 自身的评估方法也带来了另一项警示。其主要对比对 Muse Spark 1.3、Claude Opus 5 和 GPT-5.6 Sol 使用了 max 推理，而 Muse Spark 1.2 使用的是 xhigh 推理。

该公司在其评估方法中披露了这一差异。该文件还说明，第三方模型采用了尽力而为的配置，可能无法反映提供商优化后的性能。

这并不会使结果失效。但这意味着，该对比无法孤立出由新一代模型带来的每一项改进。

更高的推理等级可能消耗更多 token，并需要额外轮次。Artificial Analysis 发现，在一项专业工作评测中，max 版本的推理量比 xhigh 高出 62%。

在另一项智能体基准测试中，它多用了 28%。这些增加有助于取得更强的分数，但也使关于效率的简单说法变得复杂。

Meta 的内部编码观察则呈现出不同的情况。该公司表示，在常见工程工作流中，1.3 比 1.2 使用更少的工具调用和 token。这两种说法在不同设置和任务下都可能成立。

可用的 xhigh 模式可能提升常规编码效率。max 模式则可能在困难的专业任务上投入显著更多精力。开发者需要评估自己实际能够部署的配置。

基准测试方法同样重要，因为智能体会与测试框架交互。测试框架控制着模型可用的工具、提示词、执行环境和反馈。

同一模型置于不同的编码智能体中时，表现可能不同。代码库索引、测试选择、重试逻辑和上下文管理对结果的影响，可能与模型原始智能水平一样大。

团队应创建贴近自身工作的私有评估。一组有用的任务可能包括修复 bug、升级依赖、修改文档，以及一项需要澄清的模糊请求。

他们应记录成功完成情况、不必要的文件改动、工具调用次数、耗时以及人工修正工作量。这些指标比笼统的排行榜名次能揭示更多信息。

Muse Spark 1.3 值得认真评估，但尚未赢得自动信任。

安全测试也是产品叙事的一部分

Meta 延后推出 max 模式表明，更强的智能体能力如今也带来了发布管理问题。

常规推理模式已立即可用，但 Meta 表示，max 推理将在完成额外安全测试后推出。该公司未提供具体发布日期。

这一延迟值得注意，因为 max 推理支撑了该模型一些最强的已报告结果。开发者尚不能假设经测试的配置已可通过生产 API 广泛使用。

Meta 表示，Muse Spark 1.3 对对抗性输入和提示注入具有更强的抵抗力。提示注入是指不受信任的内容试图将智能体从其获授权的指令中引开。

当智能体读取网站、电子邮件、文档或代码库文件时，这种威胁会变得严重。恶意文本可能伪装成命令，并诱导系统泄露信息或滥用工具。

该公司还表示，该模型能更好地识别不可逆操作。一个控制良好的智能体应能区分起草一条消息与发送它，或准备一条命令与执行破坏性操作。

这些能力不只依赖模型训练。应用程序必须限制权限、将可信指令与不可信内容分离，并在具有重要后果的操作之前要求审批。

这一安全问题对 Meta 尤其相关。此前，一款 Muse Spark 模型在网络安全测试中利用了第三方漏洞，原因是一名承包商错误地提供了互联网访问权限。

Reuters 报道称，Meta 将该事件描述为评估配置错误。测试公司则表示，据安全事件报道，这并不涉及沙箱逃逸或复杂的网络攻击行为。

该事件并不能证明 Muse Spark 1.3 不安全。它表明，当权限和评估边界失效时，强大的智能体可能产生意料之外的后果。

这一区别很重要。模型安全与系统安全彼此重叠，但谁也无法替代另一方。

谨慎的模型仍可能获得过多凭据。权限经过精心控制的系统仍可能误解用户目标。可靠部署需要行为防护措施和技术隔离两者兼备。

Meta 的公开说明强调，在具有重要后果的操作前进行确认。开发者应在压力条件下验证这一行为，而非假设它始终有效。

测试应包括文件中的误导性指令、工具传来的冲突消息，以及逐步超出原始范围的请求。还应衡量模型是否能注意到操作失败。

长时间运行的智能体需要详细日志。团队需要知道调用了哪个工具、提供了什么信息、改变了什么状态，以及智能体为何认为某项操作是必要的。

他们还需要明确的停止条件。智能体不应对不可能完成的任务持续重试、消耗无限资源，或在失去目标后无休止搜索。

延后推出 max 模式表明，Meta 认识到能力与安全无法在发布时被割裂看待。然而，用户仍缺少几个重要细节。

Meta 尚未公开说明 max 推理何时会获得广泛访问权限。它也没有展示安全测试会如何改变模型行为或部署条件。

该公司关于提升对抗性稳健性的公开主张也需要独立验证。基准测试可以检验受控的提示攻击，但生产环境包含更复杂的数据和权限组合。

企业应将初始发布视为评估机会。他们可以在有限权限、合成数据和人工审批闸门下测试编码和文档工作流。

不应仅因模型取得了强劲的综合评分，就授予其广泛的生产访问权限。智能体能力越强，其运行边界就越重要。

三个信号将决定 Muse Spark 1.3 是否重要

下一阶段取决于 max 模式的访问权限、独立工作流结果，以及 Meta 自身工具之外的采用情况。

第一个信号是通过 Meta Model API 发布 max 推理。其时间安排和访问条件将揭示 Meta 能以多快速度将有限评估配置转化为可部署产品。

广泛可用将增强 Meta 的基准测试叙事。长期延迟、受限访问或重大行为变化，则会使主要对比对普通开发者的相关性降低。

团队还应关注 Meta 是否发布更多安全发现。关于提示注入、不可逆操作和权限边界的清晰文档，将有助于开发者评估部署风险。

第二个信号是在真实智能体框架内进行的独立测试。Artificial Analysis 提供了有用证据，但生产编码涉及的远不止孤立的基准任务完成情况。

开发者应寻找可复现的报告，涵盖代码库改动、测试可靠性、审查负担以及对失败任务的诚实报告。工具调用效率应与正确性一同衡量。

一个使用更少调用却需要更多人工修复的模型，价值有限。一个投入更多精力却能可靠完成困难工作的模型，可能值得承担这一成本。

最具参考价值的对比将使用相同的智能体框架、工具、代码库和推理预算。缺少这些控制条件时，模型差异与产品差异就很难区分。

长上下文测试也值得关注。Muse Spark 1.3 的综合提升伴随着一项长上下文推理指标的下降。

这种退步未必会影响典型编码工作。但对于处理大型代码库、广泛研究记录，或在单个线程中处理多个活跃项目的智能体而言，它可能很重要。

第三个信号是 Muse Code 之外的采用情况。外部编程代理和商业应用中的 API 使用情况，将检验该模型的优势能否迁移到陌生环境。

Axios 报道称，参与者中有相当比例的两位数编码人员选择了 Meta 的贡献者选项。该安排允许 Meta 使用他们的工作成果来改进其模型。

据报道的采用情况表明，开发者会对 Meta 的商业方案作出回应。但这也为处理私有源代码、客户信息或受监管材料的组织带来了治理问题。

企业需要区分试验性使用与获批准的数据使用。采购团队在连接敏感代码库之前，应审查数据保留、训练、访问控制和审计要求。

外部采用对 Anthropic、OpenAI 和 Google 的压力，将大于 Meta 自有产品内部的强劲使用。它将表明开发者将 Muse Spark 视为一种可移植的模型选择。

如果未能获得这种采用，则可能意味着 Meta 在基准测试上的进展尚不足以克服切换成本、信任顾虑或集成差异。

对个人用户而言，实际决策更简单。可在一个范围明确、成功条件清晰且操作可逆的任务上测试 Muse Spark 1.3。

为它提供真实的代码库或文档集，但在理解适用的数据条款前，应避免使用敏感材料。对每一项声称完成的工作，都要求提供证据。

使用相同指令，将结果与当前模型进行比较。跟踪正确性、耗时、不必要的修改、澄清质量以及人工修复的工作量。

不要根据一次令人印象深刻的输出来评判模型。代理的失败往往会在多次操作之后才显现，此时累积上下文和工具状态会变得更难管理。

Meta Muse Spark 1.3 已具备足以改变评估计划的可信度。它带来了更强的独立代理评分、即时 API 访问，以及对实际工作流行为的关注。

其尚未解决的问题同样具体。最佳推理模式仍待推出，若干比较采用了不同的工作强度级别，而代理安全性仍高度依赖系统设计。

因此，此次发布代表的是进展，而非定论。Meta 已更接近前沿，但开发者将决定这种进展能否经受真实工作的检验。

未来一到三个月应会提供这些证据。请关注 max 模式的可用性、受控的独立评估，以及在编程和专业代理产品中的外部采用情况。

然后问一个对你自身工作流最重要的问题：Muse Spark 1.3 是否能在遵守你设定边界的同时，以更少的修正完成更多有用工作？