從編碼、編譯到除錯、驗證，AI 智慧體能做的事情更多了。
這週三，Cognition AI 團隊釋出的首個 AI 軟體工程師 Devin 引爆了 AI 社群，引發了人們對程式設計師這個職業未來前景的熱議。
在對 Devin 的評估中，團隊使用了 SWE-bench。這是一個由 GitHub 問題和拉取請求組成的軟體工程系統的自動化基準測試。他們認為 SWE-bench 是一個不錯的選擇，它確定性地評估（透過單元測試）系統解決現實世界程式碼庫問題的能力，並與 HumanEval 等僅限於獨立功能的基準測試不同。
從結果來看，在 SWE-Bench 基礎測試中，無需人類輔助，Devin 就可以解決 13.86% 的問題。而當前 SOTA 模型，在沒有人類幫忙的情況下，只能完成 1.96% 的問題。即使提供了要編輯（輔助）的確切檔案，當前 SOTA 模型也只能解決 4.80% 的問題。
資料集
具體來講，SWE-bench 是一個包含 2294 個問題和 GitHub 流行開源 Python 儲存庫中拉取請求（pull request）的資料集，目的是測試系統編寫真實程式碼的能力。
每個 SWE-bench 例項都包含一個 GitHub 問題和解決該問題的拉取請求。拉取請求必須包含一個單元測試，該測試在程式碼更改之前失效並在程式碼更改之後透過（稱為「未能透過」（fail to pass）測試）。diff 分為兩部分，即 patch 和 test_patch，分別包含程式碼更改和測試更改。
接著要求正在評估的系統根據 GitHub 問題描述和儲存庫（問題發生時）生成 diff。如果在修補（patch）編輯後所有單元測試都透過，則該示例被認為是成功的。
在 SWE-bench 中，大模型（LLM）要麼獲得一組正確的檔案進行編輯（輔助）或者一個單獨的系統根據與問題文字的相似性檢索要編輯的檔案（無輔助）。作為一個智慧體，Devin 不會收到任何檔案列表，而是自行導航檔案，這與「無輔助」LLM 更具可比性。
正確解決 SWE-bench 示例具有挑戰性，更難的 PR 需要更改數十個檔案、保持向後相容性和 / 或進行大量複雜的推理。即使有輔助，最好的 LLM 也只能達到 4.80% 的成功率。
方法
團隊採用 SWE-bench 來評估智慧體，實現了比 LLM 原始評估更通用的設定。
設定
團隊使用標準化 prompt 來端到端地執行智慧體，要求它僅在給出 GitHub 問題描述的情況下編輯程式碼。在執行期間，團隊不會向智慧體提供任何其他使用者輸入。
儲存庫被克隆到智慧體的環境中。團隊只在 git 歷史記錄中保留 base commit 及其 ancestor，以防止資訊洩露給智慧體。值得注意的是，他們刪除了 git Remote，以便 git pull 不起作用。
團隊在測試開始前搭建了 Python conda 環境。
團隊將 Devin 的執行時間限制為 45 分鐘，因為與大多數智慧體不同，它具有無限期執行的能力。如果需要，它可以選擇提前終止。
評估
一旦智慧體執行退出，團隊會將所有測試檔案重置為原始狀態，以防智慧體修改測試。他們獲取檔案系統中的所有其他 diffs 並將它們提取為補丁。
為了確定哪些檔案是測試檔案，團隊採用測試補丁中修改的所有檔案的集合。
團隊將智慧體的補丁應用到儲存庫，然後應用測試補丁。
團隊執行 SWE-bench 提供的 eval 命令並檢查是否所有測試都透過。
結果
團隊隨機選擇了 SWE 基準測試集中 25% 的問題（即 2294 箇中的 570 個），對 Devin 進行了評估。這樣做是為了減少完成基準測試所需的時間。
結果顯示，Devin 成功解決了 570 個問題中的 79 個問題，成功率為 13.86%。這甚至比之前 SOTA 大模型（Claude 2）的 4.80% 還要高得多。
下圖中的基線在「輔助」設定下進行評估，其中為模型提供需要編輯的確切檔案。基線在「無輔助」設定下表現較差，其中單獨的檢索系統選擇 LLM 編輯的檔案，最佳的模型是 Claude 2 + BM25 檢索，成功率為 1.96%。
不過團隊表示，輔助或無輔助設定下，其他模型都不能與 Devin 進行嚴格比較。Devin 獲得整個儲存庫並可以自由瀏覽檔案，因此他們選擇更強的數字進行基線比較。團隊認為，端到端執行智慧體對於 SWE-bench 來說是更自然的設定，這樣更類似於現實世界的軟體開發。
分析
多步規劃
Devin 可以執行多步規劃來接收來自環境的反饋。72% 的透過測試需要 10 分鐘以上才能完成，這表明迭代能力有助於 Devin 取得成功。
定性案例
團隊對 Devin 的進行了一些定性分析。這裡 Devin 僅獲得了問題描述和克隆儲存庫作為輸入。
示例 1：✅ scikit-learn__scikit-learn-10870
Devin 最初對描述感到困惑，並按照描述在 return self 之前新增 self.lower_bound_ = max_lower_bound before return self 。這實際上不正確，因為該變數尚未定義。
隨後，Devin 根據問題描述中提供的測試程式碼，更新了測試檔案。
在執行測試並收到錯誤後，Devin 更正了該檔案。
修復後，Devin 重新執行測試以使其透過併成功退出。
這個例子很有趣，主要有幾個原因：
Devin 非常嚴格地遵循原始問題的指示，儘管不準確。這表明與使用者的偏好過度一致。
得益於能夠在自身環境中執行測試，Devin 能夠糾正錯誤。對於軟體開發人員來說，能夠進行迭代至關重要，智慧體也應該能夠做到這一點。
示例 2：✅ django__django-10973
Devin 找到了正確的檔案 django/db/backends/postgresql/client.py，並進行了完整的編輯：
在這裡，Devin 能夠成功修改一大段程式碼。在 SWE-bench 中，許多成功的編輯都是單行 diff，但 Devin 卻能同時處理多行。
示例 3：❌sympy__sympy-17313
這是一個複雜的任務，涉及修改計算機代數系統以正確處理 floor 和 ceiling 物件與可以指定為正或負的值之間的比較運算子。它需要複雜的邏輯推理和多個推導步驟。
Devin 錯選了要編輯的正確類，他編輯的是 frac 類，而不是 floor 類和 ceiling 類。此外，Devin 只編輯了一個比較運算子 __gt__，而 __lt、le__ 和__ge__也需要修改。這次的編輯錯的很離譜。
正確的diff可以在這裡找到：https://github.com/sympy/sympy/pull/17313/files。diff 相當複雜，包含大量邊緣情況處理和大量單元測試，需要深入瞭解 sympy 程式碼庫。(需要注意的是，每個測試都必須透過才能透過 SWE-bench 例項）。
示例 4:❌ scikit-learn__scikit-learn-10774
這項任務包括為 repo 中的所有資料集新增額外的返回選項功能。Devin 成功地對其中幾個資料集進行了編輯，示例如下。
Devin 對資料集 california_housing.py、covtype.py、kddcup99.py 和 mldata.py （最初的 PR 實際上排除了這些資料集）進行了類似的編輯。不過，Devin 漏掉了兩個資料集，即 lfw.py 和 rcv1.py，因此測試最終失敗。團隊打算改進 Devin 編輯多個檔案的功能。
測試驅動實驗
團隊還進行了一項實驗，向 Devin 提供了最終的單元測試和問題陳述。在這種測試驅動開發設定下，100 個抽樣測試的成功透過率提高到了 23%。(請注意，對測試本身的任何修改都會在評估前被刪除）
這一結果與 SWE-bench 的其他結果無法相比，因為智慧體可以訪問真實的測試補丁。不過，測試驅動開發是軟體工程中的一種常見模式，因此這種設定是 SWE-bench 的自然擴充套件。人類向智慧體提供一個需要透過的目標測試是人類工程師和智慧體合作的一種自然方式，團隊期待在未來看到更多測試驅動的智慧體。
Devin 新近透過測試解決的問題示例
✅django__django-13321：Devin 在函式前新增了列印語句，然後執行單元測試，最後根據列印語句編輯檔案，從而解決了這個問題。測試用例的存在使 Devin 能夠輕鬆地進行除錯。
✅django_django-16983：新單元測試斷言會發出 queqie 的錯誤訊息："'filter_horizontal [0]' 的值不能包括 [...]"。如果不知道錯誤資訊的確切措辭，就不可能透過測試。這突顯了基準測試的一個問題，並表明如果沒有測試補丁，就不可能得到完美的分數。
完整報告地址：https://www.cognition-labs.com/post/swe-bench-technical-report
類 Devin 專案
與此同時，Devin 釋出後幾天，社群已經出現「復刻版」。推特使用者 @antonosika 使用 GPT 和一些開源專案對 Devin 進行復刻，他表示無需程式碼即可製作 Devin。
具體工作流如下所示：
獲取 Devin 應用介面的截圖；
利用 gptengineer 應用程式與前端介面和 GitHub 程式碼空間結合；
克隆 Open Devin 並使用 gptme 作為後端；
利用 gptme 的命令列介面（CLI）來連線前後端，從而構建一個完整的應用程式。
完整影片如下：
此外還有 BabelCloud，它也是一個類似於 Devin 的 AI 軟體工程師，能夠獨立完成相對複雜的前後端任務。
技術部落格：https://medium.com/@connect_33559/how-far-from-replacing-humans-ai-programmer-build-complex-software-after-3-hours-of-working-1b61b18a0c0b
完整影片如下所示：
從部落格和影片中可以看到，該專案可以使用 Babel Agent 進行工程軟體開發，比如測試 Claude 3 的可用性、編寫後端管理系統、整合 Stripe 支付系統等。Babel Agent 的具體功能包括如下：
自主任務分解。Babel Agent 可以根據需求文件自主設計和分解任務，並逐一執行。
自主編碼、編譯和除錯。Babel Agent 不僅可以自主編寫、編譯程式碼，還可以根據編譯中的問題反饋自主除錯，就像人類程式設計師的工作流程一樣。
獨立問題的自主研究。當任務是整合 Claude 3 時，Babel Agent 會自主搜尋 SDK，找到文件，編寫程式碼，然後對其進行測試和驗證。
自主測試。Babel Agent 可以編寫自動化測試程式碼、執行測試並自行糾正問題。
尋求人類幫助。當遇到不明確的要求或沒有提供必要的資訊時，Babel Agent 會尋求人工幫助。此外在嘗試不同方法後無法完成任務時，它也會做同樣的事情。
迭代開發。Babel Agent 支援對需求的迭代更改和對線上問題的自主糾正。
未來，AI 智慧體在程式設計行業還會掀起怎樣的變革，我們拭目以待。