2026年3月，三大模型厂终于都喊出了"1M上下文"。但真正用过的人都知道——能装和能用是两码事。

前几天AI圈有个挺有意思的现象：OpenAI的GPT-5.4、Anthropic的Claude Opus 4.6、Google的Gemini 3.1 Pro，这三个当红模型在同一个月全部支持了100万token的上下文窗口。

媒体标题一出来，群里一片欢呼。

然后很快就有实操的人回来泼冷水。

用Claude Code的开发者说，context变成1M之后反而觉得体验下降了——因为系统很少自动压缩历史对话，聊着聊着context就越来越乱。

另一位搞coding agent的朋友更直接："GPT-5.4的1M上下文真的赶鸭子上架，犯了好多超级低级的指令不遵循错误。"

说白了：能塞进去的东西，不代表模型真的记得住。

一把尺子量三家

谁家长上下文更好用，得拿数据说话。目前业内最认的测试叫MRCR v2（Multi-Round Coreference Resolution，多轮指代消解）。

这个测试的名字听起来很学术，实际套路很简单：给模型扔一堆干扰文本，里面藏了8条需要记住的信息，然后让模型把第几条信息对应什么内容答出来。

8条信息同时追踪，对模型记忆力是个硬考验。

分数出来了，差距相当大：

数据来自各家官方文档和第三方评测平台 1[3]。

你看，同样是号称1M上下文，Claude拿到的分数是Gemini的近3倍。

更值得注意的是另一组数据：在128K（只有1M的八分之一）的范围内，三家的分数其实差不多，都在85%左右 [4]。

这说明了一个事实——短上下文大家都能打，拉开差距的是超长距离的记忆可靠性。

为什么1M这么难

很多人以为context window大就是一个数字游戏：我把序列长度从128K加到1M，模型自然就能读更多内容。

问题没这么简单。

核心瓶颈在于attention机制的计算方式。Transformer模型在处理每个token时，需要跟它前面出现过的所有token做相似度计算。序列越长，这个计算的复杂度越高，模型越容易在海量信息中"走丢"。

打个比方：

想象你在图书馆找一本书。128K上下文相当于你在一个中型书架间里找书——虽然不算容易，但至少你知道大概在哪一排。到了1M，相当于整个大学城的所有图书馆的书全摊在你面前，而你只能靠模糊的印象去找某一本特定的书。

Google最早（2024年初）就实现了1M上下文，一度是行业唯一。但他们家模型在1M场景下的表现一直不尽如人意，从2.5 Pro的16.4%到3.1 Pro的26.3%，几年时间只涨了不到10个百分点 [5]。

而Anthropic保守了整整两年，直到2026年2月才在Opus 4.6上放出1M beta，第一次就跑出了76%的成绩——比Google同期的1M性能好4倍。

Anthropic的工程团队后来在博客里解释了他们的思路：

"等待更大的上下文窗口看起来显然是一个好策略。但很可能在未来很长一段时间内，无论多大的context window都会面临上下文污染和信息相关性的问题。解决方案不是增加容量，而是更好地管理现有容量。"

这句话翻译成大白话就是：与其拼命堆窗户面积，不如先把窗户擦干净。

OpenAI的取舍：宁可不要1M

还有一个值得注意的选择：OpenAI的GPT-5.2版本主动把上下文收缩回了256K。

也就是说，GPT-5.2根本不支持1M。

这看起来像退缩，但实际上是一种战略选择。GPT-5.2的设计哲学是：与其做一个1M但可用性很差的模型，不如把256K以内的性能做到极致。在4K到256K的范围内，GPT-5.2的表现非常稳定，大部分日常任务完全够用 [6]。

到了GPT-5.4，OpenAI又回到了1M，但这个1M变成了付费功能——你需要花双倍的钱才能使用1M上下文，标准模式只给到272K。

这其实是另一个信号：大厂也在试探市场的真实需求。到底有多少人真正需要1M上下文？愿意为这部分能力付多少溢价？答案还在收集过程中。

短期记忆 vs 长期记忆

我们日常跟AI对话时积累的对话历史，严格来说不算是"长期记忆"。它更像是聊天过程中的短期工作记忆——用完就没了。

真正的长期记忆场景是这样的：你希望模型能跨会话记住你的项目结构、偏好、历史决策。这需要不同的技术方案，比如RAG（检索增强生成）、向量数据库、知识图谱等。

但现在长上下文能力的进步，正在模糊这两者的边界。

有一个叫MSA（Memory Sparse Attention）的研究方向就在尝试把部分记忆能力直接内化到模型内部——让模型自己学会在超长历史中选择性地访问相关信息，而不是把所有东西一股脑地塞进attention窗口里 [7]。

这条路还远，离生产可用有距离。但它指向了一个清晰的趋势：

未来AI系统的记忆架构，很可能是模型内部记忆和外部记忆系统的混合体。

哪些记忆需要保持在模型内部（推理连续性优先），哪些应该留在外部（更新和审计优先）？

给普通用户的几个建议

聊完技术层面的东西，回到实际应用层面。对大部分用AI的人来说，有几点可以留意：

第一，别被"最大支持xxx token"这个数字迷惑。标称100万和实际能在100万里可靠地找到你要的信息，中间差了十万八千里。如果必须处理超长文本，现阶段Claude Opus系列相对更靠谱一些。

第二，对于大多数日常任务，128K已经足够了。一篇论文加几段代码再加半小时的对话记录，通常不会超过这个量级。在这个范围内，各家模型的性能差异很小。

第三，如果你在用AI写代码或者做研究，好好维护你的上下文质量。同样一个工具，同样的模型，不同人用起来效果差很多。差距往往不在模型本身，而在你给模型提供了什么样的"上下文脚手架"——你的规则文档、领域知识沉淀、项目说明文件，这些才是决定AI输出质量的杠杆点 [8]。

写这些上下文文档的动作本身，会迫使你把脑子里那些说不清楚的隐性经验变成显式的文字规则。这个"显式化"的过程，才是真正的价值所在。

最后

去年这个时候，大家都在争论"context窗口的尽头是多少"。今年的讨论已经转向了"context reliability"——即模型在给定上下文中真正可用的程度。

学术界有人总结得挺到位：

"把一个百万token塞进窗口只是工程问题。让模型真正用上存在第60万token位置上的信息，那才是科学问题。" [9]

工程问题总有上限。科学问题没有尽头。

下次再看到谁家发布了更大的上下文窗口，你可以先问一句：那又怎样？

参考资料

[1] Anthropic, "Sonnet 4.6 System Card," system performance benchmark. https://docs.anthropic.com/en/docs/system-card-sonnet-4-6

[2] OpenAI, "GPT-5.4 technical report and benchmarks." https://openai.com/research/gpt-5-4

[3] contextarena.ai, "Long Context Leaderboard." https://contextarena.ai

[4] Google, "Gemini 3.1 Pro model card and technical report." https://storage.googleapis.com/deepmind-media/gemini/gemini_v3_1_report.pdf

[5] The March 2026 Frontier, "The context-window arms race is over." https://www.themarch2026frontier.com/context-race-over

[6] OpenAI Blog, "Introducing GPT-5.2." https://openai.com/blog/gpt-5-2

[7] EverMind-AI, "MSA: Memory Sparse Attention." https://github.com/EverMind-AI/MSA

[8] Morph research, "SWE-Bench Pro scaffold comparison study," 2026.

[9] Michelangelo evaluation (arXiv 2409.12640), "Crossing the long-context valley." https://arxiv.org/abs/2409.12640