函数调用就是 Agent 的脚手架：功能感知 FIM 如何给 Coding Agent 装上"行动脑"

论文：Function-Aware Fill-in-the-Middle as Mid-Training for Coding Agent Foundation Models arXiv: 2607.12463 | 作者：Yubo Wang, Jiarong Liang, Yuxuan Zhang, Xuye Liu, Cong Wei, Yuyu Zhang, Ping Nie, Wenhu Chen | 机构：University of Waterloo, UBC, NVIDIA, Verdent AI, Vector Institute | 2026 年 7 月 14 日

核心摘要

做 Coding Agent 这两年最大的一个隐痛：基础模型是给"读代码"练的，post-training 阶段才被硬塞进 action → observation → continuation 这种 agent 循环里。结果是 base 模型从来没有真正"在预训练阶段见过" agent 推理所需的条件结构。SFT 一上，agent 能力涨一点，但把代码能力、工具使用能力全赔进去了。

这篇 arXiv:2607.12463 提出了一个相当漂亮的角度：把代码里的函数调用点当成 agent 单步循环的天然脚手架。caller 绑参数、callee 在别处算出 return、downstream 消费——这跟 agent 采样动作、外部环境给 observation、再继续推理，是结构同构的。

他们据此设计了 Function-Aware FIM（FAFITM）中训练：从 GitHub 968 个 Python 仓库里用程序依赖图（PDG）+ 复杂度-可推理性双重准则选函数做 mask，再让 Gemini-3-Flash 生成 CoT rationale 塞进 FIM middle span。2.6B tokens 训完 7B/14B/Qwen3-8B，SWE-Bench-Verified 涨 2.8/3.0/3.2 分，SWE-Bench-Lite 涨 3.7/4.0/5.4 分。更关键的是，agentic post-training 搞坏的 LiveCodeBench、τ-bench、BFCL 都被拉回来了——只靠一个 2.6B token 的 Python 语料。

这是一篇把"中训练"这件事从玄学做成方法论的工作。亮点是理论洞察清晰、跨 pipeline 跨 base 跨 benchmark 鲁棒性强；小遗憾是 CoT 来源重度依赖 Gemini-3-Flash，跨语言没系统验证。

论文信息

为什么要做这个工作？先聊聊 Coding Agent 的"训练时间缺口"

我做 coding agent 评测这一年，被一个反直觉的现象反复恶心：基础模型在 SWE-Bench 上是 1-2 分的"废物"，但一上 agentic post-training 立刻蹦到 15-30 分。看起来挺好？但同期 LiveCodeBench、HumanEval、BFCL 这些非 agent 任务开始掉分。

数据上很扎心：Qwen2.5-Coder-14B-Instruct 在 LiveCodeBench 上有 37.2 分，加 R2E-Gym post-training 后掉到 24.1 分；BFCL 从 23.2 掉到 15.8。一边涨 20 多分，一边赔 10 多分——这不叫"训练"，叫"跷跷板"。

为什么？arXiv:2607.12463 给了一个我读完拍大腿的解释：base 模型在 left-to-right pretraining 里只见过 action → observation → continuation 循环的前向。它从来没用"已知 prefix → 外部计算 → 已知 suffix"这种条件结构被训练过。Random-span FIM 本来有希望补这块，但 FIM 在 base pretraining 里就被数万亿不相关 token 稀释了——到 post-training 开始时，这个结构先验已经基本消失。

更具体的，random FIM 三个问题：

1. Span 边界语法任意——大量 masked span 切断表达式中间，函数级依赖信号被切碎。
2. 没有推理监督——直接填 span，没有 think-then-act 的中间推理。
3. 目标被消融进 pretraining——trillion token 的稀释让 FIM 赋予的结构先验几乎失效。

post-training 阶段只能拿 SFT 强行把循环塞进去，代价就是其他能力的 catastrophic forgetting。所以问题变成了：能不能在 pretraining 之后、agentic post-training 之前，加一个中训练阶段，专门把"已知 prefix → 外部计算 → 已知 suffix"这种 agent 循环的同构条件结构装回去？

核心洞察：函数调用点 = Agent 单步的天然脚手架

论文让我最服气的地方是 Figure 1 那张图。把函数调用点和 agent 单步拆成同样的四阶段：

图1：左边两联对比函数调用点与 agent 单步的同构四阶段；中间展示 Function-level FIM mid-training——从 PDG 选目标，把 rationale + body 塞进 <fim_middle>；右边是 SWE-Bench-Verified 和 Lite 的增益柱图（7B/14B/8B 三个 base 在两个子集上的提升幅度）

