在權威SWE-Bench Verified基準測試中， JoyCode Agent憑藉 74.6% 的高通過率

強勢登榜全球 Top3， 並正式開源！

Github開源地址：https://github.com/jd-opensource/joycode-agent 

Gitee開源地址：https://gitee.com/JD-opensource/joycode-agent

JoyCode Agent 展現出了卓越的複雜編程問題解決能力。 與榜單先進方案相比，JoyCode Agent 在實現相近性能表現的同時，將計算資源消耗降低了 30%-50% 。這一成果不僅體現了 JoyCode Agent 高效應對複雜編碼挑戰的能力，更彰顯了其在實際應用中的高性價比和商業價值。

摘要

SWE-bench 作為當前自動軟件工程修復領域的代表性基準，要求智能體具備高效的補丁生成與驗證能力。隨着大語言模型的發展，實際場景中的軟件工程任務已經能被進一步的解決了，但基於提示詞工程的方法已經不能很好的解決代碼倉庫級別的工程修復任務。基於上述的困境，本文提出了一種以“補丁–單測協同生成與迭代驗證”為核心的自動修復框架。

具體而言，我們首先在 Docker 隔離環境中針對具體代碼倉庫生成初始補丁，並同步生成 Fail2Pass 和 Pass2Pass 兩類單元測試，對補丁效果進行全面驗證。當補丁通過所有自動生成的單測時，直接作為最終修復結果輸出；若測試未通過，則設計一套校驗流程判定問題源自補丁本身還是測試用例，並據此有針對性地重新生成補丁或單測，實現高效的錯誤定位與自適應迭代。最終，系統可獲得高質量的補丁池，為實際軟件倉庫問題的自動化修復提供有力支持。實驗結果表明，該方案在 SWE-bench 標準任務上能夠顯著提升補丁正確率與修復覆蓋率。

JoyCode京東雲開發者社區： https://developer.jdcloud.com/article/4365

JoyCode算法文章集合：

1. JoyCode-CSR上下文引擎：深度理解倉庫代碼 2. 智能編程之道：什麼樣的代碼才適合智能編程時代？【AI助力全員提效】 3. JoyCode-智能編碼質量管理方案【模型技術能力支撐方向】 4. 深入剖析：JoyCode-CSR上下文引擎的核心技術與實現 5. JoyCode在SWE-Bench Verified榜單的成績

一、項目背景與目標

1.1 SWE-bench 任務簡介

SWE-bench Verified 是由普林斯頓大學等機構開發的軟件工程基準測試，專門用於評估AI系統解決真實軟件工程問題的能力。該基準測試收集了來自 scikit-learn、matplotlib、requests 等知名開源 Python 項目的真實 GitHub Issues，要求AI模型理解問題描述、分析現有代碼庫結構，並生成能夠修復 Bug 或實現新功能的代碼補丁。與傳統的代碼生成任務不同，SWE-bench Verified 測試的是 AI 在複雜真實環境下的綜合編程能力，包括多文件協調、上下文理解和業務邏輯把握等，評估標準主要基於生成的代碼是否能在Pass\@1 就通過完整的測試套件驗證。

1.2 項目挑戰與得分概述

1.項目挑戰

◦代碼庫級理解與跨文件推理：相比於函數級別的任務，SWE-bench 涉及真實項目中的複雜問題，通常需要對整個代碼庫有全局性的理解，能夠跨文件、跨模塊進行推理和修復。這要求模型不僅能生成語法正確的補丁，還要保證語義上的一致性與正確性。

◦大規模解空間與候選方案管理：由於可能的修復路徑多樣，候選補丁空間巨大。如何高效生成、篩選、驗證和整合這些補丁，避免冗餘和錯誤，是當前系統面臨的核心技術瓶頸。

◦推理軌跡多樣性與進化：LLM 生成的解決方案往往趨同，缺乏真正多樣化的推理路徑，導致探索空間有限，難以發現創新性或邊緣性的正確修復。如何讓模型跳出高概率、慣性化的模式，挖掘潛在正確解，是提升成功率的關鍵。

◦自動化驗證與反饋循環：修復補丁需要自動化測試和驗證機制，以確保補丁真的解決了問題且沒有引入新故障。高效的測試反饋機制和驗證策略仍有很大提升空間。

2.得分概述

◦在 SWE-bench Verified 的 Pass\@1 官方評測中，目前取得 74.6% 的通過率。該分數來自於“補丁–單測協同生成與迭代驗證”的完整流程：先生成 Pass2Pass 和 Fail2Pass 單測，再進行首輪 Patch 生成，並在 Docker 隔離環境中執行單測驗證，失敗樣例進入“軌跡壓縮 ****+ CRS 檢索 + 二輪重試”的後處理流程。

二、業界現狀與優化思路

2.1 業界現狀與痛點

1.提示詞工程“一次性生成”在倉庫級任務上失效

◦本質問題：單輪大模型推理難以覆蓋複雜倉庫的代碼依賴、跨文件語義與歷史上下文，容易出現“語義漂移”和“脆弱一致性”。

◦典型症狀：Patch通過少量樣例測試但在全量測試中失效；針對特定 Issue 的“過擬合式修復”；同一倉庫的類似問題難以遷移複用，還可能引入新問題。

◦直接影響：成功率波動大、可復現性差，難以穩定提升 Pass\@1。

