軟體工廠的本質，就是將循環大規模地運用。你可以讓真人參與循環（光明工廠）：以判斷力和專注力來換取速度，並承擔可能出錯的風險。或者，你也可以完全繞過人類（黑暗工廠），讓那些 Agent 自行規劃、建構和部署程式碼，而無需任何人真正去檢視細節。但一旦人們停止閱讀，他們就會停止理解你的軟體。你現在最艱鉅的任務，就是決定要建立哪些檢查機制，以及要賦予多少自主權。
「軟體工廠」這個概念，最早可追溯至 Bob Bemer 在 1968 年發表的論文〈程式生產的經濟學〉。半個世紀以來，許多人夢想將軟體開發變成一種可重複、可量化的生產流程（就像在工廠裡沖壓汽車零件），而非孤立的個人技藝。長久以來，這個夢想通常（雖非絕對）都以失敗告終，部分原因在於「沖壓」想法這件事本身就非常困難。
但在過去兩年，情況劇變，現在我們有充分的理由重新審視這個古老的夢想。由於其中的一些細微差異很容易被忽略，因此我們有必要精確地釐清，究竟什麼才是真正的新氣象，而什麼又可能是偽裝成新機會的舊陷阱。
@dexhorthy，HumanLayer 的共同創辦人，最近在 AI 工程師世界博覽會上發表了一場精彩的演講，題為 「僅有框架工程是不夠的：軟體工廠為何失敗。」 非常值得一看。
循環是原子。工廠是規模化的循環。
結構決定一切，一切都始於微小的單位。整個堆疊其實就是三個層層疊加的概念：循環、框架和工廠。
循環，就是一個 Agent 重複執行單一任務：收集情境、採取行動、檢查結果，然後重複，直到滿足某個條件。它是 Agent 運作的最小單位，其上的一切都只是循環的堆疊。
循環工程的重點在於，你不再逐一步驟地提示 Agent，而是設計一個小型系統，由它來為你產生提示。
框架，是圍繞著循環的圍牆：它運行的沙箱、它能觸及的工具、在運行間留存下來的記憶，以及決定何時「完成」的閘門。循環是行為；框架是該行為運行的環境。
給一個未經處理的模型，卻不提供框架，它會快樂地無限循環下去。框架是圍繞著它的一切，讓它的運行既實用又安全。
軟體工廠，是許多個受框架約束的循環同時運行，由一個工作佇列供給任務，並通過審查閘門流入生產環境，而人類則從上方掌握全局。它不是一個更大的 Agent；它是一張由循環組成的組織圖。
最終的典範轉移，將從撰寫程式碼，轉變為建構和運行那個會寫程式碼的工廠。工作的單位向上提升了一個層級，變成了循環、框架，以及它們之間的流程，而非個別的程式碼差異。
循環 → 框架 → 工廠。工廠不是一個更聰明的 Agent；它是許多受框架約束的循環，共同餵養一個審查閘門，並由人類掌握外部循環。圖中描繪的工廠
Dex 花最多時間講解的核心投影片非常出色，因為它是一張清晰的接線圖，將一個原本顯而易見的循環視覺化。以下是我對它的理解：
工廠是一個封閉迴路：意圖和生產訊號餵養一個佇列，框架進行建構，自動化檢查和審查閘門進行把關，部署將它送出，監控則將生產環境的狀態轉化為訊號。意圖源自工程領導的願景，以及工程師的直接意見，流入一個待辦事項佇列。由事件和使用者請求驅動的訊號，同樣驅動著這個佇列。
框架，就是從佇列中挑選一個項目，並為其建立變更的工具。在框架之外，我們可以看到所有為了讓變更安全地進入生產環境所需的自動化檢查。這些自動化檢查同時運行，毫不費力，無需工程師有意識地參與，這都要歸功於 CI、測試、靜態分析和各式各樣的掃描。這裡唯一的決策點就是審查閘門。獲得批准後，變更會被部署並在生產環境中監控，而監控數據則會回饋到最初啟動循環的訊號中。
總體來說，這個圖表中的每個區塊幾乎都是零成本：生成、測試、掃描。它們都能以可忽略不計的成本大規模運行。只有一個昂貴的區塊頑固地抗拒規模化，那就是審查閘門。那個閃閃發亮的琥珀色區塊代表「判斷力」，這也正是我們能否讓開發變得更快、更頻繁的爭論核心所在。
為何稱之為「黑暗」
黑暗工廠在燈光全滅的環境下運作，因為廠房裡只有機器，而機器不需要光線就能看見。黑暗軟體工廠也是一樣的道理：程式碼在沒有人類閱讀過的情況下就被部署，僅由其他機器驗證。
這個意象源自製造業。它的根源是物理的，而非數位的，始於那些關燈後由機器人進行作業的工廠。日本發那科公司自 2001 年以來就一直在營運這種關燈工廠；小米在 2024 年也開設了一座高度自動化的自有黑暗工廠。它們的共同點是，產品在沒有任何人類閱讀過任何內容的情況下就被組裝並出貨。當「閱讀」這個行為從流程中被移除時，「黑暗」就隨之降臨。
我借用這個概念，並非為了它的氛圍或作為一種貶義。儘管這個詞彙聽起來有點毛骨悚然，但這裡的「黑暗」只是一個簡單的物理事實陳述：原始的工廠車間，只是沒有了光線。在軟體中，車間就是程式碼差異。無論是誰寫了那段差異、誰審查了它、誰部署了它，那些人類都不在了，留下的只有一個僅由建構它的機器所驗證的差異。
要實現這一點，出奇地容易，至少在初期是如此。這很容易，因為缺少的那個審查步驟會阻礙一切。它的缺席，會讓你覺得團隊的垂直處理量突然大幅提升。感覺就像突破了音障。儘管看似容易，但要長久維持這些黑暗工作流程，並承受其隱藏成本，卻比想像中困難。
僅有框架工程是不夠的
隨著模型與世界及彼此互動，編排、沙盒原型設計和工具呼叫的框架將變得越來越強大和有效。然而，在長期維護程式碼庫品質，並處理增量變更的過程中，存在著模型內在的缺陷，我有充分的理由相信，僅靠模型最終將在這場對抗理解債的戰爭中落敗。
理解債，是指現有程式碼量與人類仍能理解的程式碼量之間日益擴大的差距。黑暗工廠不僅不會償還這筆債務，反而會以最快的速度累積它，而所有測試結果卻一路綠燈。
這是一個重要的區別，因為模型在某些任務上表現出色。但對於任何非立即性的、影響程式碼庫小範圍的變更，特別是在複雜的既有系統中，純粹由模型驅動的自動化編碼將面臨無法逾越的障礙。新開發的應用程式、週末玩具專案和 side projects 都類似，通常幾個月的開發週期就足以讓事情運作起來，或至少足夠接近。
但一個已經開發了十年以上的企業級系統，則是另一回事；它必須在專業環境中，以專業的步伐進行維護。專案進行到三到六個月時，你已經淹沒在從未讀過的程式碼中。這種環境，特別是生產環境程式碼所施加的限制，會讓即使是強大的 Agent 也表現不佳，這與開發者在週末玩具專案中所享受的「氛圍編碼」形成鮮明對比。
Dex 根據經驗指出，這是一個重大的失敗點，其嚴重程度甚至需要進行艱鉅的手動除錯才能定位。這來自於他運作一個完全自動化的程式碼工廠約四個月的經驗，期間沒有人類看過被寫出來的程式碼。這個經驗背後隱藏著兩個相互衝突的指標之間的取捨。一個是最大化 token 利用率，這是我們目前視為進步的數字。另一個，則是被悄悄最小化的數字，那就是在任何時刻，任何人類參與者對系統仍能理解的程度。
黑暗工廠真正擅長的，是在測試保持綠燈的同時，快速消耗乾淨的程式碼。當最終的清算時刻到來時，它不會是戲劇性的「一切全盤崩潰」。它會是安靜的，且為時已晚。
黑暗與光明是同一條 pipeline，只是燈光位置不同。光明版本不僅僅是在最後重新加入審查——它還將人類的判斷力向上游移動，應用於設計和架構。瓶頸從來都不是生成能力
軟體工廠的根本限制，不在於我們能產出多少程式碼，而在於我們能多快地驗證它。
反壓法則：你能賦予一個循環的自主權，不能超過你能廉價且可靠地驗證的範圍，一絲一毫都不行。驗證，而非生成，才是工廠真正的限制。
因為無限制的生成能力，與人類注意力這個有限且無法擴展的資源處於永恆的緊張狀態中，核心問題在於廉價生成與有限審查之間的鴻溝。看看這個漏斗：只要代表驗證的瓶頸沒有擴大，它就會堵塞。正如 Dex 所指出的，數量本身不是問題：我們真正受苦於過多的不良 PR。當你擁有高數量卻沒有值得信賴的閘門時，人為造成的缺陷是不可避免的。這又回到了反壓法則：自主權不能擴展到超過可以被廉價且可靠驗證的範圍。
第二階段的問題是，為什麼單純改進模型，不應該自動縮小它能生成的和能被驗證的之間的差距？在設計良好的系統上進行訓練，可以說比通過簡單測試更為困難：請記住，衡量架構卓越性的成本函數，不是以秒或分鐘為單位，而是以月或年為單位。要計算出清晰的梯度實際上是不可能的，因此，一個期望對複雜設計決策進行即時、清晰評估的系統，無法透過良好的範例來訓練。
生成是一張大嘴；驗證是狹窄的瓶頸。加快嘴巴的速度，只會讓瓶頸處的堆積更深。
重新點亮燈光
光明工廠是同一條 pipeline，只是在判斷力所在之處保持燈火通明。Agent 仍然負責大部分的建構工作，但人類在成品出貨前會閱讀它，並且在錯誤代價高昂的地方，燈光會一直亮著。
光明版本並非將審查附加在最後，而是將人類判斷的環節向上游移動，在 Agent 開始循環之前，就介入產品、設計和架構。
花在那前半小時的功夫，好處在於能減少後續的實作時間。它能將冗長、令人沮喪的程式碼審查，轉變為快速閱讀一份兩百行的計畫。你可以在決策被實作之前就進行審查，這樣之後你就不需要在兩千行生成的程式碼中追尋，才能弄清當初的決策是什麼。有些決策成本高昂且影響深遠，你需要在成本開始累積之前，就讓人早點介入。當然，即使你花了時間在前端，有時還是需要審視程式碼差異。
你可能會覺得這聽起來一點都不酷。你說得對。這個安全網，是由我們一直都知道但大多忽略的、非常普通的架構實踐所組成的：良好的型別和方法簽名，以便錯誤能在編譯時就被捕獲，而不是在生產環境中；測試接縫，讓我們可以固定行為，使變更易於觀察；佈局程式碼，讓下一個閱讀者（無論是人類還是模型）知道去哪裡找到他們關心的東西；保持呼叫堆疊短小且易讀；保持元件邊界清晰，使變更不會有巨大的影響範圍；以及依賴注入，讓我們可以替換其中一個元件。這些都不是新鮮事。我們一直說我們在乎良好的架構。但現在，既然我們使用了自動化編碼 Agent，這個架構終於發揮了第二個作用：作為一個廉價且難以偽造的安全網，來抵擋 Agent 可能犯下的錯誤。
這個安全網必須存在於模型之外，因為模型本身無法提供它。那些感覺最能幹的編碼 Agent，如 Claude Code 和 Codex 等，都是針對它們自己的框架和工具進行強化訓練的：它們熟悉所有工具和業界慣用語，但對於長期可維護性等概念卻不熟悉。我們一直掛在嘴邊的審慎架構，就是用來捕捉這筆債務的工具，而我們對它的投資，正是我們在買回自己的自主權。
將它與安全的基礎設施結合，你就會有一些緊湊、低風險的循環可以無人值守地運行。Horthy 在最近的一篇文章中描述了一個例子：一個每晚執行的 GitHub Actions cron 任務，專門修正一種反模式（例如 lint 違規或非必要的 optional prop），自動提交（commit）並開啟一個小型 pull request，這樣團隊早上醒來時，就會看到一個稍微好一點的程式碼庫，以及一個短到足以閱讀的差異。但對於那些風險足夠高的循環，你絕對不想冒著醒來時發現認證系統、計費引擎或公開 API 合約被破壞的風險。在這些地方，請保持燈火通明，並相信一個擁有判斷力以及對系統真正運作知識的人，能夠抓住錯誤。
什麼樣的循環能贏得「黑暗」資格
這個規則，無論你稱它為反壓、驗證，還是電燈開關，都適用。
一個循環要獲得完全自動化的資格，只有在檢查成本低廉、執行頻率高，並且依賴於難以偽造的事物時才能成立。綠燈/紅燈的判斷器、型別閘門、屬性型測試，以及結合了真實評分標準的審查 Agent，都符合條件。你還需要判斷器能立即回答，並且不會隨時間漂移。當「完成」不僅可以由你，還可以由機器來證明時，你就達到了自動化。
短循環比長循環更容易驗證。Dex 的經驗法則：一個 Agent 在 3 到 10 步之內表現良好，但超過 20 步後就開始偏離主題。原因是上下文累積——Agent 拖得越久，就越容易偏離方向。當循環很短時，驗證它的成本就很低。冗長的循環會將錯誤隱藏在角落裡，這也就是說，它們從未贏得「關燈」的資格。
保持燈火通明則是相反的情況。當一個錯誤答案的代價高昂，且只有人類才能發現它時，這個循環就需要被審查。那些無法被測試發現的微妙生產環境錯誤、大的影響範圍，以及會影響一年或更長時間工作的決策，都符合條件。在這些情況下，你的注意力才是真正的產品，是昂貴且不可或缺的。
危險在於，你忘記逐一判斷每個開關，而是將它們全部設定為同一種模式。全部設定為黑暗，你就會陷入四個月後全部拆掉重來的困境。全部設定為光明，就沒有人能及時完成審查，你就會陷入巨大的瓶頸中。困難且需要技巧的工作，在於決定每個開關應該放在哪裡。
循環、圖形還是狀態機？
你應該閱讀 @DavidKPiano 的〈2 分鐘搞懂狀態機〉
當你交給一個 Agent 任務時，你可能會圍繞它建立一個圖形，無論你稱之為有限狀態機，還是一組條件式連結的服務呼叫。這是一種框架，將軟體視為不僅遵循抽象規則，而是遵循結構化的工作流程：每個節點都是一個明確的步驟，節點之間的每條邊都是一個明確的條件。
這聽起來有很多結構，但其實大部分在任何軟體中都已經存在，因為任何程式碼都可以表示為一個控制流程圖。因此，唯一真正的創新點在於，一個堅持自主權的 Agent，實際上只是在一個特定的圖形上行走，它的自由度被限制在節點內部。而以下是人們經常忘記的部分，也就是 Dex 一年前寫下的內容：軟體本來就註定要有這種結構。我們以前用流程圖來繪製程式，這是有原因的。
真正的新做法，是試圖拋棄圖表，轉而依賴一個循環，讓模型透過一次次工具呼叫來選擇路徑，直到它自行宣告完成。這感覺像是一種解放，直到它遇到一個開發了十年的程式碼庫，而現在每個人都在重新發現的紀律——掌握你的控制流程——實際上只是讓圖形重新圍繞著循環。因此，我們是否應該從循環回到圖形的問題，幾乎等於承認我們從一開始就需要流程圖。
以下是它在實踐中的樣子。以修復一個 bug 為例。作為一個純粹的循環，你坐下來思考：找出問題所在、修改一些程式碼、執行測試、看看結果，如果這次執行沒有解決問題，就循環回去重新開始。整個過程是邊做邊決定的：你要追查哪個問題、要修改哪段確切的程式碼、要執行哪些測試以及以什麼順序執行、你是否要執行測試、以及你是要再試一次還是宣告勝利。
作為一個圖形，你做的第一件事是規劃出應該發生的事。重現 bug 或去詢問更多資訊、找出原因、嘗試修復、執行測試，讓失敗的執行回到修復步驟，而成功的執行則進入審查，只有批准才能達到「完成」狀態。Agent 在每個盒子內部仍然很聰明；它只是不能偏離你允許的路徑。Santi 用一張圖表清楚地說明了這個差異，讓兩者的不同一目了然。
當然，這個圖形的真正吸引力在於，它本身就是一張被繪製出來的反壓圖。你放棄了 Agent 的部分自由，換來了強制性的檢查和清晰的失敗點，這樣當一次執行失敗時，你可以指出是哪個節點導致了失敗。這與 Dex 那句直白的觀點出於同一個直覺：大多數所謂的 Agent 其實一點都不「具備能動性」，它們「大部分是確定性的程式碼，只是在恰到好處的點上加入了 LLM 步驟。」這不僅僅是人們目前碰巧在建構時產生的結果：你可以在 LangGraph 和 LlamaIndex Workflows 中看到這個模式，在 Jerry Liu 的混合工作流程圖覆蓋 Agent 的方法中（外部循環在執行時會生長出部分圖形），以及在 David Khourshid 的提醒中看到，這其實就是狀態機和 Actor 模型換上了新裝。
需要澄清一下，因為這個詞已經被嚴重濫用了：當我反覆稱之為圖形時，我不是指知識圖譜。我指的是預先定義好的有向圖，說明工作應該如何流動，包含條件式邊緣，賦予循環一個你真正可以信任的形狀。
人類最終的位置
請注意，人類從未離開工廠。他們只是換了個位置。
我認為工程師需要越來越專注於掌握 外部循環。 Agent 可以調查 bug、撰寫診斷報告、實作修復、執行測試，並寫出報告。這是內部循環的執行，它們可以像任何人一樣高效地完成。但這從來就不是真正的重點。你掌握的，是我所謂的外部循環：決定這是否是解決問題的正確方法、驗證診斷和實作是否完善、批准變更，並承擔判斷錯誤的後果。這兩個循環之間的界線，是證據：程式碼差異、測試結果、日誌，以及一個將它們連結起來的簡短說明。型別、接縫和評分標準，讓你無需為每個變更耗費大量心力，就能監督這一切。
這樣說很有用：你不再是在生產線上手寫變更；你是在生產線的末端設計它，並守護著閘門。你可以做很多事情來讓模型更好、框架更強大，但我觀察到，識別那些長期成本高昂的問題，通常不是你可以自動化處理掉的事情。這份工作的核心，仍然是比任何紙上談兵和計算能力更好地運用你的判斷力。
機器人在黑暗中運作得很好，但人類需要看到他們在做什麼。如果工廠車間裡一片漆黑，你什麼都看不見，甚至找不到電燈開關，那就是危險所在。
Pangram 評分 本文為 100% 人類書寫。
