自主代理與軟體工程的未來 (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 內核的成功編譯，它無疑已經完成了引導啟動。