2.失敗僅“報錯不歸因”，導致重試無方向

◦本質問題：缺乏對失敗來源的系統性建模，無法區分“Patch邏輯錯誤”“工具定位錯誤”“環境/依賴異常”等根因，重試策略主要為盲目搜索。

◦典型症狀：重複觸發相同錯誤、無效重跑佔比高；token 主要消耗在“錯誤分佈內部”的局部探索；調參靠經驗，策略不可解釋。

◦直接影響：重試效率低，導致整體吞吐和穩定性受限。

3.缺乏經驗複用，長尾難例收斂慢、覆蓋率受限

◦本質問題：多數系統將每個實例當作“獨立樣本”，沒有構建可遷移的“成功策略表徵”與“失敗模式畫像”，難以跨實例複用解決方案。

◦典型症狀：相似問題反覆探索同類無效路徑；在複雜倉庫（如 django、scikit-learn）中對同類型 Bug 的“重複踩坑”；調度與提示詞無法受先驗知識指導。

◦直接影響：對長尾問題的處理成本指數級上升，難以在固定預算內擴大覆蓋率或穩定提升上限。

4.Token 消耗爆炸，成本–收益比失衡

◦本質問題：將“多次獨立運行 + 結果求並集 + 穩健投票”作為主路徑，而非建立“有方向的閉環迭代”，導致候選規模不受控。

◦典型症狀：海量候選採樣後，仍在錯誤分佈內做“次優選擇”；投票只能在“整體質量一般”的集合裏勉強挑選相對較好的方案。

◦直接影響：token 使用量與延遲快速攀升；單位 token 的有效產出下降；系統工程複雜度提升但邊際收益遞減。

5.多輪代理的誤差累積與路徑依賴

◦本質問題：倉庫級修復需要多輪工具調用與策略決策；早期的微小偏差（定位錯誤、解釋偏誤）會在後續步驟被放大，造成路徑依賴與誤差累積。

◦典型症狀：代理在錯誤上下文中越走越偏；最終Patch與問題無關或引入副作用；即便投票，也可能只是從“同一錯誤簇”中選一個“相對不差”的。

◦直接影響：整體效率與質量被鏈路前段的誤差所綁架，後續再多的採樣與投票都難以扭轉結果。

2.2 我們的優化思路及優勢

1.針對“一次性生成失效”的問題

◦現狀：單次大模型推理對倉庫級修復的覆蓋率不足，缺少驗證閉環，難以穩定提升 Pass\@1。

◦我們的思考：倉庫級修復是一個“生成–驗證–修正”的閉環問題，不能只依賴一次性生成。需要將“ Patch 生成”和“測試生成/預驗證”耦合，形成以測試為中心的工程反饋迴路。

◦我們的優化：將補丁生成與 Fail2Pass & Pass2Pass 單測協同設計，並在隔離環境下進行嚴格驗證；失敗樣例進入結構化後處理（歸因→指向性重試）。這使得系統從“單輪採樣”轉為“閉環迭代”，輸出具備可驗證證據的補丁。

◦相比同類的優勢：許多方案要麼只做補丁生成，要麼只依賴現有測試。我們採用“動態測試協同生成 + 原倉預驗證”的策略，在問題前置階段就過濾掉“測試不成立”的噪聲，顯著提升整體的穩定性。

2.針對“失敗僅報錯不歸因”的問題

◦現狀：失敗後難以判斷責任邊界（補丁邏輯 vs 測試設計 vs 環境/依賴），導致不可控的反覆重試。

◦我們的思考：精細化失敗歸因是提高重試效率的關鍵。只有明確問題來源，才能設計差異化的重試路徑，實現更低的 token 消耗與更快的收斂。

◦我們的優化：引入“失敗歸因”機制，將失敗拆分為可執行的類別標籤；針對不同標籤，選擇“基礎重試/測試側修正/策略升級” 等不同路徑，形成可解釋的再求解過程。

◦相比同類方法的優勢：與“黑盒重跑”不同，我們通過歸因實現“有方向的迭代”，減少無效探索和隨機波動，穩定提升成功率。

3.針對“缺乏經驗複用”的問題

◦現狀：大多數系統對於歷史成功案例“看過就忘”，在難例上重複走彎路。

◦我們的思考：倉庫級修復常呈現模式可遷移的特性。同類問題在補丁類別、修改策略、測試構造上具有相似性；將成功經驗結構化並遷移到相似樣例，可顯著縮短探索路徑。

◦我們的優化：基於軌跡壓縮與相似案例CSR檢索，將“策略摘要”引入下一輪重試的提示，使得“重試不是從零開始”，而是“從經驗啓航”。

◦相比同類方法的優勢：與單純的多樣化採樣不同， “經驗遷移重試”機制具備方向性與可解釋性，對於難例的收斂更友好。

4.針對“Token 消耗爆炸”的問題

◦現狀：多次獨立運行取並集、無效重試過多、無差別增加候選，都會導致 token 使用量激增，成本與時延不可控。

◦我們的思考：降低 token 的關鍵在於“有針對性的重試”與“早期篩除無效路徑”。通過歸因與協同測試，把無效路徑擋在前面；通過經驗遷移與單測篩選，提高單位 token 的有效性。

◦我們的優化：將“測試協同 + 失敗歸因 + 經驗遷移 + 投票仲裁”納入一個整體策略棧。投票只在必要時對候選進行“最後一跳”的穩健選擇，而不是以“海量並行採樣”替代系統性改進。

