FastContext 模型训练全揭秘：从 SFT 到任务驱动 RL，4B-30B 仓库探索模型是如何炼成的-平芜编程栈

【免费下载链接】fastcontext

FastContext: Training Efficient Repository Explorer for Coding Agents

项目地址：https://gitcode.com/gh_mirrors/fas/fastcontext

FastContext 是微软开源的轻量级仓库探索子代理（repository explorer），本文揭秘其 4B-30B 探索模型的完整训练路线：先用 SFT（监督微调）教会模型"如何高效搜代码"，再用任务驱动的强化学习（RL）以"引用是否命中真实补丁"为奖励信号打磨模型，最终让 coding agent 的 token 消耗最多降低 60.3%。

一、先认识 FastContext：把"找代码"这件事外包出去 🧭

大多数 coding agent 用同一个模型既写代码又找代码：大量的grep、find、整文件读取都会挤占主代理的上下文窗口，无关的代码片段还会"污染"后续推理。

FastContext 的思路是探索与求解分离：

主代理遇到不熟悉的问题时，把一句自然语言查询（如"找到认证逻辑的实现位置"）委派给 FastContext；
FastContext 只携带三个只读工具Read、Glob、Grep自主多轮探索，支持在同一轮并行发起多个工具调用；
探索结束后，它只返回一个简短的<final_answer>引用块（文件路径 + 行号范围），把"聚焦的证据"交还主代理。

下面这张图完整展示了 FastContext 的架构与工作流程：

其系统提示词要求模型"尽可能快地返回输出、能用并行工具调用就不要串行"，这正是探索模型行为风格的源头：src/fastcontext/agent/system.md。

二、为什么必须"训练"一个探索模型？🤔

直接用通用小模型 + 提示词也能做探索，但存在两个痛点：

探索不精准：小模型盲目广搜，引用大量无关文件与行号；
token 太贵：探索过程的每一次读取都消耗上下文，最终拖累主代理的成功率。

所以论文为探索任务专门训练了一族4B-30B 规模的探索模型（如 FC-4B-SFT、FC-4B-RL、FC-30B-SFT 等），走的是经典的"两阶段配方"：

2.1 第一阶段：SFT 监督微调——学会"探索的规范动作"

SFT 阶段的目标是让模型模仿高质量的探索轨迹，掌握：

查询理解：把 issue/需求翻译成搜索意图（先广后窄）；
工具编排：什么时候用Glob找文件、什么时候用Grep搜符号、什么时候直接Read；
输出纪律：最后必须以不超过 50 词的简短解释 +<final_answer>引用块收尾。

这些"规范动作"在开源的代理循环里都有对应实现，例如 src/fastcontext/agent/agent.py 中的多轮循环，以及max_turns用尽后强制输出最终答案的逻辑。

2.2 第二阶段：任务驱动 RL——奖励直接绑定"是否找到该改的代码"

SFT 只能"模仿"，而 RL 让模型为任务结果负责。FastContext 的奖励设计非常务实：引用质量 = 你返回的文件/行号与真实补丁（patch）的重合度。

评测脚本 benchmark/evaluation/run_score.py 展示了这套打分逻辑：把预测的引用与parse_patch解析出的真实改动做对比，在文件级和行级两个粒度上分别计算 precision / recall / F1。这套"任务接地"（task-grounded）的信号被搬进 RL 训练后，得到的 FC-4B-RL 在所有端到端设置中都不弱于FC-4B-SFT，甚至更稳——这就是"任务驱动"四个字的含义。

三、训练数据与查询从哪来？📚

训练与评测都建立在 SWE-bench 系列基准之上（SWE-bench Multilingual、SWE-bench Pro、SWE-QA）。其查询生成流程可以概括为：

取基准中的problem_statement（真实 issue 描述）；
由一个带subagent工具的主模型，基于 issue 生成一条自然语言探索查询（见 benchmark/evaluation/query_gen.py 中的task_prompt）；
用这些查询驱动探索模型，再用 run_score 式的 F1 信号打分，形成 SFT 轨迹与 RL 奖励。

仓库内还保留了端到端复现脚本 benchmark/evaluation/bench_mini_swe_agent.py 与主代理提示词配置 prompts/gpt-multi-fc.yaml，后者详细规定了"何时该调用 fastcontext、何时该跳过"。

四、训练成果：分数更高、token 更少 📊

三个基准上的端到端结果如下表（数字为相对"无探索"基线的变化，红色为降低，绿色为提升）：

几个关键结论：

📈端到端成功率最高 +5.5分（如 GLM-5.1 主代理在 SWE-bench Pro 上 46.0 → 51.5）；
💸主代理 token 最多省 60.3%（GPT-5.4 + FC-4B-SFT 在 SWE-QA 上 418k → 166k）；
🧠FC-4B-RL 全面追平/超过 FC-4B-SFT，验证了任务驱动 RL 的有效性；
🎯4B 小模型够用：小探索模型即可大幅降低主代理负担，探索任务不需要"大力出奇迹"。

token 节省到底省在哪？下面这张图给出了答案——节省几乎全部来自File Reading（读文件）与 Code Search（代码搜索）这两大类 token：

主代理把广撒网式的"读 10 个文件"换成"让 FastContext 先定位、再精准窄读 1-2 个区间"，上下文立刻干净了。

五、快速上手：5 分钟跑起你的探索模型 🚀

模型权重已开源，本地最简单的组合是 Ollama：

# 安装并启动 Ollama，拉取量化版 FastContext 4B-RL brew install ollama && brew services start ollama ollama pull hf.co/mitkox/FastContext-1.0-4B-RL-Q4_K_M-GGUF

配置环境变量并运行 CLI：

export FC_BASE_URL="http://127.0.0.1:11434/v1/" export FC_MODEL="hf.co/mitkox/FastContext-1.0-4B-RL-Q4_K_M-GGUF:latest" export FC_REASONING_EFFORT="none" export FC_MAX_TOKENS=1024 export FC_TEMPERATURE=0 # 在目标仓库目录下执行探索 fastcontext \ --query "Find the files that implement authentication and explain where to make a change" \ --max-turns 6 \ --traj .fastcontext/trajectory.jsonl

加--citation参数则只返回机器可读的<final_answer>引用块，方便程序化集成。CLI 入口见 src/fastcontext/cli.py，工具实现分别在 src/fastcontext/agent/tool/read.py、src/fastcontext/agent/tool/glob.py 和 src/fastcontext/agent/tool/grep.py。

也可以像 skills/fastcontext/SKILL.md 中建议的那样，把它作为 coding agent 的"默认第一步"：只要不确定答案，先跑fastcontext -q "..." --citation。

六、项目结构速览 🗂️

路径	说明
src/fastcontext/	探索代理核心：agent 循环、LLM 封装、三个只读工具
src/fastcontext/agent/context.py	对话与轨迹（trajectory）存储
benchmark/evaluation/	端到端 Mini-SWE-Agent 评测与打分工具
benchmark/swebench/	SWE-bench 风格的独立探索评测
prompts/	集成 FastContext 的主代理提示词配置
tests/	单元与集成测试