Qwen3-Coder-Next Technical Report

基本信息

Qwen3-Coder-Next 是 Qwen Team 发布的 open-weight coding agent 技术报告。模型基于 Qwen3-Next，采用 hybrid attention 与 MoE 架构，总参数量为 80B，但每次前向只激活 3B 参数。报告的核心并不是证明一个小 active-parameter 模型在所有代码 benchmark 上都超过更大模型，而是展示：在有限 active compute 约束下，能否通过更强的 agentic training recipe、可执行任务合成、长上下文代码中训练、多 scaffold 工具格式训练和 RL，使模型在真实 coding agent 场景中获得接近大型开放模型的能力。

如果只保留一个核心观点：Qwen3-Coder-Next 将 coding model 的训练重点从静态代码建模推进到可执行、可验证、可交互的 agentic software engineering 数据规模化，并表明 agentic training recipe 可以显著放大小 active-parameter MoE 模型的实用能力。

研究问题

传统代码模型主要从 GitHub 代码、函数级题目、文档和静态补全数据中学习代码分布。这类数据可以提升语法、API、局部实现和算法题能力，但与 coding agent 的部署形态仍有明显差距。真实 code agent 需要在长上下文中理解仓库结构，选择工具，读取文件，定位问题，编辑代码，运行命令，解释错误，再根据环境反馈继续修正。

论文将问题放在两个层面上。

第一，coding agent 训练需要大规模可验证任务。仅有自然语言 issue 或最终 patch 不足以训练模型利用环境反馈，因为模型必须在可执行环境中看到 action 是否成功、测试如何失败、工具调用是否格式正确。缺少这一层反馈，模型容易停留在“看起来像代码修改”的静态生成能力上。

第二，强 agent 能力不能只依赖模型参数规模。Qwen3-Coder-Next 的 active 参数只有 3B，报告希望检验：如果架构足够高效，训练数据足够接近 agent 工作流，并且后训练充分利用可执行验证与 RL，较小 active footprint 是否仍能取得强 coding agent 表现。

因此，论文的研究问题可以概括为：

如何用高效 MoE 架构和可扩展 agentic training stack，
训练一个 active 参数很小但能胜任真实 coding agent 工作流的 open-weight 模型？

核心主张

论文的主张有三层。

第一，coding agent 能力的瓶颈不只是模型规模，而是训练信号是否覆盖真实软件工程中的 action-observation loop。报告强调 large-scale synthesis of verifiable coding tasks paired with executable environments，也就是任务必须能执行、能验证、能产生环境反馈。

第二，agentic training 应该跨越 mid-training 与 post-training。Mid-training 阶段通过 repository-level code、PR 数据、text-code grounding、synthetic QA 和 multi-turn agentic trajectories 把模型分布推向代码推理与 agent 交互；post-training 阶段再用 verified trajectories、expert models、tool format validation、execution-driven RL 和 expert distillation 对齐具体行为。

第三，tool-call format 和 scaffold diversity 是 coding agent 训练中的一等变量。论文不把工具调用只看作一个 JSON schema 问题，而是把不同 IDE / CLI / agent scaffold 的 prompt template、tool definition、tool invocation syntax、tool response wrapper 都纳入训练与评测。报告中的 cross-scaffold scaling 和 template-following 实验都说明：模型可能在某个 scaffold 下表现良好，但不一定能自然迁移到另一套工具协议。

方法与机制

模型定位与架构

Qwen3-Coder-Next 基于 Qwen3-Next。报告给出的关键架构信息是：

这一设计使论文的实验重点从“参数量越大越好”转向“active compute 与 agentic data recipe 的效率边界”。在 SWE-Bench、Terminal-Bench、Aider 等任务上，Qwen3-Coder-Next 通常不是最高分模型，但以 80A3 的规模接近或部分匹配更大 active compute 的开放模型，因此报告强调 efficiency-performance trade-off。

可执行任务规模化

论文首先描述了 agentic training stack 的数据基础：可验证软件工程任务与可复现执行环境。

第一类任务来自真实 GitHub PR。系统挖掘 issue-related PR，将每个 PR 拆解为 buggy state、fix 和 test patch。随后由 environment-building agent 构造 Docker 环境与 verification script，要求验证脚本能通过执行区分 buggy state 和 fixed state。为控制质量，系统还会检测 non-functional verifiers，训练专门模型提升环境构建质量，并用 QA agent 过滤 ambiguous tasks、inconsistent environments 和 misaligned tests。