◦相比同類方法的優勢：相比“海投 + 海選”的簡單並行，我們強調“質量優先的候選構造 + 適度投票兜底”，以更低 token 成本實現更高的成功率及穩定性。

◦以下是JoyCode Agent調用LLM的次數分類及佔比：

5. 針對“多輪代理誤差累積與候選選擇”的問題

◦現狀：長鏈路代理容易誤差滾雪球；純投票可能只是在錯誤分佈內做“次優”。

◦我們的思考：需要在“多輪生成”的同時，構建強力的檢錯與糾偏機制，並明確投票的定位——用於最終仲裁，而非彌補缺乏驗證與歸因的欠賬。

◦我們的優化：通過隔離環境的一致性驗證、失敗來源的精細化歸因、經驗遷移驅動的重試，將“誤差累積”分段打斷；在候選集構造已具備質量保證的前提下，再用投票進行穩健仲裁。

◦相比同類方法的優勢：我們把投票放在“驗證-歸因-重試”之後，作為“穩定器”而非“主力軍”，使得候選質量更高、仲裁更有效，減少無謂的資源消耗。

總的來説，我們針對業界在“倉庫級自動修復”的關鍵短板進行了系統級工程優化：把補丁生成、單測生成與驗證、失敗歸因與經驗重試整合為一個可復現、可擴展、可觀測的閉環流水線。這些優化直接服務於 SWE-bench Verified 的打榜目標，既提升 Pass\@1 的穩健性，也為後續的策略演進提供了堅實的工程基礎。

三、整體系統結構



3.1 系統簡介

本系統實現了“補丁–單測協同生成與迭代驗證”端到端pipeline，關鍵設計如下：

1.單測協同生成

▪通過數據集中的 Issue，分析相應代碼倉中的問題來源，生成 Fail2Pass 和 Pass2Pass 單測樣本，並在原始代碼上進行預執行校驗，確保 Fail2Pass 單測在未修復前應當失敗，Pass2Pass 單測在未修復前應當成功，從而約束 Patch 生成方向。

2.首輪 Patch 生成與容器化驗證

▪在 Docker 隔離環境中按實例啓動 SWE-bench 對應鏡像，初始化工作區與 Git 基線，通過 Patch-Agent 和 Issue 驅動生成 Patch。

▪開啓驗證後，立即在容器內以 Pytest 執行生成的 Fail2Pass 和 Pass2Pass 單測，得到評測的結果作為首輪 Patch 的通過情況，指導後續的流程。

3.軌跡壓縮 + 相似案例檢索

▪從首輪存儲的信息中讀取軌跡信息和 Patch 信息，使用 LLM 將執行軌跡壓縮為“策略/關鍵變更/要點”的結構化摘要，沉澱到軌跡池中。

▪基於壓縮摘要對失敗的 Case 進行 CSR 檢索，即從成功案例庫中檢索最相似的實例，返回相似度分數、遷移理由與軌跡摘要，作為第二輪 Patch 生成的先驗知識。

4.二輪重試

▪將首輪“補丁為空或單測未通過”的實例彙總為重試候選；為命中高質量相似案例的實例注入先驗知識（策略 + 關鍵變更 + 相似度/理由） ，在 Retry Agent 配置下併發重試生成新補丁。

▪無相似案例時採用“無經驗”重試路徑，仍以併發方式生成候選補丁，最大化召回。

▪將一輪、二輪生成的 Patch 通過 Decision Agent 決策出最優結果，得到最終用於提交官方的 Patch。

綜上，當前實現以“Fail2Pass與Pass2Pass的單測約束 → 首輪補丁生成與容器驗證 → 軌跡壓縮與 CRS 檢索 → 二輪重試”的閉環，形成了高質量的 Patch 池與可復現的工程 Pipeline。

3.2 交互策略與系統流程

該 Multi-Agent 系統通過一套自動化的流程，將自然語言描述的軟件問題（Issue）與代碼倉庫作為輸入，最終為每個問題實例生成一個可復現、可驗證且具備明確決策依據的最優代碼補丁（Patch）。此流程由四個核心智能體協同執行：Testing Agent 負責構建測試驗證套件，Patch Agent 負責實現修復，CSR Agent 在特定失敗場景中提供經驗檢索，Decision Agent 則對重試前後的兩個候選補丁進行最終的仲裁。

第一步，系統調用 Testing Agent 將問題描述轉化為可執行的測試基準。在實現層面，Testing Agent 可以通過 Bash 工具完成依賴安裝、環境檢測、測試文件的創建與寫入等，並最終生成包含兩個 PASS TO PASS 和一個 FAIL TO PASS 的測試矩陣。生成後會立即進行預驗證，以確保生成的測試用例滿足“一敗兩通”的結構規範。

第二步，系統調用 Patch Agent 生成初步修復補丁（Patch）。Patch Agent 採用以“規劃—實現—修訂”為主線的工程化策略，藉助一系列工具進行代碼理解、錯誤復現與定位，並對目標代碼進行精確修改等。最終，此階段產出一個可運行的有效補丁，但是，生成的補丁也可能為空，或是未能通過第一步生成的測試套件。

第三步，系統根據前兩步的結果進入分支處理，通過不同策略保證流程收斂：

