“16個Agent組隊，兩周干翻37年GCC！”最強編碼模型Claude Opus 4.6首秀，10萬行Rust版C編譯器震撼業界

編譯 | Tina

Anthropic 正在升級它“最聰明的模型”。

隨著新一代旗艦模型 Claude Opus 4.6 的發布，Anthropic 釋放出的信號十分明確：這并不是一次常規的性能小修小補，而是一輪圍繞長任務、復雜工作，以及智能體（agent）如何真正干活展開的系統性升級。

在這次發布之前，Anthropic 內部和部分早期用戶已經開始讓 Opus 4.6 參與一項持續時間很長的工程任務：從零開始，用 Rust 編寫一個完整的 C 編譯器，并要求它能夠編譯 Linux 內核。

這項實驗持續了約兩周時間，期間累計運行了近兩千次 Claude Code 會話，最終產出了一個規模約 10 萬行代碼的編譯器。該編譯器不僅能夠在多種架構上構建 Linux 6.9，還可以編譯 FFmpeg、Redis、PostgreSQL、QEMU，并通過了 GCC 自身 99% 的 torture test，甚至能夠成功編譯并運行 Doom。整個實驗的 API 成本約為 2 萬美元。

為了讓外界更直觀地理解這一成果的尺度，有網友在社交平臺上給出了一個對照：GCC 的開發從 1987 年開始，歷經 37 年，投入過數以千計的工程師。而這一次，是一名研究者加上 16 個 AI 智能體，在短短數周內完成了一個能夠通過大量 GCC 測試集、并編譯真實大型項目的編譯器。

正是在這樣一段持續推進的工程實踐之后，Anthropic 對外發布了 Claude Opus 4.6。

成立于 2021 年、由一批前 OpenAI 研究人員和高管創立的 Anthropic，一直以 Claude 系列大模型為核心產品；在這一體系中，Opus 代表最大、能力最強的型號，Sonnet 和 Haiku 則分別覆蓋中等與輕量級使用場景。某種程度上，Opus 系列承擔的角色，就是在更復雜、更長期的任務環境中檢驗 Claude 的能力邊界。

1 最強的編碼模型：從跑分看 agentic 編程能力

Anthropic 對 Opus 4.6 的定位，并不只是“更會寫代碼”。他們強調，新模型在編程能力上的提升，已經從單純的代碼生成，擴展到更前置的任務規劃，以及更后置的代碼審查與調試流程。這種變化，使模型能夠在大型代碼庫中更穩定地工作，也直接決定了它是否有能力脫離短對話模式，持續參與多階段、長周期的工程任務。

這種定位在評測結果中體現得比較清楚。Anthropic 公布的多項基準測試顯示，Claude Opus 4.6 在 agentic 編程、計算機使用、工具調用、搜索以及金融等任務上，整體跑分都有所提升。

在終端 agentic 編程能力上，Opus 4.6 得分 65.4%，對比來看，略高于 GPT-5.2 的 64.7%，明顯領先 Gemini 3 Pro（56.2%）和 Sonnet 4.5（51.0%）。這說明在純終端環境下執行多步編程任務時，Opus 4.6 的穩定性和自我修正能力處在第一梯隊。

在 SWE-bench Verified（Agentic coding） 上，各家分數非常接近，Opus 4.6（80.8%）與 Opus 4.5（80.9%）、GPT-5.2（80.0%）基本處于同一水平。這里可以理解為：在標準化的軟件工程任務上，能力已經開始趨同。

但在電腦操作（OSWorld）上，代際差異開始顯現。

OSWorld（Agentic computer use） 是一個比較關鍵的分水嶺。Opus 4.6 達到 72.7%，相比 Opus 4.5 的 66.3% 有明顯提升，而 Sonnet 4.5 只有 61.4%，其他模型則未給出對等數據。這類評測關注的是 GUI 操作、跨應用流程和狀態理解能力。放在整張表里看，它與編程能力的同步提升，意味著 Opus 4.6 不只是“會想”，而是更擅長把計劃落到具體操作上。

Agentic search（BrowseComp）：明顯拉開差距。

BrowseComp 是整張表里差距最清楚的一項。Opus 4.6 為 84.0%，而 GPT-5.2 Pro 是 77.9%，Opus 4.5 只有 67.8%，Sonnet 4.5 更低。這一項測的是在真實開放網絡中定位、篩選和組合信息的能力，結果說明 Opus 4.6 在“研究型 agent 行為”上已經明顯領先，而不是只在封閉工具或結構化任務中占優。

