企业官网建设流程全解析

三阶段训练 + Agentic RL Scaling：拆解 KAT 系列的训练范式

【免费下载链接】KAT-Coder-V2.5-Dev项目地址: https://ai.gitcode.com/hf_mirrors/Kwaipilot/KAT-Coder-V2.5-Dev

如果说 2024 年的代码大模型比拼的是"单点代码生成"，那么 2025 年以来的 Agentic Coding 赛道，比拼的已经是"端到端解决真实软件工程问题"的能力：读懂一个 GitHub Issue、规划修改路径、调用工具读写文件、跑测试验证、提交修复。快手 Kwaipilot 的 KAT 系列正是在这条赛道上跑出了一组行业标杆数字——闭源旗舰 KAT-Coder 在 SWE-Bench Verified 上拿到 73.4%，开源版本 KAT-Coder-V2.5-Dev 以 35B 总参、3B 激活的 MoE 架构，把 SWE-Bench Verified 做到 69.40%，并在 SWE-bench Multilingual、SWE-bench Pro、Terminal-Bench 2.1、PinchBench 等基准上全面领先同类模型。

分数背后真正值得研究的东西，是它的训练范式：Mid-Training → SFT & RFT → Agentic RL Scaling 的三阶段流水线，以及其中对"RL 如何稳定地训练 Agent"这一开放问题的工程化回答。本文结合社区公开信息与仓库源码，逐层拆解这套范式。

为什么"会写代码"不等于"会做工程"

传统代码模型的训练目标是"给定输入，补全正确代码"，评测集是 HumanEval 式的单函数问题。但 Agentic Coding 的工作负载完全不同：模型要在一个真实仓库环境中自主行动——理解 Issue 描述、搜索代码、编辑多个文件、执行命令、根据报错迭代、最终提交。这要求模型同时具备三类此前很少被同时训练的能力：

• 指令遵循：把自然语言需求稳定地翻译成可执行的动作序列，不跑题、不"答非所问"；
• 工具调用：按照既定协议调用git、编译器、测试运行器等外部工具，且不能"幻觉"出环境里根本不存在的工具；
• 多轮与长程：在数十上百轮的交互中保持上下文一致，不重复、不遗忘。

KAT 系列的三阶段设计，正是让模型依次跨过这三道门槛：先用 Mid-Training 打 Agent 素质基础，再用 SFT & RFT 对准真实开发场景，最后用 Agentic RL Scaling 在"试错—反馈"中打磨决策质量。

第一阶段：Mid-Training，把"Agent 素质"焊进底座

Mid-Training 阶段解决的核心问题是：通用基座模型并不天然具备"当一名软件工程师 Agent"的素质。这一阶段围绕六大能力做定向强化——指令遵循、工具使用、多轮交互、代码知识注入、通用推理、场景适配。其中"工具使用"的训练目标非常具体：让模型学会调用 Git、编译器、调试器等开发常用工具，例如根据需求自动完成 Git 提交、PR 操作的代码生成，而不是把工具调用当成一个纯文本格式问题。

这一设计在仓库里有直接的工程载体。看 chat_template.jinja，模型被要求使用一套严格的 XML 式工具调用协议：内层<function=...></function>必须嵌套在<tool_call></tool_call>之中，参数以<parameter=name>value</parameter>形式给出，工具执行结果则包裹在<tool_response></tool_response>标签中回填给模型。模板里甚至写明了约束："Function calls MUST follow the specified format""If there is no function call available, answer the question like normal"——这种把工具协议"焊死"在模板层的做法，本质上是为 RL 阶段提供一个稳定、可解析的动作空间：动作格式不确定，奖励就无从谈起。

第二阶段：SFT & RFT，从"会写"到"写好"

