快手 KwaiKAT 团队推出了 KAT-Coder-V2.5，这是一款编程模型，旨在真实、可执行的软件代码仓库中工作，而不是生成单轮代码片段。服务版模型可通过 StreamLake 使用。另一个独立的开源权重版本 KAT-Coder-V2.5-Dev 已在 Hugging Face 上以 Apache-2.0 许可发布。

此次发布聚焦于智能体式编程工作流，在这类工作流中，模型需要检查代码仓库、理解任务、编辑文件、运行测试，并验证补丁是否正确。这一重点反映了编程模型评估的一种更广泛转变：从孤立的编程提示转向仓库级软件维护。在后者中，可复现环境和可靠的测试反馈可能与代码生成质量同样重要。该项目强调代码仓库环境、数据构建、沙箱可靠性、强化学习基础设施和基准评估。

AutoBuilder 构建可运行目标测试的环境

该研究将可验证的编程任务定义为一个三元组：精确的任务描述、可执行的代码仓库环境，以及一组验证测试。只有当补丁通过完整验证集时，才会被视为正确。

任务来自真实的 pull request 和 commit，沿用了 SWE-bench 的思路。合并后的代码变更提供黄金补丁，而随附的测试变更提供测试补丁。系统不使用原始 issue 文本作为规范。相反，任务描述会被重新生成为三个组成部分：基于黄金补丁的问题陈述、从测试补丁中推导出的需求，以及从两者中推断出的接口约束。清晰度检查会移除含糊、不完整、规范不足或内部不一致的任务。

AutoBuilder 负责环境构建流程。构建智能体会检查代码仓库，并编写一个配置脚本，用于从干净的 checkout 安装依赖并运行测试。随后，验证智能体会在隔离沙箱中执行该脚本。

验收流程不依赖退出码或日志模式匹配。相反，验证过程会解析来自测试框架的结构化输出。只有当超过 90% 的预期测试被收集，并且通过/失败结果能够在多次运行中复现时，环境才会被接受。失败会以结构化信息的形式返回，用于迭代修复。

通过结合预配置的基础环境、构建系统模板，以及可检索的精炼构建配方库，该团队将环境构建成功率从 16.5% 提高到 57.2%。由此形成的数据集包含跨 12 种编程语言的 100,000 多个可验证环境。Git 历史、commit 元数据和其他可被利用的痕迹会被移除，以防智能体直接从代码仓库中获取参考解法。

Data Scaling Flywheel 按过程质量进行过滤

该项目认为，仅按最终测试是否成功来过滤轨迹可能具有误导性。一些通过测试的运行可能依赖硬编码、绕过预期机制，或采用针对测试的捷径。与此同时，一些失败的运行仍可能包含有用的搜索、定位和修复行为。

KwaiKAT 同时处理这两种情况。对于接近成功的尝试，系统提供有针对性的过程级提示，指出应检查或验证什么，但不泄露解法。这使此前零通过任务的通过率提高到约 20%。由于带提示的轨迹包含推理阶段不可获得的信息，随后会固定已验证的补丁，并从原始任务上下文中重新生成一条不含提示的轨迹。只有通过验证、不包含提示泄露且与补丁保持一致的样本会被保留。

对于已经通过的轨迹，基于规则的门控会移除无效、不稳定或带有利用性质的样本。随后，评分阶段会评估探索、定位、编辑前推理、规范一致性、对代码仓库约定的遵循、补丁最小化、验证质量、恢复行为和诚实性。

第三种机制旨在减少对 harness 的过拟合。在保持功能不变的情况下，工具名称、参数约定、输出格式和提示模板会被随机化。由于验证绑定到测试结果，而不是 harness 痕迹，同一个任务可以在多种 harness 配置下重新呈现。系统还会注入现实扰动，包括缺失依赖、临时命令失败、截断输出和噪声日志。

沙箱故障在算法极限之前影响了奖励

在 KAT-Coder-V2 训练期间，缓慢的奖励曲线最初被归因于强化学习算法。后来的审计发现，约 16% 的轨迹失败是由沙箱基础设施问题造成的，而不是模型策略导致的。边界错位有时会使约 40 个步骤的观测为空，并破坏奖励。

团队实施了三项基础设施修复。首先，提前释放的镜像驱逐策略将磁盘使用率从 95% 降至 60%，使由超时导致的无效 rollout 从 6–7% 降至低于 1%。其次，在远程沙箱初始化期间修正环境变量，防止系统覆盖导致 6–7% 样本的奖励翻转，并将这些错误降至低于 1%。第三，Gateway Server 绕过主流聊天端点；这些端点会通过重新应用 apply_chat_template 和重新分词，在约 200 轮规模下造成 40% 的 token 漂移。系统改为直接调用 /generate，以保持 rollout token 对齐。

这些变更共同将沙箱反馈错误率从约 16% 降至低于 2%，并使训练崩溃次数降低了一个数量级。这一发现也突显了智能体式代码训练中的一项现实约束：奖励质量不仅取决于模型架构或优化方法，也取决于周边执行系统。

非对称 PPO 与三层奖励

研究人员选择了带 GAE 的 PPO，而不是无 Critic 的轨迹方法，因为生产 harness 会将会话拆分为结构上不同的样本，从而使组基线更加困难。

训练设置采用非对称 actor–critic 设计。Critic 接收特权训练上下文，包括奖励、测试、覆盖率、补丁、元数据和未来轮次。Actor 只看到 rollout 状态。在推理时，Critic 和额外上下文会被丢弃。

奖励被组织为三层。Core Task Scores 要求所有 fail_to_pass 和 pass_to_pass 测试通过。Standard Behavior Constraints 会惩罚重复、无效工具调用和调试残留。Failed Trajectory Incentives 通过 F2 评分文件检索，并为测试分配部分得分。

五个专家通过 Multi-Teacher On-Policy Distillation 进行组合，使用反向 KL、离策略起步，以及来自 Prune-OPD 的漂移感知截断。

基准测试结果

在统一的 Claude Code harness 下，KAT-Coder-V2.5 在 PinchBench 面板中以 94.9 的得分领先，高于 Opus 4.8 的 93.5。它在 SWE-Bench Pro 上以 65.2 对 69.2 排名第二，并在内部 KAT Code Bench 上以 53.1 对 57.3 排名第二。

该模型在 Terminal-Bench 2.1 上表现较弱，以 60.7 排在最后，落后于 GLM-5.1 的 61.8 和 Opus 4.8 的 84.6。在 SciCode 上，它得到 50.3，与 GLM-5.2 持平。由于代码仓库补丁、终端操作和科学编程测试衡量的是智能体式编程系统的不同部分，混合结果使 harness 和基准范围对解读结果尤为重要。

开源权重版本 KAT-Coder-V2.5-Dev 是一个独立的 35B-total / 3B-active MoE 模型，基于 Qwen3.6-35B-A3B，使用 127K 个 SFT 样本进行后训练，随后进行强化学习。它是在单独的内部协议下评估的，因此其结果不能与主要旗舰基准表直接比较。

该项目的主要材料包括论文、StreamLake 产品页面，以及 Hugging Face 上的 KAT-Coder-V2.5-Dev 模型权重。