通義靈碼是基于阿里巴巴通義大模型研發的AI 智能編碼助手，在通義靈碼 1.0?時代，我們針對代碼的生成、補全和問答，通過高效果、低時延，研發出了國內最受歡迎的編碼助手。

在通義靈碼 2.0 發布會上，阿里云通義實驗室自然語言處理方向負責人黃非分享了代碼大模型的演進。過去一年來，隨著大模型技術的發展，特別是智能體技術的深入應用，通義靈碼也在智能體的基礎上研發了針對于整個軟件研發流程的不同任務的智能體，這里既包括單智能體，也包括多智能體合并框架，在這樣的基礎上我們研發了通義靈碼2.0。

我們首先回顧軟件工程的發展歷史。1960年代中期，軟件開發進入危機時代，因為那個時候軟件開發并沒有固定的方法可循，整個的軟件設計是在開發人員頭腦中完成了一個隱藏的過程，而且軟件維護的成本居高不下，產品質量也比較低。

1968年以來通過 NATO 會議，正式提出了軟件工程這樣一個術語，人們提出了結構化的開發方法，也包括瀑布式的軟件生命周期流程，軟件測試和驗證成為軟件開發的重要環節。

1983年 C++?正式發布以來，推動了面向對象的程序設計方法，面向對象程序設計方法意味著對象的編程、軟件開發的工具都得到了改進，包括軟件開發的環境 IDE 和版本控制的工具也得到了廣泛的使用。同時也有一些 ISO9000、SPICE 等質量標準體系的形成，確保軟件工程的開發滿足標準化的流程。

在90?年代末，進入互聯網時代，由于軟件的快速發展催生了敏捷開發的革命，需要更緊密的團隊協作，需要不同團隊之間有效地應對不同需求的變化，需要軟件的持續構建、持續集成、持續迭代和持續交付。

到2023 年以來，隨著 GPT-4 的推出，大模型對于整個開發帶來革命性地變化。比如說基于大模型的智能輔助開發系統逐漸成為主流，大模型驅動的軟件智能開發助手已應用到軟件開發流程的各個環節中來，也推動了軟件工程以更為智能高效的方式去推動、去發展。

如果仔細來看一下智能軟件工程的詳細流程，我們會看到在2020?年生成式大模型發布之前，其實已經有了一些針對于軟件開發的小模型的工作，包括 CodeBERT、GraphCodeBERT，這些是以 BERT 為框架，但還只主要針對于代碼理解這樣的任務。

到了2021 年，以 CodeX 為代表的生成式大模型為特色，針對于代碼的生成，代碼的補全，已經開始得到了應用。在此基礎上的話，一個非常重要的衡量代碼生成的榜單，HumanEval 也被提了出來。

到了2023 年我們看到包括 ChatGPT、GPT-4，包括 Qwen 這樣的通用模型，以及在此基礎上的 CodeQwen、CodeLlama 等代碼專用模型更廣泛地應用到了軟件開發的過程中，包括代碼的生成、補齊、注釋的生成、單元測試的生成等等，都應用了這方面的能力。

我們也看到在2023 年底，SWE-bench 這樣一個更真實的模擬軟件開發流程的一個 benchmark 也被提了出來，在這個 benchmark 上提供的一些評估能力，也能更準確地評估大模型或者是 AI 編碼助手在真實軟件開發過程中的一個效果。

到了2024 年，我們可以看到更多的代碼模型不斷涌現出來，也更完整地融入到整個端到端的軟件開發流程，從用戶需求的理解，到軟件的設計，到軟件的開發、調試、生成、交付文檔等等一系列流程，都能夠用到智能大模型的技術。

總結來看的話，以大語言模型為基座帶來了整個軟件工程開發新的范式，從早期的智能助手的階段，LLM+Copilot的結合，到中期的基于智能體，每個智能體成為一個單獨的智能專家，能夠自主地用工具完成一個特定的任務。

到第三個階段即多智能體的階段，以大模型為基礎，能夠更好地完成整個軟件流程開發的不同任務，配合來完成更復雜的開發任務。

我們的通義靈碼是在QwenCode2.0?的基礎上建立的，Qwen2.5-Coder 是在 Qwen 的基礎上研發而成，這里包括了適應多場景的全尺寸的代碼大模型。

我們發布了包括7B、32B 等共六款 Qwen2.5-Coder 模型，這六款代碼模型在同等尺寸下均取得了業界最佳的效果，包括代碼生成、代碼推理、代碼修復等等核心場景，其中 32B 的旗艦代碼模型在 10?余項基準評測中都取得了開源模型的最佳成果。同時，代碼模型還在代碼生成關鍵能力上對齊了閉源模型 GPT-4o。

