天工不止造物,也能修bug:Skywork-SWE给代码智能体补上软件工程课

机器之心报道

编辑：Panda

400 多年前，宋应星著成《天工开物》。这是一部写给匠人、也写给未来的书。它让人相信：技术不是死物，而是人与世界持续互动的方式。

如果说「天工」代表了中国古代对「工程」与「制造」的极致理解，那么今天，一个同样以「天工」（即 Skywork）为名的 Agent 智能体，正试图在另一片疆域（代码世界）中，继承这份精神。

这个 Skywork，不是炼铁铸器的匠人，而是自主代码智能体基座模型，要修补的是一种现代最复杂的人造系统：（开源）软件工程。它不握锤凿，而是靠多轮交互、长上下文理解与逻辑推理，在成千上万的 GitHub 项目中识别 issue/bug、定位原因、打补丁，并验证是否真的修好了。故此，它得名Skywork-SWE。（注：SWE 是指软件工程 / Software Engineering。）

Skywork-SWE 因何而生？

软件智能体面临的困难

在古人的世界里，修一口破鼎、补一段布帛是「匠人精神」的体现。而在今天，最频繁「破裂」的，莫过于代码。

如今，代码系统早已成为现代文明的骨架。它们运行在日常软件、银行服务、交通调度等各式系统中，也支撑着我们所依赖的 AI 算法本身。但和古代器物一样，再精妙的程序也难免出现 bug—— 有些是逻辑失误，有些是环境变迁，有些甚至源于协作失控。比如，就在前几天，AWS、谷歌云、Azure 和 Cloudflare 都发生了中断，连带着 ChatGPT 和 Cursor 等热门 AI 应用也一并短暂失联；而这一事故的原因可能是一次错误的自动配额更新导致谷歌的 API 管理系统出现了故障。

同时，bug 修复也是软件工程中最基础，却也是最复杂、最消耗人力的任务之一。特别是在真实的 GitHub 项目中，修一个 bug 并不是「找到一行错字那么简单」，它常常需要：

• 读取和理解成百上千个文件；
• 推演变量在不同模块的流动路径；
• 阅读前人留下的修复记录与讨论；
• 理解上下文、猜测意图、编写代码补丁；
• 最后，还得跑几遍测试，看看是不是真的「已解决」。

那么，我们能否使用 AI 智能体来完成这些任务呢？

当然可以！但我们需要的绝不是传统的用于解决单独编程任务的 AI 编程模型，而是需要像人类开发者一样能够理解历史上下文、进行多轮推理、在模糊与不确定中做决策、具备落地执行的能力的软件工程智能体。

而难题也随之而生：这类任务长期缺乏高质量训练数据。市面上现有的 SWE 数据集，不是验证机制不足，就是训练样本杂乱无章，难以支持模型在真实工程中进化。另外，这些数据集的规模普遍较小，导致数据 Scaling Law 适用性不明确。

正是为了应对这种挑战，昆仑万维推出了自主代码智能体基座模型 Skywork-SWE。它不仅代表一个性能卓越的模型 ——32B 参数量级别的最强开源软件工程智能体，更是一个集数据、验证、推理与修复为一体的完整系统。不仅如此，他们还基于此成功揭示了LLM 软件工程能力的 Scaling Law

目前，该模型的技术报告和模型权重都已发布。

• 技术报告：https://huggingface.co/Skywork/Skywork-SWE-32B/resolve/main/assets/Report.pdf
• 技术博客：https://quixotic-sting-239.notion.site/eb17f379610040ceb54da5d5d24065bd
• 模型权重：https://huggingface.co/Skywork/Skywork-SWE-32B

Skywork-SWE

数据锤炼出的智能工匠

那么，昆仑万维究竟是如何打造出 Skywork-SWE 的呢？

核心的秘诀在于：在软件工程任务上高质量地达成了数据 Scaling Law

为了获得高质量数据，昆仑万维构建了构建了一套自动化、结构化、可复现的 SWE 数据收集与验证流程，共分为三大阶段、九个步骤。

最终，他们从 15 万个 GitHub 开源项目中筛选出 10,169 个真实代码问题和 8,209 条多轮交互轨迹，构建出了业内最大规模、可验证的 SWE 数据集，其中每一个样本都不是「描述性」的，而是「工程级」的：

