先记住这个答案
当仓库代码超出上下文窗口，Agent 应把预算当作稀缺资源分层分配。第一层是任务描述与当前待改文件的完整原文，这是生成正确补丁的前提，不可压缩。第二层是依赖的接口签名、类型定义和与改动直接相关的测试，可用签名级摘要而非全文。第三层是历史 diff、相邻模块，只保留结论性摘要或检索指针。取舍原则是：凡直接影响编辑正确性的内容保全文，其余降级为摘要，并保留按需重新拉取的通道。
- 任务契约与待改文件原文不可压缩
- 接口与测试用签名级摘要替代全文
- 历史 diff 只留摘要并保留重取通道
- 预算按决策价值密度而非文件大小分配
按决策价值密度分层取舍的机制
分配预算时不是按文件大小或字母序截取，而是问一个操作性问题：丢掉这段内容会不会改变我要生成的补丁。任务描述决定改什么，待改文件原文决定补丁的上下文行与缩进，二者任何压缩都会直接制造错误，因此必须全文保留，通常占预算一半以上。接口定义和类型签名决定调用是否正确，但函数体实现通常无关，可只保留签名、docstring 和抛出条件，压缩率可达数倍。
测试的取舍更细：与本次改动路径直接命中的测试保全文，尤其断言部分；外围测试只保留用例名和覆盖的行为描述。历史 diff 价值最低且体积膨胀快，正确做法是用工具把多次提交浓缩为「某函数在哪次改动中为何调整」的一句话摘要，并记录 commit id 作为回查指针。关键在于所有被压缩的内容都要可通过检索工具重新拉取全文，压缩是索引而非丢弃。
修复支付服务跨文件 bug 的预算分配实例
假设一个具体场景：8k token 预算，修复一个退款金额计算错误的 bug，涉及 refund.ts（600 行）、其依赖的 pricing.ts 接口、两个测试文件和近期五次相关提交。预期分配结果是：任务描述与 refund.ts 全文约 3500 token；pricing.ts 只取三个被调用函数的签名与返回类型约 400 token；直接命中的 refund.test.ts 保留断言部分约 1200 token；另一个外围测试只留用例名列表约 150 token；五次提交压缩为三条摘要加 commit id 约 300 token。
剩余约 2400 token 留给模型推理与补丁输出。预期 Agent 生成的补丁能通过目标测试。若改为按文件顺序截断，比如先塞满 pricing.ts 全文，很可能把 refund.ts 尾部截掉，补丁的上下文行对不上实际文件，可能直接导致应用失败。这个对比说明预算分配的本质是保住「编辑正确性链条」，而不是均匀照顾每个文件。
分层压缩失效的条件与应对
该机制在两类条件下失效。其一，摘要丢失关键语义：接口签名看不出副作用，例如 calculatePrice 内部会写缓存，而 bug 恰由缓存引起，签名级摘要就会误导排查方向。其二，压缩判断本身依赖对依赖图的正确理解，若静态分析漏掉了动态导入或反射调用，被判定为无关而压缩掉的文件恰恰是问题根源，Agent 会在错误位置反复修改。
应对手段是给压缩留「后悔药」：每份摘要必须携带可回查的指针（文件路径加行区间或 commit id），并允许 Agent 在发现信息不足时主动发起检索把摘要升级为全文，代价是多一轮工具调用的延迟。另一个边界是预算极度紧张（如 4k 以下）时连待改文件全文都放不下，此时应改为按函数粒度切分文件、分批处理，而不是全文压缩，否则补丁上下文行无法定位。
容易答错的地方
- 按文件顺序或大小均匀截断
- 均匀截断会把最关键文件的尾部切掉，而补丁生成依赖完整的上下文行与缩进。正确做法是按决策价值密度分层，保住任务描述与待改文件全文，宁可整文件舍弃外围内容。
- 压缩后就丢弃原文
- 把历史 diff 或外围文件压缩成摘要后不留回查指针，摘要一旦遗漏关键语义就无法补救。摘要必须附带路径、行区间或 commit id，让 Agent 能在信息不足时把摘要升级回全文。
面试官还会怎么问？
测试很多时如何在预算内取舍测试内容？
只保留被改动代码路径直接命中的测试，且优先保留断言与夹具构造，外围测试降级为用例名加行为描述。失败日志出现时再按需拉取对应测试全文，避免预先占用预算。
历史 diff 摘要应该包含哪些字段？
每次提交浓缩为一行：改动了哪个符号、为何调整、commit id。丢弃具体代码行，因为旧代码通常与当前文件已不同步，塞入全文反而造成过期上下文误导。
Agent 如何发现当前上下文不够用？
通过显式信号判断：接口签名无法回答调用疑问、测试断言引用了未见过的符号、补丁上下文行定位失败。此时应触发检索工具把摘要升级为全文，而不是凭现有信息强行猜测。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。