长上下文不可强求从 Gemini 到 Opus1M context 为什么还没体现出应有价值摘要过去一年long context 一直是大模型产品最容易被拿来宣传的能力之一。32K 不够就上 128K128K 还不够就上 1M。看起来只要上下文窗口足够大agent 就能记住更多历史、读取更多代码、处理更长文档最终自然变得更强。但真实使用里事情并没有这么简单。无论是 Gemini 系列的超长上下文承诺还是最近围绕 Opus / Claude Code / 1M context 的讨论用户反复遇到的都不是“窗口不够大”而是另一类问题上下文越来越长但收益并没有按比例增长有时甚至更贵、更慢、更不稳定。这背后的核心判断其实很朴素long context 是 capacity不是 intelligence是容器不是方法。如果 context packing、summarization、memory selection、tool filtering 和 harness 设计没有跟上1M context 很可能只是把更多噪音、更多旧状态、更多无关轨迹一起装进去。所以我越来越倾向于一个结论长上下文可以有但不可强求。从 Gemini 到 Opus1M 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 到 Opus1M 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 不够 aggressivesummarization 不够可靠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 没有 selection1M context 只会把更多过时记忆重新注入模型。所以从系统设计上看long context 与 memory 不是互补的捷径而是需要共同治理的两个风险面。七、长上下文真正需要的不是更多 token而是更强 harness这也是我现在越来越认同的观点讨论 1M context 值不值得不能只盯着模型参数表而要看它所在的 harness。一个成熟的 harness 至少应该回答这些问题1. Context packing哪些信息必须进当前轮哪些可以只留摘要哪些应该直接丢弃2. Compression历史轨迹什么时候折叠tool output 如何去噪长日志是否转成结构化状态3. Memory governancestable preferences、project state、archive logs 是否分层过时信息是否有显式废弃标记recall 是否 narrow 而不是粗暴回灌4. Tool interface hygiene工具返回是否短、准、结构化是否把冗长自然语言元数据原样塞回上下文是否防止 tool metadata 成为 prompt injection surface5. 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 到 Opus1M context 至少到今天为止还没有稳定兑现它“应有”的工程价值。它提供了更大的空间但空间本身不会自动变成判断力、不会自动变成更优的检索、也不会自动变成更稳的 agent workflow。真正决定 long context 能不能发挥价值的不是数字而是系统context packing 是否克制compression 是否足够强memory governance 是否分层tool output 是否被严格过滤harness 是否能控制 token、噪音与 drift所以如果要用一句话总结我的看法那就是长上下文可以有但不可强求真正值得强求的不是 1M而是更好的 harness。