论文

面向功能的中间填充作为编码智能体基础模型的中间训练

面向功能的中间填充作为编码智能体基础模型的中间训练

编码智能体需将外部工具返回集成到持续推理中,而标准从左到右的代码预训练仅在前向方向上暴露此能力。我们观察到编码智能体的行动-观察-延续循环在结构上同构于函数调用点:调用者绑定参数,被调用者返回在其他地方计算的值,下游代码消费该值。普通代码中这种条件结构存在于互联网规模。我们通过函数感知的中间填充 (FIM) 中间训练来利用这一点:一种自监督目标,通过程序依赖图分析和复杂度-可推断性双重标准选择函数进行掩码。我们在来自 968 个 GitHub 仓库的 26 亿 token 去污染语料上对 Qwen2.5-Coder-Instruct (7B/14B) 和 Qwen3-8B 进行中间训练,然后应用现有智能体后训练流程。 中间训练在 SWE-Bench-Verified 上提升 +2.8/+3.0 (7B/14B),在 Qwen3-8B 上提升 +3.2;SWE-Bench-Lite 增益分别为 +3.7/+4.0/+5.4。该提升在两个后训练流程 (R2E-Gym、SWE-Smith) 及非 Qwen2.5 基座 (Qwen3-8B with SWE-Lego) 上保持一致。除领域内增益外,中间训练还缓解了智能体后训练对非智能体编码 (如 LiveCodeBench) 和非编码工具使用基准 (tau-bench、BFCL) 造成的能力侵蚀:尽管中间训练语料仅含 Python 代码,但函数调用归纳偏置在后训练后仍然存在并产生一致收益。

论文精读

TL;DR 通过函数感知的填空式中级训练,将代码函数调度转化为智能体推理的强先验,显著提升 SWE 任务解决率并防止后训练能力退化。

问题

问题背景

代码智能体(coding agent)需将外部工具返回(如终端输出、文件内容)融入持续推理循环,形成 动作→观察→延续 的闭环。这与标准代码预训练中仅从左到右建模的方式存在根本差异。

现有方法局限

当前代码大模型大多采用 从左到右自回归预训练,或辅以常规的 填空(Fill-in-the-Middle, FIM) 目标,但这些方法均未能显式建模函数调用的双向条件依赖:调用方绑定参数,被调用方返回计算结果,后续代码消费该结果。常规 FIM 按随机跨度或基于 token 选择掩码,未利用程序依赖图分析,难以捕获跨文件、跨函数的复杂交互。此外,面向代码智能体的后训练(agentic post-training)虽然能提升软件工程任务表现,却会严重损害模型在非智能体编程任务(如 LiveCodeBench)和工具使用基准上的能力,即能力侵蚀(capability erosion)问题。

技术挑战与重要性

  • 结构同构未充分利用:代码智能体的行动 - 观察 - 延续循环与函数调用点在结构上同构,但这一属性在以往训练中被忽视。
  • 训练数据构造难度:需要自动从海量代码中筛选出“高价值”函数进行 FIM 掩码,要求既能表征复杂函数体,又能保证从调用上下文可推断返回值,这在技术上需要结合程序依赖图(PDG)分析复杂度分数可推断性分数的双重筛选。
  • 跨任务能力平衡:如何在提升智能体任务的同时,保持通用编程及工具使用能力,是产业落地的关键瓶颈。

行业类比

这类似于自动驾驶感知系统不仅要学会前向预测,还必须学会如何根据传感器回传信息动态调整路径——代码智能体也需要在“调用 - 返回”的双向条件分布中学习推理。

