@barrowjoseph：我认为微软FastContext论文很好地展示了公司即将构建的代理系统类型……

我认为微软的 FastContext 论文很好地展示了企业在不久的将来将构建的智能体系统类型——一个 4B 参数的任务特定搜索智能体，可将编排模型的 token 使用量减少约 20%。我认为它是检索研究帕累托前沿上“橙色点工作”的有力竞争者！论文：https://arxiv.org/abs/2606.14066 我的笔记：https://jbarrow.ai/field_notes/fastcontext/… — # FastContext：为编码智能体训练高效的仓库探索器 来源：https://arxiv.org/html/2606.14066 邵秋张12111平等贡献.222工作完成于微软 CoreAI 项目期间.毛全王1111平等贡献.玉玲石2111平等贡献.宇航王2晓东顾2 永强姚1饶傅1胜宇傅1333通讯作者. 1微软2上海交通大学 {maoquanwang, yongqiangyao, raofu, shengyufu}@microsoft.com {Qiushao418, yuling.shi, lingbo_2022, xiaodong.gu}@sjtu.com ###### 摘要 大型语言模型（LLM）编码智能体在软件工程任务上取得了强劲成果，但仓库探索仍然是主要瓶颈：定位相关代码消耗了大量 token 预算，并用不相关的代码片段污染了智能体的上下文。在大多数智能体中，同一个模型既探索仓库又解决问题，在求解器的历史中留下了探索性读取和搜索记录。我们提出 FastContext，一个专用的探索子智能体，将仓库探索与问题解决分离。FastContext 按需调用，发出并行工具调用，并以文件路径和代码行范围的形式返回简洁聚焦的上下文。FastContext 由参数规模为 4B–30B 的专用探索模型驱动。我们从强参考模型轨迹中引导这些模型，并通过基于任务真实的奖励进行细化，以实现广泛的首轮搜索、多轮证据收集和精确的引用生成。在 SWE-bench Multilingual、SWE-bench Pro 和 SWE-QA 上，将 FastContext 集成到 Mini-SWE-Agent 中可将端到端解析率提升高达 5.5%，同时将编码智能体的 token 消耗减少高达 60%，且开销很小。这些结果表明，仓库探索可以与问题解决分离，并由专用模型有效处理。代码与数据：https://github.com/microsoft/fastcontext ## 1 引言 编码智能体已成为自动化软件工程的主流方法，能够处理从本地代码重构到仓库级问答的各种任务 [Yang et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib5), Zhang et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib6), Xia et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib7), Wang et al., 2026a (https://arxiv.org/html/2606.14066#bib.bib12)]。行业领先的助手如 Claude Code、Codex、GitHub Copilot CLI 和 Cursor [Anthropic, 2026 (https://arxiv.org/html/2606.14066#bib.bib37), OpenAI, 2026 (https://arxiv.org/html/2606.14066#bib.bib38), GitHub, 2026 (https://arxiv.org/html/2606.14066#bib.bib39), Cursor, 2026 (https://arxiv.org/html/2606.14066#bib.bib40)] 通过日益复杂的机制不断推动这些边界，最近专用子智能体的兴起标志着该领域的重要前沿。然而，驱动这些高级系统的仓库探索机制通常是专有的，使得研究界缺乏开放的训练和评估方法来在此基础上构建。诸如 SWE-bench 和 SWE-QA 等基准测试体现了社区从孤立编码问题向需要导航大型多文件代码库的实际任务的转变 [Jimenez et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib4), Peng et al., 2026 (https://arxiv.org/html/2606.14066#bib.bib17)]；更新的套件进一步拓宽了这一场景，涵盖了更困难、多语言和去污染的评估 [Deng et al., 2025 (https://arxiv.org/html/2606.14066#bib.bib16), Badertdinov et al., 2025 (https://arxiv.org/html/2606.14066#bib.bib18)]。在这些任务中，智能体必须先探索仓库以识别相关文件和代码区域，然后才能推理出修复方案或答案。因此，探索阶段在任务成功和推理效率中扮演着关键角色。我们用主智能体指代负责解决问题的编码智能体，用子智能体指代主智能体为执行更窄的仓库探索任务而可调用的专用助手。 参考图注 图 1：SWE-bench Multilingual 和 SWE-QA 分数与主模型 token 使用量的关系，FastContext 将编码智能体推向更好的分数- token 权衡：成本更低，存档更多。 然而，仓库探索仍然是当前智能体轨迹中成本高昂的部分，SWE-Pruner 对编码智能体上下文消耗的观察也证实了这一点 [Wang et al., 2026b (https://arxiv.org/html/2606.14066#bib.bib19)]。我们的初步分析表明，在轨迹中，读取和搜索占用了大量工具使用轮次和主智能体总 token。这种成本与先前系统的做法一致，这些系统在补丁生成前投入大量机制进行定位、搜索或代码搜索训练 [Zhang et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib6), Xia et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib7), Sutawika et al., 2026 (https://arxiv.org/html/2606.14066#bib.bib13)]。当探索遗漏关键文件或积累了不相关的片段时，主智能体必须从嘈杂的上下文中进行推理，并可能在后续轮次中花费精力去修复错误的假设，而不是解决真正的原因。 最近的工作已开始研究仓库上下文选择。基于图和结构引导的方法利用程序信息来改进定位 [Zhang et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib6), Chen et al., 2025 (https://arxiv.org/html/2606.14066#bib.bib9), Jiang et al., 2025 (https://arxiv.org/html/2606.14066#bib.bib10), Tao et al., 2025 (https://arxiv.org/html/2606.14066#bib.bib11)]；检索、压缩和工作流方法在生成前选择或压缩仓库上下文 [Zhang et al., 2023 (https://arxiv.org/html/2606.14066#bib.bib8), Shi et al., 2025 (https://arxiv.org/html/2606.14066#bib.bib2), 2026 (https://arxiv.org/html/2606.14066#bib.bib3), Xia et al., 2024 (https://arxiv.org/html/2606.14066#bib.bib7)]；而基于 RL 或搜索的系统训练或细化仓库搜索智能体 [Sutawika et al., 2026 (https://arxiv.org/html/2606.14066#bib.bib13), Pan et al., 2025a (https://arxiv.org/html/2606.14066#bib.bib21)]。这些研究表明更好的上下文可以改进软件智能体，但它们未讨论一个轻量级、经过训练的探索器与标准主智能体共存的作用。许多面向定位的评估强调文件级或函数级指标，而端到端收益通常是在专用管道内报告的；在这两种情况下，广泛的定位仍可能向主智能体提供嘈杂或过于宽泛的上下文，不适用于其实际决策点。此外，图构建、专用工作流或前沿模型探索的成本可能过高，无法作为 Mini-SWE-Agent 等最小框架的简单可复用组件。 为解决这些限制，我们提出 FastContext，一个专用的探索子智能体，将仓库搜索与主求解智能体分离。FastContext 接收自然语言的问题描述或仓库上下文请求，迭代地规划并执行并行工具调用以进行文件读取、glob 匹配和正则表达式搜索，并返回简洁的文件路径和行范围作为主智能体的聚焦上下文。通过将广泛探索移入单独的子智能体，主智能体可以接收更清晰的仓库证据，而不是携带导航过程中积累的不相关代码。 为了使这种委托成本低廉，我们使用监督微调和强化学习训练了参数规模为 4B–30B 的专用探索模型，从强参考模型轨迹中引导，并使用基于任务真实的奖励进行细化。集成到 Mini-SWE-Agent 后，FastContext 在 SWE-bench Multilingual、SWE-bench Pro 和 SWE-QA 基准测试上将端到端解析率提升高达 5.5%，同时将主模型 token 消耗减少高达 60%。 总之，我们的贡献如下： - •我们提出 FastContext，一个探索子智能体，将仓库搜索与主智能体求解解耦，执行迭代、并行的工具使用，并以文件和行引用的形式返回扎实的紧凑上下文。 - •我们通过 SFT 和 RL 训练了一系列专用探索模型（4B–30B），教会它们从广泛搜索开始，多轮收集证据，并生成精确的最终文件-行证据。 - •在 3 个基准测试上使用 Mini-SWE-Agent 进行的端到端实验表明，我们的探索子智能体将解析准确率提升高达 5.5%，同时将主模型 token 消耗减少高达 60%。 参考图注 参考图注 图 2：GPT-5.4-high 与 Mini-SWE-Agent 的轨迹分析。左侧：在整个轨迹中，读取和搜索主导了工具使用轮次和前沿模型提示 token 使用量。右侧：在首次编辑之前，智能体跨多个顺序探索轮次执行了许多探索工具调用，这促使我们设计一个能在主求解器轨迹之外发出并行工具调用的探索组件。 ## 2 初步分析 为了解仓库探索是否是一个值得委托的独特瓶颈，我们分析了 Mini-SWE-Agent 在完整 SWE-bench Multilingual 集合上产生的全部 300 条 GPT-5.4-high 轨迹，以量化主智能体的预算使用。此分析遵循 SWE-Pruner 最近的观察，即编码智能体可能在读取/搜索上下文上花费大量 token 预算，因此受益于上下文修剪 [Wang et al., 2026b (https://arxiv.org/html/2606.14066#bib.bib19)]。图 2 (https://arxiv.org/html/2606.14066#S1.F2) 将工具调用分类为读取、搜索、编辑、测试和其他操作，并报告了它们在工具使用轮次和总 token 中的占比。对于包含多个工具调用的助手轮次，我们将轮次和 token 计数分配到所调用的工具上。 读取和搜索在整个轨迹中占主导地位：两者平均占每个实例 17.72 个工具使用轮次中的 9.96 个，即 56.2% 的所有工具使用轮次，并消耗了主智能体总 token 的 46.5%。这个 token 占比直接对应于推理成本以及前沿模型必须携带的上下文。 轮次级视图揭示了第二个瓶颈：探索也是编辑之前的一个冗长顺序前奏。在 284 条可以识别出首次源代码编辑的轨迹中，智能体平均在第 8.47 轮开始编辑。即使启用了并行工具调用，中位轨迹在首次编辑前仍需要六个顺序探索轮次和 15.5 个探索工具调用。未解决轨迹相关的编辑前探索轮次多于已解决轨迹，平均分别为 8.34 轮对 6.67 轮。这种模式是预期的：更难的问题自然需要更多搜索。与其说证明探索本身导致失败，不如说这种对比展示了单独的探索组件能发挥的作用。当困难实例需要大量探索轮次时，将搜索移出主智能体会产生机会，减少求解器必须携带的上下文和 token 负担。同时，困难实例通常需要更精确的指导，指向决定修复的少数文件和行；一个经过训练的探索器可以提供这种指导，返回紧凑的证据，而不是一长串探索性上下文。 这些结果促使我们提出 FastContext 作为一个可重用的探索组件：仓库探索成本高昂到足以影响成本，同时又足够结构化，可以委托给一个子智能体，该子智能体执行并行搜索并为主智能体返回紧凑的文件和行上下文。 ## 3 方法 我们提出 FastContext，一个轻量级的探索子智能体，将仓库搜索与主智能体问题解决分离。给定一个问题或仓库上下文请求，FastContext 使用只读工具探索目标仓库，并返回紧凑的文件-行证据供主智能体使用。正文重点介绍委托契约和训练方案；提示词、运行时限制和奖励阈值的实现细节见附录。该方法包括一个简单的运行时框架和两个训练阶段：监督微调（SFT）以初始化探索行为，随后是强化学习（RL）以将返回的证据与任务相关的代码位置对齐。图 3 (https://arxiv.org/html/2606.14066#S3.F3) 概述了该工作流：探索器通过并行工具收集仓库证据，将其压缩为文件-行引用，并将得到的上下文传递给主智能体。 参考图注 图 3：FastContext 概述。左侧：端到端智能体循环架构中的 FastContext，编码智能体将仓库探索委托给 FastContext，并在继续编辑和测试之前接收紧凑的文件-行证据。右侧：FastContext 内部架构及示例，显示查询理解、并行工具调用、观察以及最终包含支持代码片段的引用。 ### 3.1 FastContext 子智能体架构 FastContext 是一种运行时委托机制：主智能体将仓库探索委托给探索器，探索器返回证据而不是补丁。主智能体随后消费这个缩小的上下文，避免了探索性读取和搜索的长序列（否则这些会留在其自身的对话历史中）。该子智能体有意只暴露三个与语言无关的工具：Read 用于读取带行号的文件内容，Glob 用于路径发现，以及 Grep（基于 ripgrep（https://github.com/BurntSushi/ripgrep））用于在仓库文本中进行正则表达式搜索。在每一轮，探索器要么发出一个或多个工具调用，要么以最终证据列表停止。同一轮中的多个工具调用并行执行，允许探索器在综合观察之前覆盖互补的假设。输出契约是一个紧凑的最终答案块，包含文件路径和行范围，可选地附有简短的相关性说明。典型答案如下： /src/router.py:42-58 (Router definition) /tests/test_router.py:101-119 这种格式使探索器的输出可以直接作为主智能体的聚焦上下文使用。 ### 3.2 监督微调策略初始化 我们通过监督微调训练初始探索策略。具体来说，我们构建来自 SWE-bench 风格仓库探索任务的训练示例，每个示例包含一个问题描述、一个仓库快照和工作区元数据。我们不只在最终位置上训练，而是根据子智能体必须执行的运行时行为分解监督。这使得模型暴露于完整的探索循环，从广泛的初始搜索到以观察为驱动的细化，再到紧凑的引用输出。 我们从 Sonnet 4.6 探索轨迹中构建了 2,954 个经过筛选的 SFT 示例，分成与子智能体运行时行为匹配的三个来源。第一个来源 parallel_toolcalls 针对广泛的首轮搜索：参考模型被提示使用查询和顶层目录列表，并要求发出非冗余的并行工具调用，覆盖互补信号，如路径模式、符号和可能的入口点。第二个来源 multiturn_traj 针对多轮证据收集：我们保留参考模型轨迹，包括系统消息和用户消息，助