FastContext: Training Efficient Repository Explorer for Coding Agents
论文阅读：FastContext：训练高效的代码仓库探索器以服务 Coding Agent
论文标题：FastContext: Training Efficient Repository Explorer for Coding Agents
中文标题：FastContext：训练高效的代码仓库探索器以服务 Coding Agent
作者：Shaoqiu Zhang, Maoquan Wang, Yuling Shi, Yuling Shi, Yuhang Wang, Xiaodong Gu, Yongqiang Yao, Rao Fu, Shengyu Fu
机构：Microsoft；Shanghai Jiao Tong University
发表位置：arXiv preprint
arXiv 编号：2606.14066v1 [cs.SE]
原文链接：https://arxiv.org/pdf/2606.14066
代码与数据：https://github.com/microsoft/fastcontext
主题：LLM Coding Agent、代码仓库探索、上下文选择、代码定位、子 Agent、SFT/RL
核心问题：在真实软件工程任务中，coding agent 往往要先花大量轮次和 token 在仓库里查找相关代码；论文试图把这部分“探索”从主求解 Agent 中拆出来，交给一个更小、更专门的 FastContext 子 Agent 完成。
1. 论文要解决什么问题？
这篇论文关注的是 coding agent 在代码仓库级任务中的一个基础但容易被混在整体能力里的环节：仓库探索。
在 SWE-bench 这类任务中，Agent 并不是直接看到待修改的函数，然后生成补丁。它通常需要先阅读 issue 描述，再在仓库中查找相关文件、搜索符号、阅读上下文、定位可能需要修改的代码区域，之后才进入真正的修复、测试和提交阶段。
论文指出，当前很多 coding agent 里，同一个主模型既负责探索仓库，又负责解决任务。这样会带来两个问题：
- 成本问题：大量
read、grep、search会消耗主模型 token。 - 上下文污染问题：探索过程中读到的无关代码片段会留在主 Agent 的历史中，后续求解时模型需要带着这些噪声继续推理。
FastContext 的基本想法是：不要让昂贵的主模型亲自完成所有探索；可以引入一个专门的仓库探索子 Agent，让它独立地进行只读搜索，并把结果压缩成一组精确的文件路径和行号区间，再交给主 Agent。
也就是说，FastContext 并不是补丁生成器，也不是完整替代 coding agent 的新框架。它更像一个“代码仓库导航员”：先帮主 Agent 找到相关区域，主 Agent 再基于这些区域继续修复、测试或回答问题。
2. 为什么仓库探索值得单独拆出来？
论文首先做了一个 preliminary analysis，用 Mini-SWE-Agent + GPT-5.4-high 在完整 SWE-bench Multilingual 上的 300 条轨迹来分析主 Agent 的时间和 token 花在哪里。
结果显示，读取文件和搜索代码在轨迹中占了很大比例：
| 指标 | 论文报告的现象 |
|---|---|
| 工具调用轮次 | read/search 合计平均占 9.96 / 17.72 个工具轮次 |
| 工具轮次比例 | read/search 占 56.2% |
| 主 Agent token | read/search 消耗 46.5% 的主 Agent 总 token |
| 首次编辑时间 | 在可识别首次源码编辑的 284 条轨迹中，平均第 8.47 轮才开始编辑 |
| 编辑前探索 | median 仍需要 6 个顺序探索轮次和 15.5 次探索工具调用 |
| resolved vs unresolved | unresolved 轨迹编辑前探索轮次更多，平均 8.34 vs 6.67 |
这里论文的表述比较谨慎：未解决任务有更多探索轮次，并不证明“探索导致失败”。更合理的解释是，困难任务天然需要更多探索。但这仍然说明，仓库探索是一个足够重、足够结构化的环节，值得作为一个独立模块优化。
【Figure 2。该图展示 GPT-5.4-high 在 Mini-SWE-Agent 中的工具轮次与 token 分布，以及首次编辑前的探索轮次/工具调用数量。】
这一分析引出 FastContext 的核心动机：如果能把探索过程放到主 Agent 外部执行，主 Agent 就不必把大量中间搜索历史带进自己的上下文窗口，只需要拿到紧凑、可操作的文件行号证据。
3. FastContext 的整体思路
FastContext 是一个专门的 exploration subagent。它接收主 Agent 提出的自然语言查询，例如“定位和某个 bug 相关的代码路径”，然后在代码仓库中使用只读工具进行探索，最后返回一组紧凑的文件路径和行号区间。
论文中的架构可以概括为三层：
| 组件 | 作用 |
|---|---|
| 主 Coding Agent | 负责理解任务、决定是否调用 FastContext、基于返回证据继续编辑和测试 |
| FastContext 子 Agent | 负责仓库探索，使用只读工具寻找相关代码 |
| Environment / Repository | 提供代码仓库、文件读取、路径匹配和文本搜索能力 |
FastContext 的输出不是 patch，而是类似下面这样的证据列表：
<final_answer>
/src/router.py:42-58 (Router definition)
/tests/test_router.py:101-119
</final_answer>
这个输出契约很重要。它让子 Agent 的结果可以被主 Agent 直接消费：主 Agent 不需要阅读子 Agent 的完整搜索过程，也不需要继承它所有中间工具输出，只需要看到“哪些文件的哪些行值得看”。
【Figure 3。该图左侧展示 FastContext 在端到端 Agent loop 中的位置，右侧展示 FastContext 内部的 query understanding、parallel tool calling、observation 和 final citations。】
4. FastContext 子 Agent 的工具设计
FastContext 暴露的工具非常克制，只有三类只读工具：
| 工具 | 作用 |
|---|---|
| READ | 读取带行号的文件内容 |
| GLOB | 根据路径模式发现文件 |
| GREP | 对仓库文本做正则搜索 |
子 Agent 每一轮可以做两件事之一：
- 发起一个或多个工具调用；
- 停止探索，并输出最终的文件-行号证据。
论文强调并行工具调用：同一轮中多个工具调用可以并行执行。这样，FastContext 可以同时验证多个搜索假设，例如一边按路径模式找文件，一边按符号名搜索，一边读取某个候选文件的关键区域。
这和主 Agent 顺序地一点点查找相比，有两个潜在好处：
第一，探索本身可以更快覆盖多个方向；第二，中间探索轨迹不会污染主 Agent 的对话历史。主 Agent 只得到最终压缩后的证据块。
5. 训练阶段一：用 SFT 初始化探索行为
FastContext 不是简单写一个提示词让模型去搜索，而是训练了一组专门的探索模型，规模从 4B 到 30B。
第一步是 supervised fine-tuning。论文构建了 2,954 条过滤后的 SFT 样本，这些样本来自 Sonnet 4.6 的仓库探索轨迹，并被拆成三类，以对应 FastContext 实际运行时需要具备的能力：
| SFT 数据来源 | 训练目标 |
|---|---|
parallel_toolcalls |
学习第一轮如何做宽搜索，发起互补且不冗余的并行工具调用 |
multiturn_traj |
学习多轮探索过程：根据工具观察继续细化搜索 |
linerange |
学习最终输出精确的文件路径和行号区间 |
这种设计说明，论文并不只是训练模型预测“最终相关文件”。它希望模型学会完整的探索流程：先宽搜索，再根据观察缩小范围，最后把证据压缩成行号引用。
SFT 的目标函数只对 assistant token 计算损失，包括普通文本、结构化工具调用参数和最终 citation block；非 assistant token 被 mask 掉。这样训练目标和实际工具调用对话形式保持一致。
6. 训练阶段二：用任务相关 RL 优化最终证据
SFT 可以模仿参考模型的探索轨迹，但它不直接优化“最终返回的行号证据是否覆盖了解决任务所需的代码位置”。因此论文进一步使用 reinforcement learning 来细化探索策略。
RL 阶段使用 400 个 issue-resolution prompts。每个样本包含：
- explorer instruction；
- workspace metadata；
- 顶层目录列表；
- 自然语言形式的仓库探索查询；
- 从 reference patch 中解析出的目标文件和目标行号范围。
训练时，模型作为真实 FastContext 子 Agent rollout：它在同样的工具环境中使用 READ、GLOB、GREP 搜索，最后输出 <final_answer>。
奖励函数由三部分构成：
| 奖励/惩罚项 | 含义 |
|---|---|
| file-level F1 | 最终引用的文件是否覆盖 reference patch 涉及的文件 |
| line-level F1 | 最终引用的行号范围是否覆盖 reference patch 涉及的代码区域 |
| parallel bonus | 对受限范围内的并行工具调用给予小奖励 |
| format penalty | 对空输出、过长输出、格式错误或过度发散的输出进行惩罚 |
论文使用 GRPO 从 SFT checkpoint 继续优化。RL 的目的不是让子 Agent 输出越多越好，而是让它返回一个小而有效的 citation set：既要覆盖关键位置，又要保持格式规范和上下文紧凑。
7. 实验设置
论文从两个角度评估 FastContext。
第一类是端到端任务表现：把 FastContext 接到 Mini-SWE-Agent 上，看主 Agent 的任务成功率是否提高、主 Agent token 是否下降。
使用的 benchmark 包括：
| Benchmark | 任务类型 |
|---|---|
| SWE-bench Multilingual | 300 个多语言 issue-resolution 实例 |
| SWE-bench Pro | 更困难的软件工程任务；论文使用固定随机采样的 200 个实例 |
| SWE-QA | 仓库级问答任务，不要求生成 patch，但要求定位和理解相关代码 |
主 Agent 包括 GPT-5.4、GLM-5.1、Kimi-K2.6。对每个主 Agent，论文比较：
| 设置 | 含义 |
|---|---|
| w/o Explore | 主 Agent 直接求解，不使用探索子 Agent |
| same-model exploration | 用同一个强主模型执行 delegated exploration |
| FC-30B-SFT | 使用 30B SFT FastContext |
| FC-4B-SFT | 使用 4B SFT FastContext |
| FC-4B-RL | 使用 4B SFT + RL FastContext |
第二类是 standalone exploration quality：单独评估 explorer 是否能找回 reference patch 相关位置。该实验使用 SWE-bench Verified，并在 file、module、function 三个粒度上计算 precision、recall 和 F1。
8. 端到端实验结果
论文的主表 Table 1 显示，加入 FastContext 后，每个主 Agent 在每个 benchmark 上的最佳 explorer-augmented 设置都优于直接求解。
为了突出主要趋势，下面整理每个主 Agent 的直接求解 baseline，以及在三个 benchmark 上表现有代表性的 FastContext 结果。
| 主 Agent | 设置 | SWE-bench Multilingual Score / Tokens | SWE-bench Pro Score / Tokens | SWE-QA Score / Tokens |
|---|---|---|---|---|
| GPT-5.4 | w/o Explore | 71.7 / 457k | 46.0 / 818k | 81.3 / 418k |
| GPT-5.4 | same-model | 73.3 / 379k | 51.5 / 703k | 81.4 / 166k |
| GPT-5.4 | FC-30B-SFT | 75.0 / 356k | 49.0 / 688k | 82.0 / 206k |
| GPT-5.4 | FC-4B-SFT | 73.3 / 364k | 47.0 / 689k | 81.9 / 213k |
| GPT-5.4 | FC-4B-RL | 74.7 / 338k | 48.5 / 701k | 82.0 / 210k |
| GLM-5.1 | w/o Explore | 72.3 / 2514k | 17.5 / 2692k | 72.7 / 401k |
| GLM-5.1 | FC-4B-RL | 73.7 / 1971k | 22.5 / 2210k | 73.5 / 302k |
| Kimi-K2.6 | w/o Explore | 76.3 / 1553k | 31.0 / 2383k | 71.6 / 510k |
| Kimi-K2.6 | FC-4B-RL | 78.3 / 1384k | 33.5 / 2158k | 72.6 / 378k |
从结果看，最大的准确率提升出现在 SWE-bench Pro：
- GPT-5.4：46.0 提升到 51.5；
- GLM-5.1：17.5 提升到 22.5；
- Kimi-K2.6：31.0 提升到 33.5。
SWE-bench Multilingual 也有稳定提升；SWE-QA 的分数提升相对较小，但 token 节省很明显。
论文特别强调 token 结果：所有 explorer-augmented 设置都比直接求解消耗更少的主 Agent token。最大节省出现在 SWE-QA 上，例如 GPT-5.4 从 418k 降到 166k，下降 60.3%。训练出的 FastContext explorer 在 SWE-QA 上也能带来约 50% 的主 Agent token 节省。
【Figure 4。该图展示 GPT-5.4 在三个 benchmark 上加入 FC-4B-RL 前后的主 Agent token 构成变化。】
【Figure 5。该图展示 SWE-bench Multilingual 上每个实例的 GPT-5.4 主 Agent token 分布，说明 token 节省不是只来自少数异常样本。】
9. 几个消融结论
论文的 ablation analysis 主要回答三个问题。
9.1 用同一个强模型探索不一定是最好选择
same-model exploration 看似自然：既然主模型能力强，就让它自己作为 explorer 搜索。但实验显示，训练过的 FastContext 模型经常在 score 和 token 两方面都优于 same-model exploration。
例如在 GPT-5.4 + SWE-bench Multilingual 上：
| 设置 | Score | Tokens |
|---|---|---|
| same-model exploration | 73.3 | 379k |
| FC-30B-SFT | 75.0 | 356k |
| FC-4B-RL | 74.7 | 338k |
这说明，“更强的通用模型”不一定等于“更好的探索组件”。如果探索任务本身有明确输出契约和训练信号，小模型也可以成为更划算的专门模块。
9.2 4B-RL 有时能超过 30B-SFT
论文报告，FC-4B-RL 在部分设置中超过 FC-30B-SFT。例如在 GLM-5.1 + SWE-bench Pro 上，4B-RL 得到 22.5，而 30B-SFT 是 20.0，并且 4B-RL 使用更少 token。
这不是说 4B 模型整体强于 30B 模型，而是说明 task-grounded RL 对这种有明确目标的探索任务很有效。只做 SFT 的大模型可以作为 scaling reference，而经过 RL 对齐的小模型可能更符合最终任务目标。
9.3 RL 稳定改善 compact explorer
和 FC-4B-SFT 相比，FC-4B-RL 在九个端到端设置中都提升或持平。明显提升包括 GPT-5.4 + SWE-bench Pro、GLM-5.1 + SWE-bench Pro，以及 Kimi-K2.6 的两个 issue-resolution benchmark。
这与奖励设计一致：RL 直接优化最终 citation 是否覆盖 patch-relevant locations，并约束输出格式和大小，因此更适合训练一个“返回短证据列表”的探索器。
10. 单独评估探索质量
除了端到端结果，论文还用 SWE-bench Verified 评估 FastContext 的 standalone localization 能力。这里的目标不是看最终 patch 是否通过测试，而是看 explorer 输出的文件和行号是否能覆盖 reference patch 相关位置。
论文在 file、module、function 三个粒度上计算 F1、precision、recall。关键结果包括：
| 模型/设置 | File F1 | Module F1 | Function F1 |
|---|---|---|---|
| FastContext GPT-5.4 | 72.34 | 55.16 | 35.91 |
| FastContext GLM-5.1 | 73.88 | 59.31 | 43.50 |
| FastContext Kimi-K2.6 | 71.34 | 59.34 | 43.87 |
| FC-30B-SFT | 73.71 | 60.35 | 40.74 |
| FC-4B-SFT | 70.55 | 55.26 | 37.48 |
| FC-4B-RL | 71.48 | 56.26 | 38.45 |
论文指出，在非 frontier 模型比较中，训练过的 FastContext checkpoint 在 file 和 module 粒度上形成了最强的一组结果。FC-30B-SFT 达到 73.71 的 file-level F1 和 60.35 的 module-level F1；作为小模型部署目标的 FC-4B-RL 也达到 71.48 / 56.26 / 38.45。
论文还观察到，从 4B-SFT 到 4B-RL，提升主要来自 recall 提高，而 precision 接近。这和奖励目标一致：RL 鼓励模型覆盖 patch-relevant locations，同时通过格式惩罚避免输出失控。
11. token 节省该如何理解？
一个容易误解的地方是：Table 1 中的 token 是主 Agent token，不包括 FastContext 子 Agent 内部探索消耗。论文在 Appendix B 中专门解释了这个 accounting 方式。
FastContext 的设计目标之一是减少强主模型必须携带的上下文和调用成本。因此主表报告的是主 Agent 轨迹中的 token：主模型调用、shell observation、solver turns 等，不把子 Agent 内部模型调用加进去。
但论文并没有忽略子 Agent 成本。它额外审计了 GPT-5.4 + SWE-bench Multilingual + 4B-RL 的运行：
| 项目 | 数值 |
|---|---|
| 任务数 | 300 |
| FastContext 调用次数 | 162 |
| 4B-RL 子 Agent 总 token | 22.58M |
| 按 $0.20 / 1M token 估算的子 Agent API 成本 | $4.52 |
| 直接主 Agent 成本估算 | $282.47 |
| 加入 4B-RL 后主 Agent 成本估算 | $208.92 |
| augmented total | $213.44 |
| net saving | $69.03 |
论文同时说明，目标部署中 4B explorer 是本地服务的，因此这个 API 成本估计主要是为了说明：即便按保守的 serverless 价格计算，子 Agent 开销仍然较小。
这个细节很重要。FastContext 并不是让所有计算消失，而是把昂贵主模型的探索负担转移给便宜、专门的小模型，并通过只返回最终证据来降低主模型上下文负担。
12. 与相关工作的关系
论文将相关工作放在几个方向中讨论。
第一类是 coding agents，例如 SWE-agent、AutoCodeRover、Agentless、OpenHands 等。这些系统通常通过工具使用和环境交互来完成真实软件工程任务，但它们对工作流组织方式不同，有些采用通用 shell/editor loop，有些将 issue resolution 拆成多个阶段。
第二类是代码定位和上下文选择方法，包括基于图结构、程序结构、检索、压缩或 workflow 的方法。这些方法说明更好的上下文选择能帮助软件工程 Agent，但很多工作更关注 standalone localization、上下文压缩或专门 pipeline。
FastContext 的区别在于，它把仓库探索做成一个可委托、可训练、轻量的子 Agent，并通过明确的文件-行号输出契约与标准主 Agent 协作。它不要求主 Agent 完全换成一个新的专门系统，而是尝试成为一个可复用的探索组件。
13. 论文指出的局限性
论文在 Limitations 中列出几个限制。
第一，当前端到端实验只把 FastContext 集成到 Mini-SWE-Agent 中。未来还需要把它适配到更多 coding-agent 框架中，因为不同框架的工具接口、记忆策略和 subagent orchestration 机制可能不同。
第二，主 Agent 实验主要使用较强模型，包括 GPT-5.4、GLM-5.1 和 Kimi-K2.6。论文尚未充分研究 FastContext 与更小主模型，例如 30B 级 coding agent 搭配时的效果。
第三，和其他公开 Agent benchmark 一样，部分任务可能与 frontier 模型预训练或产品调优数据重叠。因此这些结果应被视为受控 benchmark 证据，而不是实际部署保证。
第四，论文中最小的 explorer 是 4B 参数。作者计划继续研究同样的 SFT + RL 方案是否可以支持更小的 explorer，例如 1.7B 或 0.6B 模型。
14. 总结
FastContext 的核心观点是：在代码仓库级任务中，仓库探索不应只是主 Agent 求解轨迹里的隐性成本，而可以被抽象成一个独立、可训练、可评估的模块。
论文的设计可以概括为：
- 主 Agent 在需要时调用 FastContext；
- FastContext 使用 READ、GLOB、GREP 进行只读、可并行的仓库探索；
- 子 Agent 不返回完整搜索轨迹，只返回紧凑的文件路径和行号区间；
- 训练上先用 SFT 学探索过程，再用 task-grounded RL 优化最终 citation 与 reference patch 的匹配；
- 端到端实验显示，FastContext 能在 SWE-bench Multilingual、SWE-bench Pro 和 SWE-QA 上提升任务表现，并降低主 Agent token 消耗；
- standalone localization 结果说明，训练过的 FastContext explorer 确实更擅长找回 patch-relevant 的代码区域。
这篇论文的主要意义不只是提出一个具体的子 Agent，而是强调一种更模块化的 coding-agent 视角：仓库导航、补丁生成、测试验证不一定都要由同一个上下文里的同一个模型完成。把仓库探索变成一个显式接口后，就可以用更小、更专门的模型承担这部分工作，让强主模型集中在真正的修复和推理上。
参考
- Shaoqiu Zhang, Maoquan Wang, Yuling Shi, Yuhang Wang, Xiaodong Gu, Yongqiang Yao, Rao Fu, Shengyu Fu. FastContext: Training Efficient Repository Explorer for Coding Agents. arXiv:2606.14066v1, 2026.
浙公网安备 33010602011771号