依赖项更新何时应调用修复代理？轻量级路由研究

依赖项更新拉取请求很频繁，而且大多是例行公事，但一小部分需要进行重要的兼容性修复。最近的存储库级编码代理使此类修复变得越来越可行，但在每次依赖项更新时调用它们会浪费模型调用、CI 时间、存储库上下文和审查注意力。我们将此视为预代理路由问题：决定在下游诊断或修复尝试之前应升级哪些依赖项更新拉取请求。我们引入了 DepFixRouter，这是一个轻量级路由器，它使用创建时文本和元数据信号根据历史兼容性修复可能性对依赖项更新进行排名。在 497 个标记为 GitHub 依赖项更新的候选者中，只有 72 个需要实质性修复。仅使用 PR 标题和机器人/依赖项标志的创建时安全的 LinearSVC 达到 0.488 修复 F1，并捕获前 20% 路由拉取请求中的 51.4% 的修复，将每次捕获修复的调用从全部路由或随机策略下的 6.90 提高到 2.68。回顾性完整历史信号将前 20% 的召回率提高到 65.3%，揭示了拉取请求历史中的大量后见之明泄漏，而不是部署时路由实用程序。在 60 个案例诊断代理试点中，路由器门控诊断将实际 LLM 调用减少了 66.7%，词元减少了 66.1%，这表明在衡量诊断而不是补丁生成时要进行预算意识升级。 DepFixRouter 可以充当例行依赖项更新自动化和昂贵的存储库级代理之间的轻量级升级层，从而实现预算意识维护，而无需依赖部署时路由的回顾性修复证据。