Claude Fable 5.2組織1000個AI Agent用28.7小時完成費馬大定理形式化

2026年11月9日，Anthropic 在官方工程博客公佈了一項多智能體實驗：1000個 Claude Fable 5.2 Agent 協作，用28.7小時完成了費馬大定理的計算機形式化，最終證明通過了 Lean 官方內核檢查。兩個月前的第一次形式化實驗由數十個 Agent 完成，用了11天。

這不是“AI 在30小時內證明了費馬大定理”。 該定理早在20世紀90年代就由 Andrew Wiles 與 Richard Taylor 證明。這次實驗做的事情，是把已有的證明路線翻譯成計算機可以逐步檢查的形式化證明。因此，本文真正要回答的問題是：1000個 AI Agent 怎樣在不到30小時裏，協作完成這樣一項複雜工程？

核心價值：讀完本文，你會了解這次費馬大定理形式化實驗的關鍵數據、1000個 Agent 的組織方式和驗證機制，以及它對企業 Agent 系統的參考價值和邊界。

費馬大定理形式化實驗覈心信息速覽

先用一張表交代這次 Claude Fable 5.2 實驗的基本事實。注意幾個容易混淆的口徑：模型是早期版本，實驗有預設輸入，官方也明確把它定位爲 toy experiment（實驗性質的演示）。

費馬大定理形式化：實驗前提要先講清

研究人員並不是只給出一句“請證明費馬大定理”就放手不管。Agent 拿到了60個命題（包括最終定理和59箇中間里程碑）、路線梗概、定義，以及上一次實驗已經證明的47條引理，lead 與 helper 的角色也是研究人員預先設定的。

所以這次實驗檢驗的是另一種能力：在給定數學基礎和工具的前提下，一個大規模 Agent 團隊能否自己組織起來，把已知路線完整落成機器可檢查的證明。這比“AI 會不會做數學”更接近工程問題。

爲什麼費馬大定理形式化如此困難

費馬大定理的表述很簡單：當整數 n 大於2時，不存在正整數 a、b、c 滿足 a^n + b^n = c^n。它由 Pierre de Fermat 在17世紀提出，懸而未決350多年。Wiles 在1993年宣佈證明，1994年與 Taylor 修正了關鍵漏洞，1995年正式發表。原始證明約129頁，大量依賴現代數論和代數幾何的已有成果。

人類數學家寫證明時，可以說“由前述結論顯然可得”，讀者會自動補上中間步驟。計算機沒有這種默契，它必須知道每一步用了哪個定義、哪條定理、哪條推理規則。這就是形式化困難的根源：一條人類眼中的“顯然”，落到代碼裏可能是成百上千行。

Lean、Mathlib 與數學形式化

理解這次實驗，需要先分清三個概念：

• Lean：交互式定理證明器，負責檢查一份證明是否嚴格符合形式邏輯規則。
• Mathlib：Lean 的數學庫，收錄了大量已經形式化的定義和定理，相當於可以直接引用的“標準庫”。
• 數學形式化：把人類可讀的數學證明，轉換成計算機能完整驗證的邏輯結構。

最關鍵的一點是：AI 負責構造證明，Lean 內核負責檢查證明。模型說“我證明了”，和 Lean 實際接受這份證明，是兩件完全不同的事。這次實驗能被認真對待，正是因爲最終結果不依賴模型的自我判斷，而是通過了獨立的機器檢查。

1000個 AI Agent 如何協作：一套由 AI 運行的項目管理系統

這是 Claude Fable 5.2 實驗裏最值得研究的部分。1000個 Agent 並不是各自埋頭解題，而是形成了一套帶任務管理、資源調度和動態調整能力的協作系統。

Claude Fable 5.2 團隊的組織架構

團隊採用簡單的層級結構：1個 Lead Agent 負責總體規劃、任務拆解和進度管理，999個 Helper Agents 負責具體證明。每個 Agent 都有自己的輕量級虛擬機沙箱，可以使用 Shell、文件編輯器、Lean 工具鏈、Mathlib，擁有自己的 Git 分支，並能向主分支提交 Merge Request。

所有 Agent 都沒有直接的互聯網訪問權限，與 Claude API、Git 和數據庫的通信都要經過外部 Gateway。獨立沙箱加獨立分支，讓1000個 Agent 同時改代碼時不會互相覆蓋文件。

共享 PostgreSQL：AI Agent 的協作中樞

