自動(dòng)化漏洞修復(fù)已經(jīng)從簡單的基于模板的方法發(fā)展到由LLM、代理、無代理和RAG范例驅(qū)動(dòng)的復(fù)雜AI系統(tǒng)。

如果你有軟件開發(fā)經(jīng)驗(yàn)，就會(huì)知道調(diào)試通常是工作中最耗時(shí)且最令人沮喪的部分。試想一下，如果人工智能可以幫你處理這些煩人的漏洞呢？

自動(dòng)化程序修復(fù)（Automated Program Repair，APR）的最新進(jìn)展使這一目標(biāo)日益成為現(xiàn)實(shí)。接下來，就讓我們來探索一下這項(xiàng)技術(shù)是如何發(fā)展的，以及它的發(fā)展方向吧。

基礎(chǔ)：傳統(tǒng)的漏洞修復(fù)方法

早期的自動(dòng)化漏洞修復(fù)方法依賴于相對(duì)簡單的原則。像GenProg這樣的系統(tǒng)就是應(yīng)用預(yù)定義的轉(zhuǎn)換規(guī)則來修復(fù)常見的模式，比如空指針檢查或數(shù)組邊界驗(yàn)證。雖然這種方法在當(dāng)時(shí)是創(chuàng)新之舉，但在處理復(fù)雜的代碼庫時(shí)，它很快就達(dá)到了極限。

1 # Example of a simple template-based fix
2 def fix_array_bounds(code):
3 # Look for array access patterns
4 pattern = r'(\w+)\[(\w+)\]'
5 
6 # Add bounds check
7 replacement = r'(\2 < len(\1) ? \1[\2] : null)'
8 
9 return re.sub(pattern, replacement, code)

總體來說，這些早期基于模板的系統(tǒng)面臨著下述重大挑戰(zhàn)：

• 有限的靈活性。它們只能解決與預(yù)定義模式匹配的錯(cuò)誤。?
• 計(jì)算成本過高。基于約束的方法通常要運(yùn)行數(shù)小時(shí)才能生成補(bǔ)丁。?
• 薄弱的適應(yīng)性。它們努力在大型動(dòng)態(tài)代碼庫中處理新穎或復(fù)雜的問題。?

當(dāng)Facebook試圖為它們的React代碼庫實(shí)現(xiàn)基于模板的修復(fù)時(shí)，系統(tǒng)在框架的組件生命周期模式和狀態(tài)管理復(fù)雜性方面遇到了困難。類似地，當(dāng)在Apache Commons庫上使用時(shí)，基于約束的方法通常要運(yùn)行數(shù)小時(shí)才能為中等大小的函數(shù)生成補(bǔ)丁。

LLM驅(qū)動(dòng)的修復(fù)興起

大型語言模型（LLM）的引入改變了自動(dòng)化漏洞修復(fù)的可能性。像GPT-4、Code Llama、DeepSeek Coder和Qwen2.5 Coder這樣的模型不只是修補(bǔ)語法錯(cuò)誤，它們還能理解代碼的語義意圖，并在復(fù)雜的代碼庫中生成上下文合適的修復(fù)。

概括來看，這些模型帶來了下述多種功能：

• 上下文感知推理。它們理解代碼不同部分之間的關(guān)系。?
• 自然語言理解。它們彌合了技術(shù)問題陳述和可操作修復(fù)之間的缺口。?
• 從模式中不斷學(xué)習(xí)。它們從大量的代碼中識(shí)別常見的漏洞模式。?

具體而言，每種模型都有其獨(dú)特的優(yōu)勢(shì)：

現(xiàn)代APR系統(tǒng)的三個(gè)范式

基于代理的系統(tǒng)

基于代理的系統(tǒng)通過多代理協(xié)作利用LLM，每個(gè)代理專注于一個(gè)特定的角色，如故障定位、語義分析或驗(yàn)證。這些系統(tǒng)擅長通過任務(wù)專門化和增強(qiáng)協(xié)作來解決復(fù)雜的調(diào)試挑戰(zhàn)。