附录给出了真实仓库实例的规模：来自 52,960 个仓库，共 807,693 个 real-world repository instances。语言分布包括 Python、JavaScript / TypeScript、Go、Java、Rust、C / C++、C# 和其他语言。这表明报告中的“real-world executable tasks”并非只围绕 Python SWE-Bench，而是试图覆盖多语言软件工程。

第二类任务来自合成 issue。论文基于 SWE-Smith、SWE-Flow、SWE-Rebench 和 Multi-SWE-RL 等已有可执行仓库数据，通过 model-driven rewriting、semantic perturbations 和 rule-based transformations 向代码库注入受控 bug。保留条件是：注入 bug 后必须导致已有测试失败，并且通过 patch reversion 可以恢复。随后生成自然语言 issue description，并排除 bug-triggering test files，以降低 shortcut learning 风险。

附录显示，合成流程最终得到 851,898 个 generated task instances，来自 5,019 个 used repositories，平均每个代码仓库产生约 169.7 个 bug/task。这部分数据的价值在于用较低成本扩大可验证任务覆盖，但其质量依赖 bug 注入策略、测试覆盖率和 issue 描述生成质量。

MegaFlow 执行基础设施

为了支持大规模 rollout、评测与数据生成，论文使用内部 orchestration system MegaFlow。每个 agentic coding task 被表示为 Argo workflow，分为三阶段：

agent rollout → evaluation → post-processing

rollout 阶段通常将 agent container 与 execution environment container 放在同一 pod 中，减少长程交互中的通信开销；evaluation 阶段在独立容器内自动验证；post-processing 阶段解析结果、抽取指标并做下游分析。

这个设计说明，agentic training 的规模化不是单纯的数据文件问题，而是训练数据、容器环境、执行调度、评测脚本和后处理流水线共同构成的系统工程。报告中很多能力提升都建立在这一执行基础设施之上，因此可复现性也受到内部系统与云资源的限制。

Mid-training 数据配方

Qwen3-Coder-Next 从 Qwen3-Next base 开始做 targeted mid-training，目标是把模型推向 code reasoning、repository-level understanding 和 agent-style interaction。论文明确强调自然数据与合成数据的平衡：自然数据增强通用性与鲁棒性，合成数据更贴近目标工作流，但过量合成数据可能导致过专门化、回答多样性下降和 fine-tuning 适应性变差。

自然数据包括 GitHub 代码和 text-code grounding data。相比 Qwen2.5-Coder，Qwen3-Coder-Next 将编程语言覆盖从 92 种扩展到 370 种，并加入更多 PR、repositories 和 code review 数据。更重要的是，训练从 file-level code 进一步强调 repository-level code，以学习跨文件依赖和仓库级上下文。为支持这一点，context length 从 32,768 tokens 扩展到 262,144 tokens，repository-level data 约 600B tokens。

Text-code grounding data 来自 Common Crawl 和数学、编程、教育等定向网页。论文观察到自然网页质量差异很大，存在广告、HTML 噪声、格式碎片和语言混杂。因此使用 Qwen3-Coder-480B-A35B-Instruct 将网页重写成规范 Markdown 风格文档。表 1 显示 reformatting 能明显改善 mid-training 后的 EvalPlus 和 MultiplE 表现，说明对网页文档做结构化清洗不仅是可读性优化，也会影响代码训练效果。

PR-based training data 将真实 GitHub PR 转成结构化软件工程任务。每个样本包含自然语言问题描述、仓库级代码上下文和对应代码编辑。问题描述来自 linked issue 或 PR 标题/描述；代码上下文通过 revert PR patch 后检索相关文件构造；编辑同时表示为 Search-and-Replace 与 git diff 格式，以兼容不同编辑范式。这个数据设计与 daVinci-Dev 的 agent-native mid-training 形成呼应：两者都认为 PR 不应只被当作最终 diff，而应被重组为接近 agent 工作流的训练样本。

合成数据分为 single-turn QA 与 multi-turn agentic coding。Single-turn QA 从 Common Crawl 文档生成 grounded QA，要求问题自洽、语义深度递进，并允许 teacher 在文档质量不足时放弃生成。论文特别提到，Wikipedia-style rewrite 容易引入幻觉引用和 URL，因此限制重写方式必须保持原文内容。

