更大的 Context Window 能容纳更多 token，却不保证模型能同样可靠地找到、区分并使用每段资讯。长任务真正的问题常是 Context Rot：旧假设、工具输出与无关内容累积后，高讯号资讯变得更难被正确取用。
「放得下」和「用得好」是两件事
2023 年的原始研究 Lost in the Middle 测试多文件问答与 key-value retrieval，发现相关资讯位于长 context 中间时，模型表现可能显著下降，常在开头或结尾较好；研究也包含明确支援长 context 的模型。Lost in the Middle 论文 这项实验不能证明每个新模型都有同样曲线，但足以否定「只要塞得下，就能等品质使用」的简化假设。
Anthropic 在 2025 年的工程文章使用 Context Rot 一词，描述 token 增加时资讯回忆能力可能下降，并把 context 视为有限的 attention budget。Effective context engineering for AI agents 因此采购模型时只比较 context window 上限，像只看仓库坪数却不看索引、标签与拣货流程。
长任务常见的三种腐化
1. 旧资讯污染
第 10 轮暂定「活跃用户 = 30 天内登入」，第 40 轮已改成「90 天内付费」，但两段都留在 history。若没有明确 artifact 标示最新版，模型可能混用两种定义。
2. 工具输出淹没决策
多次 show tables、schema、查询预览与错误堆叠会快速扩张 context。真正关键的 join key 或使用者核准条件，反而只占短短一句。
3. 对话成为唯一状态
当计划、进度、来源与限制全靠聊天顺序维持，任何截断、fork 或跨日接手都容易失去脉络。更长的 history 只是延后问题，不是解决问题。
四种比「一直加长」更有效的做法
Compaction：压缩轨迹，保留可回查指标
将旧工具结果整理成步骤摘要，但保留 step_id、快取名、SQL 来源或错误代码，必要时再读完整内容。压缩不是删光细节，而是把细节移出每轮必带 context。
Structured artifacts：把决策移出聊天
用 Plan 保存核准口径，用 SQL 保存取数逻辑，用 Report 保存结论与 limitations。Artifacts 有名称、状态和版本，比「往上滑找到那句话」稳定。
On-demand retrieval：需要时再取
每轮只带小型 summary；当任务碰到特定表、Reference 或旧步骤，再透过工具取完整内容。这能降低无关 token，但 retrieval 本身也可能漏抓，因此关键决策仍应结构化并可人工检查。
Memory governance：只保留跨任务仍有效的知识
把「本公司财务季定义」放入经核准 Memory，把「这次尝试过但失败的 SQL」留在执行纪录。两者生命周期不同，不该一起永久注入。
Plan、Reference、Memory 怎么分工
| 资讯 | 应放位置 | 原因 |
|---|---|---|
| 本次分析的分母、时间窗、checkpoint | Plan | 与任务绑定、需审阅 |
| 大型状态码表、栏位映射 | Reference | 按需全文读取，不必每轮塞入 |
| 跨专案稳定规则 | 核准后的 Memory | 可重用，但需治理 |
| SQL 执行结果与错误 | Query steps／evidence | 可回查，不当永久知识 |
| 最终结论与限制 | Report | 形成可交付成果 |
这张分工表的目标，是让 context window 里留下「目前做对下一步所需的资讯」，而不是保存所有曾经发生的事。
Lantide Data 如何处理长分析 Context
Lantide Data 的 Context Engine 每轮提供精简 Summary，完整 schema 与文件由工具按需取得；长对话采 history 截断，单轮多工具则可做 mid-turn compaction。近期查询步骤以精简 ledger 摘要保留，完整 SQL 仍可回到快取来源或步骤纪录查看。相关设计见Context 工程说明与AI Agent 架构的 token 压缩策略。
分析内容则分流到 Plan、Reference、SQL 分页、Report 和已核准 Agent Memory，而不是只依赖聊天。这让长任务跨多轮时仍有外部状态可核对，也让重要 artifact 能被人审阅。
这些机制是风险控制，不是 Context Rot 的「永久解法」。模型、retrieval、摘要都可能遗漏细节；对高风险分析，仍应在 Execute 前审 Plan、在 Report 前核对 evidence，并在 context 接近上限或任务明显转向时开新对话或新 Plan。
结语
Context Window 大有价值，但它是容量规格，不是品质保证。长任务应把聊天视为互动介面，把 Plan、SQL、Reference、Memory 与 Report 当作真正状态；再用 compaction 和按需检索控制每轮讯号密度。先整理 context，再考虑换更大的 window。