• 每条任务都能在 Docker 中复现；
• 每个补丁都要通过单元测试验证；
• 每条智能体轨迹都覆盖完整修复闭环。

下图展示了其完整的数据构建流程：

数据构建流程图

具体来说，阶段 A 的工作是数据采集与预筛选，其中又细分为 GitHub 元数据抓取、PR（Pull Request）收集与任务初筛和安装验证 3 个步骤。第一阶段的处理下来，昆仑万维团队从 15 万个开源仓库中得到了 23,389 个有效任务样本。为了防止数据泄漏，排除 SWE-bench Verified（测试数据集）已包含的仓库。

而阶段 B 则是环境设置和基于执行的验证。同样，这一阶段也分为三个步骤：统一命令生成、Docker 环境构建和单元测试验证。很容易看出来，这一步的目标是确保问题的修复是有效的，进而进一步保证数据的质量。

最后，还需要针对每个任务生成正确的智能体轨迹。这也正是阶段 C 的任务目标。同样地，三个步骤：首先，昆仑万维团队基于开源的 OpenHands 代码智能体框架，选用代码能力突出的商用大模型（如 Claude，DeepSeek 等）作为智能体基座，对每个任务执行最多 100 轮交互，完整记录智能体在问题求解过程中的交互轨迹。然后，他们进行了 Patch 级的验证，以确保智能体行为严格对齐仓库级代码修复目标。最后，构建训练样本库，得到了 8,209 条高质量、长上下文、多轮交互的经过验证的轨迹。

走完全流程后，昆仑万维团队得到了一个当前规模最大、质量最高且可验证的软件工程任务数据集：Skywork-SWE。是的，正是基于该数据集，昆仑万维训练出了同名的自主代码智能体模型：Skywork-SWE-32B！（注：32B 是指模型参数量。）

数据构建过程中各个阶段数据样本量变化图

在任务数量与代码覆盖广度方面，Skywork-SWE 远超现有同类数据集（如 SWE-Gym Lite 与 SWE-bench Verified），可为大模型提供丰富、多样且贴近实际的软件工程任务样本，进而持续推动智能体模型的能力进化。

更具体而言，如下左表所示，相较于其他基准数据集，Skywork-SWE 中的任务在编辑复杂度上显著更高：平均每个补丁涉及 2 个以上函数修改、6 个代码块、以及多达 74 行代码变更，能更真实地反映GitHub 开发中的问题修复复杂度。这也意味着，模型要在此类任务中实现有效修复，必须具备更强的代码理解、上下文建模与多轮交互推理能力。

Skywork-SWE 数据集统计表与 GitHub 仓库词云图

而右图则给出了 Skywork-SWE 数据集的仓库名称词云。可以看到，其中不仅涵盖如 Pydantic、SQLGlot、DVC 等主流开源项目，还包含大量中小型仓库，呈现出高度贴近真实开发生态的任务分布特征。这种贴近真实开发生态的数据构成，有助于提升模型在复杂多样场景下的问题解决能力。

这些能力也在基于 Skywork-SWE 数据集微调得到的 Skywork-SWE-32B 模型上得到了体现。（注：采用的基座模型是 Qwen2.5-Coder-32B-Instruct）。

Skywork-SWE-32B 的实验表现

在广受关注的 SWE-bench Verified 基准（包含 500 个实例，来自 12 个流行 Python GitHub 库的 PR）上，Skywork-SWE-32B 在 OpenHands Agent 框架下取得了 47% 的准确度，超越了现有参数规模在 32B 以下的开源模型，甚至优于参数量高达 671B 的 DeepSeek-V3-0324 模型。

而在这个亮眼成绩背后，他们的实验还成功揭示了 LLM SWE 能力在数据方面的 Scaling Law：随着训练数据规模的持续扩展，SWE 模型性能会持续提升，充分验证了「数据 scaling 带来的性能增益」在软件工程任务中的有效性与适用性。Skywork-SWE-32B 实现了 38.0% pass@1 准确度，刷新 Qwen2.5-Coder-32B 系列模型在 OpenHands 代码框架下的最佳成绩。