在此類系統(tǒng)中，最具創(chuàng)新性的實(shí)現(xiàn)包括以下幾種：

• SWE-Agent——為大規(guī)模存儲(chǔ)庫調(diào)試而設(shè)計(jì)，它可以處理跨存儲(chǔ)庫依賴關(guān)系；?
• CODEAGENT——集成LLM與外部靜態(tài)分析工具，優(yōu)化協(xié)同調(diào)試任務(wù)；?
• AgentCoder——軟件工程任務(wù)的端到端模塊化解決方案；?
• SWE-Search——采用蒙特卡羅樹搜索（MCTS）進(jìn)行自適應(yīng)路徑探索。?

其中，SWE-Search具有自適應(yīng)路徑探索能力，是一項(xiàng)重大進(jìn)步。它由一個(gè)用于探索的SWE代理、一個(gè)用于迭代反饋的Value代理和一個(gè)用于協(xié)作決策的Discriminator代理組成。與缺乏MCTS的標(biāo)準(zhǔn)代理相比，該方法的相對(duì)改善率為23%。

無代理系統(tǒng)

無代理系統(tǒng)通過消除多代理協(xié)調(diào)開銷來優(yōu)化APR。它們通過一個(gè)簡單的“三階段”模式來運(yùn)作：

• 層次定位。首先，確定有問題的文件，然后放大類或函數(shù)，最后確定特定的代碼行；?
• 上下文修復(fù)。生成具有適當(dāng)代碼更改的潛在補(bǔ)??；?
• 驗(yàn)證。使用重現(xiàn)測(cè)試、回歸測(cè)試和重新排序方法測(cè)試補(bǔ)丁。?

DeepSeek Coder憑借其存儲(chǔ)庫級(jí)別的預(yù)訓(xùn)練方法在這一類別中脫穎而出。與之前在文件級(jí)別操作的方法不同，DeepSeek使用存儲(chǔ)庫級(jí)別的預(yù)訓(xùn)練，通過創(chuàng)新的依賴解析算法更好地理解跨文件關(guān)系和項(xiàng)目結(jié)構(gòu)。

該模型利用了一種平衡的方法，在中間填充訓(xùn)練中使用50%的前綴-后綴-中間比例，提高了代碼完成和生成性能。結(jié)果不言自明——DeepSeek-Coder-Base-33B在首次發(fā)布時(shí)，在HumanEval上的平均準(zhǔn)確率達(dá)到50.3%，在MBPP基準(zhǔn)上的平均準(zhǔn)確率達(dá)到66.0%。

RAG系統(tǒng)

像CodeRAG這樣的檢索增強(qiáng)生成（RAG）系統(tǒng)將檢索機(jī)制與基于LLM的代碼生成混合在一起。這些系統(tǒng)結(jié)合了來自GitHub存儲(chǔ)庫、文檔和編程論壇的上下文信息，以支持修復(fù)過程。

這種系統(tǒng)的主要特點(diǎn)包括以下幾點(diǎn)：

• 上下文檢索：從外部知識(shí)來源中提取相關(guān)信息；?
• 自適應(yīng)調(diào)試：支持涉及領(lǐng)域?qū)＜一蛲獠緼PI集成的修復(fù)；?
• 基于執(zhí)行的驗(yàn)證：通過受控的測(cè)試環(huán)境提供功能正確性保證。?

當(dāng)在SWE基準(zhǔn)上進(jìn)行評(píng)估時(shí)，無代理系統(tǒng)的成功率達(dá)到50.8%，優(yōu)于基于代理的方法（33.6%）和檢索增強(qiáng)方法（30.7%）。然而，每個(gè)范例都有特定的優(yōu)勢(shì)，這取決于用例和存儲(chǔ)庫的復(fù)雜性。

新一代APR系統(tǒng)性能評(píng)估

