Meta 发布低价长上下文模型 Muse Ember
Meta 推出面向推理与智能体任务的 Muse Ember，支持百万 Token 上下文及文本、图像、音频和视频输入，每百万输入、输出 Token 分别收费 0.10、0.50 美元。公布的评测显示其综合表现接近 Claude Haiku 5.5，但真实工程代码合并评测成绩低于后者。
AI 深度解读
Meta 推出 Muse Ember，瞄准的是智能体里反复发生的工作：读文件、跑测试、修代码，以及处理文档和屏幕信息。它主打的组合是接近 Claude Haiku 5.5 的表现、更低的任务成本，以及足够长的上下文。
对程序员来说，值得关注的是它能否降低日常 AI 编程的开销。不过，原文给出的主要是 Meta 的宣传口径和能力描述，缺少完整跑分与成本计算过程。选型时，可以把它列为候选，暂时还不能据此认定它更划算。
「单任务成本仅为 1/3」能说明什么
据原文转述，Meta 表示，Muse Ember 在 Artificial Analysis 排行榜中的表现可以媲美 Claude Haiku 5.5，单任务成本仅为其 1/3，并在多项测试中超过 GPT-6 Luna。原文列出的对比对象还标有 Claude Haiku 5.5（max）。
这里有两个不同的问题：模型调用便不便宜，以及完成一项工作划不划算。
Muse Ember 的输入价格为每百万 Token 0.10 美元，输出价格为每百万 Token 0.50 美元。原文按其采用的汇率折算，分别约为人民币 0.67 元和 3.3 元。这是 Token 单价；任务成本还取决于输入长度、输出长度、调用轮数，以及失败后需要重试多少次。
便宜的 Token 单价，不足以证明完成任务的成本一定更低。
原文列出了 AutomationBench-AA、Agents' Last Exam、Personal Superintelligence Index、Terminal-Bench 4.0、Coding Agent Index-AA、FrontierCode 2.0-AA、OSWorld 2.1、PerceptionBench 和 Artificial Analysis Index，覆盖业务工作流、智能体任务、编程、桌面操作和视觉感知。
但提供的正文没有对应分数，也没有说明「多项测试」具体是哪几项。「成本仅为 1/3」如何计算，同样没有展开。它提供了一个值得验证的方向，还没有提供足够完整的比较依据。
长上下文能装下代码库，但不保证修得对
Muse Ember 拥有 100 万 Token 上下文窗口，最多支持输出 51.2 万 Token。原文称，它可以在一次调用中处理完整代码库或整套文档，并让智能体在一次会话中执行数百次编程子任务，包括读取文件、运行测试和针对性修复。
这对跨文件任务有吸引力。例如，修改接口类型后，还需要同步调整调用方和测试。模型能看到更多相关材料，智能体就有机会少做一些上下文搬运工作。
但「完整代码库」有容量前提，代码、文档和会话内容仍需落在窗口限制内。上下文装得下，也不代表模型能准确找出所有依赖关系。
还要分清模型与智能体：运行测试、读取本地文件，需要外部工具和执行环境。原文描述了智能体能够完成的流程，没有给出工具配置、任务成功率或长会话的稳定性数据。51.2 万 Token 的输出上限，也不能直接换算成代码质量。
多模态把更多输入接进同一条工作流
Muse Ember 原生支持文本、图像、音频和视频理解。按照原文描述，智能体无需额外调用其他模型，就能读取截图、图表和扫描文档，也能处理语音备忘录、会议录音及视频。
对前端开发而言，最直接的关联是截图与界面操作：需求可能来自页面截图，问题可能出现在跨桌面应用的操作过程中。模型能理解这些输入，有助于把视觉信息接入任务流程。
不过，支持某种输入格式，与能否稳定处理复杂材料，是两件事。原文没有交代音视频长度限制、细节识别准确率，也没有提供截图操作的完整案例。
安全方面，Meta 表示，Muse Ember 发布前经过 Meta SI 扩展框架评估，所有测试结果均低于框架设定的高风险阈值。这是框架内的评估结论，原文没有展开测试范围。
原文称，该模型自报道发布当日起，通过 Meta Model API、Google Cloud 和 Oracle Cloud 提供。
我的判断
我认为，它最值得关注的是低价模型能否承担更多重复任务。如果编程和工具调用能力足够稳定，日常读取材料、修改代码、验证结果的成本确实可能下降。
但原文没有提供作者或团队的实测，也没有给出可复核的对照数据。接近 Claude Haiku 5.5、超过 GPT-6 Luna、单任务成本降至 1/3，目前都应按 Meta 的主张理解。
与把整套代码库直接塞进上下文相比，先检索相关文件、逐步补充材料仍然有比较价值。长上下文提供了容量，团队还需要验证多放进去的材料是否有帮助，以及是否增加调用开销。模型选型应看任务完成质量，不能只看窗口大小和单价。
能拿来做什么
- 如果准备接入 Meta Model API，可以挑选现有的修复任务做小规模对照，统一需求和验收条件，记录完成率、重试次数及实际费用，验证「单任务成本」。
- 对跨文件的前端或 Node 修改，可以比较整套相关材料一次输入与按需读取两种方式，观察测试结果和上下文开销，再决定是否使用长窗口。
- 如果工作流包含截图、扫描文档或会议录音，可以先验证这些真实输入的识别质量，再考虑合并原有的多模型处理步骤。