2026年100万Token上下文正式来了：Claude Opus 4.6 和 Sonnet 4.6 的这次升级，比你想象的更重要

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

 哈喽，大家好，我是顾北。

就在刚刚。

北京时间 2026 年 3 月 14 日，Anthropic 官方博客悄悄更新了一篇公告，标题很低调："1M context is now generally available for Opus 4.6 and Sonnet 4.6"。

没有发布会，没有大张旗鼓。但在开发者社区，这条消息炸开了锅。

很多人看到"100万token上下文"会以为这是一个新功能。其实 Opus 4.6（2月5日发布）和 Sonnet 4.6（2月17日发布）在发布时就已经有 1M 上下文支持了——但当时是 beta 状态，需要在请求头里加一个 anthropic-beta: 1m-context 的标记，而且超过 200K token 的部分要收长上下文溢价：Opus 输入价格翻倍到 37.5/M。

这次 GA（Generally Available，正式可用）意味着三件事：

不再需要 beta 标头。超过 200K token 的请求直接发，不用改代码
溢价消失。90万 token 的请求和 9000 token 的请求，每个 token 的单价完全一样。Opus 4.6 维持 25，Sonnet 4.6 维持 15
单次媒体配额从 100 页/张提升到 600 页/张，一次丢进去 600 页 PDF 不是梦

对于已经在用 beta 版长上下文的团队，成本直接腰斩。对于还没用过的团队，进入门槛也彻底降下来了。

给个具体感受：

内容类型

1M token 大约能装多少

纯文字

约 75 万字（大概 5-6 本普通小说）

文档页数

约 1500 页 A4

代码行数

约 15 万行

代码仓库

5-10 个中小型 SaaS 项目全量代码

换个说法：以前用 Claude 处理代码审查，经常要手动把代码库切片，把 A 模块、B 模块、C 模块分批喂进去，然后再综合结论。现在你可以直接把整个仓库丢进去，一次问完。

用过 AI 的人大概都有一种体验：对话开始时模型很聪明，但越聊越长，它开始"忘事"。你在第 3 轮说的前提条件，到了第 20 轮它就不认了。前面的细节丢掉了，推理链断了，最后答案越来越离谱。

这就是所谓的 Context Rot（上下文腐烂）——模型有上下文窗口，但不代表它真的能平等地"记住"窗口里的所有内容。越靠近上下文中间的信息，往往越容易被忽略（学术上叫 "lost in the middle" 问题）。

Opus 4.6 在这方面做了专项优化。一个直观的数据是：在 MRCR v2 的"百万token大海捞针"测试中（在 1M token 的文本里隐藏 8 个关键信息，看模型能找到几个），Opus 4.6 得分 78.3%，而前代 Sonnet 4.5 只有 18.5%。

不是同一个量级的提升——这是质变。

Sonnet 4.6 在 GraphWalks BFS（1M token 图遍历测试）中得分 68.4%，在同等上下文长度的前沿模型里也属于领先水平。

这意味着 1M 上下文不只是个数字，模型真的能在超长文本里"找到"你需要的信息。

光有大窗口还不够。在实际的 Agent 任务里，模型跑着跑着会逼近窗口上限——尤其是调用了很多工具、产生了大量中间输出的场景。

Anthropic 同步推出了 Context Compaction（上下文压缩） 功能：当对话即将触及窗口上限时，系统自动把较早的历史压缩成摘要，关键信息保留，冗余细节丢掉，整个过程对用户透明。

在 Claude Code 里，这个功能已经向 Max、Team、Enterprise 用户默认开放，Opus 4.6 会话可以自动使用完整的 1M 上下文窗口，不再需要手动 /compact。

早期用户反馈：把上下文从 200K 扩展到 500K 甚至 100万 token 后，处理大型代码变更和跨文件依赖时，反而因为减少了上下文切分的额外轮数，总 token 消耗反而降低了。

 代码开发：完整代码仓库 + 所有测试 + 配置文件，一次性进入上下文。Claude 可以做真正的跨文件依赖分析，而不是靠你手动告诉它"这个函数在那个文件里"。Replit 团队曾评价 Opus 4.6："在 Agent 规划上是巨大跃进，能将复杂任务拆解为独立子任务、并行执行工具与子代理。"

⚖️ 法律文档：同时引入多份百页合同，完整回溯多轮谈判变更。以前需要法务助理人工对照，现在 Claude 可以跨文档检索冲突条款。

 科研：一次纳入数百篇论文、数学公式和仿真代码，做真正意义上的跨文献综合分析，而不是分批提问、人工汇总。

 运维：从初次告警到问题缓解，保留完整的日志链路、所有实体和排障假设。以前"上下文用完了，重新说一下背景"的窘境不再有了。

 金融：长时间运行财务分析，中途不丢失推理上下文，不需要每隔几轮就重新说明分析前提。

目前正式版 1M 上下文已在以下渠道上线：

Claude 原生平台（claude.ai / claude.com）
Amazon Bedrock
Google Cloud Vertex AI
Microsoft Azure Foundry
Claude Code

API 侧无需任何改动——如果你之前发了 beta 头，服务端会自动忽略，不影响运行。

坦白说，"100万token上下文"这个功能点早就不新鲜了。Google 的 Gemini 1.5 Pro 2024 年底就已经在做同样的事。但真正的问题一直不是"能不能装"，而是"装进去之后模型能不能用好"。

Sonnet 4.5 的 MRCR v2 得分 18.5% 说明了什么？说明它名义上支持长上下文，但实际上在超长文本里找信息的能力极差——装了等于没装。Opus 4.6 的 78.3% 才是真正让 1M 上下文有意义的地方。

这次 GA 的另一个信号是定价策略的转变。取消长上下文溢价，说明 Anthropic 有信心把这个能力作为基础能力向外输出，而不是当成一个高溢价的高级功能卖。这个节点，才是 1M 上下文真正进入生产可用状态的时刻。

如果你之前因为 beta 状态或溢价问题没有认真用过长上下文，现在可以真正考虑了。

你目前在用 Claude 做什么工作？有没有遇到过上下文不够的情况？ 欢迎评论区聊聊，或者聊聊你对 1M 上下文有什么具体的用法设想。

我是顾北，我们下期再见！

2026年100万Token上下文正式来了：Claude Opus 4.6 和 Sonnet 4.6 的这次升级，比你想象的更重要

相关推荐