具體來說，Qwen2.5-Coder是基于 Qwen2.5 的基礎大模型進行初始化，使用了包括源代碼、文本代碼混合數據以及代碼合成數據等總共 5.5T tokens 的數據進行持續地訓練，實現了代碼相關下游任務的顯著提升，特別是針對非常有挑戰性的真實世界的軟件工程任務，我們提出了兩階段的文件級別預訓練及倉庫級別的預訓練，增強了 Qwen-Coder 對于倉庫上下文的依賴和理解。

此外，為了適配開發者的多語言需求，Qwen-Coder在接近百種編程語言上進行了預訓練和對齊。在實際評測中，Qwen2.5-Coder 32B 的模型在 40?余種編程語言中表現優異，在 MC-EVAL 基準上取得了所有開閉源模型的最高分，并斬獲了考察多種編程語言代碼修復能力的 MD-EVAL 基準的開源冠軍。

在通義靈碼產品化落地階段，我們看到有兩個步驟，第一階段的話就是 Copilot 的階段。代碼模型作為一個編碼助手能夠幫助程序員在編碼過程中，針對特定任務完成特定的工作。

第二階段的話就是 AI 程序員，更深入地融合到軟件開發的整個流程中來，能夠起到更大的作用。

我們以Test Agent 測試智能體為例來解釋一下，Test Agent 專注于單元測試的相關任務，用戶只需要說出單測的需求，Test Agent 就會自動地幫助你完成單元測試生成的全部流程。

它具備多項能力，比如說用戶需求的分析、計劃的制定、完整分析被測函數中的代碼依賴、使用工具與 code base 進行交互，比如說搜索的工具、編輯器工具等，結合編譯器、執行器的環境反饋完成單元測試的生成和 bug 的修復。

通義靈碼2.0?的 AI 程序員采用的是多智能體的框架，這個框架分為兩個主要的部分，一個是環境的部分，一個是智能體的部分，環境的部分包括代碼倉庫、各種軟件工程工具和 Reward Model 等等。

智能體的部分是系統的核心，這里由 5 個專門的 AI 智能體組成，包括規劃智能體、搜索、生成、單測、調試智能體等等。這些智能體通過 Action 和環境進行交互執行各自的任務，同時它們也能夠接受來自于環境的反饋進行不斷地學習和改進。這種多智能體的架構使得通義靈碼 AI 程序員能夠處理復雜的軟件開發任務，從方案設計到代碼調試，全面覆蓋了開發流程的各個環節。

此外，考慮到現實軟件開發流程中的復雜性，現實軟件開發流程也包括需求分析、系統設計、軟件開發和軟件測試，而且還涉及到開發者自己的思考以及開發者和外部工具的使用，以及不同職能的人之間的交流，這樣一個流程也需要更復雜的一個軟件開發大模型。

我們看現有的代碼大模型，它是在預訓練語言模型基礎上增加了比如說Github 的靜態代碼和文檔數據、網頁代碼問答數據等等，進行了持續地預訓練，形成代碼預訓練模型，同時針對于代碼生成的一些任務，比如說代碼的指令生成數據、注釋、單測等多任務指令、通用問答指令等等數據來進行有監督地微調，進一步地針對代碼的相關任務偏好數據進行對齊，最后生成代碼對齊模型。

這些代碼對齊模型由于缺乏解決實際軟件過程中需要的推理過程數據，所以難以應用到真實的端到端的軟件工程的任務中來，比如說它缺乏解決問題所需要的一個過程數據，比如說針對用戶需求的一個規劃、反思，也缺乏和外部工具的交互的數據，比如說和編譯器的交互和執行器的交互等等。

在此基礎上，我們就提出了面向軟件工程的數據合成的思路，來訓練面向軟件工程的代碼模型，這個過程不僅能夠學習問題和答案之間的映射，更關注學習如何解決問題的過程。

過程數據合成主要包括三個階段，現實軟件工程的理解、故障的定位，包括邊界點的定位以及代碼的生成這三個部分，每個部分通過React 的形式合成解決過程的數據來改進現有模型在實際軟件開發中的應用。

具體來說，倉庫理解階段旨在分析和理解軟件倉庫的結構、文件和相關代碼，形成相應的分析和規劃，為后續步驟提供基礎。而故障定位階段，通過自主調動搜索工具、迭代細化搜索結果并定位引發Issue 的潛在代碼位置，而基于這些故障的位置和數據合成鏈路，可以在補丁生成的階段生成可以直接應用的代碼補丁，交給用戶審查和確認。

