編譯 | Tina

Anthropic 正在升級(jí)它“最聰明的模型”。

隨著新一代旗艦?zāi)Ｐ?Claude Opus 4.6 的發(fā)布，Anthropic 釋放出的信號(hào)十分明確：這并不是一次常規(guī)的性能小修小補(bǔ)，而是一輪圍繞長任務(wù)、復(fù)雜工作，以及智能體（agent）如何真正干活展開的系統(tǒng)性升級(jí)。

在這次發(fā)布之前，Anthropic 內(nèi)部和部分早期用戶已經(jīng)開始讓 Opus 4.6 參與一項(xiàng)持續(xù)時(shí)間很長的工程任務(wù)：從零開始，用 Rust 編寫一個(gè)完整的 C 編譯器，并要求它能夠編譯 Linux 內(nèi)核。

這項(xiàng)實(shí)驗(yàn)持續(xù)了約兩周時(shí)間，期間累計(jì)運(yùn)行了近兩千次 Claude Code 會(huì)話，最終產(chǎn)出了一個(gè)規(guī)模約 10 萬行代碼的編譯器。該編譯器不僅能夠在多種架構(gòu)上構(gòu)建 Linux 6.9，還可以編譯 FFmpeg、Redis、PostgreSQL、QEMU，并通過了 GCC 自身 99% 的 torture test，甚至能夠成功編譯并運(yùn)行 Doom。整個(gè)實(shí)驗(yàn)的 API 成本約為 2 萬美元。

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

正是在這樣一段持續(xù)推進(jìn)的工程實(shí)踐之后，Anthropic 對(duì)外發(fā)布了 Claude Opus 4.6。

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

1 最強(qiáng)的編碼模型：從跑分看 agentic 編程能力

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

這種定位在評(píng)測結(jié)果中體現(xiàn)得比較清楚。Anthropic 公布的多項(xiàng)基準(zhǔn)測試顯示，Claude Opus 4.6 在 agentic 編程、計(jì)算機(jī)使用、工具調(diào)用、搜索以及金融等任務(wù)上，整體跑分都有所提升。

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

在 SWE-bench Verified（Agentic coding） 上，各家分?jǐn)?shù)非常接近，Opus 4.6（80.8%）與 Opus 4.5（80.9%）、GPT-5.2（80.0%）基本處于同一水平。這里可以理解為：在標(biāo)準(zhǔn)化的軟件工程任務(wù)上，能力已經(jīng)開始趨同。

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

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

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

BrowseComp 是整張表里差距最清楚的一項(xiàng)。Opus 4.6 為 84.0%，而 GPT-5.2 Pro 是 77.9%，Opus 4.5 只有 67.8%，Sonnet 4.5 更低。這一項(xiàng)測的是在真實(shí)開放網(wǎng)絡(luò)中定位、篩選和組合信息的能力，結(jié)果說明 Opus 4.6 在“研究型 agent 行為”上已經(jīng)明顯領(lǐng)先，而不是只在封閉工具或結(jié)構(gòu)化任務(wù)中占優(yōu)。

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

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

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

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

但 Anthropic 特別強(qiáng)調(diào)，Opus 4.6 的提升并不是“能塞更多 token”，而是“塞進(jìn)去之后還能用”。

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

這正好對(duì)應(yīng)了開發(fā)者長期吐槽的一個(gè)問題：“上下文腐爛（context rot）”。很多模型在對(duì)話或任務(wù)一旦拉長之后，要么開始遺忘早期信息，要么雖然“看過”，但已經(jīng)無法在后續(xù)推理中正確調(diào)用，最終表現(xiàn)為前后不一致、定位問題跑偏、重復(fù)試錯(cuò)。

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

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

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

2 用 Agent 團(tuán)隊(duì)，構(gòu)建一個(gè) C 編譯器

4.6 最醒目的新增功能，是 Anthropic 所稱的“智能體團(tuán)隊(duì)”（agent teams）：由多個(gè)智能體組成的小隊(duì)，可以把一個(gè)大任務(wù)拆成若干獨(dú)立的子任務(wù)分別推進(jìn)。

Anthropic 的說法是：“不再讓單個(gè)智能體按順序把任務(wù)一路做到底，而是把工作分給多個(gè)智能體——每個(gè)智能體負(fù)責(zé)自己的一塊，并直接與其他智能體協(xié)調(diào)?！?/p>

Anthropic 產(chǎn)品負(fù)責(zé)人 Scott White 將其類比為“雇了一支很能干的人類團(tuán)隊(duì)”，因?yàn)槁氊?zé)拆分后，智能體可以并行協(xié)作，從而更快完成工作。目前，“智能體團(tuán)隊(duì)”以研究預(yù)覽（research preview）的形式向 API 用戶與訂閱用戶開放。

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

