解決真實(shí)GitHub Issue的基準(zhǔn)測試，字節(jié)家的豆包MarsCode Agent悄悄登頂了。

SWE-Bench，一個由普林斯頓大學(xué)提出的極具挑戰(zhàn)性的Benchmark，近期受到工業(yè)界、學(xué)術(shù)界和創(chuàng)業(yè)團(tuán)隊的廣泛關(guān)注。

在其子集SWE-Bench Lite排行榜上，豆包MarsCode Agent近期沖上第一。

雖然這是面向所有大模型解決方案的評測，但現(xiàn)在排名靠前的部分已基本被AI Agent占領(lǐng)。

AI Agent即能夠感知外部環(huán)境、操作工具并具有一定自主決策能力的智能體，受到了越來越多的研究關(guān)注。

現(xiàn)在，豆包MarsCode Agent團(tuán)隊分享了在軟件工程領(lǐng)域進(jìn)行了一系列關(guān)于AI Agent應(yīng)用的探索和嘗試：

通過構(gòu)建Agent框架并為其提供代碼檢索、調(diào)試和編輯的交互接口和工具，使得Agent有可能接管部分軟件工程開發(fā)任務(wù)。

• 在Agent框架方面，豆包MarsCode開發(fā)了多Agent協(xié)作框架，根據(jù)所要解決軟工問題類型，分配靜態(tài)或動態(tài)求解管道，從而靈活適配多樣的軟件工程問題；
• 在代碼檢索能力方面，豆包MarsCode結(jié)合代碼知識圖譜和語言服務(wù)，為Agent提供全面的代碼實(shí)體召回、關(guān)系召回、定義與引用跳轉(zhuǎn)等能力，從而使Agent具備人類開發(fā)者類似的代碼瀏覽、分析過程；
• 在代碼編輯方面，豆包MarsCode采用Conflict形式的代碼編輯描述和靜態(tài)語法檢查，能夠準(zhǔn)確生成格式正確的代碼編輯補(bǔ)??；
• 在軟件動態(tài)調(diào)試方面，豆包MarsCode基于Docker的容器化沙箱環(huán)境，讓Agent具備了人類開發(fā)者的調(diào)試能力，比如缺陷復(fù)現(xiàn)、添加日志和運(yùn)行測試框架等。

01多Agent協(xié)作框架

開發(fā)者在日常的開發(fā)工作中常常會遇到各種問題，例如：

• 運(yùn)行測試用例報錯，有錯誤或異常堆棧等，這可能是由于代碼邏輯錯誤或測試斷言失敗導(dǎo)致的問題；
• 代碼輸出結(jié)果不符合預(yù)期，沒有顯式的報錯信息，但有明確的輸出結(jié)果預(yù)期；
• 需要對現(xiàn)有功能進(jìn)行擴(kuò)展或增加新功能，有明確的開發(fā)需求及預(yù)期結(jié)果，但不知道如何實(shí)現(xiàn)和在哪實(shí)現(xiàn)；
• 需要進(jìn)行簡單的缺陷修復(fù)，有大致的修復(fù)思路，但不熟悉語言特性需要協(xié)助。

上述多樣化的程序修復(fù)和開發(fā)任務(wù)通常無法用一種固定的模式來進(jìn)行處理。

例如，一些簡單的缺陷修復(fù)或功能擴(kuò)展僅需對代碼進(jìn)行review即可完成；而較深的異常堆?；驈?fù)雜的邏輯錯誤僅憑閱讀代碼往往很難發(fā)現(xiàn)問題所在，需要通過動態(tài)執(zhí)行代碼并追蹤相關(guān)變量才能暴露出相關(guān)缺陷，從而對其進(jìn)行修復(fù)。

因此，團(tuán)隊采用了多Agent協(xié)作的框架來適應(yīng)不同的開發(fā)場景。如下圖所示，多Agent協(xié)作框架中包含以下7類角色：

