軟體工廠導入指南：從起步、穩健到全面運作

軟體工廠方法（一種在雲端運行的閉環 Agent 迴路）正日益普及，但採用起來可能令人卻步。在這篇文章中，我將介紹「爬行、行走、奔跑」的步驟，協助你從本地互動式 Agent 過渡到自動化的雲端開發。

爬行

我與許多工程主管和平台工程師交流時發現，他們已經透過使用雲端 Agent 建立簡單的自動化流程，開始了構建軟體工廠的「爬行」階段。

可以將這些自動化視為：觸發器 → Agent 活動。

例如：

問題重現與分類：讓 Agent 檢視所有新提交的 Issue，進行重現並標記標籤。
程式碼審查：當 PR 開啟時自動審查並留下評論
監控：讓 Agent 回應 Sentry 警報，除錯並修復問題
CI 自我修復：透過識別需回滾的 PR 或需解決的合併衝突來修復損壞的 CI
文件自動更新：更新面向用戶的文件並生成變更日誌
驗證：browser-use 和 computer-use Agent 透過視覺方式進行 QA 並驗證變更
簡單錯誤修復：Agent 識別並修復用戶報告的簡單問題

這些方法的共同點在於，它們都實現了軟體生命週期中某個獨立環節的自動化。從簡單的自動化入手是一種低風險、低成本的方法，有助於培養如何有效運用 Agent 處理更複雜、多階段任務的直覺。

警報監控的自動化範例

這些自動化可能是基於自建基礎設施（例如將 Claude Code SDK 放入 Docker 容器並配置伺服器以觸發它），或是使用專為在觸發條件下運行 Agent 而設計的通用雲端 Agent 自動化平台。它們也可能使用專門針對生命週期中某一階段的完整平台（例如專門的 Agentic 程式碼審查工具或 AI SRE）。

從零散的點狀自動化開始沒問題，但大多數團隊最終都會遇到這種方法的瓶頸。

具體來說：

取決於設置方式，這些自動化可能無法共享上下文。這意味著當你改進某一方面（例如程式碼審查）時，這些改進不會延續到其他階段，如分類和 QA。
缺乏全局視角來評估這些一次性自動化是否真正提升了整體生產力，也沒有系統化的方法來測試和改善你關注的高層級指標，例如每 PR 成本、週期時間、自動化比例等。要追蹤這些指標，你需要一個跨開發階段的系統。
每個點狀解決方案都會產生自己的設置和維護負擔。它們擴大了需要管理的安全攻擊面。它們沒有統一的觀測介面。團隊最終會希望擁有集中式的配置、稽核和治理。

行走

所有這些問題都指向對更全面方法的需求。已經完成「爬行」階段的組織會問自己：「我們想要什麼樣的系統，才能真正擴展 Agentic 開發？」

更具體地說，他們會問：

開發應該在哪裡進行？本地還是雲端？透過什麼介面？
成功的自動化開發流程是什麼樣子？關鍵指標有哪些？
我們的 AI 主權立場是什麼？擁有編碼 Agent 數據有多重要？我們應該多大程度上依賴模型供應商？
我們計畫如何隨著時間改善開發流程？如何在加速交付的同時控制成本？我們如何知道自己在進步？
隨著模型和 Agent 的改進，我們如何確保未來的適應性？我們是否考慮了可能影響模型存取權限的監管風險？
工程師究竟應該如何參與開發流程？設計師、PM 和其他建設者呢？
我們如何保障開發安全？如果我們的軟體生產流程遭到入侵，我們的應對計畫是什麼？

大多數深入思考這些問題的工程主管和平台團隊，最終會傾向於採用雲端軟體工廠方法。他們希望：

預設在雲端進行開發，因為給 Agent 提供沙箱比讓它在本地自由運作更安全
對編碼 Agent 及其存取的工具和系統進行集中式治理
完整記錄 Agent 的操作軌跡，以便稽核和理解生產力
在模型和執行框架上保持選項靈活性，以最小化風險並優化效能
將開發整合到團隊已經使用的所有工具中（例如 Slack/Teams、Jira、Github 等）
為人類提供接管控制的逃生門，無論是透過引導即時 Agent 還是將工作帶入內部開發迴路
一個能在開發各階段跨 Agent 運作的共享上下文層
允許進行測試、評估和基準測試的方法，讓團隊有信心系統正在隨時間改進

一旦公司決定採用工廠方法，問題就變成：如何從現有的點狀自動化過渡到那裡？這通常取決於你是 (1) 圍繞這些自動化構建更多基礎設施，還是 (2) 轉移到像 Warp Factories 這樣提供工廠基礎設施的平台。

請注意，我不會將其定義為傳統的自建 vs. 採購決策。無論選擇哪條路徑，你都應該預期內部團隊需要進行一些構建工作，因為要使工廠方法奏效，該工廠必須與團隊的上下文和工作流程深度整合。這更像是一個問題：你是完全從頭開始構建自動化基礎設施，還是與那些為你提供起點優勢的合作夥伴攜手合作。