▪測試用例生成失敗（為空），但補丁成功生成：由於缺乏有效的測試驗證基準，系統將啓動基礎重試（Base Retry），在相同的輸入條件下再次調用 Patch Agent 生成一個新的 Patch，隨後， Decision Agent 在兩個候選補丁間進行決斷，選出最優方案。

▪初次補丁生成失敗（為空）：系統同樣進行基礎重試以生成一個新 Patch，並將其直接採納為當前實例的最優解。

▪測試用例合規生成（滿足“一敗兩通”），且初次補丁成功通過驗證：流程在此收斂，初次生成的 Patch 被直接確認為最優補丁。

▪測試用例成功生成（不為空），但初次補丁未通過驗證：系統啓動失敗歸因流程：

▪歸因於測試用例（Test）：判定標準為測試用例本身不合規或未能準確反映 issue 意圖，之後，系統將觸發基礎重試，生成一個新補丁後進行投票決策。

▪歸因於補丁（Patch）：判定標準為補丁自身的邏輯錯誤、實現缺陷或考慮不周等情況，之後，系統則會激活經驗重試。首先將所有實例第一次生成 Patch 的軌跡信息（如工具調用策略等）進行壓縮，並納入軌跡池，然後調用 CSR Agent，以當前失敗實例的 issue 為檢索條件，從歷史成功案例庫中檢索出語義最相似的成功實例所對應的的壓縮軌跡，再將“失敗壓縮軌跡”與最相似的“成功壓縮軌跡”一併提供給 Patch Agent，要求其對比分析與糾偏學習，生成一個優化後的新補丁，最終由 Decision Agent 在初次補丁與優化補丁之間完成投票仲裁。

在整個 workflow 中，Decision Agent 扮演着統一的“仲裁者”角色：當面臨多個候選補丁時，它會基於對問題描述與變更意圖的深刻理解，從邏輯正確性、與 issue 的一致性、修改的最小性與風險控制、代碼質量與可維護性以及邊界條件覆蓋等維度進行綜合評估，形成明確且可追溯的投票結論。

綜上，該系統通過“建立標準（Testing Agent）→ 實施修復（Patch Agent）→ 決策重試（CSR Agent）→ 最終仲裁（Decision Agent） ”的Agent交互設計，確保每個問題實例都能收斂至一個最優補丁。最終彙集而成的結果集，因其具備明確的測試基準、可復現的實驗路徑與透明的決策依據，可直接用於後續的官方評測與對比分析。

四、Agent 結構設計

4.1 Patch Agent

1. 功能介紹

Patch Agent 是基於響應式代理（React Agent）架構構建的核心智能體。它模擬人類開發者的工作模式，在一個持續的“觀察-思考-行動”閉環中運行，根據任務的實時進展和反饋，動態地調整其策略。



◦觀察（Observe）：從問題到洞察

▪任務解析：工作流始於一個 GitHub Issue。Agent 利用大模型的語言能力，從自然語言描述、錯誤日誌和用户反饋中提煉出問題的核心。

▪代碼勘探：隨後，它會深入代碼庫，借用 Bash 工具，通過 ls、grep、find 等終端命令實現代碼搜索、閲讀，甚至直接運行代碼以復現錯誤等方式，主動勘探和定位問題相關的代碼區域。

◦思考（Think）：從洞察到策略

▪思維鏈：這是 Agent 的決策中樞，它構建一個適應性極強的行動計劃（即思維鏈）。例如：“首先，為 file.py 中的 calculate\_total 函數添加 discount 參數；然後，更新所有調用點；最後，運行單元測試驗證。”

▪動態規劃：這個計劃並非一成不變。Agent 採用“ 邊想邊做 ”的模式，可以在思考過程中穿插執行代碼編輯或 Bash 命令來獲取更多信息，並根據結果即時調整後續策略。

◦行動（Action）：從策略到解決問題

▪執行與驗證：在行動階段，Agent 調用其工具箱將策略付諸實踐。它使用 Bash 工具來配置環境（如安裝依賴、運行構建腳本），並調用代碼編輯工具來精確地實現代碼的增、刪、改。

▪迭代循環：每一步操作後都伴隨着即時驗證 。Agent 會立刻運行Codebase中原生測試套件來檢驗修改的正確性。如果驗證失敗，這並不會中止流程，而是被視為新的觀察輸入。Agent 會帶着失敗的日誌信息，自動回到“觀察”階段，重新分析、思考並再次行動，形成一個高效、自主的迭代修復循環。

當 Patch Agent 成功完成所有修改並通過必要的驗證後，它會將所有變更整合成一個標準的代碼補丁（Patch）文件。這個補丁文件清晰地記錄了所有的代碼改動，可以直接被合併到主代碼庫中。

2. 工具設計

Patch Agent 的功能由一個模塊化的工具集實現，每個工具都在“觀察-思考-行動”循環中承擔特定職責。

◦代碼編輯工具

▪功能：提供對文件內容進行精確修改的接口，支持基於上下文的原子化操作，如插入、替換和刪除指定的代碼塊。

▪用途：用於執行由推理過程確定的源代碼修改。其精確性確保了變更的最小化，從而生成清晰、易於審查的代碼補丁。

◦Bash 工具

▪功能：提供一個在項目工作空間內執行標準 Shell 命令的環境。

▪用途：主要用於信息獲取（通過 grep , ls 等進行靜態分析）、環境準備（通過 pip 等安裝依賴）和動態驗證（通過運行 pytest 等測試套件獲取執行反饋）。