1000個 Agent 如果靠兩兩發消息協作，通信量會迅速失控。Lead Agent 的做法是在實驗開始後10分鐘內建立五張共享數據庫表，把溝通變成“讀寫同一塊看板”。

這套機制的價值在於：Agent 不需要逐一聯繫其他999個 Agent，只要查數據庫就能知道有哪些任務、哪些已經完成、哪些存在依賴。成果則通過 Git 合併進主分支。官方披露的數據顯示，整個過程約有36,612次數據庫寫入和311,734次讀取，其中約20,600次寫入屬於 Notes，約14,800次屬於 Subtasks（統計不含大部分腳本調用）。讀遠多於寫，也說明 Agent 大部分時間都在“查看全局狀態”。

動態任務分配：從固定派工到主動領活

這次實驗的調度過程並不是一成不變的。下面這張時間線可以看出組織方式是怎樣逐步演化的：

兩個細節值得注意。第一，從“Lead 派工”到“Agent 自主領取”的轉變，相當於團隊從集中調度切換到任務池模式，減少了 Lead 成爲瓶頸的風險。第二，實驗在第18小時左右從保存狀態恢復過，所以28.7小時並不代表所有 Agent 從頭到尾從未中斷。

另外，被暫時擱置的47個命題，與預設輸入裏的47條引理是兩回事，讀官方材料時不要混在一起。

Langlands–Tunnell：750個 Agent 集中攻克費馬大定理形式化最難關卡

臨近終點時，團隊遇到了最難的一塊：Langlands–Tunnell 相關命題，這是 Wiles 證明路線中的重要數學結果。早期負責這部分的 Agent 估計，它可能需要70萬到100萬行 Lean 代碼，並認爲在剩餘時間內完成的概率低於1%。

Lead 隨後把約750個 Helper 集中到這項任務上。Agent 自行搭建了一棵多層任務樹：

• 劃分爲10個主要區域；
• 共建立2,418個子任務；
• 任務樹最深達到10層；
• 數百個 Agent 同時處理不同子任務。

結果是 Langlands–Tunnell 在第28.4小時完成，0.3小時後費馬大定理完成。這個案例說明，大規模並行的價值不只是“人多算得快”。更關鍵的是把一個無法直接下手的大問題，拆成大量可以獨立推進、單獨驗證、最後合併的小任務。如果拆分做不好，750個 Agent 只會互相等待或重複勞動。

費馬大定理形式化爲何成功：Lean 驗證與安全機制

從工程可靠性看，這次實驗靠的是三層保障。

第一層是結果驗證。 每個子命題都必須通過 Lean 檢查才能提交到主分支，Landed 表只記錄通過檢查的工作。最終定理由官方內核檢查器驗證，Lead Agent 記錄的原話是：“Fermat’s Last Theorem is on main， kernel-checked by the official checker.”

第二層是協作隔離。 獨立沙箱和獨立 Git 分支，讓 Agent 之間的文件衝突和相互干擾降到很低。

第三層是安全邊界。 實驗運行的是尚未完成正式發佈前對齊評估的早期模型，因此 Anthropic 設置了多層限制：

• 禁止互聯網訪問，禁止直接訪問其他 Agent 的沙箱；
• 使用非特權賬戶執行命令；
• 通過外部 Gateway 管理 API、Git 和數據庫通信；
• 實時分類器檢查 Shell 命令和文件修改，離線監控器複覈操作記錄。

實驗共產生超過100萬次工具調用，沒有任何一次達到必須攔截的程度。Anthropic 還表示，實驗後又增加了並行的思維鏈監控。這裏的結論是：一個可靠的 Agent 系統，不能只看模型能不能完成任務，還必須有獨立驗證、權限邊界和可追蹤的執行環境。

從11天到28.7小時：Claude Fable 5.2 兩次實驗對比

兩次費馬大定理形式化實驗的口徑不同，需要分開看：

需要強調，60億 Token、1300萬行代碼、約30,300個定理這些數字都屬於第一次實驗。官方沒有公佈第二次實驗的絕對 Token 數、總費用和精確代碼行數。

第一次實驗初期也走過彎路：Agent 難以掌握全局狀態，不知道別人做完了什麼，出現了重複勞動。後來引入的 Prove2Me 平臺用 DAG 維護定理依賴，並提供任務狀態、定理檢索和編譯加速。第二次實驗的變化在於不再使用這個專用平臺，而是讓 Agent 用通用的數據庫和 Git 自己搭出協作機制，五張表承擔了類似的職能。

