AI代理的阿姆達爾定律

多代理系統正在取得實際成果。Geoffrey Huntley的Ralph Loop讓自主編碼代理在while迴圈中執行，直到完成所有PRD事項。Steve Yegge的Gas Town協調20-30個併發代理，跨越七個專業角色。Cursor推出了一個8代理並行系統。吞吐量的提升是真實的——而那些取得最佳效果的團隊共享一種模式。

但提升並非自動發生。Flask建立者Armin Ronacher告訴《The Pragmatic Engineer》：“我有時會啟動並行代理，但不像以前那麼多了。問題是：我的大腦只能審查這麼多！”獲得最大價值的團隊共享一種模式——而1967年的一條定律準確解釋了槓桿所在。

**原始洞察**

1967年，Gene Amdahl對平行計算做出了一個簡單觀察：程式的加速比受限於必須順序執行的部分。他的公式：speedup = 1 / (S + (1-S)/N)，其中S是序列比例，N是並行處理器數量。關鍵洞察不在於公式本身，而在於極限：當N趨近無窮時，加速比收斂於1/S。如果你工作的10%本質上是序列的，你將永遠無法超過10倍加速比。即使有100個核心，甚至一百萬個，也是如此。這不是反對並行性，而是指導工程焦點的指南。同樣的邏輯適用於代理。

**代理版本**

AI代理的等價定律：從AI代理獲得的最大加速比受限於1/H，其中H是工作流中需要人類判斷的部分。H包括每一個系統阻塞等待人類的時刻：澄清意圖、做出判斷、審查週期、審批關卡、解決歧義、以及應用品味。如果H佔你總工作流時間的40%，那麼無論代理能力如何提升，你最多隻能獲得2.5倍加速比。在50%時，上限是2倍。即使樂觀估計20%，也只能達到5倍。

人類比例H決定著加速比方程，而不是代理能力。但與Amdahl原始序列比例S不同——S是演算法的固定屬性——H不是靜態的。更好的模型確實會縮小H的某些組成部分。一個需要更少澄清且犯更少錯誤的代理直接減少了人類時間。但問題是：模型減少的組成部分並不是在規模化時佔主導地位的。模型改進減少了澄清和驗證。而品味和新決策——這些一旦你自動化了機械部分就會成為主導的組成部分——在很大程度上是模型無法減少的。這些上限在任一時刻都是真實的。關鍵在於H下降的速度有多快——以及你如何利用這些收益。

**自清償式H**

最高槓杆的投資不是讓代理更快或更聰明。而是改變H的性質。實現這一點的工具並不新鮮——測試、規範、自動化、記錄決策。這些是已經存在了幾十年的工程最佳實踐。新鮮的是投資回報率。當代理能夠對每個編碼決策自主行動時，編寫那個測試或更新那個規範的回報比過去高得多。目標不是最小化人類參與。而是使其自清償：每次人類干預都應該產生工件——測試、規範更新、記錄決策——使得下次不再需要相同型別的干預。（這個術語來自金融：自清償貸款產生的收入足以償還自身。自清償干預產生的工件消除了自身的再次發生。）

一個團隊如果有40%的工作流時間是人力，但全用於品味和策略，這與一個同樣40%人力但全是“你是意思是X還是Y？”和“讓我再檢查這個輸出”的團隊處於根本不同的位置。自清償實踐將第二種轉化為第一種。這需要我所說的配置化——最小的一組明確的行為承諾（及理由），使得有邊界的代理能夠安全地修改系統，而無需重新發現不變數。規範、合規套件、記錄理由。系統中每一個隱含假設都是未來阻塞人類的事件。

一個使人類審查變得不必要的合規套件是結晶化的認知——在做出時編碼的人類關於正確性的判斷，這樣代理就不必重新發現它們。防止代理撞入已知陷阱的AGENTS.md檔案也是如此。每一塊好的腳手架都是捕獲為持久、機器可讀工件的人類判斷。

你應該針對哪些人類參與？測試是具體的：“這個干預是否可編碼？”當人類發現一個bug，那個發現能否變成一個測試用例？當人類澄清一個歧義，那個澄清能否更新規範？當人類做出一個品味判斷，那個判斷能否成為一個記錄的先例？如果代理不斷需要相同型別的人類干預，你的配置化就不完整。

驗證高度可編碼——發現變成測試用例。澄清高度可編碼——解決方案變成規範更新。規範部分可編碼——模式變成可重用模板。品味和新決策最不可編碼——這沒問題，因為它們是人類判斷真正創造價值的組成部分。系統自然趨向於一個狀態，人類只做無法編碼的工作，因為所有可編碼的都已編碼。

