文章作者： @SantoshPraneeth 和 @jeffizhungry
Flux 是 DoorDash 為工程師打造的雲端 Agent 平台。在 2026 年的單一個月內，我們就用 Flux 自動化了 13 萬個工程任務。Flux 自 2026 年第一季推出後便迅速擴展，目前已驅動 DoorDash 內部大量的背景工作流程，包括每週超過 25,000 次的自動化程式碼審查，以及每週超過 300 組獨特的 playbook 與 10,000 多次的呼叫執行。這些工作流程可以全天候、並行且無人值守地執行。
我們將逐一說明：那些讓我們無法再侷限於本機、筆電型 Agent 工作負載的限制、我們選擇自行打造 Flux 而非完全依賴託管編碼 Agent 的原因，以及 Agent 沙盒、MCP 閘道、playbook 與呼叫介面等平台基礎元件，如何讓 Agent 委派變得可重複且安全。
Flux 背景工作流程使用案例
DoorDash 在單一個月內的 Flux 使用概況，涵蓋自動化程式碼審查、playbook 執行與背景任務完成情況
我們的起點
過去一年來，使用者在筆電上執行 Agent 工作負載時，很快就遇到了各種限制：
- 資源與可用性。筆電的 CPU 核心數固定、記憶體有限、電池續航有限，而且這些資源都與裝置上的所有應用程式共享。Agent 工作流程經常需要並行執行建置、測試與大規模搜尋等運算密集任務，導致筆電很快就會不堪負荷。此外，這些工作流程也依賴裝置保持開機、連線與可用狀態；一旦工程師闔上筆電、失去連線或暫時離開，工作就會中斷。
- 安全管控。筆電通常擁有對敏感憑證與系統的廣泛存取權限，包括 SSH 金鑰、VPN 工作階段和已驗證的工具。讓自主 Agent 擁有同等級的存取權限，會帶來不必要的風險，並可能造成極大的爆炸半徑。本機環境也讓我們更難嚴格界定 Agent 可以存取什麼、以及存取多久。
- 可視性與可稽核性。當工作負載分散在各台筆電上執行時，執行過程既零碎又難以監控。我們很難掌握目前正在執行什麼、在哪裡執行、以誰的名義執行，以及它觸及了哪些系統或檔案。
我們解決這些問題的核心理念很簡單：
將任務委派給安全、自主的編碼 Agent，讓工程師能將更多精力投入創新、批判性思考與解決複雜問題。
為什麼我們選擇自行打造 Flux
託管的編碼 Agent 確實很有用，但它們迫使我們做出艱難的取捨：要嘛把敏感的程式碼與執行上下文送往第三方，要嘛開啟一條從第三方連回內部系統的通路。對 DoorDash 而言，真正的難題不只是讓 Agent 寫程式——那部分基本上已經解決了——而是要賦予 Agent 正確的環境、工具、權限、整合與約束。
我們的策略是掌握 Agent 周邊的基礎元件，包括編排、沙盒、工作流程、權限、整合，以及 Agent 要有效運作所需的 DoorDash 特定上下文。我們也把這些基礎元件設計成模組化，讓我們能靈活地為每項任務選用最佳的第三方工具，或在更需要深入掌控資安、整合、效能或使用者體驗時自行打造。
這些基礎元件讓工作流程的建立變得更普及，也讓系統更能適應未來的使用情境。由於它們能以不同方式組合，團隊不需要改動底層基礎架構，也不必規定每位工程師該如何組織自己的工作流程，就能建立新的 Agent 工作流程。例如，我們的程式碼審查與其評估測試都運行在 Flux 基礎架構上。
基礎元件，而非工作流程
構成 Flux 的四大平台基礎元件——沙盒、MCP 閘道、playbook 與呼叫介面——以及它們如何串接，將任務轉化為 Agent 能安全執行的工作
如上圖所示，Flux 圍繞四大平台基礎元件建構：沙盒、模型上下文協定（MCP）閘道、playbook 與呼叫介面。它們共同讓 Agent 委派變得可重複。Playbook 定義要執行的工作；雲端沙盒為 Agent 提供實際的執行場所；Agent 閘道控制 Agent 能存取哪些系統；呼叫介面則讓工程師能從自己熟悉的地方啟動工作並接收結果。
沙盒提供執行環境
本機 Agent 在互動式開發中表現出色，但非常不適合無人值守的工作流程。它們依賴個別工程師的筆電，與本機資源競爭，難以稽核，也無法在並行任務之間有效擴展。
Flux 將執行作業移到由 Firecracker 微型虛擬機器（microVM）支援的隔離雲端沙盒中，以實現硬體層級的隔離。每個沙盒都會預先配置任務所需的儲存庫、開發者工具、機密資料與執行期相依項目，為 Agent 提供完整的工程工作空間，同時也為 DoorDash 提供一致的執行、安全與可觀測性模型。
掌控這一層讓我們能支援真實的工程工作流程，包括跨多個儲存庫的變更，以及在單一工作階段中處理多個 pull request。Flux 在完整的端對端設定上，設定了 95 百分位數低於 5 秒的服務等級目標（SLO）——從啟動 microVM、複製所需儲存庫、安裝建置工具，到配置受支援的編碼 Agent 框架。
MCP 閘道提供受管控的存取
Agent 需要存取工程師日常使用的系統，包括持續整合（CI）、可觀測性平台、問題追蹤器、部署工具、程式碼搜尋、文件與服務中繼資料。但我們不應預設授予廣泛且不受限制的存取權限。
Flux 透過名為 Agent Gateway 的自建 MCP 閘道，將 Agent 連接到內部系統。每個 playbook 都會宣告所需的工具，而 Flux 只授予該任務所需的最小權限。所有動作都會被記錄，形成清晰的稽核軌跡。
這種閘道架構為我們提供了集中化的控制點，涵蓋身分驗證、授權、可觀測性、使用追蹤與政策執行，讓 Agent 的存取不僅更安全，也更容易大規模營運。
Playbook 定義工作內容
Playbook 是可重複使用的 Agent 工作單元——相當於 Flux 平台上技能與 Agent 驅動任務的 Docker 容器。它以單一標記式 YAML 檔案定義，將任務、輸入、上下文、技能、工具、權限、驗證、預期輸出與安全邊界封裝在一起，確保工作能一致地執行。
Playbook 可以結合 Agent 步驟與確定性步驟：前者提供靈活性與判斷力，後者則具備可預測性、成本更低且更容易驗證。這讓團隊能隨著需求演進，在 Agent 驅動執行與傳統程式碼之間搬移邏輯，而不需要重新設計工作流程。
呼叫介面：在開發者所在之處與他們相遇
同一個 playbook 可以從 Slack、GitHub、cron、CLI 或對話式技能觸發。這代表團隊可以只定義一次工作流程，然後從最符合當下情境的介面呼叫它：
- Slack：協作式委派
- GitHub：PR 與 CI 自動化
- Cron：週期性維護
- CLI：開發者直接控制，或透過技能呼叫
這正是讓 Flux 容易採用的原因。
經驗教訓
打造 Flux 讓我們在產品採用與基礎架構兩方面都學到很多，包括：
- 先從窄處切入，贏得信任。 我們從自動化程式碼審查開始，而不是試圖自動化整個軟體開發生命週期。程式碼審查頻率高、可衡量，而且工程師容易評估判斷。它提供了一個實際生產工作流程，讓我們在擴展到 CI 分流、值班任務、維護 playbook 與工單驅動的開發之前，先調整品質、延遲、成本與行為。
- 讓工作被看見。 我們第一個 Slack 整合為每次 Agent 執行建立私人頻道。這讓 Flux 對個人很有用，但沒有建立起團隊習慣。把工作移到公開討論串後，採用模式改變了。工程師可以看到其他人委派了什麼、觀察 Flux 逐步推進、審查輸出結果，並共同建立信任。
- Playbook 需要賦能。 可重複使用的工作流程不會因為平台存在就自動出現。工作坊與黑客松幫助團隊把重複性的維運工作轉化為 playbook。基礎元件讓自動化成為可能；賦能則幫助團隊辨識出哪些工作流程值得被編寫成 playbook。
下一步
我們將更深入探討讓 Flux 運作的平台基礎元件，以及建構新工作流程的開發者體驗。我們也會介紹我們在 Flux 之上建構的應用程式，包括我們內部的 Slack Agent——Flux Responder。
致謝
感謝 Adam Rogal、Adam Yarger、Andy Fang、Ashwin Kachhara、Fan Xia、Ivan Rudovol、Jason Prasad、Jialu Deng、Justin Block、Justin Deocampo、Justin Fan、Keith Lyall、Praneet Singh、Sean Chen、Tyler Berrett 與 Volanda Zhu 對這個平台與本文的貢獻。
