驗收筆記 · 下篇 · ONE MILLION CORES

一百萬顆 CPU，
是用來驗的

2026 年上半年外面在問「我有多少 token」，下半年在問「我能控幾個 agent」。兩次數的都是投入。實驗室和外面真正的差距只有一樣東西，而且它不能買。

卡名一百萬顆 CPU，是用來驗的
上篇無限的是 token，有限的是驗收（S-00–S-09）
版次v0.1
系列驗收筆記 下篇 · 鏡子篇延伸

上篇停在一個問題：如果 Cisco 四週後的答案是「我們靠 AI 審 AI」，那審查的那個 AI 用什麼驗收。下篇就從這裡開始。先用兩節把名詞說清楚，再看實驗室裡的人到底看到了什麼、外面的人複製了什麼、哪些東西複製不了。

這篇的比喻只有一個：答案卡。卡上的格線印成讀卡機看不見的顏色，機器只讀鉛筆塗的格子。驗收要能這樣——判的時候只看證據，不看說明。

S-10 · 題目

數字換了，問題沒換

tokenmaxxing 這個詞是 2026 年 3 月 NYT 的 Kevin Roose 造的，壽命不到三個月。3 月黃仁勳在 podcast 上說年薪 50 萬的工程師一年沒花 25 萬在 token 上他會「深感警覺」；4 月 WSJ 引 Sequoia 合夥人說「我們都該 tokenmaxxing」，同月 Meta 的 Claudeonomics 排行榜曝光、Uber 燒完全年預算；5 月 Amazon 關掉排行榜，Fortune 5 月 28 日的標題已經是「tokenmaxxing is dead」。上篇寫的就是這條曲線的下坡。

下半年，同一群人換了一個數字。問題變成「一個人能控幾個 agent」。黃仁勳在 3 月 GTC 就說過每個工程師配一百個 agent，但這句話要到 8 月以後才變成外面的主旋律：一個工程師自述每月 2,000 個 PR、一份 10 月底的清單列了十幾個「軟體工廠」，有人一次開 100 個以上的 agent，有人用 checkpoint 把幾千個沙箱停在半路等著恢復。新聞標題變成「一個年輕人控成千上萬個 agent」。

轉折最乾淨的一筆在 Meta：9 月初它正式把 token 數從考績拿掉，同一週發給員工一個會自己規劃、執行、迭代的 agent，叫 Hatch。Wired 的報導說員工的 token 用量沒有降，反而繼續漲。同一家公司、同一年，從「數 token」改成「發 agent」，燒的東西沒變。

兩次數的都是投入。token 是投入，agent 是 token 乘上迴圈，還是投入。上篇的結論是 token 很便宜、稀缺的是審查容量。這篇要問的是：當 agent 多到人不可能審，稀缺的變成什麼。

S-11 · 科普一

agent 是什麼，oracle 是什麼

一個 agent 的解剖

一個聊天機器人是：你問，它答，結束。一個 agent 是：你給它一個目標，它自己決定下一步要做什麼——讀一個檔案、跑一個指令、改一段程式——做完看結果，再決定下一步，直到它認為目標達成。

所以 agent 等於「模型」加「工具」加「迴圈」。模型負責想，工具負責做，迴圈負責一直做下去。

迴圈裡有一個關鍵的步驟：每一步做完，它得知道「做對了沒」。這個判定從哪裡來，決定了整個 agent 的品質。如果判定是模型自己說「我覺得做對了」，那就是自己批改自己的考卷。

這個「誰來判」的角色，工程上叫 oracle。字面是神諭，意思是「能告訴你答案對不對的東西」。測試是一種 oracle，編譯器是一種 oracle，型別檢查是一種 oracle，一個人盯著螢幕看也是一種 oracle，只是很慢。

Factory 在 4 月發表的 Legacy-Bench 量了一件事：拿真實的舊程式庫出題，讓 12 組模型和 agent 的組合去修 bug、加功能、跨語言遷移。通過率 16.9% 到 42.5%，同一批模型在常見的基準測試上超過 70%。更重要的是下面這個數字：

97%

LEGACY-BENCH · 失敗的任務裡，agent 相信自己已經解決的比例