◦思維鏈工具

▪功能：一個結構化的內部推理組件，用於將高層任務目標分解為具體的行動序列。

▪用途：負責制定行動計劃、根據工具執行的實時反饋進行動態調整，並協調其他工具的調用與參數傳遞。

3. 輸入輸出定義

◦輸入信息如下：

▪Issue

▪定義：對軟件問題的詳細文字描述，其內容通常等同於一個 GitHub Issue 或 Pull Request。它包含了復現問題、理解背景和明確目標所需的所有信息，如錯誤報告、功能需求、堆棧跟蹤等。

▪用途：這是 Agent 進行任務解析和構建初始計劃的原始信息源。Agent 通過自然語言理解的能力從該描述中提煉出具體的工程目標。

▪Location

▪定義：一個指向待修改代碼倉庫根目錄的路徑。 此路徑通常指向一個隔離的、容器化的文件系統環境。

▪用途：為 Agent 提供一個安全、封閉的工作沙箱。Agent 的所有操作，包括文件讀寫、編譯、測試等，都將在此目錄內進行，確保了操作的隔離性與環境的一致性。

◦輸出信息如下：

▪Patch

▪定義：一個遵循標準 diff 格式的字符串。 該補丁精確記錄了 Agent 為解決 Issue 中描述的問題而對 Location 內的代碼所做的全部修改。

▪用途：這是 Agent 工作流程的最終交付成果。此補丁可直接被版本控制系統（如 Git）應用，提交至代碼審查平台，無縫融入現有的開發工作流中。

4. 應用場景

Patch Agent 的核心價值在於其能夠根據任務的複雜度和初始嘗試的結果，動態調整其解決策略。其應用場景主要分為以下三種模式：

▪首次Patch生成： Patch Agent 的標準工作流程始於首次patch生成 。接收任務後，Agent 會啓動其“觀察-思考-行動”循環，通過任務解析、代碼修改與測試驗證，迭代生成一個能通過預設驗證的初始補丁，或在達到嘗試上限後暫停。

▪基礎重試： 若首次生成失敗，或者因測試用例問題（測試用例生成失敗、測試用例錯誤等）則會觸發基礎重試，此模式下，會再一次通過標準的 Patch Agent 工作流程執行補丁的重新生成，之後通過決策機制選擇出兩次中最優的補丁。

▪經驗驅動重試： 若因 Patch 的問題導致沒有通過 Testing Agent 生成的測試用例，則會進入經驗驅動重試階段，該模式會為 Agent 注入兩種關鍵經驗，包括自身失敗的完整軌跡，以及通過 CSR Agent 檢索出的最相似問題的成功軌跡。 Agent 會對這兩種經驗進行辯證分析，從失敗中吸取教訓，從成功中借鑑策略，形成一個全新的、更具魯棒性的行動計劃。

4.2 Testing Agent

1.功能介紹

Testing Agent 旨在為評估代碼補丁（Patch）自動生成有針對性的測試用例，它藉助大語言模型，能夠深入理解錯誤報告（Issue）和代碼庫，並自動生成一套精準的測試用例，從而對每一個代碼補丁進行全面、可靠的評估。



Testing Agent 會創建三種不同目的的測試用例，共同構成一個完整的驗證矩陣：

▪錯誤復現測試（FAIL TO PASS）：

▪運行邏輯：此測試源於代碼倉中的原始 Bug，在原始的、有缺陷的代碼上要求失敗 ，但在應用補丁修復後的代碼上要求通過。

▪核心價值：這是驗證補丁有效性的“黃金標準”，它直接證明了補丁確實解決了要修復的特定問題。

▪迴歸保護測試（PASS TO PASS）：

▪要求：此測試在修復前後的代碼上都必須通過。

▪核心價值：保護現有功能不被破壞，確保補丁在修復 bug 的同時，沒有引入新的問題。

▪邊緣檢測測試（PASS TO PASS）：

▪要求：此測試同樣在修復前後的代碼上都必須通過。

▪作用：專注於檢驗與 Bug 相關的邊界條件和特殊輸入。這確保了修復方案是健壯的，不僅能處理已知的失敗場景，在各種極端的使用情況下也能保持穩定，不會產生意外的副作用。

生成的測試用例不會立即用於評估補丁，而是必須先通過一個“預驗證”關卡。在這個階段，所有三個測試用例都會在原始的、有缺陷的代碼上運行。只有當測試結果完全符合預期：FAIL TO PASS 失敗，另外兩個 PASS TO PASS 通過，這套測試用例才被確認為有效且校準精確。

在成功生成並校準測試用例後，系統將立即調用 Patch Agent 進入代碼修復階段，生成一個候選Patch。該 Patch 會立刻接受此前生成的測試用例的嚴格檢驗：如果能順利通過所有測試，它將被初步標記為成功；反之，無論是最初未能生成合規的測試用例，還是後續生成的Patch未能通過測試，系統都將啓動相應的重試策略，針對性地迭代優化，嘗試解決問題。

2. 工具調用

在 Testing Agent 的整個自動化流程中，通過 Bash 工具將大模型生成的抽象指令（如創建一個測試文件、運行測試等）轉化為操作系統能夠理解和執行的具體命令，可以説，Testing Agent 的所有計劃和調度最終都由 Bash 工具付諸實踐。其核心用途主要體現在以下三個方面：

