Meta 最新的 AI 模型 Muse Spark 1.3，把上下文窗口扩展到 100 万 token，并将产品重点放在长周期、多步骤的 agentic workflow 上。它可以处理视频、图片和文档等多模态输入，工具调用的一阶成功率也比前代更高，代码能力在多个评测中被描述为与前沿模型持平。
真正值得工程团队拆解的，除了模型能力，还有它的定价方式：同一个模型分成两档，价格差距最高达到 21 倍。这个设计说明，百万级上下文并不只是“把窗口做大”，而是把调用频率、数据使用条件和成本控制放到了同一张商业设计图上。
100 万 token 解决的是什么问题
长上下文的价值不在于一次性塞入更多文字，而在于减少长期任务中的状态丢失。传统 agent 往往需要把历史对话、任务计划、工具结果和中间产物压缩成摘要，再在下一轮重新加载。摘要会节省 token，却也可能丢掉代码细节、异常日志、文档约束和视觉线索。
百万级上下文可以覆盖更长的工作周期，例如：
- 分析一组长视频，并结合字幕、截图和会议文档生成结论。
- 阅读大型代码仓库、Issue、变更记录和测试日志后完成修改建议。
- 让 agent 连续调用搜索、数据库、文件系统和执行环境，保留完整的工具轨迹。
- 在复杂研究任务中同时维护原始材料、阶段性结论和待验证假设。
不过，长上下文不等于无限记忆。上下文越长，输入成本、检索噪声和模型注意力分散风险也越高。实际系统仍然需要分层存储：当前任务放进上下文，稳定事实放入知识库，原始文件保留在对象存储中。
两档定价：便宜的不一定是“同一件事”
Muse Spark 1.3 的定价分成两档，差价超过 10 倍，报道标题给出的最大差距达到 21 倍。标题中的“用数据换折扣”揭示了这类价格设计的核心：低价档通常需要接受更严格的数据使用或产品条件，企业购买的并不只是 token，而是一组模型能力、数据条款和服务承诺。
工程团队评估这类模型时，不能只比较“每百万 token 多少钱”，还要把下面几项放进总成本：
- 输入与输出 token 成本：百万上下文会显著放大输入侧费用，尤其是重复发送历史内容时。
- 数据使用边界：要确认请求内容是否可用于改进服务、是否支持退出，以及日志保存和隔离策略。
- 延迟与并发：长上下文通常意味着更高的处理延迟。低价档如果有吞吐限制，可能不适合交互式 agent。
- 工具调用失败成本：一次失败的工具调用可能触发重试、重新上传上下文和额外输出，实际费用高于账面单价。
- 迁移成本：如果业务严重依赖某个模型的上下文格式、多模态协议或工具调用约定，切换模型会产生额外开发成本。
因此，21 倍价差不代表高价档一定适合所有请求。可以把低价档用于离线批处理、数据清洗和候选答案生成，把高价档留给高价值的长任务、关键代码修改和需要稳定工具调用的流程。真正可行的策略是按任务风险路由，而不是全量固定使用一个档位。
一个可落地的长上下文调用骨架
下面的 Python 示例采用常见的 OpenAI 兼容接口风格。Muse Spark 1.3 的具体 endpoint、模型名、鉴权方式和多模态字段需要以实际服务文档为准；示例中的环境变量和请求结构可以作为接入适配层的起点。
运行前设置 MUSE_API_BASE、MUSE_API_KEY 和 MUSE_MODEL。代码会读取一个文档文件，带上任务要求后发起请求，并打印模型返回结果。
import json
import os
from pathlib import Path
from urllib.request import Request, urlopen
API_BASE = os.environ.get("MUSE_API_BASE", "https://api.example.com/v1")
API_KEY = os.environ["MUSE_API_KEY"]
MODEL = os.environ.get("MUSE_MODEL", "muse-spark-1.3")
def call_model(document: str) -> str:
payload = {
"model": MODEL,
"messages": [
{
"role": "system",
"content": "你是一个严谨的长文档分析 agent。引用事实时保留证据位置。"
},
{
"role": "user",
"content": (
"请分析下面的项目文档，输出：问题摘要、风险清单、可执行计划。\n\n"
+ document
)
}
],
"max_tokens": 4000,
"temperature": 0.2
}
request = Request(
f"{API_BASE.rstrip('/')}/chat/completions",
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
},
method="POST"
)
with urlopen(request, timeout=180) as response:
result = json.loads(response.read().decode("utf-8"))
return result["choices"][0]["message"]["content"]
if __name__ == "__main__":
text = Path("project.md").read_text(encoding="utf-8")
print(call_model(text))
生产环境中建议在这个适配层外再加三层控制：
- 上下文预算器：统计当前请求的 token 数量，接近上限时优先压缩低价值历史记录。
- 任务路由器：根据是否需要多模态、工具调用、低延迟或高可靠性选择不同价格档。
- 审计与脱敏层：发送文档、代码和用户数据前删除密钥、个人信息和不应离开内部系统的内容。
如果要加入图片或视频，通常需要按照供应商定义的多模态消息格式传入 URL、文件 ID 或 base64 数据。不要直接假设不同模型的字段完全兼容，尤其要单独验证视频时长、文件大小、帧采样和 MIME 类型限制。
Agent 设计要配合长上下文
长窗口只有在工作流设计合理时才会产生收益。一个稳健的 agent 可以把上下文拆成四类内容：
- 任务状态：当前目标、已完成步骤、下一步动作。
- 证据材料：原始文档、代码片段、图片或视频分析结果。
- 工具轨迹：调用参数、返回结果、错误信息和重试次数。
- 决策记录：为什么选择某个方案，以及还缺少哪些验证。
每次工具调用后，不要只把结果追加到上下文，还应记录结果是否可信、是否需要人工确认，以及失败后能否安全重试。这样可以减少 agent 在百万级上下文中反复阅读无关内容，也方便出现错误时定位原因。
需要注意的是，摘要不能简单地按字符截断。对于代码、SQL、配置文件和日志，应保留行号、错误堆栈和相关依赖；对于视频和图片，应保留时间戳、帧信息或对象定位。压缩目标应是减少冗余，而不是删除可验证的证据。
采用前的检查清单
Muse Spark 1.3 这类百万级上下文模型适合长周期、多步骤和多模态任务，但是否值得采用，要看业务的真实调用形态。
可以在采购或接入前确认：
- 是否真的需要一次调用覆盖超长历史，而不是通过检索和摘要解决。
- 两档价格对应的数据使用、保留、隔离和退出条款是什么。
- 工具调用成功率是在真实业务工具上测得，还是只来自公开评测。
- 长上下文下的延迟、并发、超时和重试成本是否可接受。
- 能否通过路由策略，把高价档限制在高价值任务中。
- 是否保留模型无关的消息、工具和存储抽象，避免被单一供应商锁定。
百万 token 上下文降低了 agent 维护长期状态的难度，却没有消除成本、隐私和可靠性问题。对工程团队而言，最值得尝试的路径是先选一个可审计的长任务做小规模评估，再用真实的 token、延迟、工具成功率和人工修正次数计算总成本，而不是只看宣传中的上下文窗口大小。