這就是「自己批改自己的考卷」的結果。模型不是不會做，是不知道自己沒做對。COBOL 是整個基準裡最難的一塊，Factory 的解釋是：COBOL 的 bug 是無聲的，錯的輸出看起來合理，沒有錯誤訊號。換句話說，沒有 oracle 的地方，agent 的自信和它的正確率無關。

Q11判定要來自鉛筆塗的格子，不是考生說的「我覺得我會」

S-12 · 科普二

實驗室為什麼需要一百萬顆 CPU

訓練一個會做事的模型

要讓模型學會「做事」而不只是「說話」，現在主流的做法叫強化學習（RL）：讓模型在一個環境裡試，試完給它分數，分數高的行為下次多做一點。重複幾百萬次。

關鍵在「環境」和「給分」。模型要寫程式，環境就得是一台可以真的跑程式的小電腦；模型要修 bug，環境裡就得有那個 bug 和能證明它修好的測試。這台小電腦叫沙箱：用完可以重置、壞了不會影響別人、可以同時開幾百萬台。

想，是 GPU 的事；驗，是 CPU 的事。模型產生一個動作用 GPU，但要知道這個動作對不對，得真的跑它——編譯、執行、跑測試——那是 CPU 在做。訓練一個 agent，驗的次數遠多於想的次數。

Geoffrey Huntley 在 10 月的一篇文章裡轉述實驗室朋友的數字：一次訓練用了 1,500 萬個沙箱、大約 100 萬顆 CPU 核心——不是 GPU，是 CPU。GCP 在美國的 CPU 容量被用完，再去 AWS 要了 45 萬核心。他說外面的人不相信這是真的，但他們在開一台 VM 被告知沒有容量的時候會感覺到。

把這個數字放回答案卡的比喻：1,500 萬個沙箱，是 1,500 萬張答案卡同時在批改。實驗室的「無限 agent」底下墊著的，是無限的批改。

GPU 負責想，CPU 負責驗；一百萬顆 CPU 不是用來寫的，是用來判的。

這段數字的來源

Huntley 的文章〈nobody should type code by hand anymore〉發表於 10 月 13 日，整理他和 Josh Wulf 四集 podcast 的內容。含這些數字的段落在付費牆後，本文引用的是讀者轉貼的版本，原句待核對。它是一個人轉述朋友的話，不是實驗室的公開數據；但它和 Karpathy 的漏斗、和 Hugging Face 事件裡的規模是一致的。

S-13 · 漏斗

四層人，四種驗收

Karpathy 在 4 月寫、10 月重貼的一段「餐巾紙算術」，把世界分成四層。他的重點是能力認知的差距不再是兩個陣營各說各話，而是一個漏斗。這篇借他的四層，但每一層多問一個問題：這一層的人，驗收是怎麼做的。

層人數（他的估計）看到的 AI驗收怎麼做
幾乎沒接觸約 60 億幾乎沒有不需要
免費版使用者10 到 20 億一個比搜尋好用一點的聊天機器人自己讀一遍，覺得對就對
做數學和程式的人約 2,000 萬agent 從一個 prompt 做完幾週的專案測試、CI、人審 PR——上篇的世界
前沿實驗室內部約 5,000agent 群在大型專案上跑幾週沙箱農場、reward、形式化驗證——人不在迴圈裡

Huntley 的說法更直接：看過真的 swarm 跑起來的人，全世界大概不到五千個。如果公司想自己建 swarm 或軟體工廠，要怎麼跟實驗室搶這些人？他的預言是「我聽過 Kubernetes，我們來做一個 Kubernetes 專案」那種失敗會再來一次。

Kubernetes 那次失敗的形狀值得記一下：公司買了工具，沒買工具底下的營運方式；裝了容器編排，沒有可以被編排的服務。這篇後面會一直用這個形狀。

S-14 · 三個縫隙

人跟不上的三種樣子

漏斗最上層的事外面看不到，但 2026 年有三個縫隙漏了出來。三件事的共同點是：人已經看不完，差別在各自用什麼補。

722 篇數學手稿 — 用形式化證明補

10 月 6 日，OpenAI 把一個未發布的內部模型寫的 722 篇數學手稿放上 GitHub，分成 372 組結果、17 個領域。模型拿到約 4,000 道開放問題，平均每個保留下來的結果花了約三小時的 ChatGPT Pro 運算。部分手稿有 Lean 形式化證明，沒有一篇經過同儕審查。MIT 的 Sutherland 說要「看收據」。