• Searcher：利用CKG、LSP等代碼檢索工具收集與當(dāng)前問題相關(guān)的repo內(nèi)代碼片段；
• Manager：根據(jù)收集到的相關(guān)代碼片段對問題進(jìn)行定性和分流，將問題場景分為動態(tài)調(diào)試修復(fù)和靜態(tài)修復(fù)兩類；
• Reproducer：在動態(tài)調(diào)試修復(fù)場景下，根據(jù)相關(guān)代碼和問題描述編寫復(fù)現(xiàn)腳本，并在沙箱中對腳本進(jìn)行動態(tài)調(diào)試以確認(rèn)復(fù)現(xiàn)成功；
• Programmer：根據(jù)問題描述和相關(guān)代碼進(jìn)行編輯代碼，并結(jié)合Tester的測試結(jié)果進(jìn)行多輪迭代修改；
• Tester：根據(jù)問題復(fù)現(xiàn)腳本，對當(dāng)前代碼版本進(jìn)行動態(tài)驗證，檢查問題是否得到解決；
• Planner：在靜態(tài)修復(fù)場景下，根據(jù)問題和相關(guān)代碼，制定求解計劃，規(guī)劃需要修改哪些代碼片段及其修改方式；
• SymbolEditor：根據(jù)修改計劃，對所負(fù)責(zé)的代碼Symbol進(jìn)行修改，返回修改補(bǔ)丁。

團(tuán)隊為不同的Agent配備了相應(yīng)的工具集以支撐其完成指定任務(wù)，各Agent配備的工具集如下表所示。

值得注意的是，團(tuán)隊并沒有令每個Agent都擁有所有工具的使用權(quán)，而是嘗試限制各個Agent的能力和職責(zé)范圍，從而降低單個Agent解決當(dāng)前環(huán)節(jié)問題的難度，以提高任務(wù)執(zhí)行的穩(wěn)定性和輸出結(jié)果的質(zhì)量。

在動態(tài)調(diào)試修復(fù)場景下，各Agent的協(xié)作求解流程如下：

• 由Reproducer根據(jù)描述對問題進(jìn)行復(fù)現(xiàn)，生成與問題描述相符的復(fù)現(xiàn)腳本；
• 將復(fù)現(xiàn)腳本提供給Tester進(jìn)行驗證，將復(fù)現(xiàn)腳本運(yùn)行得到的異常堆棧和其他輸出信息提供給Programmer進(jìn)行修復(fù)；
• Programmer完成修復(fù)后向Tester提出測試請求；
• Tester再基于復(fù)現(xiàn)腳本進(jìn)行驗證，并判斷問題是否解決：

• 若問題已解決，則通過diff工具獲取當(dāng)前代碼變更作為該問題的修復(fù)方案，動態(tài)調(diào)試結(jié)束；
• 若仍未解決，則再次將復(fù)現(xiàn)過程中異常堆棧和其他輸出信息返回給Programmer；

• Programmer可根據(jù)Tester的報錯信息，選擇繼續(xù)修改，或重置repo放棄過往編輯，重新進(jìn)行修改。直至提交測試給Tester驗證通過為止。

在動態(tài)過程中，團(tuán)隊通過在Docker容器中搭建一個運(yùn)行環(huán)境沙箱，以實(shí)現(xiàn)動態(tài)調(diào)試的問題復(fù)現(xiàn)和運(yùn)行驗證。

在靜態(tài)修復(fù)場景下，由于無法直接對問題進(jìn)行復(fù)現(xiàn)和動態(tài)驗證，需要制定針對該問題的靜態(tài)修復(fù)方案。過程如下：

• 由Planner根據(jù)檢索到的相關(guān)代碼片段，收集更多代碼上下文，制定修改方案，修改方案以代碼符號(Symbol)為單位組成，每條修改意見包含需要修改代碼所在的Symbol名（類、函數(shù)、Top-Level變量等）、修改處所在文件、該Symbol的代碼行號范圍、修改描述；
• 在生成修改方案的過程中，團(tuán)隊采用了一些軌跡采樣和搜索的策略，使生成的plan有較高的準(zhǔn)確性；
• 針對修改方案中的每一個Symbol，實(shí)例化出一個Symbol Editor，用于完成改Symbol的修改計劃，每個Symbol Editor完成后通過git commit提交修改；
• 完成所有Symbol的修改后，將當(dāng)前代碼狀態(tài)與Base commit進(jìn)行差異對照，生成最終補(bǔ)丁作為該問題的修復(fù)方案

02代碼檢索

團(tuán)隊為豆包MarsCode Agent提供了多種可跨語言適配的代碼檢索工具，以適應(yīng)各種軟件工程開發(fā)場景下的代碼檢索需求。

