系列第 17 篇。主文档见 智能体上下文工程实现.md。
Anthropic 推出了 1M token 上下文（Opus 4.7 [1m] 模式）。但"窗口更大"不等于"问题消失"。这一篇讲超大 context 下被忽视的成本曲线、退化现象，以及该不该用 1M 模式的决策依据。
0. 1M context 不是免费午餐
很多人误以为：窗口从 200k 涨到 1M，就可以"什么都塞进去"。实际不是。
超大 context 带来三个新问题：
- 价格非线性：1M 模式单 token 成本通常显著高于 200k 模式
- 延迟非线性：处理 800k token 的请求比处理 100k 慢得多（不是 8 倍，是 12-20 倍）
- 质量非线性：context 越长，"中间内容遗忘"现象越明显
把这三条放一起看，超大 context 不是默认选择，是特殊场景的工具。
1. 价格曲线
Anthropic 1M context 模式（截至 2026/05）的定价大致：
| 区间 | 价格倍数 |
|---|---|
| 0-200k token | 基准价 |
| 200k-1M token | 基准价 × 2（input） |
意思：超过 200k 的部分单价翻倍。所以塞到 800k 的请求，比塞 200k 贵 7 倍（不是 4 倍）。
cache 在 1M 模式下仍生效，但 cache 写入成本也按新价计。一次 cache miss 在 1M 模式下的损失是 200k 模式的几倍。
1.1 实际成本计算
def estimate_cost(input_tokens, output_tokens, cached_tokens, mode):
if mode == "200k":
in_price, cache_price, out_price = 0.015, 0.0015, 0.075 # per 1k
elif mode == "1m":
in_price = 0.015 if input_tokens <= 200_000 else 0.030
cache_price = in_price / 10
out_price = 0.075 if input_tokens <= 200_000 else 0.150
uncached = input_tokens - cached_tokens
cost = (uncached * in_price + cached_tokens * cache_price + output_tokens * out_price) / 1000
return cost
数字是示意，实际以 Anthropic 价目表为准。但结论稳定：超过 200k 的部分单价跳档。
1.2 一个直观对比
任务：读取整个 100 文件的项目并回答一个问题。
| 策略 | tokens | 成本（示意） |
|---|---|---|
| 1M 模式：全读 | 800k | $$$$$ |
| 200k 模式 + 多轮 grep + read | 50k × 5 轮 = 250k | $$ |
| 200k 模式 + 子 agent 探索 | 30k 主 + 子 agent 几次 | $$$ |
第一种最省事（一次性塞进去），但贵 5-10 倍。第二种最省钱但要更精细的 prompt 工程。第三种平衡。
2. 延迟曲线
延迟增长比成本更陡峭。
实测（基于 Opus 4.7）：
| input tokens | typical latency |
|---|---|
| 10k | 2-4 秒 |
| 50k | 4-8 秒 |
| 200k | 15-25 秒 |
| 500k | 60-90 秒 |
| 800k | 120-180 秒 |
| 1M | 180-300 秒 |
1M 输入的请求可能要等 5 分钟才出第一个 token。这不是"用户能等"的体验。
2.1 延迟的根因
- attention 复杂度：理论 O(n²)，实际经过 flash attention 等优化降到准线性，但仍比短 context 慢得多
- KV cache 大小：占 GPU 内存，更大 → 调度更难
- prefill 阶段：在生成第一个 token 前要"读完"整个输入
2.2 streaming 也救不了 prefill
streaming 让 output 边生成边显示。但 prefill 阶段（处理输入）没法 streaming —— 必须读完整个输入才能生成第一个 token。
所以即使你看到"output 流畅出"，前面已经等了几十秒到几分钟。1M 模式下这个等待是不可避免的。
3. "lost in the middle" 现象
这是超大 context 最隐蔽的问题：模型对中间位置的内容关注度降低。
实验验证（多模型、多任务一致）：
内容位置 注意力强度
──────────────────────────────────
开头（前 10%） 高
开头-中间 中
中间（30-70%） 低 ← 容易被忽略
中间-结尾 中
结尾（后 10%） 高
放在中间的关键事实，模型可能"看到了但没用上"。
3.1 在 200k context 里也存在
不是 1M 才有的问题。在 200k context 里"lost in the middle"已经出现。但 1M 时严重得多 —— 中间区域占比更大，被忽视的内容也更多。
3.2 工程后果
如果你把 800k 的项目代码塞进 1M context 让模型回答问题：
- 关键文件在中间 → 模型可能没真正理解
- 输出看起来合理 → 你以为它读懂了
- 实际是基于开头和结尾的内容 + 模型先验 hallucinate 出来的
这是最危险的失败模式：看起来对、实际错。
4. 1M 模式何时值得用
不是所有任务都不该用 1M。值得用的场景：
4.1 单文件超大但密集相关
- 一个 800k 的合同 PDF，每段都可能相关
- 一个超长的 log 文件需要找跨段关联
- 一份完整的代码库做整体安全审计
这些任务没法切（切了就丢了关联），且每段都重要（不是只看开头结尾）。
4.2 超长会话不切的场景
- 用户在做长篇创作，之前的所有上下文都重要
- 某些角色扮演场景需要完整对话史
但即使这些，也建议主动压缩（参见 07 篇）而不是裸 1M。
4.3 不值得用 1M 的场景
- 代码库探索（用 grep + Read 更省）
- 多文档问答（用 RAG 或 sub-agent 更省）
- 通用编程任务（200k 模式 + 多轮足够）
5. 替代方案：把"大输入"变"小请求"
大多数 1M 想解决的问题，可以用其他方式解决：
5.1 RAG（检索增强）
用户问题 → embed → 检索相关段 → 只把相关段塞进 context
适用：
- 文档库
- FAQ
- 大型知识库
200k context + 5k 检索结果 = 比 1M 全塞便宜十倍。
5.2 子 agent 隔离
参见 03 篇。子 agent 用自己的 context 读 800k，主 agent 只收摘要。
5.3 多轮 grep + read
参见前几篇。代码库不要全读，定位 + 精读。
5.4 切分 + 接力
参见 14 篇。长任务跨多个会话，每个会话上下文可控。
6. cache 在 1M 模式的特殊性
cache 仍然工作，但有几点要注意：
6.1 cache 写入更贵
cache 写入价格 ≈ input 价格 × 1.25。1M 模式下 input 单价已翻倍，cache 写入也翻倍。
第一次建立 cache 的成本特别高。所以1M 模式下尽量复用 cache，避免反复建立。
6.2 cache 命中收益更大
成本翻倍的同时，cache 命中折扣仍是 1/10。所以命中一次省的钱比 200k 模式多。
但前提是真的命中。1M 模式下 cache miss 的惩罚比 200k 严重得多。
6.3 cache breakpoint 选位置更难
200k 模式下 4 个 breakpoint 比较奢侈，1M 模式下更稀缺。每个 breakpoint 该放在哪里需要更精细的设计。
7. 如何决定用不用 1M
决策树：
任务最大输入预计多大？
├─ < 100k → 200k 模式
├─ 100k-200k → 200k 模式
├─ 200k-500k
│ ├─ 内容可切分？→ 200k + 分批
│ └─ 不可切分 → 1M
└─ > 500k
├─ 内容可切分？→ 强烈建议切分
└─ 不可切分 → 1M（接受高成本和延迟）
关键判断：内容可切分性。如果可切分（多文档、可独立段落），就别上 1M。
7.1 用户感知
如果是交互式 agent（用户实时等回复）：
- 1M 模式延迟 60s+ 的请求是 UX 灾难
- 200k 模式 + 多轮即使总时间相近，也比一次长等待好
如果是批处理（异步）：
- 1M 模式可接受更长延迟
- 但要权衡成本
8. 监控 1M 模式的指标
如果用 1M 模式，13 篇讲的指标外还要监控：
| 指标 | 阈值 | 行动 |
|---|---|---|
| 平均 input tokens | >300k | 检查是否真需要这么多 |
| prefill 延迟 | >60s | 用户体验告警 |
| 中间内容利用率 | 难直接测 | 通过 eval 测试 |
| 1M vs 200k 成本比 | >5x | 评估 ROI |
8.1 中间内容 eval
设计 eval 验证模型确实读了中间内容：
test_input = preamble(50k) + "FACT_X = 42" + middle(500k) + question("What is FACT_X?")
expected_output = "42"
如果模型答错或编一个值，说明中间内容没真正进入推理。这种 eval 应该作为 1M 模式上线前的必测。
9. 从设计哲学看 1M
主文档反复说"信噪比比容量重要"。1M context 让人误以为容量解决了问题，但实际上：
- 容量越大，信噪比越难维持
- 模型越关注开头结尾，中间噪音越大
- 越大的窗口，越需要精细的拼接策略
所以 1M context 是升级版的考验而不是免死金牌。它让懒人方案（"全塞进去"）短期可行，但长期看仍要回到上下文工程的基本原则：让模型在每一刻看到正好的那部分。
10. 给 Agent 设计者的可迁移规则
- 默认 200k 模式：不要无脑用 1M
- 测算成本曲线：200k vs 1M vs 替代方案的端到端成本
- 测算延迟曲线：1M 模式的 prefill 延迟可能毁 UX
- eval 中间内容：验证模型真的读了，不是 hallucinate
- cache 在 1M 下更关键：miss 惩罚翻倍
- 可切分就切分：RAG / sub-agent / 多轮 / 多会话
- 1M 用于真正不可切的密集任务：合同、log、整体审计
- 交互场景慎用 1M：用户等不了 60 秒
- 批处理可考虑 1M：异步场景延迟容忍度高
- 监控 input token 分布：长尾要警惕
11. 一句话总结
1M context 不是"上下文工程的解药"，是"特殊场景的工具"。容量增大反而让信噪比挑战更严峻 —— 把它当作能力补充而非默认选项，agent 系统才不会被超大 context 的成本和延迟拖垮。
