Claude 4.5 Opus 长上下文实测：100 万 token 真的能用吗？

Anthropic 在 7 月悄悄把 Claude 4.5 Opus 的上下文窗口从 200K 提到了 1M，配合 Sonnet 一起开放给所有 API 用户。官方的"lost in the middle"问题已大幅改善 — 至少在他们的内部 benchmark 上是这样。

但真实情况呢？我花了两周，把 1M context 用在 4 个真实业务场景上。

测试设置

模型：claude-4-5-opus-20250901，temperature=0.3
上下文填充：用 5 个不同长度的真实数据集，从 100K 到 950K
任务类型：文档问答、代码审查、长对话摘要、跨文档关联分析
对比基线：Gemini 2.5 Pro（同样支持 1M）和 GPT-5（256K）

四个场景的真实数据

场景 1：法律合同审查

输入：47 份 PDF 合同，共 820K token，跨 12 个司法管辖区。

任务：找出所有提到"管辖法律变更"和"争议解决"的条款，并交叉对比。

Claude 4.5 Opus 准确率：91%
- 优点：跨文档引用非常准，能精确到第几节
- 缺点：处理 PDF 表格时偶尔丢失合并单元格信息
- 延迟：18 秒（首次响应 6 秒，完整输出 12 秒）
- 成本：$11.40

Gemini 2.5 Pro 准确率：89%
- 优点：表格处理明显更好
- 缺点：在引用具体节号时容易说"在前文提到过"而不是给准确位置
- 成本：$7.80

GPT-5 准确率：84%（上下文被截到 256K，丢了 580K 内容）
- 只能分批处理，正确率受 batch 大小影响

场景 2：代码库全局重构

输入：整个 monorepo 压缩成单一 prompt，920K token。

任务：找出所有调用 getUserById 但没有处理 null 的地方。

Claude 4.5 Opus：找到 23 个位置，2 个误报
Gemini 2.5 Pro：找到 21 个位置，1 个误报
GPT-5：因上下文限制无法完成

但 Opus 的速度明显慢 — 单次推理要 32 秒，Gemini 18 秒。如果在 IDE 里等结果，这个延迟会让人抓狂。

场景 3：长对话摘要

输入：90 轮客服对话记录（450K token）。

任务：生成结构化摘要，提取所有客户提到的痛点。

三个模型表现都在伯仲之间（85-89%），但 Opus 的摘要更敢于做归因 — 它会说"客户在第 32 轮明显感到挫败"，Gemini 和 GPT-5 更倾向于平铺直叙。

场景 4：跨文档时间线构建

输入：156 份会议纪要，680K token。

任务：构建一张"Q2 所有产品决策的时间线"。

这是 Opus 真正发光的地方。它能准确还原"3 月 5 日会议 A 提到 X，3 月 12 日会议 B 反驳 X，3 月 18 日会议 C 折中采纳 Y"这种复杂关系。Gemini 经常把不同会议的人物搞混，GPT-5 直接放弃（截断）。

三个关键发现

1. 1M context 是真有用，但有边界

不是说 1M 都能用，而是长尾场景才用得上。日常 90% 的调用都在 50K 以内，1M 是给那 10% 准备的。如果你的业务里没有"需要同时看 50 份以上文档"的场景，别为 1M 付溢价。

2. Op[u]s 的"lost in the middle"确实改善了，但没完全消失

在 600K-900K 这个区间，准确率从 91% 掉到 79%。Anthropic 显然做了什么，但中段（30%-70% 位置）的内容仍比首尾更容易被忽略。如果你的查询可能落在中段，建议把关键信息显式复述或放在文末。

3. 成本是隐藏的杀手

1M context 的输入 token 计价是 $15/M（Opus 4.5），输出 $75/M。一次 950K 的调用，光输入就 $14.25。我们跑了一周的测试，账单 $340。生产环境一定要严格限制触发 1M 的场景，或者用 prompt caching 降低成本（缓存命中后输入 $1.5/M，便宜 10 倍）。

实操建议

# 推荐的调用模式
import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-4-5-opus-20250901",
    max_tokens=4096,
    system="[关键指令] 引用原文时必须给出准确位置（节号 / 行号）",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": f"以下是 {len(docs)} 份文档..."},
                # 关键文档放在最后，避免 lost in the middle
                {"type": "text", "text": "【优先关注】" + last_doc},
            ] + docs,
        }
    ],
    # 启用 prompt caching
    extra_headers={"anthropic-beta": "prompt-caching-2024-07-31"},
)

结论

1M context 是不是"噱头"？不是噱头，但对大多数人用不上。

如果你有以下场景，值得为 1M 付钱：
- 法律 / 医疗 / 金融的批量文档分析
- 整个 monorepo 的代码审查
- 多源会议记录 / 邮件的时间线构建

如果只是日常聊天或单文档问答，200K 的 Sonnet 4.5 + 良好的 RAG 检索就够。

Anthropic 这次升级把长 context 从"我能跑"变成了"我能跑好"。但别忘了，长 context 是放大器，不是替代品。垃圾进，垃圾出 — 你的检索质量决定一切。