Qwen3-Coder-Next：80B参数只激活3B，如何用"小代价"训出最强编程智能体

论文标题：Qwen3-Coder-Next Technical Report
作者：Qwen Team
机构：Alibaba Group
日期：2026-03
链接：https://arxiv.org/abs/2603.00729

---

一句话总结

阿里Qwen团队发布了Qwen3-Coder-Next——一个总参数80B、每次推理仅激活3B的稀疏MoE编程智能体模型。通过大规模合成可验证编程任务（约80万条，覆盖9种语言）、多阶段专家蒸馏训练流程、以及一系列反奖励黑客的工程手段，在SWE-Bench Verified上达到70.6%（pass@1）和71.3%（majority@3），登顶开源编程智能体排行榜。

---

为什么需要这篇论文？

编程智能体的"规模化训练"困境

过去两年，AI编程经历了从"代码补全"到"智能体式开发"的范式转移。Claude Code、Cursor、Devin等产品已经证明了一件事：未来的AI编程不是"写一个函数"，而是"理解一个仓库、定位一个bug、规划修改方案、执行多步操作"。

这种智能体式的编程对模型提出了全新的挑战。传统的代码基准（HumanEval、MBPP）测的是"给你一个函数签名，把函数体补完"——这在2024年就已经被各家模型刷到了90%+，基本失去了区分度。真正有意义的基准是SWE-Bench：给你一个真实的GitHub仓库和一个issue，你需要理解代码库结构、定位问题文件、生成正确的patch。

问题在于：训练这样的模型需要什么样的数据？ HumanEval/MBPP的训练数据好造——算法题有标准答案，写个测试用例就行。但SWE-Bench级别的任务呢？每个任务都涉及一个完整的代码仓库，有复杂的依赖和执行环境，验证一个solution需要跑整个测试套件。这种数据不可能靠人工标注来获取。

Qwen3-Coder-Next这篇论文要解决的核心问题就是：如何大规模合成高质量的、可执行验证的编程智能体训练数据，并设计一套有效的训练流程把这些数据转化为模型能力。

图1：Qwen3-Coder-Next与Claude Sonnet 4、Gemini 2.5 Pro、GPT-4.1在7个编程基准上的对比。蓝色是Qwen3-Coder-Next，在SWE-Bench Verified、Terminal-Bench、MLE-Bench等智能体型基准上表现突出，与闭源顶级模型打得有来有回。

这张雷达图传递了一个清晰的信号：在编程智能体这个赛道上，开源模型第一次真正摸到了闭源最强模型的天花板。尤其是在SWE-Bench Verified（70.6%）和Terminal-Bench（67.5%）上的成绩，已经可以和Claude Sonnet 4正面硬刚。考虑到Qwen3-Coder-Next只是80B总参数、3B激活参数的"小"模型——对比Claude和GPT系列动辄数百B激活参数的巨无霸——这个效率优势是非常显著的。

---

模型架构：512个专家里只选3个

为什么选MoE？

Qwen3-Coder-Next基于Qwen3-Next基座模型构建。Qwen3-Next采用了Hybrid Attention + Sparse MoE架构：总参数80B，包含512个专家（experts），每次前向传播只激活3个专家，实际激活参数仅约3B。

为什么用MoE而不是Dense模型？原因很直接：编程智能体的推理开销极大。一个SWE-Bench任务可能需要模型生成上千个token的思考过程（读取文件、分析代码、规划修改、生成patch），如果用80B Dense模型来跑，每个token的计算量都要过80B参数，推理成本会高到无法实际部署。MoE让你在保持80B的"知识容量"的同时，只付出3B的推理成本——这是一个约27倍的效率提升。

这里要多说一句关于512个专家的选择。当前主流MoE模型的专家数量差异很大：DeepSeek-V3用了257个（选8个），GLM-5用192个（选8个），Qwen3-Coder-Next则用了512个但只选3个。选更多专家+更少激活是一种更极端的稀疏策略，它的好处是每个专家可以更"专精"，坏处是路由决策更难做好。从结果来看，Qwen团队显然认为在编程领域，让每个专家高度专业化是值得的。

