大模型重塑軟件研發，從輔助編程到多 Agent 協同還有多遠？| 新程序員

07月31日 12:06 新浪網 news-china-auto-hilite

【導讀】當編程成為最高頻的 AI 應用場景，代碼大模型的技術與產品發展之路該怎麼走？本文作者從大模型軟件研發的三大階段和四大技術難點出發，分析了 AI 如何提升編程效率，並預測了未來軟件研發工具的形態，終極目標是實現 AI 程序員，通過多智能體協同工作，大幅提升研發效率。

本文整理自阿里云云效、通義靈碼產品技術負責人陳鑫在2024 全球軟件研發技術大會中的演講，同時收錄於《新程序員 008》。《新程序員 008》聚焦於大模型對軟件開發的全面支撐，囊括 Daniel Jackson 和 Daniel Povey 等研發專家的真知灼見與「AGI 技術 50 人」欄目的深度訪談內容，歡迎大家點擊訂閱年卡。

作者 | 陳鑫阿里云云效、通義靈碼產品技術負責人

責編 | 何苗

出品丨新程序員編輯部

大模型帶來了前所未有機遇，突破傳統軟件工程和研發效能工具的局限，讓 AI 成為軟件研發必選項。

據統計，當前大模型技術近 30 %的應用需求來自於軟件研發，在軟件研發領域的應用也已經從簡單的代碼輔助生成，演進到能夠實現自主處理和開發，市場上豐富的代碼輔助工具也驗證了這一點。

這些工具借助大語言模型來提高生成代碼的準確性和性能，同時強調數據個性化的重要性，以滿足不同企業和個人的編碼習慣。我一直在思考，怎麼才能進一步挖掘大語言模型的強大推理能力、理解能力和分析能力，給研發提供更強的輔助？代碼大模型以及相關產品和技術發展之路該怎麼走？

接下來，我將從大模型軟件研發的三大階段，四大難點等角度深入剖析。

大模型軟件研發演進三步走

自AI技術浪潮再度襲來，大模型在編程領域的普及是個不可忽視的趨勢。據統計數據顯示，大模型技術近 30 %的應用需求來自於軟件研發，編程成為最高頻的 AI 應用場景。編程領域代碼生成也是大模型擅長的方向，它可顯著提升內部工作效率，讓開發者協同的方式變得更加優雅、高效、流暢。AI已成為軟件開發行業提升效率的關鍵要素。

據 CSDN、《新程序員》發起的《2024 中國開發者調查報告》顯示，專門為開發而打造的 AI 輔助編碼工具上，通義靈碼使用率位居第一，佔比 19 %。生成代碼、解釋 Bug 並提供修正、生成代碼註釋或者代碼文檔是開發者常用 AI 輔助編碼工具來實現的事情，分別佔比 41 %、29 %和 28 %。而我們正努力通過大模型與軟件研發工具鏈的融合，逐步優化這些任務。

大模型正從兩大方向影響著軟件研發：

圖 1 大模型對軟件領域的影響

1、編程事務性工作的普遍替代

開發者的工作中存在大量重覆性任務，例如編寫膠水代碼、框架代碼和簡單的業務邏輯。這些任務並非開發者核心關注點，如果大模型可以有效替代這些重覆性工作，將顯著提高個體效率。

此外，編程過程中通常涉及大量角色的協同工作，如產品經理、架構師、開發、測試和運維等。溝通往往耗時費力、協作成本高。如果能引入智能體，打造「超級個體」，將部分編碼任務交由 AI 完成，就可以減少複雜的協同工作，提高整體協作效率。

2、知識傳遞模式的革新

傳統的知識傳遞方式主要依賴於口口相傳，如 code review、培訓和代碼規範的宣導等，這些方式往往滯後且效率低。智能化的研發工具鏈可以直接賦能一線開發者，提升團隊整體水平。未來，每個團隊可能會有專門擅長知識沉澱和梳理的成員，通過不斷訓練和優化大模型，使整個團隊受益。

縱觀整體趨勢，大模型軟件研發相關技術將分三步演進：

第一階段：代碼輔助生成

如 GitHub Copilot、通義靈碼這類工具作為 IDE 插件，安裝後可以顯著提升編碼效率，但並沒有改變現有的編程習慣和研發工作流。AI 只是生成代碼、編寫測試或解釋問題，最終的校驗和確認依然由人完成，這個階段，依然以人類為主導。

