🤖 AI

SkillForge: Self-Distilling Agents for Project-Specific Issue Resolution

SkillForge 是一个自我蒸馏框架，它通过合成并解决源自核心功能的虚拟问题，主动增强大语言模型智能体在特定代码库中解决软件问题的能力，从而在不依赖历史修复数据或高昂的测试时探索的情况下，蒸馏出可重用的、基于实体锚定的项目知识。

原作者： Silin Chen, Han Li, Xiaodong Gu, Yuling Shi, Haibing Guan

发布于 2026-08-20

📖 1 分钟阅读☕ 轻松阅读

原作者： Silin Chen, Han Li, Xiaodong Gu, Yuling Shi, Haibing Guan

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

在现代软件那广阔而复杂的景观中，代码是构建我们数字世界的基石。当复杂的程序出现故障时，修复它通常不仅需要对损坏的部分有深刻理解，还需要了解该部分如何与整个机器协同工作。几十年来，人类一直是这项工作的核心机械师，但最近，人工智能已开始拿起工具。大型语言模型——这些经过海量文本和代码训练的强大计算机程序——已经展示出它们能够浏览这些数字仓库、寻找漏洞并编写修复方案的能力。然而，一个显著的障碍仍然存在：当面对特定的、陌生的项目时，这些 AI 智能体往往会感到吃力。它们缺乏局部上下文——即那些不成文的规则、不同代码部分之间相互通信的具体方式，以及该特定软件构建过程中的独特历史。没有了这些内部知识，AI 就像是一位被丢进一个从未见过的车库里的天才机械师，每次遇到新问题时都不得不被迫猜测引擎的工作原理。

上海交通大学的研究人员开发了一种解决这一问题的新方法，他们称之为 SkillForge。该系统并非等待 AI 在现实世界的错误中跌跌撞撞并随着时间的推移从错误中学习，而是主动在 AI 尝试进行实际修复之前，就对其进行特定项目的教学。团队意识到，要理解一个项目，AI 需要先在上面进行练习。因此，他们创建了一个训练场，让 AI 生成自己的虚假问题。通过提取软件项目的核心功能（即那些已经被测试过且已知运行正常的部件），并要求 AI 从头开始重写它们，该系统迫使 AI 犯错。由于 AI 无法访问原始代码，它必须依赖其通用知识，这不可避免地会导致与该项目实际构建方式相关的错误。研究人员将这些错误称为“合成问题”，并将它们作为学习工具。AI 尝试修复这些虚假漏洞，并在此过程中揭示了该软件项目的隐藏模式和特定规则。

随后，系统会将 AI 解决这些虚假问题时所采取的路径提炼成一套“技能”。可以将这些技能想象成针对该特定软件的个性化指南手册。研究人员将这些知识组织为两种类型。第一种类型是高层级地图，帮助 AI 理解项目的整体结构，例如不同代码部分的作用及其通常的交互方式。第二种类型是针对 AI 实际编辑代码时的具体指令，提醒它注意常见的陷阱，并告知它项目独特的特性。当 AI 稍后被要求解决该相同软件中的真实问题时，它会查阅这份指南手册。它首先加载高层级地图以确定方位，然后在深入挖掘代码时，会接收到关于其需遵循的特定规则的即时提醒。这一过程是自动完成的，确保 AI 在需要时能获得正确的上下文。

研究人员在广泛的现实世界软件项目上测试了这种方法，并使用了两种不同的强大 AI 模型来验证其有效性。他们将该系统与其它试图通过学习人类过去的修复记录或通过在解决问题时探索代码来辅助 AI 的方法进行了对比。结果非常明确：SkillForge 方法的表现始终优于其他方法。在一项标准的软件工程任务测试中，与没有任何特定项目知识的基准模型相比，该系统将 AI 的成功率提高了近六个百分点。即使研究人员在另一组更具挑战性的难题上测试该系统时，这一提升依然成立。研究表明，通过在正式工作开始前教授 AI 关于特定项目的知识，该系统能够比那些试图在过程中边学边做或依赖可能无法覆盖当前问题的历史数据的模型，更准确、更高效地解决问题。