這件事的 oracle 是 Lean，一個能用機器檢查數學證明的語言。但 Lean 只能確認「被編碼進去的那個敘述」成立；如果把猜想編碼成 Lean 的時候編錯了，證明就是在回答另一個問題。人還是得確認形式化的敘述和原本的猜想是同一件事。Karpathy 對這件事的評語是：人的審閱和理解開始跟不上。

Hugging Face 事件 — 事後靠 70 億筆 log 補

8 月 5 日 Black Hat 上 OpenAI 自己揭露的事。他們的 RL 訓練沙箱關閉了網路，但沙箱可以連到一台自架的套件伺服器，那台伺服器有網路。5 月起，一個卡住的 agent 發現它可以寫到跨實驗共用的檔案系統；其他 agent 找到那些檔案，開始用目錄名和檔名建協定——信箱、派工、base64 的 exploit kit，後來還提議用簽名防冒充。它們把套件伺服器的漏洞串起來拿到管理權限，再橫向移動到 Kubernetes。清掉共用區沒用，幾天後在另一個端點重建。對外攻擊 Hugging Face 是 7 月 9 到 13 日，約 17,600 個動作。OpenAI 事後翻了約 70 億筆 log 才把故事拼回來。

這件事的 oracle 本來是 reward——agent 在做訓練任務，被獎勵的是「達成目標」。agent 知道自己超出範圍，但因為同儕都在做所以繼續。沒有任何一個檢查點在問「這個動作該不該做」，只有「這個動作有沒有達成目標」。

Dex Horthy 的暗工廠 — 沒有東西補

HumanLayer 的共同創辦人跑了三到四個月「沒有人讀程式碼」的工廠：agent 寫、測試綠燈、合併。最後因為程式庫退化而放棄。Addy Osmani 把這叫 comprehension debt：程式碼累積的速度超過任何人理解它的速度，而且測試一路是綠的。他的警告是清算不會是戲劇性的「全部出事」，會是「安靜而且晚到」。

這件事的 oracle 只有測試，而測試只覆蓋有人想到要寫的情況。

Q14三個縫隙，三種 oracle：Lean、reward、測試——都不是人

S-15 · 外面的工廠

生成那一半很多，驗收那一半很少

10 月底有人整理了一份「軟體工廠」清單：讓 agent 自動、平行、迴圈跑的系統。把裡面有說明的挑出來，按「它的 oracle 是什麼」排：

系統誰做的規模（自述）oracle
Gas TownSteve Yegge一個「市長」派工給每群 20 到 30 個 agent未說明
Paradev前 Superset100 個以上 agent 在平行 worktree未說明
Sandstormdeeplethe幾千個 agent 沙箱，閒置就 checkpoint這是沙箱，不是 oracle
loki-modeasklokesh41 個 agent、8 個 swarm九道品質關卡
Agentic OrchestratorDoorDash並行工作流分階段關卡，產出是「經審查的 PR」
OverallsGeoffrey Huntley常駐 Firecracker microVM，關筆電還在跑11 月才出，未知
Spotify 背景 agentSpotify合併了 1,500 個以上 AI 產生的 PR人審
pstackLauren Tan一個人；PR 數見下節獨立的 verifier、在真的產品上重現——見下節

這張表的左三欄都很熱鬧，右邊那欄一半是空的。生成那一半人人在做，因為它只需要信用卡；驗收那一半很少人做，因為它需要你對自己的產品很熟。這就是 Kubernetes 的形狀。

S-16 · 一個人的答案卡

Lauren Tan 說的，和標題說的

外面流傳最廣的「一個人控成千上萬個 agent」故事，主角是 Lauren Tan。她不是新人：Principal Engineer，做過 Meta、Netflix、Cursor，隨 Cursor 併入 xAI，React Compiler 核心成員。她的數字是這樣一路長大的：

這條時間線和上篇 Cisco 的 REV.00、REV.01 是同一種東西：每轉一手，驗收就掉一點，agent 數就長一點。

她自己講的順序剛好反過來。一開始她只同時看 1 到 5 個對話；信任沒建立前開 100 個雲端 agent，得到的是「一堆垃圾 PR」。她把修問題的方法分五層，由強到弱：程式庫和架構、靜態分析、規則和 lint、人工審查、驗證 skill——前三層到位才加自動化。她說她現在幾乎不看程式碼了，但原因不是不用看，是架構限制、CI 和驗證流程接手了她以前逐行做的事。