说到底这是一个相当优雅的视角：agent 循环不是只能从合成轨迹里学，互联网上普通的 Python 代码里到处都是它的实例。一次普通的 result = compute(x) 就是一次完整的"前缀 → 外部计算 → 后缀"循环。把"compute 函数体"mask 掉，让模型从 caller 上下文和 downstream 消费恢复 body——这跟 agent 拿到 observation 后再决定下一步动作，几乎是同一件事。

所以 agent 训练第一次有了一个自监督的、与 agent 循环同构的、互联网规模的预训练目标——不用再编几个 SWE-Bench 风格的合成轨迹，直接吃 GitHub 上 968 个 Python 仓库。

方法：Function-Aware FIM 中训练 pipeline

数据：968 仓库、400K FIM 样本、2.6B tokens

从 GitHub 候选约 2000 个 star 数达标的 Python 仓库开始：

• 手动质量过滤
• 移除与 SWE-Bench 源仓库重叠的仓库（按仓库名和已知 fork 校验）
• 时间过滤：所有 commit 早于 SWE-Bench-Verified 和 Lite 中使用的最早 base-commit
• 留 968 个仓库，去污染零重叠

最终切出 约 400K FIM 样本（约 2.6B tokens，Qwen2.5-Coder tokenizer），target 分布：

• 320K 单函数（80%）
• 60K pair（15%）
• 20K triple（5%）

10 个主题类别（参考实现、科学计算、小型框架占大头），许可证 MIT/Apache/BSD 占 80% 以上。

目标选择：PDG + 双重准则

Function-aware FIM 区别于 random FIM 的关键在怎么选 mask 哪个函数。论文分三步：

第一步：程序依赖图（PDG）

对每个文件解析 AST，提取函数节点集合，按 qualified name 标识。建两类边：

• Call edges \(\mathcal{E}_{\text{call}}\)：caller → callee
• Sibling edges \(\mathcal{E}_{\text{sib}}\)：同一类的方法之间（捕获共享实例状态流）

call resolution 处理 Python 惯用法：直接调用、类实例化、self/cls 方法。允许 short-name fallback 匹配。

第二步：两个分数

复杂度分（\(\hat{H}\)）——这个函数自己有多难：

三个分量：代码行数、McCabe 圈复杂度、控制流最大嵌套深度。\(\varphi(x, c) = \min(x/c, 2)\) 是 soft cap 归一化。权重 (0.4, 0.4, 0.2)，caps (50, 10, 5)。

可推理分（\(\hat{I}\)）——给定函数 body 之外的上下文，能不能反推 body：

五个手工设计的上下文信号（论文 §2.3.3）：

• \(C_{\text{caller}}\)：调用点的参数特异性（call base 0.5，literal-arg +0.15，name-arg +0.05，kw-arg +0.12，per-caller cap 1.5）
• \(C_{\text{callee}}\)：函数调用的文件内其他函数数
• \(C_{\text{sig}}\)：类型注解 + 名字描述性（return-type +0.30，param-type +0.25，name-parts up to 0.25）
• \(C_{\text{doc}}\)：docstring 存在 +0.5
• \(C_{\text{class}}\)：类内 sibling 数 + __init__ 存在 +0.30

混合权重 (0.30, 0.25, 0.20, 0.10, 0.15)。手工设计是有意为之——避免学出来的可预测性分数耦合到特定参考模型。

第三步：调和平均 + 难度惩罚

调和平均形式强迫 \(\hat{H}\) 和 \(\hat{I}\) 同时大，惩罚任何一头虚高的目标。\(\Delta(v) = \max(0, \hat{H} - \hat{I})/(\hat{H} + \varepsilon)\) 是一侧难度惩罚——即使有完整上下文仍很困难的样本会被降权。

硬过滤：文件行数 [50, 1800]、函数 LoC ∈ [10, 200]、\(\hat{H}(v) < 0.15\) 丢弃、\(\text{FIM}(v) < 0.08\) 丢弃。

多函数组：真实代码 patch 经常跨多个相关函数，扩展为 mask k=2 或 k=3 个结构连接的函数组，8 种拓扑模式（caller-callee、co-callee、sibling-coupled、mutual-call、call-chain、hub、fan-in、class-triad）。