研究中最具启发性的观察之一是，观察到 AI 的行为如何随着这种新知识而发生变化。在一个涉及流行 Web 框架中复杂格式错误的特定案例中，没有经过此类训练的 AI 很快就采用了一个看似正确但经测试无法满足完整需求要求的简单且错误的解决方案。它忽略了处理数据所需的细微且具有项目特性的逻辑。相比之下，配备了 SkillForge 指南手册的 AI 则采取了更加谨慎、结构化的方法。它停下来考虑项目的特定规则，避开了未经训练的 AI 会掉入的常见陷阱，并最终找到了通过所有必要测试的解决方案。这表明，该系统不仅仅是在给 AI 提供更多信息，而是在从根本上改变它对代码的推理方式，帮助它避免因将通用规则应用于特定、独特环境而导致的错误。

研究人员还探讨了从一个 AI 模型中获得的知识是否可以转移到另一个模型中。他们发现，由一个模型提炼出的技能在由同一个模型使用时最为有效。这表明，这些知识与特定 AI 如何思考和编写代码深度绑定，而非关于软件的通用事实集。这一发现强调了该系统的价值在于其捕捉特定 AI 与特定项目交互方式的能力。此外，研究表明，当系统专注于同时重写多个相互关联的部分，而非仅仅是孤立的单个函数时，效果最好。这种方法捕捉了不同部分之间的复杂交互，而这正是最关键的项目特定知识隐藏的地方。

最终，这项工作为弥合强大的通用 AI 与现实世界软件工程特定需求之间的差距提供了一种新途径。通过从一种“反应式”方法（即 AI 在错误发生后才从错误中学习）转向一种“主动式”方法（即在比赛开始前学习游戏规则），研究人员展示了一条通往更可靠、更强大的软件智能体的路径。该系统不需要庞大的过去人类修复的历史记录来运作，也不要求 AI 在实际修复过程中浪费时间和资源去盲目探索代码。相反，它构建了一个针对性的、高效的知识库，让 AI 能够迅速进入状态。结果表明，要让 AI 真正成为软件开发的合作伙伴，必须给它机会去学习它所从事项目的特定语言和习俗，而 SkillForge 为实现这一点提供了一种切实有效的方法。

技术摘要：SkillForge

问题陈述

基于大语言模型（LLM）的智能体在自动化软件问题解决方面已展现出显著的能力，特别是在 SWE-bench 等标准基准测试上。然而，在将这些智能体部署到特定的、真实的仓库时，一个关键的瓶颈出现了：冷启动问题。智能体通常缺乏特定于项目的知识，例如结构规律性、循环出现的失败模式、特定的 API 契约以及特定于代码库的隐式执行路径。

现有的方法在弥补这一差距方面是响应式的而非主动式的：

历史驱动型方法（如 EvoCoder、SWE-Exp）从历史性的问题解决轨迹中提取知识。这些方法受限于过去问题的覆盖范围和质量；它们无法学习尚未被历史数据触发的仓库行为或组件。
在线方法在当前问题的测试时探索过程中优化智能体。虽然有效，但这类方法在每个问题上都会产生巨大的 Token、时间和计算资源成本。

本文认为，等待真实问题的积累或依赖昂贵的在线探索是不充分的。需要一种框架，能够在尝试解决真实问题之前，主动从仓库本身获取特定于项目的知识。

方法论：SkillForge

SkillForge 是一个自蒸馏框架，旨在通过直接从仓库的代码和测试中合成问题，来主动获取特定于项目的知识。该框架通过四个不同的阶段运行：

1. 特定于项目的议题合成

与其等待真实的缺陷报告，SkillForge 通过重写仓库的核心功能来生成合成议题。

测试驱动范围：框架识别覆盖核心功能的测试用例，并在覆盖率插桩下执行这些测试以生成执行轨迹。
关键片段选择：LLM 选择由这些测试触发的高影响代码段（函数或内聚的代码片段）。
代码重写：要求 LLM 在“严格掩码（strict-mask）”约束下重新实现这些片段。至关重要的是，LLM 不会获得原始实现，仅接收周围的上下文和测试的目标。这迫使模型依赖通用的编程知识，通常会导致违反项目特定规范（例如 API 耦合、特定的执行路径）的实现错误。
实例组装：重写的代码会引发测试失败。这些失败被转换为合成的议题实例（问题陈述、错误的补丁、参考补丁），其格式模仿了标准的 SWE-bench 任务。

2. 技能蒸馏

一个 SWE 智能体尝试解决这些合成议题。产生的动作轨迹随后被蒸馏为双层技能库：