代碼知識圖譜（Code Knowledge Graph）

代碼知識圖譜是將代碼元素、屬性以及元素之間的關(guān)系表示為圖結(jié)構(gòu)，從而幫助Agent更好地理解和管理大規(guī)模的代碼庫。

在這種圖結(jié)構(gòu)中，頂點(diǎn)代表代碼的實(shí)體（如函數(shù)、變量、類等），邊則代表實(shí)體之間的關(guān)系（如函數(shù)調(diào)用、變量引用、類的繼承關(guān)系等）。通過這種方式，代碼知識圖譜可以為代碼庫提供更豐富且結(jié)構(gòu)化的信息。

團(tuán)隊通過程序分析的技術(shù)，將倉庫中的代碼，文檔信息進(jìn)行分析組織，生成一個以變量，函數(shù)，類，文件等代碼語義節(jié)點(diǎn)為實(shí)體，文件結(jié)構(gòu)關(guān)系、函數(shù)調(diào)用關(guān)系，符號索引關(guān)系為邊的多向圖。構(gòu)成一張融合了代碼，文檔，倉庫信息等多數(shù)據(jù)源的代碼知識圖譜。

在給定的代碼庫中，每個節(jié)點(diǎn)和邊都通過唯一標(biāo)識符進(jìn)行標(biāo)記，確保每個代碼實(shí)體在整個代碼庫中都是唯一的。

在這種設(shè)計中，代碼知識圖譜將使用圖屬性來存儲代碼實(shí)體及其依賴關(guān)系。每個節(jié)點(diǎn)記錄其在代碼庫中的位置、類型和名稱。每條邊標(biāo)識兩個節(jié)點(diǎn)之間的關(guān)系類型，以及關(guān)系在代碼中的位置。

比如對下面這樣一段代碼：

// file: main/fileA.go
package main


import (
    "ckg-prompt/main/cmd/pkg_b"
    "fmt"
)


// StructA struct
type StructA struct{}


// FunctionA method for StructA
func (a *StructA) FunctionA() pkg_b.StructB {
    x := pkg_b.NewStructB() // Instantiate StructB
    return x
}


// XFunction function
func XFunction() {
    x := pkg_b.NewStructB() // Instantiate StructB
    x.FunctionB() // Calls FunctionB
}

它的代碼知識圖譜如下圖所示：

△圖1代碼知識圖譜元素構(gòu)成

在構(gòu)建完成代碼知識圖譜后，Agent的代碼檢索請求將通過下圖中的管道進(jìn)行處理并實(shí)現(xiàn)召回。

• 將Agent的問題與代碼語句（如有），通過模型進(jìn)行實(shí)體識別，得到實(shí)體mention+類型，然后在知識圖譜中進(jìn)行SQL搜索查詢，查詢結(jié)果標(biāo)記為候選實(shí)體列表1；
• 將Agent的問題與代碼語句（如有），進(jìn)行embedding，在知識圖譜中進(jìn)行embedding相似度匹配，取相似度最高的一批實(shí)體，為候選實(shí)體列表2；
• 將Agent的問題直接通過關(guān)鍵詞識別構(gòu)造查詢語句，在知識圖譜中進(jìn)行SQL搜索查詢，查詢結(jié)果標(biāo)記為候選實(shí)體列表3。

最后將候選實(shí)體列表1 & 2 & 3進(jìn)行合并，通過精排模型，得到最終實(shí)體列表X，返回給Agent，完成代碼檢索。

△圖2代碼知識圖譜召回流程

在豆包MarsCode Agent中，代碼知識圖譜工具能夠?qū)崿F(xiàn)廣泛、全面的代碼檢索，為Agent提供了repo內(nèi)知識問答的能力。目前，代碼知識圖譜支持包含C、C#、CPP、Java、Kotlin、Javascript、Typescript、TSX、Rust、Golang、Python、Lua在內(nèi)的12種常用編程語言。

語言服務(wù)器協(xié)議（LanguageServerProtocol）

代碼知識圖譜能夠應(yīng)對大部分目標(biāo)工程下的類、函數(shù)定義與引用的檢索需求，但仍存在以下盲區(qū)：