核心洞察

  • - **函数调用结构与代理循环的结构同构性使得大规模代码语料可转化为代理能力自监督 mid-training 信号**:与依赖昂贵代理轨迹或手工指令的微调不同,本文观察到代码中普遍存在的函数调用(调用者绑定参数、被调者返回计算结果、下游消费返回值)天然蕴含条件生成结构,与编码代理的“动作→观察→继续”循环完全对应。通过函数感知的 Fill-in-the-Middle 目标,利用程序依赖图选取复杂且可推断的函数进行掩码预测,模型在无需任何代理标注数据的情况下习得了工具调用和结果整合的推理模式,大幅降低了训练成本,同时避免了标准预训练仅关注前向依赖的局限。
  • - **mid-training 在增强代理能力的同时有效缓解了灾难性遗忘,并表现出跨领域迁移**:典型的代理后训练(如 R2E-Gym)会导致非代理编码能力(LiveCodeBench)和工具使用能力(tau-bench, BFCL)的退化,而本文方法在 Python 代码上完成的 mid-training 不仅将 SWE-Bench-Verified 提升 +2.8~3.2 分,还使得模型在后续代理微调中保留了这些非代理能力,甚至在非编码工具基准上取得一致性收益。这表明函数调用归纳偏置作为一种元能力,在代理后训练中存活并泛化,为构建通用代理基础模型提供了可能性,其价值超出单一任务提升。

方法

输入:大规模代码语料与去污染

从 968 个 GitHub 仓库中收集 2.6B tokens 的 Python 代码,经过严格去污染(排除已见于预训练数据或测试集的部分),确保训练数据清洁。

关键模块:函数感知的 FIM 目标选择与训练

  1. 程序依赖图分析:对每个函数构建 PDG,识别调用者-被调用者关系,以此选择可能形成“调用-返回”结构的函数组。
  2. 双标准评分:为每个函数计算复杂度分数 H_hat(基于控制流、AST 深度等)和可推断性分数 I_hat(基于上下文信息量),综合得分筛选出既非平凡可推断也非过度复杂的函数作为掩码目标。
  3. 多函数组选择:支持同时掩码调用者和被调用者,模拟代理环境中多步工具交互。
  4. FIM 训练样本构造:将选中函数的函数体替换为 <FIM_HOLE>,要求模型根据函数签名、参数、调用上下文及类/模块语境补全实现。样本中融入 思维链增强 :在生成函数体前,先输出推理步骤(例如分析参数用途、预期返回值),提升结构化推理能力。
  5. 中间训练:在 Qwen2.5-Coder-Instruct (7B/14B) 及 Qwen3-8B 上使用上述 FIM 目标继续训练,学习将外部工具返回集成到当前推理流的条件化能力。

输出:具备函数调用上下文感知的基座模型

中间训练后模型不直接面向代理任务,但已内化函数调用结构推理,后续经标准代理后训练流程(R2E-Gym、SWE-Smith 等)可获得一致且显著的性能提升。

与同类方法的差异:传统代码预训练或 FIM 通常随机掩码跨度,未显式利用函数调用结构;本工作通过依赖图引导的有偏掩码,将代理的“动作-观察-继续”循环显式建模为函数调用,并以最小 Tokens 代价(仅 2.6B)实现跨模型、跨后训练管道的稳定提升。

实验

实验设计

实验采用 函数感知填充中间 (function-aware FIM) 作为中间训练目标。首先从 968 个 GitHub 仓库 收集 Python 代码,经过去污染和程序依赖图分析,根据复杂度和可推断性双重标准筛选函数作为掩码目标,构建 2.6B tokens 的自监督语料。中间训练在 Qwen2.5-Coder-Instruct (7B, 14B)Qwen3-8B 基座上完成,随后应用到两种代理后训练管道:R2E-GymSWE-Smith,并在 SWE-Lego 管道上验证对非 Qwen2.5 基座的泛化性。评估覆盖 SWE-Bench 家族、LiveCodeBench、tau-bench 和 BFCL。

关键发现

  • 主要基准大幅提升:在 SWE-Bench-Verified 上,7B/14B/8B 模型分别提升 +2.8 / +3.0 / +3.2;在 SWE-Bench-Lite 上提升 +3.7 / +4.0 / +5.4。增益在不同模型尺寸和后训练管道下保持稳定。
  • 跨域能力迁移:尽管中间训练仅使用 Python 代码,但模型在非代理编码任务 (LiveCodeBench) 和非编码工具使用基准 (tau-bench, BFCL) 上均表现出能力保持甚至提升,有效缓解了代理后训练造成的通用能力侵蚀。
  • 结构归纳偏置:函数调用的 action→observation→continuation 结构与代理循环同构,使得 FIM 中间训练能够注入对工具返回值整合的归纳偏置,该偏置在后续微调中存活并泛化。