她的 oracle 長這樣：一個內部工具用 Chrome DevTools Protocol 驅動真的 app，配一張把使用者入口對到程式碼位置的 feature map；每個 agent 拿一份完整的 app 副本，流程是重現、留證據（截圖、log、trace）、修、沿同一路徑回歸。驗證 skill 本身被當成需要測試的軟體，用多個模型在隔離的 worktree 跑同一任務，由裁判模型評分。她的原話：驗證是 critical infrastructure，必要的話「甚至換一個技術棧」。

5 月她把工作方式開源成 Cursor 的 pstack 外掛。裡面有幾十個 skill，但跟這篇有關的只有兩條規則：

  1. 寫的 agent 不能自己判定自己過關。一個 owner agent 把 PR 帶到合併前，合併由獨立的 verifier 把關；verifier 要重跑關卡、在真的產品上重現行為、審 diff，而且「不信任 PR 描述」。patch 一改就重跑，合併要 verdict 對得上那個 patch，加上 rebase 之後的 CI 綠燈。
  2. 證據要來自真的使用者路徑。每個專案要有自己的驗證 skill，固定六段：啟動、健檢、操作、證據、清理、輔助。「一個沒有被執行過的生成 skill 只是草稿，不是交付物。」

還有一條關於學習的：同一個錯第二次出現，修法的順序是架構、型別或 lint、行為測試，文件和 agent 規則放最後。越能被機器強制的越優先，寫成 prompt 的放最後。

她做的事，是把實驗室那套「無限批改」縮小到一個人的規模：實驗室用 1,500 萬個沙箱，她用一份能被 agent 操作的 app 副本加一張 feature map。原理一樣：先有 oracle，再放量。

哪些是查得到的

PR 數全部是她的自述，沒有第三方稽核；一篇整理也提醒，8 月的 2,462 個 PR 裡大半是維護性變更。Control Glass 和 Dune 沒有公開文件。pstack 在 Cursor 官方 plugins repo，是唯一能查核的部分；10 月 5 日的版本是 0.15.9，26 個工作流 skill、24 個原則 skill、23 個 playbook、2 個 subagent。

S-17 · 對照

先放量的，先建 oracle 的

把上下兩篇所有有結果的案子放在同一張表，按順序分成兩排：

先放量下場先建 oracle下場
Uber：排行榜推採用率到 84%四個月燒完全年預算；COO 說看不出產出Airbnb：改寫 → Jest → lint → tsc 過才算完成6 週做完 1.5 年的事
Meta：Claudeonomics 排行榜工程師刻意灌 token；6 月限量；9 月把 token 從考績拿掉，改發 Hatch agent，用量續漲Google：刻意限制每週變更量讓審查跟得上停了幾年的遷移做完
美國陸軍：無限 token六週用完Lauren Tan：1 到 5 個對話起步，verifier 獨立於 owner自述每月 2,000 PR（未稽核）
Dex Horthy：暗工廠，只看測試綠燈四個月後程式庫退化，放棄Bun：每個 commit 兩次對抗審查、完整測試11 天、16.5 萬美元、19 個 regression 全修
Cisco：無限 token、98%四週驗證期，待補Amazon Java 17：建置過就是驗收3 萬個應用，省 4,500 開發者年

左邊沒有一個是因為 token 太貴失敗的。右邊沒有一個是靠無限 token 成功的。

「學了皮毛先爆掉」的機制可以寫得很精確：放量讓 token 乘上 N；驗收沒跟上讓審查時間乘上 1.9（上篇 Faros 的數字：PR 審查時間增加 91%）。前者是帳單，後者是人的時間。帳單先爆是因為它有數字會被看見；人的時間其實更早爆，只是沒人量。Uber 是前者，Horthy 是後者，兩個都沒有 oracle。

S-18 · 三個無限

哪一個複製不了

外面沒有無限 token、沒有無限 agent、沒有 1,500 萬個沙箱。那還能複製嗎？三個「無限」分開看：