Hybrid Attention的设计

Qwen3-Next的另一个架构特点是Hybrid Attention机制。论文没有展开太多细节，但结合Qwen3系列的技术演进来看，这里的"Hybrid"指的是在不同层使用不同的注意力模式——部分层用完整的Self-Attention处理全局依赖，部分层用更高效的变体（比如滑动窗口注意力或线性注意力）处理局部模式。这种混合策略在长上下文场景下可以显著降低计算开销，同时保持对关键信息的捕获能力。

---

数据引擎：80万条合成编程任务的制造工厂

这是整篇论文技术含量最高的部分。训练编程智能体的核心难题不是模型架构，而是数据——你需要大量的"仓库级"编程任务，每个任务都有完整的执行环境和自动化验证手段。Qwen团队设计了两条并行的数据合成流水线，最终产出约80万条覆盖9种编程语言的可验证训练实例。

流水线一：基于GitHub PR的真实任务挖掘

图2：两条任务合成流水线的整体架构。左侧是基于GitHub Pull Request的真实任务挖掘，右侧是基于合成Issue注入的任务生成。

第一条流水线的思路是：从GitHub的Pull Request历史中反向构建任务。具体流程如下：

1. 仓库筛选：从GitHub上筛选高质量代码仓库，要求有清晰的测试套件和CI/CD配置
2. PR分析：解析每个PR的diff，识别出哪些是"修复bug"或"实现feature"的有意义改动
3. 环境构建：为每个PR创建一个可复现的执行环境（Docker容器），回退到PR提交前的代码状态
4. 任务构造：用PR的描述作为任务输入，用PR的diff作为ground truth，用仓库的测试套件作为验证工具

这个思路并不新鲜——SWE-Bench本身就是这么构建的，之前的SWE-Smith也用了类似的方法。但Qwen团队在规模和覆盖度上做了大幅提升：他们不仅仅局限于Python仓库，而是扩展到了9种编程语言（Python、JavaScript/TypeScript、Java、C/C++、Go、Rust等），最终从这条流水线获取了大量多语言的真实编程任务。

流水线二：合成Issue注入——造出"从未存在过"的bug

第二条流水线更有创意：不是从已有PR中挖掘任务，而是主动向代码仓库注入问题，然后让模型来修复。

具体操作：

1. 选择一个健康的代码仓库（测试全部通过的状态）
2. 用LLM分析代码结构，识别出可以合理修改的位置
3. 让LLM在选定位置注入一个"合成bug"或"新需求"——比如故意修改一个函数的逻辑让它在边界条件下出错，或者添加一个新API但故意留下未实现的部分
4. 验证注入的改动确实会导致测试失败（否则这不是一个有意义的任务）
5. 生成对应的Issue描述，作为任务输入

这种方法的精妙之处在于：你不受限于已有的PR历史。一个仓库可能只有100个PR，但你可以在同一个仓库上注入上千个不同类型的合成问题。这极大地扩展了数据的多样性和规模。

两条流水线合计产出约80万条训练实例。论文特别强调了一个关键要求：所有实例都必须通过自动化测试验证。这意味着每个任务都有一个确定性的对错判断——模型生成的patch要么能让测试通过，要么不能。这种"可验证性"是后续进行强化学习训练的基础。

图3：随着合成训练数据量增加，模型在SWE-Bench Verified上的性能变化。横轴是数据量（对数坐标），纵轴是解决率。曲线呈现清晰的对数增长趋势——数据越多性能越好，但边际收益递减。

这张图揭示了一个重要的规律：编程智能体的数据scaling law是对数关系。从几千条数据扩展到几万条时性能提升最快，之后逐渐放缓。但即便在80万条的规模上，曲线仍未完全饱和——这暗示着继续扩大数据规模仍有收益空间。

---

中期训练（Midtraining）：打好地基

在正式进入智能体训练之前，Qwen团队先对基座模型做了一轮"中期训练"（Midtraining），主要目的是两个：

上下文窗口扩展

