为什么 AWS 和 Azure 跑不了真正的 AI Agent？这位创始人说出了大多数人没想明白的事

Daytona 的 CEO Ivan Burazin 最近接受了一档播客的采访，聊了一个小时的 AI agent 基础设施。他花了十几年时间做云端开发环境，经历了一次早到无人买单的创业，又在 AI 浪潮里找到了正确的时间点。这期访谈信息量很大，很多观点值得细细拆解。

每个 AI Agent 都需要一台属于自己的电脑

Ivan 有个核心比喻，他把 AI agent 比作数字知识工人。知识工人要完成工作，离不开一台电脑。agent 也一样，如果它只是和你聊聊天、回答问题，也许不需要太多。但一旦它要搜索网页、执行代码、操作文件、登录系统，就必须有一台真正意义上可以运行这些操作的机器。

这个"机器"就是他们所说的沙箱。沙箱不是某种抽象的概念，它就是一台完整的计算机，有 CPU、内存、硬盘，可以联网，可以安装软件，可以跑任何脚本。只不过它是虚拟的，而且是专门给 agent 用的。

Ivan 自己就是这么用的。他给自己的 AI 助手分配了一个独立账号、一个独立手机号，因为银行的双重验证需要接收短信。他说，当时他让 AI 帮他拉一份董事会财务报告，AI 直接问他能不能直接登录公司银行账号，他当场就意识到这条路不对，必须给 AI 一台独立的机器和独立的身份，而不是让它在你的个人环境里乱跑。

这个细节其实值得多想一想。很多人用 Claude Code 或者 OpenClaw 时，直接在自己的笔记本上跑，agent 能看到你所有的文件、所有的凭据。你觉得它只是在帮你整理邮件，但它实际上有权限碰到你不想让它碰的东西。沙箱解决的第一个问题，其实是权限边界。

为什么 AWS 和 Azure 没有解决这个问题

很多人第一反应是，这东西直接用云服务不就行了？AWS 有服务器，Azure 有虚拟机，为什么还需要单独做一层沙箱基础设施？

Ivan 给了一个很清晰的解释。现有的大云厂商，从一开始就是为"无状态"工作负载设计的。什么叫无状态？就是你部署了一个网站，这个网站的代码本身不会在运行过程中改变。用户访问量大了，你多起几个实例，访问量降了，你把实例关掉，每个实例都是相同的副本，互不依赖，随时可以销毁。

这种架构对 Web 服务来说很完美。但 AI agent 完全不一样。agent 在执行任务的过程中，它的状态会不断变化，它下载了文件、安装了依赖、写了中间结果。你不能把它随意销毁再重建，因为那样所有的进展都没了。它需要一台能持续存在、能保留状态的机器。

Ivan 打了个比方。大云厂商造的是货车，稳、可靠、适合运货。而 agent 需要的是跑车，设计目标完全不同，底盘、引擎、重量分配都得重来。你可以强行让货车开快一点，但那不是它该干的事。

沙箱在技术上到底是什么

Ivan 把沙箱分成三层来解释：基础设施、底层原语、工具层。

基础设施这一层解决的是速度和规模。Daytona 可以在 60 毫秒内启动一个沙箱，在 70 秒内并发起 5 万个。为什么速度这么重要？

对普通用户来说，等待本身就是一种体验损耗，没人喜欢盯着加载动画发呆。但对做强化学习训练的研究团队来说，背后有更实际的成本逻辑：GPU 比 CPU 贵得多，你希望 GPU 始终在满负荷跑，CPU 沙箱的作用是给 GPU 不断喂任务。如果每次任务切换都要等几秒才能启动新的沙箱，GPU 就在空转，钱就在白烧。所以沙箱的启动速度，直接影响整个训练集群的资源利用率。

底层原语这一层，说的是沙箱具体用什么技术来实现隔离。目前主流有几种选择：Firecracker 是 AWS 开源的微型虚拟机，启动极快，但不支持 GPU；QEMU 功能完整，支持 GPU 和 Android 等复杂场景，但更重；Docker 容器密度高、速度快，但安全隔离比虚拟机弱。Daytona 的做法是把这些都支持，根据用户的具体需求自动选择，用户不需要知道底层用的是哪种技术。

工具层是让 agent 用起来更顺手的部分，比如封装好的文件操作接口、终端命令接口，还有防止 agent 乱来的防火墙和密钥管理。这些工具一方面帮 agent 少用 token 就能把事办成，另一方面相当于给它套了一个行为边界。

快照和分叉：agent 可以"存档读档"

Ivan 提到了一个很有意思的特性，沙箱可以做快照和分叉。

快照的商业价值首先是省钱。想象一个应用有一千万用户，每个用户同时跑着一个 agent，这些沙箱如果一直开着，持续消耗 CPU 和内存，成本非常可观。但很多时候 agent 其实在等，等用户回复，等某个外部 API 返回数据。这段时间里，你完全可以把沙箱暂停，等到需要继续的时候再恢复。用户感知不到它停过，但你少付了一大笔钱。

分叉的用途更有趣。agent 在执行任务时可以在某个节点做快照，然后分裂成两个独立的沙箱，各自尝试不同的路径，最后对比结果选最好的那条。这和人类做决策时"如果当时选了另一条路"的思维实验很像，区别在于 agent 可以真的同时走两条路。

