AI News

自主代理與軟體工程的未來 (Autonomous Agents and the Future of Software Engineering)

在自主 AI(Autonomous AI)能力的一次重大演示中,Anthropic 研究人員成功利用一個由 16 個並行 AI 代理組成的團隊,從零開始構建了一個功能齊全的 C 編譯器。使用新發佈的 Claude Opus 4.6 模型,這次實驗標誌著從傳統的「AI 作為編碼助手」範式向「AI 作為開發團隊」新時代的轉變。該項目最終產生了一個包含 100,000 行代碼、基於 Rust 的編譯器,能夠編譯 Linux 6.9 內核(Kernel),為多代理軟體工程的潛力——以及目前的局限性——提供了切實的窺見。

這項實驗由 Anthropic 研究員 Nicholas Carlini 領導,旨在對 Opus 4.6 模型的「代理團隊(Agent Teams)」能力進行壓力測試。與需要人類不斷提示的標準編碼助手不同,這些代理在近 2,000 個執行會話中自主運行。它們認領任務、編寫代碼、運行測試,並在極少的人類干預下針對失敗進行迭代,API 使用成本約為 20,000 美元。

實驗:從零開始構建編譯器

目標非常宏大:用 Rust 創建一個 C 編譯器,能夠成功為 x86、ARM 和 RISC-V 架構編譯 Linux 6.9 內核。這項任務需要高精度的邏輯、對系統架構的深刻理解以及對標準的嚴格遵守——這些領域正是大語言模型(Large Language Models,LLMs)在長期任務中歷來難以保持一致性的地方。

研究團隊部署了 16 個 Claude Opus 4.6 代理並行工作。為了管理這支分散式勞動力,他們設計了一個協作環境,代理在獨立的 Docker 容器中運行。該系統利用鎖文件(lock-file)機制進行任務認領,並使用 Git 進行版本控制,模擬了初步的人類開發團隊工作流。

關鍵項目指標

指標 數值 描述
使用的模型 Claude Opus 4.6 Anthropic 最新推出的專為長程任務設計的前沿模型
團隊規模 16 個並行代理 同時工作的自主實例
總會話數 ~2,000 自主執行循環次數
總成本 ~$20,000 整個項目的預計 API 成本
代碼量 ~100,000 行 最終生成的基於 Rust 的編譯器大小
成功標準 Linux 6.9 內核 成功編譯出適用於 x86、ARM、RISC-V 的可啟動內核

工程自主化:驗證即控制

這次實驗的一個關鍵見解是控制機制的轉變。在傳統的 軟體開發(software development) 中,人類經理協調任務並審核代碼。在這種代理工作流中,驗證成為了主要的控制平面(control plane)。代理高度依賴強大的測試套件和「已知良好的預言機(known-good oracles)」來驗證其進度。

當代理遇到瓶頸時——例如編譯整個 Linux 內核的巨大複雜性——系統利用了差異測試(differential testing)策略。通過將其編譯器的輸出與已建立的 GCC 編譯器(作為預言機)進行比較,代理可以隔離差異並自我修正。這種「分解(decomposition)」策略允許代理將內核編譯的龐大任務拆分為更小的、可驗證的單元,從而在無需人類不斷引導的情況下實現持續的並行執行。

代理團隊的能力與「真相」

成功編譯 Linux 內核,以及 QEMU、FFmpeg、SQLite 和 Redis 等其他複雜開源項目,突顯了自主 AI 現狀的多個「真相」:

  • 持續執行是可能的: 通過適當的腳手架,AI 代理可以維持上下文並在數週(而非僅僅數分鐘)內推動進度。系統將狀態外部化到代碼庫和構建日誌中,允許代理持續接手工作。
  • 並行需要獨立性: 當任務可以解耦時,代理的表現最為出色。使用標準協議(如鎖文件)允許它們同時工作,儘管它們經常遇到合併衝突——這在軟體工程中是一個非常人性化的問題。
  • 無塵環境實現: 編譯器在開發過程中沒有直接訪問互聯網,完全依賴 Rust 標準庫和模型的訓練數據,展示了模型對編譯器理論和 C 語義的內化知識。

「挑戰」:局限性與工程現實

儘管取得了顯著成功,該項目也揭示了定義未來發展「挑戰(The Dare)」的重大局限性。產出的代碼雖然功能齊全,但並非商業上可行的代碼。

  • 效率與優化: 生成的代碼效率明顯低下。即使開啟了優化,AI 產出的編譯器輸出也比關閉優化的 GCC 輸出更慢。代理將正確性(通過測試)置於性能之上。
  • 架構差距: 代理在系統組件的「最後一英里」中遇到了困難。它們未能實現啟動 Linux 所需的 16 位元 x86 後端,因此在該特定組件上不得不回退到 GCC。同樣地,彙編器和連結器組件也存在錯誤且不完整。
  • 人類權威: 「自主性」是有邊界的。人類研究人員仍需定義架構、設定範圍,並在代理陷入死胡同時(如 16 位元編譯器問題)進行干預。高層次的系統設計仍然是人類專屬的責任。

分析轉變:從助手到隊友

這次實驗代表了我們看待軟體開發生命週期(Software Development Life Cycle,SDLC)中 AI 方式的根本轉變。我們正在從 AI 實時提供建議的「副駕駛(copilot)」模式,轉向 AI 被分配任務工單並帶著完成的合併請求返回的「代理」模式。

AI 開發模式對比

特性 副駕駛 / 助手模式 代理團隊模式
交互方式 同步(人類在環) 異步(人類在環上)
範圍 函數/片段級別 模組/項目級別
上下文 當前文件/打開的標籤頁 完整倉庫與構建日誌
控制 逐行的人類審查 自動化測試與 CI/CD 流水線
主要瓶頸 人類的注意跨度 測試套件質量與任務分解

未來之路

對於開發者和首席技術官(CTO)來說,其影響是明確但微妙的。完全取代人類開發者的技術尚不存在;代理構建的編譯器中缺乏架構遠見和優化能力證明了這一點。然而,將「苦差事(toil)」——即定義良好的規格說明書的重複實現——外包出去正成為現實。

Anthropic 實驗的成功很大程度上取決於驗證工程(validation engineering)。代理的有效性完全取決於引導它們的測試。這表明高級軟體工程師未來的角色將越來越多地集中在設計這些「馬具」上——即允許自主代理安全地承擔繁重工作的架構邊界、測試套件和成功標準。

正如 The Futurum Group 的分析師所指出的,雖然這些結果是基於模型創作者內部的「無塵室」實驗,但它們為工業規模的代理 AI 建立了概念驗證。現在的挑戰已從「AI 能寫代碼嗎?」轉向「我們能否設計出讓 AI 安全寫代碼的系統?」

自主軟體代理的時代尚未完全到來,但隨著 Linux 內核的成功編譯,它無疑已經完成了引導啟動。

精選