第二階段：任務自主處理

AI 可以通過智能體技術自主校驗生成的結果，例如，AI 編寫測試用例後，能夠自主判斷測試是否通過、能否解決程序遇到的問題或發現新的問題。當我們進入智能體階段，開發者可以減少對 AI 生成結果的人工校驗。在此階段，雖然仍以人類為主導，但AI已展現出獨立完成特定任務的能力。此時將出現一條明顯的產品分界線。

第三階段：多智能體協同工作

多個智能體協同工作，並由大模型進行規劃，完成複雜任務，如編寫測試、寫代碼、撰寫文檔和需求分解等，而人類主要負責創意、糾偏和確認。這一階段，AI 不只是 IDE 插件，而是可以實現功能的自主開發。代表性的產品有 GitHub Workspace 和今年 6 月阿里雲剛推出的 AI 程序員，這些都標誌著我們正在迎來 AI 自主化編程的時代。

以上前兩個階段，軟件效率的提升大約在 10 %至 30 %之間，包括編碼效率的提升和 DevOps 流程的優化。那麼，在第三階段，我們可以通過打破現有的軟件研發流程框架，面向 AI 設計新的編碼框架和編程模式，效率提升有望突破 30 %，達到 50 %甚至 70 %。

死磕 Copilot 模式四大核心技術難點

接下來，當我們聚焦每個階段，現有產品、技術發展的現狀以及技術細節，就會發現未來還需攻堅的技術難點。以第一階段最常見的 Copilot 模式為例，它主要分為以下幾層：表現層、本地服務端、服務端、模型層、數據處理層、基礎設施層。

圖 2 Copilot 階段通義靈碼的核心功能架構

當我們聚焦現有代碼助手產品技術發展的現狀，以及技術細節，就會發現未來需要攻堅的難點主要有四點：

生成的準確度：準確率是決定產品能否應用於生產的關鍵因素；
推理性能：代碼生成速度和整體性能的提升；
數據個性化：適應不同企業和個人的編程習慣；
代碼安全與隱私：確保代碼生成過程中數據的安全和隱私。

其中準確度包含生成準確度和補全信息準確度兩方面。

1、加強生成準確度

根據內部調研報告顯示，準確率才是產品的核心，開發者可以接受慢一點，也可以接受有瑕疵，但準確率才是決定能否應用於生產、會不會持續使用的最關鍵因素，而過硬的基礎模型能力是準確度的基礎。我們通常認為模型是產品能力的上限，一個可靠的基礎模型是首要的。

通義靈碼的可靠模型主要依賴以下兩個：

通義靈碼補全模型。它專做代碼補全，被稱為「 CodeQwen2 」技術模型，是目前世界範圍內非常強大的模型，在基礎模型中排名第一，主要通過持續訓練，提升其跨文件感知能力、生成代碼能力及各個語言的細節優化，糾正其基礎模型上的一些缺點，最終訓練而成。

通義靈碼問答模型。要想模型不僅基礎能力強，還能很好地處理專項代碼任務，就需要構造大量數據用於訓練。單元測試、代碼解釋和代碼優化等複雜任務，都需要構造大量數據進行訓練，讓模型遵循固定範式，從而持續輸出穩定的結果。阿里目前基於 Qwen2 模型進行訓練，它支持最大 128K 的上下文，不論是處理具體代碼任務、Agent 任務，還是 RAG 優化，都表現出色。

除此之外，還需補全信息準確度。開發者在寫代碼時，不僅關注當前文件，還有查看引用、工程框架及編碼習慣等。因此我們在端側還設置了複雜的代碼分析功能，專門構建整個工程的引用鏈及相關數據，將其轉化為全面的上下文傳給大模型進行推理。在代碼補全方面，我們進行插件與模型的聯合優化，每增加一種上下文都需要構造大量數據訓練模型，使其能感知到輸入上下文與預測結果的關聯關係。通過一系列處理，可大幅降低模型生成的幻覺，使其更好地遵循當前工程開發者的習慣，模仿人類編寫相應代碼，從而提升生成代碼的質量。

圖 3 通義靈碼補全準確度的方式

2、解決性能問題

