什麼是 Firecracker？為什麼所有 Agent Infra 公司都如此重視它？

每天，AWS Lambda 執行數兆次函式呼叫。AWS Fargate 排程數百萬個容器。每一個都是一個完整的虛擬機器，擁有自己的核心，並在零點幾秒內啟動。

怎麼辦到的？靠著大約 50,000 行名為 Firecracker 的 Rust 程式碼。它的誕生，是因為業界終於承認，一個用來控制資源使用的 Linux 容器，從未被設計成安全邊界。

隔離問題

你筆電上的每個 Docker 容器，其實是三個 Linux 核心功能穿在同一件風衣裡：

命名空間是眼罩。裡面的行程只能看到系統的私有視圖：自己的 PID 列表、網路堆疊、掛載表、主機名稱和使用者 ID。容器內的 PID 1，其實是主機上的某個隨機 PID；容器甚至看不到其他行程。
cgroups 是預算。控制群組是核心的記帳和速率限制層。它限制一個行程樹可以消耗多少 CPU、記憶體、磁碟 IO 和網路頻寬的上限。
seccomp + 能力是允許清單。能力將 root 的權限切成大約 40 個單獨的特權（例如綁定低連接埠、載入核心模組、掛載檔案系統等），這樣你就能只授予需要的部分。seccomp 是一個行程過濾器，決定該行程允許執行哪些系統呼叫（使用者空間與核心互動的唯一 API）。

你甚至不用安裝 Docker 就能自己驗證：

Docker 做的其他事情（映像層、註冊表、DNS）都是在這之上的編排之上。

所有這些保護機制，都匯集到同一個 Linux 核心，這個核心有大約約有 3000 萬行程式碼，開放了 400 多個系統呼叫。主機上的每個容器都呼叫同一個核心。只要其中任何一個系統呼叫有漏洞，那台機器上的所有租戶就完了。

全虛擬機器用暴力方式解決隔離問題：每個 VM 都有自己的核心。

現代 CPU 有一個「來賓模式」，可以直接在真實矽晶片上執行來賓指令。只有當來賓執行特權操作（觸碰真實硬體、發生錯誤、被中斷）時，主機才會介入。虛擬機器監控器就是仲裁這些時刻的薄層。

Linux 將它的虛擬機器監控器作為一個名為 KVM 的核心模組提供，透過 /dev/kvm 暴露出來。它依賴硬體虛擬化擴充功能（Intel 的 vmx，AMD 的 svm）：

全虛擬機器的問題在於它們又慢又肥。一個傳統的 QEMU VM 會模擬一整台虛擬 PC（BIOS、PCI 匯流排、IDE 控制器、VGA 卡、PS/2 鍵盤），因為這是 1998 年的作業系統預期要啟動的環境。映像檔有數百 MB。啟動需要好幾秒。在工作負載開始之前，記憶體佔用就已經數百 MiB。對於一個只存活 40ms 的網路請求，你得花 40 倍的時間來啟動機器。

所以你陷入了兩難：

容器：50ms 啟動，5 MiB 開銷，共用核心的攻擊面。
VM： 5 5 秒以上啟動，300+ MiB 開銷，硬體隔離。

每個執行不受信任的多租戶程式碼的廠商（AWS，以及基本上所有現有的現有的 AI 沙盒供應商）都需要同時兼顧這兩者。

進入微VM

VMM（虛擬機器監控器）是驅動虛擬機器監控器的使用者空間行程：它設定來賓記憶體、插入虛擬裝置，並告訴 KVM 開始執行來賓程式碼。

微VM 是刪除了 1998 年 PC 的 VMM：沒有 BIOS、沒有 PCI 匯流排、沒有 VGA、沒有 USB、沒有 ACPI（真實桌上型電腦啟動時會經歷的所有傳統硬體，對一個 40ms 的函式呼叫來說都無關緊要）。剩下的是：KVM、一個序列主控台，以及少數幾個 virtio 裝置（網路、區塊、vsock）。

virtio 是標準的「我知道我在 VM 中執行」的裝置介面。來賓會與虛擬機器監控器合作，透過輕量級的虛擬 NIC 和磁碟（virtio-net、virtio-block）來運作，而不是假裝驅動真實的 Intel e1000 卡或 IDE 控制器。這種合作，加上上述所有被省略的傳統硬體，是微VM 啟動快速的最大原因。

結果：

從 VMM 啟動到來賓使用者空間執行 init 約需 125ms。
每個 VM 的 VMM 記憶體開銷小於 5 MiB（主機為每個 VM 支付的記帳記憶體，在來賓工作負載為自己分配任何東西之前）。
單一主機上每秒建立 150 個 VM。
與裸機相比，執行時期效能損失約 2–8%。