評(píng)估APR系統(tǒng)需要跨多個(gè)維度測(cè)量性能：漏洞修復(fù)的準(zhǔn)確性、效率、可擴(kuò)展性、代碼質(zhì)量和適應(yīng)性。以下是三個(gè)關(guān)鍵基準(zhǔn)：

SWE -bench：全方位的基準(zhǔn)

SWE -bench在12個(gè)流行的Python存儲(chǔ)庫中測(cè)試真實(shí)GitHub缺陷的APR功能。它創(chuàng)建了具有解決問題任務(wù)的真實(shí)世界場景，這些任務(wù)需要深入的分析和代碼編輯中的高精度。解決方案是使用個(gè)別存儲(chǔ)庫中的特定測(cè)試用例進(jìn)行評(píng)估，以獲得客觀評(píng)級(jí)。

CodeAgentBench：專注于多代理框架

作為SWE -bench的擴(kuò)展，CodeAgentBench的目標(biāo)主要是多代理框架和存儲(chǔ)庫級(jí)調(diào)試功能。它主要從以下方面評(píng)估系統(tǒng)：

• 動(dòng)態(tài)工具集成——能夠與靜態(tài)分析工具和運(yùn)行時(shí)集成；?
• 代理協(xié)作——任務(wù)專門化和代理間通信；?
• 覆蓋范圍——復(fù)雜的測(cè)試用例和多文件挑戰(zhàn)。?

CodeRAG-Bench：測(cè)試檢索增強(qiáng)方法

CodeRAG-Bench專門評(píng)估集成了上下文檢索和生成管道的系統(tǒng)。它通過測(cè)量系統(tǒng)如何整合來自不同來源（如GitHub discussion和文檔）的信息來測(cè)試修復(fù)復(fù)雜漏洞的適應(yīng)性。

當(dāng)前的限制和挑戰(zhàn)

盡管取得了令人矚目的進(jìn)步，但APR系統(tǒng)仍然面臨以下重大障礙：

• 有限的上下文窗口——處理大型代碼庫（數(shù)千個(gè)文件）仍然具有挑戰(zhàn)性；?
• 準(zhǔn)確性問題——由于缺乏準(zhǔn)確的上下文敏感代碼生成，多行或多文件編輯有更高的錯(cuò)誤率；?
• 計(jì)算費(fèi)用——使大規(guī)模、實(shí)時(shí)調(diào)試變得困難；?
• 驗(yàn)證差距——當(dāng)前的基準(zhǔn)測(cè)試不能完全反映現(xiàn)實(shí)世界的復(fù)雜性。?

現(xiàn)實(shí)世界的應(yīng)用程序

將APR集成到行業(yè)工作流程中已經(jīng)顯示出顯著的好處，具體如下所示：

• 自動(dòng)化版本管理——在升級(jí)期間檢測(cè)和修復(fù)兼容性問題；?
• 安全漏洞修復(fù)——模式識(shí)別和上下文感知分析，以加快修補(bǔ)速度；?
• 測(cè)試生成——為未覆蓋的代碼路徑創(chuàng)建單元測(cè)試，并為復(fù)雜工作流創(chuàng)建集成測(cè)試。?

正在實(shí)施APR工具的公司匯報(bào)了下述結(jié)果：

• 與手動(dòng)調(diào)試相比，修復(fù)常見問題的時(shí)間減少了60%；?
• 測(cè)試覆蓋率增加40%；?
• 減少30%的回歸漏洞。?

諸多大型企業(yè)都正在采取行動(dòng)：

• 谷歌的Gemini Code Assist報(bào)告稱，常規(guī)開發(fā)人員的任務(wù)時(shí)間減少了40%；?
• 微軟的IntelliCode提供了上下文感知的代碼建議；?
• Facebook的SapFix自動(dòng)修復(fù)生產(chǎn)環(huán)境中的漏洞。?

原文標(biāo)題：??Automated Bug Fixing: From Templates to AI Agents??，作者：Meghana Puvvadi、Santhosh Vijayabaskar