如何解決代碼生成既快又好的問題，還是得在性能方面下功夫。各種代任務通常不是由單一模型完成的，而是多個模型組合完成。因此，在代碼補全方面，我們使用了 CodeQwen2 這個 7B 參數的小模型能保證在 500 到 800 毫秒內完成推理，做到快；在代碼任務訓練方面，使用千億參數模型成本高且不划算，用中等參數模型訓練，性價比高且更擅長；對於問答任務，通過大參數模型 Qwen-Max 和互聯網實時檢索技術，可以快速且準確地回答這些問題。

通常，採用多個模型組合來保證時延的優化是比較可靠的做法。大參數的模型，具有廣泛的知識面和強大的編程能力，能夠獲取實時支持；各種加速和緩存技術，包括在端側使用流式補全也可以降低延時；使用本地緩存、服務端緩存，再加上推理加速等多種技術，可以兼顧實現速度和準確性。這些措施共同作用，能讓通義靈碼能提供高效、準確的編程輔助。

圖 4 通義靈碼提升推理性能的方式

3、攻克數據個性化

數據個性化依然針對兩個典型場景：代碼補全和研發問答。

圖 5 在代碼補全、研發問答兩方面提升推理性能

在代碼補全中，對於相似邏輯的編寫，可以用企業已寫過的優質邏輯代碼來生成，避免重覆造輪子。在自研框架的使用中，尤其是在前端開發，每個企業的前端框架往往不盡相同，如果直接使用基於開源數據訓練的模型，生成的結果可能會有瑕疵，可以通過 RAG 技術，使員工在代碼補全過程中實時獲取所需的參考範例，從而生成符合企業規範的代碼。

而研發問答這一領域相對成熟，文檔問答、API 生成代碼規範、代碼校驗等比較簡單就能做到，假設開發者選中一段代碼並請求模型根據團隊規範進行修正，其背後的原理是通過 RAG 技術，模型能夠檢索團隊當前語言的規範，並據此對代碼進行校驗和生成，這些都屬於數據個性化場景應用。

代碼補全場景更加關注時延，力求將檢索時間降低到 100 毫秒以內，技術實現有一定難度。而研發問答場景更注重精準度，目標是召回率達到 70 %以上甚至 90 %以上，以提高回答效率。儘管優化目標不同，兩者在基礎設施上都涉及知識庫管理、 RAG 流程、推理引擎和向量服務，這也是通義靈碼重點優化的方向。

4、代碼安全與隱私

為解決代碼的安全隱私問題，我們設計了全鏈路安全防護策略，讓企業可以以較低的成本享受到 AI 的能力，每月僅需一兩杯咖啡錢。

圖 6 通義靈碼的全鏈路安全防護

加密端側代碼，確保即使請求被攔截也無法複原代碼；

製定本地向量存儲和推理全部在本地完成的策略，除非是主動上傳的企業級數據，否則代碼不會上傳到雲端，保證了雲端沒有代碼殘留，即使黑客攻破了通義靈碼集群，也無法獲取用戶數據，確保了安全性；

設置敏感信息過濾器，確保所有企業上傳的代碼都合規，能夠放心使用公共雲的推理服務，實現極高的性價比。

從簡單走向複雜的代碼生成，並非一蹴而就

通義靈碼在以 Copilot 為代表的代碼助手方面已經比較成熟，從滿意度調查和替代率兩個重要方向來評估它在企業中的滿意度。基於 1124 份有效樣本，超過 72.5 %的受訪者在編碼工作效率提高方面給予了四分以上的評分（總分為五分）。針對後端語言，通義靈碼生成代碼的替代率在 30 %以上，而前端由於存在大量的複製黏貼操作，生成率略低，約為 20 %左右。

那麼，在大模型軟件研發相關技術演進的第二階段，我們如何從簡單的代碼任務逐步走向複雜的代碼生成？

2024 年 3 月，Devin 發佈，只需一句指令，它可以端到端地進行軟件開發和維護。雖然只是一個預覽版，但它讓我們看到 Multi Agent 方向的可行性。這是從 0 到 1 的突破，Devin 顯著提升了 AI 在實際編碼任務中的應用能力。同年 4 月，GitHub 發佈了 Workspace，它是編碼自動化的初步嘗試。

以上再次證明了 AI 在代碼生成領域的潛力巨大，儘管還有很長的路要走，但這表明我們正在朝著實現更高效、更智能的編程環境邁進。在技術路線上，我認為需要分為四個階段逐步發展，而非一次性躍遷。

圖 7 從單一 Agent，走向多 Agent 架構的四大階段