從“協(xié)作式 Agent”到“自治式 Agent”

現(xiàn)有的 Agent scaffolding（例如 Claude Code）本質(zhì)上仍然是人機(jī)協(xié)作系統(tǒng)：模型在解決復(fù)雜問題時(shí)，往往會(huì)在某個(gè)階段停下來，等待操作者繼續(xù)輸入新的指令、確認(rèn)狀態(tài)，或澄清歧義。Anthropic 的實(shí)驗(yàn)?zāi)繕?biāo)是消除這種對(duì)“人類在線”的依賴，讓 Claude 能夠在無人監(jiān)督的情況下，持續(xù)推進(jìn)一個(gè)長期任務(wù)。

為了實(shí)現(xiàn)持續(xù)自主的進(jìn)展，Claude 工程團(tuán)隊(duì)并沒有引入復(fù)雜的調(diào)度系統(tǒng)，而是構(gòu)建了一個(gè)程序，讓 Claude 進(jìn)入一個(gè)簡單的循環(huán)（如果你見過 Ralph 循環(huán)，應(yīng)該會(huì)覺得眼熟）：每完成一個(gè)任務(wù)，就立刻進(jìn)入下一個(gè)任務(wù)，而不是回到“等待用戶”的狀態(tài)。

done

在 Agent prompt 中，Claude 被明確要求將問題拆解成可執(zhí)行的小任務(wù)、記錄當(dāng)前進(jìn)展、判斷下一步行動(dòng)，并持續(xù)迭代，直到系統(tǒng)判定“沒有明顯改進(jìn)空間”。（在這最后一點(diǎn)上，Claude 沒有選擇，因?yàn)檠h(huán)會(huì)一直運(yùn)行——不過在一次實(shí)驗(yàn)中，團(tuán)隊(duì)確實(shí)看到 Claude 不小心執(zhí)行了 pkill -9 bash，結(jié)果把自己殺掉了，循環(huán)也就隨之結(jié)束了。）

并行運(yùn)行 Claude

并行運(yùn)行多個(gè)實(shí)例，可以緩解單一 agent harness 的兩個(gè)弱點(diǎn)：

• 一次 Claude Code 會(huì)話同一時(shí)間只能做一件事。隨著項(xiàng)目范圍擴(kuò)大，并行調(diào)試多個(gè)問題會(huì)高效得多。

• 運(yùn)行多個(gè) Claude agent 可以實(shí)現(xiàn)“分工”。當(dāng)一部分 agent 負(fù)責(zé)解決核心問題時(shí)，其他專門的 agent 可以被調(diào)用來（例如）維護(hù)文檔、盯代碼質(zhì)量，或處理更專門的子任務(wù)。

Claude 工程團(tuán)隊(duì)的并行實(shí)現(xiàn)非?；A(chǔ)：先創(chuàng)建一個(gè)新的裸 Git 倉庫；然后為每個(gè) agent 啟動(dòng)一個(gè) Docker 容器，把倉庫掛載到 /upstream。每個(gè) agent 會(huì)在容器內(nèi)克隆一份本地副本到 /workspace，完成工作后，從各自的容器把改動(dòng)推回 upstream。

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

• Claude 通過在 current_tasks/ 下寫入一個(gè)文本文件來“鎖定”某個(gè)任務(wù)（例如，一個(gè) agent 可能鎖定 current_tasks/parse_if_statement.txt，另一個(gè)鎖定 current_tasks/codegen_function_definition.txt）。如果兩個(gè) agent 試圖認(rèn)領(lǐng)同一任務(wù)，Git 的同步機(jī)制會(huì)迫使第二個(gè) agent 改選另一個(gè)任務(wù)。

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

• 無限的 agent 生成循環(huán)會(huì)在一個(gè)全新的容器里啟動(dòng)新的 Claude Code 會(huì)話，然后重復(fù)上述流程。

這是一個(gè)非常早期的研究原型。Claude 工程團(tuán)隊(duì)尚未實(shí)現(xiàn)任何其他 agent 之間的通信方法，也沒有強(qiáng)制任何高層目標(biāo)管理流程，也沒有使用 orchestration agent。

相反，團(tuán)隊(duì)把“如何行動(dòng)”的決定權(quán)交給每個(gè) Claude agent。多數(shù)情況下，Claude 會(huì)選擇“下一個(gè)最顯而易見”的問題繼續(xù)做；當(dāng)卡在某個(gè) bug 上時(shí)，Claude 往往會(huì)維護(hù)一份持續(xù)更新的文檔，記錄失敗過的方法和剩余任務(wù)。在項(xiàng)目的 Git 倉庫里，可以通過歷史記錄看到它如何在不同任務(wù)上獲取鎖并推進(jìn)。