下面这张图把上面这套打分在 calc.py 这个小例子上完全跑了一遍，能看到 total 函数被选中而 add/is_int/mean/push 都被过滤掉的具体原因：

图2：(a) 解析 calc.py AST 得到的 PDG，黑色实线 \(\mathcal{E}_{\text{call}}\)（add→total、is_int→total、push→is_int），灰色虚线 \(\mathcal{E}_{\text{sib}}\) 标记类内耦合；(b) 选中函数 total 的分数拆解：\(\hat{H}=0.40\)（LoC 0.08 + CC 0.20 + depth 0.12），\(\hat{I}=0.48\)（caller 0.06 + callee 0.13 + sig 0.10 + doc 0.05 + class 0.14）；(c) \(\hat{H}\)-\(\hat{I}\) 平面上的散点，红线是 FIM = \(\tau\) 等高线，total 通过、其他函数被过滤

CoT 增强：让 middle span 不只是 body

光 mask body 还不够，论文的第三板斧是在 FIM middle span 里塞 CoT rationale，镜像 agent step 的 think-then-act 结构：

<fim_prefix>⟨prefix⟩
<fim_suffix>⟨suffix⟩
<fim_middle>⟨rationale⟩⟨body⟩

三阶段 pipeline：

1. Generate：Gemini-3-Flash 只看到 masked file，生成 step-by-step rationale + candidate body（没有 ground-truth body 访问权，防止变成蒸馏）
2. Filter：另一个 Gemini-3-Flash judge 对 (rationale, candidate body) pair 相对 ground-truth body 打分（feasibility + 5 个质量维度），保留 top-scoring 约 400K 样本
3. Format：保留的 pair 放进 FIM middle span，rationale 在 body 前

模型被训练先产生推理再产生一致代码——这正好对应 agent 的 think-then-act 模式。ground-truth body 仅作为 filter anchor，从不出现在训练目标中。

主实验：跨规模、跨 pipeline、跨 base 三轴验证

Table 1：SWE-Bench-Verified / SWE-Bench-Lite 主结果

基线对比：base + post-training（已存在的 pipeline 复现），以及 base + FIM mid-training + identical post-training。

Qwen2.5-Coder-7B-Instruct

Qwen2.5-Coder-14B-Instruct

Qwen3-8B

三个一眼能看出来的结论：

1. 跨规模一致：7B/14B 上 Verified 提升 +2.80/+3.00，相对幅度不缩（14B 数字看着小，相对幅度其实差不多 11-12%）。
2. 跨 pipeline 传递：同一个 7B base，SWE-Smith 复现基线是 12.30，加 mid-training 后 17.60——Verified 提升 +5.30（比 R2E-Gym 的 +2.80 还猛）。说明 FAFITM 的收益不绑死某条 post-training pipeline。
3. 跨 base family 传递：换到 Qwen3-8B + SWE-Lego 组合，Verified +3.20、Lite +5.40。SWE-Lego 数据超过 Qwen2.5-Coder 的 32K 上下文，训练只跑了 2 epoch（官方 4 epoch 防过拟合）——这都不是"开卷考"了，Recipe 真的不绑死某套组合。

Table 3：消融——3 个维度、3 个独立的杠杆

（7B + R2E-Gym，共享 200K target budget）

(A) CoT 来源：function-aware FIM 本身已经做了大部分工作

注意 baseline → FIM no-CoT 这一步涨了 +1.18 平均分，已经约为 Gemini CoT 总增益（+2.43）的一半。Self-CoT 恢复了 2.43 中的 1.68，frontier teacher 单独贡献仅 0.75。这张表我认为是整篇论文最关键的——这条 recipe 不是伪装的蒸馏 pipeline，function-aware FIM 信号本身就在做实质性工作。

(B) Function-selection 算法：主导杠杆

Random 设定下限 13.95，frontier judge Gemini-selected 达 15.05——frontier judgment 有帮助但不充分。\(\hat{H}\) 和 \(\hat{I}\) 各自有贡献（15.05 vs 15.35），合到 Full 达 15.60——这两个信号不冗余。这个 ablation 强力支撑了"双重准则"的设计选择。

(C) Mask 粒度：pair 有帮助，triple 收益饱和

Table 2：最有价值的部分——非 agent 任务的能力恢复

这块我读完真的拍了一下大腿。

14B + R2E-Gym 这个组合下，对比三组配置（Instruct / + R2E-Gym / + FIM-Midtrain + R2E-Gym）在六个非 agent / 非编码工具使用基准上的表现：