◦文件操作：創建與寫入測試用例

▪核心價值：大模型並不會手動輸入代碼，而是通過執行 Bash 工具來精確地把構思好的測試代碼，準確無誤地生成為實體文件，存放於工作區中。

▪實現方式：通過調用 mkdir 命令確保生成存放測試文件的目錄，利用 cat 組合指令，將包含複雜縮進和特殊字符的多行測試代碼原封不動地寫入到指定的 .py 文件中，為後續的測試執行做好準備。

◦環境管理：安裝與檢查依賴

▪核心價值：執行測試之前，自動確保 pytest 等所有必需的依賴庫都已安裝就緒，保證測試環境的一致性和可靠性。

▪實現方式：採用條件邏輯，只有檢查環境的命令失敗（意味着依賴缺失）時，才會觸發 pip install 進行安裝，這種智能化的檢查機制避免了盲目安裝以及不必要的重複操作。

◦測試執行：運行並反饋結果

▪核心價值：自動執行生成的測試用例，並捕獲測試結果，為 Agent 的後續決策提供依據。

▪實現方式：Bash 工具直接調用 pytest 命令來運行測試，執行完成會自動捕獲執行完畢後的退出碼（Exit Code），在該流程中，退出碼為 0 被視為成功，否則為失敗。

3. 設計目的

SWE-bench 旨在衡量一個 Agent 是否能像一名真正的軟件工程師那樣，完成理解、分析並最終解決一個複雜軟件問題的完整鏈路，Testing Agent 的設計正是這一理念的直接體現，是為了響應 SWE-bench 評測對 Agent 綜合問題解決能力的考驗，而不僅僅是為了評估其最終產出的 Patch。

1）將問題理解轉化為可執行的規範： 面對一個 issue ，一個初級的方法是直接嘗試生成代碼補丁，但一個高級且更符合工程實踐的思路是首先深刻理解問題到底是什麼以及修復的標準是什麼。Testing Agent 構成的測試套件，就是 Agent 對“修復成功”這個目標的精確定義，它清晰地展示了 Agent 對問題分析與拆解能力。

2）為高級 Agent 策略奠定基礎： 生成的測試套件並非一次性工具，而是整個修復流程中可被反覆利用的核心。當 Patch Agent 首次生成的補丁未能通過測試用例時，可以直接嘗試判斷失敗的原因（測試用例問題 / Patch問題），然後針對性選擇不同的重試機制（基礎重試 / 經驗重試），最後進行投票，決策出最優的 Patch。

4. 輸入輸出定義：

◦輸入信息——與 Patch Agent 的輸入信息一致：

▪Issue：詳細描述軟件問題的文本

▪Location：指向對應代碼倉庫的路徑

◦輸出信息——三個獨立的測試代碼文件：

▪Test Failure Scenario (錯誤復現測試)

▪Test Happy Path (迴歸保護測試)

▪Test Edge Case (邊緣檢測測試)

這是 Testing Agent 的核心產物，該測試套件首先用於“預驗證”，確保其自身邏輯的準確性，通過後，它將作為評估後續代碼補丁的“黃金標準”，從有效性、安全性和健壯性三個維度對補丁進行自動化、全方位的質量檢驗。

4.3 CSR Agent

1.功能介紹

該 Agent 是系統在測試用例成功生成，但代碼補丁未能通過測試用例的情況下所激活的一套高級錯誤診斷與自我優化的調度 Agent。它通過軌跡壓縮、根因決策、CSR 相似度檢索和經驗重試，將第一次失敗的原因和過往相似的成功經驗作為第二次重試的先驗知識，旨在通過借鑑多維歷史經驗來指導並優化新Patch的生成。



1）軌跡壓縮

在 Patch Agent 的第一次工作流程結束後，無論成功與否，其完整的執行軌跡都將被捕獲和處理。

▪軌跡定義：一次完整的執行軌跡包含了 Patch Agent 從接收任務到生成最終Patch的全過程記錄，主要包括其內部的思考鏈、每一輪的工具調用（如代碼搜索、文件讀寫等）。

▪壓縮目的：為了高效存儲和檢索，原始的冗長的軌跡會被壓縮為一個結構化、信息密集的摘要。這個摘要保留了解決問題的核心邏輯和關鍵步驟，去除了冗長信息。

▪軌跡池：所有壓縮後的軌跡都會被存入一個統一的“軌跡池”中，這個池子構成了系統的知識庫，為後續的經驗檢索和學習提供了數據基礎。

2）根因決策

當一個由 Patch Agent 生成的補丁未能通過 Testing Agent 所生成的測試組合時，系統並不會直接判定補丁無效，而是啓動根因決策模塊進行失敗歸因。具體的決策邏輯為，大模型作為診斷引擎，分析並判斷導致測試失敗的根本原因。綜合分析原始的問題描述、Testing Agent 生成的測試用例、失敗的代碼補丁（Patch）、測試結果這四個維度的信息，進行歸因：

▪歸因於測試用例：如果模型判斷 Patch 驗證失敗是由於測試用例本身存在缺陷（例如生成的測試用例未能準確反映 issue 的真實意圖），系統將觸發基礎重試流程。

▪歸因於代碼補丁：如果模型判斷測試用例是準確的，而失敗源於補丁自身的邏輯錯誤、實現缺陷或考慮不周等情況，系統將觸發經驗重試流程。