我們可以看到上述整個過程，在倉庫環境下，通過React 的形式合成了解決過程的數據，這種方法能夠改進現有模型在實際開發過程中的應用，使得 AI 系統不僅能夠給出答案，還能夠模擬軟件工程師解決問題的思路。

基于這種軟件工程的過程數據合成方法，我們訓練了Lingma-SWEGPT 軟件工程大模型，這個模型旨在解決需要復雜推理的軟件工程任務。Lingma-SWEGPT 接收真實的 Github Issues 和 Reports 作為輸入，通過倉庫理解、故障定位和補丁生成這三個階段，最終輸出了提交的補丁。該模型采用迭代訓練的方法，利用合成數據不斷地優化，模型在每個階段都用了 Chain-of-Thought 推理和觀察行動循環，實現了從問題到解決方案的全流程智能化。

同時通過整合倉庫的導航、精確的搜索這樣的工具，以及使用的 Git 的相關命令和 Pylint 等代碼質量檢查工具，模型能夠處理越來越復雜的軟件工程問題，并且在每個階段生成中間結果，也供進一步地分析和改進，最終模型生成的補丁由人工進行審查和確認，確保其正確性和實用性。

這種端到端的智能化的流程，使得Lingma-SWEGPT 在復雜軟件工程任務中表現出色，能夠模擬專業開發者解決問題的過程，為軟件開發和維護提供強大的 AI 輔助能力。

我們舉一個例子，比如說在單元測試的生成場景中，通義靈碼Test Agent 會在識別到生成單元測試需求之后開始分析你的項目環境，逐一檢查生成單元測試所必要的依賴項是否通過，在前置依賴項檢查通過之后，Test Agent 會列出生成單測計劃待用戶確認，用戶確認之后，Test Agent 會開始按照計劃為每個測試函數開始生成單元測試的代碼，并自動修復其中存在的錯誤，在生成和修復完成之后，Test Agent 會合并生成好的單元測試用例，將合并后的文件作為呈現給用戶的最終結果。

基于用戶的代碼倉庫對用戶的問題進行分析之后，我們可以看到多文件生成也使用了類似的框架，首先，它需要定位需要修改的一個或多個文件代碼或片段，再次，它會給出整體的修改說明，這樣的目的是使得用戶的交互更加友好。第三，生成每個文件的具體代碼修改方案，主要是因為要緩解模型生成速度的慢的問題，不是生成全部的修改代碼，而只是修改方案中僅包括被修改的部分。第四步是根據修改的方案能夠快速生成完整的修改后的代碼文件，這樣的話工程根據修改前后的代碼文件進行渲染，生成Diff 的可視化效果，給用戶友好的交互體驗。

我們下一步來展望一下未來的代碼大模型的發展，首先根據SWE-bench 的這個結果我們來看，在過去一年多以來，這個結果的數據集的評分從?0.4 快速上升到 71.7，它的解決率的速度遠遠超過我們的想象，我們來看代碼的數據其實儲備非常豐富，從第一天開始就是數字化的數據，此外代碼的流行的過程本身就是一個思維鏈的過程，它就是一個解決問題的方法、步驟和過程，這樣的話我們的大模型的推理能力、思維鏈能力，在代碼任務上能夠得到很好地體現和應用。此外代碼本身也有很好的環境交互，比如說編譯器、執行器等等都可以用來判斷代碼的正確性。

所以綜合來看的話，代碼的智能開發很有可能是AGI 最先突破的方向，我們也在業界看到了在這個方向的廣泛地應用和落地，以及大量的產品，如果我們看 Gartner 對于不同技術的發展趨勢來看，我們可以看到，基于 AI 的智能代碼目前正處在發展的頂峰階段，我們可以預見現在和今后未來很近的時間內，基于 AI 的代碼輔助和智能軟件工程的模型和產品會得到巨大的爆發和發展，我們也要積極擁抱人機共生的軟件工程的新的范式。

最后我們來總結，以智能體為核心的AI Agent 將成為用戶和編程過程之間的智能中介，它不僅能夠通過觀察，學習到大模型處理和執行操作來完成更為復雜的編程任務，更重要的是，這個系統能夠持續學習和進化，通過數據飛輪不斷地改進自身的能力。

未來我們期待看到更加智能的、自主的編程助手，它不僅能夠被動地解決現有的編程需求，還能夠持續學習、主動發現并解決可能存在的問題，極大地提升編程的效率和代碼質量。更進一步，以自然語言為交互，它可以讓更多不具備代碼開發能力的泛編程人員通過自然語言和多框架的編程模式，能夠靈活地開發更多的、更個性化的代碼或者是Task 引擎，在廣泛的場景中得到應用。