Appearance
上下文窗口与 1M 的区别
上下文窗口是什么
上下文窗口(context window)是模型单次请求能"看到"的全部内容的上限,按 token 计算。对编程 Agent 来说,窗口里装的远不止你的提问:
text
┌───────────────────────────────┐
│ 系统提示(Claude Code 自身) │ ~1-2 万 token
│ 工具定义(内置 + MCP) │ 数千 ~ 数万 token ⚠️
│ CLAUDE.md / AGENTS.md / 记忆 │ 数百 ~ 数千 token
│ 对话历史(你的每条消息) │
│ 工具调用与结果(读文件、命令输出)│ ← 占大头,持续增长
│ 模型的思考与回复 │
└───────────────────────────────┘一次任务中 Agent 每读一个文件、每跑一条命令,结果都追加进窗口。窗口是只增不减的,直到触发压缩(compact)——Claude Code 会在接近上限时自动把早期历史总结成摘要,细节随之丢失。
200K vs 1M:真实的区别
Claude 模型默认 200K token 上下文;Sonnet 4 起提供 1M token 的长上下文模式(约 5 倍)。直观感受:200K ≈ 15 万英文单词或数千页代码摘录;1M 可以装下一个中型仓库的大部分源码。
但两者的区别不只是"更大":
| 维度 | 200K(默认) | 1M(长上下文) |
|---|---|---|
| 容量 | 中型任务足够,长任务依赖 compact | 超长会话、大仓库分析、多文档对照 |
| 价格 | 标准价 | 超过 200K 的部分按约 2 倍输入价、1.5 倍输出价计费 |
| 延迟 | 较低 | 上下文越大,首 token 延迟越高 |
| 质量 | — | 并非无代价:上下文过长会出现"迷失在中间"(lost in the middle)、指令遵循变弱的现象 |
| 缓存 | 重要 | 更重要——1M 的前缀全量重建一次非常昂贵(见缓存篇) |
核心心智
1M 不是"免费的更大内存",而是"更贵、更慢、但能装下更多"的选项。能用 200K + 良好的上下文管理解决的,不要靠 1M 硬扛。 1M 的正确场景:一次性大范围代码审计、跨几十个文件的重构分析、超长文档问答。
在 Claude Code 中开启 1M
在会话中用 /model 命令,在模型 ID 后加 [1m] 后缀:
text
/model claude-opus-5[1m]也可以在启动时指定,或写进配置:
bash
# 启动参数
claude --model claude-opus-5[1m]
# 环境变量
export ANTHROPIC_MODEL='claude-opus-5[1m]'json
// .claude/settings.json
{
"model": "claude-opus-5[1m]"
}支持 1M 的模型都可以用同样的后缀,例如 claude-sonnet-5[1m]。切换后用 /context 查看,窗口上限会显示为 1M,自动压缩的触发点也随之推后。
注意
- 1M 模式需要你的账号/套餐支持长上下文(API 早期为 beta,需要 usage tier 达标;订阅计划中高档位才开放)。
- 超过 200K 的部分按长上下文费率计费,Max/Team 订阅下则消耗更多的用量额度。
直接调 API 时开启 1M
如果你在自己的程序里用 Anthropic API,长上下文通过 beta header 开启:
python
import anthropic
client = anthropic.Anthropic()
resp = client.beta.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
betas=["context-1m-2025-08-07"], # 开启 1M 上下文
messages=[{"role": "user", "content": "..."}],
)大窗口 ≠ 不需要上下文管理
即使开了 1M,这些实践依然成立: