“軟工任務要改多文件、多輪工具調(diào)用，模型怎么學透？高質(zhì)量訓練數(shù)據(jù)稀缺，又怕軌跡含噪聲作弊？復雜 RL 訓練成本高，中小團隊望而卻步？”

華為研究團隊推出SWE-Lego， 僅基于監(jiān)督微調(diào)（SFT）的軟件工程代碼智能體，無需復雜 RL 流程，在 SWE-bench Verified 基準中斬獲同等規(guī)模開源模型 SOTA，甚至超越部分更大規(guī)模閉源模型！項目已開源，代碼、模型和全部數(shù)據(jù)一鍵獲��！

• arXiv 地址：https://arxiv.org/abs/2601.01426
• GitHub 地址：https://github.com/SWE-Lego
• HuggingFace 地址：https://huggingface.co/SWE-Lego

SWE-Lego 具有三大創(chuàng)新，包括數(shù)據(jù)、訓練和測試時擴展。

1. 混合數(shù)據(jù)集構建：

• 雙數(shù)據(jù)管道互補：GitHub 真實 PR 數(shù)據(jù) + 注入真實場景 Bug 的合成數(shù)據(jù)，產(chǎn)出 32k 高質(zhì)量任務實例 + 18k 專家軌跡；
• 嚴格軌跡篩選：過濾 Git 歷史泄露、工具錯誤等噪聲，重用部分解決的優(yōu)質(zhì)軌跡，提升 SFT 訓練有效性。

2. 改進的監(jiān)督微調(diào)：

• 兩大亮點：① 步驟級錯誤掩碼，讓模型從長軌跡中學習有效子軌跡；② 課程學習，按交互輪次分級提升任務難度；
• 性能提升：比傳統(tǒng) SFT 在不同模型上提升 2~4%，筑牢 SOTA 基礎。

3. 測試時擴展策略（TTS）：

• 擴展優(yōu)先級：先串行擴展（增大軌跡最大交互輪數(shù)）至飽和，再分配資源給并行擴展（多備選答案選最優(yōu)）；
• 打分器優(yōu)選：生成式打分器在并行擴展中，全程優(yōu)于回歸式打分器，適配不同模型規(guī)模與測試預算。

引言

在軟件工程領域，Code Agent 需要處理復雜的任務：修復 bug、重構代碼、理解大型代碼庫。這些任務要求 Code Agent 具備長序列推理、多文件操作和工具使用等能力。現(xiàn)有的訓練方法通常需要復雜的訓練范式，比如強化學習（RL）或者 RL 和 SFT 的迭代組合。

這些方法雖然有效，但計算成本高，訓練過程復雜。能否用更簡單的方法達到同樣的效果？

華為的研究團隊提出了SWE-Lego，一個僅基于監(jiān)督微調(diào)（SFT）的軟工代碼模型的解決方案。在 SWE-bench Verified 基準測試上基于 Qwen3 系列模型作為起始模型，經(jīng)過 SFT 之后得到 SWE-Lego-Qwen3-8B 和 32B 分別達到 42.2% 和 52.6%，達到了開源模型的 SOTA 水平，并超越了一些更大規(guī)模的閉源模型。基于測試時擴展策略（TTS）可以進一步把性能提高 6~7%。

圖 1：SWE-Lego 系列模型在 SWE-bench Verified 上的性能對比，在同等規(guī)模模型中表現(xiàn)達到 SOTA

一、挑戰(zhàn)與動機

軟件工程任務與傳統(tǒng)的單文件編程任務有著明顯區(qū)別：一個 bug 修復可能涉及代碼項目里多個文件的修改，需要多輪工具調(diào)用（讀取文件、執(zhí)行測試、編輯代碼等），必須在真實的代碼庫環(huán)境中驗證修復效果，還需要理解代碼邏輯、定位問題、設計修復方案等復雜推理能力。

