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

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

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

我們首先回顧軟件工程的發(fā)展歷史。1960年代中期，軟件開發(fā)進(jìn)入危機(jī)時代，因?yàn)槟莻€時候軟件開發(fā)并沒有固定的方法可循，整個的軟件設(shè)計(jì)是在開發(fā)人員頭腦中完成了一個隱藏的過程，而且軟件維護(hù)的成本居高不下，產(chǎn)品質(zhì)量也比較低。

1968年以來通過 NATO 會議，正式提出了軟件工程這樣一個術(shù)語，人們提出了結(jié)構(gòu)化的開發(fā)方法，也包括瀑布式的軟件生命周期流程，軟件測試和驗(yàn)證成為軟件開發(fā)的重要環(huán)節(jié)。

1983年 C++ 正式發(fā)布以來，推動了面向?qū)ο蟮某绦蛟O(shè)計(jì)方法，面向?qū)ο蟪绦蛟O(shè)計(jì)方法意味著對象的編程、軟件開發(fā)的工具都得到了改進(jìn)，包括軟件開發(fā)的環(huán)境 IDE 和版本控制的工具也得到了廣泛的使用。同時也有一些 ISO9000、SPICE 等質(zhì)量標(biāo)準(zhǔn)體系的形成，確保軟件工程的開發(fā)滿足標(biāo)準(zhǔn)化的流程。

在90 年代末，進(jìn)入互聯(lián)網(wǎng)時代，由于軟件的快速發(fā)展催生了敏捷開發(fā)的革命，需要更緊密的團(tuán)隊(duì)協(xié)作，需要不同團(tuán)隊(duì)之間有效地應(yīng)對不同需求的變化，需要軟件的持續(xù)構(gòu)建、持續(xù)集成、持續(xù)迭代和持續(xù)交付。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

它具備多項(xiàng)能力，比如說用戶需求的分析、計(jì)劃的制定、完整分析被測函數(shù)中的代碼依賴、使用工具與 code base 進(jìn)行交互，比如說搜索的工具、編輯器工具等，結(jié)合編譯器、執(zhí)行器的環(huán)境反饋完成單元測試的生成和 bug 的修復(fù)。

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

智能體的部分是系統(tǒng)的核心，這里由 5 個專門的 AI 智能體組成，包括規(guī)劃智能體、搜索、生成、單測、調(diào)試智能體等等。這些智能體通過 Action 和環(huán)境進(jìn)行交互執(zhí)行各自的任務(wù)，同時它們也能夠接受來自于環(huán)境的反饋進(jìn)行不斷地學(xué)習(xí)和改進(jìn)。這種多智能體的架構(gòu)使得通義靈碼 AI 程序員能夠處理復(fù)雜的軟件開發(fā)任務(wù)，從方案設(shè)計(jì)到代碼調(diào)試，全面覆蓋了開發(fā)流程的各個環(huán)節(jié)。

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

我們看現(xiàn)有的代碼大模型，它是在預(yù)訓(xùn)練語言模型基礎(chǔ)上增加了比如說Github 的靜態(tài)代碼和文檔數(shù)據(jù)、網(wǎng)頁代碼問答數(shù)據(jù)等等，進(jìn)行了持續(xù)地預(yù)訓(xùn)練，形成代碼預(yù)訓(xùn)練模型，同時針對于代碼生成的一些任務(wù)，比如說代碼的指令生成數(shù)據(jù)、注釋、單測等多任務(wù)指令、通用問答指令等等數(shù)據(jù)來進(jìn)行有監(jiān)督地微調(diào)，進(jìn)一步地針對代碼的相關(guān)任務(wù)偏好數(shù)據(jù)進(jìn)行對齊，最后生成代碼對齊模型。

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

在此基礎(chǔ)上，我們就提出了面向軟件工程的數(shù)據(jù)合成的思路，來訓(xùn)練面向軟件工程的代碼模型，這個過程不僅能夠?qū)W習(xí)問題和答案之間的映射，更關(guān)注學(xué)習(xí)如何解決問題的過程。

過程數(shù)據(jù)合成主要包括三個階段，現(xiàn)實(shí)軟件工程的理解、故障的定位，包括邊界點(diǎn)的定位以及代碼的生成這三個部分，每個部分通過React 的形式合成解決過程的數(shù)據(jù)來改進(jìn)現(xiàn)有模型在實(shí)際軟件開發(fā)中的應(yīng)用。

具體來說，倉庫理解階段旨在分析和理解軟件倉庫的結(jié)構(gòu)、文件和相關(guān)代碼，形成相應(yīng)的分析和規(guī)劃，為后續(xù)步驟提供基礎(chǔ)。而故障定位階段，通過自主調(diào)動搜索工具、迭代細(xì)化搜索結(jié)果并定位引發(fā)Issue 的潛在代碼位置，而基于這些故障的位置和數(shù)據(jù)合成鏈路，可以在補(bǔ)丁生成的階段生成可以直接應(yīng)用的代碼補(bǔ)丁，交給用戶審查和確認(rèn)。

我們可以看到上述整個過程，在倉庫環(huán)境下，通過React 的形式合成了解決過程的數(shù)據(jù)，這種方法能夠改進(jìn)現(xiàn)有模型在實(shí)際開發(fā)過程中的應(yīng)用，使得 AI 系統(tǒng)不僅能夠給出答案，還能夠模擬軟件工程師解決問題的思路。

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

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

這種端到端的智能化的流程，使得Lingma-SWEGPT 在復(fù)雜軟件工程任務(wù)中表現(xiàn)出色，能夠模擬專業(yè)開發(fā)者解決問題的過程，為軟件開發(fā)和維護(hù)提供強(qiáng)大的 AI 輔助能力。

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

基于用戶的代碼倉庫對用戶的問題進(jìn)行分析之后，我們可以看到多文件生成也使用了類似的框架，首先，它需要定位需要修改的一個或多個文件代碼或片段，再次，它會給出整體的修改說明，這樣的目的是使得用戶的交互更加友好。第三，生成每個文件的具體代碼修改方案，主要是因?yàn)橐徑饽Ｐ蜕伤俣鹊穆膯栴}，不是生成全部的修改代碼，而只是修改方案中僅包括被修改的部分。第四步是根據(jù)修改的方案能夠快速生成完整的修改后的代碼文件，這樣的話工程根據(jù)修改前后的代碼文件進(jìn)行渲染，生成Diff 的可視化效果，給用戶友好的交互體驗(yàn)。

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

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

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

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