基线对比解读

基线为未经过中间训练、直接使用相同后训练管道的模型。中间训练带来的绝对提升最高达 +5.4,证明了 函数感知 FIM 作为一种中间训练策略的有效性。相比于仅依赖后训练从示范中学习,中间训练利用海量代码中的函数调用结构提供了一种 数据高效的结构先验。这一结果强调了对代理能力进行 分阶段训练 的重要性:先用自监督目标建模工具交互的基本模式,再通过后训练对齐到具体环境。此外,跨基准的增益表明该先验的泛化性超越了领域和任务边界,为构建更通用的代码代理基础模型提供了可复用的训练范式。

行业影响

落地场景

该工作直接赋能 编码 Agent 产品,如自动化代码修复、PR 审查助手、IDE 内智能编程(Copilot、Cursor 等)。其核心能力——理解函数调用与返回值,并整合外部工具反馈——对多文件、跨模块的任务尤其有效。因此,任何需要 Agent 在大型代码库中执行复杂修改(如重构、依赖更新、Bug 修补)的服务都适用。

商业价值

  • 降本:通过提升 Agent 的一次性修复率(SWE-Bench Verified +2.8~3.2),减少人工介入与返工,直接降低软件维护成本。
  • 增产 / 体验:更可靠的编码 Agent 可加速开发迭代,缩短上线时间;对代码审查平台(如 GitHub、GitLab),更高的问题解决率意味着用户粘性和付费转化提升。Mid-training 阶段用 2.6B token 的自监督数据即可带来显著增益,训练成本可控,且兼容现有后训练管线,无需推倒重来。

与现有工作流集成

该方法作为模型增强的中间环节插入现有栈:

  1. 从企业代码仓库(如内部 GitLab)采集源码;
  2. 运行作者提供的程序依赖图分析 + 复杂度 / 可推断性打分脚本,自动构建 Function-Aware FIM 语料;
  3. 在已有基座模型(如 Qwen、DeepSeek)上执行 mid-training;
  4. 沿用企业已有的 Agentic 后训练(如 RL、SFT)流程,无需修改。 成品模型直接替代原模型,无需改动推理服务或工具链。

具体落地案例

  • 电商平台后端微服务维护:一个包含数百个服务的代码库,Agent 常需跨服务修改函数签名和调用方。Function-Aware FIM 让模型预见到调用方代码在接收新返回值后的行为,减少因契约不匹配导致的 Bug。
  • 金融交易系统的自动化代码审计:严格要求每个函数的前置 / 后置条件,Agent 需要推断函数实现与调用环境的交互。该方法提升对复杂调用链的理解,降低误报,提高审计覆盖率。

局限

  • **语言局限性**:论文的 mid-training 语料仅包含 Python 代码,虽然实验表明函数调用归纳偏置在跨任务中有所迁移(如 tau-bench、BFCL),但所有代理及编码基准均基于 Python。对于其他主流编程语言(如 JavaScript、TypeScript)的函数调用模式,该方法的有效性尚未验证。这限制了其在多语言编码代理中的直接应用,实际工程中可能需要针对每种语言适配程序依赖分析工具并重新收集语料。
  • **中训练规模与函数覆盖**:mid-training 使用了 2.6B token 的脱毒语料,这一规模相对于现代 LLM 的预训练数据量(数万亿 token)较小。尽管论文通过复杂度-可推断性双重标准筛选高价值函数,但有限的语料可能难以覆盖所有函数类型和复杂调用模式。对于特殊领域(如异步调用、高阶函数、复杂装饰器)或罕见库函数的覆盖可能存在不足,导致模型在某些真实场景下的泛化能力受限。
  • **静态分析的固有局限**:函数选择依赖于程序依赖图(PDG)和静态评分,虽然设计了复杂度 Ĥ 和可推断性 Î,但静态分析无法捕捉动态运行时行为(如多态、反射、动态导入)。某些函数在静态看来简单却可能涉及复杂的动态特性,反之亦然。这可能导致 FIM 目标的噪声,影响中训练效果。此外,评分函数中的超参数(如权重、阈值)需针对特定语料调优,迁移到新数据分布时可能需要重新校准。
论文Yubo Wang2026-07-14原文

相关内容