编程任务中，模型的上下文窗口开多大最合适?

现在的旗舰模型普遍标称 1M 甚至更大的上下文窗口。一个很自然的想法是把窗口拉满，一次性塞进整个仓库，省得频繁压缩。直觉上窗口越大越省事，压缩越少越省钱。但真的如此吗。本文把 2023 到 2026 年的相关论文、基准和工程博客串起来，回答三个问题。

1. 标称窗口等于有效窗口吗？
2. 压缩阈值和最大输出应该怎么设？
3. 有缓存的前提下，频繁压缩到底贵不贵？

一、标称窗口不等于有效窗口

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 的性能。

五、最终配置建议

以 350K 窗口、70K 最大输出、280K 压缩触发点为基础，补充四条原则。

1. 检查供应商的缓存读单价。低于每百万 token 约 0.55 美元时，频繁压缩省缓存的顾虑基本不存在，可以更从容地晚压缩。
2. 稳定前缀，只在缓存边界之下压缩。系统提示和工具定义固定化，去掉时间戳，压缩只动动态历史区。
3. 优先外置而不是压缩。大输出写文件，长历史移出主上下文，工具输出截断。2026 年的数据证明这些手段比摘要压缩更便宜且不伤缓存。
4. 压缩少次而深，压缩后回贴关键信息。目标是把缓存失效次数降到最低，同时把因摘要丢信息导致的返工降到零。

六、总结

目前最优实践不再是调一个最优窗口或阈值的数字，而是稳定前缀缓存、边界下压缩、外置存储这套组合拳。单纯纠结 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.¹¹⁴⁵⁄_3748302. 链接