譯者 | 晶顏

審校 | 重樓

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

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

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

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

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

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)：

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

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

LLM驅(qū)動的修復興起

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

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

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

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

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

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

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

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

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

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

無代理系統(tǒng)

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

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

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

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

RAG系統(tǒng)

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

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

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

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

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

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

SWE -bench：全方位的基準

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

CodeAgentBench：專注于多代理框架

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

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

CodeRAG-Bench：測試檢索增強方法

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

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

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

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

現(xiàn)實世界的應用程序

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

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

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

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

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

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

原文標題：Automated Bug Fixing: From Templates to AI Agents，作者：Meghana Puvvadi、Santhosh Vijayabaskar