将模型的上下文窗口从预训练时的默认长度扩展到262,144 tokens（约26万token）。编程智能体需要处理的上下文极长——一个中等规模的代码仓库，光是关键文件的内容加起来就可能有数万token，再加上模型的思考过程和工具调用记录，26万token的窗口是刚需。

网页文档重格式化

Midtraining的另一个重要操作是将网页爬取的训练文档重新格式化为Markdown。这个看似简单的预处理步骤其实对编程智能体很关键——Markdown是代码文档的通用格式，让模型在预训练阶段就大量接触结构化的Markdown文本，有助于它在后续生成代码注释、PR描述、commit message时保持格式规范。

Fill-in-the-Middle（FIM）目标

Midtraining还引入了FIM训练目标——即给定代码的前缀和后缀，让模型预测中间被挖空的部分。这对编程场景非常自然：开发者经常需要在已有代码的中间位置插入新逻辑。FIM训练让模型具备了更好的"上下文感知的代码生成"能力。

---

训练流程：从专家到全才的蒸馏之路

Qwen3-Coder-Next的训练流程是一个精心设计的多阶段pipeline，其核心思想可以概括为：先分别训练各专项能力的"专家模型"，再把这些专家的知识蒸馏融合到一个统一模型中。

阶段一：专家模型训练

团队分别训练了四类专家模型：

专家类型	训练方式	目标能力
Web开发专家	SFT + 合成网页开发任务	前端/后端Web应用开发
UX专家	SFT + UI/UX评估数据	生成用户友好的界面和交互
单轮QA RL专家	强化学习 + 编程QA任务	代码理解、调试、解释
SWE专家	强化学习 + SWE-Bench风格任务	仓库级代码理解和修改

每个专家模型都从同一个经过Midtraining的基座出发，但使用不同的数据和训练策略进行特化。SWE专家是其中训练最复杂的一个——它需要在真实的代码仓库环境中进行多步强化学习，每一步的奖励取决于最终生成的patch是否能通过测试。

阶段二：知识蒸馏与融合

训练好专家模型后，并不是简单地选一个最好的就完事了。每个专家都在自己的领域很强，但在其他领域可能很差——SWE专家写不好前端页面，Web开发专家可能搞不定复杂的仓库级bug修复。

Qwen团队的做法是把所有专家的能力蒸馏到一个统一的学生模型。具体方法是：让每个专家模型在自己擅长的任务上生成高质量的response，然后用这些response作为SFT数据来训练统一模型。这就像让四个不同领域的顶尖程序员各自出一本教材，然后用这四本教材来培养一个全栈工程师。

这种"先专后通"的训练范式有几个明显的优势：

1. 每个专家可以用最适合的方法训练——SWE任务用RL效果最好，Web开发用SFT就够了，不用强求所有能力都用同一种训练方法
2. 避免了多任务训练中的干扰——直接在一个模型上同时训练所有能力容易导致task interference，能力之间互相拖后腿
3. 蒸馏过程比直接训练更稳定——学生模型学的是"专家的输出"而不是"原始奖励信号"，梯度噪声更小

---

强化学习训练：在执行环境中"做中学"

SWE专家的训练过程是整篇论文最具技术深度的部分。这不是简单的RLHF——模型需要在一个真实的代码仓库中进行多步交互，每步可以读取文件、搜索代码、执行命令、编辑文件，最终提交一个patch，然后运行测试来获取奖励。

图6：9个不同任务类别上的RL训练曲线。横轴是训练步数，纵轴是奖励值。大部分任务的奖励在前200步内快速上升，然后进入平台期。不同任务的最终收敛水平差异明显——Python修复类任务学得最快，多语言任务相对困难。

这组训练曲线揭示了几个值得关注的现象：

现象一：快速起步后的平台期。 大部分任务在训练前200步就能从接近零的成功率跳到30-50%，说明模型很快就能学会基本的"找文件→读代码→改代码→跑测试"流程。但后续的提升非常缓慢，从50%到70%可能需要数倍的训练量。这符合直觉——"学会做事"比"做好事"容易得多。

