跳到主要內容

翻譯，Anthropic 如何使用並行 Claude Code 團隊來開發一個完整的 C 編譯器

這篇文章詳細紀錄了 Anthropic 如何使用並行代理團隊來構建一個功能完備的 C 編譯器。以下是該部落格文章的全文完整繁體中文翻譯：

使用並行 Claude 代理團隊構建 C 編譯器

發佈日期：2026 年 2 月 5 日 作者：Nicholas Carlini（Anthropic 安全團隊研究員）

我們指派了 Opus 4.6 模型，利用「代理團隊（agent teams）」構建了一個 C 編譯器，然後（基本上）就放手不管了。以下是這次實驗告訴我們關於自主軟體開發未來的啟示。

對代理團隊進行極限壓力測試

我一直在實驗一種監管語言模型的新方法，我們稱之為「代理團隊」。在代理團隊中，多個 Claude 實例在一個共享的代碼庫上並行工作，無需人類主動干預。這種方法極大擴展了 LLM 代理能達到的目標範圍。

為了進行壓力測試，我指派了 16 個代理，要求它們從零開始用 Rust 撰寫一個能編譯 Linux 核心（Kernel）的 C 編譯器。經過將近 2,000 次 Claude Code 會話和約 2 萬美元的 API 成本，這個代理團隊產出了一個擁有 10 萬行代碼的編譯器，能夠在 x86、ARM 和 RISC-V 上構建 Linux 6.9。

編譯器本身是一個有趣的成品，但我這裡的重點在於我從中學到的經驗：如何為長期運行的自主代理團隊設計「腳手架（harnesses）」、如何編寫測試以確保代理在無人監管的情況下不偏離軌道、如何結構化工作以便多個代理能並行推進，以及這種方法的極限在哪裡。

實現長期運行的 Claude

現有的代理架構（如 Claude Code）通常需要一個操作者在線協作。如果你要求解決一個長期且複雜的問題，模型可能會解決一部分，但最終會停止並等待輸入——例如提問、狀態更新或澄清請求。

為了實現持續的自主進展，我構建了一個將 Claude 置於簡單循環中的腳手架（如果你看過 Ralph-loop，這應該很眼熟）。當它完成一個任務，它會立即開始下一個。（請在容器中運行，不要在你的實際機器上運行）。

#!/bin/bash
while true; do
  COMMIT=$(git rev-parse --short=6 HEAD)
  LOGFILE="agent_logs/agent_${COMMIT}.log"
  claude --dangerously-skip-permissions \
    -p "$(cat AGENT_PROMPT.md)" \
    --model claude-opus-X-Y &> "$LOGFILE"
done

在代理提示語（Prompt）中，我告訴 Claude 要解決的問題，並要求它將問題拆解成小塊、追蹤進度、確定下一步任務，並持續進行直到完美為止。（在最後一點上，Claude 別無選擇，因為循環會永遠運行——雖然有一次我看到 Claude 意外地執行了 pkill -9 bash 殺死了自己，終結了循環。哎呀！）。

並行運行 Claude

並行運行多個實例可以解決單個代理架構的兩個弱點：

  1. 效率： 一個 Claude Code 會話一次只能做一件事。隨著項目規模擴大，並行調試多個問題效率更高。
  2. 專門化： 當一些代理負責解決核心問題時，其他專門的代理可以負責維護文檔、監控代碼質量或解決特定的子任務。

我的並行實現非常簡單：創建一個空的 git 倉庫，為每個代理啟動一個掛載了該倉庫的 Docker 容器。每個代理克隆一份本地副本，完成工作後再推送到遠端。

為了防止兩個代理同時解決同一個問題，腳手架使用了簡單的同步算法：

  • 鎖定機制： Claude 通過在 current_tasks/ 目錄寫入文本文件來「鎖定」任務（例如：一個代理鎖定 parse_if_statement.txt，另一個鎖定 codegen_function_definition.txt）。如果兩個代理試圖搶佔同一任務，git 的同步機制會強制第二個代理選擇其他任務。
  • 合併衝突： Claude 工作完成後，會拉取（pull）遠端代碼、合併其他代理的更改、推送（push）自己的更改並刪除鎖定。雖然合併衝突頻繁發生，但 Claude 足夠聰明，能自行解決。
  • 循環重複： 無限代理生成循環會在新的容器中啟動新的 Claude Code 會話，循環往復。

這是一個非常早期的研究原型。我尚未實現代理間的其他溝通方式，也沒有強制執行高層目標的管理流程。我沒有使用編排代理（orchestration agent）。

相反，我讓每個 Claude 代理自行決定如何行動。大多數情況下，它們會挑選「下一個最明顯」的問題。陷入僵局時，Claude 通常會維護一份記錄失敗嘗試和剩餘任務的文檔。在項目的 git 歷史中，你可以看到它不斷鎖定各種任務的過程。

與 Claude 代理團隊協作的教訓

