Code Change Control

使用编码代理的工程团队需要在长流程运行前设置成本门槛，并在反复查看和编辑文件时强制停止。证据已经不再只是对昂贵代理的含糊抱怨。在 OpenHands 的 SWE-bench Verified 上，agentic coding 的 token 消耗大约是单轮代码推理的 3500 倍，是多轮代码聊天的 1200 倍；同一任务的不同运行之间，差距最高可达 30 倍。论文把最差的失败归因于重复搜索行为，尤其是反复访问文件和编辑，并且显示模型在开始前很难预测自己的 token 账单。

一个可行的方案是做一个面向仓库的预算控制器，实时观察行动轨迹，在代理开始反复试探时把运行切成更小的范围。控制点很直接：统计文件打开次数、回访次数、编辑回退次数和上下文增长；一旦这些计数超过阈值，就要求更窄的子任务或人工批准。已经为自动修复 bug 或实现功能付费的团队会最先关心这个，因为他们要承担失败轨迹的成本，而且通常拿不到可靠的事前估算。

一个低成本测试是回放过去的代理轨迹，测量在重复文件抖动后提前停止，能在不降低通过率的情况下减少多少 token 消耗。如果这个控制器主要拦住的是失败和后期游走，它就值得作为编码代理产品里的默认保护措施。

仓库级生成流程在项目超过大约 1000 行代码后，应该把规划和实现分开。RealBench 显示，即使给了自然语言需求和 UML 包图、类图，当前模型在完整仓库上还是表现不稳。最高平均 Pass@1 只有 19.39%，500 行以下的表现超过 40%，2000 行以上低于 15%；平均来看，只有 44.73% 的方法是独立的。在最大的仓库里，独立方法降到 26.23%，说明依赖处理是主要失败来源。

具体的流程改动很明确：不要再让模型一次性输出中大型代码库的全部内容。先让模型根据设计工件梳理模块、接口和依赖边，再按步骤增量生成文件，并在每一步后跑测试。RealBench 自己的对比也支持这一点：完整仓库生成更适合较小仓库，而仓库变大后，增量生成更好。

一个低成本检查是找一个已经有架构说明或图的内部需求，分别跑两种方式：一次性全仓库生成，和按依赖顺序生成文件。比较测试通过率、破损导入数量和人工修复时间。做内部脚手架、SDK 或 CRUD 密集型服务的团队，可以在不更换整个工具链的情况下试这个。

需求追踪现在可以支撑一个更窄的维护工具，用来把变更后的需求链接到最可能受影响的文件、类或方法，同时把上下文控制在日常开发可用的范围内。R2Code 在五个数据集上比强基线平均提高 7.4% 的 F1，并通过自适应上下文控制把 token 使用最多降低 41.7%。这个机制对产品设计有直接影响：它把需求和代码拆成对齐的语义部分，检查每个候选链接的解释，并根据需求复杂度调整检索深度。

这支持一个具体的产品形态，适合有过期工单、文档薄弱或受监管变更评审的团队：在 pull request 旁边放一个侧车，输入需求 ID，给出代码链接，展示每个链接的解释，并把一致性低的匹配标出来供复核。这比宽泛的代码聊天更适合影响分析或审计准备，因为用户需要的是一条紧凑、并且绑定到具体工件的证据链。

一个低成本检查是从某个服务里抽取已经关闭的工单，隐藏已知修改过的文件，再把工具给出的 top-k 链接建议和真实实现 diff 对比。如果这些链接准确到足以缩短维护人员的搜索时间，这一层追踪能力就值得在更宽的代理流程之前先上。