现在的旗舰模型普遍标称 1M 甚至更大的上下文窗口。一个很自然的想法是把窗口拉满，一次性塞进整个仓库，省得频繁压缩。直觉上窗口越大越省事，压缩越少越省钱。但真的如此吗。本文把 2023 到 2026 年的相关论文、基准和工程博客串起来，回答三个问题。
- 标称窗口等于有效窗口吗？
- 压缩阈值和最大输出应该怎么设？
- 有缓存的前提下，频繁压缩到底贵不贵？
一、标称窗口不等于有效窗口
Lost in the Middle
Liu 等人在 2023 年的奠基性工作发现，模型对上下文开头和结尾的信息利用最好，中间位置的信息检索准确率会下降三成以上，有时还不如干脆不给这份文档。窗口越大，中间被浪费的区域就越大，所以拉满 1M 反而让有效信息占比更低。
LongCodeBench 给出的编程任务拐点
2025 年的 LongCodeBench 是目前最直接的编程长上下文基准。它在真实 GitHub issue 的代码理解和修复任务上测出一组很扎眼的数据。多数模型的准确率峰值落在 64K 到 128K 之间，之后单调下降。Claude 3.5 Sonnet 在 LongSWE Bench 上从 32K 的 29 分跌到 256K 的 3 分。Qwen2.5 从 512K 的 70.2 分跌到 1M 的 40 分。
换句话说，1M 窗口的模型真正干活的区间就在 32K 到 256K 之间。
有效上下文和标称上下文的差距
NVIDIA 的 RULER 基准专门测声称长度和有效长度之间的差距，方法论是跑一条长度扫描曲线，找到准确率跌破阈值的拐点，那个拐点才是可用窗口。NoLiMa 把字面匹配线索去掉以后更狠，GPT 4o 从 1K 的 99.3 分跌到 32K 的 69.7 分。工程博客把这类现象统称为上下文腐烂，也就是 context rot ，意思是上下文装得越满，模型表现越差。
arXiv 2512.02445 发现标称 1M 到 2M 窗口的模型在 100K 处能力就严重退化，良性任务掉幅超过五成。
LocoBench 和 LocoBench Agent 在 2025 年下半年提出，作者指出既有代码长上下文基准只测理解和补全，多会话开发、跨文件重构、架构一致性这类真实工程场景基本没被覆盖。AgencyBench 把评测推到 1M token 真实场景，Letta 的 Context Bench 用 1000 轮任务链暴露短会话测不出的记忆失效。选型时可以用这类基准验证某个模型在目标长度上到底还行不行。
二、配置怎么设
工作窗口
综合所有基准数据，对 1M 标称窗口的模型，工作窗口设在标称值的四分之一到一半比较稳妥，也就是 250K 到 500K 之间。但注意 LongCodeBench 显示多数模型 256K 以后编程能力已经崩了，所以更保守的取值是 256K 上下。本次调研最终落在 350K ，是一个偏宽松但仍有余量的选择。
最大输出
单轮编程输出一般是补丁、单个文件、一段重构代码再加工具调用参数。普通补丁占 2K 到 8K ，大型源文件或批量修改占 8K 到 16K 。超过 32K 的单轮输出在实践中几乎都是失控重复。因此建议 32K ，极限 64K 。输出上限还充当保险丝，模型一旦开始无意义复读，会在上限处被截断，而不是烧掉整段预算。
压缩触发点
主流编程工具的做法是从窗口里扣除最大输出作为缓冲，即压缩阈值等于窗口减去最大输出。以 350K 窗口配 70K 输出为例，280K 开始压缩，此时任何一轮的上下文加输出都不会超窗，永远不会硬截断。这是 Claude Code 系工具的标准做法，逻辑自洽且安全。
两个保留意见。其一，280K 的触发点偏深，多数模型的编程能力在 256K 后已明显退化，280K 触发意味着允许上下文在退化区间里跑较长一段，若工具支持可往 245K 到 260K 收。其二，压缩本身会引入漂移，2026 年的研究指出递归摘要是漂移的机制，所以压缩要少次而深，压缩后把关键文件和未完成事项原文回贴。
三、频繁压缩到底贵不贵
缓存机制决定了成本结构
主流 API 的 prompt caching 大致是缓存命中部分按约一成的价格计费，未命中部分全价。压缩一旦发生，摘要后的新上下文对不上旧缓存，下一轮请求必然缓存失效，一次全价的 280K 输入。一次压缩的代价大约是普通轮次的十倍以上。这就是频繁压缩费 token 的真相，费的不是摘要那几千 token ，而是缓存失效的那几轮。
但拉大窗口也有隐性成本
窗口拉大以后每轮都在退化区间里运行，错误率上升。SWE Effi 提出过 token snowball 效应，上下文越长，推理质量下降、无效轨迹越多，产出更多需要重试的轮次。返工一轮的代价是全价输入加输出，比一次计划内的压缩贵得多。
真实的成本曲线是这样的。压缩太少导致质量衰减，然后返工，最贵。压缩适中，偶尔全价重建，中等。压缩太频繁，频繁全价重建，偏贵。最低点在中间，而不是越靠近少压缩越好。
一些有趣的实验
Louis Bouchard 在 2026 年 8 月的工程博客记录了一组生产环境实验。他们用 414 轮乘以 3 次的规模对比后发现，把工具输出直接截断能降本 38 且缓存命中率几乎不变，而引入模型调用的摘要压缩在每种配置下都让账单更贵，比全量历史贵约五成。结论是缩小上下文而不是重写上下文。他们还给出一条可操作的判据，只要缓存读价低于每百万 token 约 0.55 美元，保留全量历史就比压缩便宜。
TokenPilot 在 arXiv 2606.17016 里指出，前缀里任何变动的字节，比如目录路径、时间戳、工具 schema 抖动，都会打碎缓存。用静态占位符替换动态字段后，缓存命中率从 38.7 升到 79.2 ，成本从 8.31 美元降到 4.35 美元。
veso.ai 在 2026 年 5 月的工程梳理给出三条规则。缓存和压缩天然冲突，每次 compact 都让旧缓存失效。只压缩缓存边界之下的内容，永远不要穿透缓存边界压缩。系统提示里的分钟级时间戳会每轮打碎前缀，改成日期级或用工具读时钟。
四、研究的新方向，外置而不是压缩
剪枝与准入控制
SWE Pruner 在 arXiv 2601.16746 里针对 coding agent 的 context wall 问题做任务感知的行级剪枝，在 SWE Bench Verified 上实现 39 的 token 削减，交互轮数最多减少 26 。LaMR 是它的改进版，指出单目标剪枝会误删强模型需要的结构行，导致 Opus 4.6 上部分设置反而增加最多 22 的 token 消耗，多维度评分后多轮任务再省 7 到 14 。教训是剪枝器和底座模型强度要匹配。
A MAC 在 arXiv 2603.04549 把信息准入形式化为一个决策，用未来效用、事实置信度、语义新颖度、时间新近度、内容类型先验五个因子打分，结果是存得更少但更刻意，agent 反而更快更准。
Self Compacting Language Model Agents 在 arXiv 2606.23525 让模型自己根据评分量规决定何时压缩、压什么，替代固定间隔压缩，该压才压。
把上下文请出窗口
Coding Agents are Effective Long Context Processors 在 arXiv 2603.20432 提出一个很适合编程场景的思路。与其把几百万 token 塞进上下文，不如让 agent 把长文本组织成文件系统，用原生工具去处理，在含 3 万亿 token 的语料上比已发表方法平均高 17.3 。
对实际配置的启示很直接。大文件和长日志不要贴进上下文，写成文件让 agent 用 grep 和 sed 去读。不占窗口，不触发压缩，还天然缓存友好。
记忆治理
2026 年还有一小簇记忆治理论文。When to Forget 把遗忘作为治理原语。Novel Memory Forgetting Techniques 指出无控累积会让性能从 0.455 衰减到 0.05 ，假记忆率达到 6.8 。Meta Cognitive Memory Policy Optimization 锁定递归摘要是漂移的机制，用信念熵优化记忆策略，在 1.75M token 上下文保持 97.1 的性能。
五、最终配置建议
对编程任务而言，1M 模型推荐设置最大上下文窗口为 350K 、70K 最大输出、280K 压缩触发点，补充四条原则。
- 检查供应商的缓存读单价。低于每百万 token 约 0.55 美元时，频繁压缩省缓存的顾虑基本不存在，可以更从容地晚压缩。
- 稳定前缀，只在缓存边界之下压缩。系统提示和工具定义固定化，去掉时间戳，压缩只动动态历史区。
- 优先外置而不是压缩。大输出写文件，长历史移出主上下文，工具输出截断。2026 年的数据证明这些手段比摘要压缩更便宜且不伤缓存。
- 压缩少次而深，压缩后回贴关键信息。目标是把缓存失效次数降到最低，同时把因摘要丢信息导致的返工降到零。
六、总结
目前最优实践不再是调一个最优窗口或阈值的数字，而是稳定前缀缓存、边界下压缩、外置存储这套组合拳。单纯纠结 350K 还是 300K 的边际收益，远小于把这三件事做好。
主要参考文献
[1] Liu N F, Lin K, Hewitt J, et al. Lost in the Middle: How Language Models Use Long Contexts[J]. Transactions of the Association for Computational Linguistics, 2024, 12. 链接
[2] Hsieh C P, Sun S, Kriman S, et al. RULER: What's the Real Context Size of Your Long-Context Language Models?[EB/OL]. arXiv 2404.06654, 2024. 链接
[3] Rando J, Trinh T, Sengupta N, et al. LongCodeBench: Long-Context Evaluation Beyond Code Generation[EB/OL]. arXiv 2505.07897, 2025. 链接
[4] LocoBench: A Benchmark for Long-Context Software Engineering Tasks[EB/OL]. arXiv 2509.09614, 2025. 链接
[5] LocoBench-Agent: Long-Context Benchmarking for Real-World Complex Software Engineering[EB/OL]. arXiv 2511.13998, 2025. 链接
[6] Safety and Capability Degradation in Long-Context LLM Agents[EB/OL]. arXiv 2512.02445, 2025. 链接
[7] Optimizing Context Compression for Long-horizon LLM Agents[EB/OL]. arXiv 2510.00615, 2025. 链接
[8] SWE-Pruner: Adaptive Context Pruning for Coding Agents[EB/OL]. arXiv 2601.16746, 2026. 链接
[9] LaMR: Multi-dimensional Line-level Context Pruning for Coding Agents[EB/OL]. arXiv 2605.15315, 2026. 链接
[10] A-MAC: Adaptive Memory Admission Control for LLM Agents[EB/OL]. arXiv 2603.04549, 2026. 链接
[11] Meta-Cognitive Memory Policy Optimization for Long-Horizon LLM Agents[EB/OL]. arXiv 2605.30159, 2026. 链接
[12] TokenPilot: Cache-Efficient Context Management for LLM Agents[EB/OL]. arXiv 2606.17016, 2026. 链接
[13] Coding Agents are Effective Long-Context Processors[EB/OL]. arXiv 2603.20432, 2026. 链接
[14] Self-Compacting Language Model Agents[EB/OL]. arXiv 2606.23525, 2026. 链接
[15] Bouchard L. Why We Stopped Compacting Our Agent's Context[A/OL]. 2026-08. 链接
[16] veso.ai. Context Caching vs Compaction for AI Agents[A/OL]. 2026-05. 链接
[17] A Survey on the Memory Mechanism of Large Language Model-based Agents[J/OL]. ACM Transactions on Information Systems, 2025. DOI 10.1145/3748302. 链接
Select Language