可以看到，随着训练轨迹数量的增多，Skywork-SWE-32B 的性能会持续提升。请注意，上图的横轴采用了指数刻度，这意味着模型性能几乎呈指数级随数据增长而提升。更重要的是，在当前数据集规模范围内，性能提升尚未出现饱和迹象，这充分揭示了进一步扩展高质量数据的巨大潜力。

另外，为了在推理阶段进一步释放模型能力，昆仑万维团队也实验了测试时扩展（TTS）技术对 Skywork-SWE-32B 带来的提升，充分释放了模型的潜力，在 Best of 8 的测试下即可达到 47% 的正确率。

下图展示了其具体在不同仓库上的得分情况。

相较于主流的一些闭源模型，经过 TTS 后的 Skywork-SWE-32B 的表现也相当不俗：显著超越了 GPT-4.1-mini（23.86%）、 Claude 3.5 HaiKu（40.6%）和 OpenAI-o1-preview (41.3%)，并且领先于 Claude v3.5（46.0%）。

下面通过一个实际案例来看看 Skywork-SWE-32B 的工作过程。

以用 Python 编写的、用于天文学的通用核心软件包 Astropy 及对应的 #14309 PR 为例。

Astropy 仓库 issue：修复当提供的文件路径没有 args 参数时 FITS 链接逻辑崩溃问题。

向 Skywork-SWE-32B 模型输入上述 Astropy 仓库 issue 和相应的代码仓库，可以看到该模型能精准定位问题源文件与具体缺陷，并生成 patch 修复方案。

生成 patch 修复方案示例图

如下所示，Skywork-SWE-32B 生成的方案成功通过了全部测试样例，实现了在 GitHub 代码仓库中从问题理解到解决的一站式代码修复。

单元测试结果示例图

Skywork-SWE-32B 的优异表现充分验证了 Skywork-SWE 数据集的高质量与实际价值。

一份数据集

撬动一个智能体时代

在大模型走向智能体时代的今天，真正稀缺的已不是算力，也不是参数，而是经得起验证、贴近真实、具备闭环反馈的数据。

Skywork-SWE 的意义，恰恰在于此。它不仅仅代表了一个模型，而是一套系统化构建真实工程数据的范式，其中收集的不是孤立的函数调用或代码段，而是成千上万个来自 GitHub 仓库的实际修复任务 —— 每一条都能在环境中复现、通过测试、形成可追踪的智能体交互轨迹。

这份数据集不仅让 Skywork-SWE-32B 成为当前 32B 参数规模下最强的开源软件工程模型之一，更重要的是，它揭示了 LLM 在 SWE 任务中持续增长的性能与数据之间的强相关性，首次系统性验证了数据 Scaling Law 在复杂工程任务上的适用性，堪称软件工程智能体的「ImageNet」。

昆仑万维表示，未来 Skywork-SWE 数据集还将向更多编程语言扩展；另外，其在运行时环境中执行并验证单元测试的设置也有助于近期 LLM 社区对在线强化学习方法的探索。

这背后，折射出昆仑万维对行业趋势的清醒判断：大模型走得再远，最终也要落到真实任务中；开源要想站稳脚跟，必须在「数据+系统+执行力」上全面补强。

过去一年里，昆仑万维围绕 Skywork 系列已布局从 MoE 架构、预训练模型到智能体框架与垂直场景的全链条。我们看到了多模态推理模型 Skywork-R1V 以及超越 Suno V4 的音乐模型 Mureka O1，甚至还有国内首个短剧创作大模型 Skyreels-V1、可交互视频生成世界模型 Matrix-Game 和 Matrix-Zero 以及堪称智能体界的全能型选手的天工超级智能体（Skywork Super Agent）。而更妙的是，以上这些模型大都是开源的！（可点击对应链接了解详情。）

Skywork-SWE 的推出，标志着这一体系进一步落地，也是昆仑万维在代码、内容、办公等智能体任务场景长期探索的延续。在这个探索中，他们不仅造模型，更造数据；不仅做生成，还进行验证。而放眼未来，这种以高质量任务型数据为基础的智能体训练范式，或将成为代码、软件工程乃至通用多模态智能体的「标准工艺」。

天工再起，从数据开始。Skywork-SWE 是对「工程智能体」时代最扎实的回答，也是昆仑万维写下的一份面向行业的「天工开物」。