第一階段：單工程問答 Agent

要解決基於單工程的問答需求。典型的功能如代碼查詢、邏輯查詢、工程解釋，基於工程上下文的增刪改查接口、編寫算法，在 MyBatis 文件中增加 SQL 語句等，都屬於簡單任務，已經充分利用了單庫的 RAG 技術以及簡單的Agent來實現。這為更複雜的多 Agent 協同系統打下了基礎。

第二階段：編碼 Agent

進入能夠自主完成編碼的階段。Agent 將具備一定自主任務規劃能力，以及使用工具能力，可自主完成單庫範圍內的編碼任務。例如，在集成開發環境（IDE）中遇到編譯錯誤或缺陷報告時，用戶可以一鍵讓 AI 生成相應的補丁。

第三階段：測試 Agent

到達具備自主測試能力的 Agent 階段，它不僅能夠編寫單元測試，還能理解任務需求、閱讀代碼並生成測試。不管是單元測試還是黑盒測試方法。而另一些 Agent 可以用於架構分解、文檔編寫、輔助閱讀等功能。

第四階段：Multi-Agent

接下來，多 Agent 基於 AI 調度共同完成任務，就可以實現更複雜的任務管理和協作實現，從需求->代碼->測試的全流程自主化。我們的終極目標是 AI 程序員的水平，類似於 Devin 項目。這一階段將涵蓋更複雜的編程任務，需要更高級的 AI 調度和協同能力。

Code Agent 落地門檻：問題解決率至少 50 %以上

從整個技術路線圖來看，前三步通義靈碼已覆蓋。它展示了整體工作流，以本地康尼檢索增強服務為核心，提高了代碼和文檔的準確檢索及重排效率，並結合企業知識庫，增強了系統的綜合問題解決能力。

這一過程需要不斷優化，其過程涉及幾個關鍵點：首先，深入理解需求，這是整個優化流程的基石；其次，提升需求在康尼檢索的成功率，它直接影響到後續步驟的效率與效果；再者，模型本身的性能提升，將檢索到的信息整合併解決問題的能力至關重要，這是 Code Agent 的前身。

接下來要重點攻克的是 Code Agent 技術。SWE-bench-Lite 測試集是業界公認的Code Agent 測試標準，在測試集上，通義靈碼 Agent 實現了 33 %的問題解決率，領先業界。然而，要推動這一技術走向實際應用，仍面臨諸多挑戰。

圖 8 靈碼 Agent 在 SWE-bench-Lite SOTA 測試集的表現

難點一：當前 Code Agent 的效果高度依賴 GPT-4 等先進基礎模型，基礎模型的能力可能是整個領域往前走的一大阻礙，這限制了技術的普及與自主可控性。

難點二：上述方案在調優上比較困難，容易牽一髮動全身，難以快速迭代；

難點三：長上下文依賴和多輪次複雜 Action 處理仍是技術瓶頸；

難點四：模型調優問題，這是當前的一個重要挑戰，即便是使用 GPT-4，我們在SWE-bench-Lite SOTA 測試集上的表現也僅為 30 %以上的問題解決率，這與生產級可落地的標準仍存在較大差距。因為測試集中不僅包含了相對簡單的單文件修改任務，還涉及到了更為複雜的多文件和多任務修復場景，這對模型的上下文理解、邏輯推斷及代碼生成能力提出了更高的要求。要達到生產級可落地的標準，需要至少將問題解決率提升至 50 %以上，繼續加大技術研發投入是必要的。

未來的軟件研發工具形態

對於通義靈碼仍有差距的第四階段——Multi-Agent 階段，我們也已經有了清晰的概念架構，其工作流程大概是：用戶輸入指令後，一個複雜的多 Agent 協同系統隨即啟動。該系統核心解決三大問題：

首先，通過結構化的任務管理，模擬人類團隊分解大型任務的行為，實現高效協作；
其次，簡化工作流程，將複雜任務細化為小任務，並借助 Agent 特性逐一執行；
最後，高效執行任務，讓每個智能體專注自身任務並協同工作，共同完成複雜任務。

未來的軟件研發工具鏈也將呈現三層架構：

圖 9 未來的軟件研發工具鏈架構

底層為 AI 基建層，為中層的通義靈碼與AI程序員等提供基礎支持，涵蓋運行環境、模型推理服務、模型微調 SFT、檢索增強 RAG、企業管理功能及核心模型。在 AI 基建層，工具共享、不同模型各司其職，這進一步驗證了我們的技術演進路線。

