RepoCompass

问题

修复代码之前，Agent 需要先确定问题发生在哪里。对大型仓库进行反复搜索会消耗上下文和推理预算；提前结束检索又可能漏掉相关文件或函数。

RepoCompass 将这一阶段独立为代码定位任务：输入 Issue 与对应仓库状态，输出结构化的文件和函数位置，供下游修复 Agent 使用。

环境与奖励

任务按 Commit / Patch 隔离物化为 Unix 多轮环境。Agent 可以使用 Terminal 探索仓库，并通过结构化 Finish 工具提交定位结果。

奖励围绕文件和函数两级 F1 构造，同时检查 Finish 的合法性。目标是让探索过程能够接受任务结果的反馈，而不仅仅学习一段固定的搜索示范。

数据与训练

围绕 Qwen3-4B 自生成搜索轨迹，以输出合法性、定位质量和轨迹质量筛选 RFT 数据，并探索 RFT → GSPO 与纯 GSPO 两条路线。

任务分层考虑仓库、定位复杂度与可探索性。重复检索、过早 Finish 和函数漏召回等现象，用于调整单文件、多文件、单函数和多函数任务的配比。

工程工作

同一道题的多个 rollout 会重复准备仓库、传输长历史，并执行策略前向。针对这些成本，项目实现了：

• 节点级 Git Bare Mirror 缓存与共享对象的隔离 checkout，减少重复准备。
• 裁剪中间轮次的重复 prompt，并异步保存轨迹。
• 在单步 GSPO 新旧策略等价条件下融合 logprob 前向。

项目记录中的 8 路环境准备从 4.35 秒降至 0.87 秒；10 轮轨迹载荷从 968 KB 降至 214 KB。这些数字对应各自的工程测量条件，不应解释为整体训练的同等加速。

项目范围

RepoCompass 基于开源 CodeScout 代码库继续开发。这里展示的工作是任务侧环境、奖励、数据组织、后训练与工程优化；不代表参与创作 CodeScout 论文或从零编写所有底层基础设施。

Qwen3 Runtime 是相关的独立推理层项目。二者通过适配层连接，Agent 的工具、环境和训练逻辑仍由上层系统负责。