全局诊断技能 ( $M_{ext}$ )：捕捉用于诊断和导航的项目级知识。对于每个仓库实体，它记录了：
- 用途：该实体在问题解决中的角色。
- 剧本（Playbook）：在解决过程中经过验证的可复用推理策略。
- 相关 API：API 之间特定于项目的交互模式。
局部干预技能 ( $M_{int}$ )：捕捉针对特定实体的修改指南。它记录了来自成功和失败轨迹的可操作教训，例如“避免覆盖 X”或“确保调用了 setup_query”，以防止重复出现的陷阱。

3. 技能适配（检索与注入）

在下游的真实问题解决过程中，SkillForge 通过两阶段机制利用蒸馏后的知识：

宏观级初始化：在解决问题之前，根据议题描述检索相关的全局诊断技能 ( $M_{ext}$ )，并将其前置到智能体的提示词中，以提供高层级的项目上下文。
微观级即时（JIT）注入：当智能体与代码交互（例如，执行 Shell 命令读取文件）时，系统会动态注入与所访问实体相关的局部干预技能 ( $M_{int}$ )。这确保了在智能体遇到特定代码区域时提供指导，从而避免上下文噪声。

核心贡献

主动式自蒸馏范式：本文提出了一种解决冷启动问题的新方法，通过直接从仓库的测试和代码中获取特定于项目的知识，消除了对丰富的历史议题轨迹或昂贵的单议题在线探索的需求。
双层技能库：设计了一个结构化的知识库，将全局诊断技能（用于导航和推理）与局部干预技能（用于特定的代码修改）分离，实现了基于实体的检索和即时指导。
实证验证：广泛的实验表明，这种主动获取策略在不同的基准测试和模型骨干网络上均显著优于历史驱动和在线基准方法。

实验结果

该框架在 SWE-bench Verified (500 个任务) 和 SWE-bench Pro (731 个任务) 上使用 DeepSeek-V3.2 和 GPT-5-mini 进行了评估。

性能提升：
- 在 SWE-bench Verified 上，SkillForge 实现了 72.2% (DeepSeek) 和 60.6% (GPT-5) 的 Pass@1，相比基准 Mini-SWE-Agent 分别提升了 +5.8% 和 +5.6%。
- 在 SWE-bench Pro 上，它实现了 34.1% (DeepSeek) 和 51.7% (GPT-5) 的 Pass@1，相比基准分别提升了 +5.8% (DeepSeek) 和 +4.1% (GPT-5)。
对比：SkillForge 优于所有评估的历史驱动（如 MemGovern、SWE-Exp）和在线（如 SAGE、SWE-Debate）基准。值得注意的是，它避免了与在线探索方法相关的高昂单议题成本。
消融研究：
- 移除全局或局部技能中的任何一种都会导致性能显著下降，证实了两种知识类型的必要性。
- 可迁移性：研究发现蒸馏的知识具有 LLM 特异性。由一个模型（如 DeepSeek）蒸馏的知识对另一个模型（如 GPT-5）的收益较小，这表明在合成过程中暴露出的“不匹配”是依赖于模型的。
超参数：适度的检索数量 ( $k_r=5$ ) 和合成范围 ( $k_s=5$ 个片段) 产生了最优结果；过多的检索或重写引入了冗余或复杂性，从而降低了性能。
泛化能力：SkillForge 在七个不同的仓库（如 Django、Scikit-learn、Sphinx）中表现出一致的改进且没有退化，而历史驱动的基准方法表现出不一致的性能并偶尔出现退化。

意义与主张

本文主张，在解决真实问题之前主动获取特定于项目的知识是一种比响应式获取更优越的策略。通过合成能够暴露智能体通用编程先验与仓库特定实现模式之间差距的议题，SkillForge 创建了一个可复用的、基于实体的知识库。

作者强调，这种方法：

在无需依赖可能稀疏或有偏差的历史数据的情况下，解决了冷启动问题。
避免了为每个新问题进行高昂的在线测试时探索的成本。
提供了一种可扩展的机制，使通用目的 LLM 智能体能够适应特定的代码库，从而实现更鲁棒、更准确的问题解决。

该工作得出结论，从仓库本身进行知识的“自蒸馏”，而非从外部历史或实时试错中获取，是增强软件工程智能体的一种有效且可扩展的替代方案。