為了訓練具備軟件工程項目級代碼編寫能力的代碼模型，研究者們嘗試了多種方法。強化學習（RL）雖然不需要預定義的軌跡，但訓練成本極高。復雜組合方法將多種訓練范式結合，比如 SFT 和 RL 的迭代訓練，進一步增加了訓練復雜度。更重要的是，高質(zhì)量的訓練數(shù)據(jù)稀缺。現(xiàn)有的數(shù)據(jù)集要么規(guī)模有限，要么缺乏可執(zhí)行環(huán)境，要么難以擴展到足夠大的規(guī)模。

二、SWE-Lego 的三大核心組件

SWE-Lego 包含三個核心組件：

圖 2：SWE-Lego-Qwen3-32B 的性能提升分解，混合數(shù)據(jù)集貢獻最大（+25.6%），改進的 SFT 貢獻 + 3.8%，TTS 貢獻 + 6.2%

從圖 2 可以看到每個組件的貢獻：混合數(shù)據(jù)集貢獻 + 25.6%（最大貢獻），改進的 SFT 貢獻 + 3.8%，測試時擴展貢獻 + 6.2%。總計從基線 23.2% 提升到 58.8%，提升了 35.6 個百分點。這些結果清楚地表明，好的數(shù)據(jù)集是性能提升的最大驅(qū)動力，而改進的 SFT 和測試時擴展提供了不錯的增量收益。

核心組件一：混合數(shù)據(jù)集構建

SWE-Lego 數(shù)據(jù)集包含 32,119 個高質(zhì)量任務實例，18,110 個驗證軌跡（其中 14,110 個完全解決，4,000 個半解決），覆蓋 3,251 個代碼倉庫。

SWE-Lego 采用混合數(shù)據(jù)構建策略，結合真實世界數(shù)據(jù)和合成數(shù)據(jù)。真實世界數(shù)據(jù)來自嚴格篩選的 GitHub Pull Requests （PRs），這里的 PRs 中非測試文件作為 Golden Patch, 也就是這個任務的解決方案。真實 PR 數(shù)據(jù)具有貼近生產(chǎn)環(huán)境的優(yōu)勢，能夠提供真實的 bug 的復雜性，真實的任務參考 SWE-rebench [1]。但是真實數(shù)據(jù)數(shù)量有限，且每個任務需要獨立的沙箱環(huán)境，成本較高。

參考 SWE-smith [2] 的通過故意引入 Bug 來合成軟工任務的方式，SWE-Lego 通過 AST 轉換和 LLM 重寫，基于真實代碼倉得到相應的合成軟工數(shù)據(jù)，對可以通過測試的代碼庫故意引入一些 Bug。具體地，AST 轉換提取抽象語法樹（AST）并應用隨機變換，如移除條件 / 循環(huán)、修改運算符或依賴關系，而 LLM 重寫則提示模型使用函數(shù)頭和文檔字符串等信息重寫代碼。引入 Bug 的補丁進行反轉就可以得到解決這個任務的 Golden Patch。合成數(shù)據(jù)具有可擴展、成本低、多個任務可共享沙箱的優(yōu)勢，但復雜度相對較低。

在下一步，團隊對真實和合成數(shù)據(jù)采用測試驅(qū)動的方式去得到驗證后的軟工數(shù)據(jù)實例，篩選出合格的軟工任務。具體地，在應用 Golden Patch 前可以通過的測試在應用 Golden Patch 之后仍然可以通過， 而應用 Golden Patch 前不通過的測試在應用 Golden Patch 之后也需要通過。

圖 3：SWE-Lego 數(shù)據(jù)管道，結合真實 PR 和合成的軟工任務實例，基于專家模型去生成可執(zhí)行的軌跡用于 SFT 訓練

真實數(shù)據(jù)提供深度（復雜性和真實性），合成數(shù)據(jù)提供廣度（數(shù)量和覆蓋范圍）。兩者互補：真實數(shù)據(jù)提供主要收益但難以擴展，合成數(shù)據(jù)通過進一步擴展提供額外收益。實驗證明，增加合成數(shù)據(jù)可以顯著提升有效軌跡數(shù)量和下游性能。

