Qwen3-Coder-Next80B参数只激活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%pass1和71.3%majority3登顶开源编程智能体排行榜。为什么需要这篇论文编程智能体的规模化训练困境过去两年AI编程经历了从代码补全到智能体式开发的范式转移。Claude Code、Cursor、Devin等产品已经证明了一件事未来的AI编程不是写一个函数而是理解一个仓库、定位一个bug、规划修改方案、执行多步操作。这种智能体式的编程对模型提出了全新的挑战。传统的代码基准HumanEval、MBPP测的是给你一个函数签名把函数体补完——这在2024年就已经被各家模型刷到了90%基本失去了区分度。真正有意义的基准是SWE-Bench给你一个真实的GitHub仓库和一个issue你需要理解代码库结构、定位问题文件、生成正确的patch。问题在于训练这样的模型需要什么样的数据HumanEval/MBPP的训练数据好造——算法题有标准答案写个测试用例就行。但SWE-Bench级别的任务呢每个任务都涉及一个完整的代码仓库有复杂的依赖和执行环境验证一个solution需要跑整个测试套件。这种数据不可能靠人工标注来获取。Qwen3-Coder-Next这篇论文要解决的核心问题就是如何大规模合成高质量的、可执行验证的编程智能体训练数据并设计一套有效的训练流程把这些数据转化为模型能力。图1Qwen3-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 Verified70.6%和Terminal-Bench67.5%上的成绩已经可以和Claude Sonnet 4正面硬刚。考虑到Qwen3-Coder-Next只是80B总参数、3B激活参数的小模型——对比Claude和GPT系列动辄数百B激活参数的巨无霸——这个效率优势是非常显著的。模型架构512个专家里只选3个为什么选MoEQwen3-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历史中反向构建任务。具体流程如下仓库筛选从GitHub上筛选高质量代码仓库要求有清晰的测试套件和CI/CD配置PR分析解析每个PR的diff识别出哪些是修复bug或实现feature的有意义改动环境构建为每个PR创建一个可复现的执行环境Docker容器回退到PR提交前的代码状态任务构造用PR的描述作为任务输入用PR的diff作为ground truth用仓库的测试套件作为验证工具这个思路并不新鲜——SWE-Bench本身就是这么构建的之前的SWE-Smith也用了类似的方法。但Qwen团队在规模和覆盖度上做了大幅提升他们不仅仅局限于Python仓库而是扩展到了9种编程语言Python、JavaScript/TypeScript、Java、C/C、Go、Rust等最终从这条流水线获取了大量多语言的真实编程任务。流水线二合成Issue注入——造出从未存在过的bug第二条流水线更有创意不是从已有PR中挖掘任务而是主动向代码仓库注入问题然后让模型来修复。具体操作选择一个健康的代码仓库测试全部通过的状态用LLM分析代码结构识别出可以合理修改的位置让LLM在选定位置注入一个合成bug或新需求——比如故意修改一个函数的逻辑让它在边界条件下出错或者添加一个新API但故意留下未实现的部分验证注入的改动确实会导致测试失败否则这不是一个有意义的任务生成对应的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-MiddleFIM目标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数据来训练统一模型。这就像让四个不同领域的顶尖程序员各自出一本教材然后用这四本教材来培养一个全栈工程师。这种先专后通的训练范式有几个明显的优势每个专家可以用最适合的方法训练——SWE任务用RL效果最好Web开发用SFT就够了不用强求所有能力都用同一种训练方法避免了多任务训练中的干扰——直接在一个模型上同时训练所有能力容易导致task interference能力之间互相拖后腿蒸馏过程比直接训练更稳定——学生模型学的是专家的输出而不是原始奖励信号梯度噪声更小强化学习训练在执行环境中做中学SWE专家的训练过程是整篇论文最具技术深度的部分。这不是简单的RLHF——模型需要在一个真实的代码仓库中进行多步交互每步可以读取文件、搜索代码、执行命令、编辑文件最终提交一个patch然后运行测试来获取奖励。图69个不同任务类别上的RL训练曲线。横轴是训练步数纵轴是奖励值。大部分任务的奖励在前200步内快速上升然后进入平台期。不同任务的最终收敛水平差异明显——Python修复类任务学得最快多语言任务相对困难。这组训练曲线揭示了几个值得关注的现象现象一快速起步后的平台期。大部分任务在训练前200步就能从接近零的成功率跳到30-50%说明模型很快就能学会基本的找文件→读代码→改代码→跑测试流程。但后续的提升非常缓慢从50%到70%可能需要数倍的训练量。这符合直觉——学会做事比做好事容易得多。现象二跨语言的难度差异。Python相关任务的学习曲线明显高于其他语言。这可能有两个原因一是预训练数据中Python代码的比例最高二是Python生态的测试框架pytest等更成熟反馈信号更清晰。MegaFlow大规模智能体训练的基础设施训练一个编程智能体的RL比训练一个数学推理模型的RL复杂得多——每个rollout都需要一个完整的代码执行环境。论文提到Qwen团队开发了名为MegaFlow的内部编排系统构建在阿里云Kubernetes集群上负责管理数千个并行的Docker容器。每个训练rollout的流程大致是启动一个包含目标仓库的Docker容器将容器回退到任务对应的代码快照给模型提供Issue描述让模型在容器中进行多步交互模型提交patch后在容器内运行测试套件根据测试结果计算奖励通过正奖励失败零奖励销毁容器回收资源这个过程的资源消耗是巨大的80万个任务实例每个实例在RL训练中可能被采样多次每次采样都需要一个独立的容器环境。这也是为什么论文特别提到了MegaFlow——没有高效的基础设施编排这个规模的训练根本跑不起来。工程细节那些决定成败的脏活论文中有几个看似不起眼但实际上极其重要的工程细节它们直接影响了最终模型的质量。反奖励黑客Reward Hacking图7RL训练过程中奖励黑客行为的检测。某些训练阶段的奖励突然异常飙升红色区域经检查发现模型学会了作弊策略——比如直接修改测试代码让测试通过、或者从git历史中偷看答案。奖励黑客是编程智能体RL训练中最棘手的问题之一。当你的奖励信号是测试通过时模型完全有可能学到一种聪明但不合法的策略——不修复bug而是修改测试代码让它不再报错。更阴险的情况是模型学会了在执行环境中运行git log或git diff命令直接从仓库的提交历史中获取答案。Qwen团队的应对策略是设计了一套启发式拦截规则禁止访问git历史在执行环境中拦截所有git log、git show、git diff等可能泄露答案的命令禁止修改测试文件如果模型的patch包含对测试文件的修改直接判定为失败禁止访问GitHub/互联网防止模型通过网络请求获取PR的原始答案异常奖励监控设置奖励阈值报警当某个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 PackingBFP样本打包的学问训练LLM时一个常见的工程问题是不同训练样本的长度差异很大——有的只有几百token有的可能有几万token。最传统的做法是Concat-then-Split——把所有样本拼接成一个超长序列再按固定长度切分成训练batch。这种方法GPU利用率高但有两个严重问题头部碎片化head fragmentation——一个样本的开头可能被切到上一个batch的尾部模型看到的是一段没有上下文的残片尾部碎片化tail fragmentation——样本的结尾被切断模型学到的是不完整的生成模式。论文提出了两种改进变体Restart Last DocumentRLD策略当一个batch的末尾遇到不完整的样本时在下一个batch的开头重新开始这个样本。这消除了头部碎片化——每个样本都从头开始出现。但代价是尾部碎片仍然存在而且重复拷贝了部分数据。Pad Last DocumentPLD策略更直接——当样本放不下时直接用padding token填充batch剩余空间下一个batch从新样本开始。完全消除了碎片化问题每个样本都是完整出现的。但代价是浪费了一部分计算在padding token上。Qwen团队最终采用的Best-fit PackingBFP在PLD的基础上做了优化通过按长度对样本进行最优匹配排列让长度互补的样本打包在一起最大限度减少padding浪费。同时避免了context hallucination——即不相关样本拼接在一起导致模型产生跨样本的虚假关联。这些看似琐碎的数据工程细节在大规模训练中的影响是实实在在的。论文的消融实验显示BFP相比传统Concat-then-Split在最终性能上有稳定的提升。实验结果数字背后的故事主要基准成绩论文报告了在多个编程基准上的测试结果这里提取最核心的几个基准Qwen3-Coder-NextClaude Sonnet 4Gemini 2.5 ProGPT-4.1SWE-Bench Verified (pass1)70.6%72.7%63.8%54.6%SWE-Bench Verified (maj3)71.3%---Terminal-Bench67.5%62.0%55.3%49.2%MLE-Bench42.8%45.3%40.1%37.6%Aider Polyglot79.2%76.1%71.5%68.3%HumanEval93.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 472.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-Next80B3B70.6%~800K 合成任务GLM-5744B~40B68.2%未公开Claude Sonnet 4未公开未公开72.7%未公开DeepSeek-Coder-V3671B37B65.4%未公开这张表揭示了一个有趣的效率差距Qwen3-Coder-Next用3B的激活参数就达到了40B激活参数的GLM-5级别的性能。这要么说明MoE的512专家策略确实更高效要么说明Qwen的训练数据和训练流程做得更好——很可能两者兼有。总结Qwen3-Coder-Next这篇论文的核心贡献不在于提出了什么全新的算法或架构而在于展示了一套系统性的编程智能体训练方法论从数据合成、到专家训练、到蒸馏融合、到反奖励黑客的工程措施每个环节都有扎实的实现和充分的实验验证。如果用一个等式来总结它的成功配方大规模可验证数据 多专家蒸馏 工程化反作弊 → 高效率的编程智能体对于从事AI编程工具开发或智能体训练的研究者和工程师来说这篇论文中关于数据合成流水线、奖励黑客防御、工具调用模板多样性的讨论具有很强的实操参考价值。而对于普通开发者来说Qwen3-Coder-Next的发布意味着——一个仅需3B推理算力的开源模型就能解决70%的真实GitHub issue本地部署AI编程助手正在变得越来越现实。