擁有與全 VM 相同的硬體隔離，同時具有與容器相同數量級的密度。

Firecracker 就是那個 VMM，那個實際與 /dev/kvm 通訊並啟動微VM 的行程。這篇文章的其餘部分將從頭到尾介紹這個堆疊。

Firecracker

2018 年 11 月，AWS 在 re:Invent 上開源了 Firecracker。它當時已經在 Lambda 的 Lambda 中運作，正是讓你的 import pandas 冷啟動速度快到可以按毫秒計費。2020 年，團隊在 NSDI '20 上發表了這套架構。

架構

從 Google 的 crosvm 分支出來，用 Rust 重寫，並移除了超過一半的程式碼。每個 Firecracker 行程就是一個微VM，且正好有三種執行緒類型（在 docs/design.md 中有文件說明）：

API 執行緒是訂單櫃檯。一個綁定到 Unix socket 的 REST 伺服器（一個只存在於磁碟檔案上的本地端 socket，不是 TCP 連接埠）。在啟動前接受設定，並在啟動後接受有限的操作。
VMM 執行緒是硬體車間。它假裝是來賓能看到的所有裝置。當來賓碰觸它認為是 NIC 暫存器的東西時，CPU 會暫停來賓，VMM 處理這個碰觸（「來賓踢了 TX 佇列，清空它」），然後恢復。機制：來賓讀取寫入魔術位址；CPU 將這些位址陷阱到主機。[^mmio]
vCPU 執行緒是跑者。每個來賓 CPU 一個，各自在一個緊密迴圈中：要求 KVM 執行來賓，直到發生有趣的事情（裝置碰觸、中斷、暫停），處理它，然後迴圈。

它們透過 Rust 通道（行程內、無鎖的執行緒間訊息佇列）相互通訊。來賓正好看到四個裝置。

**四個裝置

**virtio-net 是 VM 的 NIC，沒有 1998 1998 年的模擬。來賓將封包寫入 virtqueue（共享記憶體中的環形緩衝區）；VMM 透過主機端的 TAP 裝置（核心作為檔案暴露為檔案），由 io_uring 或 epoll 驅動，這樣 VMM 執行緒就不會阻塞。
virtio-block 是 VM 的磁碟，只是主機上的檔案 IO。來賓將磁區請求放入 virtqueue；VMM 對主機檔案發出簡單的 pread/pwrite。沒有 IDE、沒有 AHCI、沒有 SCSI。
virtio-vsock 是 VM 與主機的對講機。使用（context-id, port）元組定址，而不是 IP/連接埠對，這樣來賓代理可以回報（日誌、健康檢查、快照元資料），無需來賓 IP，且網路上沒有東西可以偽造。
8250 序列 UART 是啟動主控台。一個在固定位址模擬的小型傳統序列晶片。用於 virtio 啟動前的早期啟動日誌和崩潰轉儲。便宜、通用，永遠不會消失。

啟動一個微VM，從頭到尾

API 是整個控制平面：設定通道，刻意與資料平面（實際執行來賓程式碼的 vCPU 執行緒）分開。你啟動指向 Unix socket 的二進位檔：

然後你將設定 PUT 進去：

四個 HTTP 呼叫。這就是整個控制平面。

安全洋蔥

單一的 KVM 邊界已經很強了。Firecracker 在它外面又包了兩層。

jailer 是一個沙箱建構器。它的唯一工作是在 VMM 執行之前把它關起來。它建立一個 chroot（一個 Linux 功能，將行程鎖定到單一目錄子樹，就好像該目錄是檔案系統的根目錄一樣；行程完全無法命名其上任何東西），放入一個新的 PID 命名空間，這樣它就看不到主機的其他行程，切換到一個非特權的 uid/gid，套用 cgroup 的 CPU/記憶體限制，然後才在該監獄中執行 Firecracker 二進位檔：

現在 VMM 行程本身除了專用的 chroot 之外沒有檔案系統，看不到主機上的其他行程，也沒有 root 能力。如果來賓到主機的逃逸確實透過 virtio 或 KVM 發生，攻擊者會落在具有 cgroup 限制的 chroot 中。

Seccomp 是一個執行緒的系統呼叫允許列表。不在列表上的任何東西在到達核心的系統呼叫處理器之前都會被殺死（或回傳 EPERM）。Firecracker 提供三個層級：

層級 0：關閉。不要在正式環境使用。
層級層級 層級 1：按系統呼叫號碼允許列表。 層級 2：也限制引數值（例如 ioctl 可以，但只能使用 KVM_RUN 作為指令）。預設且建議使用。