腳手架讓 Claude 循環運行，但只有在 Claude 知道如何取得進展時才有用。我的大部分精力花在設計 Claude 周圍的環境——測試、環境、反饋——讓它在沒有我的情況下也能自我定位。以下是我發現最有用的方法：

1. 編寫極高質量的測試

Claude 會自主解決我給它的問題。因此，任務驗證器必須近乎完美，否則 Claude 會解決錯誤的問題。改進測試腳手架需要尋找高質量的編譯器測試套件、編寫驗證器和開源軟件包的構建腳本，並觀察 Claude 犯的錯誤，從而設計新測試來應對這些失敗模式。

例如，在項目後期，Claude 每次實現新功能時都會頻繁破壞現有功能。為了解決這個問題，我建立了一個持續集成（CI）流水線，實施更嚴格的強制措施，確保新的提交不會破壞舊代碼。

2. 站在 Claude 的角度思考

我必須不斷提醒自己，這個測試腳手架是為 Claude 寫的，而不是為我自己。這意味著需要重新思考關於測試反饋的假設。

例如，每個代理進入的是一個全新的容器，沒有背景知識，會花大量時間定位自己。為了幫助 Claude，我在指令中要求它維護詳盡的 README 和進度文件，並頻繁更新當前狀態。

我還考慮到語言模型的內在局限性：

  • 上下文污染： 測試腳手架不應打印數千個無用的字節。最多只需打印幾行，並將詳細信息記錄到文件中。
  • 日誌易讀性： 錯誤日誌應易於自動處理。如果有錯誤，Claude 應該寫下 ERROR 並在同一行註明原因，以便 grep 查找。
  • 時間盲性： Claude 無法判斷時間，如果不管它，它可能會花數小時運行測試。腳手架會不頻繁地打印增量進度，並包含一個 --fast 選項，僅運行 1% 或 10% 的隨機樣本。

3. 讓並行化變得容易

當有許多獨立的測試失敗時，並行化很簡單：每個代理選一個失敗的測試。但在編譯 Linux 核心時，代理們卡住了。編譯核心是一個巨大的單一任務，每個代理都會遇到同一個 Bug，修復它，然後覆蓋彼此的更改。

解決方案是引入 GCC 作為「已知正確的編譯器預言機（oracle）」。我寫了一個新的測試腳手架，隨機地將核心的大部分文件交給 GCC 編譯，只留下少數文件交給 Claude 的編譯器。如果內核崩潰，說明問題出在 Claude 編譯的文件中。這讓每個代理能並行地修復不同文件中的不同 Bug。

4. 多代理角色分工

並行化也實現了專門化。我指派一個代理負責合併重複代碼，另一個負責優化編譯器性能，第三個負責讓生成的代碼更高效。我還要求一個代理以 Rust 開發者的角度批評設計並改進代碼質量，另一個則專注於文檔。

評估成果

  • 規模： 10 萬行代碼，完全依賴 Rust 標準庫。
  • 成本： 兩週內消耗 20 億輸入 Token，1.4 億輸出 Token，API 成本近 2 萬美元。這比最貴的訂閱計劃貴得多，但遠低於雇用人類團隊的成本。
  • 能力： 成功構建了可引導的 Linux 6.9、QEMU、FFmpeg、SQLite、PostgreSQL、Redis。在 GCC 酷刑測試中達到 99% 通過率。它還通過了終極測試：編譯並運行《毀滅戰士》（Doom）。

侷限性：

  • 缺乏 16 位代碼生成： 它無法處理 Linux 進入保護模式所需的 16 位實模式代碼，這部分目前調用 GCC（但在 ARM 和 RISC-V 上可以完全獨立編譯）。
  • 匯編器與鏈接器： 這些是最後自動化的部分，仍有 Bug。演示視頻使用了 GCC 的匯編器和鏈接器。
  • 效率： 生成的代碼效率不如 GCC。即使開啟所有優化，性能也低於 GCC 在關閉優化時的表現。
  • 代碼質量： Rust 代碼質量「合理」，但不及專家水平。

展望未來

代理團隊展示了自主實施整個複雜項目的可能性。這讓我們作為工具的使用者能擁有更宏大的目標。

我們仍處於早期階段，完全自主開發存在真實風險。當人類與 Claude 協作時，可以即時發現錯誤。對於自主系統，很容易看到測試通過就以為大功告成，但事實往往並非如此。作為一名前滲透測試員，想到程序員部署從未經過人工驗證的軟體，我感到擔憂。

雖然這個實驗令我興奮，但也讓我感到不安。我沒想到在 2026 年初這就已經成為可能。我們正在進入一個新世界，這將需要新的策略來安全導航。


原文出處

https://www.anthropic.com/engineering/building-c-compiler

留言

張貼留言

這個網誌中的熱門文章

Vibe Coding：為什麼 Junior 更快上手？Senior 要如何追趕？

