SkillForge: 自蒸馏智能体用于项目特定问题解决

TL;DR SkillForge 通过重写仓库测试覆盖的核心功能来合成项目特定 issue，并从中蒸馏可复用的实体锚定技能，让 LLM agent 在遇到真实缺陷前主动获得项目知识，显著提升软件 issue 解决率。

问题

问题背景

LLM 智能体在自动化软件缺陷修复（如 SWE-bench 任务）中表现优异，但面对特定代码仓库时，常因缺乏项目专属知识而失败。

现有方法局限

现有自进化方法试图从仓库历史或在线修复轨迹中补充项目知识，但存在两类明显短板：

• 依赖历史 issue-resolution 信号：若仓库历史修复记录稀疏或质量低，知识获取受限。
• 在线探索成本高：针对每个真实 issue 在测试时大量探索，带来显著的推理开销与延迟，难以规模化。

这些方法被动等待真实问题暴露知识缺口，效率与覆盖均不理想。

为什么难/重要

项目专属知识难以从通用预训练中获得：每个仓库的 API 约定、模块结构、隐式约束各不相同。合成高质量、与真实功能对齐的 issue 需要在仓库测试覆盖范围内自动定位核心功能并构造可验证的修复任务，技术挑战不小。业界对自动化修复的关注持续升温，减少人工介入、提升真实项目中的修复成功率是核心诉求。

行业类比

类似主动学习在训练前合成任务样本——SkillForge 提前从仓库中“锻造”问题与技能，用合成数据增强提升下游 agent 的领域适应性。

核心洞察

• SkillForge 的核心创新在于将项目特定知识获取从被动响应转为主动合成问题驱动的自我蒸馏。与依赖历史 issue 或在线修复轨迹的自进化方法不同，SkillForge 通过重新实现测试覆盖的核心功能来合成项目特定问题，再通过解决这些问题蒸馏出可复用技能，无需等待真实 issue 暴露知识缺口，避免了在线探索的高成本，实现了低开销且不依赖历史信号的主动知识构建。
• SkillForge 将项目特定知识表示为与仓库实体绑定的技能（entity-grounded skills），使知识检索和复用高度精准。与现有方法存储原始修复轨迹或非结构化经验不同，SkillForge 在蒸馏过程中将技能关联到具体的代码实体（如类、函数、文件），使得解决新问题时能根据涉及的实体快速调用相关技能，显著提升了知识在跨 issue 和跨模型场景下的可迁移性与适应效率。

方法

SkillForge 的输入是目标 repository 的源代码与测试套件，不依赖历史 issue 或在线修复轨迹。流程分为三个阶段：

输入与问题合成

• 从 repository 中识别被测试覆盖的核心功能，将其视为需重新实现的模块。
• issue 合成：让 LLM 为这些核心功能自动生成拟真 issue，描述缺失或待重构的行为，而非真实 bug。

关键模块：技能蒸馏与关联

• 用基础 agent 解决合成 issue，产生修复 patch 与推理轨迹。
• 技能蒸馏：从解决过程中提取可复用的操作模式、约定与实体交互，蒸馏为 entity-grounded skills（实体锚定技能），并绑定到相关 repository 实体（如类、函数、配置）。
• 将这些技能存入按实体索引的技能库，供后续 retrieval 使用。

输出与适应

• 面对真实 issue 时，技能适应 模块根据当前 issue 涉及的实体检索对应技能，注入 agent 的 prompt 或工具调用中，指导导航与修改。
• 最终输出为增强后的 agent 行为与修复 patch，提升特定 repository 的 issue 解决率。

与现有 self-evolving 方法相比，SkillForge 的关键差异在于“主动从 repository 本身合成训练信号”，避免了对历史 issue 信号的依赖，也无需在每个真实 issue 上付出高昂的 test-time 探索成本。

实验

实验设计