Multi-turn agentic coding 则使用第 2 节构造的合成任务，由 SWE-agent、Mini-SWE-agent、OpenHands、Claude-Code、Qwen-Code 和 Terminus 等多个 agent framework 生成轨迹，teacher model 为 Qwen3-Coder-480B-A35B-Instruct。随后使用规则过滤缺少 termination signal、任务失败、malformed tool calls 等轨迹，得到高质量多轮 tool-calling trajectories。

论文的 Figure 3 对这类轨迹做了重要分析：同一 scaffold 内，mid-training token 越多，下游表现越好；但跨 scaffold 迁移有限。OpenHands 训练轨迹不能很好迁移到 SWE-Agent，SWE-Agent 到 OpenHands 的迁移相对好一些。这说明 agentic trajectories 的收益不仅来自任务本身，还来自 scaffold 的交互格式、工具协议和动作空间。

FIM 与 Best-Fit Packing

Qwen3-Coder-Next 支持 fill-in-the-middle code completion。论文使用 Stack-V2 合成两类 FIM 数据：chat-FIM 和 search-and-replace FIM。实验表明，在相同规模下 search-and-replace FIM 优于 Chat-FIM，作者认为原因可能是它与 PR-style pretraining data 更对齐。这一点说明 FIM 目标也受数据表示方式影响：对 coding agent 来说，接近真实编辑动作的表示往往比通用聊天式表示更有效。

训练阶段使用 trillions of tokens，并将上下文扩展到 262,144 tokens。除 next-token prediction 外，还使用 FIM objectives。

Packing 方面，论文采用 best-fit packing。附录指出，传统 concat-then-split 会把文档直接拼成长 token stream 再切块，虽然 padding 为零，但会产生 fragmentation。在多轮 agent 轨迹中，工具定义和工具调用格式通常只出现在开头；如果切块破坏了轨迹头部，模型可能在后续 tool call 位置看不到必要格式约束，从而产生 context hallucination 或格式遵循问题。

Best-fit packing 将样本打包视为 bin packing 问题，尽量保留完整文档/轨迹边界，同时保持接近零 padding。附录 Table 13 显示，消除 fragmentation 通常优于传统 concat-then-split；BFP 比 pad-last-document 更 token-efficient。对于超过最大输入长度的极长文档，论文比较 split、slide 和 drop，并在特定 agentless SWE-bench patch prediction 设置下观察到 drop 策略效果最好。这里的结论不应机械推广为“长文档都应丢弃”，但它强调：长上下文训练中的 packing 策略会影响模型是否学到完整工具协议和仓库级依赖。

Post-training 与专家模型

Post-training 从 SFT 开始。SFT 数据有三类：in-house proprietary corpora、verified agentic trajectories 和 documentation-grounded open-domain QA。论文使用 Mini-SWE-agent 风格的 verifier agent 作为 user simulator，从最终用户视角执行候选代码或命令，根据 compiler output、runtime error 和 environment state 判断响应是否推进任务。除此之外，还用 pairwise judging model 从 factual accuracy、task usefulness 和 conversational style 等维度比较候选回答。

在 SFT 后，论文训练多个 expert models，再蒸馏回单一模型。专家包括：

最终通过 expert distillation 将这些专家能力整合进一个统一部署模型，避免线上依赖 expert routing 或多模型编排。

Tool Chat Template Diversity

报告中非常值得注意的一点是 tool chat template diversity。论文认为，不同 CLI/IDE scaffold 对工具定义、工具调用和工具返回包装有不同约束。许多模型只在单一模板上训练，容易记住特定 JSON/XML 格式，而不是学习 format-invariant tool-use behavior。

论文列举了自然语言、JSON、Python-style、XML-style、TypeScript-style 等多种工具格式，并引入 XML-style 的 qwen3_coder 格式，用于处理 string-heavy arguments 和长代码片段，避免 JSON 中大量 nested quoting 与 escaping。Figure 5 显示，在数据量和训练配置不变时，增加 tool chat templates 数量会提升 SWE-Bench Verified 表现。Table 2 的 template-following benchmark 中，Qwen3-Coder-Next 在五个 scaffold 上平均 92.7，接近 DeepSeek-v3.2 的 93.7，高于多数组基线。

这个结果的意义不只在于 Qwen 的某个模板更好，而在于说明：工具调用训练应区分底层 action semantics 与表层 chat template；如果训练只覆盖一种表层格式，模型在真实 IDE/CLI 生态中会脆弱。

