给 AI 编程工具喂上下文有什么讲究？为什么整仓塞进去反而更差？

上下文窗口虽然大，但模型的注意力是有限的，塞得越多、无关内容越多，它越容易被干扰，这就是常说的 context rot——不是线性变笨，而是在某些位置上失效。所以我一般不整仓贴，而是给相关的几个文件，加上一段说明。另外整仓贴的 token 成本也很高，每轮都要重发。

到这一步是及格：说清了「容量 ≠ 有效」，也说清了成本。但它是一段常识陈述，没有可验证的东西，任何读过两篇博客的人都能说。

90 分要在四个地方长出细节：有数字、分了层、讲了检索路线、护住了缓存。

第一，这件事在编程场景已经有硬数字了。 2026 年的一项评测覆盖 1476 个真实修复任务、51 个仓库、9 种语言，结论很反直觉：给模型一份平均 217 token 的精炼摘要，解决率从 26.26% 升到 34.34%；给它平均 25,633 token 的完整探索轨迹，只有 27.27%；让它不受限地自由检索，26.26%——等于没提升，成本还多花 27.3%。另一项工作从反面印证：把 agent 会话的 token 剪掉 23%–38%，解决率掉不到 1 个百分点，成本降了约 27%，而且读取类操作占了 agent 总 token 的 76%。所以「整仓塞进去更差」不是感觉，是一百倍 token 换负收益。

第二，我把上下文分四层来管，因为它们的变化速度不一样：系统提示与工具定义（几乎不变）→ 项目规则文件（周级变化）→ 本次任务取回的内容（每次都变）→ 对话历史（单调增长）。真正能调控的是第三层，但优化的关键动作是把关键事实从第三层上提到第二层。举个具体的：我们仓里有新旧两套支付回调 handler，长得几乎一样，代码里没有任何一行写着哪个在跑；靠模型每次自己推断就是在掷骰子，把「V2 才是在跑的那个、V1 只在灰度 0% 兜底」写进规则文件，问题就消失了。规则文件是用来放推不出来的事实的，不是用来放读一眼代码就知道的事实的。

第三，大仓里怎么找。 两条路线：预先做全仓 embedding 索引，或者让模型自己 grep、读文件、顺引用爬。要注意的是两边争的根本不是同一个指标——索引派讲召回率（有厂商公布语义检索比纯 grep 的问答准确率平均高 12.5%，千文件以上大仓的代码留存率高 2.6%），代理派讲新鲜度（embedding 流水线跟不上活跃团队的提交，开发者查到的是几小时甚至几周前的快照）。而且没有第三方在同一 benchmark 上做过公开对照，所以谁也没证伪谁。实践里两条路线已经在合流：代理派在做更快的 grep 原语，索引派配了只回摘要的探索子 agent。

第四，别把缓存打穿。 编程 agent 每轮都在重发同一个巨大前缀，命中率不是省钱技巧、是成本结构本身。原则是静态在前、动态在后。