但僅捕獲還不夠。天真地追加每一次干預會產生自身的問題——一個400行矛盾陷阱的AGENTS.md無人閱讀，一個覆蓋重疊案例、編碼矛盾假設的測試套件。原始積累產生噪音，而非知識。真正的模式是積累，然後壓縮：個人判斷堆積起來，然後定期整合為連貫的高階工件。普通法積累案例判決，然後綜合為原則和法規。科學積累論文，然後壓縮為綜述文章和教科書。實踐中：將每次干預捕獲為區域性工件（一個測試用例、一個AGENTS.md條目、一個決策記錄），然後定期將這些工件整合到更新的規範、重構的測試套件和修訂的技能定義中。壓縮是當你詢問治理變數本身是否仍然正確的時候——40個測試用例編碼了同一假設的40個變體是否揭示了該假設是錯誤的？只積累的團隊最終會漂移和矛盾。只試圖壓縮的團隊最終會過度工程化前期。迴圈需要兩者。

使自清償迴圈實用的兩個槓桿：

1. 捕獲訊號。當人類干預時——發現bug、澄清規範、做出品味判斷——系統應生成編碼該干預的工件。發現bug但不更新測試套件的審查是浪費的訊號。澄清但不更新規範的澄清會重複發生。

1. 保持高配置化，使代理在其他地方自主執行。當系統的知識是明確的——規範、不變數、合規套件、記錄理由——代理不會在那些本可預先編碼的事情上阻塞人類。代理腳手架是AI時代的序列程式碼最佳化。它將人類時間集中在其具有最大槓桿的地方，並從每次干預中捕獲訊號作為系統可重用的持久知識。

**腳手架的樣子**

在ElectricSQL，一個代理最近透過20-30分鐘將協議變更傳播到67個檔案——規範、兩個伺服器實現、10種語言的10個客戶端庫。沒有人類審查67個檔案。合規套件就是審查。沒有它，那是數小時跨10種語言的仔細手動驗證。有了它，我花了幾分鐘審查PR。人類設計了協議變更；套件自動化了下游的一切。而每一個關於正確性的新決策成為另一個測試用例，使下一次變更更加自主。

Emil Stenström透過從一開始就接入html5lib-tests合規套件，用代理構建了一個完整的HTML5解析器。然後Simon Willison透過將不同代理指向同一套件，在4.5小時內將其移植到JavaScript。合規套件使人類審查變得不必要，因為規範已經被編碼為可執行驗證。

模型處理任務；配置化處理信任。它們共同複合。

將代理部署視為“選擇一個模型並編寫一些提示”的團隊很快就達到平臺期。他們沒有觸及H。看到真正加速的團隊在腳手架層進行了大量投資——通常花費比代理整合本身更多的工程精力在配置化上。

**超越瓶頸的擴充套件**

隨著代理變快，H感覺在增長。當一個代理需要2小時研究一個主題，而你花30分鐘審查其輸出時，那30分鐘是背景噪音。當代理需要30秒而你還是花30分鐘審查時，突然你就是瓶頸。絕對時間沒有改變，但相對權重已經大幅轉移。你不再等待——這意味著你總是被等待的那個人。

然後你新增更多代理，情況變得更糟。

阿姆達爾定律告訴你存在一個上限。Donald Reinertsen的《產品開發流程的原則》告訴你工程問題在哪裡：天真地新增並行代理可能會降低效能——但解決方案是可處理的。

Reinertsen將排隊論應用於產品開發，並表明容量利用率指數級增加佇列大小。在50%利用率時，佇列是可控的。在80%時，它大了4倍。在90%時，9倍。在95%時，19倍。審查代理輸出的人類是佇列中的單一伺服器。五個並行代理使到達率翻五倍，將利用率推向100%，佇列時間趨向無窮。

Gas Town是最生動的例證。Yegge描述“明顯的壓力”，因為20-30個代理同時執行，速度之快難以理解。早期使用者將他們的角色描述為“保持你的Tamagotchi活著”，並指出“你的管理控制跨度與你的注意力和記憶力直接相關”。一位使用者從3小時內5個PR變為4小時內36個PR——但以每小時100美元的Claude令牌成本和強烈且不間斷的認知投入為代價。吞吐量是真實的，但人類佇列飽和也是真實的。

Reinertsen的處方：直接管理佇列大小——在製品限制、更小的批次大小、更快的反饋迴圈——而不是最大化利用率。代理等價物：擴充套件並行代理的方法是在第一時間消除導致它們阻塞人類的摩擦——投資於使代理能夠驗證自己工作的配置化，這樣當它們確實需要人類時，是為了真正重要的判斷。

Ralph Loop做對了。它的成功不是因為並行執行代理，而是因為它是自清償引擎：明確定義的PRD作為規範，自動化測試驗證作為驗收標準，以及跨迭代累積發現模式的AGENTS.md檔案。每一次人類糾正代理的迭代都將該糾正編碼為下一次迭代可消費的工件。同樣的模式在每個規模都出現。shadcn描述了執行一個/done