通義靈碼與中層的 AI 程序員之間存在遞進的技術演進關係，雖然共享同一 AI 基建，但在產品交互及與開發者的連接方式上，兩者差異顯著。AI 程序員擁有自主化工作區，採用問答式交互方式，這種非傳統 IDE 形態卻能無縫連接最上層的 IDE 端、開發者門戶及 IM 工具，成為開發者主要入口的延伸。

右側，與現有 DevOps 工具鏈緊密鏈接，在不顛覆現有 DevOps 或 CICD 流程的基礎上，極大地簡化和優化了這些流程。

AI 程序員邊界明確，專注於從任務輸入到文檔編寫、測試用例測試完成的全過程，未涉及 CICD 或複雜運維操作，作為現有工具鏈的有效補充，它將大幅簡化工具鏈交互，優化流程協作，對組織結構和開發者技能產生深遠影響，甚至可能引領未來編程軟件向 AI+Serverless 的架構轉型。

當前的 Serverless 主要由各類 function 構成，並通過 workflow 緊密相連。AI 擅長獨立完成單一的 function，但面對龐大、複雜的代碼工程，尤其是質量欠佳的代碼時，修復能力尚顯不足。未來，Serverless 與 AI 融合的編程架構有望成為主流趨勢，這並非無稽之談。我們堅信，隨著技術和基礎模型的不斷演進，預計在未來 3-6 個月內，將有相應產品推出，並有望在部分生產級場景中實現落地應用。

阿里雲內部代碼助手落地實況

阿里雲已經全員推行 AI 輔助編碼，同時充分考慮各部門的差異。面對不同部門的框架差異，主要採取兩種策略。一種是通過 RAG 來實現，即根據每個部門自身需求建立知識庫，用於補全和問答優化。每個部門都能梳理並優化其常用代碼樣例、框架示例及 API 示例，儘量保持其獨特性。這種方式讓一個工具能夠靈活覆蓋所有部門的需求。

另一種是進行模型微調，已在一些企業中嘗試過。利用小規模數據集對模型進行微調，結果顯示，這種基於個性化業務代碼的微調能夠顯著提升模型的準確率，雖然有效，但其成本較高且過程複雜。

從採納率和 AI 代碼生成佔比來看。目前，阿里雲內部的 AI 代碼生成佔比已達到 31%，後端語言如 Java 的佔比更高，達到 30 %以上。這些數字表明，基於開源代碼訓練的模型已經能夠在實際應用中發揮重要作用，未來通過 RAG 的進一步優化，我們有信心進一步提升這些指標。

關於前文提到的通過前端工具將上下文學習與後端大模型結合，以在代碼補全方面取得更好效果，我們主要根據不同語言的特性來解析代碼的依賴關係，以構建整個工程的依賴樹。當我們需要為某個文件進行代碼補全時，會找到該文件所處的上下文，類似於人類編寫代碼時的行為。為確保代碼補全的準確性，需要將當前文件的所有依賴項都納入上下文考慮範圍，否則模型可能會產生「幻覺」，即生成與上下文不符的代碼。

此外，我們還會尋找與當前編寫位置相似的代碼片段，幫助模型理解工程內部的編寫風格，為代碼補全提供有價值的參考。以 Spring Boot 等框架為例，許多內部擴展或「膠水層」代碼都具有一定的相似性。通過找到這些相似代碼，模型能夠生成更貼近實際需求的代碼，從而提高採納率。

同時我們會收集跨頁面的相似組件信息，以供模型參考。判斷哪些上下文對當前位置的代碼生成具有更高的採納概率，再通過算法調優來確保模型能夠優先利用最重要的上下文信息，包括優先級排序、篩選和壓縮等一系列操作。

一般情況下業務研發部門無需直接參與前端上下文知識的處理工作，這取決於具體的業務需求和項目複雜度。

為了進一步提升效果，我們還需要收集和處理業務單位的反饋。在實際應用中，開發者們可能會遇到一些「 bad case 」，即插件生成的代碼不符合他們的期望或需求。為了優化插件的性能和準確性，我們需要基於具體場景進行調優。我們會不斷優化通義靈碼並持續發佈先進的產品，向著大模型賦能軟件開發的終極形態堅定地走下去。