• 代碼知識圖譜是對目標(biāo)工程進(jìn)行構(gòu)建，而目標(biāo)工程外（如標(biāo)準(zhǔn)庫、第三方庫等）的類、函數(shù)、變量的定義和引用是無法通過代碼知識圖譜被準(zhǔn)確召回的；
• 對于庫中存在多個重名實(shí)體的情況，LSP相比代碼知識圖譜能夠更準(zhǔn)確地跳轉(zhuǎn)到相關(guān)類或函數(shù)定義，避免召回和Rerank過程帶來的遺漏或冗余；

為解決上述問題，豆包MarsCode Agent利用通用的語言服務(wù)協(xié)議（Language Server Protocol）實(shí)現(xiàn)用戶機(jī)器上全局、精確的代碼召回。

語言服務(wù)器協(xié)議是一種由Microsoft開發(fā)的協(xié)議，廣泛適配包含編程語言、標(biāo)記語言、多種工具和框架在內(nèi)的語法體系，在IDE場景下具有很好的通用性。豆包MarsCode Agent調(diào)用語言服務(wù)器協(xié)議實(shí)現(xiàn)代碼召回的過程如下圖所示：

△圖3語言服務(wù)的召回流程

Agent調(diào)用語言服務(wù)器進(jìn)行代碼召回的過程與開發(fā)者在IDE中使用“Ctrl+左鍵”點(diǎn)擊某個標(biāo)識符進(jìn)行代碼跳轉(zhuǎn)的過程是一致的，但由于Agent的數(shù)字定位和計算能力較弱，團(tuán)隊增加了模糊定位功能以進(jìn)一步強(qiáng)化Agent使用LSP工具的能力：

• 根據(jù)Agent的提供的文件名和行號，在該行內(nèi)尋找標(biāo)識符并計算列號，構(gòu)成LSP請求；
• 根據(jù)Agent的提供的文件名和行號，在該行附近尋找標(biāo)識符并計算列號，構(gòu)成LSP請求；
• 根據(jù)Agent的提供的標(biāo)識符和行號，在Agent打開和瀏覽過的文件中尋找標(biāo)識符，并構(gòu)成LSP請求；

這三個服務(wù)的優(yōu)先級自上而下由高到低，使用第一個成功得到響應(yīng)的LSP請求結(jié)果作為工具的輸出。

其他通用檢索能力

除LSP和CKG外，團(tuán)隊將通用的項目內(nèi)文件檢索（find file）、項目或文件內(nèi)標(biāo)識符檢索（grep）等能力在豆包MarsCode Agent框架下進(jìn)行統(tǒng)一的封裝，從而為Agent提供調(diào)用風(fēng)格一致的代碼檢索工具庫。

03代碼編輯

代碼編輯描述

在團(tuán)隊對研發(fā)域AI Agent的長期探索過程中，嘗試了各種使用LLM進(jìn)行代碼編輯描述的方式，發(fā)現(xiàn)目前LLM的代碼修改能力普遍較弱。如下是團(tuán)隊曾經(jīng)探索（失?。┻^的代碼編輯方案：

• 要求Agent生成Unified diff格式的代碼變更描述；

Unified diff格式的變更是將原始文件和修改后文件以一種統(tǒng)一的方式展示出來，比如：

Unified diff的代碼編輯描述有著非常嚴(yán)格的格式要求，而且LLM很難正確計算變更的代碼行號增量，從而導(dǎo)致生成的Unified diff無法成功apply。

• 要求Agent提供代碼變更的起始行號、終止行號和替換的代碼片段；

團(tuán)隊在所有的代碼檢索的結(jié)果中都對代碼添加了行號，希望Agent能正確填寫修改范圍并完成修改，然而即便是GPT-4，也不能完全正確地提供需要修改的代碼范圍，時常會出現(xiàn)1～2行的偏移，從而導(dǎo)致修改后出現(xiàn)重復(fù)行或誤刪；

-對整個文件進(jìn)行重寫；

為LLM提供整個文件的內(nèi)容和修改描述，要求LLM輸出修改后的完整文件內(nèi)容。這種方式能夠避免LLM進(jìn)行行號的計算，但顯然每次代碼編輯都使用閉源模型生成整個文件是非常不經(jīng)濟(jì)的，且在一些長文件中幾乎不可用。團(tuán)隊也正在嘗試通過SFT獲取一個專門的代碼編輯模型實(shí)現(xiàn)全文重寫的能力，但這是一個長期計劃。

