Meta 用 Ember 把 Agent 成本打下来

Meta 在 11 月 9 日发布了 Muse Ember，一款专门面向 Agent 高频执行任务的轻量推理模型。

**Muse Ember 是 Meta 目前体积最小、推理成本最低的 Muse 系列模型，主要负责工具调用、任务路由、信息提取、代码子任务和长文档处理。**它的定位不是挑战最强前沿模型，而是把那些每天需要运行成千上万次、又不能频繁出错的 Agent 操作，压到足够低的成本。

Meta 给出的定价是每百万输入 Token 0.10 美元、缓存输入 0.004 美元、输出 0.50 美元。按 Artificial Analysis 的任务口径计算，Muse Ember 完成一次综合任务的成本约为 0.14 美元，只有 Claude Haiku 5.5 高推理配置的大约三分之一。(research.meta.ai)

这可能比单纯刷新一次跑分榜更重要。

过去一年，Agent 产品的瓶颈已经逐渐从“模型会不会做”，转向“能不能以可接受的成本重复做”。一个负责处理客服工单、审核合同或维护代码库的 Agent，不会每天只回答十个问题，而是可能连续读取文件、查询数据库、调用工具、检查结果，再根据错误重试数千次。模型每一步只贵几厘钱，乘上调用次数之后也会变成一笔不小的账单。

Muse Ember 瞄准的正是这部分账单。

它不是“小号聊天模型”，而是 Agent 的执行层

**Agent 执行模型是负责把计划拆成具体操作，并持续调用工具完成任务的模型。**它与普通聊天模型最大的区别，是评价标准不再只是回答是否聪明，而是能否稳定地读取环境、选择工具、完成操作、检查结果，并在失败后修正动作。

例如，一个代码 Agent 收到“修复登录模块的并发问题”后，真正产生消耗的不是最开始那次规划，而是后续几十甚至几百个步骤：

• 搜索相关文件和调用链；
• 阅读代码与测试用例；
• 修改几个局部函数；
• 运行测试并分析报错；
• 根据结果再次修改；
• 输出变更说明并提交结果。

如果每一步都调用旗舰模型，效果可能很好，但成本和延迟很难规模化。更合理的架构，是让强模型负责判断方向，让轻量模型承担大量可验证的执行工作。

Meta 对 Muse Ember 的描述非常直接：Muse Wonder 负责规划，Muse Ember 负责处理数量。换句话说，Wonder 更像项目经理，Ember 更像可以快速并行工作的执行团队。

这套分层架构并不新鲜，但 Muse Ember 的意义在于，Meta 正在把它做成一个明确的模型产品，而不是要求开发者自己拿通用小模型反复调提示词。官方称，Muse Ember 是首个使用 Muse Wonder Full 训练出的专用模型，说明 Ember 的能力很可能包含了一部分由更强模型生成、筛选和纠正的推理轨迹。(research.meta.ai)

跑分与 Haiku 同档，但优势集中在“把事做完”

**Artificial Analysis Index 是汇总模型推理、编程和任务执行表现的综合指标。**在最高推理配置下，Muse Ember 和 Claude Haiku 5.5 都得到 36 分，GPT-6 Luna 为 28 分。

只看综合分，Ember 与 Haiku 基本处于同一档。但拆开项目后可以看到，Ember 的强项并不是所有类型的编程，而是端到端业务工作流、工具使用和多步骤执行。

| 评测项目 | Muse Ember | Claude Haiku 5.5 | GPT-6 Luna | Ember 的表现 | |---|---:|---:|---:|---| | Artificial Analysis Index | 36 | 36 | 28 | 与 Haiku 持平，领先 Luna 8 分 | | AutomationBench-AA | 37.8 | 13.9 | 20.2 | 约为 Haiku 的 2.72 倍 | | Agents' Last Exam | 61.6 | 57.0 | 57.1 | 领先约 4.5 分 | | Personal Superintelligence Index | 46.8 | 36.1 | 37.0 | 领先 Haiku 10.7 分 | | Terminal-Bench 4.0 | 40.9 | 39.2 | 16.4 | 小幅领先 Haiku | | Coding Agent Index-AA | 46 | 37 | 31 | 领先 Haiku 9 分 | | FrontierCode 2.0-AA | 27.2 | 34.9 | 25.2 | 明显落后 Haiku | | OSWorld 2.1 | 69.5 | 68.9 | 50.5 | 与 Haiku 基本持平 | | PerceptionBench | 80.6 | 78.6 | 62.8 | 三者最高 |

这些数字揭示了 Muse Ember 很明确的取舍。

