點選上方↑↑↑「OpenCV學堂」關註我
來源：公眾號 新智元授權
【導讀】 全球第一個AI程式設計師Devin誕生之後，讓碼農紛紛恐慌。沒想到，微軟同時也整出了一個AI程式設計師——AutoDev，能夠自主生成、執行程式碼等任務。網友驚呼，AI編碼發展太快了。
全球第一個AI程式設計師Devin的橫空出世，可能成為軟體和AI發展史上一個重要的節點。
它掌握了全棧的技能，不僅可以寫程式碼debug，訓模型，還可以去美國最大求職網站Upwork上搶單。
一時間，網友們驚呼，「程式設計師不存在了」？
甚至連剛開始攻讀電腦學位的人也恐慌，「10倍AI工程師」對未來的工作影響。
除了Cognition AI這種明星初創公司，美國的各個大廠也早就在想辦法用AI智慧體降本增效了。
就在3月14日同一天，微軟團隊也釋出了一個「微軟AI程式設計師」——AutoDev。
論文地址：https://arxiv.org/pdf/2403.08299.pdf
與Devin這種極致追求效率和產出結果的方向有所不同。
AutoDev專為自主規劃、執行復雜的軟體工程任務而設計，還能維護Docker環境中的私密和安全。
在此之前，微軟已有主打產品GitHub Copilot，幫助開發人員完成軟體開發。
然而，包括GitHub Copilot在內的一些AI工具，並沒有充分利用IDE中所有的潛在功能，比如構建、測試、執行程式碼、git操作等。
基於聊天界面的要求，它們主要側重於建議程式碼片段，以及檔操作。
AutoDev的誕生，就是為了填補這一空白。
使用者可以定義復雜的軟體工程目標，AutoDev會將這些目標分配給自主AI智慧體來實作。
然後，這些AI智慧體可以對程式碼庫執行各種操作，包括檔編輯、檢索、構建過程、執行、測試和git操作。
甚至，它們還能存取檔、編譯器輸出、構建和測試日誌、靜態分析工具等。
在HumanEval測試中，AutoDev分別在程式碼生成和測試生成方面，分別取得了91.5%和87.8% Pass@1的優秀結果。
網友表示，AI編碼發展太快了，2021年GitHub Copilot能解決28.8%的HumanEval問題，到了2024年，AutoDev直接解決了91.5%的問題。
不用人類插手，AutoDev自主完成任務
AutoDev工作流程如下圖所示，使用者定義一個目標，比如「測試特定方法」。
AI智慧體將測試寫入一個新檔，並啟動測試執行命令，以上都在安全的評估環境中進行。
然後，測試執行的輸出（包括失敗日誌）將合並到對話中。
AI智慧體分析這些輸出，觸發檢索命令，透過編輯檔合並檢索到的資訊，然後重新啟動測試執行。
最後，Eval環境提供有關測試執行是否成功，以及使用者目標完成情況的反饋。
整個過程由AutoDev自主協調，除了設定初始目標之外，無需要開發人員幹預。
相比之下，如果現有的AI編碼助手整合到IDE 中，開發人員必須手動執行測試（比如執行pytest）、向AI聊天界面提供失敗日誌、可能需要辨識要合並的其他上下文資訊，並重復驗證操作確保AI生成修改後的程式碼後測試成功。
值得一提的是，AutoDev從以前許多在AI智慧體領域的研究中汲取了靈感，比如AutoGen——編排語言模型工作流並推進多個智慧體之間的對話。
AutoDev的能力超越了對話管理，使智慧體能夠直接與程式碼儲存庫互動，自動執行命令和操作，從而擴充套件了 AutoGen。
同樣，AutoDev的研究也借鑒了Auto-GPT。這是一種用於自主任務執行的開源AI智慧體，透過提供程式碼和IDE特定功能來支持執行復雜的軟體工程任務。
AutoDev構架
上圖是AutoDev架構的簡單示意圖。
AutoDev主要由4個功能模組組成：
-用於跟蹤和管理使用者與代理對話的對話管理器（Conversation Manager）；
-為代理提供各種程式碼和整合式開發環境相關工具的工具庫（Tools library）；
-用於排程各種代理的代理排程器（Agents Scheduler）；
-以及用於執行操作的評估環境（Evaluation Environment）。
下面就給大家詳細介紹每種功能模組。
規則、行動和目標配置
使用者透過yaml檔配置規則和操作來啟動流程。
這些檔定義了AI代理可以執行的可用命令（操作）。
使用者可以透過啟用/禁用特定命令來利用預設設定或細粒度許可權，從而根據自己的特定需求量身客製AutoDev。
配置步驟目的是實作對AI代理能力的精確控制。
在這一階段，使用者可以定義人工智慧代理的數量和行為，分配特定的責任、許可權和可用操作。
例如，使用者可以定義一個 「開發者 」代理和一個 「稽核者 」代理，讓它們協同工作以實作目標。
根據規則和操作配置，使用者可以指定AutoDev要完成的軟體工程任務或流程。
例如，使用者可以要求生成測試用例，並確保其語法正確、不包含錯誤（這涉及編輯檔、執行測試套件、執行語法檢查和錯誤尋找工具）。
對話管理器（conversation manager）
會話管理器負責初始化會話歷史，在對正在進行的會話進行高級管理方面發揮著關鍵作用。它負責決定何時中斷對話行程，並確保使用者、人工智慧代理和整個系統之間的無縫交流。
它維護和管理的對話物件，主要包括來自代理的資訊和來自評估環境（eval environment）的操作結果。
解析器
解析器解釋代理生成的響應，以預定格式提取指令和參數。它能確保指令格式正確，驗證參數的數量和準確性（例如，檔編輯指令需要檔路徑參數）。
如果解析失敗，就會在對話中註入錯誤資訊，阻止對資源庫的進一步操作。
透過強制執行特定的代理許可權和進行額外的語意檢查，成功解析的命令會被進一步分析。
它能確保建議的操作符合使用者指定的細粒度許可權。
如果命令透過審查，對話管理器就會呼叫工具庫中的相應操作。
輸出組織器
輸出組織器模組主要負責處理從評估環境接收到的輸出。
它選擇關鍵資訊（如狀態或錯誤），有選擇地總結相關內容，並將結構良好的資訊添加到對話歷史記錄中。
這可確保使用者對AutoDev的操作和結果有一個清晰、有條理的記錄。
對話終止器
會話管理器決定何時結束會話。這可能發生在代理發出任務完成訊號（停止命令）、對話達到使用者定義的最大叠代次數/token、或在行程或評估環境中檢測到問題時。
AutoDev的全面設計確保了人工智慧驅動開發的系統性和可控性。
代理排程器（Multi-Agents）
代理排程器負責協調人工智慧代理，以實作使用者定義的目標。
配置了特定角色和可用命令集的代理協同執行，執行各種任務。排程器采用各種協作演算法，如迴圈、基於令牌或基於優先級的演算法，來決定代理參與對話的順序和方式。
具體來說，排程演算法包括但不限於以下幾種：
(i)迴圈協作，按順序呼叫每個代理，讓每個代理執行預定數量的操作；
(ii)基於令牌的協作，讓一個代理執行多個操作，直到它發出一個令牌，表示完成了分配的任務；
(iii)基於優先級的協作，按照代理的優先級順序啟動代理。代理排程器透過當前對話呼叫特定代理。
代理
由OpenAI GPT-4等大型語言模型（LLM）和為程式碼生成而最佳化的小型語言模型（SLM）組成的代理透過文本自然語言進行交流。
這些代理從代理排程器（Agent Scheduler）接收目標和對話歷史，並根據規則和行動配置指定的行動做出響應。每個代理都有其獨特的配置，有助於實作使用者目標的整體進展。
工具庫（Tools Library）
AutoDev中的工具庫提供了一系列命令，使代理能夠對資源庫執行各種操作。
這些命令旨在將復雜的操作、工具和實用程式封裝在簡單直觀的命令結構中。
例如，透過build和test <test_file>這樣的簡單命令，就能抽象出與構建和測試執行有關的復雜問題。
-檔編輯：該類別包含用於編輯檔（包括程式碼、配置和文件）的命令。
-該類別中的實用程式，如寫入、編輯、插入和刪除，提供了不同程度的精細度。
-代理可以執行從寫入整個檔到修改檔中特定行的各種操作。例如，命令 write <filepath> <start_line>-<end_line> <content> 允許代理用新內容積比重寫一系列行。
檢索：在這一類別中，檢索工具包括grep、find和ls等基本CLI工具，以及更復雜的基於嵌入的技術。
這些技術能讓代理尋找類似的程式碼片段，從而提高他們從程式碼庫中檢索相關資訊的能力。
例如，retrieve <content> 命令允許代理執行與所提供內容類似的基於嵌入的片段檢索。
-構建與執行：這類命令允許代理使用簡單直觀的命令毫不費力地編譯、構建和執行程式碼庫。底層構建命令的復雜性已被抽象化，從而簡化了評估環境基礎架構中的流程。這類命令的範例包括：構建、執行 <檔>。
-測試與驗證：這些命令使代理能夠透過執行單個測試用例、特定測試檔或整個測試套件來測試程式碼庫。代理可以執行這些操作，而無需依萊特定測試框架的底層命令。
這類工具還包括校驗工具，如篩選器和錯誤尋找工具。這類命令的例子包括：檢查語法正確性的 syntax <file> 和執行整個測試套件的 test。
-Git：使用者可以為Git操作配置細粒度許可權。包括送出、推播和合並等操作。例如，可以授予代理只執行本地送出的許可權，或者在必要時將更改推播到原始碼庫。
-通訊：代理可以呼叫一系列旨在促進與其他代理和/或使用者交流的命令。值得註意的是，talk命令可以發送自然語言資訊（不解釋為版本庫操作命令），ask命令用於請求使用者反饋，而stop命令可以中斷行程，表示目標已實作或代理無法繼續。
因此，AutoDev中的工具庫為人工智慧代理提供了一套多功能且易於使用的工具，使其能夠與程式碼庫進行互動，並在協作開發環境中進行有效交流。
評估環境（Eval Environment）
評估環境在Docker容器中執行，可以安全地執行檔編輯、檢索、構建、執行和測試命令。
它抽象了底層命令的復雜性，為代理提供了一個簡化的界面。評估環境會將標準輸出/錯誤返回給輸出組織器模組。
整合
使用者透過指定目標和相關設定啟動對話。
對話管理器初始化一個對話物件，整合來自人工智慧代理和評估環境的資訊。隨後，對話管理器將對話分派給負責協調人工智慧代理行動的代理排程器。
作為人工智慧代理，語言模型（大型或小型 LM）透過文本互動提出指令建議。
命令界麵包含多種功能，包括檔編輯、檢索、構建和執行、測試以及 Git 操作。對話管理器會對這些建議的命令進行解析，然後將其引導至評估環境，以便在程式碼庫中執行。
這些命令在評估環境的安全範圍內執行，並封裝在 Docker 容器中。
執行後，產生的操作將無縫整合到對話歷史中，為後續叠代做出貢獻。
這種叠代過程一直持續到代理認為任務完成、使用者幹預發生或達到最大叠代限制為止。
AutoDev 的設計確保了系統、安全地協調人工智慧代理，以自主和使用者控制的方式完成復雜的軟體工程任務。
實證 評估設計
在研究人員的實證評估中，評估了AutoDev在軟體工程任務中的能力和有效性，研究它是否能夠提升人工智慧模型的效能，而不僅僅是簡單的推理。
此外，研究人員還評估了AutoDev在步驟數、推理呼叫和token方面的成本。
主要是確定了三個實驗研究問題：
-𝑅 𝑄 1 : AutoDev 在程式碼生成任務中的效果如何？
-𝑅 𝑄 2 : AutoDev 在測試生成任務中的效果如何？
-𝑅 𝑄 3 : AutoDev 完成任務的效率如何？
𝑄 1 : AutoDev在程式碼生成任務中的效率如何？
研究人員使用Pass@k指標來衡量AutoDev的有效性，其中𝑘表示嘗試的次數。
成功解決的問題是指AutoDev生成的方法主體程式碼滿足所有人工編寫的測試。一次嘗試相當於一次完整的AutoDev對話，其中涉及多個推理呼叫和步驟。
這與其他方法（如直接呼叫 GPT-4）形成鮮明對比，後者通常只涉及一次推理呼叫。有關多次推理呼叫和步驟的細節將在𝑅 𝑄 3 中進一步探討。在本次評估中，研究人員設定𝑘 = 1，從而計算Pass@1，只考慮第一次嘗試的成功率。
𝑄 2：AutoDev在測試生成任務中的效果如何？
對於這個研究問題，研究人員修改了HumanEval數據集，來評估AutoDev在生成測試方面的能力。
研究人員考慮人工編寫的解決方案，並放棄所提供的人工編寫的測試。
他們指示AutoDev為重點方法生成測試用例，並根據測試成功率、重點方法的呼叫和測試覆蓋率對其進行評估。
研究人員報告Pass@1，如果測試透過並呼叫了焦點方法，則認為測試成功。
此外，研究人員還將AutoDev測試的覆蓋率與人工編寫的測試覆蓋率進行了比較。
𝑅 𝑄 3：AutoDev 完成任務的效率如何？
在本研究問題中，研究人員將調查AutoDev完成SE任務的效率。
研究人員分析了所需步驟或推理呼叫的數量、所使用命令的分布（如寫入、測試）以及對話中使用的token總數。
AutoDev設定
在本次評估中，AutoDev基於GPT-4模型（gpt-4-1106-preview）與一個代理保持一致的設定。
啟用的操作包括檔編輯、檢索和測試。
唯一可用的通訊命令是表示任務完成的stop命令。
其他命令，如詢問，都是禁用的，這就要求 AutoDev 在初始目標設定之外，在沒有人類反饋或幹預的情況下自主執行。
實驗結果
- AutoDev在程式碼生成任務中的效率如何？
表1顯示了，將AutoDev與兩種替代方法和零樣本基線進行了比較。
研究人員將AutoDev與語言代理樹搜尋（LATS）和Reflexion 進行了比較，這兩種方法是截至2024年3月HumanEval 排行榜上的兩種領先方法。
零樣本基線（GPT-4）的結果取自OpenAI GPT-4技術報告。
AutoDev Pass@1率為91.5%，在HumanEval排行榜上穩居第二。
值得註意的是，這個結果是在沒有額外訓練數據的情況下獲得的，這將AutoDev與LATS區分開來，後者達到了94.4%。
此外，AutoDev框架將GPT-4效能從67%提升至91.5%，相對提升了30%。
這些結果體現出，AutoDev有能力顯著提升大模型完成軟體工程任務方面的表現。
- AutoDev在測試生成任務中的效果如何？
AutoDev在針對測試生成任務修改的HumanEval數據集上，獲得了87.8% Pass@1分數，與使用相同GPT-4模型的基線相比，相對提高了17%。
AutoDev生成的正確測試（包含在Pass@1中）實作了99.3%的魯棒覆蓋率，與人工編寫的測試的99.4%覆蓋率相當。
- AutoDev完成任務的效率如何？
圖3顯示了，AutoDev在程式碼生成和測試生成任務中使用的命令累積數，其中考慮到問題1和問題2中每個HumanEval問題的平均評估命令數量。
對於程式碼生成，AutoDev平均執行5.5條命令，其中包括1.8條寫入操作、1.7條測試操作、0.92條停止操作（表示任務完成）、0.25條錯誤命令，以及最少的檢索（grep、find、cat）、語法檢查操作和通話通訊命令。
在「測試生成」任務中，命令的平均數量與「程式碼生成」任務一致。
不過，「測試生成」任務涉及的檢索操作更多，錯誤操作的發生率也更高，因此每次執行的平均命令總數為6.5條。
在前兩個問題中，為解決每個HumanEval問題而進行的AutoDev對話的平均長度分別為1656和1863個token。
這包括使用者的目標、來自AI智慧體的資訊和來自評估環境的響應。
相比之下，GPT-4（基線）的零樣本在每個任務中平均使用200個token（估計值）生成程式碼，使用373個token生成測試。
雖然AutoDev使用了更多的token，但大量token用於測試、驗證和解釋自己生成的程式碼，超出了基線方法的範圍。
最後，AutoDev會產生與協調人工智慧智慧體、管理對話以及在Docker環境中執行命令相關的執行成本。
接下來，一起看一下AutoDev如何執行測試生成任務。
開發者給到任務：設定生成遵循特定格式的pytest測試。
AutoDev智慧體啟動write-new命令，提供測試檔的檔路徑和內容。
隨後，AutoDev智慧體觸發測試操作，AutoDev在其安全的Docker環境中執行測試，並給出測試執行報告JSON。
然後，AutoDev開始自主執行：
AutoDev智慧體在pytest輸出中發現了一個錯誤，認識到需要進行修復，以使測試與函式的預期行為保持一致。
繼續如圖5所示，AutoDev智慧體發出寫入命令，指定檔路徑和行號範圍 (5-5)，以重寫錯誤的斷言語句。
隨後，AutoDev智慧體繼續執行測試，並測試成功。
從上面例子中看得出，AutoDev能夠自我評估生成的程式碼，並解決自身輸出中的錯誤。
此外，AutoDev可以幫助使用者深入了解智慧體的操作，並允許智慧體在任務期間進行交流。
隨著Devin、AutoDev等AI工程師的誕生，程式設計師們的工作可能會一大部份實作自動化。
參考資料：
https://www.reddit.com/r/singularity/comments/1bfolbj/autodev_automated_aidriven_development_microsoft/
