2 月上旬,Anthropic 工程部落格刊登 Safeguards 團隊研究員 Nicholas Carlini 的實驗:16 個 Claude Opus 4.6 代理平行工作,從零寫出約 10 萬行、以 Rust 實作的 C 編譯器 claudes-c-compiler,可在 x86、ARM 與 RISC-V 上編譯出可開機的 Linux 6.9 核心,也編譯了 QEMU、FFmpeg、SQLite 等大型專案。Ars Technica 與 The Register 隨後報導。
這件事的分量在於條件是 clean-room:Claude 沒有網路存取,只依賴 Rust 標準庫,Carlini 在搭好架構後幾乎不插手。這不是 demo,而是刻意把模型推到極限的能力基準:用有客觀驗證標準(能不能編譯、能不能開機)的大型工程題,看代理在哪裡崩潰。
數字說話:2,000 個工作階段、20 億輸入 token
整個專案跑了近 2,000 個 Claude Code 工作階段,歷時約兩週,成本近 2 萬美元——對應約 20 億個輸入 token 與 1.4 億個輸出 token。產出的 10 萬行程式碼在 GCC torture tests 等主要測試套件上達到約 99% 通過率,還能編譯並執行 Doom。
換句話說:2 萬美元買到能自舉 Linux 核心的編譯器初形——這是「代理能否在無人監督下完成大型軟體工程」最具體的公開資料點。
極簡編排:無窮 bash 迴圈與共享 git 倉庫
架構簡單得反直覺:一個無窮 bash 迴圈不斷重啟 Claude Code 工作階段,每個代理各跑在獨立 Docker 容器;所有代理共用一個 bare git 倉庫當 upstream,各自 clone、merge、push,並靠 current_tasks/ 目錄裡的 lock file 避免重複做工——merge 衝突經常發生,但代理會自己解決。
沒有總指揮 agent,每個 Claude 自行挑「下一個最顯眼的問題」去解;Carlini 另外指派專責角色:去重、加速、輸出效率、Rust 設計評審與文件各有代理。
人類的工作:打造近乎完美的測試
Carlini 的力氣幾乎全花在代理的「環境」而非程式碼上。他的原話很直白:驗證器若有缺陷,代理「會解決錯的問題」。因此他把測試做到近乎完美,並針對兩個模型限制設計:context pollution——代理極簡輸出、日誌 grep 友善;時間盲——確定性抽樣測試,讓代理可靠判斷是否讓事情變好。
當代理在 Linux 核心這種單體建置上卡住時,他把 GCC 當「已知良好的編譯器 oracle」,隔離出由 Claude 編譯器處理的檔案,讓平行除錯可行。關鍵是:與其設計更聰明的代理,不如設計讓平庸代理自我糾錯的回饋迴路。
限制清單:它還不是 GCC
Carlini 列出的限制一樣具體:
- 不支援 16-bit real-mode x86,核心開機階段的編譯委託給 GCC(ARM 與 RISC-V 則完全自舉)
- 組譯器與連結器不完整且有 bug,展示影片依賴了 GCC 工具鏈
- 產生的程式碼效率不及 GCC——即使關閉 GCC 的優化
- Rust 程式碼品質未達專家水準,新功能經常弄壞既有功能
他自述對結果感到興奮、擔憂與不安,並警告:通過測試不代表工作完成,自主開發帶著真實風險。
為什麼重要
三個層面。第一,能力基準:Carlini 說這個專案「幾乎觸及 Opus 4.6 能力的極限」(Opus 4.6),而他沒預期這在 2026 年這麼早就可能。第二,方法論:無窮迴圈 + Docker + 共享 git + lock file 的組合,任何團隊都能用自己的 agent harness 重現。第三,提醒:系統可信度取決於測試品質——當代理能通過所有測試卻仍交付有缺陷的軟體,瓶頸就從「生成」移到了「驗證」。
參考來源
- Building a C compiler with a team of parallel Claudes — Anthropic
- Sixteen Claude AI agents working together created a new C compiler — Ars Technica
- Claude Opus 4.6 spends $20K trying to write a C compiler — The Register
本文由 AI 協助自上述來源整理，經人工審核後發布。