我的第一反应是：LiveCodeBench 这一项从 24.10 拉回 35.20，基本把 R2E-Gym 赔掉的能力找回了 84%。OJBench 离 Instruct 上限仅差 0.46，几乎完全恢复。

但更让我想鼓掌的是 τ-bench +3.90 和 BFCL +2.40 这两行。

这两个基准里没有任何 Python 代码编辑数据——τ-bench 是客户服务 agent 模拟，BFCL 是 Berkeley 函数调用 leaderboard。mid-training 语料里也没有任何工具使用轨迹。所以唯一的解释是：mid-training 装进去的"已知 prefix → 外部计算 → 已知 suffix"结构先验在 post-training 里存活下来并外溢到非编码工具使用上。这是 function-call 和 tool-call 同构假设最直接、最干净的证据——比 SWE-Bench 那些数据更让人信服。

行为分析：增益到底从哪儿来

论文 §4 给了两个相当扎实的归因分析。

4.1 负面观察恢复（Table 4）

观察 88.8% (baseline) vs 91.8% (ours) 的轨迹都包含负面观察（错误工具返回、失败测试等）——比例基本相同。但恢复率从 24.8% 拉到 28.8%（+4.0 pp，相对涨 16%），平均每解决任务的编辑数 3.3 → 7.4、步数 15.1 → 23.6。

翻译一下：模型从"提交了事"的策略转向 iterate-and-verify——错了不慌，再来一次。这个我太熟了，这是好的 agent 跟凑合 agent 之间的分水岭。

4.2 增益集中在多函数推理

看 multi-func single-file 这一行——88 个任务上从 13.6% 拉到 22.7%，绝对增益 +9.1 pp，是单函数任务增益的 4 倍以上。Per-instance 对比里 ours 独特解决的任务数约为 baseline 的 2 倍。

这条结果跟 function-aware FIM 的设计目标完美闭环——多函数推理正是 PDG + 双重准则优先 mask 的目标。

但同样的，多文件任务没有任何增益。论文老实承认了：FIM 在文件内操作，跨文件 patch 粒度不匹配。这是设计上的明确边界，没硬吹。

下面这张图把上面的数据直观画出来：

图5：单函数单文件（n=341）baseline 32.5% → 34.6%；多函数单文件（n=88）baseline 13.6% → 22.7%，最大增益；多文件（n=71）11.3% → 11.3%，无变化。每个 checkpoint 跑了三次 evaluation 取均值

我的判断

读完之后我的整体评价：这是一篇把"中训练"这件事从玄学做成方法论的工作。理论洞察清晰，实验鲁棒性强，跨 pipeline 跨 base 跨 benchmark 的验证都比较扎实。

亮点

理论洞察是真的漂亮。"Agent 循环 = 函数调用点同构"这个观察本身价值很大——它把"agent 需要的能力"从合成轨迹的依赖里解放出来，重新接回互联网规模的源代码。这是这篇工作最值钱的地方，比那个 +2.8/+3.0 的具体数字值钱得多。

消融实验做得相当扎实。CoT 来源、function-selection 算法、mask 粒度三个独立维度都有清晰信号，没有任何一个组件是 fluff。"FIM no CoT 涨 1.18"这一行尤其关键——直接证伪了"这是披着 FIM 皮的 Gemini 蒸馏"。

能力恢复那条线最有说服力。τ-bench / BFCL 上的 +3.9 / +2.4 是只有结构性先验才能解释的跨域迁移——比 SWE-Bench 上那些直接 domain 内的数字更有意思。

几个让我皱眉的地方

第一，CoT 来源重度依赖 Gemini-3-Flash。Self-CoT 恢复 2.43 中的 1.68，留给 frontier teacher 的只有 0.75——这看起来 Gemini 贡献不大，但前提是 self-CoT 用 Qwen2.5-Coder-7B-Instruct 自己生成，跟"完全开源复制需要同等强度开源 teacher"是两件事。一个 70B+ 的开源 model 能不能同样生成高质量 rationale，这事论文没测。如果你想复现又不想用 Gemini 3 Flash，这条 recipe 暂时还不算"完全开源"。

第二，跨语言只通过 FullStackBench-EN 间接验证。所有数据是 Python，所有训练目标是 Python，所有"同构"假设建立在 Python 函数调用上。Java/C++/Rust 的传递性"留待未来工作"——这是论文自己说的。一个好的 follow-up 是把这套 recipe 套到 TypeScript/Go 这种静态类型更严格的语言上，看看 \(\hat{I}\) 的 sig 分量会不会更吃香。