現象層面（市場觀察） 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變，非常熱門。 身為 Cympack 產品開發團隊 ，我們也一直關注這個議題，在閱讀這篇文章時觀察到一些有趣的現象，對我們來說，這正好反映出 AI 正在改變開發生態，junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位，其中有些啟發（insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding？ 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」，反而 embrace 快速迭代、快速出成果 反觀 Senior： 熟悉大型系統設計 有豐富的「工程正統流程」知識（架構設計、測試策略、效能優化、設計模式） 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師，對 prompt engineering 沒那麼熟練，還在觀望 技能面（未來的關鍵能力） Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢？ Prompt 撰寫 / AI 互動 Junior 較強（熟悉 chat-based 流程） 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強（能看出潛在問題） 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding，並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力，但若不主動練習 vibe coding，長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享，希望帶給各位的感受， 『與 AI 協...
張貼留言
繼續閱讀>>

Vibe Coding 協作到自建 Dev Agent？從 Claude / Codex 到 OpenHands

過去一年，越來越多工程師開始 把 AI 真正帶進工作流程 。從一開始用 ChatGPT、Claude 來問語法問題，到後來很多人愛上 Cursor，直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗，已經大大改變了我們寫程式的方式。 更現實的是，在很多企業內部、政府單位、或涉及機密資料的專案裡， 其實根本不能直接用 Cursor 或雲端 LLM 工具。   畢竟這些服務通常會把資料傳到雲端模型做處理，萬一專案裡有未公開的技術、敏感客戶資料，或是受限於法規 （像金融、醫療、政府標案） ，直接用雲端 AI 工具就會踩 紅線 。  因此，許多團隊反而更希望 「自己架一套 Dev Agent」 ，可以在內網執行，資料完全掌握在自己手上，該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline，全部客製化、安全可控。 這時候，像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手，而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署，從 CLI 操作到瀏覽器查詢， 從多檔案編輯到自動測試，全部都能自己完成，甚至還能針對不同專案調整專屬的工作流。 對很多開始探索 AI 協作開發的團隊來說，這是一條 從 「AI 幫你寫一段程式」，走向「AI 幫你解決一整個任務」 的進化路徑。而且，還是在可控、可自定義、安全的環境裡完成的。 🧩 主要概述 OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」，能模仿人類工程師從建立程式、修改程式碼、執行指令，到瀏覽網頁、呼叫 API……等一整套開發流程 它提供雲端（OpenHands Cloud）與本地 Docker 運行版本，用戶能配置 LLM（如 Claude、OpenAI、Gemini…) 📚 核心特性與怎麼使用 代理人的工具能力 支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用，又或者如果自己本機有 docker 的話，可以自己Local 版本透過 Docker 自架環境。 ...
張貼留言
繼續閱讀>>

Google Gemini 全端 AI Agent 快速入門 - 打造「思考」的 AI 助理

一套從搜尋、反思到輸出的全端 AI 代理人範例，讓你看懂什麼叫 Research Agent 在 AI 工具百家爭鳴的今天，大家都在問一個問題： 「我能不能不只問 AI 答案，而是讓它像一位助理一樣，有流程、有反思、還有出處，真正幫我完成一件事？」 Google 最近釋出了一個相當具有指標意義的開源專案 gemini-fullstack-langgraph-quickstart ，正是為了解這個問題而誕生。 這套系統到底是什麼？ 這個範例不是傳統 Chatbot，而是展示一個完整的 AI research agent ： 它會根據使用者的提問，自動發想搜尋關鍵字、查資料、整合重點，最後給出答案還附上引用來源。背後的邏輯設計得非常扎實，不只是能跑，更是具備可讀性、可擴展性與可商用性。 它的流程大致如下：  1. 使用者輸入問題（例如：「抖音是否影響台灣選舉？」）  2. Gemini LLM 幫你想出關鍵字（不只是照抄問題）  3. 呼叫 Google Search API 抓資料   4. LangGraph 控制流程 → 判斷資料夠不夠 → 若不足，自動補查  5. 整合最終答案，並產生 citation（來源說明） 你可以想像這就像一位實習助理幫你寫報告， 不只輸出一段內容，而是會 去查、會判斷、會補資料，而且說明「我為什麼這樣說」 。 LangGraph 是什麼角色？ LangGraph 就是整個 Agent 背後的控制系統 。 用白話講，它幫你定義 AI 每一步要幹嘛、遇到什麼狀況該走哪條路、要不要反思、要不要再查，甚至可以定義條件邏輯與資料流動。 這就不像寫一個單純的 Chat API，而是比較像「把一個流程圖變成可以跑的程式」。 對工程師來說，它提供了從 prompt 到流程控制的設計彈性；對產品設計來說，它讓 AI 有了 「多步驟任務執行」 的能力。 技術架構與使用方式 這整套系統是 Fullstack 架構，前後端都幫你整好了，技術選型也非常實用：   前端：Vite + React + TailwindCSS + Shadcn UI  後端：FastAPI + LangGraph...
張貼留言
繼續閱讀>>