經(jīng)過大量的探索和嘗試，團(tuán)隊認(rèn)為LLM的代碼編輯描述需要具備以下特點(diǎn)：

• 不需要嚴(yán)格的格式校驗，編輯描述在經(jīng)過處理和解析后能夠穩(wěn)定apply；
• 不需要提供行號范圍，或進(jìn)行行號計算，LLM在這方面的能力很不穩(wěn)定；
• 出于token成本和時間成本的考慮，編輯描述要簡明，不包含冗余信息。

基于此，團(tuán)隊注意到Aider的代碼變更方式，受此啟發(fā)并開發(fā)了團(tuán)隊目前認(rèn)為相對穩(wěn)定的代碼編輯：豆包MarsCode AutoDiff。

（https://aider.chat/docs/benchmarks.html#the-benchmark）

AutoDiff的代碼編輯描述與git沖突的表現(xiàn)方式是類似的，Agent需要在Conflict標(biāo)識柵欄中提供需要編輯的文件路徑、代碼原文、替換代碼。

AutoDiff會對該代碼編輯塊進(jìn)行解析，嘗試在給定文件中匹配與LLM提供代碼原文片段相似度最高的片段，并用LLM提供的替換代碼進(jìn)行替換操作，隨后結(jié)合修改文件的上下文對替換代碼的縮進(jìn)進(jìn)行自動調(diào)整。

最后修改前后的文件進(jìn)行差異對照從而獲取Unified diff格式的變更文件。上述修改是模擬進(jìn)行的，并未實(shí)際在用戶設(shè)備上落盤，只是為了獲取Unified diff格式的變更文件，最終代碼修改需要經(jīng)過后續(xù)的靜態(tài)代碼診斷。

