一項耗資 2 萬美元的實驗編譯了 Linux 核心，但需要深入的人類管理。

在推動 AI 代理（agents）的浪潮中，Anthropic 和 OpenAI 本週都推出了多代理工具，而 Anthropic 也樂於展示其更大膽的 AI 編碼實驗。但一如往常，與 AI 成就相關的聲明，總會伴隨著一些關鍵的注意事項。

週四，Anthropic 研究員 Nicholas Carlini 發布了一篇部落格文章，描述了他如何以極少的監督，讓 16 個該公司 Claude Opus 4.6 AI 模型實例同時處理一個共享程式碼庫，並將任務設定為從零開始建構一個 C 語言編譯器。

在兩週的時間裡，耗費了近 2,000 次 Claude Code 會話，以及約 2 萬美元的 API 費用，據稱 AI 模型代理們產出了一個 10 萬行的、基於 Rust 的編譯器，能夠在 x86、ARM 和 RISC-V 架構上編譯一個可開機的 Linux 6.9 核心。

Carlini 是 Anthropic Safeguards 團隊的研究科學家，此前曾在 Google Brain 和 DeepMind 工作七年，他使用了 Claude Opus 4.6 新推出的「代理團隊」（agent teams）功能。實際上，每個 Claude 實例都運行在自己的 Docker 容器內，複製一個共享的 Git 儲存庫，透過寫入鎖定檔案來領取任務，然後將完成的程式碼推送到上游。沒有一個協調代理來指揮交通。每個實例獨立識別出最明顯需要處理的問題，然後開始解決。當出現合併衝突時，AI 模型實例會自行解決。

由此產生的編譯器已由 Anthropic 在 GitHub 上發布，能夠編譯一系列主要的開源專案，包括 PostgreSQL、SQLite、Redis、FFmpeg 和 QEMU。它在 GCC 測試套件上達到了 99% 的通過率，並且在 Carlini 所稱的「開發者的終極試金石」中，成功編譯並運行了《毀滅戰士》（Doom）。

值得注意的是，C 語言編譯器對於半自主 AI 模型編碼來說，是一項近乎理想的任務：其規格已有數十年歷史且定義明確，現有全面的測試套件，並且有一個已知的良好參考編譯器可供比對。大多數現實世界的軟體專案都不具備這些優勢。大多數開發的難點不在於編寫通過測試的程式碼；而在於首先弄清楚測試應該是什麼。

該編譯器也有 Carlini 直言不諱的明顯限制。它缺乏啟動 Linux 實模式所需的 16 位元 x86 後端，因此需要調用 GCC 來完成該步驟。其自身的組合器和連結器仍然存在錯誤。即使啟用了所有優化，它產生的程式碼效率仍不如禁用所有優化的 GCC。而且 Rust 程式碼的品質雖然功能可用，但遠不及專業 Rust 程式設計師的水平。「產生的編譯器幾乎達到了 Opus 能力的極限，」Carlini 寫道。「我（非常努力地）嘗試修復上述幾項限制，但並未完全成功。新功能和錯誤修復經常會破壞現有的功能。」

這些限制可能比成功之處更能說明問題。Carlini 報告說，在專案後期，修復錯誤和添加功能「經常會破壞現有的功能」，這對於任何看著程式碼庫成長到任何貢獻者都無法完全理解的程度的人來說，都是一個熟悉的模式。

而當處理 AI 編碼代理時，這種限制甚至更為普遍，因為它們會隨著時間推移而失去連貫性。該模型在大約 10 萬行程式碼時達到了這個瓶頸，這表明自主代理編碼的實際上限，至少以目前的模型而言。

Anthropic 將該編譯器描述為「乾淨室實現」（clean-room implementation），因為代理在開發過程中沒有網路存取權。但這種說法有些誤導。底層模型是在海量公開來源程式碼上訓練的，幾乎可以肯定包括 GCC、Clang 以及眾多小型 C 編譯器。在傳統軟體開發中，「乾淨室」特指實施者從未見過原始程式碼。按照這個標準，這並不算是一個乾淨室實現。

Hacker News 上，這一區別引發了激烈的辯論，反映了開發者對此新聞的爭議性反應。一位評論者寫道：「這更像是一種蠻力嘗試，試圖解壓網路中模糊儲存的知識。」

2 萬美元的數字也值得一些背景說明。這個數字僅涵蓋 API 令牌成本，不包括訓練模型的數十億美元花費、Carlini 在建構腳手架上投入的人力，以及編譯器工程師數十年來為使專案成為可能而創建測試套件和參考實施所付出的努力。

而且這個腳手架並非微不足道，這使得 AI 代理在 C 編譯器上進行任何「自主」工作的說法都值得懷疑。雖然標題的成果是編譯器在沒有人類結對編程的情況下寫成的，但使專案能夠運作的實際工作中，有很大一部分涉及設計 AI 模型代理周圍的環境，而不是直接編寫編譯器程式碼。Carlini 花費了大量精力來建構測試夾具、持續整合管道和針對語言模型失敗的特定方式進行調整的回饋系統。

他發現，例如，冗長的測試輸出會污染模型的上下文視窗，導致它失去對正在做什麼的追蹤。為了解決這個問題，Carlini 設計了只列印幾行摘要並將詳細資訊記錄到單獨檔案的測試運行器。

他也發現 Claude 沒有時間觀念，會花費數小時運行測試卻沒有進展，因此他建立了一個快速模式，僅抽樣 1% 到 10% 的測試案例。當所有 16 個代理同時卡在修復同一個 Linux 核心錯誤時，他使用 GCC 作為參考預言機，隨機使用 GCC 編譯大多數核心檔案，只使用 Claude 的編譯器編譯一部分檔案，以便每個代理可以在不同的檔案中處理不同的錯誤。

「Claude 會自主地解決我給它的任何問題，」Carlini 寫道。「所以任務驗證器幾乎完美是很重要的，否則 Claude 就會解決錯誤的問題。」

這些都不應掩蓋該專案實際展示的內容。一年前，即使有這種程度的指導和無限的預算，沒有任何語言模型能夠產生一個功能齊全的多架構編譯器。透過 Git 協調、極少人類監督的平行代理方法是新穎的，而 Carlini 開發的用於保持代理生產力的工程技巧（上下文感知測試輸出、時間限制、用於並行化的 GCC 預言機）可能代表了對代理軟體開發工具更廣泛應用的有益貢獻。

Carlini 本人也承認對自己的成果感到矛盾。「建造這個編譯器是我最近最有趣的經歷之一，但我沒想到在 2026 年初就能實現，」他寫道。他還提出了源於他先前滲透測試職業生涯的擔憂，指出「程式設計師部署他們從未親自驗證過的軟體，這是一個真正的擔憂。」