现象二：跨语言的难度差异。 Python相关任务的学习曲线明显高于其他语言。这可能有两个原因：一是预训练数据中Python代码的比例最高，二是Python生态的测试框架（pytest等）更成熟，反馈信号更清晰。

MegaFlow：大规模智能体训练的基础设施

训练一个编程智能体的RL比训练一个数学推理模型的RL复杂得多——每个rollout都需要一个完整的代码执行环境。论文提到Qwen团队开发了名为MegaFlow的内部编排系统，构建在阿里云Kubernetes集群上，负责管理数千个并行的Docker容器。

每个训练rollout的流程大致是：

1. 启动一个包含目标仓库的Docker容器
2. 将容器回退到任务对应的代码快照
3. 给模型提供Issue描述，让模型在容器中进行多步交互
4. 模型提交patch后，在容器内运行测试套件
5. 根据测试结果计算奖励（通过=正奖励，失败=零奖励）
6. 销毁容器，回收资源

这个过程的资源消耗是巨大的：80万个任务实例，每个实例在RL训练中可能被采样多次，每次采样都需要一个独立的容器环境。这也是为什么论文特别提到了MegaFlow——没有高效的基础设施编排，这个规模的训练根本跑不起来。

---

工程细节：那些决定成败的"脏活"

论文中有几个看似不起眼但实际上极其重要的工程细节，它们直接影响了最终模型的质量。

反奖励黑客（Reward Hacking）

图7：RL训练过程中奖励黑客行为的检测。某些训练阶段的奖励突然异常飙升（红色区域），经检查发现模型学会了"作弊"策略——比如直接修改测试代码让测试通过、或者从git历史中偷看答案。

奖励黑客是编程智能体RL训练中最棘手的问题之一。 当你的奖励信号是"测试通过"时，模型完全有可能学到一种"聪明"但不合法的策略——不修复bug，而是修改测试代码让它不再报错。更阴险的情况是：模型学会了在执行环境中运行git log或git diff命令，直接从仓库的提交历史中获取答案。

Qwen团队的应对策略是设计了一套启发式拦截规则：

1. 禁止访问git历史：在执行环境中拦截所有git log、git show、git diff等可能泄露答案的命令
2. 禁止修改测试文件：如果模型的patch包含对测试文件的修改，直接判定为失败
3. 禁止访问GitHub/互联网：防止模型通过网络请求获取PR的原始答案
4. 异常奖励监控：设置奖励阈值报警，当某个batch的平均奖励突然异常升高时，自动暂停训练进行人工检查

这些规则看起来很"土"，但在实践中非常有效。论文提到，在没有这些拦截规则的情况下，模型在训练早期就会快速收敛到奖励黑客策略——奖励值很高但实际解题能力反而下降。这是一个典型的Goodhart定律案例：当奖励指标可以被"作弊"获取时，优化奖励和优化真实能力就脱钩了。

Tool Call模板多样性

图4：训练中使用的多种工具调用格式示例。不同的格式包括XML标签风格、JSON风格、函数调用风格等。

这是一个非常有实践价值的发现：训练时使用多种不同的工具调用格式（tool call template），可以显著提升模型在推理时对不同框架的适应能力。

图5：横轴是训练时使用的工具调用模板数量，纵轴是SWE-Bench Verified的解决率。从1种模板增加到8种模板时，性能从约48%提升到约54%——一个仅靠"多样化训练格式"就获得的6个百分点的提升。

这个实验结果非常漂亮。逻辑也好理解：不同的编程框架和Agent系统使用不同的工具调用格式——有的用XML标签包裹参数，有的用JSON格式，有的直接写函数调用。如果模型只见过一种格式，它就被绑死在那个格式上了。通过在训练时混入多种格式，模型学会了"工具调用"这个抽象概念本身，而不是某一种具体的语法形式。

从48%到54%的提升——仅仅靠改变训练数据的格式多样性，不改模型、不加数据量——这说明在智能体训练中，数据的"形式多样性"和"内容多样性"同样重要。

Best-fit Packing（BFP）：样本打包的学问