```diffs
/playground/swe_ws/testbed/matplotlib__matplotlib__3.6/lib/matplotlib/figure.py
<<<<<<< SEARCH
        elif constrained_layout is not None:
=======
        elif constrained_layout in [None, False]:
>>>>>>> REPLACE


<<<<<<< SEARCH
        else:
=======
        elif constrained_layout in [None, False]:
            self.set_layout_engine(layout='none')
>>>>>>> REPLACE

靜態(tài)代碼診斷

盡管AutoDiff能夠正確完成大部分的代碼編輯請求，但仍然會存在諸如類型錯誤、變量未定義、縮進(jìn)調(diào)整錯誤、括號沒有正確閉合等LLM常見的代碼編輯語法問題，針對這些問題，團(tuán)隊使用語言服務(wù)器協(xié)議對AutoDiff修改前后的文件進(jìn)行靜態(tài)代碼診斷，過程如下：

△圖4代碼編輯過程中的靜態(tài)代碼診斷

• 對AutoDiff生成的Unified diff格式的代碼編輯補(bǔ)丁在原文件上進(jìn)行apply，得到修改后的文件內(nèi)容；
• 對原文件內(nèi)容進(jìn)行LSP靜態(tài)代碼診斷，保存診斷結(jié)果；
• 對修改后文件內(nèi)容進(jìn)行LSP靜態(tài)代碼診斷，保存診斷結(jié)果；
• 對兩次代碼診斷結(jié)果進(jìn)行對照，檢查Agent的診斷結(jié)果是否引入新的靜態(tài)錯誤（只關(guān)注Fatal和Error級別的診斷結(jié)果）；
• 如果未引入新錯誤，則完成修改并向Agent返回修改成功的消息和相應(yīng)的Unified diff描述；
• 如果引入了新錯誤，則將相關(guān)診斷信息返回給Agent進(jìn)行修改和調(diào)整。

04 實(shí)驗結(jié)果分析

團(tuán)隊在SWE-bench Lite數(shù)據(jù)集上對豆包MarsCode Agent的性能進(jìn)行了詳細(xì)評測。

SWE-bench是由普林斯頓大學(xué)提出了一個極具挑戰(zhàn)性的針對LLM解決程序邏輯bug的benchmark。該數(shù)據(jù)集整理了真實(shí)的來自Github的12個工業(yè)級Python代碼大倉中的2294個issue問題。

給定一個代碼庫以及對要解決issue問題描述，Agent需要從代碼倉中檢索并編輯代碼，最終提交能解決相關(guān)問題的代碼補(bǔ)丁。

在SWE-bench中解決問題通常需要同時理解和協(xié)調(diào)多個函數(shù)、類甚至文件之間的更改，要求模型與執(zhí)行環(huán)境交互，處理極長的上下文并執(zhí)行比傳統(tǒng)代碼生成更復(fù)雜的推理。作者評估表明，Claude 2和GPT-4僅能解決其中4.8%和1.7%的實(shí)例。

△SWE-bench中測試實(shí)例在各repo中的分布

△不同代碼倉樣本的求解難度也參差不齊

由于SWE-bench的難度很大，在后續(xù)的研究中，開發(fā)者們發(fā)現(xiàn)在SWE-bench的2294個實(shí)例上進(jìn)行評測是一個時間與Token投入巨大且令人沮喪的過程，無法驗證短期內(nèi)的進(jìn)展。

所以SWE-bench作者從原本的數(shù)據(jù)集中抽取了300個Issue描述完整、求解邏輯清晰、相對易于解決的300個實(shí)例，組成SWE-bench Lite數(shù)據(jù)集。目前，SWE-bench Lite數(shù)據(jù)集已經(jīng)成為Agent解決軟件工程問題水平的評測標(biāo)桿，已有20多家企業(yè)與研究組織參與了SWE-bench Lite評測和提交中。

豆包MarsCode Agent在最新的SWE-bench Lite評測實(shí)驗中，成功求解了其中的118個實(shí)例，求解率達(dá)到39.33%。

下表展示了評測實(shí)驗結(jié)果的詳細(xì)分析：

豆包MarsCode Agent的錯誤定位能力

團(tuán)隊對目前SWE-bench Lite排行榜上排名前三的工具（CodeStory Aide，Honeycomb和AbanteAI MentaBot）進(jìn)行了錯誤定位能力評估。對于一個patch，如果它修改的文件和gold patch所修改的文件相同，則認(rèn)為錯誤定位正確，否則錯誤。分析結(jié)果如圖6所示：

豆包MarsCode Agent通過代碼知識圖譜、語言服務(wù)等代碼檢索工具，在300個實(shí)例中成功定位到了245個實(shí)例的待修改文件（成功率81.7%），而CodeStory Aide為221（成功率73.7%），Honeycomb為213（成功率71%），AbanteAIMentatBot為211（成功率70.3%）。從代碼檢索和錯誤定位能力看，豆包MarsCode Agent處于領(lǐng)先地位。

△圖6各方案在成功解決數(shù)量、成功定位上的對比

豆包MarsCode Agent動態(tài)靜態(tài)求解的實(shí)例分布

團(tuán)隊分析了實(shí)驗中靜態(tài)和動態(tài)求解的實(shí)例分布，如下圖所示，在所有實(shí)例中，有104/300=34.67%的實(shí)例被PlannerAgent認(rèn)為適合動態(tài)求解，196/300=65.3%的實(shí)例被認(rèn)為適合進(jìn)行靜態(tài)求解，通過動態(tài)方式成功求解53個實(shí)例，求解率為51%，靜態(tài)方式成功求解65個實(shí)例，求解率為33%。由于動態(tài)調(diào)試有缺陷復(fù)現(xiàn)和和驗證的過程，表現(xiàn)在求解率上略高于靜態(tài)修復(fù)。在被求解的118個實(shí)例中，有44.9%的實(shí)例是由動態(tài)方式修復(fù)，55.1%的實(shí)例由靜態(tài)方式修復(fù)。

△圖8豆包MarsCode Agent實(shí)驗中靜態(tài)與動態(tài)求解分布

05未來展望

豆包MarsCode Agent團(tuán)隊致力于AI Agent方法在軟件工程領(lǐng)域的落地和應(yīng)用。在未來將持續(xù)關(guān)注以下優(yōu)化方向：

-降低大語言模型調(diào)用成本，推廣豆包MarsCode Agent在更多場景的落地，為更多用戶提供高質(zhì)量智能軟件開發(fā)服務(wù)；
-加強(qiáng)用戶與Agent的協(xié)作和交互，提升用戶對Agent作業(yè)過程的掌控感；
-支持Agent對用戶工作區(qū)的動態(tài)調(diào)試，同時避免用戶環(huán)境污染等問題；
-進(jìn)一步提升文件錯誤定位準(zhǔn)確率和代碼修改正確率。

歡迎大家通過論文了解更多信息：
https://arxiv.org/abs/2409.00899