3）CSR 相似度檢索

在根因決策將失敗歸因於代碼補丁（Patch）後，CSR 相似度檢索機制會被激活，為經驗重試尋找可借鑑的“良師”。

▪檢索目標：以當前失敗實例的問題描述（issue）作為查詢條件，進行CSR相似度檢索，檢索到與當前失敗實例問題最相似的一個成功實例。

▪檢索範圍：歷史上所有成功解決（即其生成的補丁通過了對應的生成的測試用例）的實例軌跡。

▪檢索結果：成功實例對應的壓縮軌跡，即“成功範式”。

4）經驗重試

Patch Agent 在此階段會接受到其自身上次生成失敗 Patch 的壓縮軌跡以及通過 CSR 檢索到的解決相似問題的成功軌跡。然後進行一次有指導的、基於反思的學習與再生成。

▪揚長：分析並借鑑成功軌跡中的優點，理解其解決問題的思路、關鍵代碼實現和工具調用策略。

▪避短：反思並規劃自己失敗軌跡中的缺陷，找出導致錯誤的關鍵節點。

在完成上述分析後，Patch Agent 生成一個經過深度優化的新補丁，最後與原始的失敗補丁一起被提交給 Decision Agent 進行最終投票，以確保選出最優的補丁方案。

2. 輸入輸出信息

◦軌跡壓縮：

▪輸入信息——Raw Trajectory：第一次 Patch Agent 執行過程的完整、原始日誌。其中包含了 Agent 的思維鏈、工具調用詳情等信息。

▪輸出信息——Compressed Trajectory：一個結構化的、信息密集的摘要，提煉了 raw trajectory 中的核心邏輯和關鍵步驟。

◦根因決策：

▪輸入信息：

▪Issue：原始的問題描述

▪Test Cases：用於驗證的代碼測試用例

▪Patch A：第一次生成的未能通過測試的代碼補丁

▪Test Results：測試驗證結果

▪輸出信息：

▪Failure\_Cause：一個明確標識失敗根源的分類標籤，其值為 “PATCH”（歸因於補丁） 或 “TEST”（歸因於測試用例）

◦CSR 相似度檢索

▪輸入信息：

▪Issue：當前失敗案例的問題描述。

▪Trajectory Pool：一個包含所有歷史上成功解決問題的壓縮軌跡的集合。

▪輸出信息：

▪Original Trajectory：當前失敗實例所對應的生成 Patch 的壓縮軌跡。

▪Similar Trajectory：與當前失敗實例語義最相似的成功實例所對應的生成 Patch 的壓縮軌跡。

◦經驗重試

▪輸入信息：

▪Issue：原始的問題描述。

▪Location：代碼倉庫的根目錄路徑。

▪Original Trajectory：第一次生成的失敗補丁的壓縮軌跡。

▪Similar Trajectory：通過 CSR Agent 檢索到的最相似的成功軌跡。

▪輸出信息：

▪Patch：經過辯證分析與經驗學習後重試生成的新補丁。

4.4 Decision Agent

1.功能介紹

Decision Agent 在整個工作流中扮演着關鍵的“仲裁者”角色，其核心職責是在系統通過重試機制產生兩個候選補丁（Patch）時，通過比較投票，從中選擇最優的解決方案。Decision Agent 的功能主要圍繞以下兩種核心重試場景展開：

◦基礎重試（Base Retry）場景：在這種場景下，問題出在測試用例生成階段，導致 Patch Agent 的工作缺乏有效驗證。

▪觸發條件：

▪Testing Agent 達到交互輪次限制，未能生成任何測試用例。

▪Testing Agent 生成的測試用例不符合規範，例如不滿足 1 個 FAIL TO PASS，2 個 PASS TO PASS 的要求，或經大模型判定失敗根源是測試用例未能準確表達問題意圖，而非補丁本身存在缺陷。

▪執行流程：

▪由於缺乏有效的測試基準，Patch Agent 的初次生成結果 Patch A 即便已完成也無法被驗證。因此，系統啓動基礎重試，在完全相同的輸入條件下，重新執行一次 Patch Agent，產生一個全新的 Patch B。

▪此時，Decision Agent 會基於其對原始問題的理解，從代碼質量、邏輯清晰度、實現思路等方面綜合分析並比較這兩個補丁，最終票選出它認為更有可能解決問題的最優版本。

◦經驗重試（Experience Retry）：在這種場景下，測試用例本身是合格的，但 Patch Agent 的初次實現未能通過測試，暴露出邏輯缺陷。

▪觸發條件：

▪Testing Agent 成功生成了合規且有效的測試用例。

▪Patch Agent 初次生成的補丁在執行這些測試用例時失敗。

▪執行流程：

▪首先，調用 CSR Agent，它會在知識庫中檢索與當前問題最相似且已經成功通過生成的測試套件的歷史案例。

▪對應着提取出其 Patch Agent 生成 Patch 的壓縮軌跡（即關鍵的思考鏈與代碼實現步驟）。

▪將獲取到的經驗信息與上次失敗（未能通過生成的測試套件）的 Patch 的壓縮軌跡傳遞給 Patch Agent 進行經驗重試。

▪Patch Agent 被要求進行“辯證學習”：一方面反思並規避自己生成失敗補丁中的缺陷；另一方面分析並借鑑成功軌跡中的優點，從而生成一個經過深度優化的新補丁。