另外，在 Humanity’s Last Exam（跨學科推理）和 ARC-AGI-2（新問題解決） 上，Opus 4.6 的優勢更加明顯，尤其是 ARC-AGI-2 的 68.8%，相比 GPT-5.2 Pro 的 54.2% 和 Gemini 3 Pro 的 45.1%，已經不是細微差距。這類評測通常更難通過“提示工程”或策略優化取得躍升，更像是在反映模型本身的泛化推理能力。

“上下文腐爛”與模型可用性的分水嶺

Opus 4.6 還擴大了上下文窗口，也就是單次會話里可記住、可處理的信息量更大。

新模型在 Beta 階段提供100 萬 token的上下文長度，與該公司現有的 Sonnet（4 和 4.5 版本）相當。Anthropic 表示，這樣的上下文容量更適合處理更大型的代碼庫，也能支持對更長文檔的分析與處理。

但 Anthropic 特別強調，Opus 4.6 的提升并不是“能塞更多 token”，而是“塞進去之后還能用”。

他們在說明中提到，Opus 4.6 在大規模文檔中檢索關鍵信息的能力顯著增強，這一點在長上下文任務中尤為明顯：它可以在數十萬 token 范圍里持續跟蹤信息，偏差更小，也更容易捕捉到埋得很深的細節——包括一些 Opus 4.5 本身就已經容易漏掉的信息。

這正好對應了開發者長期吐槽的一個問題：“上下文腐爛（context rot）”。很多模型在對話或任務一旦拉長之后，要么開始遺忘早期信息，要么雖然“看過”，但已經無法在后續推理中正確調用，最終表現為前后不一致、定位問題跑偏、重復試錯。

MRCR v2（8-needle、100 萬 token）這類“草堆找針”測試，本質上就是在專門檢驗這種能力：把多個關鍵線索埋在超長文本里，看模型能否在不迷路的情況下把它們重新找出來。Opus 4.6 在該測試中的得分為76%，而 Sonnet 4.5 僅為18.5%。

這并不是簡單的“高一點、低一點”，更像兩種不同的可用性狀態：一個模型在超長上下文中仍然能穩定檢索并利用信息，另一個則在任務拉長后迅速失效。

這種長上下文的穩定性，直接影響模型能否勝任更“工程化”的工作，尤其是復雜代碼分析與故障診斷。在 Anthropic 給出的能力圖中，Opus 4.6 被特別標注為擅長做root cause analysis（根因分析）。

2 用 Agent 團隊，構建一個 C 編譯器

4.6 最醒目的新增功能，是 Anthropic 所稱的“智能體團隊”（agent teams）：由多個智能體組成的小隊，可以把一個大任務拆成若干獨立的子任務分別推進。

Anthropic 的說法是：“不再讓單個智能體按順序把任務一路做到底，而是把工作分給多個智能體——每個智能體負責自己的一塊，并直接與其他智能體協調。”

Anthropic 產品負責人 Scott White 將其類比為“雇了一支很能干的人類團隊”，因為職責拆分后，智能體可以并行協作，從而更快完成工作。目前，“智能體團隊”以研究預覽（research preview）的形式向 API 用戶與訂閱用戶開放。

編譯器本身固然是一個高度復雜、且極具工程價值的成果，但在 Anthropic 團隊看來，它更像是一次“能力壓力測試”的載體。真正值得總結的，是圍繞長時間運行的自治 Agent 團隊（long-running autonomous agent teams）所形成的一整套工程方法論：如何設計無需人工干預的測試體系、如何讓多個 Agent 并行推進復雜工作、以及這種架構在現實工程中究竟會在哪些地方觸碰到上限。

從“協作式 Agent”到“自治式 Agent”

現有的 Agent scaffolding（例如 Claude Code）本質上仍然是人機協作系統：模型在解決復雜問題時，往往會在某個階段停下來，等待操作者繼續輸入新的指令、確認狀態，或澄清歧義。Anthropic 的實驗目標是消除這種對“人類在線”的依賴，讓 Claude 能夠在無人監督的情況下，持續推進一個長期任務。

為了實現持續自主的進展，Claude 工程團隊并沒有引入復雜的調度系統，而是構建了一個程序，讓 Claude 進入一個簡單的循環（如果你見過 Ralph 循環，應該會覺得眼熟）：每完成一個任務，就立刻進入下一個任務，而不是回到“等待用戶”的狀態。

