Google 的 AI 與基礎設施團隊在一篇多數業界人士都匆匆略過的部落格文章中，低調發表了一項驚人成果：將生產環境中的機器學習模型從 TensorFlow 遷移至 JAX，速度提升了六倍，而這項遷移涉及數千行程式碼、數百個層，以及橫跨多個檔案的深層依賴關係。Sundar Pichai 在 Google Cloud Next 大會上提及了此事。這個數字成了頭條新聞。但其底層的架構才是真正的故事核心，而這個架構，也正是當前所有可信的大規模 Agent 遷移專案背後所使用的同一套架構——無論這個群體是 8 個 Agent 還是 800 個 Agent。
這裡有個最關鍵的細節：他們最初嘗試讓單一 AI Agent 直接處理整個程式碼庫。結果失敗了。不是部分失敗，而是完全失敗。它失去了上下文，憑空想像出根本不存在的 API，並產生了無法編譯的程式碼。解決方案並非使用更聰明的模型，而是採用一種截然不同的架構，這個架構現在有個名字：「暗工廠」模式。在這種模式下，Agent 們能規劃、實作、測試並交付程式碼，過程中完全不需要人工審查，就像一座全自動化的工廠在黑暗中運轉機器，因為已經沒有人需要為它開燈了。
這篇文章就是對該模式的完整解析。不是行銷話術，而是數百個 Agent 如何在沒有人類逐一檢查每個變更的情況下，遷移一個真實程式碼庫的實際運作機制；以及，讓這一切安全無虞的關鍵，並非對模型的信任，而是一個從根本上就設計成「永遠不需要那種信任」的架構。
為什麼單一 Agent 無法大規模運作
在探討架構之前，先要精確理解為什麼這種單純的做法會失敗，因為成功模式中的每一項設計決策，都是為了修補這些失敗中的某一項。
一個單一 Agent 面對大型程式碼庫時，首先會遇到上下文問題。即使擁有寬廣的上下文視窗，一個包含數百個相互依賴的檔案、深層呼叫鏈以及跨模組繼承假設的程式碼庫，仍然超出了任何單一會話能連貫處理的範圍。Agent 在處理前幾個檔案時表現良好，但隨著工作上下文被累積的、半相關的歷史資訊填滿，表現就會開始下滑。
接著它會遇到順序問題。程式碼遷移預設上不是一個可以平行處理的任務。檔案 B 通常依賴於檔案 A 已經被遷移完成，因為函式簽章改變了、匯入路徑移動了，或者資料結構改變了型態。一個沒有明確依賴關係圖的 Agent，要嘛猜測處理順序（這會產生損壞的中間狀態），要嘛按照檔案被列出的順序處理（這在功能上等同於猜測）。
然後它會遇到驗證問題，而這才是真正最關鍵的問題。一個 Agent 遷移程式碼後，再自行評估自己的遷移成果，這就像是在檢查自己的作業，而且檢查時帶著與當初犯錯時完全相同的盲點。如果 Agent 不理解某個特定 API 在新版本下行為有所不同，那麼當它審查自己的輸出時，也無法發現這個誤解，因為同樣的理解差距存在於兩次處理過程中。
Google 的團隊直接發現了這個問題。單一 Agent 的設定無法同時兼顧遷移的結構性規則與逐行執行的細節。將這兩個關注點拆分到不同的角色中，才是真正的解決方案。而這個相同的解決方案，也獨立出現在 OpenAI 發表的遷移手冊、關於多 Agent 遷移循環的學術研究，以及每一個實際大規模運作的生產系統中。
架構：三個角色，而非一個通才
這個可行的模式將工作拆分為三個角色，每個角色都有真正不同的任務，而不僅僅是為同一個通才 Agent 提供不同的提示詞。
規劃者（Planner）使用確定性工具（而非 LLM 猜測）來安排工作順序。 這個細節區分了一個能真正擴展的系統，與一個在展示時令人印象深刻、但在生產環境中卻會崩潰的系統。Google 的 Planner 並非要求 LLM 透過推理來找出遷移順序。它使用基於編譯器的靜態分析——這種確定性工具類別已支撐企業軟體數十年——來建立實際的依賴關係樹，並定義一個從葉節點（沒有其他檔案依賴的檔案）開始，向上處理到所有其他檔案都依賴的檔案的執行計畫。
這點至關重要，因為依賴關係排序不是一個創意問題。它是一個有正確答案的機械性問題。使用 LLM 來解決一個已經有確定性解決方案的問題，只會引入一個本不該存在的新錯誤來源。其底層規則是：任何一個有演算法答案的問題，就使用演算法。將語言模型保留給任務中真正需要判斷力的部分，也就是實際的程式碼轉換，而不是決定哪個檔案先處理的排序工作。
遷移 Agent（Migration Agent）（在較大的系統中，可能是數百個以平行、隔離、範圍狹窄的相同角色實例運行）負責執行實際的程式碼轉換。 每個實例獲得一個範圍明確的任務，理想情況下是一個檔案或一個緊密耦合的模組、一個單一的程式碼檢出，以及一份明確的遷移簡報，說明需要更改的內容及其原因。它檢查相關程式碼、進行編輯，並產生一個修補程式。它不決定自己的修補程式是否正確。這不是它的工作，而且該架構的設計也特別確保它不會意外地承擔這項工作。
環境與驗證層（Environment and Verification layer）在隔離環境中建置、運行和測試遷移後的程式碼，然後才接受任何變更。 這就是「完成就是完成」從一個觀點變成機械性事實的地方。Google 對此的表述非常精準：業界歷來提供了兩個糟糕的選項來決定 AI 的工作何時真正完成：要嘛是無法擴展到數百個檔案的人工審查，要嘛是無法被稽核的 AI 自我評估（因為沒有實際檢查內容的記錄）。他們的答案是數學驗證，也就是確定性的程式碼，用以確認編譯成功、測試通過，以及行為符合定義的規格。這用一個真正可被檢視的第三選項，取代了前述兩個糟糕的選項。
請注意這個清單中缺少了什麼：在合併前，沒有人類逐一閱讀每個差異（diff）。這就是「暗工廠」模式的全部重點，同時也是大多數人對安全性直覺出錯的地方，因為這聽起來像是系統只是更加信任 Agent。事實正好相反。這是從結構上減少對 Agent 的信任，方法是將單一的判斷點——「Agent 說這個可行」——替換成一個 Agent 無法影響或繞過的驗證層。
隔離層：為什麼每個 Agent 都有自己的沙盒
讓數百個 Agent 同時針對同一個程式碼庫運行，會產生一個明顯的風險：當 Agent 47 正在編輯一個檔案，而這個檔案正是 Agent 12 的變更所依賴的，但 Agent 12 的編輯卻剛好破壞了編譯，這時會發生什麼事？
答案，與 OpenAI 發表的遷移架構和 Google 的生產系統一致，就是預設隔離。每個遷移任務都在自己的沙盒環境中運行，通常是它自己的 git worktree，也就是一個針對該任務範圍的、完整且獨立的儲存庫檢出。如果沙盒中的 Agent 破壞了某些東西，它破壞的是一個隔離的副本，而不是共享的程式碼庫，更不會影響另一個 Agent 正在進行的工作。
這種隔離的作用不僅僅是防止衝突。它還使整個系統可以輕易地平行化，因為沒有共享的可變狀態會讓數百個同時運行的 Agent 互相干擾。從 Agent 1 到 Agent 800 可以真正地同時運行，每個都在一個乾淨的環境中，只包含與其特定任務相關的檔案和上下文，完全不用擔心一個 Agent 的幻覺會污染另一個 Agent 的正確工作。
控制程式（harness），也就是決定哪個任務進入哪個沙盒以及如何處理結果修補程式的編排層，則保持在每個沙盒之外。這是一個具體且重要的架構選擇：擁有存取機密、外部工具和實際儲存庫權限的可信任程序，與運行 AI 生成程式碼的不可信任執行環境是分開的。沙盒只獲得其單一任務所需的確切內容，僅此而已。主機程序絕不會直接使用其自身提升的權限來運行生成的程式碼。這種分離正是讓 Agent 的程式碼得以安全執行的關鍵，因為沙盒內的錯誤（甚至是惡意的提示注入）都無法影響到沙盒外的任何東西。
循環本身：規劃、執行、驗證、改進
剝離規模和特定工具，這一切底層實際運行的循環包含四個階段，每個任務重複進行，直到該任務通過或用盡其重試次數。
第一階段：遷移規劃。 遷移 Agent 接收其範圍明確的任務（一個檔案或模組）、特定的目標規格（語言版本、框架變更、API 相容性要求），並產生一個候選轉換方案。這是唯一一個由創意性、基於判斷的語言模型推理來完成主要工作的階段，因為決定如何將一個特定模式正確地轉換為新框架中的等效模式，確實需要理解，而不僅僅是機械式的查詢。
第二階段：自動化環境設定。 一個獨立的組件（在學術文獻中有時稱為環境 Agent）會自動為遷移後的程式碼建構一個建置和運行環境，處理依賴關係解析和配置，以便候選修補程式能夠在真實條件下被編譯和運行，而不是在抽象層面上進行評估。
第三階段：測試驗證。 遷移後的程式碼會針對實際的測試套件運行，如果該特定模組沒有測試套件，則針對生成的等效測試運行。這是機械式的驗證步驟，會產生客觀的「通過」或「失敗」結果，而不是一個印象。測試要嘛通過，要嘛不通過，沒有模糊空間讓 Agent 可以繞過。
第四階段：反饋改進。 如果失敗，具體的測試失敗訊息和診斷日誌會作為有針對性的修正輸入，回饋給遷移 Agent，而不是一個模糊的「這沒用，再試一次」。擁有該修補程式的 Agent 會根據具體的失敗證據來改進其特定邏輯和依賴關係映射，而不是從頭開始進行一次泛泛的重試。
這個四階段的循環會針對每個任務重複進行，並設有明確的上限。一個有文件記載且可運作的、使用此精確循環模式的版本，指定了停止條件，例如「沒有檔案再符合舊模式」，同時也設定了硬性的最大迭代次數。在一個已發布的範例中，這個數字是 200 次迭代，超過這個次數後，系統會自動停止，而不是在一個無法收斂的任務上無限期運行。
這個上限在大規模運行時極其重要。沒有它，一個結構上不可能完成的任務（因為規格本身含糊不清，或者目標模式確實沒有乾淨的等效方案）將會永遠消耗資源，而不是作為一個具體的、有界限的失敗浮現出來，讓人類可以實際查看並解決。
為什麼人工審查無法擴展，以及什麼取代了它
值得精確說明為什麼「沒有人類逐一審查」在這裡實際上是更安全的設計，而不是偷工減料。
比較 AI Agent 程式碼審查與人類程式碼審查的研究發現了一些具體且有用的資訊：AI 生成的審查意見，每行程式碼的長度幾乎是人類審查的七倍，並且幾乎完全集中在程式碼改進和缺陷檢測上；而人類審查則自然地擴展到其他完全不同的事情上：建立共同理解、傳遞知識、團隊成員之間的社交溝通。人類審查的來回往復會根據回饋類型而有很大差異。AI 對 AI 的審查互動則非常統一和機械化，無論標記的是什麼。
正確解讀這一點，它說明了重要的事實：人類審查和 AI 驗證擅長於結構上不同的事情。要求人類以 Agent 群體產生的速度和數量來審查 800 個獨立的差異，這不是安全升級，而是產生橡皮圖章式批准的瓶頸，因為沒有人類能在這種數量下保持真正的審查力度。「暗工廠」模式中的實際安全性並非來自於移除驗證。而是來自於用一種可以擴展的不同驗證方式，取代了另一種驗證方式（緩慢、耗費精力、且不一致的人類注意力分散在數百個重複的差異上）：確定性的建置和測試驗證，它在第 1 個差異和第 800 個差異上產生完全相同的嚴謹度，並且零注意力疲勞。
這也正是 Planner 階段使用基於編譯器的靜態分析而非 LLM 判斷來進行排序的精確原因。在系統中任何可以用確定性檢查取代判斷呼叫的地方，都應該這麼做，因為確定性檢查是這個架構中唯一可以在事後真正被稽核的部分。你可以完全重現靜態分析器發現了什麼。但你無法完全重現一個語言模型「覺得」某個特定遷移順序是正確的原因。
仍然需要人類的地方，以及界線在哪裡
這種模式並非「完全移除人類然後祈禱」。每一個可信的已發布版本——Google 的生產系統、學術界的「環境參與循環」研究、OpenAI 自己的手冊——都為人類判斷必須保留的地方劃定了明確的界線。
一項關於 Agent 驅動的函式庫遷移的量化研究，其一致發現是：Agent 能可靠地達到高遷移覆蓋率，正確識別需要哪些 API 變更，但特別是在更複雜的案例中，它們難以保留整體應用程式的行為——在這些案例中，成功的遷移需要理解意圖，而不僅僅是匹配語法模式。根據該發現的直接建議是，針對確定性驗證標記為高風險或低信心度的檔案子集，設置一個「人在迴路中」的檢查點，而不是針對整個批次。
在實務上，這產生了一個分層系統。靜態依賴分析歸類為小型、隔離良好且結構簡單的檔案（這是任何真實遷移中的大部分），會通過完全自動化的循環，除了確定性的建置和測試關卡外，完全不需要人類介入。而被標記為複雜、深度互連或觸及業務關鍵邏輯的檔案，則會被路由到一個佇列中，在合併前進行實際的人類審查，即使是在一個其他部分完全自動化的系統中也是如此。
這種分層方法是「800 個 Agent，零人類逐一審查」這個說法的現實版本。這並非指人類永遠不會查看任何東西。而是指系統被特別設計，將 95% 的機械化、低風險工作透過完全自動化處理，同時將稀缺資源（真正的人類判斷力）集中運用於少數確定性驗證無法複製、且人類判斷力能真正增加價值的案例上。
為你自己的程式碼庫建置這個模式
這個模式向下擴展和向上擴展一樣乾淨。無論你是運行 800 個平行 Agent 來處理一個大型生產程式碼庫，還是用少數幾個序列化的遷移任務來處理一個單一儲存庫，這四個相同的角色都適用。
從 Planner 開始，並克制住讓它變成 LLM 的衝動。如果你的遷移有任何形式的依賴結構（檔案匯入、共享介面、建置順序），請使用適合你語言的實際靜態分析工具來機械式地建立那個依賴關係圖。這個單一決策是整個系統中槓桿效應最高的決策，因為下游的每個階段都會繼承 Planner 所做的任何排序錯誤。
將每個單一任務的範圍限制在依賴關係圖允許的最小範圍內。一個檔案、一個模組、一個清晰界定的變更單位，並附上一份明確的簡報，說明需要做什麼以及為什麼。抵制為了效率而將多個不相關的變更合併到一個任務中的想法，因為狹窄的範圍是讓驗證階段的「通過或失敗」判斷變得明確無誤的關鍵。
隔離每個任務的執行環境。至少為每個任務建立一個全新的 git worktree，如果你以任何實際規模運行，則需要一個完整的沙盒環境。這不是可選的基礎設施開銷。這是讓平行化變得安全、並讓單一 Agent 的錯誤被限制住而非傳染開來的關鍵。
在建立其他任何東西之前，先建立確定性驗證。編譯成功、測試套件通過率、以及（如果可以建構的話）行為等價性檢查。這個組件取代了「Agent 說它可行」，變成了「它是否真的可行」。而這也是大多數自行建置的遷移嘗試完全跳過的單一組件，這正是那些嘗試在任何有意義的規模下失敗的確切原因。
明確地設定重試循環的上限，用一個數字，而不是一個感覺。在運行任何東西之前，先定義「這個任務卡住了」的樣貌，並將卡住的任務自動路由到人類佇列，而不是讓它們無限消耗資源，或者更糟的是，默默地回報虛假的成功。
頭條數字背後的真正教訓
無論在任何特定的大規模遷移中實際運行的數字是多少——800 個 Agent、80 個、還是 8,000 個——頭條數字都是故事中最無趣的部分。有趣的部分在於，這些 Agent 中沒有任何一個被單獨信任來決定自己的工作是否正確，而整個系統正是圍繞著這種不信任來設計的，而不是無視它。
暗工廠並非因為沒有人在看而在黑暗中運行。它之所以在黑暗中運行，是因為「看」這項工作已經完全轉移到了機器本身內部——轉移到了編譯器檢查、測試套件和依賴關係圖中。這些工具每次都會產生同樣嚴謹的答案，無論是處理第一個檔案還是第八百個檔案，沒有疲勞，也不會產生要求人類連續數千次重複相同判斷時所帶來的不一致性。
這就是當前所有在生產環境中運作的此類模式背後的真實模式。不是對更大模型抱持更勇敢的信任。而是一種更有紀律的拒絕，拒絕讓任何單一組件（無論是人類還是 AI）成為自己工作的唯一評判者。
關注 @cyrilxbt 以獲取更多 AI 內容