每個執行緒獲得可能的最小表面：API 執行緒不需要 ioctl(KVM_RUN)；vCPU 執行緒不需要 socket()。一個規則的簡化版本看起來像這樣：

每一層都必須獨立失效，攻擊者才能到達主機。

快照：Lambda SnapStart 的作弊碼

對一個正在執行的微VM 拍攝快照。在幾毫秒內，在不同的主機上恢復到一個全新的 VMM 行程。跳過核心啟動、跳過 init、跳過 JIT 暖機。

你凍結正在執行的 VM 並將記憶體 + 裝置狀態傾印到磁碟：

快照捕捉了暖機後的狀態，因此恢復的 VM 會在其生命週期的中間醒來，而不是在開始。

這正是 AWS Lambda SnapStart 所做的：初始化一次 Java Lambda，拍攝微VM 的快照，然後在每次後續冷啟動時恢復該快照（公告）。JVM 冷啟動突然從 8 秒以上降到次秒級。

它們如何配合

gVisor 是一種不同的設計：一個用 Go 寫的使用者空間核心，是 Linux 系統呼叫介面的重新實作，作為一個正常行程執行。來賓的系統呼叫會命中 gVisor 而不是主機核心，gVisor 決定要將什麼（如果有的話）轉發到下游。啟動速度比微VM 快，熱路徑上有 10–30% 的系統呼叫開銷，以及不同的信任邊界。

Firecracker 屬於「自己的核心，但沒有 PCI BIOS」的盒子裡：硬體隔離、微小的裝置模型，以及毫秒級的啟動。

選擇你的工具：

誰在使用這個

列出那些不建立在微VM 之上的無伺服器平台可能更快。

Firecracker 在正式環境中：

AWS Lambda 和 AWS Fargate：原始用例。每個 Lambda 呼叫都落在 Firecracker 微VM 中；Fargate 任務是帶有內部輕量容器執行環境的 Firecracker VM。
**Fly.io Machines：每個 fly machine 執行個體都是一個 Firecracker 微VM，全球分佈，具有次秒級冷啟動和持久化磁碟。
幾乎所有你在過去一年半用過的 AI 代理程式碼執行沙箱都存在於 Firecracker 微VM 中。

目前，各供應商的沙箱 API 形狀大致相同：

大約四行程式碼：一個 Firecracker 微VM 啟動，一個核心初始化，來賓內部的一個代理行程透過 vsock 接收你的命令，執行它，將結果串流回，然後 VM 終止。

Agent 時代：為什麼這一切現在如此重要

一年前，「什麼是 AI 沙箱？」還是個小眾問題。如果 LLM 產生了程式碼，它可能不是 100% 安全到可以在任何機器上執行，所以你會在一個短暫的沙箱中執行它。

今天，每個嚴肅的 AI 產品都出貨了一個 Agent。它們的沙箱也變得更好了，但 Agent 的形狀改變了，舊的執行時期答案不再適合新的形狀。

**行程內程序 Agent 與主機層級 Agent

第一輪的 AI Agent 存在於你的應用程式內部。你匯入一個函式庫，建立一個迴圈，然後在你現有的後端中執行它：

每次呼叫都是到模型的一次 HTTP 往返。每次工具呼叫都是你自己行程中的一個函式。「沙箱」就是你自己的伺服器。這是 Vercel AI SDK、LangChain、OpenAI Agents SDK 的世界。它運作得很好，今天仍然出貨了很大一部分正式環境 Agent 的很大一部分。

第二輪則不同。Claude Code、Codex 和 OpenCode 是主機層級的 Agent：接管一台機器，而不是存在於你內部的函式庫。它們期望一個真實的 shell、一個套件管理器和一個可寫入的磁碟。當你給 Claude Code 一個任務時，它會執行這類東西：

那是個 shell/bash。它需要一個真實的檔案系統、真實的 fork/exec、套件管理器、可以寫入的磁碟、可以到達的網路。這些都無法用聊天補工具 schema 表達，而且與其他租戶共用核心的容器中執行也不安全。

實驗室正在直接這些 harness（模型周圍的 scaffolding）上對模型進行後期訓練：shell、檔案編輯器、測試執行器、Agent 迴圈本身。這意味著「模型 + 它訓練時用的 harness」與「模型 + 自製 scaffolding」之間的差距每季都在擴大。

每個 Agent 一台完整的 Linux 機器，執行 Agent 剛剛發明的不受信任的程式碼，正是 Firecracker 的設計目標。上述的匯聚並非偶然。

我們開始看到更多圍繞 Agent 圍繞運算與 harness 分離的更多實驗。Anthropic 的 Managed Agents 就是一個例子，其中 Agent harness 在沙箱旁邊執行，而不是在沙箱內部。

