快手 KwaiKAT 團隊推出了 KAT-Coder-V2.5，這是一款編碼模型，設計目標是在真實、可執行的軟體倉庫中運作，而不是產生單輪程式碼片段。服務版模型可透過 StreamLake 使用。另有一個獨立的開放權重版本 KAT-Coder-V2.5-Dev，已依 Apache-2.0 授權發布於 Hugging Face。

此次發布聚焦於代理式編碼工作流程，也就是模型必須檢查倉庫、理解任務、編輯檔案、執行測試，並驗證修補程式是否正確。這一重點反映了編碼模型評估的一項更廣泛轉變：從孤立的程式設計提示，轉向倉庫級軟體維護；在這類場景中，可重現的環境與可靠的測試回饋，可能與程式碼生成品質同樣重要。該專案強調倉庫環境、資料建構、沙盒可靠性、強化學習基礎設施與基準測試評估。

AutoBuilder 建構可執行預期測試的環境

該研究將可驗證的編碼任務定義為三元組：精確的任務描述、可執行的倉庫環境，以及一組驗證測試。只有在修補程式通過完整驗證集時，才會被視為正確。

任務取自真實的 pull request 與 commit，沿用 SWE-bench 的脈絡。合併後的程式碼變更提供 golden patch，而相應的測試變更提供 test patch。系統不使用原始 issue 文字作為規格。相反地，任務描述會被重新生成為三個組成部分：以 golden patch 為基礎的問題陳述、由 test patch 推導出的需求，以及從兩者推斷出的介面限制。清晰度檢查會移除模糊、不完整、規格不足或內部不一致的任務。

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 drift。系統改為直接呼叫 /generate，以維持 rollout token 對齊。

總體而言，這些變更將沙盒回饋錯誤率從約 16% 降至低於 2%，並使訓練崩潰減少一個數量級。這項發現也凸顯了代理式程式碼訓練的一項實務限制：獎勵品質取決於周邊執行系統，而不僅是模型架構或最佳化方法。

非對稱 PPO 與三層獎勵

研究人員選擇搭配 GAE 的 PPO，而非不使用 critic 的軌跡方法，原因是生產環境中的 harness 會將 session 切分成結構不同的樣本，使群組基準更難建立。

訓練設定採用非對稱 actor–critic 設計。Critic 會取得特權訓練上下文，包括獎勵、測試、覆蓋率、修補程式、中繼資料與未來輪次。Actor 只能看到 rollout 狀態。在推論時，Critic 與額外上下文都會被丟棄。

獎勵分為三層。Core Task Scores 要求所有 fail_to_pass 與 pass_to_pass 測試都通過。Standard Behavior Constraints 會懲罰重複、無效工具呼叫與殘留除錯內容。Failed Trajectory Incentives 透過 F2 對檔案檢索評分，並對測試給予部分分數。

五個 expert 透過 Multi-Teacher On-Policy Distillation 結合，使用 reverse KL、off-policy start，以及來自 Prune-OPD 的 drift-aware truncation。

基準測試結果

在統一的 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 模型權重。