Back to all posts

無伺服器 Agent

無伺服器 Agent

打造一個 Agent 並不容易。

一年前,我們需要自己管理上下文與記憶體,思考 RAG 和向量資料庫,並非常仔細地調整工具呼叫的準確性。Claude Code / Claude Agent SDK 的出現改變了這一切。現在越來越多的團隊開始直接使用 Claude Agent SDK + VM 來建構 Agent。那麼問題變得更簡單了嗎?並沒有。

在 VM 中運行 Claude Code 依然是一件極具挑戰性的事。

  1. 每個使用者 Session 都需要一個獨立的 VM。在某些情境下,VM 的持久化能力確實有其用處,但這也讓 VM 難以升級和編排。舉例來說,從使用者的角度,他們希望安裝在 VM 上的軟體在幾個月後仍然可以使用。但 VM 上負責與編排層溝通的部分,也需要能夠順利推出升級。

  2. 大規模建立與編排 VM。單一 k8s 叢集大約支援數千個 Pod 的編排,對於應用服務叢集來說已經足夠。但對於每個 Session 都需要啟動一個 Claude Code Pod 的情境而言,就顯得捉襟見肘了。

  3. 使用 k8s 方案會面臨 k8s 本身帶來的延遲,難以達到 1 秒以內的效能。

  4. 使用 e2b 方案需要自行處理持久化,而且上傳與下載檔案的速度都非常慢。

  5. e2b 方案無法滿足特定的網路環境需求,私有部署也相當繁瑣。

我們如何解決這些問題?讓我們從歷史中尋找答案。把時間撥回十多年前,2012 年,世界上還沒有 Serverless,沒有 k8s,也沒有 Docker。後端工程師需要在實體機器上手動維護一個服務行程來運行服務。那個年代,ssh 和 ansible 是伺服器工程師的標準工具。服務行程嚴重依賴實體機器上的各種工具環境,要在不同實體機器之間保持一致的工具環境配置極為困難,大規模擴展是需要團隊提前很久就開始準備的大工程。我還記得有一次,一位工程師修改了某台機器的環境,卻忘記同步到其他機器,結果在生產環境中引發了一個極難排查的靈異 Bug。那段時期真的是一段非常痛苦的歲月。

2012 年,Docker 出現了。Docker 將所有工具環境打包進一個映像檔,解決了環境不一致的問題。社群逐漸意識到,在實體機器上的虛擬機器中運行的服務行程,可以像管理實體機器上的行程一樣被管理。但 Docker 的編排仍然需要工程團隊自行建構編排系統。而一旦 Docker 內部的服務行程與實體機器的網路和檔案系統產生耦合,編排就會變成一件非常痛苦的事。

2014 年,無狀態服務開始成為主流趨勢。那一年,Kubernetes 和 AWS Lambda 相繼誕生。它們從不同的角度描繪了無狀態服務的未來。無狀態服務意味著服務邏輯避免與網路位址耦合,也不再在本地依賴持久化的檔案系統。

接下來是十年的雲端原生時代,無狀態服務的浪潮催生了大批雲端原生基礎設施,例如:

  • 服務閘道 Istio / Linkerd / Envoy / Traefik
  • CI/CD 平台 Argo CD / Flux
  • 可觀測性平台 Prometheus / Grafana / ELK Stack
  • 呼叫鏈分析 Jaeger / Zipkin / OpenTelemetry
  • 儲存 Rook / MinIO / JuiceFS

而我們現在正站在一個新的起點。十年前,一個運算單元是一個 Java/Python API 服務行程。從今年開始,這個運算單元已經變成了一個 Coding Agent。

ACFS 就像是在實體機器上手動維護服務行程的年代。E2B 就像是 Docker。在沒有任務編排平台、可觀測性平台,以及分散式狀態持久化儲存能力的情況下,可擴展性對 Coding Agent 來說依然是一道難題。而我所期待的 Serverless Agent Infra,應該具備以下能力:

  1. 能夠適當地持久化 Coding Agent 的 Session 和工作目錄,而不會遺失上下文。
  2. 超快速,能在 100ms 以內讓 Coding Agent 開始運作。
  3. 具備易於人類理解的 Agent 行為 Logging / Metric / Tracing,讓人類更容易理解並調整 Agent 的行為模式。
  4. 開發者不再需要關心虛擬機器、容器等維運細節,讓大規模編排變得非常容易。

我認為能夠滿足這些能力的基礎設施其實都已經就緒了,例如 Firecracker 已經驗證了 microVM 的效能與穩定性,分散式可觀測性平台和檔案儲存系統也有許多選擇。但作為一個曾經使用 e2b 封裝 Claude Code 的開發者,將這些整合在一起依然非常困難。舉例來說,當 E2B 中的 Claude Code 因 OOM 意外中斷時,工程師很難監控到這件事,更難取得當時的現場資訊和日誌。

我希望 2026 年之後的開發者不需要再經歷這樣痛苦的過程,就像 2026 年的大多數工程師不再需要用 ssh 手動初始化實體機器一樣。

這是 VM0 的夢想。我希望有一天能透過一個符合人體工學的 API 來驅動 Coding Agent,就像這樣:

cosnt agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})

Stay in the loop

// Get the latest insights on AI teammates and collaboration.