KAT-Coder-V2 技术报告精读快手训练配方从 Dev 到 Pro 的演进【免费下载链接】KAT-Coder-V2.5-Dev项目地址: https://ai.gitcode.com/hf_mirrors/Kwaipilot/KAT-Coder-V2.5-Dev2026 年 7 月快手 KwaiKAT 团队在发布 KAT-Coder-V2.5 之后随即开源了其权重版本 KAT-Coder-V2.5-Dev——一个总参数量 35B、仅激活 3B 的 MoE 代码模型并同步发布《KAT-Coder-V2.5 Technical Report》arXiv:2607.05471系统披露了从 KAT-Coder-V2 延续至今的后训练配方。这份报告最反直觉的论断是强编码 Agent 的瓶颈不在于模型规模而在于训练基础设施——可复现的执行环境、可验证的奖励信号与高价值的轨迹数据。本文结合技术报告全文与开源仓库源码拆解快手从开源 Dev 到闭源 Pro 的训练配方演进路径包括环境构建引擎、数据飞轮、RL 稳定性工程与多教师蒸馏并给出对复现者与竞品团队可操作的启示。一、报告的核心结论与新增能力报告开篇即定义了范式转移编码模型不再是被动的代码补全器而是能够在真实、可执行仓库内部自主行动的 Agent。这意味着能力被重新定义为仓库理解、工具调用、长程规划、工程纪律与验证驱动的问题求解的组合——而非仅仅生成语法正确的片段。围绕这一目标报告把 agentic capability 当作一个系统问题而非数据或参数量问题给出了三层新增能力。1. 环境规模引擎 AutoBuilder把真实仓库变成可验证任务从真实 PR/commit 挖掘训练任务的最大障碍是原始 issue 文本往往含糊、残缺、与最终合并的改动不一致而仓库环境又难以规模化复现。报告的解法是可验证任务三元组精确的任务描述 可执行的仓库环境 一组验证测试。AutoBuilder 是一个沙箱化的构建—验证循环构建 Agent 分析仓库并生成配置脚本验证 Agent 在隔离沙箱中执行脚本且不以命令退出码或表面日志为准而是解析结构化测试框架输出——只有当超过 90% 的预期测试被收集且通过/失败结果可跨次复现时环境才被接受。失败的结构化信息会反馈给构建 Agent 迭代修复。为了规模化AutoBuilder 组合了预配置基础环境、语言与构建系统模板以及从成功配置中蒸馏出的可检索构建配方库将环境构建成功率从16.5% 提升到 57.2%最终产出12 种语言、超过 10 万个可验证环境。同时报告还刻意移除了 git 历史、commit 元数据等可能泄露参考解法的痕迹确保 Agent 只能从任务描述、仓库状态与可执行测试出发解题。2. 数据飞轮从最终奖励到过程质量只用最终测试通过率筛选轨迹是误导性的有些通过的轨迹依赖硬编码或绕过机制而有些失败的轨迹反而包含有价值的搜索、定位与修复行为。数据飞轮包含三个组件Hint-Boosted Rollout对差一步成功的轨迹注入过程级提示如检查某个文件将原先零通过率任务的成功率提升到约 20%随后固定已验证的 patch在无提示条件下重新生成轨迹确保训练数据与推理分布一致。Process-Score-Driven Filtering用规则门控 启发式过程评分从探索、定位、规范匹配、patch 最小性、验证质量等维度筛除通过但低质量的轨迹。Harness Rewriting随机化工具名、参数约定、输出格式与提示模板注入缺失依赖、瞬时命令失败等真实扰动迫使模型学到与 harness 无关的解题策略。3. RL 稳定性工程与多教师蒸馏RL 侧的新增能力最为密集引入白盒 harnessmini-swe-agent低噪声与黑盒 harnessClaudeCode、Codex、OpenClaw 等贴近真实部署分布的Harness Scaling将沙箱反馈错误率从约16% 压到 2% 以下采用带 hindsight 增强价值估计的非对称 Actor-Critic PPO——Critic 在训练时能看到最终奖励、测试结果、patch 差异等特权信息而 Actor 只观察正常交互历史推理时仅部署 Actor并设计了核心任务得分 标准行为约束 失败轨迹激励的三层规则奖励辅以经专门 RL 训练的 GRMgenerative reward model做轨迹级评判。最后报告用Multi-Teacher On-Policy DistillationMOPD将软件工程、Claw 工具使用、终端、Web Coding、通用知识五个领域专家在函数空间融合为单一学生模型配合 off-policy cold start 与 drift-aware dynamic truncation缓解了权重空间合并常见的跷跷板效应。基准结果是PinchBench 94.9 居首SWE-Bench Pro 65.2 与 KAT Code Bench 53.1 均仅次于前沿通用模型 Opus 4.8。二、Dev 与 Pro同一配方的开源投影与关键分叉开源仓库的 README.md 明确写道Dev 版本largely follows the post-training recipe of KAT-V2.5数据构建、训练管线、优化策略基本不变以社区广泛认可的 Qwen3.6-35B-A3B 为基座先在 127K 样本上做 SFT再对 SFT 模型进行 RL 训练。这意味着 Dev 与 Pro 共享同一套配方骨架但存在三处分叉恰好是配方如何迁移到新基座的活教材。1. 基座差异引发的奖励适配报告中关于 Dev 的章节披露了一个极具工程价值的细节Qwen3.6 的轨迹模式与 KAT-V2.5 时期不同简单的 0–1 二值奖励在第二个 epoch 就导致模型坍塌。对训练轨迹的分析显示随着训练推进模型越来越倾向在单轮内发起大量并行工具调用——偶尔超过 70 次导致上下文快速膨胀、产生大量无效轨迹与执行错误最终使 RL 训练失稳。为此团队在原有层级奖励之上为 Qwen3.6 增加了若干针对性惩罚单轮过度并行工具调用、失败的工具调用、空工具调用块、大量重复内容。这些适配使训练稳定跑满 10 个 epoch——**奖励设计必须针对基座模型的性格behavioral patterns**是这份配方最可迁移的教训。2. RL 训练的可见成效README 报告了两项异常行为优化的硬数据异常工具标签从9.34% 降至 0.28%-9pp单轮连续重复从 0.34% 降至 0%。仓库自带的训练曲线图注明了 y 轴含义——每批次样本中通过单元测试的比例1 为通过0 为失败展示了 RL 全程的稳步上升趋势3. 开源投影纯语言模型权重多模态不可用Dev 与 Pro 最直接的产品差异在发布形态开源版只发布语言模型权重作为纯文本模型运行视觉/多模态组件不包含且不可用。这一点在仓库中可以得到源码级印证——config.json 中architectures为Qwen3_5MoeForConditionalGenerationmodel_type为qwen3_5_moe仍保留了vision_config、image_token_id248056与video_token_id248057等字段但推理时必须显式跳过视觉编码器vLLM 部署要求--language-model-only标志SGLang 也提示若加载时尝试构建多模态组件可能因缺少视觉权重而启动失败。仓库的权重布局进一步印证了纯语言模型的定位model.safetensors.index.json的weight_map全部指向model.language_model.*embed_tokens、40 层 transformer、每层 256 个专家的 gate/up/down 投影等13 个 shard 合计约 69.3GBbf16。架构细节同样来自 config.jsonnum_experts256、num_experts_per_tok8即 35B 总参、3B 激活的由来、hidden_size2048、max_position_embeddings262144且layer_types采用 3:1 混合的 linear_attention 与 full_attention 交错布局。三、从配置与模板看为 Agent 而生的工程细节Dev 的Agent 原生属性不只体现在训练配方上也写进了推理配置与对话模板里这些在 README.md 与仓库配置文件中都有直接对应。解码配置generation_config.json 中temperature1.0、top_p0.95、top_k20eos_token_id为[248046, 248044]——保留了思维与结尾的双终止符设计与 Qwen 风格一致。工具调用协议chat_template.jinja 完整定义了tool_call/function.../parameter...的 XML 风格调用格式与tool_response回包封装并实现了两个对 Agent 场景至关重要的开关enable_thinkingFalse可进入无思考的直答模式preserve_thinkingTrue可保留历史消息的思维链——README 说明该能力在多轮 Agent 场景中能提升决策一致性、减少冗余推理并优化 KV cache 利用率。模板中甚至包含 multi-step tool 的tool_response包裹校验逻辑确保工具结果不被当作独立用户查询处理。超长上下文原生支持 262,144 token 上下文README 给出通过 YaRNrope_type: yarn、factor: 4.0、original_max_position_embeddings: 262144将max-model-len扩展到101 万 token的完整配置覆盖 vLLM、SGLang、KTransformers 等框架——这是长程仓库级任务多文件定位、长对话压缩的刚需。评估透明性README 给出了可复现的评测协议——SWE-bench 系列采用claude_code2.1.195harness、passk1、temperature1.0、256k 上下文Terminal-Bench 2.1 采用 terminus-2 与 claude_code 双 harness 取平均PinchBench 采用openclaw2026.3.13。在这一统一协议下Dev 取得 SWE-bench Verified69.40、SWE-bench Multilingual63.00、SWE-bench Pro45.96、Terminal-Bench 2.141.02、PinchBench93.43、Scicode44.20、KAT-Code-Bench46.21全部高于同量级对比组Qwen3.5-27B、Qwen3.6-35BA3B、Gemma4-31B、Ornith-1.0-35B 等。值得注意的是README 还主动披露了评估偏差来源对 Qwen3.6-35BA3B 的自测结果与官方存在约 10pp 差距归因于 harness 版本与官方测试集优化对 Qwen3.5-35BA3B 与 Gemma4-26B-A4B 观察到在评测环境不可用的 MultiEdit 工具上的幻觉调用。这些备注把模型能力与harness 适配解耦恰恰是严谨的基准比较该有的样子。四、对复现者与竞品团队的三点启示启示一先修环境再调算法报告中最容易被低估的数字是沙箱反馈错误率早期约16%的轨迹至少包含一次环境自身导致的失败磁盘打满触发 GC 超时、环境变量覆盖导致 verifier 误判、单个沙箱边界错位可使后续约 40 步观测为空。团队最初把训练坍塌归因于 RL 算法本身投入大量精力调超参后才定位到环境问题。对任何复现者而言这条教训的优先级高于算法选型在奖励信号不干净之前任何 RL 算法都救不回来。AutoBuilder 给出的路径也很明确——用结构化测试解析 跨次可复现替代退出码 日志把环境构建本身做成一个可迭代的系统模板库 配方检索成功率可以从 16.5% 拉到 57.2%。启示二奖励设计要读基座模型的性格Dev 的训练历史提供了最直观的证据同样的配方换一个基座Qwen3.6简单的 0–1 奖励第二个 epoch 就崩而加入针对单轮并行工具调用过多、空工具块、重复内容、失败调用的惩罚后稳定跑满 10 个 epoch。这印证了报告提出的三层奖励结构的设计哲学——顶层核心任务得分锚定目标并防 reward hacking必须同时通过 fail-to-pass 与 pass-to-pass 测试中层行为约束全程规范化工具使用底层失败轨迹激励文件搜索 F2 得分、单元测试部分通过率把失败样本也变成有效学习信号。对竞品团队来说奖励系统应当作为针对模型病理行为的监控器 调节器来持续维护而不是一次性写死的公式。启示三开源的边界就是复现的边界对想复现 Dev 的团队README 与仓库已经划清了边界开源的是纯语言模型权重部署需显式--language-model-onlyvLLM或等效选项SGLang训练侧配方TITO token 一致性、TIS 截断重要性采样、可靠沙箱、层级奖励在 README.md 中均有描述但完整的环境构建与轨迹生成基础设施AutoBuilder、KwaiClawEnv属于 Pro 侧的系统能力未随权重开放。因此理性的复现路径是以 Qwen3.6-35B-A3B 为基座先复刻 SFT 127K 两阶段 RL 的骨架再依据自己基座的轨迹模式定制奖励惩罚项最后用 README 给出的统一评测协议同一 harness、passk1、256k 上下文来度量差距——而非期待直接拿到与 Pro 等价的完整系统。结语从 KAT-Coder-V2 到 V2.5快手把编码模型的后训练从喂数据、调损失升级为造环境、修信号、稳 RL、融专家的系统工程而 V2.5-Dev 的开源则把这套配方中最可迁移的部分——奖励适配的教训、评测的透明化、Agent 原生的推理与模板设计——以可下载、可运行、可对照的形态交付给了社区。对从业者而言这份报告最有价值的也许不是某个具体分数而是那句贯穿始终的判断当环境可复现、奖励可验证、轨迹可筛选时编码 Agent 的能力上限将由工程系统的质量决定而非参数规模。【免费下载链接】KAT-Coder-V2.5-Dev项目地址: https://ai.gitcode.com/hf_mirrors/Kwaipilot/KAT-Coder-V2.5-Dev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考