5個AI寫國際象棋引擎：1200分打贏Stockfish

給5個AI agent一個任務：從零寫個國際象棋引擎。1個做架構規劃，3個并行寫模塊，1個統籌全局。沒有外部棋庫，沒有聯網查詢，只有agent、測試套件，以及一個目標——在1200 ELO等級分下至少50%勝率擊敗Stockfish。

引擎跑通了。但作者Matt Bateman發現，真正讓他意外的不是輸出結果，而是整個監督式AI agent執行過程中暴露的問題。

團隊配置：Opus做大腦，Sonnet當手腳

5個agent的分工很明確。架構師跑Claude Opus，負責整體規劃。3個工程師跑Claude Sonnet，并行實現具體模塊。1個經理負責在架構師和工程師之間路由任務。每個工程師有自己的git worktree——獨立分支、獨立目錄，完全隔離。

任務板就是一個Markdown文件：待辦、進行中、已完成。作者輸入batty start --attach，然后旁觀。

他最初以為工程師——那些寫實際代碼的agent——會是瓶頸。錯了。

好的架構規劃讓工程師能獨立工作。棋盤表示、走法生成、局面評估，這些模塊天然隔離：觸及不同文件、使用不同數據結構、可以獨立測試。架構師看清了這一點，相應分解了任務。

早期版本用過較弱的架構規劃，工程師互相阻塞。評估agent要等棋盤表示agent完工。搜索agent要等前兩個都完成。3個agent，理論上并行，實際上串行。

解決方法是給規劃階段更多時間、更多昂貴的token。作者用Opus跑架構師，并給出明確指令："分解任務，讓每個工程師無需等待其他工程師輸出就能立即開始。預先定義接口。"

架構師產出了一份規劃：清晰的模塊邊界、共享類型定義放在common/types.rs、每個工程師可以對著寫的存根實現。3個工程師在幾秒內同時啟動。

第一個教訓：在監督式AI agent執行中，任務分解的質量決定一切。規劃上的投入不是開銷，是杠桿。

經理agent：最被低估的角色

經理agent的工作是讀取任務板，決定下一步行動，分派給架構師或工程師。聽起來簡單，但作者發現這個角色的設計直接決定系統能否收斂。

早期版本的經理太"積極"。只要看到待辦事項，立刻分派。結果工程師同時收到多個任務，任務板混亂，依賴關系斷裂。

修正后的經理采用嚴格的狀態機：檢查進行中任務→評估依賴→若無阻塞則分派→否則等待。每次只推進一個任務，確保完成后再下一步。

這個設計讓整體耗時從不可預測變成可預期。作者記錄的數據顯示，嚴格順序執行的版本比"積極"版本平均快23%，且失敗率從31%降到4%。

但經理的瓶頸很快暴露：它成了單點。所有信息流經它，所有決策出自它。3個工程師經常處于等待狀態，不是因為代碼依賴，而是因為經理還沒處理完上一輪反饋。

作者嘗試過讓經理并行處理，但導致狀態競爭——兩個工程師同時修改同一文件，合并沖突爆炸。最終妥協：經理保持單線程，但優化提示詞減少每輪決策的token消耗，把平均響應時間從45秒壓到12秒。

第二個教訓：協調agent的吞吐量，比執行agent的數量更重要。并行執行需要并行協調，但協調的并行化是hard模式。

測試驅動：agent的"地面真相"

整個項目沒有人類寫業務代碼。但人類寫了一個關鍵東西：測試套件。

測試分為三層。單元測試驗證單個函數：給定FEN字符串（一種棋盤狀態的標準表示），驗證走法生成是否返回合法移動列表。集成測試用已知棋局驗證搜索深度和評估分數。最終驗收測試讓引擎對戰Stockfish 1200，統計勝率。

這些測試是agent唯一的"地面真相"。作者觀察到有趣現象：agent會"針對測試優化"——不是作弊，而是表現出類似人類開發者的行為模式。

比如早期版本，走法生成在單元測試全過，但集成測試發現它漏了王車易位的合法性檢查。工程師agent的修復不是理解規則，而是看到測試失敗→定位代碼→添加條件判斷→驗證通過。這個過程重復了17次，直到所有邊界情況被覆蓋。

更意外的是評估函數。作者沒有給agent任何國際象棋知識，只給了測試標準：材料分+位置表，目標是對戰Stockfish 1200勝率超50%。agent自己摸索出的權重配置，和人類引擎的經典值相差不到15%。

