Muse Wonder 详解：API 价格、Full 订阅与上手方法

Muse Wonder 是什么，适合做什么？

Meta Superintelligence Labs 于 2026 年 10 月 12 日发布了 Muse Wonder 和 Muse Wonder Full。面对需要长时间执行、反复规划、调用工具并从失败中恢复的任务，这次发布提供了能力更强的模型选择。智能体是围绕模型构建的软件，让模型能够执行这些操作，而不只是给出一段聊天回复。Meta 的发布公告明确了发布日期和这两个版本。

实际用起来，你的工作流里多了一个模型选项。开发者可以用跨多个软件包的重构来评估 Wonder；业务人员可以用需要查阅大量文档、调用多种工具才能得出答案的调查任务来评估它。至于已经稳定运行、成本低廉的分类模型，没必要因为新模型上线就替换。

Meta 在开发者发布说明中介绍了规划、并行调用工具和错误恢复能力。但这些能力有没有价值，要看最终产出能否通过你的验收。运行得再久，做错了任务，仍然只会增加审核工作。

Muse Wonder 和 Wonder Full 有什么区别？先看使用权限

Wonder 可以通过 API 调用；Wonder Full 能力更强，但仅向符合条件的 Muse Code 订阅用户开放。Meta 的模型页面列出的两个版本都支持 1M 上下文。上下文指模型一次能够综合处理的材料量，以 token 计量；token 是文本及其他编码输入的较小单位。

上述权限限制来自 Meta 的模型可用性文档。该文档明确指出，把 Wonder 的推理强度设为 max，不会切换到 Wonder Full。推理强度决定当前模型投入多少思考，不会改变你获准使用的模型。

Wonder Full 多少钱？

Meta 在 Wonder 模型页面列出的 Muse Code Power Usage 价格为 $50.00/月，Maximum Usage 为 $200.00/月，两者均包含 Full。这是 Muse Code 的订阅价格，与独立的 Muse 应用不同。

如果 Power Usage 包含的用量足够，可以用它来评估 Full。只有需要更高额度时，才有必要考虑 Maximum Usage；使用 Full 并不要求购买最贵的套餐。Meta 标注的两档额度分别是 Everyday Usage 的 20x 和 80x，均不代表无限使用。

订阅也不等于可以抵扣任意 API 调用的费用。订阅文档说明，订阅凭证仅限 Muse Code 使用，额外创建的 API 密钥单独计费。权益和可用性可能因地区而异。

Muse 应用现在能用 Wonder 吗？

Meta 发布时的说法是**“即将上线”，并优先向订阅用户开放**。这一表述没有给出明确日期，也没有确认 Muse 应用用户是否能使用 Wonder Full。目前有明确文档支持的使用路径是 API 和 Muse Code；按照 Meta 的公告，应用内的上线仍有待落实。

Muse Wonder API 价格：完成一项任务要花多少钱？

**预算应按任务实际消耗的 token 计算，重复调用也要算进去。**1M 上下文窗口代表容量，不代表一次请求只收固定费用，也不是每月用量额度。

以下美元价格已于 2026 年 10 月 13 日对照 Meta 当时在线的模型和定价页面核实，均为 Standard 模式下每百万 token 的费率：

缓存输入是可重复使用、且符合低价计费条件的提示词内容。Meta 的定价文档说明，长上下文不加价。网页搜索则在 token 费用之外，按每 1,000 次查询 $2.50 单独收费。Wonder 的 API 仅支持 Standard 模式，没有 Contributor 模式的 API 折扣。

算一笔开发和业务任务的账

假设一项任务在多次调用中合计消耗 200,000 个未缓存输入 token 和 20,000 个计费输出 token。这只是用于估算的工作量，并非实测结果。先不计搜索等非 token 费用，并假设两个模型的用量相同：

• **Spark 1.2：**每项任务 (0.2 × $1.25) + (0.02 × $4.25) = $0.335。
• **Wonder：**每项任务 (0.2 × $4.00) + (0.02 × $20.00) = $1.20。
• **差额：**每项任务多花 $0.865，token 费用约为原来的 3.58 倍。

执行 1,000 项任务，就是 Spark 花 $335，Wonder 花 $1,200，相差 $865。如果创业者只把最难的 10% 交给 Wonder，其余 90% 留在 Spark，同样的示例工作量合计花费 $421.50。这个分流示例假设任务可以按难度区分，并不说明任一模型一定能成功完成任务。

不同模型的实际 token 消耗可能不同。可以先用相同用量的计算来规划试用，再用自己任务的实际计费用量和审核时间替换假设。

哪些任务应该继续用 Muse Spark 1.2？

**如果 Wonder 在某项任务上还没有证明优势，就保留已经验证有效的 Spark 工作流。**Muse Spark 1.2 本身已有 1M 上下文，其模型页面也将编程和工具调用列为应用方向。因此，大上下文窗口本身不足以成为升级理由。

对负责请求分类、字段提取或日常摘要的资深业务人员来说，关键是结果能否达到验收要求。对独立开发者来说，修复一个范围明确的 bug，关键是补丁和测试是否正确。如果 Spark 已经达标，就需要具体理由来支撑 Wonder 更高的费用。

版本选择还有一点需要分清：Meta 目前建议新的 Spark 项目使用 Muse Spark 1.3，同时仍提供 1.2。模型文档也提示，1.3 的音频支持尚不完整，音频用户应使用 1.2。继续选择 Spark 系列，和有意保留经过验证的 1.2 部署，是两个不同的决定。