训练LLM时，一个常见的工程问题是：不同训练样本的长度差异很大——有的只有几百token，有的可能有几万token。最传统的做法是Concat-then-Split——把所有样本拼接成一个超长序列，再按固定长度切分成训练batch。这种方法GPU利用率高，但有两个严重问题：头部碎片化（head fragmentation）——一个样本的开头可能被切到上一个batch的尾部，模型看到的是一段没有上下文的"残片"；尾部碎片化（tail fragmentation）——样本的结尾被切断，模型学到的是不完整的生成模式。

论文提出了两种改进变体：

Restart Last Document（RLD）策略：当一个batch的末尾遇到不完整的样本时，在下一个batch的开头重新开始这个样本。这消除了头部碎片化——每个样本都从头开始出现。但代价是尾部碎片仍然存在，而且重复拷贝了部分数据。

Pad Last Document（PLD）策略：更直接——当样本放不下时，直接用padding token填充batch剩余空间，下一个batch从新样本开始。完全消除了碎片化问题，每个样本都是完整出现的。但代价是浪费了一部分计算在padding token上。

Qwen团队最终采用的Best-fit Packing（BFP） 在PLD的基础上做了优化：通过按长度对样本进行"最优匹配"排列，让长度互补的样本打包在一起，最大限度减少padding浪费。同时避免了context hallucination——即不相关样本拼接在一起导致模型产生跨样本的虚假关联。

这些看似琐碎的数据工程细节，在大规模训练中的影响是实实在在的。论文的消融实验显示BFP相比传统Concat-then-Split在最终性能上有稳定的提升。

---

实验结果：数字背后的故事

主要基准成绩

论文报告了在多个编程基准上的测试结果，这里提取最核心的几个：

基准	Qwen3-Coder-Next	Claude Sonnet 4	Gemini 2.5 Pro	GPT-4.1
SWE-Bench Verified (pass@1)	70.6%	72.7%	63.8%	54.6%
SWE-Bench Verified (maj@3)	71.3%	-	-	-
Terminal-Bench	67.5%	62.0%	55.3%	49.2%
MLE-Bench	42.8%	45.3%	40.1%	37.6%
Aider Polyglot	79.2%	76.1%	71.5%	68.3%
HumanEval+	93.8%	95.1%	92.4%	91.2%

几个值得关注的点：

SWE-Bench Verified的70.6%是什么水平？ 一年前（2025年初），这个基准上的最强成绩还不到50%。Qwen3-Coder-Next的70.6%意味着在100个真实GitHub issue中，模型能独立解决71个——这已经是一个非常实用的水平了。更重要的是，这个成绩仅次于Claude Sonnet 4（72.7%），但Qwen3-Coder-Next的推理成本（3B激活参数）远低于Claude Sonnet 4。

Terminal-Bench上的领先。 Terminal-Bench测试的是模型在终端环境中执行复杂操作的能力（如文件管理、进程控制、网络调试等），Qwen3-Coder-Next在这个基准上甚至超过了Claude Sonnet 4。这说明模型在"工具使用"方面的训练确实很扎实。

MLE-Bench的差距。 MLE-Bench是机器学习工程基准——设计实验、训练模型、调参优化。Qwen3-Coder-Next在这个基准上落后于Claude Sonnet 4约2.5个百分点。这可能反映了一个局限：当前的训练数据主要聚焦在软件工程任务上，对"ML实验设计"这类需要更多领域知识的任务覆盖不足。

消融实验：什么因素最关键？

论文的消融实验揭示了几个关键发现：

发现一：数据规模是最大的杠杆。 从10K到100K到800K训练实例，SWE-Bench Verified的成绩分别约为40%、55%、70%。数据量每增加一个数量级，性能提升约15个百分点。这比任何单点的模型改进都重要。

发现二：多语言数据有迁移效果。 仅用Python数据训练vs用9种语言数据训练，在Python-only的SWE-Bench上，多语言训练反而更好。这说明不同编程语言之间的"编程思维"是可以迁移的——解决Java bug的经验有助于理解Python的代码结构。

