Daytona AI 代理運算與沙盒

AI 代理需要可組合的電腦，而不只是代碼執行

AI 代理需要具狀態且可組合的電腦——本質上是生產級沙盒——而非一次性、短暫的代碼執行盒。雖然簡單的隔離環境可以運行一段代碼並返回輸出，但複雜的代理需要類似人類筆記本電腦的環境：能夠維持狀態、暫停和恢復工作，以及訪問多樣化的作業系統（Linux, Windows, 和 macOS）以與舊版軟體互動。

轉向 AI 沙盒

Daytona 在 2025 年初從為人類工程師自動化開發環境轉向提供 AI 沙盒。這一轉變是由一個關鍵的市場洞察所驅動：代理的基礎設施需求與人類的需求根本不同。

在開發 MVP 期間，Daytona 發現代理開發者迫切需要一個能夠處理高併發且具狀態工作負載的運行時。這導致了快速增長軌跡，公司報告月增長 74%，且有些客戶每天運行近 850,000 個沙盒。

高效能基礎設施架構

為了實現 AI 代理所需的速度與狀態性，Daytona 採用特定的架構堆疊：

• 裸金屬部署： 在裸金屬而非虛擬機器 (VMs) 上運行，Daytona 消除了計算與存儲之間的網路延遲（例如，避免 EBS），從而顯著提升 IOPS。
• 自訂排程器： Daytona 使用自己的排程器來管理資源，避免了 Kubernetes 的開銷與複雜性，該公司發現其不適合此特定工作負載。
• 快速啟動時間： 該架構使單個沙盒能在約 60 毫秒內啟動。對於大規模場景，Daytona 能在約 75 秒內同時啟動 50,000 個沙盒。
• 具狀態快照： 模板和快照預先載入在裸金屬機器上，使代理能夠「關閉蓋子」於會話中，並立即返回完全相同的狀態。

處理尖峰 RL 與 Eval 工作負載

Daytona 使用量的重要部分——大約 50%——已轉向強化學習 (RL) 與評估 (eval) 工作負載。這些工作負載創造了一種以極端「尖峰性」為特徵的獨特基礎設施挑戰。

與遵循「追隨太陽」使用模式的背景代理不同（中午峰值，午夜最低），RL 與 eval 工作負載是不可預測且二元的。研究人員可能會瞬間請求 100,000 個 CPU，運行一批任務，然後降回零。這導致平均利用率較低（約 15%），但需要能夠處理 90% 峰值的容量。

Daytona 動態調整沙盒大小的能力可以即時防止記憶體不足 (OOM) 錯誤，這是競爭對手所使用的受管 Kubernetes 環境 (EKS/GKS) 常見的失敗點。

Windows 與 macOS 對知識工作的必要性

雖然 Linux 是大多數 AI 代理的標準，但全球大量知識工作被鎖定在運行於 Windows 和 macOS 的舊版應用程式中。

• RPA 機會： 世界上許多醫療、政府和金融領域的高價值工作發生在缺少 API 的應用程式中。為了讓代理自動化此工作，他們必須能夠像人類一樣操作電腦（Computer Use）。
• Windows 沙盒： Daytona 已開發出 Windows 沙盒，儘管其速度較 Linux 慢（以秒而非毫秒計），但提供了舊版應用程式自動化所需的環境。
• macOS 挑戰： 提供 macOS 沙盒受到 Apple 授權限制的複雜影響，該限制限制了每台機器上的平行 VM 數量，並將記憶體快照限制在相同的實體硬體上，阻礙了在叢集間移動工作負載以管理負載的能力。

AI 雲端的未來

Ivan Burazin 認為 AI 運算的未來不會像傳統雲端供應商 (AWS)，而是更像一種基於消費的 API (Stripe)。

開發者將不再管理複雜的基礎設施，而是透過無縫 API 與一組原始元件——沙盒、網路搜尋和代理專用資料庫——進行互動。隨著代理成為計算的主要使用者，瓶頸將從 GPU 轉移到 CPU 和網路，因為龐大的併發代理任務量創造了對通用計算的前所未有需求。