圖 4：隨著合成實例的增加，有效軌跡數(shù)量顯著增長

圖 5：隨著混合數(shù)據(jù)的增加，模型的性能逐步提升

• 軌跡質(zhì)量優(yōu)化

為了確保訓練數(shù)據(jù)的質(zhì)量，SWE-Lego 實施了嚴格的軌跡生成和驗證流程。

防止解決方案泄露：最近 SWE-Bench 社區(qū) [3] 發(fā)現(xiàn)，LLM 可能通過查看 Git 歷史來 "作弊"，直接找到正確答案。為了防止這種解決方案泄露，對于真實實例，SWE-Lego 移除問題創(chuàng)建日期之后的所有提交和日志消息，使未來的修復不可見；對于合成實例，由于有 bug 的版本在無 bug 的版本之前（由于故意的 bug 注入），完全移除整個 Git 歷史和所有日志，只暴露 buggy 代碼庫的單個快照。這迫使模型真正推理代碼和測試，而不是從版本控制中讀取答案。

處理工具調(diào)用錯誤：在使用 Qwen3-Coder-480B-A35B-Instruct 作為教師模型時，觀察到對 str_replace_editor 工具的頻繁格式錯誤調(diào)用，例如將字符串傳遞給 view_range 或指定超出范圍的行范圍，導致工具失敗并浪費交互預算。為了緩解這些錯誤，SWE-Lego 應用輕量級后處理：如果 view_range 是字符串，則在執(zhí)行工具之前將其轉換為整數(shù)；如果請求的行范圍超過文件長度，則返回有效行的子集而不是引發(fā)錯誤，使得模型能夠更可靠地檢查代碼。

精簡工具集：雖然任務管理工具（如 task_tracker）已被一些最近的專有模型采用，但發(fā)現(xiàn) Qwen3-Coder-480B-A35B-Instruct 無法有效使用它們，經(jīng)常導致執(zhí)行錯誤。因此，SWE-Lego 丟棄此工具，將工具集限制為四個基本操作：execute_bash、str_replace_editor、think 和 finish，以保持軌跡精簡。

軌跡過濾策略：SWE-Lego 通過應用預測補丁并運行測試集來驗證軌跡。如果軌跡通過所有測試，則分類為已解決，否則為未解決。然后，過濾低質(zhì)量的已解決軌跡（例如，通過修改測試文件來 "作弊" 的軌跡），并重用部分解決軌跡（那些正確識別了所有相關文件但未能修復的軌跡）。這些部分解決軌跡提供了有價值的故障定位監(jiān)督，我們發(fā)現(xiàn)加入此類數(shù)據(jù)會適當提升模型的性能。

圖 6：軌跡生成中的關鍵實踐，包括防止 Git 泄露、處理工具錯誤、精簡工具集

表 1：SWE-Lego 的可驗證的任務實例和有效訓練軌跡的統(tǒng)計以及和其他 SWE 相關工作的數(shù)據(jù)對比

具體的數(shù)據(jù)統(tǒng)計和對比見表 1，可以看出 SWE-Lego 的混合數(shù)據(jù)管道提供了數(shù)量充足的、代碼倉多樣的、環(huán)境可驗證的 SWE 任務實例和軌跡。

總結：混合數(shù)據(jù)集是性能提升的最大驅(qū)動力。真實數(shù)據(jù)與合成數(shù)據(jù)互補確保了數(shù)據(jù)數(shù)量，嚴格的軌跡驗證確保了軌跡的質(zhì)量。

核心組件二：改進的監(jiān)督微調(diào)

通常的監(jiān)督微調(diào)將通過測試驗證的整條軌跡拿去訓練，但實際上在軟工的場景，專家軌跡需要多輪在沙箱中交互得到最后的預測補丁，即使最終成功解決的軌跡也可能包含中間錯誤步驟，盲目學習這些錯誤可能強化不良行為。另外，不同數(shù)據(jù)的難度不同，在訓練初期讓模型學習難題可能比較吃力。針對這些情況，SWE-Lego 提出了兩個改進：

