譯者 | 晶顏

審校 | 重樓

自動化漏洞修復已經從簡單的基于模板的方法發展到由LLM、代理、無代理和RAG范例驅動的復雜AI系統。

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

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

基礎：傳統的漏洞修復方法

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

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)

總體來說，這些早期基于模板的系統面臨著下述重大挑戰：

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

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

LLM驅動的修復興起

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

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

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

具體而言，每種模型都有其獨特的優勢：

現代APR系統的三個范式

基于代理的系統

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

在此類系統中，最具創新性的實現包括以下幾種：

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

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

無代理系統

無代理系統通過消除多代理協調開銷來優化APR。它們通過一個簡單的“三階段”模式來運作：

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

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

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

RAG系統

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

這種系統的主要特點包括以下幾點：

• 上下文檢索：從外部知識來源中提取相關信息；
• 自適應調試：支持涉及領域專家或外部API集成的修復；
• 基于執行的驗證：通過受控的測試環境提供功能正確性保證。

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

新一代APR系統性能評估

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

SWE -bench：全方位的基準

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

CodeAgentBench：專注于多代理框架

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

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

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

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

當前的限制和挑戰

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

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

現實世界的應用程序

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

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

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

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

諸多大型企業都正在采取行動：

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

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