长上下文不可强求：从 Gemini 到 Opus，1M context 为什么还没体现出应有价值
摘要
过去一年，long context 一直是大模型产品最容易被拿来宣传的能力之一。32K 不够，就上 128K；128K 还不够，就上 1M。看起来，只要上下文窗口足够大，agent 就能记住更多历史、读取更多代码、处理更长文档，最终自然变得更强。
但真实使用里，事情并没有这么简单。
无论是 Gemini 系列的超长上下文承诺，还是最近围绕 Opus / Claude Code / 1M context 的讨论，用户反复遇到的都不是“窗口不够大”，而是另一类问题：上下文越来越长，但收益并没有按比例增长；有时甚至更贵、更慢、更不稳定。
这背后的核心判断其实很朴素：long context 是 capacity，不是 intelligence；是容器，不是方法。 如果 context packing、summarization、memory selection、tool filtering 和 harness 设计没有跟上，1M context 很可能只是把更多噪音、更多旧状态、更多无关轨迹一起装进去。
所以我越来越倾向于一个结论：长上下文可以有，但不可强求。 从 Gemini 到 Opus，1M context 目前并没有稳定体现出它“应有”的工程价值。问题往往不在数字不够大，而在系统不会节制地使用这份容量。
一、1M context 听起来很强，为什么实际体感经常没有预期那么强
从产品叙事上看，1M context 很有吸引力。它给人的想象空间太大了：
- 一次塞下整本书
- 一次看完整个 repo
- 一次带着所有历史会话继续工作
- 不用频繁摘要，也不用担心“模型忘了”
但这套叙事默认了一个前提：模型和系统知道该把什么放进去，也知道什么不该继续带着跑。 现实往往不是这样。
在真实 agent workflow 里，context 的组成通常非常复杂：
- 用户原始需求
- system / policy / safety instructions
- 历史计划
- 工具调用记录
- shell 输出
- 文件 diff
- 错误日志
- 旧的总结
- memory recall 结果
- 当前阶段的中间结论
只要其中任意几层没有裁剪好，长上下文就会从“能力增强器”变成“噪音放大器”。
这也是为什么不少开发者在用 Claude Code、Gemini 类长上下文模型或者其他 coding agent 时，会有一种很相似的感受：模型看起来知道得更多了，但任务不一定做得更好。
二、长上下文最常见的误区：把“能装下”误认为“该装进去”
这是我觉得最核心的误区。
模型支持 1M tokens，意味着系统可以把非常多内容塞进去；但这不等于系统应该这么做。工程上，这两者差别极大。
1. 容量不是价值
一个 1M window 的真正价值，不是“终于能把所有东西原样保留”，而是允许系统在必要时：
- 保留更完整的问题背景
- 处理更大的代码或文档切片
- 延缓上下文裁剪带来的信息丢失
但如果系统缺乏良好的选择机制，它往往会退化成另一种行为：
- 旧计划不清理
- 旧错误不折叠
- 工具输出整段回灌
- 重复文件片段继续累积
- 过期 memory 继续占位
这时 1M window 不再是 buffer，而是垃圾场。
2. 大窗口会纵容坏习惯
小窗口时代，系统被迫做 compression：摘要、提炼、裁剪、分层。
大窗口来了之后，很多产品会不自觉地偷懒：既然还能塞，那就继续塞。
结果就是，short context 阶段必须正视的问题，在 long context 阶段被推迟了，但没有被解决。等到问题积累到一定程度，用户看到的就是：
- 单任务 token 消耗飙升
- latency 增加
- rate limit 更频繁
- provider capacity 更紧张
- agent 更容易 drift
所以，大窗口有时不是解决方案，而是把设计缺陷延后暴露。
三、为什么从 Gemini 到 Opus，1M context 都还没有兑现“应有价值”
这里我不想把问题简单归因到单一模型，因为现象跨产品都存在。
Gemini 早就把 long context 作为核心卖点之一；Opus / Claude Code 近期围绕 1M context 也引发了很多讨论。用户的共同反馈大致集中在几件事上：
- 更长上下文不自动等于更高质量输出
- 长任务里 token 烧得更快
- 任务越长，越容易累积无关历史
- 稳定性和速度未必变得更好
- 当 provider capacity 紧张时，long context 反而更像成本放大器
这些现象并不意味着 1M context 没有价值，而是说明：现在的大多数 agent harness 还没有把这项能力用好。
换句话说，不是 window 本身失败了，而是“围绕 window 的工程系统”还不成熟。
四、真正的问题，不是 long context，而是 weak context compression
最近有人提出一个很有意思的判断：用户觉得 Claude Code 的 limit 变紧，可能不是平台真的“突然变小气”，而是因为 1M context model 上线后，系统每个请求携带的上下文变胖了，结果同样一个 task 更快烧掉 token 与 capacity。
这个说法是否完全准确，我没有官方证据，不会把它当成既成事实。
但从工程角度看，这个推理非常合理。
因为在 agent 场景里，真正危险的不是 context 太小，而是：
- compression 不够 aggressive
- summarization 不够可靠
- selection 不够精确
- tool output 过滤不够严格
一旦这些环节做得弱，1M context 就很容易变成 token sink。
也就是说，问题并不是：
为什么我们没有更大的窗口？
而更像是：
为什么我们还在把不该保留的东西继续带着跑？
这个区别很关键。因为前者的解决方案是继续追更大的数字，后者的解决方案则是更好的 context engineering。
五、在 coding agent 里，长上下文尤其容易失控
在普通聊天产品中，长上下文的问题还没有那么尖锐。
但一旦进入 coding agent / DevOps copilot / tool-using agent 场景，context 膨胀速度会快很多。
原因很简单：这里的上下文不仅是自然语言，还包括大量“工作轨迹”。
例如一个真实 coding task 里，上下文可能不断加入：
- 文件树与源码片段
- grep/search 结果
- 编译错误
- 测试失败日志
- shell command 输出
- patch / diff
- 中间计划与自我修正
- 历史失败尝试
如果 harness 不做强约束，模型每轮都在背着越来越重的背包继续工作。
到后面，系统不是在解决当前问题，而是在努力消化自己的历史残留。
这也是为什么不少关于 harness engineering 的讨论都在强调：真正拉开差距的，不是模型本身，而是 orchestration、context packing、tool loop、validation 和 cache。
从这个角度看，1M context 不是 agent 成功的充分条件，甚至连必要条件都未必是。很多时候，一个 context 更克制、压缩更强、loop 更干净的系统，反而比“大窗口全塞型”系统表现更好。
六、memory 也在放大这个问题：记得太多，不一定等于记得更好
长上下文的另一个常见误解是：既然窗口变大了，那 memory 问题是不是就自动解决了？
恰恰相反，window 变大，可能让坏 memory governance 更难被察觉。
最近一些关于 OpenClaw memory plugins 的讨论，已经把这个问题讲得很清楚：
- memory 不是单一功能，而是写入、检索、遗忘、维护和治理的组合
- markdown 或自然语言记忆如果不做分层，很容易变成沉积层
- 长期运行后，旧偏好、旧计划、旧日志会污染当前决策
- 真正重要的不是“记住最多”，而是“retrieves narrowly, forgets safely”
这和 long context 的问题本质上是同一个问题：信息容量扩大，不会自动提升信息质量。
如果 memory recall 没有 selection，1M context 只会把更多过时记忆重新注入模型。
所以从系统设计上看，long context 与 memory 不是互补的捷径，而是需要共同治理的两个风险面。
七、长上下文真正需要的，不是更多 token，而是更强 harness
这也是我现在越来越认同的观点：讨论 1M context 值不值得，不能只盯着模型参数表，而要看它所在的 harness。
一个成熟的 harness 至少应该回答这些问题：
1. Context packing
- 哪些信息必须进当前轮
- 哪些可以只留摘要
- 哪些应该直接丢弃
2. Compression
- 历史轨迹什么时候折叠
- tool output 如何去噪
- 长日志是否转成结构化状态
3. Memory governance
- stable preferences、project state、archive logs 是否分层
- 过时信息是否有显式废弃标记
- recall 是否 narrow 而不是粗暴回灌
4. Tool interface hygiene
- 工具返回是否短、准、结构化
- 是否把冗长自然语言元数据原样塞回上下文
- 是否防止 tool metadata 成为 prompt injection surface
5. Budget awareness
- 单轮 token 预算如何控制
- 长任务如何避免上下文越跑越胖
- 什么时候该摘要、什么时候该重启阶段
这些事情做不好，再大的 context window 都只是看起来很强。
八、为什么“长上下文不可强求”反而是更成熟的工程态度
这里的“不可强求”，不是说 long context 没用，也不是说 1M context 不值得追。
我的意思更接近：不要把它当成万能解法，更不要把它当成产品成熟度的替代品。
工程上更成熟的态度应该是：
- 需要时使用长上下文，但不迷信长上下文
- 优先提升 context quality，而不是盲目放大 context size
- 先解决 compression、selection、memory governance，再追更大窗口
- 把 long context 当作 buffer，而不是兜底垃圾桶
这其实和系统设计里的很多原则一致：
- 更大的磁盘不等于更好的数据管理
- 更大的 cache 不等于更高的命中效率
- 更大的日志保留不等于更强的可观测性
同理，更大的 context window 也不等于更好的 agent intelligence。
结论
从 Gemini 到 Opus，1M context 至少到今天为止，还没有稳定兑现它“应有”的工程价值。
它提供了更大的空间，但空间本身不会自动变成判断力、不会自动变成更优的检索、也不会自动变成更稳的 agent workflow。
真正决定 long context 能不能发挥价值的，不是数字，而是系统：
- context packing 是否克制
- compression 是否足够强
- memory governance 是否分层
- tool output 是否被严格过滤
- harness 是否能控制 token、噪音与 drift
所以如果要用一句话总结我的看法，那就是：
长上下文可以有，但不可强求；真正值得强求的，不是 1M，而是更好的 harness。
