post-training没有软件工程数据,为什么模型反而更会修Bug了?

用文档、表格、检索、日程和浏览器操作等363个办公工作流，对Qwen3.5-122B-A10B做post-training。训练集合里没有软件工程任务、代码仓库issue、相关grader或benchmark反馈，但模型在SWE-Bench Pro上的pass@1仍从20.5%升到26.3%，绝对提升5.8个百分点。

这项结果值得追问的是：模型没有从训练集合里学到代码仓库知识，哪些变化仍能跨到软件工程？作者团队给出的解释是，长程办公任务反复训练了agent形成目标、整理状态、保持上层约束和验证结果的执行行为，而软件工程也需要同一类行为。不过，这还是基于结果和轨迹分析提出的解释，实验尚未证明哪种训练任务属性造成了迁移。

[表3：同一组checkpoint在SWE-Bench Pro上的跨领域表现] 基模型pass@1为20.5%，训练后为26.3%，变化为+5.8个百分点。

363个训练任务与软件工程内容零重合

训练数据来自LHMTA（Long-Horizon Multi-Tool Agent）。完整快照包含403个任务，其中363个用于训练、40个留作域内评测；27类任务覆盖文档、电子表格、幻灯片、搜索、文件管理、日历、浏览器自动化、规划和跨办公服务协作。成功轨迹通常需要30–40轮工具调用，长度达到8万–10万个token，因此训练对象是长程、有状态的工作流。

post-training分两步完成。第一步用Kimi K2.6在LHMTA上生成并筛选3000条得分高于0.9的轨迹做监督预热；第二步在363个任务上使用GSPO训练，每个prompt采样8条rollout，并按grader条件完成比例给予轨迹级奖励。模型通过LoRA更新attention和MLP投影，外部benchmark没有参与训练、checkpoint选择、调参或奖励设计。

[表2：域内与外部工具使用结果] 对比LHMTA留出集、Toolathlon和BFCL-V4在基模型与训练后checkpoint上的pass@1；所有结果均使用greedy decoding。

域内提升17.5点，跨到SWE-Bench Pro仍保留5.8点

训练后的域内LHMTA留出集从10.0%升至27.5%，增加17.5个百分点。离训练域更远后，Toolathlon从22.2%升至31.8%，增加9.6个百分点；BFCL-V4从55.7%升至59.2%，增加3.5个百分点；SWE-Bench Pro则从20.5%升至26.3%，增加5.8个百分点。

这些数字衡量的都是greedy decoding下的pass@1，也就是每个任务只看一次生成能否通过，不是平均代码质量或所有编程能力。SWE-Bench Pro使用真实代码仓库issue，5.8个百分点说明训练效果跨过了明显的领域边界；它没有证明办公数据比软件工程数据更高效，因为实验未设置等预算的软件工程训练对照。

[图4：LHMTA中的四类任务需求] 深度分解、并行调查与综合、纠缠约束和长依赖链都可能锻炼GDE的多个方面；原图只标出每类需求的一种常见压力。

GDE把跨域共同结构拆成四种执行行为

作者团队用Goal-Directed Execution（GDE，目标导向执行）描述agent在长程任务中持续对准目标的能力。一次执行可以看成循环：根据父目标和当前状态形成局部目标，行动或查询环境，用反馈更新工作状态，再检查目标是否真正满足；复杂任务会把这个循环递归展开成多层目标树。

GDE包含四种可观察行为：(1) 目标形成，选择服务于上层任务的当前目标；(2) 状态构建，收集并保留后续决策真正需要的信息；(3) 目标稳定性，处理局部问题时不丢掉上层约束；(4) 验证，向环境取得足以证明任务完成的证据。这是分析agent轨迹的行为框架，不代表模型内部存在一套可直接观察的符号目标栈。

[表1：四种GDE能力及其典型失效方式] 表中归纳目标形成、状态构建、目标稳定性和验证分别会怎样失效。

办公表格和代码仓库会在同一种执行环节失手

状态构建案例展示了这种跨域相似性。SWE-Bench Pro的一项Ansible任务要求拒绝Python保留关键字：基模型看到了仓库已有的验证结构，却又写了一个错误helper，最终触发NameError；训练后模型把需求接回中央validator。Toolathlon的表格任务也类似：基模型把公式字符串当成无效数据丢弃，训练后模型重新以缓存值打开工作簿，把计算结果纳入上层报告需要的状态。

[图6：跨领域的状态构建] 基模型丢弃或错误表示相关观察，训练后模型把它整合进父任务需要的工作状态。

验证案例对应另一种共同失效。Element Web重构任务中，基模型只检查新helper是否导出和导入，没有搜索仍在调用旧静态API的下游代码；训练后模型搜索陈旧用法、迁移调用点并运行针对性TypeScript检查。办公目录核对任务里，基模型只确认中间文件内部自洽，训练后模型还比较两个独立工作簿视图，确认抽取范围覆盖完整目录。

[图8：跨领域的验证] 基模型依赖代理信号或自我参照的证据，训练后模型向环境核对真正的完成条件。

731组SWE-Bench Pro轨迹显示检索更少重复、测试更频繁

在731组相同任务、prompt、环境和评测协议的配对轨迹中，训练后模型平均检索调用从25.6次降到23.9次，获取的不同信息片段从7985增至9019，重复信息占比从22.5%降到14.3%。最终补丁触及的参考文件数从2.69增至3.08，平均新增代码从415.5行降到111.7行。

验证行为变化最明显：运行正式测试的轨迹从37.5%升至73.3%，首次测试位置由整段轨迹的70.8%提前到62.0%，测试通过后继续编辑的比例从5.9%升至12.9%。这些指标与更有方向的调查、更聚焦的修改和更早的验证一致，但它们仍是间接信号；较小补丁不必然更好，参考补丁也不是唯一正确实现，目标稳定性还没有可用的聚合指标。

[表5：731组SWE-Bench Pro轨迹的行为指标] 对比基模型与训练后模型的检索、参考文件覆盖、补丁规模，以及正式测试的频率和时机。

5.8点支持执行行为迁移，还没有证明办公数据更优

现有结果支持的答案：长程办公post-training带来的变化能够迁移到软件工程，GDE四种行为为这种变化提供了统一描述。训练数据没有传授仓库规范或代码级答案，轨迹中却同时出现更完整的状态构建、更稳定的约束保持和更主动的环境验证，因此“模型更会组织并调用预训练阶段已有知识”是一个与证据一致的解释。

因果结论还缺少关键对照。全部结果来自一个基模型和一次训练；研究没有分别消融深度分解、并行综合、纠缠约束与长依赖链，也没有比较等预算软件工程数据。用于解释的案例还集中在“基模型失败、训练后成功”的103个任务，适合展示改善如何发生，不能估计每种行为改善的普遍程度。对训练数据设计而言，这项工作给出了值得验证的方向：除了题材相似度，还要测量任务究竟锻炼了哪些执行行为；它尚未提供一套可直接照搬的跨领域训练配方。