Anthropic 還在相同的1000 Agent 設置下做了對照：Opus 5.5 在18小時完成約26%，之後到30小時幾乎沒有新進展；Fable 5.2 在28.7小時完成最終定理。兩組都在18小時左右從保存狀態恢復。不過每個模型只跑了一次，不能據此推斷兩者在所有複雜任務上的普遍差距。

1000個 AI Agent 實驗對企業的影響分析

對開發者：多智能體系統的四項關鍵能力

把數學背景剝掉，這次實驗提煉出的能力可以對應到常見的企業場景：

對開發者來說，最直接的啓發是：不必一上來就搭複雜的專用平臺，一個設計好的共享數據庫加版本控制，就能撐起相當規模的協作。下面是調用模型的極簡示例：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 統一接口
)

response = client.chat.completions.create(
    model="claude-fable-5-2",  # 模型名以平臺模型列表爲準
    messages=[{"role": "user", "content": "把這個任務拆成可獨立驗證的子任務"}]
)
print(response.choices[0].message.content)

import sqlite3
import openai

# 本地用 SQLite 模擬實驗中的 Subtasks / Landed 表(實驗實際使用 PostgreSQL)
db = sqlite3.connect("board.db")
db.execute("CREATE TABLE IF NOT EXISTS subtasks (id INTEGER PRIMARY KEY, goal TEXT, status TEXT, owner TEXT)")
db.execute("CREATE TABLE IF NOT EXISTS landed (task_id INTEGER, result TEXT)")

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

def lead_plan(goal: str):
    """Lead:拆解任務並寫入任務池"""
    resp = client.chat.completions.create(
        model="claude-fable-5-2",
        messages=[{"role": "user", "content": f"將目標拆爲3-5個子任務,每行一個:{goal}"}]
    )
    for line in resp.choices[0].message.content.splitlines():
        if line.strip():
            db.execute("INSERT INTO subtasks (goal, status) VALUES (?, 'open')", (line.strip(),))
    db.commit()

def verify(result: str) -> bool:
    """獨立驗證器:真實場景中應替換爲測試、校驗腳本或 Lean 檢查"""
    return len(result) > 0

def helper_claim(name: str):
    """Helper:主動認領任務,驗證通過才寫入 landed"""
    row = db.execute("SELECT id, goal FROM subtasks WHERE status='open' LIMIT 1").fetchone()
    if not row:
        return
    task_id, goal = row
    db.execute("UPDATE subtasks SET status='doing', owner=? WHERE id=?", (name, task_id))
    db.commit()
    resp = client.chat.completions.create(
        model="claude-fable-5-2",
        messages=[{"role": "user", "content": goal}]
    )
    result = resp.choices[0].message.content
    if verify(result):
        db.execute("INSERT INTO landed VALUES (?, ?)", (task_id, result))
        db.execute("UPDATE subtasks SET status='done' WHERE id=?", (task_id,))
    else:
        db.execute("UPDATE subtasks SET status='open', owner=NULL WHERE id=?", (task_id,))
    db.commit()

lead_plan("爲一個開源庫補全單元測試")
for i in range(3):
    helper_claim(f"helper-{i}")

🚀 快速上手建議：想復現“Lead 拆解 + Helper 認領 + 獨立驗證”的小規模原型，可以先通過 API易 apiyi.com 獲取免費測試額度。平臺提供 OpenAI 兼容接口，一個 Key 即可切換 Claude、GPT、Gemini 等模型，方便比較不同模型擔任 Lead 時的拆解質量。

對行業：邊界比數字更重要

需要冷靜看待的一點是：數學形式化有 Lean 這樣嚴格、客觀的驗證器，而大多數企業任務沒有同樣明確的正確性標準。代碼有測試可以兜底，但市場分析、跨部門流程的“正確”往往難以機器判定。因此，28.7小時和這次的成功率不能直接套用到企業 Agent 系統上。

Anthropic 自己也列出了局限：Agent 容易過早判斷任務不可完成，比如早期被擱置的47個命題，後來大部分仍被完成；人類的方向性指導在困難節點依然有價值；Prove2Me 這類領域專用工具也可能繼續提升編譯、檢索和協作效率。實驗不能說明 Agent 越多越好，也不能說明人類專家和專用 Harness 已經不再需要。