有些公司甚至在建置完整的託管檔案系統（例如 Archil 和 Mesa），為 Agent 提供更好的搜尋和儲存。

隨著 Agent 變得更好並隨著時間改變，將會出現更多建立在 Firecracker 之上的有趣基礎設施產品。

你實際上在為 Agent 基礎設施平台付費的是什麼

通用的「執行任意程式碼」沙箱現在已經是大宗商品。基礎設施是完全開源的。微VM 層是 Firecracker 或 Cloud Hypervisor，可在 Apache 2.0 下取得。容器到 rootfs 的轉換是一個 200 行的 Go 腳本。有天賦的工程師可以在一個週末內建立一個可運作的沙箱平台。

你為連接到 VM 的東西付費。裸露的微VM 只是入場券。

有趣的產品表面：

**可觀測性就是產品，而不是除錯輔助工具。Agent 所做的一切（stdout、系統呼叫、檔案寫入、網路請求）都透過一個 socket 流向主機端的收集器。Agent 建構者需要完整的會話重播，以及每個動作的工件，才能打造出最好的產品。
機密在線路上仲介，從不交給來賓。來賓只會看到佔位符環境變數；在沙箱中執行 echo $SECRET 會回傳佔位符。一個主機端的出口代理（每個傳出封包都必須經過它）會在主機端的 TAP（VM 虛擬 NIC 的核心端，來賓看不到也無法定址）處，根據明確的允許清單，並附上每個會話的稽核軌跡，來替換真實的憑證。Agent 可能正在執行它五秒前產生的任意程式碼，但仍然無法外洩它從未擁有的憑證。
身分在主機端簽署，而不是在 Agent 內部。傳出請求可以攜帶一個加密的每會話身分（包括 Web Bot Auth 簽章，基於 HTTP 訊息簽章 + Ed25519），由主機在封包離開橋接器之前鑄造。簽章金鑰從不進入微VM。
其他運算與執行時期捆綁在同一個微VM 中。Browserbase 將每個 Agent 執行時期與同一主機上的瀏覽器進行 1:1 配對，通常是同一個微VM。Agent 行程與 Chromium 之間的物理距離幾乎為零：CDP 命令（Chrome DevTools Protocol，用於程式化驅動 Chrome 的 JSON-over-WebSocket 線路格式）透過 Unix socket 傳輸，而不是跨服務網路，因此動作延遲是單位數毫秒。螢幕錄影畫面不需要穿越公共網際網路就能進入會話重播。

而且你無法在 Docker 之上乾淨地將所有這些縫合在一起。縫隙不存在。我們的賭注是，Agent 執行時期市場不會由原始運算贏得，而是由最好的可觀測性、機密、身分、合作夥伴關係，以及共置運算整合到一個產品表面來贏得。

值得關注的執行時期替代方案

[Bubblewrap](https://github.com/containers/bubblewrap)：非特權使用者命名空間沙箱化。非 root 使用者可以在沒有 sudo 的情況下啟動沙箱，使用 Flatpak 用來限制桌面應用程式的相同核心原語。比 VM 輕量，但仍然共用主機核心，因此不能替代微VM 來處理真正不受信任的程式碼。但它是一個很好的巢狀隔離層，可以在微VM 內部執行，或者對於你自己主機上相對可信的程式碼來說是一個不錯的選擇。
[V8 isolates](https://blog.cloudflare.com/cloud-computing-without-containers/)：Cloudflare Workers 的模型。每個 isolate 是一個獨立的 JS 執行上下文，擁有自己的堆積，所有 isolate 與其他數千個租戶共用一個 V8 行程。啟動約 5ms，比微VM 快兩個數量級。信任邊界是 V8 自己的沙箱；歷史上它表現良好，但它比虛擬機器監控器的邊界薄得多。另一個問題：你只能得到 Node 風格的語意。沒有 fork、沒有 exec、沒有原生模組、模擬的檔案系統。對純 JS Agent 程式碼來說非常強大；如果你需要 pip install numpy 就沒用了。
[gVisor](https://gvisor.dev/)：Google 的使用者空間核心。強大的隔離，無需巢狀虛擬化（一個來賓 VM 在另一個 VM 內部執行，大多數雲端供應商預設禁用它；gVisor 不需要它，因此它可以在 GKE 中開箱即用）。在系統呼叫密集的工作負載上付出約 10–30% 的代價。當硬體虛擬化不可用時，是一個堅實的中間地帶。
WASM 沙箱（[wasmtime](https://wasmtime.dev/)、[wasmer](https://wasmer.io/)）：確定性、體積小、速度快，但生態系較淺。WASI（WASM 的標準系統呼叫 API）正在成熟。目前還不能直接取代「執行這個任意 Python/Node 二進位檔」的目標。