# Muse Wonder 想记住你的长期任务，但 API 和 Full 是两道门

> Meta 把跨会话记忆与长期任务执行推到 Muse Wonder 的中心；普通 Wonder API 和 Full 订阅却有不同的入口、账单与数据使用边界。

- Published: 2026年10月13日
- Author: PiRouter Team, Engineering
- Tags: models, agents, pricing
- Canonical: https://pirouter.ai/zh/blog/muse-wonder-memory-focus-access

---
Muse Wonder 在 10 月 12 日发布时，把「记住与你有关的信息」和「把难事做下去」放到了模型卖点的中心。开发者现在可以通过 Meta Model API 调用普通版 Muse Wonder，但能力更高的 Wonder Full 不在这个 API 里：它只向 Muse Code 的 Power 和 Maximum 订阅开放。第三方榜单能告诉我们它在特定试题上进步了多少，却不能替任何人决定该走哪扇门、付哪笔钱、交出哪些数据。

不妨设想一项要分几天完成的工作：周一告诉助手跑步时间、出行方式和膝盖旧伤，周三再让它按临时变化调整周末行程；另一边，软件项目的测试失败，助手要定位原因、修改多个文件，再决定什么时候需要找人确认。前一种工作怕它忘记真正重要的条件，后一种工作怕它只会提出计划，却遇到阻碍就停。Meta 分别把要解决的两类问题称为 **Active Memory** 和 **Active Focus**（[Muse Wonder 研究公告](https://research.meta.ai/blog/muse-wonder)）。它们值得认真看，也值得分清：这是厂商的能力描述，不是我们运行了跨天任务后的结论。

![Muse Wonder 官方发布视觉](/blog/images/muse-wonder-official-social.png "Meta 在发布页展示的 Muse Wonder 视觉。来源：[Muse Wonder 研究公告](https://research.meta.ai/blog/muse-wonder)")

## Active Memory 要记住的不是整段聊天，而是此刻有关的旧条件

长对话不是记忆的全部。一次请求能容纳很多历史文字，模型未必就能在下一次对话里找到那条需要的旧约束；反过来，一个从没出现过的私人偏好，也不会凭空从百万 token 的上下文窗口里长出来。Meta 对 Active Memory 的[原文定义](https://research.meta.ai/blog/muse-wonder)是：跨对话保留与你有关的重要上下文，并在当前任务里主动取回相关细节。开发者[发布说明](https://dev.meta.ai/resources/blog/build-with-muse-wonder)进一步把目标、约束和此前决定列为长期工作中要保持可用的信息。

回到那条假设中的周末路线。一个称得上有用的系统，不能只记住“用户想跑步”，还需要在安排坡道、时间和交通时拿出旧伤与出行方式；但如果用户后来说明膝盖已经恢复，它也不该把旧信息当永远有效的命令。前半段是召回，后半段涉及冲突处理与更新。公告清楚表达了前一种能力目标，却没有让这篇文章能够独立判断真实账户的记忆保留期、删除机制、错误召回频率，以及新旧偏好互相矛盾时实际如何裁决。我们没有登录使用或连续追踪一个账户，不能把这些空白写成已经解决。

官方[模型目录](https://dev.meta.ai/docs/models)给普通 Wonder 标出 1,048,576-token 上下文窗口，并写明文本、图片、视频、音频、PDF 输入与文本输出。这个数字回答的是一次模型请求可以处理多长的输入规格，不回答「它跨会话记住了什么、何时又忘记」。把长上下文直接当跨会话记忆，是选型时最容易走错的第一步。开发者要验证这项能力，至少应准备一组旧条件、一次新条件变更和一次隔时重访的任务，分别记录它取回了什么、漏了什么、是否沿用过期信息；这是建议的验收方法，不是本稿已经完成的实验。

Meta 的官方 MemoryBench 原图提供了另一种证据：厂商展示在长交互历史中回想和使用用户上下文的内部评估，图中普通 Wonder 在 max 档为 85.6%，Full 为 85.5%（[研究公告及图示](https://research.meta.ai/blog/muse-wonder)）。这说明厂商至少拿出了一个针对记忆的测试切面；它不意味着普通版在所有记忆任务中超过 Full，两个相邻读数也不足以推断真实个人资料长期保存时的准确率。图是厂商发布的内部评估，不能与下文 Artificial Analysis 的独立总分画等号。

![Meta MemoryBench 图比较长期交互历史中的上下文利用能力](/blog/images/muse-wonder-memorybench.png "厂商内部 MemoryBench 评估：普通 Wonder 85.6%、Full 85.5%，不代表真实个人资料长期保存的准确率。来源：[Meta 研究公告](https://research.meta.ai/blog/muse-wonder)")

## Active Focus 的难点：继续尝试，也知道什么时候停下

在代码仓里，一次「修好问题」常常不是一次生成。提出假设、定位多个文件、修改、跑测试、读报错、撤回错误改动，再给人解释取舍，可能跨越许多次工具调用。Meta 把 Active Focus 描述为朝困难目标持续工作：换一种方法、跨过阻碍、根据新信息调整；同时在需要澄清时提问，在重要行动前找用户确认（[研究公告](https://research.meta.ai/blog/muse-wonder)）。开发者文章把多步规划、顺序调用工具和调用失败后的恢复列入模型定位（[开发者发布说明](https://dev.meta.ai/resources/blog/build-with-muse-wonder)）。

这里真正微妙的不是“更有毅力”，而是**坚持和克制必须同时存在**。测试报错后换方案是好事；在有隐私或外部副作用的操作前继续自动尝试，未必是好事。假设一个任务要求在用户的日历上预留行程，安排草案可以多轮推敲，发出邀请前是否该确认却是另一道权限问题。Meta 的措辞是模型被训练去询问和确认，并非任何接入它的应用都已经替你实现了确认 UI、权限范围与撤销能力。系统设计者仍需自己定义哪些动作必须由人批准，尤其是发消息、花钱、写入第三方服务这类不可逆步骤。

Meta 在公告中提到 FocusBench 和面向长时间软件项目的 SWE-Marathon 作为评估线索。它还展示了跨应用制定跑步计划、定制礼品、婚礼座次等演示。演示帮助读者看到一种工作形态，不提供一般用户的成功率、平均耗时、失败恢复代价，也不能证明已经有可复制的端到端产品流程。官方关于「泛化」的图则比较被后训练重点覆盖的任务与未被覆盖任务：图中不同推理强度的点落在各自位置，Meta 认为 Wonder Full 对陌生任务的表现高于用 Spark 1.3 趋势预测的水平（[研究公告的泛化讨论](https://research.meta.ai/blog/muse-wonder)）。这是厂商对实验分布的解释，不是现实世界里任意新任务都能做成的保证。

![Meta 比较已针对训练任务与未针对训练任务表现的泛化散点图](/blog/images/muse-wonder-generalization.png "每个点对应不同推理强度；趋势解释来自厂商，不保证任意现实任务成功。来源：[Meta 泛化讨论](https://research.meta.ai/blog/muse-wonder)")

如果你的目标是每晚自动接续一项工作，那么应该测的是一个带中断和失败的完整任务，而非只截取一次漂亮回答：昨天留下的约束今天能否取回，失败时有无证据表明换路有效，权限点会不会被越过，最终结果能否由人复核。尤其不能把长时间运行与无人值守混成一回事。一个可操作的验收任务可以故意放进互相冲突的两条旧要求，再在中途让工具返回失败：观察模型是否指出冲突、是否选择另一条路、是否在外部写入前等待明确批准。记录的不只是最终答案，还应包括每一步实际调用了什么工具、哪些结果来自旧记忆、哪些由当前输入提供。若没有这份轨迹，偶然完成一次演示，也无法分辨它是记住了约束，还是恰巧猜中了结果。先明白这些限制，再谈哪个版本可用，才不至于买到一个分数、却买不到需要的工作流。

## 同一个“max”按钮，不能把 Wonder 变成 Full

开发者打开模型列表，会看到明确的两个变体。普通 Muse Wonder 的 API 型号是 `muse-wonder-1.0`，可经 Meta Model API 按量付费，也可在 Muse Code 中按量或通过各档订阅使用；Full 在 Model API 上标为 **Not available**，只能在 Muse Code 的 **Power Usage** 与 **Maximum Usage** 套餐中使用（[Models — Muse Wonder availability](https://dev.meta.ai/docs/models)）。开发者发布公告也把 Full 写为 Muse Code 订阅专属（[Put your ideas to work with Muse Wonder and Muse Wonder Full](https://dev.meta.ai/resources/blog/build-with-muse-wonder)）。研究公告概括的“面向 Muse Code 订阅用户”，要以这张更具体的可用矩阵为准，不能推成每个订阅档都包括 Full。

普通版接受从 `minimal` 到 `max` 的 reasoning effort，且目前标为 preview。但文档有一句比规格更关键的话：把普通 Wonder 的 reasoning effort 设为 `max`，**不会选择 Wonder Full**（[Models — Muse Wonder](https://dev.meta.ai/docs/models)）。两个名字都能跟着 `(max)` 出现在基准图上，所指的却仍是两个不同产品入口。若有人看到基准文章中 “Wonder Full (max)” 的领先成绩，便在 API 上给 `muse-wonder-1.0` 设置 `max`，以为得到了 Full，这正是目录里的明确反例。

这里也有时间与地域限定：模型目录称普通 Wonder 处于预览阶段，并提示国家/地区可用性可能不同；[订阅 FAQ](https://dev.meta.ai/help/subscriptions/what-is-a-muse-code-subscription)说订阅实际权益与可用性可能依地区变化，签约前以 onboarding 展示为准。不要把「官方宣布今天可用」理解为任何地区、任何账号、任何第三方 API 路径现在都能用。本文没有替某个地区登录验证。

## 普通 API 是按 token 计费；Full 是受额度约束的 CLI 订阅

看价目时，先确定是哪一笔钱。普通 `muse-wonder-1.0` 在 API 的 Standard 模式下，每 100 万 token 普通输入 **4 美元**、命中缓存的输入 **0.20 美元**、输出 **20 美元**（[Pricing and rate limits — Muse Wonder](https://dev.meta.ai/docs/pricing-rate-limits)）。三项不是三个随意挑选的套餐。只有请求中有可复用的缓存前缀并实际命中时，对应 token 才按缓存输入价收费；官方建议用响应里的 `cached_tokens` 核对。没有命中，不能把整次输入预算都按 0.20 美元算。官方说长上下文没有额外的每 token 溢价，但窗口越长、使用的输入 token 越多，总额仍可能上升。

另一个容易被单价掩住的细节是工具与配额：API 的 web search grounding 在 token 费之外每 1000 次搜索查询收费 2.50 美元；普通 Wonder 的表列上限为每团队每分钟 3000 请求和 400 万 token（[Pricing and rate limits — Rate limits](https://dev.meta.ai/docs/pricing-rate-limits)）。这是限流表，不是保证每个团队都能持续跑到这一吞吐。多个 API key 属于同一团队也共享相应限额，不能靠拆 key 获得独立的团队预算。这里说的是普通版 API 的账单和限流，不是 Full 的套餐数字。

Full 的支付入口是 Muse Code。官方[订阅 FAQ](https://dev.meta.ai/help/subscriptions/what-is-a-muse-code-subscription)列出 Everyday 每月 5 美元、High 15 美元、Power 50 美元、Maximum 200 美元；而 Full 只在后两档开放。Power 的用量是 Everyday 基准的 20 倍，Maximum 是 80 倍；这不是 20 倍或 80 倍的智力，也不是无上限调用。开发者公告说明 Maximum 与既有套餐一样存在五小时和每周刷新窗口。达到额度后可升级或等待刷新；已经在 Maximum 档则只能等（[What is a Muse Code subscription?](https://dev.meta.ai/help/subscriptions/what-is-a-muse-code-subscription)）。数字描述套餐额度，不构成“每月花 200 美元可以得到多少百万 Full tokens”的换算式。

最关键的凭证边界藏在 FAQ：订阅关联 Muse Code CLI onboarding 自动连接的专用 key，只能用于 Muse Code；通过同一个 Model API 账户另建的 API key，仍按 pay-as-you-go 收费。换句话说，如果你想把模型接到自己的服务里，不能先买 Full 订阅，再把这张 CLI 月票当通用 API 凭证。**Full 没有公开的普通 API 每百万 token 价表**，Artificial Analysis 也因此不给它计算按 token 定价的单任务成本。拿普通 Wonder 的 4/0.20/20 去乘一个假想 Full 用量，得到的只是一张写错对象的账单。

## 需要个人历史的助手，先选清楚数据怎样被使用

Active Memory 的吸引力，恰好让数据边界变得更重要。跑步旧伤、日程、团队代码与长期任务目标，不是同一种风险，但都有一个共同前提：你必须愿意把相关内容交给这个服务处理。Meta 的[模型目录](https://dev.meta.ai/docs/models)和[价目说明](https://dev.meta.ai/docs/pricing-rate-limits)写明，普通 Wonder 的 Model API 只提供 Standard 模式；在该模式中，发送的提示词、代码、文件、上下文和得到的回复不用于训练 Meta 模型。不能从“默认不训练”推导为“不处理、不存储、零保留”，文档这句话回答的是训练用途，而非所有数据生命周期问题。

Muse Code 订阅的默认设置却是 **Contributor mode**：换取更多用量，允许 Meta 将提交内容与模型回复用于训练未来模型（[订阅 FAQ](https://dev.meta.ai/help/subscriptions/what-is-a-muse-code-subscription)；[Contributor mode 说明](https://dev.meta.ai/help/subscriptions/muse-code-contributor-mode)）。可以在 Muse Code 的 `/settings` 关闭；官方的准确时态是关闭后**未来**内容不再用于训练，不能把它转述为先前上传内容自动撤回。关闭改变套餐能使用的量，不改变所订档位，也不自动开放一个新 API。具有 Zero Data Retention（ZDR）的账户不能使用 Contributor mode。

这一点不能按普通 API 的逻辑倒推。API 里某些其他型号用带 `-contributor` 的模型 ID 选择 Contributor；普通 Wonder API 没有这种变体。Muse Code 订阅则用一项模式设置控制，默认开启。官方帮助中心还直说，不应向 Discounted Services 提交敏感、机密或个人信息，涉及个人信息应使用 Standard Services（[What is Contributor mode in Muse Code?](https://dev.meta.ai/help/subscriptions/muse-code-contributor-mode)）。具体账户条款和适用地区仍须自行核对；但至少在决定把个人长期历史交给代理前，先检查开关和额度变化，比等账单或授权争议发生后才读说明更稳妥。

## 第三方的 52 和 56 分，回答不了你那条具体任务

独立测评给了厂商演示之外的一组坐标。[Artificial Analysis 的 10 月 12 日评测](https://artificialanalysis.ai/articles/muse-wonder)在 Intelligence Index **v4.3**、各自 **max reasoning effort** 条件下，给普通 Wonder **52**、Wonder Full **56**，此前 Spark 1.3 **48**。差距是这一套指数的结果，不是 52% 或 56% 的真实工作任务完成率，也不能据此说 Full 对每项工作都比普通版强四个点。评测还给 Coding Agents Index 普通版 63、Full 68、Spark 54；两个 Index 测的内容不同，不能把编码指数的 68 拿去覆盖通用指数的 56。

AA 报道细分了分数从哪里来：Full 在十项指数子测评中的六项进入前三，Terminal-Bench 4.0 从 Spark 1.3 的 33% 到 Full 的 57%，普通 Wonder 为 52%。这些结果提示长流程和代理型任务值得试，却不能推断任何一个用户的私人长期记忆都会准确，也没有测你自己的批准流程是否可靠。AA 同时指出知识仍是相对弱项：在 AA-Omniscience 中，Full 为 30、普通 Wonder 为 25，普通版与 Spark 1.3 的 25 持平。关注一次任务有无幻觉、会不会编造过期记忆的人，不能只看总分上升的那一面。

厂商原图中的 MemoryBench 与 AA 的 Intelligence Index 更不能相互代指：前者由 Meta 作为内部长期交互上下文测试展示，后者由独立评测方给出的综合指数。即使研究页转载 AA 总览图，该图也不是我们亲测；图从哪一页取、分数是谁测的，是两件事。我们没有复跑这两项测试，更没有对长期记忆或安全报告做独立评估。Meta 公告说完整的附加安全评估报告随后发布；截至本次引用的发布说明，这项材料仍不应被当成已经在本文审过的证据（[Muse Wonder — Safety at the Frontier](https://research.meta.ai/blog/muse-wonder)）。

AA 还计算了普通 Wonder(max) 在其指数任务上的平均成本 **每项 4.52 美元**，Spark 1.3(max) 是 **1.60 美元**，前者约为后者的 2.8 倍；其统计的普通 Wonder 平均输入量为每项 **769 万 tokens**（[Artificial Analysis — Cost per Task](https://artificialanalysis.ai/articles/muse-wonder)）。这证明同一个评测任务的总代价不能仅看输出 token 或价目表第一行，并不证明你的下一个任务也要花 4.52 美元。用不同提示词长度、缓存命中率、工具次数，账单会变。Full 没有可比较的 token 单价，AA 也没有给它这项同口径美元成本；拿普通版的数字替 Full 填空，会让选型看似精确，实则错配。

![Artificial Analysis Intelligence Index 总览中普通 Wonder 为52分、Full为56分](/blog/images/muse-wonder-aa-index.png "独立测评方的指数，由 Meta 发布页转载；52与56不是任务成功率。来源：[Meta 发布页原图](https://research.meta.ai/blog/muse-wonder) · [Artificial Analysis 测评](https://artificialanalysis.ai/articles/muse-wonder)")

## 最后该选的不是冠军，而是可验证的任务边界

如果你需要把模型嵌入自己的应用、按 API key 调用、让系统按团队限流和 token 账单运行，那么可检查的入口是普通 Wonder API。先确认历史由应用还是产品层保存、如何传回模型，再用自己的任务测旧条件利用、失败恢复与权限确认，核对实际缓存命中和成本；不能假定普通 API 自带跨会话存储。如果工作主要在 Muse Code CLI 内，先在 `/settings` 核对 Contributor 模式，按数据性质决定是否关闭，并重新查看可用额度。涉及敏感、机密或个人信息时，不要在不符合条款的模式下提交。完成这些检查，再比较 Full 的任务收益是否值得 Power 或 Maximum 的月费。两种路径都要看地域可用与预览状态，不能让第三方榜单代替产品条款。

更难的题仍是开头那两项工作：旧条件在新任务里是否恰好被取回，代理受阻后是否找到了可复核的解法，重要动作之前是否真的停下来等你。Meta 已把这三件事摆到发布叙事的前排；厂商评估与 AA 测评给了值得关注的起点。至于它们在你的数据、你的权限和你的长期任务上能否成立，只有针对实际工作流的验证能回答。榜单负责提出候选，不负责替读者签订账单与授权。

---

## Sources

### research.meta.ai

- [Muse Wonder 研究公告](https://research.meta.ai/blog/muse-wonder)

### dev.meta.ai

- [发布说明](https://dev.meta.ai/resources/blog/build-with-muse-wonder)
- [模型目录](https://dev.meta.ai/docs/models)
- [订阅 FAQ](https://dev.meta.ai/help/subscriptions/what-is-a-muse-code-subscription)
- [Pricing and rate limits — Muse Wonder](https://dev.meta.ai/docs/pricing-rate-limits)
- [Contributor mode 说明](https://dev.meta.ai/help/subscriptions/muse-code-contributor-mode)

### artificialanalysis.ai

- [Artificial Analysis 的 10 月 12 日评测](https://artificialanalysis.ai/articles/muse-wonder)