聊大模型上下文长度，最容易掉进一个很浮的讨论：谁的数字更大，谁的宣传图更夸张，谁又把 token 数再往上抬了一截。Martin Alderson 这篇文章的好处，是它没停在“100 万 token 听起来很多”这种表面震撼，而是把问题拽回到一个真正影响今天 AI 工程实践的地方：长上下文到底会不会实打实改善 agent 工作流。
这也是我觉得这篇值得进 AideHub 的原因。因为对普通聊天用户来说，1M context 也许只是“能塞更多文档”；但对真的在用 coding agent、research agent、分析型工作流的人来说，它关系的是另一件事：任务能不能在长回路里不失忆、不频繁压缩、不一直把刚才做过的事再读一遍。
Martin 一开头给了个很具体的量级感：按他的经验估算，100 万 token 大概相当于 1000 到 2000 页英文文本，差不多是 4 到 5 本小说。这不是一个单纯拿来炫参数的数字，而是会直接改变长任务工作方式的量级。
如果这个问题解决得足够好，长上下文就不只是参数表上的漂亮数字，而是 agent 可用性的一次明显跃迁。
关键不是 1M 本身
文章里有个判断很对：不是所有 context length 都一样有用。
过去几年，模型上下文窗口确实一路变大了。从 GPT-3.5 那种几千 token，到后来的 128K、200K、再到现在一些模型宣称的 1M，看起来像是线性进步。但真实使用里，大家很快会发现一个更烦的问题：窗口虽然写得大，模型不一定真的能在长上下文里稳定工作。
这就是 Martin 提到的 context rot。上下文一长，模型会开始忘前文、混概念、重复犯错，甚至你能明显感觉到它后半程像在带着一点轻度失忆硬撑。很多人之所以习惯频繁开新会话，本质上不是因为他们爱整洁，而是因为旧会话太长以后质量会开始塌。
他文里还专门提到 Anthropic 拿来展示的一类 benchmark，也就是常说的 “needle in a haystack” 测试。这个测试当然不是完美标准，但它至少在尝试回答一个很实际的问题：上下文窗口拉长以后，模型还能不能把埋在远处的关键信息稳定捞回来。 Martin 真正在意的，就是 1M 的 Claude 在这个问题上是不是终于开始“像真能用”，而不只是“名义上装得下”。
所以 1M context 真正该问的，不是“它装不装得下”，而是“装满以后它还会不会好好干活”。这比单纯比较窗口大小重要得多。
agent 最怕 compaction
如果你用过 coding agent，一定对一个词很熟：compaction。
上下文快满的时候，agent 会把前面的对话、文件、操作过程压缩成摘要，只留下它认为还重要的东西，腾出空间继续干活。这套机制不是没用，很多时候它确实能救命；但它也有一个很明显的问题：压缩从来不是无损的。
你丢掉的，往往不是最显眼的大结论，而是那些特别影响后续判断的细节：
- 为什么之前放弃了某条实现路线
- 某个 bug 的真实复现条件是什么
- 哪些文件已经被改过，改动意图是什么
- 用户早些时候说过的偏好和约束
- 一些没有被正式写进总结、但实际非常关键的语气和判断
这就是 Martin 说得很实在的一点：很多 agent 任务并不是缺“一个总结”，而是缺“完整连续的工作记忆”。一旦进入 compaction，agent 常常先得重新读一堆文件，重新建立场景，结果很快又把上下文吃满。整个过程像一个不断遗忘、不断补课的循环。
对于复杂工程任务，这种来回折返非常伤。不是模型不会写代码，而是它总要花很多力气重新想起自己刚才为什么这么写。
长上下文对 agent 最大的好处，不是一次多塞点资料，而是让它少经历几次“我刚才到底做到哪了”的脑雾时刻。
coding agent 最容易被折腾
文章里有个观察我挺认同：软件任务某种程度上反而比法律合同、投研报告这类材料更适合被摘录和模块化。代码天然结构化，文件边界清楚，搜索和局部重建都比自然语言文档友好。
但这不代表 coding agent 对长上下文不敏感。恰恰相反，它很容易在多文件、多步骤、长链路任务里被 context limit 折腾得效率下降。
比如一个稍大点的重构任务，agent 可能需要同时记住：
- 项目的目录结构
- 几个核心模块之间的调用关系
- 前几轮测试暴露的问题
- 用户说过不能破坏的边界条件
- 已经尝试过但被否掉的实现方案
这些东西单看都不算“巨量文档”，可一旦叠在一起，再加上对话、日志、diff、测试输出，很容易把上下文撑爆。然后 agent 开始 compact，再读文件，再接着 compact。你会感觉它不是在稳定推进任务，而是在反复做短期失忆后的康复训练。
如果 1M context 真能像 Martin 初步体验里那样，在 500K 左右的长会话里仍然保持稳定，那这对 coding agent 的意义其实很大。因为它改进的不是某个 benchmark 分数，而是长任务推进的连续性。
更吃长上下文的场景
虽然 coding agent 是大家最常碰到的例子，但文章里也说得很清楚：有些工作天然更吃完整上下文。
法律合同审阅、财务报告交叉比对、政策与制度对照、研究资料汇总，这些任务的问题不在“找不到材料”，而在过度摘要很容易误伤语义。一份合同里真正决定解释结果的，可能就是几个例外条款、限定语、定义段。把这些压成摘要之后，模型看起来像懂了，实际上已经失去很多判断依据。
这类场景里，长上下文不是锦上添花，而更像一个底层前提。你想让 agent 真正做 cross-reference，就得尽可能让原始材料都留在视野里，而不是只给它压缩版笔记。
所以 1M context 真正打开的，不只是“聊天能放更多附件”，而是一些之前必须靠 RAG、分批处理、人工拆分才能勉强完成的任务，现在可能有更多机会在同一个连续推理空间里完成。
真正关键的是成本
Martin 文章里我最喜欢的一段，反而是讲价格。
因为长上下文如果只是“技术上能做到，但贵到离谱”，那它更多还是 demo 能力，不是日常工作流能力。真正让这次更新更像一件大事的，是 Anthropic 没有继续对超长上下文额外加价。Martin 文里给了一个很具体的对比：Google 和 OpenAI 之前都会在超过 200K 到 272K token 后把输入价格翻倍，而 Anthropic 这次把这层 surcharge 去掉了。
这点特别关键。因为 agent 工作流本来就是一个高 token 消耗场景：
- 会话长
- 工具输出多
- 文件内容多
- 经常还会有子 agent 或并行任务
如果上下文一长，单价也跟着明显跳升，那团队就会很自然地自我阉割使用方式：能摘要就摘要，能切会话就切会话，能少塞就少塞。这样一来，长上下文的理论优势很大一部分会被成本压力吃掉。
所以真正能改变工作流的，从来不只是“窗口更长”，而是“窗口更长之后，你还用得起”。这就是为什么 Martin 会说这可能是今年最有影响力的发布之一。不是因为它最炸眼，而是因为它更有机会进入真实使用。
现在拼的是长任务稳定性
把这篇文章放回现在的 AI 工程语境里看，它其实在提醒一件很现实的事：大模型竞争已经不只是“谁回答更聪明”了，而是在比谁更能撑住长回路工作。
这对 agent 特别重要。因为 agent 的价值本来就不在单轮问答，而在持续推进目标。只要任务跨越多轮、多文件、多状态，稳定记忆就会变成硬通货。
以前很多 agent 体验差，并不是不会调工具，也不是不会写代码，而是做着做着就开始掉上下文。于是人不得不重复说明、重新贴文件、再次强调约束。表面看像模型能力不够，底层很多时候其实是上下文管理能力不够。
如果 1M context 真能在长会话里保持低衰减，那它补上的就是 agent 系统里一个特别硬的短板：不是让 agent 更会想，而是让它更不容易忘。
这件事没那么 flashy，但非常值钱。
这篇文章最该带走的一句话
如果让我把它压缩成一句话，我会说：1M context 的真正意义，不是让模型一次读更多页，而是让 agent 在长任务里少失忆、少压缩、少反复回头补课。
窗口变大本身不稀奇，真正稀奇的是窗口变大之后，质量别掉、价格别爆、工作流真的因此更顺。Martin 这篇文章的价值，就在于它把这三个判断标准摆到了一起。
所以这不是单纯的参数更新新闻。对正在认真使用 coding agents 和长链路 AI 工作流的人来说，这更像是一个很实际的问题：我们离“能一路做到底的 agent”是不是又近了一步。
参考
- Why Claude’s new 1M context length is a big deal — Martin Alderson
- Understanding LLM Tokenization — ChristopherGS