Claude Opus 4.6 和 Sonnet 4.6 百万 Token 上下文窗口正式 GA

Anthropic 宣布 Claude Opus 4.6 和 Sonnet 4.6 的 100 万 Token 上下文窗口正式进入 GA（General Availability）阶段。此前这个能力一直处于有限测试，现在所有用户都可以直接使用。对于处理大型代码库、长文档分析和复杂多轮对话的开发者来说，这是一个实质性的能力解锁。

发生了什么

Anthropic 通过官方推文确认，Claude Opus 4.6 和 Sonnet 4.6 两个模型的 100 万 Token 上下文窗口现已全量开放。这意味着通过 API 和 Claude 客户端，用户都能使用完整的百万级上下文能力。

100 万 Token 大约相当于多少？粗略换算：约 75 万英文单词，或者一个中等规模的完整代码仓库。你可以一次性把整个项目的源码、文档、测试用例全部丢进去，让 Claude 理解全局后再回答问题。

这个时间点也值得关注。过去一周 Anthropic 密集发布了多项 Claude Code 更新：多 Agent 代码审查系统、内置 /loop 调度器、交互式图表生成。百万上下文 GA 是这一系列能力升级中的关键一环 — 更大的上下文窗口让 Claude Code 在处理真实项目时的实用性大幅提升。

为什么重要

上下文窗口大小直接决定了大语言模型（LLM）能处理多复杂的任务。128K Token 的模型大约能处理一本短篇小说；100 万 Token 可以处理一整套技术文档或一个中大型代码库。

这不只是数字上的提升，而是使用方式的质变。以前你必须精心挑选喂给模型的上下文 — 截取关键文件、手动摘要、分批处理。现在你可以更粗放地把相关材料全部扔进去，让模型自己判断什么重要。

横向对比看：Google 的 Gemini 2.5 Pro 已经提供 100 万上下文窗口；OpenAI 的 GPT-5.4 上下文为 256K。Claude 百万上下文 GA 让 Anthropic 在这个维度上与 Google 持平，远超 OpenAI 当前水平。

对于用 Claude Code 做日常开发的团队，这意味着 Claude 可以一次性理解更完整的项目结构。不再需要频繁地"你看一下这个文件""再看一下那个文件" — 模型能同时持有足够多的上下文来做跨文件的推理和修改。

技术细节

百万 Token 上下文在实际使用中有几个关键考量：

延迟和成本。更长的上下文意味着更多的计算。百万 Token 输入的请求，首 Token 延迟（TTFT）会显著高于短上下文请求。API 按 Token 计费，一次百万 Token 的输入成本不低。实际使用时需要权衡：不是每个请求都需要把整个代码库塞进去。

检索精度。"Needle in a haystack" 测试衡量模型在超长上下文中定位特定信息的能力。Claude 在此前的测试中表现出色，但百万级上下文下的准确率是否有衰减，需要在具体场景中验证。一般来说，信息在上下文中间位置时更容易被"遗忘" — 这是所有长上下文模型的共性问题。

实际使用模式。百万上下文最适合的场景包括：

代码库分析：把整个仓库的核心代码一次性输入，进行架构审查或跨模块重构
文档 QA：把完整的技术文档集（API 文档、设计文档、运维手册）作为上下文
长对话保持：在复杂的多轮开发对话中，不再因为上下文截断而丢失前面的讨论

在 API 层面，使用方式没有变化。设置 max_tokens 和正常调用一样，模型会自动处理长上下文。但建议在 prompt 中合理组织输入材料的结构 — 比如用清晰的分隔符标注不同文件，让模型更容易定位。

你现在该做什么

重新评估你的 RAG 管线。如果你之前因为上下文限制搭了复杂的检索增强生成（RAG）系统，现在可以考虑简化 — 对于中等规模的知识库，直接塞进上下文可能比 RAG 检索更准确。
试试整仓库输入。把你的核心代码库（去掉 node_modules 和构建产物）一次性传给 Claude，测试跨文件理解的效果。
注意成本控制。百万 Token 输入很贵。在生产环境中做好 Token 预算，只在真正需要全局理解的任务中使用超长上下文。
关注 Claude Code 的配合。百万上下文 + 代码审查 + /loop 调度器，这套组合拳让 Claude Code 在实际项目中的能力边界又往外推了一大步。

相关阅读：今日简报有更多 AI 动态。另见：Claude vs ChatGPT 对比。

觉得有用？订阅 AI 简报，每天 5 分钟掌握 AI 动态。