为什么要自己造调度器

Ivan 说他们最终决定从头写自己的调度器，放弃了 Kubernetes 和 Nomad 这些现成的工具。

调度器负责的事情是：当你发来一个"给我启动一个沙箱"的请求时，系统决定把这个沙箱放到哪台物理服务器上，怎么分配资源，什么时候关掉或者迁移。

现有的调度器，比如 Kubernetes，是为长期稳定运行的容器设计的，不擅长处理"大量极短生命周期"和"少量极长生命周期"混在一起的场景。agent 沙箱恰恰就是这两种情况都有。另外，Kubernetes 对底层服务器的维护也有要求，如果服务器需要重启升级，必须把上面的任务都先停掉，这对短任务还好，对可能跑了好几天的长任务就很麻烦了。

Daytona 的解决方案是做沙箱的实时迁移，就是在用户完全感知不到的情况下，把一个运行中的沙箱从一台服务器迁移到另一台，这样你就可以随时对服务器做维护，而不影响上面跑着的任务。这在技术上相当复杂，但这也是为什么一个合格的沙箱基础设施真的很难自己造。

自己造沙箱的坑

Ivan 提到，他们看到很多公司一开始说"我们自己造吧，不难的"，三个月、六个月后又找回来。

一个 Firecracker 实例确实不难起。难的是起一百万个，难的是处理 GPU 场景，难的是在保证速度的同时还要保证安全隔离，难的是做快照迁移、做资源动态扩缩容、处理服务器宕机时的数据恢复。

他们做了一个在技术上很反直觉的决定：把沙箱的硬盘放在本地而不是网络存储上。大多数云基础设施用网络硬盘，原因是好管理，服务器挂了直接挂另一台上去，数据没有丢失。但网络硬盘的 IOPS 只有几十万，本地硬盘能到几千万。对于某些需要密集磁盘操作的 agent 任务，这个差距至关重要。代价是故障处理更复杂，需要做更精细的实时备份。这是一个为性能主动选择了更难路径的技术决策。

两个还没解决的问题

Ivan 直接说，agent 技术栈里有两块还没被真正解决。

第一个是记忆。现在最常见的做法是把信息写进 Markdown 文件，然后通过压缩和检索来给 agent 提供上下文。Ivan 自己也觉得这个方案太粗糙，但目前没有更好的标准答案。

第二个更根本，模型现在实际上不会"学习"。你用一个模型，给它上下文，它可以表现得更好。但你在今天的使用过程中教会它的东西，明天换个会话它全忘了。它不会因为你昨天纠正了它的某个习惯就真的改变了什么，你每次都得重新告诉它。Ivan 的说法是，这就好像你有个同事，你教了他六次同一件事，他第七次还是会犯同样的错误。这个问题目前不清楚要用更密集的强化学习来解决，还是需要在模型架构层面做更根本的改变。

CPU 短缺可能比大家想象的来得更快

谈到算力，大家讨论最多的是 GPU 短缺。但 Ivan 提出了一个不太常被提到的角度，CPU 的短缺可能才是下一个大问题。

强化学习训练需要大量 CPU 来配合 GPU 工作。agent 的普及意味着每个用户都在运行沙箱，每个沙箱都消耗 CPU。Semi Analysis 的报告预测，CPU 的供需紧张可能在 2024 年下半年就会出现。Ivan 在推特上点名了 Intel，说这是他比较确定的一个判断方向。

这个预测的底层逻辑其实很直接：过去几年大家把钱和注意力都放在 GPU 上，CPU 的产能扩张相对滞后。但 agent 爆发之后，对 CPU 的需求是几何级的，这个缺口不是一两年能补上的。

关于做创业这件事

Ivan 的第一次创业，产品是云端 IDE，时间是 2009 年。那时候没有 Docker，没有 Kubernetes，没有 VS Code，他们把整个栈都从头搭了一遍。但他说他们早了将近二十年，开发者那时候根本不想把自己的代码从本地环境搬走。

他总结了两个核心教训。第一个是要搞清楚用户和客户的区别。个人开发者会用你的产品，但他们不付钱。只有当你的产品能嵌入一个公司的工作流、让公司愿意用公司信用卡买单，你才有了真正的商业模式。现在 Daytona 的 PLG 路径，就是让工程师先用起来，用顺了再推动公司采购，这和当年那个人人都爱但没人付钱的云 IDE 是本质不同的产品逻辑。

第二个是市场时机比产品本身重要得多。技术可以领先，但领先太多和领先太少一样不好。他说自己做了十五年云 IDE，一直在等那个"开发者终于愿意让代码离开本地"的临界点。现在 agent 来了，那个临界点才真正到来，因为 agent 根本就不在乎跑在哪台机器上。

他在客户服务上的一个观点也很有意思。他说，好的客户支持其实就是两件事：第一响应要快，让客户知道有人接住了他们的问题；承诺解决时间，然后在到期前主动更新状态，哪怕是说"这个要再延两天"。大多数人不是愤怒于问题本身，而是愤怒于被晾在那里不知道发生了什么。这个道理放在产品上、放在团队协作上，其实都成立。

来源

• MAD Podcast: Why AWS and Azure Cannot Run Autonomous AI, Ivan Burazin (Daytona)
• YouTube: https://www.youtube.com/watch?v=kMXJrzAa5fM (opens in a new tab)