用 Claude 團(tuán)隊(duì)寫代碼：一些更管用的做法

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

一個(gè)核心前提是：必須圍繞語言模型的固有限制來設(shè)計(jì)系統(tǒng)。在這次實(shí)踐中，團(tuán)隊(duì)重點(diǎn)應(yīng)對(duì)了兩類限制。

首先是上下文窗口污染。測試框架不能輸出成千上萬字節(jié)的無用信息，最多只保留幾行關(guān)鍵輸出，其余重要內(nèi)容統(tǒng)一寫入文件，供 Claude 在需要時(shí)自行查閱。日志也需要便于自動(dòng)處理：一旦出現(xiàn)錯(cuò)誤，必須在同一行明確標(biāo)出 ERROR 以及失敗原因，方便 grep 直接檢索。同時(shí)，能提前算好的匯總統(tǒng)計(jì)信息會(huì)被預(yù)先計(jì)算，避免 Claude 在上下文中反復(fù)做同樣的推導(dǎo)。

另一類限制是時(shí)間盲。Claude 無法感知時(shí)間，如果無人干預(yù)，很容易長時(shí)間沉浸在跑測試?yán)锒煌七M(jìn)工作。為此，測試框架很少輸出增量進(jìn)度，避免不斷污染上下文，并提供默認(rèn)的 --fast 選項(xiàng)，只運(yùn)行 1% 或 10% 的隨機(jī)子樣本。這個(gè)子樣本對(duì)單個(gè) agent 是確定的，但在不同虛擬機(jī)之間是隨機(jī)的，從整體上仍能覆蓋所有文件，同時(shí)又能讓每個(gè) agent 精確識(shí)別回歸問題。

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

但當(dāng)任務(wù)升級(jí)到編譯 Linux 內(nèi)核時(shí)，情況發(fā)生了變化。內(nèi)核編譯本質(zhì)上是一個(gè)高度耦合的整體任務(wù)，所有 agent 都會(huì)命中同一個(gè) bug，修完再相互覆蓋。即便同時(shí)運(yùn)行 16 個(gè) agent，也無法帶來實(shí)質(zhì)進(jìn)展，因?yàn)榇蠹叶伎ㄔ谕患律稀?/p>

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

并行運(yùn)行也帶來了另一層收益：角色分工成為可能。在實(shí)踐中，Claude 工程團(tuán)隊(duì)發(fā)現(xiàn)，LLM 生成的代碼很容易重復(fù)實(shí)現(xiàn)已有功能，因此專門安排了一個(gè) agent 負(fù)責(zé)掃描并合并重復(fù)代碼；另一個(gè) agent 聚焦于提升編譯器自身的性能；第三個(gè) agent 負(fù)責(zé)改進(jìn)生成代碼的效率。

除此之外，還有 agent 從 Rust 開發(fā)者的視角審視整個(gè)項(xiàng)目的設(shè)計(jì)，提出結(jié)構(gòu)性調(diào)整建議，以提升整體代碼質(zhì)量；另一個(gè) agent 則專注于文檔維護(hù)。通過這種方式，不同 Claude 實(shí)例在同一代碼庫中承擔(dān)起相對(duì)穩(wěn)定的職責(zé)，而不是反復(fù)在同一層面“重新發(fā)明輪子”。

3 評(píng)估結(jié)果與能力邊界

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

該編譯器是一次完全的 clean-room 實(shí)現(xiàn)：開發(fā)過程中 Claude 從未獲得互聯(lián)網(wǎng)訪問權(quán)限，僅依賴 Rust 標(biāo)準(zhǔn)庫。

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

但與此同時(shí)，這一項(xiàng)目也把當(dāng)前 Agent 團(tuán)隊(duì)的能力邊界暴露得相當(dāng)清晰。

• 缺乏啟動(dòng) Linux 所需的 16 位 x86 編譯能力，因此在 real mode 階段會(huì)調(diào)用 GCC（x86_32 與 x86_64 編譯器由其自身實(shí)現(xiàn)）。

• 尚未擁有穩(wěn)定可用的 assembler 與 linker；這些是 Claude 開始自動(dòng)化的最后環(huán)節(jié)，目前仍存在問題，演示中使用的是 GCC 的相關(guān)工具。

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

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

• Rust 代碼質(zhì)量尚可，但遠(yuǎn)不及 Rust 專家級(jí)程序員編寫的代碼質(zhì)量。

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

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

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

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

聲明：本文為 InfoQ 整理，不代表平臺(tái)觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。

會(huì)議推薦

InfoQ 2026 全年會(huì)議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實(shí)生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點(diǎn)，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實(shí)戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實(shí)現(xiàn)技術(shù)價(jià)值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點(diǎn)，搶占 2026 智能升級(jí)發(fā)展先機(jī)！