第三，单一非 Qwen2.5 base。跨 base 证据只来自 Qwen3-8B + SWE-Lego——同时换了 base 和 post-training pipeline。这说明 recipe 不特定于某个组合，但不保证跨所有 base family 传递。如果用 Llama / DeepSeek-Coder 复现，结果未知的部分要自己承担。

第四，多文件任务完全没动。FIM 天然在文件内操作，跨文件 patch 想要进 FIM middle span 就需要 concatenate——这会带来上下文长度爆炸和新的 masking 策略问题。不是这篇论文的锅，但 FAFITM 的能力范围因此被画了一条清晰的硬边界。

跟同期前置工作的对比

Random-span FIM（Bavarian et al. 2020；Beltagy et al. 2022）和 CodeFIM/PSM/SPM 这些变体是基础，但它们的 mask 边界完全是句法级随机切，跟函数级依赖没关系。Infilling-Guided Learning（Wei et al. 2024）之类用代码结构做 mask，但没有把 agent 循环的同构性讲清楚——这是这篇最关键的概念贡献。

OpenCoder、Sky-Coder 这些基础模型在 pretraining 阶段也用过 FIM，但都是 random-span，没有 PDG 引导。Qwen2.5-Coder-7B 的技术报告里提到过 CodeFIM，但同样没有按函数依赖关系选择目标。这篇的 2.6B tokens 体量跟那些动辄几 T 的 pretraining 没法比——但精准选择弥补了规模。

把 Post-training 阶段的 catastrophic forgetting 当真问题认真解的，主要有几条线：KL 约束、模型合并（model souping）、以及在 post-training 数据里混入原始 base 任务数据。这些都是 workaround——它们假设"post-training 一定要搞坏一些东西"，想办法把坏的东西修回来。FAFITM 反过来，假设"base 不该只见过前向"，在 mid-training 阶段把同构条件结构装回去，让 post-training 不用再"学会"agent 循环而是从零重建。这是个范式上的差别。

工程启发

如果你也在做 coding agent 或者工具使用 agent，这个思路强烈值得借鉴：

1. 不要把所有负担都丢给 post-training。base 模型在 pretraining 里没见过的条件结构，光靠 SFT 是装不回去的——你会在 LiveCodeBench 这种地方付出真实代价。
2. 中训练阶段是当前最被低估的训练阶段。pretraining 太贵、post-training 太短，中间这个几 B token 体量的窗口既便宜又能定向装先验。
3. 手工设计的可解释打分比学习型打分更值得这个体量的任务。\(\hat{H}\) + \(\hat{I}\) 这套"复杂度 × 可推理性"调和平均，在 ablation 里稳定优于 Gemini-selected（15.05 vs 15.05 之间持平但更可解释）。400K 样本这个规模上，别上学习器。
4. 行为归因比主表重要。Table 4 那些"恢复率 24.8% → 28.8%"、"编辑数 3.3 → 7.4" 的数字，比 +2.8 SWE-Bench Verified 给我更多信心——前者说明策略真的变了，后者只说明"某次跑分高了"。

收尾

arXiv:2607.12463 这篇最让我满意的，是它没有把"中训练"卖成银弹——多文件任务零增益、跨 base 只测了一组、跨语言留待未来，画得清边界的论文可信度比吹上天的论文高一个量级。

说到底，函数调用点本来就是为"已知 prefix → 外部计算 → 已知 suffix"循环设计的语言原语——只是过去没人把它跟 agent 单步对应起来。把这层关系讲清楚，剩下 2.6B tokens 的数据、PDG、调和平均、CoT rationale，都是顺势而为的工程实现。

如果你是做 coding agent 的从业者，下一步可考虑：

• 拿自己领域的代码语料（TypeScript/Go/Rust）跑一遍同一套 recipe，看看 \(C_{\text{sig}}\) 在静态类型语言上权重是不是要重调
• 把 CoT 来源从 Gemini-3-Flash 换到 DeepSeek-V3 / Qwen3-Max，看 self-CoT 之外的 frontier teacher 是不是 0.75 那个量级的"边际贡献"是稳定的
• 试试在 multi-file 任务上把 FIM 扩展到"跨文件 concatenate + multi-file CoT"——这是论文留下的明确硬骨头

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我。