在 AutomationBench-AA 这类端到端业务流程测试中，Ember 得分 37.8，较 Haiku 的 13.9 高出 23.9 分，增幅约为 172%。这类测试通常不是让模型回答一道题，而是要求它跨多个应用查找信息、按顺序调用工具，并把处理结果写回业务系统。Ember 在这里取得明显领先，说明 Meta 优先优化的是 Agent 的完整任务成功率。

但在 FrontierCode 2.0-AA 上，Ember 只有 27.2，落后 Haiku 的 34.9。这项测试更强调真实工程代码能否达到可合并标准，而不只是能否运行几个命令。因此，Muse Ember 并不是更便宜的全能编程冠军；涉及复杂架构修改、深层代码推理或大型重构时，Haiku 或更强模型仍然可能更可靠。

这也是看待官方跑分时必须保留的判断：Muse Ember 擅长的是大量、局部、可检查的执行任务，而不是一次解决最困难的问题。

此外，Agents' Last Exam、Personal Superintelligence Index、OSWorld 2.1 和 PerceptionBench 中包含 Meta 内部评测或特定工具配置，不能简单等同于所有真实生产环境。开发者仍需要用自己的工具链、重试策略和业务数据测试实际成功率。(research.meta.ai)

真正的竞争力是每个任务花多少钱

**单任务成本是模型完成一组标准任务时，综合输入、输出、推理长度和失败重试后产生的实际费用。**它比单看每百万 Token 价格更接近 Agent 产品的真实成本。

在 Artificial Analysis 的最高推理配置中，Muse Ember 的综合得分约为 35.8，单任务成本约 0.136 美元；Claude Haiku 5.5 的得分约为 36.2，单任务成本约 0.411 美元。两者综合能力只差 0.4 分，但 Ember 的任务成本低了约 67%。(research.meta.ai)

| 指标 | Muse Ember | Claude Haiku 5.5 | GPT-6 Luna | |---|---:|---:|---:| | 最高配置综合得分 | 约 35.8 | 约 36.2 | 约 27.8 | | 对应单任务成本 | 约 0.136 美元 | 约 0.411 美元 | 约 0.152 美元 | | 相对定位 | 低成本高频执行 | 轻量高质量推理 | 较低成本通用执行 |

这里需要注意，单任务成本低并不完全等于 Token 单价低。模型如果更快找到正确工具、使用更短的输出完成操作，或者减少失败后的重试次数，即使标价接近，最终成本也可能拉开数倍。

早期合作方 You.com 称，Muse Ember 在其编码任务中的 p95 延迟为 2.2 秒，比测试的主流开放权重模型快约 4 至 13 倍，同时输出 Token 减少 36% 至 48%。Cloudflare 则表示，Ember 的尾部延迟最多降低约 30%。这些数据来自合作方的特定测试，不宜直接外推到所有场景，但至少说明 Meta 优化的不只是账面价格，也包括输出长度与高并发延迟。(research.meta.ai)

对于每天处理 100 万次任务的系统，即使每次只节省 0.1 美元，理论上每天也能减少 10 万美元成本。真实业务不会完全按照同一种基准任务运行，但规模效应正是 Ember 这类模型存在的理由。

100 万上下文很大，51.2 万输出更值得注意

**上下文窗口是模型一次推理能够接收和参考的最大 Token 数量。**Muse Ember 支持 100 万 Token 上下文，最大输出达到 51.2 万 Token。

100 万 Token 意味着模型理论上可以一次读入一个中大型代码库、一套合同文档，或者包含大量表格和附件的项目资料。更关键的是 51.2 万 Token 输出上限，它让 Ember 可以在一个持续会话中产生大量工具调用记录、补丁、测试结果和结构化数据，而不必频繁开启新会话。

但长上下文不代表模型能够无损记住所有细节。

对 Agent 来说，把整个仓库一次性塞进上下文通常不是最经济的做法。检索、文件索引和状态压缩仍然重要，否则模型会在大量无关信息上消耗 Token。100 万上下文更适合作为保险：当任务确实涉及跨目录依赖、长时间执行记录或多份关联文档时，Agent 不容易因为窗口不足而丢掉早期信息。

最大输出长度也是上限，不是建议值。让模型连续生成数十万 Token，不仅增加成本，也会放大错误累积。生产系统仍应在关键步骤设置检查点，把一次超长执行拆成可以验证、回滚和重试的阶段。

多模态能力让它可以直接看屏幕干活