• 改進 1：步驟級錯誤掩碼

核心思想：保持完整軌跡上下文，但只對正確的步驟計算損失。

圖 7：步驟級錯誤掩碼示例，錯誤步驟被掩碼，模型只學習正確的操作

實現(xiàn)方法：使用正則表達式識別終端環(huán)境提供的錯誤消息，對相應的模型響應應用錯誤掩碼。關鍵是要排除因復現(xiàn) bug 或執(zhí)行測試文件而產(chǎn)生的錯誤。這種方法保持完整的軌跡上下文，但只對正確的步驟計算損失，使模型能夠?qū)W習正確的操作和恢復策略，而不會強化錯誤。通過強調(diào)學習正確操作，直接減少了核心推理失敗，如 "錯誤實現(xiàn)" 和 "定位錯誤"。

• 改進 2：基于難度的課程學習

核心思想：從簡單任務開始，逐步增加難度。

SWE-Lego 探索了兩種難度分類方法：基于模型的評分和基于軌跡輪數(shù)的啟發(fā)式。研究發(fā)現(xiàn)，軌跡輪數(shù)與解決率之間存在強負相關（相關系數(shù) - 0.95）。基于這一發(fā)現(xiàn)，SWE-Lego 采用可以直接獲取的指標，軌跡輪數(shù)，作為軌跡的難度指標，將數(shù)據(jù)分為三個難度等級：簡單（0-50 輪）、中等（50-70 輪）、困難（70-100 輪）。訓練策略采用三階段課程：先訓練簡單任務，再逐步加入中等和困難任務。這種課程學習與訓練動態(tài)一致：首先讓模型在 "簡單" 任務上克服基本的 "無法復現(xiàn)" 錯誤，然后引入 "困難" 任務以發(fā)展避免 "超出最大輪次" 失敗所需的戰(zhàn)略規(guī)劃。

圖 8：軌跡輪次與平均解決率之間的強負相關關系

• 訓練過程分析

通過分析訓練過程中的錯誤類型演變，可以清楚地看到模型的學習軌跡：

圖 9：訓練過程中解決率的提升趨勢

圖 10：訓練過程中錯誤類型的演變，從早期的 "無法復現(xiàn)" 到后期的 "錯誤實現(xiàn)"

錯誤類型的變化：訓練初期時 "無法復現(xiàn)" 錯誤占主導，表明模型此時缺乏對軟工任務基本的理解能力；訓練中期時 "無法復現(xiàn)" 比例大幅減少，但 "定位錯誤" 比例仍有較多，表明缺乏戰(zhàn)略規(guī)劃；訓練后期 "錯誤實現(xiàn)" 成為瓶頸，表明從過程失敗轉向推理失敗。

改進的 SFT（錯誤掩碼 + 課程學習）帶來 3.8% 的性能提升。在 SWE-bench Verified 上，SWE-Lego-Qwen3-8B 達到 42.2%，SWE-Lego-Qwen3-32B 達到 52.6%。通過漸進式訓練和選擇性學習，模型能夠更有效地掌握復雜任務。

核心組件三：測試時擴展

測試時擴展（TTS）可以在不重新訓練的情況下，通過在測試階段分配額外的計算資源來提升性能。SWE-Lego 系統(tǒng)研究了兩個正交維度：

• 維度 1：串行擴展 vs 并行擴展

SWE-Lego 研究了串行擴展和并行擴展之間的資源分配。串行擴展通過增加最大交互輪次實現(xiàn)，在低測試預算的區(qū)域非常高效。額外輪次都能獲得環(huán)境反饋，使模型能夠糾正錯誤并迭代改進解決方案。這使得串行擴展在預算有限時成為首選策略。然而，模型性能在約 100-140 輪后開始飽和，此時相比于串行擴展，更加需要并行擴展來提升性能。