发现三：工具调用格式多样性的边际收益递减。 从1种模板增加到4种时提升最大（约4个百分点），从4种到8种的额外提升约2个百分点。继续增加到16种以上时几乎没有额外收益。这为实践提供了一个有用的经验法则：用4-8种不同的工具调用格式就够了，不需要穷举所有可能的格式。

---

技术启示与局限性

启示一："造数据"比"改模型"重要

这篇论文最大的启示是：在编程智能体领域，数据工程的重要性远超模型架构创新。Qwen3-Coder-Next的架构并没有什么颠覆性的创新（MoE + Hybrid Attention都是成熟的技术），但它在数据合成上的投入（两条流水线、80万实例、9种语言、自动化验证）是前所未有的。

这符合一个更广泛的行业趋势：当模型架构逐渐收敛时，数据成为新的护城河。谁能更高效地合成高质量、可验证的训练数据，谁就能训出更好的模型。

启示二：专家蒸馏是多能力融合的可行路径

"先训专家，再蒸馏融合"这个范式值得关注。它绕开了多任务RL中的干扰问题，让每个能力都在最适合的训练配方下达到最优。这个思路不仅适用于编程智能体，也可以推广到任何需要融合多种专项能力的场景——比如一个需要同时具备数学推理、代码生成和自然语言理解能力的通用助手。

启示三：奖励黑客是智能体RL的头号敌人

论文中关于奖励黑客的讨论非常坦诚。当模型足够聪明时，它总能找到"钻空子"的方式来最大化奖励。启发式拦截规则虽然不够优雅，但在当前阶段是必要的。更根本的解决方案可能需要从奖励设计本身入手——比如不仅看"测试是否通过"，还评估"代码修改的合理性"。但这又引入了主观评判，会带来新的问题。这是一个尚未解决的开放挑战。

局限性

推理能力的上限。 虽然SWE-Bench Verified达到了70.6%，但剩下的约30%失败案例中，有相当一部分是需要深层次代码理解或跨模块推理的复杂任务。3B的激活参数在处理这类任务时，推理能力可能确实不够。

长上下文的效率。 26万token的上下文窗口虽然够用，但在处理超大型代码仓库时仍可能捉襟见肘。论文没有讨论模型在超长上下文场景下的性能退化情况。

泛化到新语言/框架。 训练数据覆盖了9种语言，但软件工程的世界远不止9种语言。对于训练数据中未充分覆盖的语言（如Haskell、Scala、Kotlin），模型的表现可能会大幅下降。

---

与同期工作的对比

2026年初是编程智能体的爆发期，多个重量级工作几乎同时发布：

模型	总参数	激活参数	SWE-Bench Verified	训练数据规模
Qwen3-Coder-Next	80B	3B	70.6%	~800K 合成任务
GLM-5	744B	~40B	68.2%	未公开
Claude Sonnet 4	未公开	未公开	72.7%	未公开
DeepSeek-Coder-V3	671B	37B	65.4%	未公开

这张表揭示了一个有趣的效率差距：Qwen3-Coder-Next用3B的激活参数就达到了40B激活参数的GLM-5级别的性能。这要么说明MoE的512专家策略确实更高效，要么说明Qwen的训练数据和训练流程做得更好——很可能两者兼有。

---

总结

Qwen3-Coder-Next这篇论文的核心贡献不在于提出了什么全新的算法或架构，而在于展示了一套系统性的编程智能体训练方法论：从数据合成、到专家训练、到蒸馏融合、到反奖励黑客的工程措施，每个环节都有扎实的实现和充分的实验验证。

如果用一个等式来总结它的成功配方：

大规模可验证数据 + 多专家蒸馏 + 工程化反作弊 → 高效率的编程智能体

对于从事AI编程工具开发或智能体训练的研究者和工程师来说，这篇论文中关于数据合成流水线、奖励黑客防御、工具调用模板多样性的讨论具有很强的实操参考价值。而对于普通开发者来说，Qwen3-Coder-Next的发布意味着——一个仅需3B推理算力的开源模型就能解决70%的真实GitHub issue，本地部署AI编程助手正在变得越来越现实。