done

在 Agent prompt 中，Claude 被明確要求將問題拆解成可執行的小任務、記錄當前進展、判斷下一步行動，并持續迭代，直到系統判定“沒有明顯改進空間”。（在這最后一點上，Claude 沒有選擇，因為循環會一直運行——不過在一次實驗中，團隊確實看到 Claude 不小心執行了 pkill -9 bash，結果把自己殺掉了，循環也就隨之結束了。）

并行運行 Claude

并行運行多個實例，可以緩解單一 agent harness 的兩個弱點：

• 一次 Claude Code 會話同一時間只能做一件事。隨著項目范圍擴大，并行調試多個問題會高效得多。

• 運行多個 Claude agent 可以實現“分工”。當一部分 agent 負責解決核心問題時，其他專門的 agent 可以被調用來（例如）維護文檔、盯代碼質量，或處理更專門的子任務。

Claude 工程團隊的并行實現非常基礎：先創建一個新的裸 Git 倉庫；然后為每個 agent 啟動一個 Docker 容器，把倉庫掛載到 /upstream。每個 agent 會在容器內克隆一份本地副本到 /workspace，完成工作后，從各自的容器把改動推回 upstream。

為避免兩個 agent 同時嘗試解決同一個問題，harness 使用了一個簡單的同步算法：

• Claude 通過在 current_tasks/ 下寫入一個文本文件來“鎖定”某個任務（例如，一個 agent 可能鎖定 current_tasks/parse_if_statement.txt，另一個鎖定 current_tasks/codegen_function_definition.txt）。如果兩個 agent 試圖認領同一任務，Git 的同步機制會迫使第二個 agent 改選另一個任務。

• Claude 在任務上工作完成后，會從 upstream 拉取、合并其他 agent 的改動、推送自己的改動，然后移除鎖。合并沖突很常見，但 Claude 能夠處理。

• 無限的 agent 生成循環會在一個全新的容器里啟動新的 Claude Code 會話，然后重復上述流程。

這是一個非常早期的研究原型。Claude 工程團隊尚未實現任何其他 agent 之間的通信方法，也沒有強制任何高層目標管理流程，也沒有使用 orchestration agent。

相反，團隊把“如何行動”的決定權交給每個 Claude agent。多數情況下，Claude 會選擇“下一個最顯而易見”的問題繼續做；當卡在某個 bug 上時，Claude 往往會維護一份持續更新的文檔，記錄失敗過的方法和剩余任務。在項目的 Git 倉庫里，可以通過歷史記錄看到它如何在不同任務上獲取鎖并推進。

用 Claude 團隊寫代碼：一些更管用的做法

把 Claude 放進循環只是起點，真正決定它能否持續推進的，是它能不能從環境和反饋中判斷“下一步該做什么”。因此，Claude 工程團隊把大量精力放在模型之外：測試如何設計、反饋如何呈現、運行環境如何約束，才能讓 Claude 在無人干預的情況下仍然保持方向感。

一個核心前提是：必須圍繞語言模型的固有限制來設計系統。在這次實踐中，團隊重點應對了兩類限制。

首先是上下文窗口污染。測試框架不能輸出成千上萬字節的無用信息，最多只保留幾行關鍵輸出，其余重要內容統一寫入文件，供 Claude 在需要時自行查閱。日志也需要便于自動處理：一旦出現錯誤，必須在同一行明確標出 ERROR 以及失敗原因，方便 grep 直接檢索。同時，能提前算好的匯總統計信息會被預先計算，避免 Claude 在上下文中反復做同樣的推導。

另一類限制是時間盲。Claude 無法感知時間，如果無人干預，很容易長時間沉浸在跑測試里而不推進工作。為此，測試框架很少輸出增量進度，避免不斷污染上下文，并提供默認的 --fast 選項，只運行 1% 或 10% 的隨機子樣本。這個子樣本對單個 agent 是確定的，但在不同虛擬機之間是隨機的，從整體上仍能覆蓋所有文件，同時又能讓每個 agent 精確識別回歸問題。

在并行方面，團隊也很快意識到：并行是否有效，取決于問題是否“好拆”。當失敗測試數量多且彼此獨立時，并行非常直接——每個 agent 處理一個不同的失敗測試即可。在測試通過率接近 99% 后，團隊讓不同 agent 分別去完成不同小型開源項目的編譯，例如 SQLite、Redis、libjpeg、MQuickJS 和 Lua。