Mid-Training 解决"能不能做 Agent"，SFT & RFT 阶段解决"做得好不好、贴不贴真实场景"。据公开资料，KAT-Coder 系列的 SFT 数据覆盖 8 大用户任务（应用开发、功能实现、Bug 修复、代码重构、性能优化、测试用例生成、代码理解等）与 8 大编程场景（前端 UI/UX、数据科学、机器学习、数据库、基础设施、安全工程、配置部署等），让模型在进入强化学习前就对开发者的真实工作负载有充分覆盖。

RFT（Rejection Fine-Tuning 类方法）阶段引入"多 Ground Truth"机制：对同一需求采集多种可行的代码实现方案作为监督数据，而不是只保留单一"标准答案"。其收益在后续 RL 阶段才真正显现——多样化的轨迹起点让 rollout 更丰富，减少训练冗余，也避免模型因单一数据形成"思维固化"。

到 KAT-Coder-V2.5-Dev 这里，SFT 阶段的具体规模是可考的：团队以广受认可的 Qwen3.6-35B-A3B 为基座，在 127K 条样本上完成监督微调，再对 SFT 模型做 RL 训练（见 README.md）。与"从头做三阶段"的 KAT-Coder 系列不同，V2.5-Dev 走的是"成熟基座 + SFT + RL"的精简路线，但其 RL 配方完整继承了 KAT-V2.5 的四大技术设计——这正是第三阶段的核心看点。

第三阶段：Agentic RL Scaling，范式真正的护城河

Agentic RL 的难点不在于"定义奖励"，而在于在异步 rollout、真实沙盒执行、超长轨迹的条件下，让训练稳定收敛。KAT 系列在 Agentic RL Scaling 阶段沉淀了四项关键技术，在 README.md 中有明确记载：

1. Token-in-Token-out（TITO）一致性：保证 rollout 与训练阶段的 token 序列严格一致，杜绝因聊天模板、序列化或分词器行为差异导致的训练信号错位——在异步分布式 RL 里，这类隐蔽的不一致会被放大成灾难；
2. 截断重要性采样（TIS）：异步 rollout 天然带来策略陈旧与 off-policy 问题，TIS 通过截断重要性权重，压制过大权重造成的方差与训练不稳定；
3. 可靠沙盒与验证器：系统性检查沙盒与验证器的稳定性和正确性，防止"执行超时、环境错误、验证器误判"这类基础设施故障被当成模型错误惩罚，从而污染奖励信号；
4. 基于执行反馈的层级奖励：把工具执行返回的细粒度反馈拆解为多层奖励——模型即使最终没有跑通，也能在失败轨迹中获得"有意义进展"的信用，提高失败样本的训练价值。

更值得借鉴的是团队处理"Qwen3.6 水土不服"的过程，这几乎是每个做 Agentic RL 的人都会踩的坑。初始实验里，简单的 0-1 二元奖励在第二个 epoch 就让模型崩溃；分析轨迹发现，模型越来越倾向于在单回合内发起大量并行工具调用，最多一次超过 70 个，导致上下文爆炸、无效轨迹和错误堆积。团队的解法不是推翻框架，而是在层级奖励之上追加针对性的惩罚项：单回合过多并行工具调用、工具调用失败、空工具调用块、大量重复内容。这些纠偏让 RL 稳定推进了10 个 epoch。

效果直接反映在"行为健康度"上——这是比基准分更见训练功力的指标：异常工具标签出现率从 9.34% 降到 0.28%（-9pp），单回合连续重复从 0.34% 降到 0%。也就是说，经过 RL 训练，模型不再胡乱调用环境中不存在的工具，也不再陷入无意义的自我重复。对照同类模型的评测报告（如某些竞品在 Agent 环境中反复尝试调用不支持的 MultiEdit 工具、因上下文溢出而崩坏），更能理解这套"行为优化"的稀缺性——基准分数可以被算力堆出来，行为稳定性只能靠训练设计抠出来。