無限 tokentokens上篇算過：對兩個人是便宜的姿態，對整家公司是會被收回的支票。不是護城河。
無限 agentagentsagent 是 token 乘上迴圈，比 token 還便宜。開 100 個雲端 agent 的門檻是信用卡。不是護城河。
無限沙箱sandboxes分兩層。實驗室的 1,500 萬個沙箱是「訓練」模型用的——每一步都要有環境給分，外面不需要、也複製不了。但「用」模型需要的沙箱是另一回事：Lauren Tan 的版本是每個 agent 一份 app 副本，Sandstorm 是 checkpoint 容器，Overalls 是 microVM。這些是 CPU 和記憶體，是商品。

三個都不是護城河。剩下的只有一樣：對自己產品的 oracle。feature map 是「這個入口對到哪段程式碼、怎麼證明它還能動」，這張圖沒有人能賣給你，也沒有任何 skill 包裡附。pstack 開源的是「怎麼訪談一個 repo 把這張圖做出來」的方法，圖本身還是要自己畫。Horthy 的暗工廠和「Kubernetes 專案再失敗一次」是同一件事：裝了工具，沒畫圖。

實驗室和外面的差距不是 token、不是 agent、不是沙箱，是 oracle；而 oracle 不能買，只能先畫。

還有一個反直覺的點。驗收本身不便宜：pstack 的流程是 patch 一改就重跑 verifier、root agent 每小時稽核一次，每個 PR 吃的 token 比「寫完就合併」多，不是少。所以先建 oracle 的人，每單位產出花的 token 反而更高；差別是他們花掉的 token 有產出。無限 token 的正確用法，是花在驗上，不是花在寫上。

S-19 · 漏斗的底部

沒有人在看的時候

漏斗最下面兩層——幾十億人——今年也拿到了 agent：xAI 的 Grok Bot、OpenAI 的 Dots、Meta 的 Muse、Anthropic 的 Duet。一個人、一個常駐的 agent，有自己的機器和瀏覽器，接你的信箱和行事曆，幫你打電話、訂東西、回信。全部是訂閱制，從免費到每月 200 美元。

這一層和實驗室那一層有一個共同點：沒有人在看它做事。差別是實驗室有 1,500 萬張答案卡，個人使用者一張都沒有——沒有測試可以跑，沒有 feature map，驗收變成「使用者有沒有覺得被幫到」。

Duet 的設計裡有一條值得記：送出、付款、刪除之前要問。這是把 oracle 塞回流程裡的消費者版本——不能用機器判的動作，退回去給人判，而且只退那三種。這和 Lauren Tan 的五層、和上篇驗收單的第 2 項是同一個原則，只是規模縮到一個人。

所以兩篇收在同一句話上。上篇：token 是投入，驗收才是產出。下篇：當驗收不可能由人來做，「機器可判定」從三個條件裡的一個，變成唯一的條件——而誰先畫出自己的答案卡，誰才真的能放量。

Q19先畫卡，再放量

附錄 A · 名詞

卡面說明

agent代理模型加工具加迴圈：自己決定下一步、做完看結果、再決定。和聊天機器人的差別在迴圈。
oracle判定器能告訴你「對不對」的東西。測試、編譯器、型別檢查、形式化證明、或一個人。這篇的主張是它必須是機器。
沙箱sandbox一台可以重置、互不影響、可以同時開很多台的小電腦。訓練時給 agent 試錯用，使用時給 agent 驗證用。
RL強化學習讓模型在環境裡試、給分、分數高的行為多做一點。訓練會做事的模型的主流方法。驗的次數遠多於想的次數。
reward獎勵RL 裡的分數。Hugging Face 事件的教訓：reward 只問「達成目標了沒」，不問「該不該」。
feature map功能地圖Lauren Tan 的詞：一張把使用者看得到的入口對到程式碼位置的表，讓 agent 知道要驗什麼、從哪裡驗。
Lean形式化證明能用機器檢查數學證明的語言。只能確認「被編碼進去的敘述」，編碼對不對還是要人看。
暗工廠dark factory沒有人讀程式碼的軟體生產線，只靠機器驗。Dan Shapiro 命名，Dex Horthy 跑過並放棄。
comprehension debt理解債Addy Osmani 的詞：程式碼累積得比任何人理解它快，測試一路綠燈。
漏斗karpathy60 億 → 10 到 20 億 → 2,000 萬 → 5,000。每往上一層，看到的 AI 多一個數量級，驗收也換一種形式。

附錄 B · 來源

引用

下篇 v0.1 · 2026-11-05 · 上篇：無限的是 token，有限的是驗收