Meta新模型瞄准低成本高并发Agent任务

Meta 新发布的 Muse Ember，瞄准的是 Agent 里反复执行的工具调用、路由、信息提取和编码子任务。原文给出的结论是：它在综合能力上接近 Claude Haiku 5.5，但完成评测任务的平均成本约为后者三分之一。

对前端和全栈开发者，更有用的信号是模型分工：复杂问题交给大模型规划，大批重复步骤交给小模型执行。不过，Ember 的工作流成绩和真实仓库编码成绩并不一致，不能只看一个综合分数就决定替换。

便宜的原因，是完成任务用的 token 更少

Muse Ember 于 2026 年 11 月 9 日发布，是 Muse 系列继 Spark、Glimmer、Wonder 之后的第四个模型。Meta 将它定位为体量最小、效率最高的一款，但没有公开参数量。

它也是 Meta 首个使用 Muse Wonder Full 训练的模型。原文没有交代具体训练方法，不能据此推断蒸馏流程或能力继承程度。产品分工倒很明确：Muse Wonder 负责难题和规划，Muse Spark 面向编码与 Agent 工作流，Ember 承担规模化的重复任务。

价格是这次发布最容易看错的地方。Ember 每百万输入 token 收费 $0.10，输出收费 $0.50，与 Claude Haiku 5.5、GPT-6 Luna 的基础单价相同。

它的成本优势，来自评测中完成任务的 token 用量，而非更低的基础单价。

Meta 图表里，Ember 在最高推理强度下得分 35.8，每项任务花费 $0.136；Haiku 5.5 得分 36.2，花费 $0.411。Luna 的最佳设置得分 27.8，花费 $0.152。文章把综合分数取整后写成 36、36、28，因此「能力持平」是接近的意思，并非每项能力相同。

长输入还有额外差别：Haiku 的提示词超过 100K token 后，输入和输出单价分别升至 $0.50、$2.50；Luna 输入超过 272K token 后，输入单价翻倍。原文列出的 Ember 价格没有长上下文分档，缓存输入每百万 token 为 $0.004，另外两款均为 $0.01。

这些价格能帮助估算账单，但评测里的「每项任务成本」不能直接当成业务里的「每次成功成本」。

工作流领先，不代表更会改真实仓库

文章最有说服力的成绩来自 AutomationBench-AA。它包含 657 个 Zapier 业务工作流，Ember 完成率为 37.8%，Luna 为 20.2%，Haiku 为 13.9%。Meta 内部的 Agents’ Last Exam 中，三者分别为 61.6、57.1、57.0。

编码评测却出现了分叉：

评测	Muse Ember	Claude Haiku 5.5	GPT-6 Luna
Terminal-Bench 4.0	40.9	39.2	16.4
AA Coding Agent Index	46	37	31
FrontierCode 2.0-AA	27.2	34.9	25.2

Ember 在终端任务和编码 Agent 综合指标上领先，但在原文用于衡量可合并真实仓库代码的 FrontierCode 2.0-AA 上，落后于 Haiku。

对开发者而言，这个区别很实际。能顺利调用工具、完成终端步骤，不等于能提交符合项目约束、可以合并的修改。用 Ember 做执行层有数据支持；让它接管完整需求开发，原文证据还不够。

上述成绩均按 Meta 报告的最高推理强度展示，来源混合了 Artificial Analysis 和 Meta 内部测试。表格注明参考 Artificial Analysis Intelligence Index v5，因此阅读时还要区分第三方指标与内部评测。

1M 上下文有用，但容量不等于理解可靠

Ember 支持 1M token 上下文，最多输出 512K token，是 Haiku 和 Luna 各自 128K 输出上限的 4 倍。不过，1M 上下文本身并非独有：Haiku 同样支持 1M，Luna 为 1.05M。

原文称它能在一次调用里容纳完整代码库或文档集。这里需要补上条件：材料首先得装得进去。文章也没有给出接近容量上限时的检索准确率、跨文件推理效果或延迟数据。能接收长输入，与能稳定找到关键约束，是两项能力。

输入模态是另一处差异。Ember 原生接受文本、图片、音频和视频，可以处理截图、扫描件、语音备忘和会议录制，并能依据截图操作桌面应用。原文对比的另外两款仅列出文本和图片输入。

相关评测中，Ember 与 Luna 在 GDP.pdf-AA 上同为 22.8；支持工具的 PerceptionBench 得分分别为 Ember 80.6、Haiku 78.6、Luna 62.8。OSWorld 2.1 的部分得分为 69.5、68.9、50.5，二元判定得分则为 33.8、27.8、17.0。

接入方式也有明确边界：只能通过 Meta Model API 或 Muse Code 使用，支持 Responses API，权重不公开，没有本地 GPU、笔记本或量化部署选项。Box、Cline、Oracle、Cloudflare、You.com 参与了早期测试，但文章没有提供这些合作方的生产效果数据。

我的判断

我认可它按任务分配模型的方向。对重复调用量大的 Agent，综合能力略有差异，可能没有单次任务消耗和成功率的差异重要。Ember 的工作流评测，足以支持把它放进候选名单。

但「同等能力、三分之一成本」应当限定在对应评测配置里。原文没有提供国内访问条件、实际延迟、限流、业务重试和人工返工成本，也没有展示普通团队的生产对照实验。把评测结果直接扩展成普遍收益，目前缺少依据。

与继续统一使用 Haiku 相比，Ember 提供了降低重复执行成本的可能；Haiku 则在文章列出的真实仓库编码指标上更强。与本地模型相比，Ember 提供的是托管服务，无法满足必须私有部署的需求。选择依据应当是任务和部署条件，而非模型大小或上下文长度。

能拿来做什么

• 给现有 Agent 拆出工具调用、路由、信息提取和编码子任务，分别评估是否适合交给 Ember，复杂规划继续保留独立的模型选择。
• 在 Node 服务的模型调用层记录输入、输出、缓存命中、重试次数和任务成功率，再比较每次成功的总成本，验证 $0.136 的评测优势能否迁移到自己的任务。
• 为 AI 编程准备两类验收样本：一类检查终端操作和工具执行，一类检查仓库修改能否通过项目检查并达到合并要求，避免用前一类成绩代替后一类。
• 处理代码库或长文档前先统计 token，并单独测试接近 1M 上限时的准确率和延迟，再决定一次传入全部材料，还是继续分段处理。