谁该试用，谁该等待，谁该保留现有模型？

开发者可以试用 Wonder，尤其是任务经常卡在跨文件修改、工具协作或中途失败这些环节时。试用时固定任务范围和验收标准，才能判断换模型是否有帮助。只有更难的编程任务足以支撑订阅成本时，再到 Muse Code 中评估 Full。

业务人员应把低成本任务留给 Spark，再选一项边界清晰的疑难任务试用 Wonder。例如，需要核对多份文档、形成有证据支撑的答案的复杂案例。验收时，对它的证据要求应与对执行这项工作的人相同。

**采购人员和 CTO 应把部署决策与模型排名分开看。**需要 API 集成的产品，目前无法通过 API 使用 Full。如果你专门在等 Muse 应用里的 Wonder，应等待该应用确认开放，而不是买错产品、订阅 Muse Code。

Active Memory 和 Active Focus：Meta 声称它们能做什么？

**Meta 承诺的是记起相关信息、持续推进任务，而不只是容纳更长的提示词。**这个区别很关键：记不住指令，与记住了却没能执行到底，是两类不同的问题。

按照 Meta 的描述，Active Memory 能在对话之间保留有用的上下文，并检索与当前任务相关的信息；Active Focus 则能持续推进困难目标、尝试其他方案、处理阻碍，并在重要操作前寻求澄清或核查。这些是 Meta 对模型行为的表述，并非本文经过独立验证后给出的保证。

业务人员可以这样测试记忆：审核新订单时，智能体能否找回此前提供的交付限制？测试专注能力，则看它能否在查询失败后恢复推进，同时仍遵守这项限制。前者检验能否记起，后者检验能否执行到底。最后写出一段漂亮的总结，不能证明任何一项。

自行集成时，需要明确历史信息存在哪里、如何传给模型。不要以为更换 API 模型 ID，就会自动获得持久记忆系统。例如，Muse Code 文档介绍了按不同作用范围划分的 Markdown 记忆，说明模型之外的产品机制同样发挥作用。

Muse Wonder 怎么用？从 Muse Code 或 API 开始

**处理代码仓库任务可以使用 Muse Code，集成到自己控制的应用则使用 API。**首次试用应聚焦一个问题，并产出可供检查的结果。

从 Muse Code 开始

Muse Code 是 Meta 的终端编程智能体。在 macOS 或 Linux 上，按照官方快速入门文档运行：

curl -fsSL https://dev.meta.ai/install.sh | sh
muse

请在要处理的仓库目录中启动它。首次启动时，通过浏览器登录或使用 API 密钥。打开 /models 并选择 Wonder；只有订阅包含 Full 时，才选择 Full。

给它一个范围明确的目标，例如：“查明分页测试失败的原因，提出最小修复方案，并展示相关测试的结果。”接受改动前，检查代码差异和验证证据。我们的 Muse Code 使用指南介绍了更完整的安装、规划和审核流程。

直接发送 API 请求

在 Meta Model API 控制台中，依次选择 API 密钥 → 创建 API 密钥，然后在 shell 中将密钥设为 MODEL_API_KEY。设置好变量后，下面的示例以 Meta 文档中的 Responses 请求为基础，将模型 ID 换成 Wonder：

curl -sS https://api.meta.ai/v1/responses \
  -H "Authorization: Bearer $MODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-wonder-1.0",
    "input": "Plan a contained fix for a pagination bug. List the evidence needed to verify it."
  }'

这次请求会返回方案，不会修改仓库，因为请求没有提供仓库或工具。Meta 表示，Wonder 和 Spark 在相同端点接受相同的请求，因此，已有的 Spark 集成可以作为评估 Wonder 的起点。

哪些期待被夸大了？有使用权限，不等于能自主完成任务

**影响最大的错误，是带着错误预期购买使用权限。**购买前应分清以下几点：

• **Full 是独立版本。**推理强度设为 max 的 Wonder 仍是 Wonder。$4/$20 的 API 费率不包含 Full。
• **1M 上下文不保证记得住。**容量大，不代表模型一定找到了相关事实，也不代表它会在整个任务中始终依据这些事实行事。
• **订阅不等于无限 API 额度。**Muse Code 和单独创建的 API 密钥分别计费。
• **本次发布采用托管服务形式。**本文引用的发布说明和使用文档未提供可下载、用于自行部署的 Wonder 权重。

还有一项需要实际设置的选项：Muse Code 订阅默认启用 Contributor 模式，允许 Meta 将用户提供的内容用于模型训练，以换取更多使用额度。如果不适合你的工作，应在设置中关闭。对于 Wonder API 的 Standard 模式，Meta 表示不会将内容用于训练其模型。请核对你实际使用的产品和模式。

如果要比较不同模型，可以阅读 Muse Wonder 与 Claude Opus 5.5 对比。想了解更早的 Spark 版本，可参考 Muse Spark 1.1 评测；它提供的是历史背景，当前预算应使用上文列出的费率。

常见问题

下一步：用自己的任务验证是否值得换

从现有工作流中选出 10 项范围明确的任务，保持输入和验收标准相同，对比当前的 Spark 配置与 Wonder，记录通过验收的结果、计费总用量和人工审核时间。Spark 已经能做好什么，就继续让它做；只有实测改善足以抵消额外费用时，才采用 Wonder。只有工作本身适合在 Muse Code 中完成，才单独评估 Full。

想获取 AI 模型选择和使用成本方面的实用指南，可以订阅邮件简报。