例如，無論選擇哪條路徑，你都應該預期要構建特定於組織的技能，並針對你的代碼庫進行調優。你應該預期要暴露並配置特定於組織的 MCP 和內部上下文來源。但是，你可能不想構建用於運行和管理 Agent、引導它們、移交工作、衡量其效能、執行電腦操作等的雲端基礎設施。經驗法則是專注於構建特定於你組織的部分，而不是每個組織都需要的部分。

無論你採取哪種方法，我建議在行走階段最大的里程碑是在一個簡單的產品表面上端到端地部署第一個工廠。這可以是你的行銷網站或內部應用程式。

從一個簡單的專案開始的好處是，可以在低風險和極簡複雜度的情況下啟動整個迴路。增加更多的倉庫、代碼行數、服務依賴關係、人類利益相關者等，會增加複雜度，並可能讓你感覺還沒準備好進行自動化。最好先調整好一個簡單的迴路。

目標是一個從分類 → 規格 → 實施 → 審查 → 驗證 → 監控的多 Agent 系統。更具體地說：

新 Issue 進入系統，透過人類或監控 Agent
分類 Agent 運行，嘗試理解並重現 Issue。如果確定任務可自動化 → 交給實施 Agent。如果因範圍問題需要規格 → 讓規格 Agent 與人類迭代以制定規格。如果模糊不清 → 獲取人類輸入並重新運行，或直接決定暫時擱置該 Issue
[如有必要] 規格 Agent 運行，人類審查規格，然後傳遞給實施 Agent
實施 Agent 編寫代碼
程式碼審查 Agent 審查代碼
驗證 Agent 執行電腦操作或其他驗證
人類審查代碼和驗證輸出。如有必要，返回步驟 2、3、4 或 5
CI / CD
發布
監控 Agent 運行，如有需要則創建 Issue，從而完成迴路

在 Warp 內部，我們的行走工廠自動化約 75% 對 warp.dev（我們的行銷網站）的變更。與 Warp Terminal（65k GitHub 星標，近百萬活躍開發者，100 萬行原生 Rust 代碼）不同，我們的行銷網站是一個相當簡單的應用程序。請注意，這裡所說的「自動化」是指從人類輸入到功能發布，全程透過工廠完成，除了描述我們想要的變更外，幾乎沒有人類介入點，无论是在 Slack 還是在我們的任務追蹤器中。

奔跑

只有當你在一個簡單專案上建立了基本迴路後，才應該擴展到更複雜的專案。擴展工廠需要更穩健的基礎設施。

具體來說，隨著規模擴大，某些瓶頸會出現：

讓遠端開發環境在大專案上正常運作很困難。更多的倉庫、代碼行數、服務依賴關係，都會使自動化變得更難。
隨著技能和代碼等的增多，很難判斷你對工廠所做的更改是對開發產生正面影響，還是只是造成混亂
由於 Agent 在更複雜的代碼庫上工作，你需要更強大的模型且 Agent 需要運行更長時間，因此你自然面臨更高的成本風險。模型路由和執行框架的選擇變得更加重要。
隨著你將工廠方法應用於關鍵任務的面向用戶應用程序，安全性和稽核變得越來越重要
更多的應用程序利益相關者意味著更多的人類協調和簽核。你會希望有一個支持多人輸入和審計軌跡的工廠解決方案
不可避免地，PR 會開始堆積，因此你需要一個明確的策略來決定哪些內容進行程式碼審查，以及如何利用 Agentic 驗證和 QA
你會需要更穩健的工具來閉合迴路，確保發布到生產環境的變更具有高品質、不崩潰等

在我看來，讓規模化的工廠順利運作，將是未來幾年最有趣的軟體工程挑戰之一；軟體工程正在轉變為工廠工程。能夠使其工廠穩健、可靠且自我改進的組織，將能以更好的成本交付更多產品，並獲得競爭優勢。

要讓工廠真正高效運轉，需要大量的投入。在 Warp，我們將此視為完整構建你的工廠技術棧：

我在這篇文章中詳細介紹了每一層：

https://x.com/zachlloydtweets/status/2097739116720910619

有幾個關鍵點值得特別指出，它們可能並不顯而易見：

工廠即代碼：你可以做出的關鍵選擇之一是將工廠定義為代碼。這使得測試不同的工廠配置成為可能，以查看哪些配置最有效率、品質最高等。
多模型與多執行框架：你應該確保你的工廠能夠使用最新的模型，包括前沿模型和開放權重模型，並使用不同的編碼 Agent 執行框架，如 Claude Code 和 Codex。
數據所有權：你應該確保存儲並擁有從工廠輸出的所有數據——這是改善其運營的原材料。

在一個完全高效運轉的工廠中，關鍵特徵在於它是一個閉環、可測量、可改進的系統。這應該是目標。在這樣的系統中，每個人都在相同的上下文中公開工作，以完全受稽核和觀察的方式進行。Agent 本身也在觀察驅動系統的技能和配置，並提出改進建議。平台工程師能夠擴展系統，將其整合到所有內部系統中。工程主管可以看到生產力指標，並了解正在進行哪些更改以改善這些指標。整個過程是基於實證運作的，而不是憑藉感覺。

在 Warp，我們正逐漸接近這一願景。每一天，我們都在公開協作，調優我們的工廠，降低成本並提高吞吐量和品質。