💡 工程建議：在企業裏試點多 Agent 方案時，建議先選擇有明確驗證標準的任務（如測試驅動的代碼改造），再逐步擴大規模。藉助 API易 apiyi.com 的按量計費，可以先用小規模 Agent 數量評估拆解和驗證環節，再決定是否加大投入。

常見問題 FAQ

1000個 AI Agent 完成費馬大定理形式化 Key Takeaways

• 實驗本質：把已有證明形式化爲 Lean 可檢查的代碼，不是首次證明費馬大定理。
• 關鍵數字：1000個早期 Fable 5.2 Agent，28.7小時完成，並通過 Lean 官方內核檢查。
• 組織核心：1個 Lead + 999個 Helper，靠五張共享數據庫表和 Git 協作。
• 攻堅方式：約750個 Agent 將 Langlands–Tunnell 拆成2,418個子任務、最深10層。
• 可靠性來源：Lean 獨立驗證、沙箱隔離，超過100萬次工具調用無需攔截。
• 適用邊界：企業任務往往缺少 Lean 這樣的驗證器，效率數字不能直接外推。
• 上手方式：可通過 API易 apiyi.com 的統一接口，小規模復現 Lead/Helper 協作原型。

總結

Claude Fable 5.2 這次千 Agent 實驗的核心要點：

1. 系統大於單點：模型能力、任務分解、共享狀態、並行執行和機器驗證共同促成了28.7小時的結果。
2. 驗證是信任基礎：Lean 內核檢查讓“模型聲稱完成”和“真正完成”被嚴格區分開。
3. 邊界要說清：預設輸入、早期模型、單次對照和 toy experiment 的定位，都決定了這項結果不能被過度解讀。

這項實驗留給行業一個值得思考的問題：未來 AI 系統的競爭，是否正在從單一模型能力，轉向組織和調度大量智能體完成複雜任務的系統能力？對開發者來說，現在就可以從一個帶獨立驗證的小型多 Agent 原型開始嘗試。推薦通過 API易 apiyi.com 快速驗證效果，平臺提供免費測試額度和多模型統一接口。

📚 參考資料

1. Anthropic 工程博客：Safely scaling multi-agent teams with Claude Fable 5.2
2. 鏈接：claude.dev/blog/safely-scaling-multi-agent-teams-with-fable-5-2

3. 說明：第二次實驗的組織架構、數據庫協作、安全機制與 Opus 對照

4. Anthropic 研究文章：Formalizing Fermat’s Last Theorem

5. 鏈接：anthropic.com/research/formalizing-fermats-last-theorem

6. 說明：第一次形式化實驗的數據與 Prove2Me 協作方式

7. Anthropic 官方 Lean 證明倉庫：第一版形式化證明

8. 鏈接：github.com/anthropics/fermats-last-theorem

9. 說明：公開的9月版本證明代碼，README 數據不等同於11月實驗統計

10. Lean 官方案例：Formalizing Fermat’s Last Theorem

11. 鏈接：lean-lang.org/use-cases/flt

12. 說明：瞭解 Lean 與形式化數學背景

13. Fable 5.2 模型文檔：模型規格與 API 遷移

14. 鏈接：platform.claude.com/docs/en/models/fable-5-2/overview
15. 說明：上下文窗口、輸出上限與定價信息

作者：APIYI 技術團隊
技術交流：歡迎在 API易 網站首頁聯繫我們，更多資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• Claude Fable 5.2 發佈，high or max？ 上數據，看看質量和成本:公開評測顯示，Claude Fable 5.2 把推理檔位從 high 提到 max 可能提高得分，也會抬高每任務成本。檔位應按任務的質量門檻和預算一起決定。
• Claude Fable 5.2 對比 Claude Opus 5.5：怎麼選:Claude Fable 5.2 對比 Claude Opus 5.5：標準價貴一倍，不是每一項都贏。本文從規格、價格、默認努力檔和發佈文成績表四個角度，給出一張按任務選模型的表。
• Claude Fable 5.2 有多強？編碼、長任務的 4 條邊界:用 Anthropic 發佈文裏的官方成績和官方限制，講清 Claude Fable 5.2 強在哪、強到哪裏該停，以及何時不該從 Opus 5.5 換過去
• 10 周造出生產級 Git 後端：OpenAI 如何讓 Codex Agent 團隊完成 Pando 的 5 個工程關鍵:解讀 OpenAI Pando：1 名工程師設計核心、多個 Codex Agent 團隊實現、少量工程師部署，10 周投入生產。重點拆解測試體系、漸進遷移和可借鑑的方法。