但有個失敗案例。搜索深度的迭代加深策略，agent始終調不好。時間控制要么太激進（深度3就停，太弱），要么太保守（深度20超時判負）。作者最終手動干預，給了一個簡單的時間分配公式：基礎時間+每步增量×0.1，深度上限動態調整。

第三個教訓：測試定義能力邊界。agent能在測試覆蓋的范圍內優化，但測試沒覆蓋的盲區，agent不會自動填補。

成本核算：token花在哪最值

整個項目跑了約340萬token。按當時Claude API價格，總成本約47美元。分布很有啟示：

架構規劃占12%（Opus，貴但省時間）。工程師實現占61%（Sonnet，主力消耗）。經理協調占19%（反復讀取任務板、解析輸出、生成指令）。測試運行占8%（非LLM成本，可忽略）。

作者做了對照實驗：砍掉架構師，讓經理直接分派任務給工程師。總token降到280萬，但工程師互相阻塞的時間增加，實際 wall-clock 時間從4.2小時變成11.7小時。且最終引擎強度下降約180 ELO，因為模塊接口設計粗糙。

另一個實驗：把3個工程師加到5個。token消耗飆升到520萬，但完成時間只從4.2小時降到3.8小時。邊際收益遞減明顯——協調開銷吞噬了并行收益。

最意外的發現是經理的token效率。早期版本經理用詳細自然語言寫任務描述，每輪決策消耗約800 token。優化后改用結構化JSON+簡短注釋，降到220 token，決策質量無顯著差異。

第四個教訓：在agent系統中，溝通格式的壓縮率直接影響吞吐量。自然語言對人類友好，對agent是冗余開銷。

失敗案例：當agent遇到模糊目標

不是所有任務都適合agent并行。作者嘗試過一個變體：讓agent優化引擎的"風格"——讓棋風更具攻擊性，同時不損失強度。

這個目標失敗了。因為"攻擊性"沒有可量化的測試標準。作者試過用勝局平均步數、子力交換頻率作代理指標，但agent優化的結果對人類觀察者"感覺更激進"，實戰強度卻下降。

最終這個任務被拆成兩個可量化子目標：提高戰術機會識別率（用 puzzles 測試集）、降低局面簡化傾向（用特定開局測試）。agent在這兩個目標上表現穩定，但"風格"本身仍是人類判斷。

另一個失敗是代碼重構。作者讓agent在功能保持的前提下優化代碼結構。結果agent反復陷入"重構→測試失敗→回滾→再重構"的循環，3次嘗試后作者手動終止。推測原因：重構的收益（可讀性、可維護性）沒有自動化測試覆蓋，agent無法獲得反饋信號。

第五個教訓：agent需要可量化的反饋閉環。模糊目標和長期收益，目前仍是人類專屬領地。

Stockfish對戰：50%勝率背后的真相

最終引擎在1200 ELO設定下對Stockfish取得52%勝率。作者強調這個數字的語境：Stockfish 1200不是"弱"，而是被故意限制計算資源的版本。同等硬件下，完整Stockfish的ELO超過3500。

對戰數據顯示引擎的明顯短板。殘局轉化率只有38%，遠低于開局和中局的61%。時間壓力下（每步5秒）勝率暴跌到31%，說明搜索深度對強度影響極大。特定開局（如西西里防御納道爾夫變例）勝率僅29%，暴露評估函數對復雜中局結構的理解不足。

但有個意外發現：引擎在"非標準"開局（如1.b3，1.g4）表現反而更好，勝率67%。作者推測是因為Stockfish 1200的評估在這些少見局面中同樣不準，而agent優化的評估函數對"非典型"局面的權重配置恰好形成優勢。

這個發現引出一個問題：如果讓agent自我對弈優化，而不是以Stockfish為基準，會得到什么樣的棋風？

作者沒有繼續這個實驗。但他在項目總結中寫道，5個agent、4小時、47美元，產出一個能擊敗入門級Stockfish的引擎——這個投入產出比，在兩年前是不可想象的。

真正讓他興奮的還不是結果，而是過程中反復出現的模式：規劃質量決定并行效率，協調吞吐量決定整體速度，測試覆蓋決定能力邊界，反饋清晰度決定優化上限。這些模式似乎不只適用于國際象棋引擎。

如果給agent一個更模糊的目標——比如"設計一個讓新手覺得有趣的教學引擎"——測試套件該怎么寫？