很多人都遇到过这种情况：一个编程代理没能完成你确信它能完成的任务。面对这种质量忽好忽坏的怪象，我们往往懒得深究，只是随口归结为AI的“非确定性”本质。但你可能没意识到，代理失败的原因不在智能不足，而在它的上下文空间已经被噪声挤占得一塌糊涂。

解决路径需要从一味地最大化上下文，转向确定性的剪枝。你需要建立清晰的边界，让代理只看见该看见的东西——而不是整个仓库。下面是你将会在深度剖析中得到的关键线索：为什么把整个代码库都喂给代理会直接导致推理失灵；如何在棕地代码中隔离子系统，让代理只处理局部；怎样在启动一次代理运行前，动态地掩盖掉那些死代码；一个可靠剪枝框架到底需要哪些核心要素；以及不受限制的上下文怎样把PR吹成气球，再耗尽评审者的耐心。

打开网易新闻 查看精彩图片

计算机体系结构中有一个概念叫“抖动”，指的是一个运行中的进程需要的内存超出了缓存容量，处理器便不再执行有用指令，而把所有资源都花在从内存和RAM之间来回交换页面。编程代理的提示窗口也存在类似瓶颈。面对棕地开发，你可能会忍不住把整座遗留代码山都倒进上下文，然后直接发令“把这个项目重构到Next.js”。但一旦你这么做了，代理就很容易把过时的代码和旧库的用法当成当前真实的设计意图。上下文中一旦有效信息被稀释到这种程度，推理的准确性就会遭到主动侵蚀——这就是我们所说的上下文破产。

一些开发者把完整仓库的拉取视为前沿模型大上下文窗口的招牌功能。他们默认全面的可见性等于深刻的理解。但事实并非如此。在清爽的绿地项目中，大范围上下文摄入可能还能运转；可换作数百万行的遗留代码库，大范围摄入反而急剧削弱代理的推理能力。大多数人并不在绿地应用上工作，更多时候接手的是混乱、文档匮乏的遗留代码——里面常常埋着叫“v1-alpha”的文件夹、已完全不可用的临时辅助脚本，或者孤零零的特性开关。当代理通过天真的RAG检索或超大上下文窗口把这些数据一股脑扫进视野时，它会把那些过期模式当成当前的工程真理去对待。

驱动这一失败的规则，就是把海勒姆定律搬到AI上下文窗口时的模态：当获取信息的广度够大，每一个可观测到的历史实现细节，最终都会被一个自主模型当成可靠的依赖。给代理开放1000个文件，它就会围绕你最狡猾的临时补丁进行推理。它把存放过时的辅助脚本视作锚点，然后把那些技术债务一点不剩地复制进新模块里。

因此，我们需要一种有选择的忽略，并以此强制构筑边界。而不只是无止境地往里塞文件。在审视一个遗留单体时，真正重要的不是把一切交给上下文，而是先决定代理不该看见什么。