第七章 · Daytona——星数最高的 AI 沙箱平台

这章为谁设计

你想理解「一个完整的 AI Agent 执行平台长什么样」，或者你在做产品调研、想看最成熟的竞品。

一句话定位

57.6K star 的 TypeScript 项目，不只是沙箱，而是一个完整的 Agent 工作台——有 Dashboard、Web Terminal、VNC 远程桌面、SSH 直连、MCP Server、Playground，一个不落。

日常类比

如果 Firecracker 是发动机、E2B 是网约车 App，那 Daytona 就是一个「汽车 + 车库 + 维修厂 + 加油站 + 洗车房」的综合体：

你可以在里面造车（创建沙箱）
你可以在里面开车（执行代码）
你可以在里面修车（调试代码——有 Web Terminal 和 SSH）
你可以在里面给车拍照（快照）
你甚至可以远程看车（VNC 远程桌面）

类比边界：Daytona 的「什么都有」既是优势也是劣势。优势是一站式体验；劣势是架构复杂、每个组件都可能出问题。

三层架构

┌─────────────────────────────────────────────────────────┐
│                    Interface Plane（人机入口）            │
│  Python/TS/Go SDK · CLI · Dashboard · Web Terminal      │
├─────────────────────────────────────────────────────────┤
│                    Control Plane（编排层）               │
│  NestJS API · PostgreSQL · Redis · Snapshot Manager     │
├─────────────────────────────────────────────────────────┤
│                    Compute Plane（计算层）               │
│  Runner (Go) · Docker 容器 · Daemon (沙箱内 Agent)     │
└─────────────────────────────────────────────────────────┘

NestJS：一个 Node.js 后端框架。类比：Python 有 Django，Java 有 Spring Boot，Node.js 有 NestJS——都是帮你快速写 API 服务的脚手架。

控制平面 → 计算平面：异步 Job Queue

Daytona 最关键的架构决策是「控制平面怎么告诉计算平面干活」：

旧做法：API 直接 HTTP 调用 Runner，等 Runner 返回结果。简单但脆弱。

现在的做法（v2）：异步 Job Queue——

API 在数据库（PostgreSQL）里创建一个 Job（「请创建一个沙箱」）
Runner 用长轮询不断问数据库：「有新 Job 给我吗？」
Runner 拿到 Job → 执行 → 把结果写回数据库
API 通过 Redis 事件总线把结果推给 SDK 客户端

长轮询（Long Polling）：客户端发一个请求到服务器，服务器不立刻回复，而是等到有新数据时才回复。类比：你打电话问快递「到了吗？」，快递员不挂电话，等包裹到了才说「到了！」——而不是你每 5 秒打一次电话问。

Daemon：沙箱内的「管家」

每个 Daytona 沙箱内部不是裸容器——它跑了一个 Go 写的 Daemon 进程，提供 5 个服务：

服务	功能
Toolbox API	文件读写、命令执行、Git 操作
Terminal Server	PTY 终端（你可以 SSH 进去敲命令）
SSH Server	标准 SSH 直连
Recording	会话录制回放
Session	进程生命周期管理

Daemon 不是打包在镜像里的——Runner 在启动容器时动态注入（bind mount 一个编译好的二进制文件）。这意味着 Daemon 版本和 Runner 版本总是一致的。

Daytona 和其他项目最大的区别

Daytona 是 6 个项目里唯一一个对「人也要用」做了深度设计的。

其他项目设计时想的是「Agent 怎么用我」——API 调用、SDK 创建、程序化销毁。

Daytona 设计时想的是「人和 Agent 都要用我」——所以有 Dashboard（人看的）、Web Terminal（人调试用的）、VNC 远程桌面（人需要 GUI 时用的）。

这在调试 Agent 行为时非常有价值：Agent 在沙箱里跑了一段代码出了问题，你可以直接 SSH 进去看看环境状态，而不是只能通过 API 猜。

隔离方式

Daytona 的隔离和 CubeSandbox/Firecracker 有本质区别：

CubeSandbox/Firecracker：KVM 硬件虚拟化——每个沙箱是独立的 VM，有自己的内核
Daytona：Docker 容器级隔离——每个沙箱是一个 Docker 容器，共享宿主机内核

具体来说，Daytona 用三层隔离：

Docker Bridge 网络：容器间网络隔离
iptables 规则：出站流量过滤
独立文件系统：每个容器有自己的文件系统视图

这意味着：Daytona 的隔离强度低于 CubeSandbox/Firecracker（共享内核有内核漏洞逃逸风险），但灵活性更高（不需要 KVM、启动更快、生态兼容性好）。

57.6K star 从哪来

Daytona 的高星数来自三个因素：

产品做得好：Dashboard、MCP Server、VNC 等功能让人一看就觉得「这个好用」
门槛低：TypeScript 为主，前端工程师也能贡献
时机好：在 AI Agent 代码执行需求爆发时早期推出

但在纯隔离技术层面，Daytona 不如 CubeSandbox/Firecracker 极致。如果你的选型标准是「最强隔离」，Daytona 不是最佳选择；如果标准是「最完整的开箱体验」，Daytona 是首选。

一个有教训的 bug

Daytona #1418：用户用 node:18-alpine 镜像创建沙箱时，整个流程失败。原因是 Daemon 启动时需要容器里有 bash、sudo、curl——但 Alpine 镜像只有 BusyBox（一个极简的 shell 替代品）。

教训：平台对基础镜像有隐式依赖。如果文档没写清楚「你的镜像必须有 bash」，用户会踩坑。这也是为什么 CubeSandbox 选择完整 VM（跑完整的 Linux 内核）而不是容器——VM 里天然有 bash。

读完这章你应该能回答

Daytona 和 CubeSandbox 的隔离方式有什么区别？（容器级 vs KVM 硬件级）
Daytona 的 Daemon 是什么？（沙箱内的 Go 进程，提供文件/命令/终端/SSH 等服务）
为什么 Daytona star 数最高但不一定是最好的选择？（产品功能丰富但隔离强度不是最强）
Daytona 的三层架构是什么？（Interface / Control / Compute）

导读目录：README.md 上一章：第六章 · E2B——沙箱即服务的「标准化者」下一章：第八章 · gVisor——「不用 KVM 也能隔离」的第三条路