但當任務升級到編譯 Linux 內核時，情況發生了變化。內核編譯本質上是一個高度耦合的整體任務，所有 agent 都會命中同一個 bug，修完再相互覆蓋。即便同時運行 16 個 agent，也無法帶來實質進展，因為大家都卡在同一件事上。

解決辦法是引入GCC 作為在線的、已知良好的對照編譯器。團隊編寫了新的測試框架：隨機選擇內核中大部分文件用 GCC 編譯，只把剩余文件交給 Claude 的 C 編譯器。如果內核能夠正常運行，說明問題不在 Claude 負責的那部分文件；如果失敗，則再通過把其中一些文件切回 GCC 編譯，逐步縮小范圍。這樣一來，不同 agent 就可以并行地修復不同文件中的不同錯誤，直到 Claude 的編譯器最終能夠編譯全部文件。即便如此，后續仍需要配合增量調試（delta debugging），找出那些“單獨沒問題、組合在一起就失敗”的文件對。

并行運行也帶來了另一層收益：角色分工成為可能。在實踐中，Claude 工程團隊發現，LLM 生成的代碼很容易重復實現已有功能，因此專門安排了一個 agent 負責掃描并合并重復代碼；另一個 agent 聚焦于提升編譯器自身的性能；第三個 agent 負責改進生成代碼的效率。

除此之外，還有 agent 從 Rust 開發者的視角審視整個項目的設計，提出結構性調整建議，以提升整體代碼質量；另一個 agent 則專注于文檔維護。通過這種方式，不同 Claude 實例在同一代碼庫中承擔起相對穩定的職責，而不是反復在同一層面“重新發明輪子”。

3 評估結果與能力邊界

在兩周內接近 2,000 次 Claude Code 會話中，Opus 4.6 共消耗約 20 億輸入 token、生成約 1.4 億輸出 token，總成本略低于 2 萬美元。該團隊表示，即便與最昂貴的 Claude Max 方案相比，這仍是一次成本極高的實驗；但這一成本依然遠低于由單人、甚至完整人類團隊完成同等工作的成本。

該編譯器是一次完全的 clean-room 實現：開發過程中 Claude 從未獲得互聯網訪問權限，僅依賴 Rust 標準庫。

最終得到的約 10 萬行代碼，能夠在 x86、ARM 和 RISC-V 架構上構建可啟動的 Linux 6.9，同時也可以編譯 QEMU、FFmpeg、SQLite、Postgres、Redis，并在包括 GCC torture test 在內的大多數編譯器測試套件中達到約 99% 的通過率。此外，它還通過了開發者的終極考驗：它可以編譯并運行 Doom 游戲。

但與此同時，這一項目也把當前 Agent 團隊的能力邊界暴露得相當清晰。

• 缺乏啟動 Linux 所需的 16 位 x86 編譯能力，因此在 real mode 階段會調用 GCC（x86_32 與 x86_64 編譯器由其自身實現）。

• 尚未擁有穩定可用的 assembler 與 linker；這些是 Claude 開始自動化的最后環節，目前仍存在問題，演示中使用的是 GCC 的相關工具。

• 該編譯器能夠成功編譯許多項目，但并非所有項目都能成功。它目前還不能完全替代真正的編譯器。
  

• 生成的代碼效率不高。即使啟用所有優化，其效率也低于禁用所有優化的 GCC 生成的代碼。

• Rust 代碼質量尚可，但遠不及 Rust 專家級程序員編寫的代碼質量。

整體實現已接近 Opus 的能力上限，新增功能或修復 bug 時，經常會破壞已有功能。其中一個最具代表性的難點是 16 位 x86 代碼生成。盡管編譯器可以通過 66/67 opcode 前綴生成語義正確的 16 位 x86 代碼，但生成結果超過 60KB，遠高于 Linux 強制的 32KB 限制。因此，在這一階段，Claude 選擇調用 GCC 作為替代（該情況僅出現在 x86 上；在 ARM 與 RISC-V 架構下，編譯可完全由 Claude 自身完成）。

該編譯器的源碼已經公開：https://github.com/anthropics/claudes-c-compiler。Claude 工程團隊建議直接下載、閱讀代碼，并在自己熟悉的 C 項目上嘗試。

https://www.anthropic.com/news/claude-opus-4-6

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

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！