一个很反常的体验是：模型明明还在同一个会话里，前面也都“看过”，但写代码时开始漏约束、误读目标、重复走弯路。

Garrit's Notes 提醒的就是这件事：200K、1M、2M tokens 的大上下文窗口，不该被当成稳定工作区。标称容量是真的，但有效工作集是另一回事。

我更在意的是，这个问题最先伤到的不是偶尔问答的用户，而是每天把编码 Agent 当同事用的人。会话管理，正在变成 Agent 工作流的硬成本。

大窗口不等于有效上下文

作者用了一个很直观的比喻：上下文里有 smart zone，也有 dumb zone。

smart zone 里，模型还能抓住任务目标、约束和文件关系。进入 dumb zone 后，它不是立刻坏掉，而是慢慢变钝：漏掉刚说过的要求，忽略关键 diff，或者把已经排除的方案又拿回来。

作者观察到的经验分界，大约在 100K tokens 附近。这个数不能当硬阈值。不同模型、任务、提示方式都会影响结果。

但方向是清楚的：上下文越满，稳定性越难保证。

RULER 和 Chroma 关于 context rot 的研究，也给了类似依据。有效上下文通常小于标称窗口，性能会随填充增加逐步下降。它更像“腐蚀”，不是到某个点才突然断电。

你看到的卖点实际要问的问题
200K、1M、2M tokens多少内容能被稳定调用
长会话不断档后半段是否还守得住约束
自动摘要、auto-compact摘要发生得是否足够早，质量是否可靠
Agent 能读更多文件读进去的是高信号信息，还是日志和噪音

这不是说厂商的大窗口宣传是假的。容量是产品能力，稳定有效工作集是工程能力。两者不能混着看。

对团队采购和工具选型来说，这意味着一个现实动作：不要只看窗口参数。试用时要看长任务后半程的表现，尤其是跨文件修改、测试修复、需求变更之后，Agent 还能不能守住原始目标。

编码 Agent 会很快把会话拖进低效区

聊天问答消耗 token 通常还算可控。编码 Agent 不一样。

它会读仓库文件，追调用链，跑命令，贴测试日志，看报错栈，再生成 patch diff。一次调试循环下来，上下文里很容易混进大量低信号材料。

这些材料单独看都有用，堆在一起就会变成泥沙俱下。

Claude Code 的 auto-compact 是一个有用补丁。会话过长时，它会自动压缩历史，让后续上下文变轻。这至少承认了一件事：上下文不是免费资源。

但它有两个限制。

一是压缩常常发生得偏晚。等系统触发时，会话可能已经进入低效区。二是摘要本身也依赖模型生成。如果模型已经开始漏重点，摘要就可能把该保留的约束压掉。

Cursor、GitHub Copilot 类工具也会遇到类似取舍：让模型多看一点，还是让人提前把任务切干净。前者容易做成参数，后者更像流程纪律。可真正影响交付质量的，往往是后者。

受影响最直接的是两类人。

一类是高频用编码 Agent 的开发者。更实际的做法是，遇到任务目标变化、测试方向变化、日志堆太多时，主动开新会话，而不是继续往旧会话里塞。

另一类是设计 Agent 工作流的团队。要把“什么时候新开会话、哪些内容能进上下文、交接文档写到什么粒度”写进规范。否则，大窗口会诱导团队把 Agent 当长期记忆库，最后得到一个更贵、更慢、更不稳的助手。

更可靠的是 breadcrumb，而不是长会话

作者推荐的 breadcrumb 方法，我认为是这篇笔记里最有操作价值的部分。

核心不是让模型记住一切，而是人为留下小型、清晰、可交接的 artifacts。下一个会话只读高信号材料，不翻完整聊天记录。

可以这样落地：

场景不建议继续塞什么更建议留下什么
需求变了旧讨论、旧方案、长解释一页 spec 或 PRD
调试跑偏大段日志、重复报错、失败尝试当前假设、已排除路径、下一步 plan
多文件修改全量 diff 和历史对话文件清单、改动意图、约束条件
交给新 Agent整个旧会话sub-agent handoff、skills、检查清单

这里的重点是“人工写”。

自动摘要可以帮忙，但不能完全托付。人写 spec、plan、handoff，看起来慢一点，实际是在把噪音挡在会话外面。

一个可执行的规则是：当会话开始反复解释同一约束，或者 Agent 开始忘记刚确认过的方向，就不要再赌它能自己拉回来。开新会话，把任务压成一份短 spec，再继续。

接下来最该看两件事。

一是模型在长上下文任务里的稳定性是否真的改善，而不只是窗口数字变大。二是 Agent 产品能不能把 spec、计划文档、自动压缩和交接机制做成默认工作流。

如果这两点没有跟上，大窗口只是把问题推迟。会话越长，越像一间没人整理的仓库：东西都在，但要用时找不到。