并行擴展生成多個候選軌跡，用打分器選擇最佳的軌跡。在串行擴展飽和后，并行擴展變得更加有效，因為每個獨立軌跡探索解決方案空間的不同路徑。

圖 11：串行擴展和并行擴展的權衡，等延遲曲線顯示了最優(yōu)資源分配策略

在有限的測試階段計算預算下，應優(yōu)先進行串行擴展；在串行擴展飽和后，將剩余計算資源分配給并行擴展。圖 11 中的等延遲等高線說明了這種權衡：在等效延遲下，最優(yōu)分配隨著總延遲預算的增加從順序主導轉向并行主導。

• 維度 2：生成式 vs 回歸式打分器

打分器用于從多個候選軌跡中選擇最佳方案。SWE-Lego 比較了兩種范式：回歸式打分器和生成式打分器。

回歸式打分器在模型上添加一個頭輸出，使用二元交叉熵損失訓練，對整個軌跡轉化為單個標量去打分。生成式打分器將驗證表述為文本生成任務，預測 "是" 或 "否"，從輸出 "是" 或 "否的"token 概率計算分數(shù)。生成式打分器的訓練目標與預訓練的下一個 token 預測目標對齊，可能更好地利用模型的固有知識。

圖 12：生成式打分器與回歸式打分器的對比，生成式打分器在 K 值較大時持續(xù)改進

在 rollout 的個數(shù)（K 值）比較小時，生成式打分器與回歸式打分器兩者的性能相近；隨著 rollout 的次數(shù)（K）的增加，回歸式打分器趨于飽和，而生成式打分器持續(xù)改進。對于 SWE-Lego-Qwen3-8B，在 K=16 時差距達到 2.8%（49.6% vs 46.8%）。

圖 13：SWE-Lego 打分器與現(xiàn)有公開打分器的對比

SWE-Lego-Verifier-8B 在 TTS@16 上達到 49.6%，超越了 OpenHands-Critic-32B（44.0%）和 R2E-Gym-Verifier-14B（47.0%）。除了絕對性能外，還觀察到不同打分器范式的定性不同縮放行為。OpenHands-Critic-32B 采用回歸式范式，在更高的 K 值下表現(xiàn)出性能下降，這是一個反直覺的結果，表明更大的候選池壓倒了其判別能力。相比之下，生成式打分器（SWE-Lego 和 R2E-Gym）保持單調(diào)改進，趨向于 Pass@K 上限，進一步確認生成式表述提供了更穩(wěn)健的縮放屬性。

總結：測試時擴展可以在測試階段帶來額外提升。在測試的計算預算比較低的時候，串行擴展優(yōu)先于并行擴展。生成式打分器在并行擴展中表現(xiàn)更優(yōu)。

三、結語與展望

SWE-Lego 證明了輕量級方法也能達到 SOTA，不一定需要復雜的 RL 或 SFT 和 RL 的迭代訓練，SFT 也可以取得軟工任務的 SOTA 性能。數(shù)據(jù)質(zhì)量至關重要，混合數(shù)據(jù)集和嚴格驗證是性能提升的關鍵。訓練技巧的價值也不容忽視，錯誤掩碼和課程學習等看似簡單的改進也帶來了性能提升。

未來將探索更大模型和更多數(shù)據(jù)的組合，擴展到 Python 之外的其他編程語言和其他類型的代碼任務，處理企業(yè)級的長序列、多文件任務，并將 SWE-Lego 應用到真實的軟件開發(fā)流程中。

參考文獻

[1] Badertdinov, I., Golubev, A., Nekrashevich, M., Shevtsov, A., Karasik, S., Andriushchenko, A., ... & Yangel, B. (2025). SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents. arXiv preprint arXiv:2505.20411.

[2] Yang, J., Lieret, K., Jimenez, C. E., Wettig, A., Khandpur, K., Zhang, Y., ... & Yang, D. (2025). Swe-smith: Scaling data for software engineering agents. arXiv preprint arXiv:2504.21798.

[3] https://github.com/SWE-bench/SWE-bench/issues/465