在更大的 KAT-Coder 系列尺度上，Agentic RL Scaling 还叠加了工程侧创新：熵引导树剪枝（把海量轨迹组织成前缀树，按熵与访问概率剪枝，把计算预算集中到高信号节点）与 SeamlessFlow 异构调度（训练流程与 Agent 逻辑解耦，让 CPU/GPU 集群资源接近"零气泡"运行）。这些是支撑"RL 规模化"（Scaling）的基础设施，正是它与普通"给模型做一轮 RL"的本质区别。

Agent 增强在源码里的落点：思考保留、工具协议与长上下文

指令遵循、工具调用、Git 操作这三类 Agent 能力，最终都要落到推理期的协议与配置上。仓库里可以逐项对证：

• 工具调用的协议与容错：如前述 chat_template.jinja 定义的<tool_call>协议，同时模板支持enable_thinking（关闭思考直接回答）与preserve_thinking（保留历史轮次的推理痕迹）两种模式。preserve_thinking对 Agent 场景尤其关键：完整推理上下文能提升多轮决策一致性、减少重复思考的 token 开销、优化 KV 缓存利用——这解释了 RL 训练中"重复内容惩罚"为何能同时改善行为与推理成本。
• 超长上下文支撑多文件工程任务：模型原生支持 262,144 token 上下文（config.json 中max_position_embeddings: 262144），并可经 YaRN 缩放扩展至约百万 token（README 给出的配置为factor: 4.0、max-model-len 1010000）。代码库级任务动辄数万 token 的上下文，是 Agent 范式成立的前提。
• MoE 架构的成本结构：config.json 显示该模型 40 层、256 个专家、每 token 激活 8 个专家，且层类型采用 linear attention 与 full attention 每 4 层交替的混合注意力设计——3B 激活参数意味着单卡即可运行，这是"开源复刻"在经济性上的关键。

这套范式对开源复刻的参考价值

把 KAT 系列的范式压缩成可迁移的清单，大致是四句话：

第一，动作空间要先于奖励设计。工具协议、模板、token 序列的一致性（TITO）没有做好之前，RL 奖励再精巧也是空中楼阁。V2.5-Dev 在 SGLang/vLLM 部署时要求--tool-call-parser qwen3_coder、--reasoning-parser qwen3（见 README.md），正是为了保证推理时生成的结构与训练时一致。

第二，奖励必须"防崩溃"优先于"求最优"。Qwen3.6 案例说明，0-1 奖励在 Agent 场景下极易被"刷并行调用"这类捷径击穿；对病态行为的显式惩罚（并行过多、调用失败、空调用块、重复内容）是稳定训练的必需品，层级奖励则是提升失败样本价值的放大器。

第三，沙盒可靠性是奖励信号的护城河。执行超时、环境错误、验证器误判一旦混入奖励，模型会把"环境坏了"学成"我错了"，污染难以逆转。KAT 团队将其列为四大支柱之一，复刻者应同样重视。

第四，用"行为健康度"而非单一分数验收 RL。异常工具标签率、重复率这类指标比总分更能暴露训练信号的质量；9.34% → 0.28% 的收敛背后，是完整一套"检测病态行为—定位轨迹原因—设计惩罚项"的闭环方法论。

最后回到开源本身：KAT-Coder-V2.5-Dev 以 Apache-2.0 协议开放权重，配套 config.json、generation_config.json、tokenizer_config.json 等完整推理配置，API 兼容 OpenAI 格式，覆盖 SGLang、vLLM、KTransformers、Transformers 四大推理框架。对于想复刻 Agentic RL 训练范式的团队，它同时提供了"结果"（35B/3B 的 SOTA 权重）与"过程"（可验证的训练配方与踩坑记录）。当训练范式的每一步都有源码与数据可查、每个奖励设计都有崩溃案例与修复记录可循时，"Agentic Coding 的训练"才真正从玄学变成了工程。

【免费下载链接】KAT-Coder-V2.5-Dev项目地址: https://ai.gitcode.com/hf_mirrors/Kwaipilot/KAT-Coder-V2.5-Dev