▪Decision Agent 最終投票決定哪個補丁是最優的解決方案。

Decision Agent 通過對不同策略生成的候選方案進行嚴謹的比較與投票，確保了系統在面對挑戰時，能夠通過自我反思和外部經驗學習，不斷迭代出更優質的解決方案。

2. 輸入輸出定義

◦輸入信息：

▪issue（String）：詳細描述軟件問題的文本

▪Patch A（String）：第一次調用 Patch Agent 生成的補丁

▪Patch B （String）：重試調用 Patch Agent 生成的補丁

◦輸出信息：

▪solution\_index (String)：被選中的補丁對應的索引

▪basis\_of\_reasoning (String)：一段對選擇該方案的推理和理由的簡明摘要，旨在體現一個嚴謹的投票分析過程

五、典型流程示例

如下圖，我們以 django-16454 實例為例詳細闡述一個完整的工作流程，整個過程通過四個核心階段，完成了真實代碼倉庫級問題的理解與解決。

◦第一階段：自動化生成測試用例

▪環境初始化：流程啓動後，首先從數據集中獲取指定實例（ django-16454 ）的詳細問題描述。隨即，系統在一個隔離的 Docker 容器中準備代碼倉庫，並自動檢測和安裝所有必需的測試依賴包，確保了一個純淨且一致的執行環境。

▪測試策略規劃：基於問題描述，系統會深入分析代碼，定位潛在的錯誤根源，並檢索項目中是否已存在相關的測試代碼。此步驟旨在為後續生成結構化的測試用例提供充分的上下文信息。

▪測試用例生成與預驗證：接下來，系統調用大語言模型，根據分析結果成功生成了 3 個測試用例：錯誤復現測試、迴歸測試、邊緣場景測試。之後執行預驗證程序，該實例生成的測試用例符合兩個 PASS TO PASS，一個 FAIL TO PASS 的結構要求，成功通過了預驗證程序。

◦第二階段：代碼補丁生成與驗證

▪代碼勘察與錯誤重現 ：系統利用 Bash 工具深入代碼庫，理解其整體架構，並再次確認錯誤的具體表現，為制定修復策略提供依據。

▪通過深度分析，系統會藉助 Sequential Thinking 等工具規劃出具體的修復方案。一旦方案確立，系統將利用 String Replace 工具精確地修改相關代碼，生成一個初始的代碼補丁（Patch）。

▪測試驗證：該步驟使用第一階段生成的測試用例來檢驗該補丁的有效性。在此 django-16454 實例中，測試驗證宣告失敗：該補丁不僅未能解決核心問題，反而還導致了迴歸測試失敗。

◦第三階段：重試策略選擇與執行

▪軌跡壓縮：首先會利用大模型對所有實例的 Patch 初次生成的軌跡進行壓縮，構建軌跡池作為後續流程的前置條件，區分哪些實例是可參考的成功的案例，哪些是失敗的案例。

▪失敗歸因：分析失敗是因為測試用例的設計不當還是代碼補丁本身存在缺陷。在此案例中，系統判定第一階段生成的測試用例是準確的，但是生成的代碼補丁未能有效解決問題。

▪相似案例檢索：由於確定是補丁的問題，系統會啓動 CSR 檢索機制，尋找一個與當前失敗案例高度相似，並且已經成功的補丁，並且獲取到其生成補丁的過程對應的壓縮軌跡。

▪經驗重試：系統將檢索到的成功案例的解決策略與上次失敗的經驗進行整合，構建出一個信息更豐富、指導性更強的新提示，然後進行經驗重試，再次嘗試生成一個新的代碼補丁。

◦第四階段：投票決策最優補丁

▪系統對兩次生成的補丁進行評估和投票，在此案例中，第二次重試後的補丁被認為質量更優，因此被選定為最終的解決方案。





結束語

本次技術報告系統梳理了JoyCode Agent在自動化軟件修復領域的核心架構、創新算法及工程優化路徑。從倉庫級別的深層代碼理解，到“補丁–單測協同生成與迭代驗證”閉環，再到多智能體協作、高效經驗遷移與精細化失敗歸因 ， JoyCode Agent在SWE-bench Verified全球測評中實現了高通過率與顯著的資源節約，充分展現了JoyCode團隊對AI軟件工程的深度思考與技術積累。

展望未來，我們將持續迭代JoyCode Agent的能力邊界，不斷優化多Agent協同、經驗複用機制和倉庫級修復方案，推動自動化修復的智能化與工程化落地。下階段，我們將進一步開源核心技術（目前正在走外部開源代碼審批流程），深化與社區開發者的交流合作，拓展更多真實場景下的應用實踐，助力企業和開發者以更低成本、更高質量應對複雜編碼挑戰。此外，我們還將陸續發佈相關專利，持續提升技術創新能力，為行業發展注入更多動力。

當前時代，技術變革正在重塑軟件開發的每一個環節，選擇JoyCode，意味着選擇一個能夠與用户共同成長、不斷進化的智能工具。我們始終堅持以用户需求為導向，致力於打造高效、可靠的AI編程引擎，與廣大開發者攜手邁向智能編程時代的新高峯。

開源鏈接，歡迎收藏支持！

https://github.com/jd-opensource/joycode-agent

https://gitee.com/JD-opensource/joycode-agent