三份上下文清单，管住长寿命分支上的编码代理开销

01 · 分支持续数周，不等于会话也要持续数周

长寿命分支会积累需求修订、失败尝试、合并记录和测试输出。把这些内容全部留给编码代理，看似省去交接，实际却让过期判断与当前约束争夺注意力。对持续运行大量任务的团队，问题不只是单次调用变贵，更是错误背景被反复读取、执行和放大。

团队负责人应把分支当作工作载体，把上下文当作有预算的临时工作集。历史可以完整保存，但每次执行只应加载与当前任务有关、能够验证的信息。上下文窗口装得下，不代表内容就值得留下。

02 · 用三份清单替代不断变长的聊天记录

• › 稳定规则清单：记录架构边界、编码约定、测试入口和权限限制。保持短小，纳入版本管理；仅在规则真正变化时修改。
• › 分支状态清单：注明当前提交、合并基点、已完成改动、已知缺陷与待决事项。结论必须对应代码位置或测试结果，不能只写“已经处理”。
• › 当前任务清单：只列本轮目标、允许修改的范围、验收条件和停止条件。任务结束后归档，不让旧目标继续影响新任务。

加载顺序尽量固定：稳定规则在前，分支状态居中，当前任务与必要片段在后。先给文件索引，再按需读取实现；不要把整份日志、整个目录或所有历史讨论一次塞入。

03 · 把重新交接设为事件，而不是等窗口耗尽

完成一个可验收子任务、合入主线、改变实现路线，或连续尝试仍无进展时，都适合结束旧会话。让代理先提交交接摘要，再由新会话读取清单与实际差异，而不是自动继承全部聊天。

摘要至少区分已验证事实、尚未验证的推断和下一步动作，并注明对应提交与未提交改动。失败尝试只保留方法、失败原因及适用条件，不复制整段工具输出。重新开始前，检查工作区、差异和关键测试，防止压缩摘要把猜测变成事实。

04 · 缓存降低重复成本，但不能修复过期背景

稳定前缀有助于缓存复用，但是否命中取决于具体模型、接口和缓存机制。频繁改写规则、调整前缀顺序或在开头插入动态日志，都可能影响复用。更重要的是，过期内容即使命中缓存，仍可能误导代理。

对重负载团队，本专栏所属的按量接口中转平台适合用于统一管理多模型余额，并观察真实令牌消耗；缓存写入与缓存读取分别计价，核算时应分开看，而不能只比较调用次数。可开通账户，先选择一条活跃分支验证清单与交接流程，再决定扩大使用范围。

05 · 按验收任务核算预算，不奖励单次调用便宜

为每个任务记录输入、输出、缓存写入、缓存读取、重试次数和验收结果。分别设置任务预算与分支累计预算；达到阈值就暂停，要求更新状态清单或人工确认，而不是让代理自行追加尝试。

不同模型承担不同阶段时，也应使用同一套清单，但重新核对工具权限与输出约定。不要假定更换模型后，旧会话中的隐含前提仍然成立。

最终要比较的是每个验收通过任务的总消耗。同时观察返工、越界修改和交接后重复探索的情况。先在小范围试行，再逐步推广：让每轮代理知道自己该读什么、该做什么，以及何时必须停下来。