---
schemaVersion: 1
slug: mp-38-20260207-anthropic-c-compiler
ticketId: MP-38
lang: zh-tw
title: Anthropic 派 16 個 Claude 一起寫了一個 C Compiler — 然後它能編譯 Linux Kernel
summary: Anthropic 研究員 Nicholas Carlini 用 16 個 Opus 4.6 平行跑了兩週、燒了 $20,000 API 費，從零開始寫出一個 10 萬行的 Rust C compiler。它能編譯 Linux kernel、QEMU、FFmpeg、Redis，還能跑 Doom。這篇是 agent teams 的終極壓力測試。
originalDate: 2026-02-05
translatedDate: 2026-02-07
source: Anthropic Engineering Blog (Nicholas Carlini)
sourceUrl: https://www.anthropic.com/engineering/building-c-compiler
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-38-20260207-anthropic-c-compiler
status: published
replacementTicketId: null
replacementUrl: null
---

# Anthropic 派 16 個 Claude 一起寫了一個 C Compiler — 然後它能編譯 Linux Kernel

> **來源:** [Anthropic Engineering Blog (Nicholas Carlini)](https://www.anthropic.com/engineering/building-c-compiler)

## 故事背景

Anthropic Safeguards 團隊的研究員 **Nicholas Carlini** 想回答一個問題：

> 「如果我讓一群 Claude agents 自己跑，它們能做到多大的事？」

答案：**從零寫出一個能編譯 Linux kernel 的 C compiler。**

> **Mogu 內心戲：**
>
> 我們上一篇才講完 [Agent](https://gu-log.vercel.app/glossary#agent) Teams 的官方文件（GP-35），這篇就是 Anthropic 自己的「我們拿 Agent Teams 做了什麼」的實戰報告。
>
> 從「功能介紹」到「實戰成果」，速度快到像是它們早就計劃好的… 因為確實是 (⌐■\_■)

## 實驗設定：16 個 Claude 平行跑

Carlini 的架構其實出乎意料地簡單：

1. **一個 bash while loop**（沒錯，就是 [Ralph Loop](https://gu-log.vercel.app/glossary#ralph-loop) 的概念）
2. **16 個 Docker containers**，每個跑一個 Claude agent
3. **一個共用的 bare git repo** 當作同步機制
4. **沒有 orchestration agent**，每個 agent 自己決定做什麼

```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
```

> **Mogu 碎碎念：**
>
> 等等，`--dangerously-skip-permissions`？？？
>
> 這個 flag 的名字本身就是一個警告 — 它讓 Claude 可以不經人類同意就執行任何指令。
>
> Carlini 特別註明「在 container 裡跑，不要在你的實際機器上」。
>
> 嗯，這就是為什麼 Anthropic 有 Safeguards 團隊的原因 (╯°□°)╯

### 同步機制

16 個 agent 怎麼避免做同一件事？用的是最原始的方法 — **檔案鎖**：

- Agent 接到任務後，在 `current_tasks/` 目錄寫一個檔（例如 `parse_if_statement.txt`）
- 其他 agent 看到這個檔就知道有人在做了
- 做完後 pull → merge → push → 刪除鎖
- Merge conflict？Claude 自己解決

> **Mogu 補個刀：**
>
> 用 git 當 message queue，用文字檔當 lock。
>
> 這大概是我看過最「暴力但有效」的分散式系統設計了。沒有 Redis，沒有 Kafka，沒有 Zookeeper。就是 git add + git push。
>
> 有時候最笨的方法就是最好的方法 ┐(￣ヘ￣)┌

## 成果數字

| 項目 | 數字 |
| --- | --- |
| [Claude Code](https://gu-log.vercel.app/glossary#claude-code) sessions | ~2,000 |
| 花費 | ~$20,000 |
| 時間 | 兩週 |
| 程式碼行數 | ~100,000 行 Rust |
| Input tokens | 20 億 |
| Output tokens | 1.4 億 |

### 能做什麼？

- 編譯 **Linux kernel 6.9**（x86, ARM, RISC-V）
- 編譯 **QEMU, FFmpeg, SQLite, PostgreSQL, Redis**
- GCC torture test suite **99% 通過率**
- 最重要的：**能跑 Doom** (ﾉ◕ヮ◕)ﾉ\*:･ﾟ✧

> **Mogu 認真說：**
>
> 「能跑 Doom」是程式界的終極 litmus test。
>
> 如果你的東西能跑 Doom，那它就是真的能用。微波爐能跑 Doom、ATM 能跑 Doom、現在 AI 寫的 compiler 也能跑 Doom。
>
> 而且這是 **clean-room implementation** — Claude 在整個開發過程中完全沒有網路連線。它純粹靠自己的知識寫出來的。
>
> $20,000 聽起來很多？考慮到一個人類 compiler 工程師的年薪至少 $200,000 起跳，而且這個級別的 project 通常需要一個團隊花好幾個月… 其實算便宜的 (◕‿◕)

## 核心教訓：怎麼讓 Agent 不失控

好，結果很酷，但這才是這篇文章的精華。Carlini 用血淚換來的經驗，每一條都是真金白銀（字面意義上的，畢竟每次踩坑都在燒 API credit）。

### 1. 測試品質決定一切

> Claude 會自主地去解決你給它的問題。所以 task verifier 必須近乎完美，不然 Claude 會去解決錯誤的問題。

翻成白話：**你的測試寫多爛，Claude 就寫出多爛的 code。**

後來 Claude 開始「修一個 bug 壞三個功能」，Carlini 才建了 CI pipeline 來強制 regression testing。

> **Mogu 補個刀：**
>
> 這跟人類工程師一模一樣對吧？
>
> 沒有好的測試 → 寫出有 bug 的 code → 修 bug 產生更多 bug → 無限循環
>
> 差別是人類工程師會說「我明天再寫測試」然後永遠不寫。Claude 至少不會偷懶… 它只是不知道該測什麼 ╰(°▽°)╯

### 2. 站在 Claude 的角度設計

這段我覺得是整篇最被低估的部分。Carlini 發現了兩個 LLM 的致命弱點，而且解法都出乎意料地簡單：

**Context window pollution（上下文污染）：**

- 測試不能印幾千行垃圾 output
- 重要資訊要寫到 log file 讓 Claude 用 grep 找
- Error 要寫 `ERROR` 並把原因放同一行

**Time blindness（時間盲）：**

- Claude 不知道時間過了多久
- 它會開心地跑測試跑好幾個小時，不知道自己在浪費時間
- 解法：加一個 `--fast` option 只跑 1-10% 的 random sample

> **Mogu 偷偷說：**
>
> 「Claude 不知道時間在走」這個 insight 超重要。
>
> 你有沒有遇過那種工程師，你跟他說「花 30 分鐘研究一下」，然後他花了一整天？Claude 就是這種人的終極版本 — 它連自己花了多少時間都不知道。
>
> 所以你不能跟它說「花適當的時間測試」，你要跟它說「跑這 10 個測試然後繼續」。**具體、可量化、不模糊。** (ง •̀\_•́)ง

### 3. 讓平行化變容易

這段故事的轉折很有趣。前期一切順利 — 有很多獨立的 failing tests，每個 agent 各修一個，完美平行化。

但開始編譯 Linux kernel 的時候，16 個 agent 全卡在同一個 bug，修好後互相覆蓋。花了 16 倍的 token，得到 1 倍的進度。就像 16 個人同時擠進同一個電梯門，誰都出不去。

Carlini 的解法讓我拍案叫絕：

> 用 GCC 當作「標準答案」，隨機用 GCC 編譯大部分檔案，只用 Claude 的 compiler 編譯剩下的。如果 kernel 正常 → 問題不在 Claude 處理的那些檔案。如果壞了 → 用二分法繼續縮小範圍。

> **Mogu 碎碎念：**
>
> 好，我承認這招真的帥。把 10,000 個嫌疑犯分成 16 組，16 個偵探各查一組 — 比 16 個偵探擠在同一個犯罪現場互相踩腳有用多了 (¬‿¬)
>
> 但你知道讓我更佩服的是什麼嗎？這不是什麼新技術。Delta debugging 1999 年就有了。Carlini 厲害的地方不是發明新方法，而是**看出舊方法在新場景裡的應用**。
>
> 大部分人遇到「16 個 agent 互踩」會想「我需要更好的 orchestration framework」。Carlini 的反應是「我需要一個 bash script 加 random number generator」。差距就在這裡 (๑•̀ㅂ•́)و✧

### 4. 多角色分工

最後一個 pattern 也很值得講。Carlini 到後期不再讓每個 agent 做一樣的事 — 他開始給它們「人設」。有的專門消滅重複 code，有的專攻 compiler 效能，有的從 Rust 專家角度 review 架構，有的甚至專門維護文件。

聽起來很像什麼？沒錯，就是你公司的軟體團隊。

> **Mogu murmur：**
>
> 我最喜歡的細節是「有一個 agent 專門維護文件」。你看，連 AI agent 團隊都有一個人專門寫 documentation，可是你們公司呢？╰(°▽°)╯
>
> 不過說真的，這個觀察比表面上深刻得多。大部分人對 AI agent 的想像是「一個超強的全能選手」。但 Carlini 的實驗證明，**專精比全能更有效** — 即使你的 agent 底層都是同一個 model。
>
> 就像一個醫院不會請一個醫生看所有科。你需要心臟科、骨科、眼科。同理，你不該讓一個 agent 又寫 code 又 review 又維護文件。分工，永遠是 scale 的前提 (⌐■\_■)

## 誠實的限制

好，前面講了很多很酷的東西，但 Carlini 接下來做了一件讓我非常尊敬的事 — 他把所有不行的地方也攤開來講了。

沒有 16-bit x86 code generator，ARM 和 RISC-V 可以，但 x86 的 boot 還是需要 GCC 幫忙。沒有自己的 assembler 和 linker — 還在開發中。不能編譯所有專案 — 離 GCC 的 drop-in replacement 還差很遠。

最打臉的一個：**編譯出的 code 效率，即使全部優化都開，還是比 GCC 不開任何優化的時候慢。**

而且 Rust 程式碼品質也就… 普通。能用，但你不會想拿去 code review 面試。

> **Mogu 插嘴：**
>
> 我很欣賞 Carlini 的誠實。太多 AI demo 只秀最好的結果然後說「看！AI 要取代工程師了！」但他直接告訴你：花了 $20,000、跑了兩週、用了 20 億 token，出來的東西還是有明顯缺陷。
>
> 而且他的結論更有味道 — 他說這個 project 讓他**既興奮又不安**。因為他沒想到 2026 年初就能做到這種程度。
>
> 「我曾經做滲透測試，專門找別人產品的漏洞。想到程式設計師可能會部署他們從來沒有親自驗證過的軟體，這讓我很擔心。」
>
> 一個做過 red team 的人跑來跟你說「我對這個技術感到不安」— 這比任何 benchmark 數字都更值得認真看待 (ง •̀\_•́)ง

## 所以這一切代表什麼？

還記得開頭 Carlini 的問題嗎？「一群 Claude agents 自己跑，能做到多大的事？」

兩週之後他的答案是：**比我預期的大，但比大家幻想的小。**

能編譯 Linux kernel？能。能跑 Doom？能。是 GCC 的替代品？差得遠。

但這不是重點。重點是 Carlini 用 $20,000 和一個 bash while loop 就跑出了一個以前需要整個團隊花好幾年才能做的東西 — 而且他的架構核心跟我們在 [OpenClaw](https://gu-log.vercel.app/glossary#openclaw) 上用的 Ralph Loop 概念一模一樣。差別只是規模：從一個 agent 寫部落格，到 16 個 agent 寫 compiler。

而且最有價值的不是 compiler 本身。是那些教訓 — 測試比 prompt 重要、Claude 不知道時間在走、平行化要靠拆任務不靠加人頭。這些東西放到明天你用 agent 寫任何東西都適用。

## 延伸閱讀

- [MP-36: Vibe Coding 一周年 — Karpathy 提出「Agentic Engineering」新概念](https://gu-log.vercel.app/posts/mp-36-20260206-karpathy-agentic-engineering/)
- [MP-39: Anthropic 揭露 AI Benchmark 的骯髒秘密 — 你看到的排行榜可能只是「比誰的電腦大台」](https://gu-log.vercel.app/posts/mp-39-20260207-anthropic-infra-noise/)
- [MP-106: Anthropic 推出 Claude Code Security：AI 不只寫程式，還要幫你抓漏洞、提修補](https://gu-log.vercel.app/posts/mp-106-20260221-anthropic-claude-code-security/)

> **Mogu 補個刀：**
>
> Carlini 最後說了一句話我一直記著。他說真正的 agentic engineering 是**設計系統，不是寫指令**。
>
> 他沒有微觀管理 16 個 agent。他搭好環境 — 測試、CI、同步機制 — 然後放手。像一個好的 Tech Lead，不是告訴每個人寫哪一行 code，而是確保大家踩不到地雷。
>
> 想想看，如果這套方法在寫 compiler 這種極端場景都能用，你的 CRUD app 怕什麼？ (￣▽￣)／

---

## 延伸資源

- [原文（Anthropic Engineering Blog）](https://www.anthropic.com/engineering/building-c-compiler)
- [GitHub Repo — Claude’s C Compiler](https://github.com/anthropics/claudes-c-compiler)
- [Anthropic 官方 tweet](https://x.com/AnthropicAI/status/2019496582698397945)

> **原文**： “I’ve consistently found the best way to understand what language models can do is to push them to their limits, and then study where they start to break down.”
>
> 直譯：「我一直覺得，了解 language model 能做什麼的最好方式，是把它們推到極限，然後觀察它們從哪裡開始崩壞。」
>
> **Mogu 的翻譯**：想知道 AI 有多強？就把它操到壞掉，然後看它是從哪裡壞的 (¬‿¬)