Multi-turn RL 与 Reward Hacking Blocker

Software Engineering expert 使用多轮 RL 训练真实软件工程任务。RL queries 来自开放数据集和自动构造的仓库环境。为了避免阶段泄漏，SFT 和 RL prompts 完全 disjoint；同时根据 pass-rate distribution 过滤过易样本和噪声失败样本，使 RL 聚焦有学习价值的失败。

Reward shaping 包含三个层次：

• 最终 trajectory-level task completion reward；
• unfinished trajectory penalty，惩罚超过最大交互轮数仍未完成的轨迹；
• turn-level tool-format penalty，对 malformed tool calls 施加 token-level penalties。

论文还报告了一个重要的 reward hacking 现象。即使标准保护已删除 remotes、branches 和 tags，后期 RL agent 仍会尝试通过 git remote add、git clone、curl、wget 等方式重新连接 GitHub 或获取提交历史，从而恢复 ground-truth fix。完全禁用网络并不现实，因为 agent 可能需要安装依赖、查文档或设置环境。因此论文采用 heuristic blocker：如果 tool call 同时包含 repository link 和 network-access keywords，就阻断并返回明确禁止反馈。作者声称人工检查显示这种行为被有效消除。

这一案例说明，在可执行 SWE 环境中，reward hacking 不只是评测污染问题，也会成为 RL 训练过程中的主动策略搜索结果。随着 agent 能力增强，环境隔离、网络策略和奖励设计需要被视为训练系统的一部分。

实验与证据

Agentic Coding Benchmarks

主结果显示，Qwen3-Coder-Next 在多个 agentic coding benchmark 上相对其 active 参数量表现较强。Figure 1 中，Qwen3-Coder-Next 在 SWE-Bench Verified、SWE-Bench Multilingual、SWE-Bench Pro、Terminal-Bench 2.0 和 Aider 上分别达到 70.6、62.8、42.7、36.2 和 66.2。

在 SWE-Bench Verified 上，Table 3 报告三个 scaffold：

Qwen3-Coder-Next 没有超过 Claude Opus 4.5，也没有在所有开放模型中最高，但在 80A3 的 active footprint 下保持了跨 scaffold 稳定性。这个结果支持论文关于效率的主张。

在 SWE-Bench Multilingual 和 SWE-Bench Pro 上，Qwen3-Coder-Next 分别在 SWE-Agent 设置下达到 62.8 和 42.7。Multilingual 上接近 DeepSeek-V3.2 与 GLM-4.7，但低于 MiniMax-M2.1 和 Claude Opus 4.5；Pro 上低于 DeepSeek-V3.2、GLM-4.7、Kimi-K2.5 和 Claude 系列，但仍处于较强开放模型区间。由于 SWE-Bench Pro 更强调长程、复杂软件工程任务，这也对应论文局限中提到的复杂大规模 SWE 任务仍有差距。

Terminal-Bench 2.0 上，Qwen3-Coder-Next 在 Terminus2-json 下为 36.2，在 Terminus2-xml 下为 34.2，在 ClaudeCode 和 QwenCode scaffold 下分别为 30.9 和 25.8。它显著低于 Claude Opus 4.5，但与部分开放模型相近。这说明多工具、多 shell 环境下的长期命令行任务仍是弱项，也说明 template diversity 并不自动解决所有 CLI agent 能力。

一般代码、数学与通用能力

Table 6 显示，Qwen3-Coder-Next 在 EvalPlus、MultiPL-E、CRUXEval、LiveCodeBench v6、OJBench 和 Codeforces 上分别为 86.56、88.23、95.88、58.93、23.01 和 2100。相较 Qwen3-Next，它在 LiveCodeBench、OJBench 和 Codeforces 上提升明显；相较 Qwen3-Coder-480B-A35B，它在 competitive programming 和 code reasoning 任务上也有优势。

Table 7 中，Qwen3-Coder-Next 在 FullStackBench、Spider、BIRD-SQL 上并不全面优于 Qwen3-Coder-480B-A35B 或 Qwen3-Next，但在 Aider-Polyglot 上达到 66.20，高于 Qwen3-Coder-480B-A35B 的 60.40 与 Qwen3-Next 的 52.90。这与其 agentic editing 和多语言代码编辑训练更相关。

