在軟體開發流程中引入 AI 代理人（AI Agents）已成為提升生產力的趨勢，但許多企業最初的實作方式是讓代理人在開發者的個人筆記型電腦上運行。然而，當 AI 代理人的任務量增加且複雜度提升時，本地端執行會面臨嚴重的資源限制與安全風險。外送平台 DoorDash 針對此問題開發了名為 Flux 的雲端平台，將 AI 工程任務從本地端遷移至雲端環境，旨在實現大規模、自動化且受控的工程工作流。
本地端執行的三大瓶頸
DoorDash 在推動 Flux 之前，發現將 AI 代理人運行在開發者筆電上存在三個核心問題。首先是硬體資源限制，本地端的 CPU 與記憶體無法支撐高強度的並行計算，且代理人的運行依賴於開發者設備的在線狀態，無法實現真正的非同步自動化。其次是安全風險，本地代理人通常直接繼承開發者的權限，這意味著 AI 可能在無意中獲取過高的系統權限或存取敏感憑證。最後是監控缺失，企業難以追蹤哪些代理人在運行、存取了哪些內部系統，以及這些操作是由誰發起的。
Flux 平台的四大核心架構
為了克服上述限制，DoorDash 構建了 Flux 平台，其運作邏輯基於四個基礎原語（Primitives），確保 AI 代理人在隔離且可監控的環境中執行。
第一是雲端沙盒（Cloud Sandboxes），這是提供隔離執行環境的基礎。Flux 使用 Firecracker 微型虛擬機（microVMs）來隔離每個代理人的工作負載。這種技術能快速啟動獨立的虛擬環境，並為其配置必要的程式碼庫、開發工具、秘密金鑰與執行環境。DoorDash 實現了極高的效能，其 95% 的服務水準目標（SLO）將端到端的沙盒設定時間控制在 5 秒內。
第二是代理人閘道（Agent Gateway），這是一個基於 MCP（Model Context Protocol）的內部閘道。MCP 是一種讓 AI 模型能以標準化方式與外部數據或工具互動的協議。透過此閘道，Flux 能為代理人提供精確的範圍權限（Scoped Permissions），並記錄所有活動日誌，以便進行稽核與政策執行。
第三是可複用的劇本（Playbooks），使用 YAML 格式定義。劇本詳細規定了任務目標、所需工具、權限邊界與驗證機制。值得注意的是，劇本允許將 AI 驅動的靈活步驟與確定性的程式碼（Deterministic Code）相結合，確保在需要高度可預測性的驗證環節中不會出現 AI 幻覺。
第四是調用界面（Invocation Surfaces），讓工程師能透過 Slack、GitHub、定時任務（Cron）、命令列或對話式界面輕鬆觸發工作流。
從代碼審查到全自動化工程流
Flux 的應用路徑是由淺入深。起初，DoorDash 將其用於自動化代碼審查（Automated Code Review），因為這類任務頻率高且成效易於衡量。隨後，應用範圍擴展至 CI 故障排除（CI Triage）、值班任務（On-call tasks）、維護工作流以及基於工單的開發（Ticket-driven development）。
根據 DoorDash 提供的數據，Flux 在 2026 年的單月內已自動執行了 13 萬項工程任務，每週支持超過 2.5 萬次自動化代碼審查，並擁有超過 300 個劇本與每週 1 萬次以上的調用。為了增加透明度，DoorDash 將 Slack 的整合方式從私有頻道改為公開討論串，讓工程師能觀察代理人的執行過程與結果，並學習其他團隊如何委派 AI 任務。
規模化 AI 代理人的實務啟示與限制
DoorDash 的經驗顯示，當 AI 代理人開始處理背景工作與併發執行時，開發者的核心挑戰將從選擇哪個 AI 模型（Model Choice）轉移到如何進行控制（Control）。這包括身份認證、權限管理、沙盒隔離、稽核日誌、配額限制以及在緊急情況下能立即停止所有操作的終止開關（Kill Switch）。
這種將執行環境雲端化的趨勢也見於其他領先工具，例如 GitHub Copilot 亦提供雲端沙盒環境，以避免消耗開發者的本地資源並加強對文件系統與網路存取的控制。
然而，這種架構也帶來了新的維運壓力。企業必須維護一套極高可用性的微虛擬機基礎設施，以確保沙盒啟動速度不會成為開發瓶頸。同時，定義精確的 YAML 劇本需要投入大量的人力成本，以確保 AI 在安全邊界內運行且不會產生不可預期的副作用。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。