Meta推出Muse Wonder：模型已可调用，开放权重仍未承诺

Meta于2026年10月12日在Muse Wonder发布公告中推出Muse Wonder和Muse Wonder Full：Muse Wonder已通过Meta Model API与Muse Code提供，Full版本面向Muse Code订阅者。它们是面向个人及专业代理任务的模型，重点是跨对话保留背景、持续推进复杂任务和编程。开发者现在可以调用Muse Wonder，但调用模型与取得模型权重是两种不同的权限。

Axios在Wonder系列报道中引述Meta超级智能实验室负责人Alexandr Wang的话：“We're still committed to open source”；报道同时指出，Wonder系列是否开放权重尚无明确说法，领先性能的主张也有待独立测试。对使用者来说，眼下已确定的是托管调用和产品内的使用资格，而不是自行下载、部署模型的权利。

Muse Wonder把记忆和持续执行放进同一任务流程

Muse Wonder的能力主张围绕Active Memory和Active Focus展开。前者旨在跨对话保留与用户有关的背景，并在后续任务中取回相关细节；后者旨在让代理遇到障碍时尝试其他方法、根据新信息调整行动，必要时请求澄清，并在重要操作前征求确认。两者配合，针对的是需要多次判断与行动才能完成的工作，而不只是单轮问答。

编程是这一设计的具体场景：代理要记住需求，在代码库中完成修改，再根据测试结果继续修正。发布时展示的任务还包括把可定制图片输入转成可玩的立体厨房游戏，以及依据复杂匹配条件制作婚礼座位安排。这些展示说明了产品设定的任务范围；演示中的完成过程并不能直接换算成开发者在其他工具、权限和数据条件下的成功率。

跨对话记忆也带来判断上的难题。较早提出的条件可能已经改变，新的任务又可能只需要其中一部分背景；取回的信息是否相关，与能否持续执行同样影响最终结果。因而，评价这类个人代理时，单次回答是否流畅只是观察点之一，更关键的是它能否在条件变化后继续完成目标。

四层可用性对应不同的入口与权限

Wonder系列的“可用”至少涉及托管API、编码工具、计划中的Muse体验和模型权重。它们对应不同版本与使用条件，不能因为产品同属一个系列，就把某个入口的资格推及其他入口。

• Meta Model API：已提供Muse Wonder的托管调用。开发者向服务发送请求并取得输出；已公布的API入口没有因此包含Muse Wonder Full，也不提供可自行运行的权重。
• Muse Code：已提供Muse Wonder；Muse Wonder Full面向Muse Code订阅者。这里的订阅资格针对编码工具中的Full版本，不能理解成所有调用入口都开放Full。
• Muse订阅体验：Muse Wonder计划用于Muse的部分后续体验，并先向订阅者推出。这是一项未来的产品部署安排，与目前已提供的API和Muse Code入口应分开看。
• 开放权重：意味着使用者能够取得模型参数，并在许可及技术条件允许时自行部署。现有托管调用和订阅入口不赋予这项权限，Wonder系列目前也没有明确的权重开放承诺。

这种区分会影响对产品能力的预期。例如，API接入对应Muse Wonder；如果一项展示或基准成绩属于Muse Wonder Full，就不能仅凭系列名称推断API用户会得到相同表现。代理使用的工具、可执行的操作和推理设置，也可能改变同一任务的结果。

此前已有Meta模型发布权重，并不能代替针对Wonder系列的决定。只有出现具体的权重发布安排，使用者才能进一步判断许可范围、部署条件及两个版本各自是否包含在内。在此之前，自行部署仍不是已确认的Wonder使用方式。

基准成绩需要按版本和测试来源分别看

Meta的Muse Wonder模型卡将Muse Wonder及Full与GPT-6 Astra、Claude Fable 5.1和Claude Opus 5.5比较，并列明Personal Superintelligence Index、MemoryBench和FocusBench等内部评估，以及采用Artificial Analysis、Datacurve和Abundant AI结果的部分外部项目。模型卡还列出文本、图像、视频和音频输入、文本输出，以及推理时一百万token的上下文长度。能力规格说明模型能接收什么；基准成绩则取决于具体任务、版本和执行方式。

内部评估与外部结果并列，让成绩单覆盖了个人代理、专业任务、记忆和软件工程等不同问题，但不能把整张表当成由同一独立机构在统一环境下完成的复核。内部记忆测试关注较长对话中的关键信息能否被取回；持续任务测试关注遇到障碍后能否继续推进；编程测试则通常涉及修改代码和运行验证。某个项目上的优势，适用范围首先是该项目的任务定义和评分方法。

软件工程比较尤其需要保留“模型加工具”的边界。部分内部编程对比让不同模型使用相同的基准执行框架；部分外部成绩则沿用各提供者原有的代理产品或工具组合。后一种结果反映的是整套执行配置的表现，不能直接解释为只替换底层模型后的差距。

这也解释了为什么Full版本的成绩不能直接用于判断API版本。两个版本虽然同属Wonder系列，但可用入口不同；比较时还要看推理设置、所用工具，以及成绩究竟来自内部运行、模型提供方还是第三方。接下来最能厘清其前沿模型定位的，是在可比任务和工具条件下，对两个版本分别开展独立测试；权重发布条件若有明确决定，也会直接改变开发者的部署选择。

相关阅读：

• Faraday复现论文胜过前沿模型，但它的基准还没被独立复现
• Muse Image接入Runway API：一张图1美分，可用10张参考图
• Meta Muse Spark 1.3进入API：关键操作会先向用户确认