Daytona AI 代理计算与沙箱

AI 代理需要可组合的计算机，而不仅仅是代码执行

AI 代理需要有状态、可组合的计算机——本质上是生产级别的沙箱，而不是一次性、短暂的代码执行盒子。虽然简单的隔离环境可以运行一段代码并返回输出，但复杂的代理需要的环境类似于人类的笔记本电脑：能够保持状态、暂停并恢复工作，并且能够访问多种操作系统（Linux、Windows 和 macOS）以与遗留软件交互。

向 AI 沙箱的转型

Daytona 在 2025 年初将重点从为人类工程师自动化开发环境转向提供 AI 沙箱。这一转变源于一个关键的市场洞察：代理的基础设施需求与人类根本不同。

在 MVP 开发期间，Daytona 发现代理开发者迫切需要一种能够处理高并发、有状态工作负载的运行时。这推动了公司快速增长，报告的月环比增长率为 74%，部分客户每天运行近 850,000 个沙箱。

高性能基础设施架构

为实现 AI 代理所需的速度和有状态性，Daytona 采用了以下特定架构栈：

• 裸金属部署： 通过在裸金属上运行而非虚拟机（VM），Daytona 消除了计算与存储之间的网络延迟（例如避免使用 EBS），从而显著提升 IOPS。
• 自定义调度器： Daytona 使用自研调度器来管理资源，避免了 Kubernetes 的开销和复杂性，公司发现 Kubernetes 并不适合这种特定工作负载。
• 快速启动时间： 该架构使单个沙箱的启动时间约为 60 ms。对于大规模场景，Daytona 能在约 75 秒内并发启动 50,000 个沙箱。
• 有状态快照： 模板和快照预加载在裸金属机器上，允许代理“合上盖子”后立即恢复到完全相同的状态。

处理波动的 RL 与评估工作负载

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 与网络，因为并发代理任务的庞大数量对通用计算提出了前所未有的需求。