论文在多个开源和闭源 LLM 后端上评估 SkillForge，覆盖多种软件仓库（细节见正文）。基线包括强自演化方法与直接 issue 解决 agent。实验设置包含四个研究问题：整体有效性、消融、超参数影响、跨仓库泛化。

关键发现

• SkillForge 相比强基线一致提升 issue 解决性能，且提升在开源/闭源模型上均稳定。
• 消融表明合成 issue 与 entity-grounded skill 蒸馏均贡献显著。
• 超参数敏感性低，跨仓库迁移有效。

基线对比解读

与依赖历史 issue 或在线探索的自演化方法相比，SkillForge 通过主动从仓库自身合成 issue 并蒸馏技能，避免了对历史信号的依赖和测试期探索开销。其增益来源于前置获取项目特定知识，而非更强的修复策略。

行业影响

落地场景

SkillForge 适用于大型软件仓库的自动化问题修复，特别适合代码托管平台（如 GitHub、GitLab）、企业内部 DevOps 平台、AI 编程助手（如 GitHub Copilot 的后端增强）以及软件维护服务。对于新启动项目或历史 issue 数据稀疏的仓库，该框架可以离线预生成技能库，无需真实缺陷样本即可储备修复知识。

商业价值

通过提前蒸馏项目特定技能，降低修复每个 issue 时的探索成本，提升首次修复成功率。对于企业而言，这直接减少开发人员排查时间，缩短故障修复周期，进而降低线上事故造成的业务损失；对于代码托管平台或工具厂商，可以作为增值能力提升客户留存与订阅价值。

与现有工作流接口

SkillForge 作为离线阶段先于真实 issue 处理执行：从仓库源码和测试中生成合成 issue → 求解并蒸馏技能 → 将技能与仓库实体关联入库。部署时可作为CI/CD 前置任务或代码仓库机器人插件，输出技能索引文件；在线 issue 解析 agent 只需查询该索引即可调用对应技能，无需修改原有 agent 架构。相比依赖历史修复轨迹的方法，它不需要仓库有大量已解决 issue；相比 test-time 探索方法，它将探索成本转移到离线阶段，在线响应更快。

具体 use case：

• 电商平台核心交易系统：对订单、库存、支付等测试覆盖的核心模块，SkillForge 主动合成边界条件和并发场景 issue，蒸馏出的技能可帮助修复 agent 快速定位真实生产缺陷，减少大促期间故障影响。
• 金融行业核心系统：银行支付网关或风控服务通常变更谨慎、真实缺陷样本少，SkillForge 从单元测试逆向生成合成问题并预训练修复技能，提高自动化修复的可信度，降低人工介入风险。

局限

• - 合成 issue 与真实 issue 存在分布偏差。论文通过重新实现测试覆盖的核心功能来合成 issue，但真实缺陷常源于非预期交互、边界条件或外部依赖变化，合成 issue 难以覆盖这些复杂场景，导致蒸馏技能在处理真实 issue 时泛化有限。若仓库测试覆盖不足，可合成的 issue 数量和质量会明显下降，框架效果可能打折扣。论文在威胁有效性讨论中应承认这一外部效度问题。
• - 方法引入一次性前期成本。运行 LLM 合成 issue、解决它们并蒸馏技能需要额外准备时间和计算资源，虽然避免了 per-issue 测试时探索，但对小型仓库或 issue 数量很少的项目，前期成本可能超过收益。此外，蒸馏出的技能需要随仓库代码演化持续更新，否则可能过时，论文未给出技能维护或失效检测机制，长期可用性存疑。
• - 实验覆盖范围和泛化性有限。实验可能仅针对 Python 仓库和 SWE-bench 类数据集，未验证多语言、大型单体仓库或特定领域项目。虽然使用了多个开闭源 LLM，但模型列表未必涵盖所有主流架构，且技能跨模型迁移能力可能受骨干模型特性影响，结论的普适性需要更多实证支持。