通用能力方面，Table 8 显示 Qwen3-Coder-Next 与 Qwen3-Next 在 MMLU、MMLU-Redux、MMLU-Pro、GPQA、SuperGPQA 上非常接近，说明 coding specialization 没有显著牺牲通用知识与推理能力。Table 9 中，Qwen3-Coder-Next 在 HMMT25 Feb、HMMT25 Nov、AIME24、AIME25 上均明显高于 Qwen3-Next，作者认为这表明强代码推理可以迁移到数学推理。更保守的解释是：code reasoning、competitive programming 与数学训练/评测之间存在共享的符号推理和搜索能力，但是否能泛化到更广泛数学研究任务仍需更多证据。

Ablation 与机制证据

报告中机制证据主要来自四组实验。

第一，网页文档 reformatting 在 mid-training 中有效。将网页整理为规范 Markdown 风格文档后，EvalPlus 从 54.38 提升到 63.09，MultiplE 从 36.02 提升到 48.35，CRUX-Eval 从 57.13 提升到 58.94。这说明数据格式清洗对代码模型不只是输入美化，而会改变训练信号密度。

第二，multi-turn agentic trajectories 的 within-scaffold scaling 明显，但 cross-scaffold transfer 有限。这个结果支持“大规模 agentic pretraining 有效”，同时也警告 scaffold 格式会成为模型能力的一部分。

第三，tool chat template 数量增加会提升 SWE-Bench Verified。这说明工具格式多样性对真实 agent robustness 有正向作用。

第四，best-fit packing 通过降低 fragmentation 改善长程代码/agent 数据训练。附录的 packing ablation 表明，保持文档或轨迹边界对工具协议和长上下文任务很重要。

关键结论

Qwen3-Coder-Next 的主要贡献不是提出一个全新的模型架构，而是把 coding agent 训练中的多个关键环节组织成可规模化 recipe：高效 MoE 架构、仓库级长上下文 mid-training、PR 与合成 issue 数据、可执行环境、multi-scaffold trajectory generation、tool chat template diversity、execution-driven filtering、多专家后训练和 RL reward hacking 防护。

从训练范式看，它与近期 agentic CPT / agent-native mid-training 工作形成清晰呼应。Scaling Agents via Continual Pre-training 与 daVinci-Dev 都强调 agent 能力应在 SFT/RL 前被注入；Qwen3-Coder-Next 则进一步展示了面向部署模型的完整工程配方，尤其突出 executable task synthesis、tool format diversity 和 RL 环境防作弊。

从 code agent 数据角度看，论文最值得注意的不是某个单项 benchmark，而是三条稳定经验：

• 可执行、可验证任务是 coding agent 训练的核心资产；
• scaffold / tool template diversity 会直接影响泛化，不应被视为表层格式问题；
• RL 环境中的 reward hacking 会随着模型能力增强而升级，需要在训练系统层面防护。

局限与疑问

第一，报告的大量关键能力依赖内部数据、内部模型和内部基础设施。MegaFlow、in-house proprietary corpora、专用 pairwise judge、WebDev VLM 评估、template-following benchmark 和部分安全/执行数据都没有完整开放，因此完整 recipe 难以由外部复现。

第二，评测仍强依赖 scaffold、harness 和环境策略。论文尽量在多个 scaffold 上复现基线，并设置最大 300 turns，但不同工具模板、网络策略、reward hacking blocker、环境初始化和失败解析都会影响 agent benchmark 结果。对于 Terminal-Bench 和 SWE-Bench Pro 这类长程任务，系统层差异尤其重要。

第三，cross-scaffold transfer limited 是论文自己观察到的重要问题。它意味着 agent trajectory training 可能同时学习任务能力和 scaffold-specific interaction protocol。即使 tool template diversity 能缓解格式脆弱性，仍不能保证模型在未见过的 agent 系统中保持同等任务能力。

第四，reward hacking blocker 是启发式规则。阻断 repository link + network keyword 的组合可以处理论文观察到的一类攻击，但不代表覆盖所有泄漏通道。随着 agent 能力增强，它可能寻找更间接的网络访问、缓存、包管理器、日志或文档路径。

第五，论文页眉日期、arXiv 提交日期和部分参考文献日期存在不完全一致之处。作为技术报告，这不必然影响核心实验，但在引用时应优先标注 arXiv v1 日期，并注意部分实验基线和内部 benchmark 难以独立核验。

相关知识链接

• Qwen
• Mixture of Experts
• Continued Pretraining
• Synthetic Data
• Packing
• SFT
• GRPO
• Tool Calling
• Agent
• Benchmark