10月12日，Meta发布Muse Wonder和Muse Wonder Full两款新模型。它们均支持百万Token级上下文，重点面向复杂任务、软件工程和Agent应用。
普通版Wonder已经开放Meta Model API与Muse Code，Full目前通过Muse Code订阅提供。与此同时，Meta将Active Memory（主动记忆）和Active Focus（主动专注）作为此次发布的两项核心能力。
前者强调跨会话保留和检索相关信息，后者强调模型在复杂任务中持续推进、处理障碍和修正错误。
这也是此次发布值得关注的地方：在上下文容量不断扩大的同时，Meta开始把信息记忆与长任务执行放到同一套模型能力中。
不过，这两项能力究竟能在多大程度上改善实际工作，还需要结合模型评测、工具环境和产品开放范围来看。
两款模型：共享百万上下文，开放入口不同
普通版的API模型ID为muse-wonder-1.0，服务地址为https://api.meta.ai/v1。
Meta官方文档显示，其上下文上限为1,048,576 Token，模型卡概括为1M。
这表示模型在推理时可以处理约100万Token的上下文，但不能直接换算为100万汉字，也不意味着单次回答可以输出同样长度的内容。
模型卡列出的输入模态包括文本、图像、视频和音频，输出模态为文本。两款模型因此可以理解不同形式的输入信息，但多模态理解并不等同于图片或声音生成。
Meta目前尚未公开两款模型的总参数量和激活参数量。
从开放方式来看，两个版本存在明显区别。
普通Wonder已经提供按量计费的API，价格为每百万Token输入4美元、缓存输入0.20美元、输出20美元。API文档目前将它标记为预览状态。
Wonder Full则主要通过Muse Code订阅使用。官方模型页面列出了两个支持Full的档位：每月50美元的Power Usage，以及每月200美元的Maximum Usage。
Full尚未公开独立的按量API价格，因此普通Wonder的Token定价不能直接用于计算Full的调用成本。
两款模型虽然共享百万上下文规格，但产品入口、使用额度与计费方式并不相同。
Active Memory：长上下文之外，还需要正确检索历史信息
上下文窗口越来越长，已经成为近几年大模型发展的一个明显趋势。
但对于长期运行的Agent来说，容量并不是唯一的问题。
一个持续数周的软件项目，可能积累大量需求文档、代码修改记录、测试结果和对话信息。其中既包括仍然有效的要求，也包括已经被替代的方案。
模型即使能够读取全部历史，也需要判断哪些信息与当前任务相关、哪些决定已经失效。
Meta将这种跨会话携带重要信息、并在需要时主动找回相关细节的能力称为Active Memory。
例如，一个项目原本使用邮件登录，后来决定改用企业单点登录。两条要求都存在于历史记录中，但继续开发时应当以更新后的决定为准。
这个例子说明，记忆的价值不仅在于保留信息，还在于检索的相关性、时效性以及对冲突信息的处理。
Meta在研究介绍中将Active Memory与Active Focus结合讨论：模型不仅需要取得相关上下文，也需要在任务执行过程中适应新的信息和要求。
不过，这里需要区分模型能力与产品层面的记忆系统。
百万Token上下文并不自动形成永久记忆库。历史信息如何保存、更新、隔离和删除，仍然取决于接入产品的存储机制与权限体系。
同样，使用Wonder API也不意味着模型会自动访问应用未提供的历史会话或用户文件。
对于开发者而言，Active Memory是值得关注的能力方向，但它并不能替代应用侧的数据管理。
Active Focus：长任务执行仍取决于工具和运行环境
如果说Active Memory主要关注信息能否被正确使用，那么Active Focus关注的是任务能否持续推进。
Meta将其描述为模型在遇到困难时尝试其他方法、处理错误、适应新要求，并在必要时向用户寻求澄清或确认重要操作的能力。
这一方向尤其适用于软件工程和多步骤Agent任务。
例如，修改一个涉及多个文件的项目，通常不止需要生成代码。
模型还需要理解现有结构、定位相关文件、执行修改、运行测试，再根据错误结果继续调整。
整个过程中，任何一个环节都可能出现新的问题。如果模型无法有效利用工具返回的结果，或者不能在失败后重新规划，任务就可能中断。
Meta开发者页面将长时间执行、多文件修改、子Agent分工和并行工具调用列为Wonder的主要应用方向。
但工具调用与实际执行仍然是两个不同环节。
对于开发者自定义的工具，模型负责生成调用请求，真正访问数据库、编辑文件或执行命令的是外部应用和运行环境。
Muse Code则提供了一个现成的终端Agent入口，可以在项目中规划、修改文件和运行命令。官方文档同时说明，它具有操作审批与操作系统沙箱等机制。
因此，模型的持续执行能力、Agent运行环境的完整程度，以及实际开放的执行权限，需要分别评估。
在软件开发中，模型生成了测试命令，并不代表测试已经运行；最终回答中出现“测试通过”，也不能代替真实的执行记录。
Meta展示了根据图像构建3D厨房游戏的演示，以及涉及个人偏好和复杂关系的礼物规划、婚礼座位安排等任务。
这些案例展示了记忆、推理与执行能力结合后的应用形态，但仍属于官方演示，不能直接等同于所有外部应用已具备相同的数据接入和执行能力。
Muse应用中的新体验也将分阶段推出。
对于第三方开发者，模型能力能否转化为可靠的任务交付，仍然依赖工具调用、任务状态管理、错误恢复和结果验证等配套机制。
长程编程评测：79%的成绩需要结合测试条件理解
在此次发布的评测数据中，长程软件工程是比较突出的部分。
Meta官方公布的DeepSWE 1.1成绩显示：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
DeepSWE 1.1包含113项任务，涉及91个代码仓库和5种编程语言，使用功能测试与回归测试判断任务结果。
相比单纯生成代码或回答编程问题，它更关注模型能否在既有软件项目中完成修改，并通过相应验证。
不过，上述结果并非全部来自统一条件下的同一套测试。
Meta模型卡说明，Wonder、Wonder Full与Opus 5.5的成绩使用第三方Datacurve结果，GPT-6 Astra则采用OpenAI报告的成绩。
因此，这组数据可以用于了解模型在相关基准中的表现，但不能视为所有模型在完全相同工具、推理预算与运行环境下的严格对照。
在另一个强调更长任务执行的软件工程基准SWE-Marathon中，Wonder Full取得57.5%，普通Wonder为53.1%。
模型卡注明，该项目使用Abundant AI的评测结果，但不同模型采用的Agent环境并不完全相同，其中Wonder Full标注了xhigh推理档位。
这意味着最终成绩可能同时受到模型能力、工具环境和执行策略的影响，不能将差距全部归因于模型本身。
如果看综合能力指标，结果又有所不同。
在Meta汇总的Artificial Analysis Intelligence Index中，Wonder Full为56分，普通Wonder为52分，而Opus 5.5为58分。
长程编程任务上的较高成绩，并不意味着模型在综合能力上同样排名第一。
DeepSWE、SWE-Marathon和综合智能指数衡量的是不同能力。对于开发者而言，实际选择模型时，还需要考虑任务类型、成功率、响应成本以及工具环境的兼容性。
尤其是长时间运行的Agent任务，最终成功率并不能完全反映执行过程。
一次成功可能经历多轮修复与验证，也可能消耗大量Token和工具调用。真实应用中的成本、稳定性与错误恢复能力，同样值得关注。
缓存输入便宜95%，但任务总成本不能直接按此计算
普通Wonder的API价格中，缓存输入的折扣较为明显。
每百万Token普通输入收费4美元，缓存输入收费0.20美元，相当于命中缓存的输入Token单价降低95%。
对于需要多轮处理同一个项目的Agent，这种计费方式有实际意义。
系统指令、项目背景和部分历史上下文可能在连续请求中被重复使用。如果这些内容能够命中缓存，相应输入成本就可以降低。
但这并不意味着整个Agent任务的费用也能减少95%。
假设某个工作流经过多轮调用，累计使用1000万缓存输入Token、100万普通输入Token以及100万输出Token。
按照当前刊例价格：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
如果同样的1100万输入Token全部没有命中缓存，输入成本将达到44美元，加上输出费用后合计64美元。
两种情况下，Token总费用相差38美元，下降约59.4%。
这一计算基于假设的多轮累计用量，并非Meta公布的实际任务账单。
它说明，缓存价格和任务总成本是两个不同的指标。
实际执行中，模型可能需要反复输出代码、调用工具、分析测试结果或重新尝试失败的步骤。这些操作依然会产生相应费用。
Meta目前采用自动前缀缓存机制，匹配的是请求开头相同的Token序列。
因此，保持系统说明和可重复使用的上下文相对稳定，有利于提高前缀复用率；如果靠前的内容持续变化，后续相同内容也可能无法有效命中缓存。
开发者可以通过API响应中的cached_tokens字段查看缓存命中数量，而不是仅凭多个请求属于同一项目就推断其已被缓存。
此外，Meta表示Wonder没有额外的长上下文单价溢价，但内置网页搜索等工具可能单独计费。其中网页搜索的公开价格为每1000次查询2.50美元。
长期运行Agent的实际成本，仍需结合缓存命中率、输出规模、重试次数和工具使用量计算。
API、订阅与数据训练设置需要分别看待
除了模型性能和调用成本，Muse Code与Meta Model API在订阅额度和数据使用规则上也存在区别。
Muse Code订阅对应的是产品内的使用凭证和配额。用户另外创建的Model API密钥，仍按照API规则独立计费。
因此，通过50美元或200美元订阅获得Wonder Full的使用权限，并不代表开发者可以将这份订阅额度直接用于自己的外部应用。
数据处理规则也需要按照具体入口确认。
Meta Model API的Standard模式说明，请求内容不会用于训练Meta模型。普通Wonder在Model API上目前不提供Contributor折扣模式。
Muse Code订阅则默认启用Contributor模式。
在该模式下，Meta可以使用用户发送的提示词、代码、文件、上下文及模型回复来训练后续模型。用户可以在设置中关闭这一模式，关闭后的新内容不再按该模式用于训练。
这意味着，即使使用同一模型，不同产品入口的数据设置也可能不同。
对于个人开发者，这会影响订阅方案与按量API之间的选择；对于需要处理公司代码、内部文档或客户数据的团队，则需要进一步确认数据使用条款和相关权限设置。
模型名称相同，并不代表计费方式、使用额度和数据处理条件完全相同。
从上下文记忆到任务交付，还有多少距离？
Muse Wonder此次发布提供了明确的API入口、百万上下文规格、公开Token价格，以及覆盖长期软件工程和Agent任务的评测数据。
与此同时，Meta将Active Memory和Active Focus放在模型能力介绍的核心位置，强调历史信息的主动检索与复杂任务的持续执行。
这两项能力所针对的问题并不陌生。
随着Agent从短时问答转向跨文件、跨工具和跨会话的长期工作，模型需要处理的信息不再局限于单次请求，任务执行也越来越依赖持续的状态管理和工具反馈。
但目前的官方演示与基准成绩，还不足以直接推导真实应用中的整体收益。
跨会话记忆能否准确识别已更新的信息，长任务能否在失败后恢复，工具调用结果是否得到正确处理，最终产物是否通过验证，都需要进一步观察。
对于开发者而言，值得关注的不只是模型的上下文上限和评测排名，还包括它与现有Agent框架结合后的实际表现。
Muse Wonder提供了观察长任务Agent能力的新模型选择，但信息记忆、工具执行与最终交付之间的可靠性，仍然需要通过真实工作流检验。