**原生多模态模型是能够在同一个模型中理解文本、图像、音频和视频输入的模型。**Muse Ember 可以读取截图、图表、扫描文件、语音备忘录、会议录音和视频，不需要先把内容转交给另一个视觉或语音模型。

这一能力对 Agent 比对聊天产品更有价值。

很多企业软件没有稳定接口，或者页面中同时包含文字、图表、按钮和弹窗。Agent 如果只能读取网页文本，就很难判断图表变化、识别远程桌面状态，也无法处理扫描版合同。Ember 可以直接根据截图理解桌面环境，在 OSWorld 2.1 中得到 69.5 分，与 Haiku 的 68.9 接近，并明显领先 Luna 的 50.5。(ithome.com)

一个典型场景是财务对账：Agent 先读取邮件附件中的扫描发票，再打开企业系统查找对应订单，随后比较金额、日期和供应商信息，最后把异常记录写入表格。过去这套流程可能需要 OCR、视觉模型、语言模型和浏览器自动化工具相互传递结果；原生多模态模型可以减少中间环节，也减少格式转换带来的信息损失。

不过，能看懂屏幕不等于可以放心控制屏幕。Agent 依然可能点击错误按钮、被网页中的隐藏指令诱导，或者把普通文本误判为系统命令。Meta 表示 Ember 在发布前接受了生物安全、网络安全、失控风险以及提示注入抵抗测试，并低于其高风险阈值，但这些测试不能替代权限隔离、操作确认和审计日志。(research.meta.ai)

Meta 的算盘：把 Ember 塞进每一个产品

**模型分层是用不同成本和能力的模型分别承担规划、执行与校验任务的系统架构。**Muse Ember 补上了 Meta 模型组合中最靠近执行层的一块：Wonder 处理高难度规划，Spark 处理编程和复杂 Agent 工作流，Ember 处理可以大规模重复的子任务。

这套组合的商业逻辑非常清楚。Meta 不需要让 Ember 在所有测试中击败旗舰模型，只需要让它在 Facebook、Instagram、WhatsApp、智能眼镜和企业服务中运行时足够便宜。

一次用户请求背后，可能包含十几次模型调用：识别意图、查询记录、分析图片、生成参数、调用服务、检查结果、写回系统。模型成本如果降到足够低，Meta 就可以让 Agent 更主动地工作，例如持续监控价格、整理通知、筛选内容或检查任务状态，而不是等用户每次发出明确指令。

这也意味着，Muse Ember 最值得关注的地方并不是排行榜上的 36 分，而是它把“持续运行的 Agent”向经济可行推进了一步。

对开发者来说，Ember 更适合以下任务：

• 高频工具调用和结构化信息提取；
• 大量相似工单、合同或文档的批处理；
• 代码仓库中的文件读取、测试运行和局部修复；
• 桌面软件和网页界面的多步骤操作；
• 由更强模型规划、再交给子 Agent 并行执行的任务。

它不一定适合以下任务：

• 需要一次完成的大型架构设计；
• 缺乏验证标准的开放式复杂决策；
• 对事实错误几乎零容忍、又无法人工复核的高风险操作；
• 需要最强数学、科学或深层代码推理的任务。

Ember 的价值，不是更聪明，而是终于够便宜

Muse Ember 不是一款让人惊叹“模型又聪明了多少”的产品，它更像是 Agent 基础设施中的成本优化器。

综合得分与 Claude Haiku 5.5 持平、任务成本约为其三分之一，说明轻量模型的竞争已经从 Token 单价进入系统效率阶段。谁能用更短的推理、更少的输出和更低的重试率完成同一个任务，谁才真正适合部署到高频业务中。

但 Meta 的跑分也暴露了它的边界：Ember 在端到端自动化和工具调用上很强，在最困难的真实代码合并任务上仍然落后 Haiku。开发者不应该把它当作旗舰模型的低价替代品，而应该把它放在正确的位置——作为强模型下面的执行层。

如果 Muse Ember 能在真实生产环境中维持官方展示的成功率、延迟和 Token 效率，它会让更多团队重新计算 Agent 的成本模型。过去因为调用费用太高而只能每天运行一次的流程，未来可能变成每小时运行一次；过去需要人工抽查的重复任务，也可能被拆给数百个低成本子 Agent 并行处理。

Agent 时代真正昂贵的从来不是回答一个问题，而是把一件事反复、稳定地做完。Muse Ember 的核心卖点，就是试图把后者变成一种廉价能力。

参考来源

• IT之家：Meta 推出轻量级 AI 模型 Muse Ember — 汇总 Muse Ember 的发布时间、价格、上下文窗口、多模态能力与主要基准测试结果。