我们现在正处于这样一个超级周期（super cycle）之中
Ivan: 我们现在正处于这样一个超级周期（super cycle）之中，而超级周期不会永远持续下去。所以，如果你打算在这个超级周期中停下脚步，你就是在把市场拱手让人（ceding market），你现在的所作所为就是这样。我会问 Claude，你能去从我们的银行获取数据吗？然后它就说，哦，好的，只要登录并给我访问权限。我就想，登录给你权限？不，我不会马上给你访问权限。从根本上来说，这对我而言打破了整个逻辑，所以你需要给它一台属于自己的机器。当我想到 agent 时，我把它们视为数字知识工作者（digital knowledge workers）。作为一个知识工作者，要完成任何工作，你确实需要一台计算机。我的观点是，每个 agent 都将需要至少一个安全沙箱（sandbox），有时甚至更多。
Matt: 大家好，我是 Matt Turck。欢迎来到 The MAD Podcast。我今天的嘉宾是 Daytona 的 CEO Ivan Burazin。Daytona 是在 agent 基础设施领域讨论度最高的初创公司之一。如果你在每一次的 AI agent 对话中都能听到“sandbox（沙箱）”这个词，并暗自琢磨它到底是什么意思，以及为什么它突然变得如此重要，那么这一期节目就是为你准备的。我们将从第一性原理（first principles）出发——为什么 agent 根本上需要一台计算机？一直深入到深度的技术话题——为什么 Daytona 不得不抛弃 Kubernetes 并编写他们自己的调度器（scheduler），以及为什么全球 CPU 短缺的到来可能会比人们想象的更快。Ivan 还剖析了在他眼中完整的 agent 技术栈（agent stack）：模型（models）、沙箱（sandboxes）、工具、MCP、记忆（memory）和编排（orchestration），以及每个部分的发展方向。在此过程中，Ivan 还分享了一些针对技术型创始人在推向市场（go-to-market）和分发方面非常有趣的经验，这些都是他 16 年来创立开发者工具初创公司所学到的。请享受这段我与来自 Daytona 的 Ivan 的精彩对话。
Matt: 嘿，Ivan，欢迎。
Ivan: 很高兴来到这里。
Matt: 所以你曾说过，每个 agent 都需要一台自己的计算机。解释这个想法最简单的方式是什么？
Ivan: 嗯，当我想到 agent 时，我把它们视为数字知识工作者。作为一个知识工作者，要完成任何工作，或者我应该说任何复杂的工作，你确实需要一台计算机。所以，你和我可以进行一次对话并完成一些事情，但我们通常需要某种工具。在我们的世界里，通常是一台计算机以获得更高的生产力，并能够执行任务。所以，我用同样的视角来看待这个问题。对我来说，agent 实际上就是数字知识工作者。
Matt: 太棒了。所以它在计算机上。这就是 sandbox（沙箱）的整个概念。作为这场对话的引言，什么是沙箱？
Ivan: 绝对的。虽然“sandbox”这个词最初来自于隔离（isolation），也就是确保有一个安全的地方让 agent（在这个语境下）运行并执行任务。但在另一方面，它本质上就是一台计算机。它是一台功能完备的计算机，agent 在上面有能力安装工具、访问网络、运行脚本、运行代码，或者做任何完成其工作所需的事情。所以，最简短的回答是，沙箱本质上是我们所说的为 AI agent 准备的可组合计算机（composable computers）。
Matt: 是的。在某些方面，整个 Open Claude 和 Mac mini 的事情，是不是沙箱的一个很好的类比？就像 Mac mini 在某种程度上扮演了沙箱的角色。
Ivan: 完全正确。我认为 Open Claude 和 Mac mini 的例子帮助了很多人理解我们实际在做什么。就像是，“哦，我现在懂了。我明白了。”所以它需要一台计算机，在这个例子中是一台 Mac mini，来执行各种操作。所以是的，那绝对很大程度上提升了大家的认知。
Matt: 是的，因为再次拆解来看，Open Claude 作为一个框架系统（frameworking system），用于帮助 agent 在你的计算机上执行各种操作。基本上，如果它失控（goes rogue），你会希望能干掉它，因此你可以拔掉 Mac mini 的电源，就像你可以干掉一个沙箱一样。是这种感觉吗？
Ivan: 有点像。所以，有几件事是我个人考虑过的。我的 Open Claude 不是运行在一台物理的 Mac mini 上，而是运行在一个沙箱化的虚拟 Mac mini 上。为什么我没有——人们通常是在自己的电脑上运行这些东西，比如 Claude Code 或 Open Claude，因为它能帮他们整理邮件、搜索文档之类的。这其中存在极高的安全风险。因为有一次我们在做董事会演示，我就问 Claude：“你能去从我们的银行获取数据吗？”然后它说：“哦，好的，只要登录并给我访问权限。”我就想，“登录给你权限？不，我绝对不会给你访问权限。”所以对我来说，这瞬间就打破了整个基本逻辑。所以你给它一台自己的机器。我个人给了它一个自己的、类似于 Daytona 的账户，给了它自己的电话号码。我之所以给它电话号码，是因为它需要双重认证（2FA）才能进入银行。除了通过电话号码进行双重认证外，没有其他办法进入这家特定的银行。所以它必须拥有所有这些东西，就像一个数字雇员一样，才能去访问这些东西。那么既然它现在有了自己的计算机，有了自己的账户，这些账户本身也是有限制的。所以它只能查看我银行里的数据，而不能花掉我银行里的钱。除了我们给它的信用卡，里面可能有比如每天 100 美元之类的额度。所以在沙箱中，你本质上面临的唯一风险就是，它是否会拿着这些数据并将其泄露到某个地方。这是我们稍后可以讨论的话题。但从根本上说，最坏的情况也就那样。而且就像你说的，如果需要，你可以把整台机器干掉。
Matt: 是的。这里有一个基本概念，就是有状态（stateful）与无状态（stateless）。你能为我们解释一下吗？
Ivan: 所以这基本上发生在我们向人们谈论我们正在构建的东西时。他们会说：“哦，这在任何超大规模云服务商（hyperscalers）那里不是已经存在了吗？”答案是否定的。原因在于他们构建的、用于部署应用的一切，都是无状态的。如果你有——我们随便选一个你的网站或任何你想说的 Web 应用——你不会希望它在运行中（on the fly）被改变。如果你是——我们拿 eBay 举例，因为他们就在这栋楼里，所以我脑子里就想到了。如果你是 eBay 的工程师，然后你说，“哦，有个新更新，这里有个按钮，或者它实现了这个功能。”你不希望应用在运行中被改变，对吧？数据库可以变，信息可以变，但你不希望应用本身发生改变。所以，人们是带着这些想法来构建那些云基础设施的。这就是你接触并构建其上的底层架构。我给人们最简单的类比是，假设你在造卡车，你是一家卡车工厂。它的重量、发动机类型、底盘，所有这些都是为了非常缓慢但安全地运输某种货物而设计的，对吧？另一方面，你可能有一辆跑车，它同样有四个轮子、有发动机等等，但它的用途不同。它是为了跑得非常快而设计的。所以它底盘的构造方式、发动机、重量平衡都完全不同。所以你可以用两者做很多事情，但它们本质上不是同一个东西。作为一家试图把这两种东西都打造出来的公司，它们完全是不同的平台。
Matt: 嗯。所以沙箱是一个全新的基础原语（primitive）。这样说对吗？沙箱有历史吗，或者它以前就存在吗？
Ivan: 我可能会说，那个人可能推动了这一点，虽然他说他推动了，也有人说其他人推动了。但是，不管怎样，以前有一家叫 CodeSandbox 的公司。当时我们用我们的公司 Codeanywhere 与之竞争，同样是在类似 Replit 的领域，也就是所有这些基于云的 IDE。他们给它起名叫 CodeSandbox，因为我相信这听起来很可爱。这就像一个让你的代码、你的 IDE 运行的盒子。他们实际上是最早的先行者之一。所以那里的团队实际上使用了 microVM，做了我们今天使用的快照（snapshotting）、分叉（forking）所有这些事情。这可能是十年前的事了。但是供人类开发者使用的普及度或它带来的价值并没有那么高。有一篇关于“本地主机（localhost）之死”的文章，人们讨论这个问题已经很久了，我都讨论了 20 年了。基本上开发者会说，你想拿走我的 localhost，“除非从我冰冷的尸体上跨过去”。但现在 agent 来了，你实际上出于诸多原因不再需要 localhost 了。所以我们终于走到了这一步。最初围绕沙箱的技术和理论现在似乎终于开花结果了。
Matt: 嗯。而围绕沙箱的巨大加速力就是 agent，对吧？就是这东西。
Ivan: 绝对的。当我们思考 agent 时。第一，如果你确实在你的电脑上运行一个 agent，你当然可以这么做，随你便。但这会带来一堆问题。其一是在你的笔记本电脑上运行。现在 Twitter 上有一股潮流，人们都会保持他们的笔记本电脑开着。
Matt: 人们怎么做？是的，我看到你发了推文。
Ivan: 嗯，因为我总是保持我的笔记本电脑开着。这就是我的习惯。但人们这样做是因为他们想让 Claude 或者 Open Claude 完成工作。
Matt: 是的。
Ivan: 因为如果你合上电脑，它就——
Matt: 是的。
Ivan: 就被终止了。是的。就是暂停或者停止或者什么的。所以问题在于，这种持续不断工作的不间断能力是不存在的，只要它还在你的笔记本电脑上。这是其一。另一件事是你没法做到并发（concurrency）。你可以开启多个 agent，但受限于你笔记本的计算能力，那将会非常有限。你可能想启动 10 个、20 个、50 个、100 个或者十万个，不管那个数字是多少。这很难做到。所以理想情况下，你真的希望能把它挪到某个远程的地方。所以你可以在笔记本电脑上开始，然后在手机上继续。它对那个 agent 来说是同一台计算机，它在做它的事情，对吧？因此这标志着我们现在已经认为它不再存在于我们的 localhost 是完全没问题的了。但再次重申，这对那个 agent 来说仍然是一个 localhost，这台计算机对于 agent 就如同笔记本电脑对于我们一样。
Matt: 所有的 agent 都需要沙箱吗？还是说这是一个特定的类别？
Ivan: 我的观点是，每个 agent 都会需要至少一个沙箱，有时候会需要更多，我们一会也可以再聊这个。有些地方你不需要。在很大程度上，我把 agent 类比为人类。我们也可以在没有计算机的情况下进行富有成效的工作。这就有了早期的那种聊天机器人，基本上你只是和 agent 说话，它进行推理（inference），所以它只是思考并给你提供价值。大家用它来获取情感支持什么的。在大多数情况下，它不需要计算机。它有足够的、与你来回交互的数据，然后它能理解并给你反馈。但这只是较小的一部分。如果我们看看所有生产力提升的地方，在一些最大的垂直领域中——医疗保健、金融服务等等——大部分都是通过计算机完成的。所以如果你希望 agent 能做所有这些事情，那么 agent 就会需要这些计算机来工作。
Matt: 所以如果你进行工具调用（tool calls）、编写代码，或者任何这类操作，你就需要一个沙箱。如果你只是聊天——
Ivan: 那你可能就不需要。是的。所以即便你只是聊天，如果聊天时它需要搜索网络，它仍然需要打开浏览器，或者需要使用像 Perplexity、Exa 等类似的东西来实现，那就是一个工具调用。所以这取决于用例。但关于我们所处的世界，有件非常有趣的事。第一，我们退一步来看。我坚信，在适当的时候，所有的工具都将是无头（headless）的。现在它是在沙箱内部还是外部那是另一回事，但它们都将是无头的。对于 agent 来说，那是最高效的工作方式。但是绝大部分知识工作仍然被锁定在遗留应用（legacy apps）中，锁定在 Windows 内部，真的是绝对的绝大部分。所以，如果你今天想让 agent 端到端（end-to-end）地完成一项工作，你实打实地必须给它一台计算机。关于这个的一个例子还是那个董事会报告的事。比如，“哦，你能调取这份报告吗？”我们的银行有一个 API，它可以调取数据，但 API 上只有支出数据，没有进账收入数据。它就是没有暴露出来。
Matt: 或者实际上也没有通过 MCP 工具暴露。
Ivan: 对，它没有暴露。然后 agent 就说：“哦，我获取不到。”我就说：“伙计，登录进去，然后下载它。”它就说，“好的，我去获取。”然后你能看到它打开了浏览器，去下载之类的。其他我们拥有的任何数据源也是一样的。如果它能通过无头方式拉取，它就会使用无头方式；如果不行，那它就登录并进行操作。所以，如果今天我们想要赋予它们力量并获得价值，我们就必须让它们拥有这些工具。
Matt: 你前几天发了一条很棒的推文，你在其中谈到了作为 agent 沙箱提供商，你所看到的实际用例。你想讲讲这个吗？你提到了代码和命令执行（code and command execution）、计算机和浏览器使用（computer use / browser use）以及 RL（强化学习）环境基础设施。你想展开讲讲吗？
Ivan: 当然可以。从那条推文之后，我想我已经对它进行了更好的梳理。现在我们有两个主要的用例，或者说两种类型的客户在不同的用例中使用 Daytona。第一类是研究人员，比如 RL 评估（RL eval）基准测试等。另一类是应用于我们所说的后台 agent 或长时间运行（long-running）的 agent。所以当你想到后台 agent 或长期运行的 agent，比如最流行的那些，即人类作为最终消费者。人类与包含 agent 的应用层服务对话，然后 agent 就会调用沙箱。想想像 Harvey 或 Perplexity，或 Lovable 这样的公司，作为这种类型的后台长时间运行的 agent，它们既可以是无头的（headless）——即代码和命令执行，也可以是计算机和浏览器使用。所以这取决于它们需要做什么。研究人员方面也是一样的，比如在进行 RL 评估等。你可以为编程做 RL 评估，对此它基本上就是无头的，在里面像执行命令一样执行。或者你可以教它在现实世界中做事情，那它就必须启动一个 Windows、Mac 或 Linux 的桌面或浏览器来走流程。代码和命令执行以及浏览器或计算机使用是 agent 工作的两种方式，因此为了执行这两种不同的任务，沙箱的消费方式基本上也是不同的。
Matt: 这真是一个很好的，对沙箱概念入门级别的介绍。帮助我们了解一下，在这个大家都在同时试图弄清楚的新兴 agent 技术栈（agent stack）的整体图景中，沙箱处于什么位置。有很多不同的组件，文件系统、编排等等，不同的部分到底是什么？
Ivan: 我试着思考所有的东西。对我来说，其实很有趣的一点是，我们稍后也会谈到这个。目前生活中的很多东西都已经存在了。所以人们在过度思考这个问题。我不是说不会有新的产品、解决方案和技术来解决它，但这并不是一种全新的工作基础方式。所以当你想到 agent 技术栈本身时，就像好的，首先你有模型（models），模型本质上是它的大脑，这等同于人类的大脑。你告诉它一些事情，它回答，它理解等等。在那之下的是，它能用什么工具把事情做完，对吧？这可以是任何通过 MCP 或工具调用能做的事情。它可以是沙箱，计算机，就像我们人类也有一堆使用的工具。从锤子到计算机，以及围绕它的一切，对吧？所以所有这些东西也是存在的。然后就是记忆（memory）的存在。agent 能记住这些事情吗？类似于你能记住那里的这些事情吗？人们谈论 agent 的编排（orchestration）。就像管理一样。你管理人员吗？我管理人员。管理 agent 类似于、并不不同于管理人类。现在你将使用什么工具来管理它们？你是否会用同样的方式管理它们，只是发一条 Slack 消息，或者你用 Linear，或者不管是什么，我们将拭目以待，或者是将出现一个全新的应用程序，我们会弄清楚的。但它就是这样的。当然，还有可观察性（observability），你能不能看到你的队友或同事做了什么，并验证那项工作是好的，对吧？这就是技术，这就是我在非常宏观的层面上如何思考这个问题的方式，然后你可以将其分解为人们为此创建的不同类型的解决方案。
Matt: 是的，让我们来谈谈其中一些吧。
Ivan: 我考虑的事情，比如还有哪些是已经解决的，哪些是未解决的。比如模型，我不是说它们已经被完美解决了，它们肯定还会继续进步。可能会有不同版本的模型出现，但很明确的是存在某种大脑，我们有领导者和前沿模型，也有人尝试做不同的事情，这可以说是大局已定。至于工具层面，我不知道是否还要花太多时间。这正是我们现在讨论的重点，也就是沙箱、计算机、MCP 工具等等正在涌现的一大堆东西。解决得不是很好的一个是记忆本身。比如记忆，你现在怎么做这个？最好的解决方案就是把东西倒进 Markdown 文件（MD files）里，然后你就有权限访问那些，然后你知道去压缩它。这正是我们前几天谈到的《为什么我们要睡觉》（Why We Sleep）那本书中的内容。在那本书里，讲到了很多如何进行数据保留（data retention）等类似的事情。这部分正是我们在 agent 领域试图为 agent 本身解决的问题，所以关于记忆部分就在这里。实际上让我非常感兴趣的是模型的学习。有一件事我之前没有理解或内化，那就是模型目前其实是不学习的。你使用一个模型，即使你解决了记忆问题，让它有了关于事物的记忆，有了这些上下文信息。所以它说，“哦，这里有上下文”，然后它可以因为拥有这些上下文而给出一个更好的答案，但它实际上并没有从昨天完成的工作中进行学习，对吧？所以谁在解决或者我们如何解决这个问题？这是否需要类似在后训练（post-training）阶段进行持续的强化学习（RL）？还是我们在模型根本上做出改变，让模型能够做到这一点？我不知道，但这绝对是一个阻碍当前进展的事情。目前还不完全清楚我们如何达到那一步，因为与一个实际上不会变聪明的人共事感觉有点奇怪，对吧？就像你换了个新模型，哦，出了一个全新的，但你做同一件事做了五次，它还是会搞砸，在第六次的时候它真的又搞砸了。是的，所以真的每一次都是这样。所以你可以尝试给更好的提示词（prompt），可以提供更多的上下文以防它再犯，但它实际上并没有学习。我认为看看这方面将如何进展会非常有趣。
Matt: 是的。从你的视角来看，记忆就是刚才提到的那些 Markdown 文件，或者是类似文件系统的组合，而不是数据库。Markdown 文件看起来极其优雅和简单，但总觉得不如数据库提供的能力那样强大。
Ivan: 我的意思是，就个人观点而言——而且我可能会改变这个观点，我也倾向于同意你的看法，也就是对于这存在的问题、其中的压缩机制以及你如何访问其中的内容而言，Markdown 似乎显得过于简单了。所以，我们作为一家为这些提供基础设施的公司，努力要做的就是确保我们能够以非常简单的方式，暴露 agent 访问并追加这些信息的能力。但是解决记忆问题本身是不在我们的……
Matt: 可以说是不在你们的职责范围（mandate）内。而且在这个整个的，我想可以称为 agent harness 中，你描述的一切似乎都属于当前的 harness 概念。从长远来看，沙箱适合处于什么位置？你认为其中的很多内容最终会被内置到沙箱中吗，还是说沙箱将继续作为执行层（execution layer）存在？
Ivan: 有两件事。如果你看这里，本身就有沙箱，我在这场谈话中一次又一次地重申这个比喻：如果我们以高盛（Goldman）的一位普通员工为例，你有一个工作者，也就是这个人，在这个语境下我们可以称之为模型。你有一台计算机，他登录进去。而这个 harness 是一套规则，它塑造了模型可以或不能做的事情以及交互方式，打个比方，它几乎就像是手一样，深入地说。但基本上，沙箱是为了支撑它而存在的。所以如果你再想想一台计算机，我再拿高盛来举例。我从来没在高盛工作过，这只是我的假设，我曾在一些大公司工作过。所以我的假设是，当你登录那台计算机时，里面有许许多多的软件记录着你在做什么、限制你能做什么、确保你不会泄露数据等等。再次声明，我并不真正了解高盛内部的情况，这只是对于这些事物的假设。所以作为沙箱提供商，这些类型的功能我们绝大多数肯定会将其整合进去。但是那个 harness 在其中仍有它的功能，即引导模型，比如：“哦，我现在知道怎么和这台机器交互了。哦，我知道怎么做工具调用了。哦，我知道这是我处理记忆的方式，这是我与模型交互更改的方式。”所以这里是有价值的。因此我们不会去承担 harness 的工作。这是一件我们非常确定我们永远不会去做的事情。但我们在沙箱中所做的事情确实能帮助或支持整个系统。
太棒了
Matt: 太棒了。我们讨论了模型。那么，像那些大型的、处于前沿的 AI 实验室这样的模型提供商，在这个整体格局中处于什么位置呢？OpenAI 最近发布了 agent SDK，那是什么？
Ivan: 是的。我的意思是他们在这个领域有很大的投入，比如 Claude Code 及其 agent SDK 已经推出了，因此对他们来说，现在的重点基本上是在市场的这个细分领域追赶上来。所以——
Matt: 这其实是两回事，对吧？有 OpenAI 的 agent SDK，然后还有 Claude 的托管 agent (managed agent)，或者说——
Ivan: 它们是不同的。对，它们是不一样的。
Matt: 好，请为我们详细解释一下。
Ivan: Anthropic 的 managed agent 是一项托管服务。你基本上把模型、harness 和 sandbox 都打包在一起了，作为一项服务为你管理整个技术栈。这就是 managed agent。相比之下，如果你只提供 agent SDK，你可以使用它并在任何 sandbox 提供商那里运行，或者在你自己的服务器、任何你想要运行的机器上运行，并且它可以连接到——取决于许可或其他情况——为你提供那个 harness 的模型提供商，或者你也可以将这些东西互换。所以基本上，一个只是 harness，另一个是将模型、harness 和 sandbox 全都结合在一起。
Matt: 好的。而且我相信 Daytona 是 OpenAI agent SDK 的合作伙伴，对吧？作为 sandbox 提供商之一。
Ivan: 没错，我们是那个最初框架的一部分。
Matt: 好的。这就是围绕 agent 技术栈的整体格局。稍后我们将更深入地从技术角度探讨 sandbox 及其工作原理。但作为个小插曲，让我们来聊聊你的故事和 Daytona 的故事。这不是你的第一次创业。谈谈你之前做的事情。你提到过一些，比如那个有点像 Replit 的项目。
Ivan: 是的。其实在 2009 年，我和联合创始人基本上开创了云端 IDE 领域。在 2009 年，经历过那个时期的人都知道，当时没有 Docker，没有 Kubernetes，也没有 VS Code，所以我们必须构建整个技术栈，我们在那个过程中学会了如何做这些事，并将这些经验应用到了今天。所以，那是真的非常非常早。我之所以说“我们开创了它”，是因为在我们之前起步的公司是 Heroku，它后来成为了如今的 Heroku，并砍掉了 IDE 业务（我们可能也早该这么做）。所以，从有始有终的意义上讲，我们是唯一一家。后来有了其他公司加入，像 CodeSandbox、Replit，还有现在的 StackBlitz 和 Bolt 等等。Replit 现在也发生了改变，Bolt 也转向了其他方向，Replit 做得非常成功。当我们决定创办下一家公司时，我们决定走一个完全不同的方向。我们已经学会了如何构建这整个技术栈，所以当我们决定启动 Daytona V1（与现在的产品不同）时，我们决定不做应用层，而是纯粹做基础设施——可能受到了 Heroku 发展方向的启发。我们觉得：“哦，我们已经学会了在底层编排层做所有这些事情，这似乎非常有价值。”所以我们就朝那个方向发力，这就是我们的起点。
Matt: 你在推特上说过：“我的第一家初创公司教会了我在 Daytona 绝不能做什么。”谈谈这方面，比如向开发者推销新的 on-prem 解决方案，谈谈你们学到的一些东西。
Ivan: 我们学到了很多东西。其中之一是时机（timing）。我以前从未理解过所谓的市场时机，你必须去选择。要把握市场时机非常困难，但如果你在正确的时间入场，或者相当快——理想情况下，你希望刚好在风口到来之前，但这非常非常难。你绝对不想完全踏空。我们大概错判了两个十年，或者说十几年。所以在这一点上我们绝对是错的。另一件事是，我不知道“用户”（user）和“客户”（customer）之间的区别。现在 Daytona 100% 是一种 PLG（产品驱动增长）模式。之前的 Codeanywhere 产品也是一种 PLG 模式，但它没有任何企业用例的价值，它的价值全都体现在单个开发者身上，而单个开发者是不愿意为这些东西付费的。相比之下，我们现在的产品虽然也是 PLG 模式，也为单个开发者提供价值，但这个开发者很可能是在一家公司内部工作，因此他们会用公司的信用卡来支付，这就非常非常不同了。但你刚开始的时候是不知道这些的。所以，这些绝对是我们在创办这家公司时弄明白的事情。至于 Daytona V1，我们没细说，它是一个为大型企业的人类工程师进行管理的基础设施产品，完全是 enterprise（企业级）打法；而 Daytona V2 的 sandbox，我们可以称之为新一代云（neo-cloud）。尽管 neo-cloud 通常是指 GPU 云，但我们确实意识到这里有一个企业级市场可以切入。所以，我们所学到的一切关于 on-prem、multi-cloud、不同的管理方式、可观测性、审计日志等等企业所需要的东西，我们要么已经内置了，要么已经知道未来会需要，所以我们从一开始就为产品做好了准备。
Matt: 太棒了。你在整体分发和品牌建设，以及吸引开发者方面也非常出色，这很令人着迷，对吧？因为这是技术型创业公司典型的痛点之一：团队里的人往往非常优秀，对产品和技术有极深的思考，但在分发和推广方面却常常是事后才想起来。你是如何在这方面变得擅长的？有什么经验可以分享给技术型创业者吗？
Ivan: 我的意思是，这很大程度上是因为我在这些方面可能曾经做得极度糟糕。有太多方式来讲述我们是怎么做到的了。首先，我认为我非常了解“规模化的人类群体”（humans at scale）——了解市场想要什么、需要什么，或者感受到什么。当你做到这一点时……我并非生来就知道这些，而是你开始逐渐学习，你开始理解人。要理解单个的人很难，但理解更大规模、聚合起来的人群要容易得多。这是一方面。另一方面，我小时候是一个超级害羞、有点极客（geeky）的人。
Matt: 而且有舞台恐惧症。
Ivan: 非常可怕的怯场。比如为我的第一家初创公司做路演时，我会紧张到在登台前五分钟，必须去洗手间十次，纯粹是因为这种压力。后来几乎是偶然发生了一件事：在我们的第一个创业项目 Codeanywhere 期间，我们在世界各地的这些会议上到处路演。很有趣的是，在其中一次会议的 afterparty 上，我当时可能喝得有些醉了，那个会议的创始人之一问我：“你想在克罗地亚办一场会议吗？”（我当时住在克罗地亚），我就说：“好啊，我们办吧。”于是我就去筹办这场会议。会议在克罗地亚举行，有 250 人参加，这对当时的我们来说已经是很大规模了。我雇了一个主持人，结果他在最后一刻爽约了。所以就没有主持人了，而我有舞台恐惧症。
Matt: 你只能亲自上了。
Ivan: 我只能硬着头皮上了。我就这样连续两天亲自当了主持人。这就好像硬生生地打破了这种恐惧，你必须去面对它。我想说的是，这跟走向市场策略大不相同，但它建立在这样一个基础上：一旦我不再有舞台恐惧症，你就开始学习、开始理解怎样的互动能让人们兴奋，怎样的互动效果不佳，如何吸引人们等等。这也是个问题，因为当我们说要办一场会议时，我其实根本不知道会议是什么。你得去拆解会议是什么：会议首要的就是娱乐，你得有一场秀；秀的核心是演讲嘉宾，你怎么请到他们？有了演讲嘉宾，你就得去向观众推销。观众是谁？谁会来？你怎么把他们吸引来？然后还得有人为这一切买单。观众确实买门票，但绝大部分收入来自赞助。那你如何向赞助商推销？你把这些事情拆解开，然后开始理解所有这些不同参与方的激励机制，并把它们整合在一起。我们的 GTM 动作也是如此。我们做会议做了差不多十年，所以你每年的迭代周期就是这样；后来我们开始一年做两次，然后一年做三次。每一场会议都比上一场好，因为迭代周期变快了，反馈循环变快了。后来当我们决定做 Daytona 的时候，我们最初的整个 GTM 策略都围绕着线下活动展开。我们举办了晚宴、meetups、drinkups（喝酒聚会）、黑客松，但它们都是简化版的会议。要记住，我们以前办的会议有 4000 人规模，已经相当大了，虽然不到 10 万人，但也很大了。我记得我曾对现在在 Daytona 和我一起负责会议业务的一个同事说：“我死也不会再办会议了。绝不干了。这是世界上压力最大的工作，绝不再干了。”但我们会做这些小型的活动，因为它们很简单。然后人们会跑来问我们：“你们是怎么办这些活动的？这些 meetups 是怎么组织的？”其实，当你懂得了如何举办一场大型会议——了解利益相关方有哪些——你自然就知道怎么举办一场小型的 meetup 了。同样的原则也适用，只不过规模小得多，容易得多。最后我们办了一大堆这样的活动。这些活动显然不卖票，但在场地爆满的意义上，可以说是“售罄”了。我们现在还能吸引到合作伙伴来和我们共同赞助这些活动。这对我们来说是一个极佳的 GTM 动作。后来到了某个时候，我的同事说：“我们必须办一场会议。”我说：“不！”但最终我们还是在大通中心办了。两个月前，我们在旧金山的大通中心办了一场。我想你当时也在，你还帮忙了。
Matt: 是啊，顺便说一句，整个活动非常不可思议。当你把营销视为一种建立公司、创造品牌、让公司看起来庞大且有实力的努力时，那简直是一次大师级（masterclass）的展示。
Ivan: 谢谢。但我们在 GTM 方面所做的全部也就是这些了，我们没有做其他的事情。比如 Twitter 也是一种走向市场的方式。我们完全没有销售人员之类的。我思考这个问题的方式（这是我从 Sentry 的 David 那里借用或改写过来的）：人们选择你的产品基本上有三个层面。第一是知名度（awareness），他们知道你的存在吗？如果不知道，他们根本无从选择你。第二是偏好（preference），涉及定价、品牌、个人好感度、不同的功能等，这属于偏好。第三是，你是否能提供别人都没有的决定性优势？第三点最简单的例子就是：你是否有 FedRAMP 认证？如果你有这个合规证书，客户可能就只能用你而不能用别人。但前两点非常有趣：如何确保每个人都知道你是谁，然后你再去建立这种偏好。所以对我来说，我花很大一部分时间思考的是——如果所有条件都一样，如果我们的产品和其他所有人的产品完全对等，那么区别在哪？怎么才能让更多人了解你？你的品牌建设是否到位？体验是否出色？体验是一个非常微妙的东西，有些人会去想它，有些人不会。但问题是，比起那个产品，你是否更喜欢这个产品的感觉？这些都与产品的实际技术能力毫无关系。所以我的联合创始人、我们的 CTO Vedran，他的工作主要是确保产品比市场上任何其他产品都好。而我的任务是确保，即使我们的产品只是和其他人持平，我们也能在体验和品牌上超越他们。这就是我对 GTM 的总体看法。
Matt: 你是否也把客户支持和客户服务视为——
Ivan: 这些全都是！这些全都是 GTM 的一部分。我们讨论过这个话题，我们能够获得用户和客户，仅仅是因为我们在这方面做得太好了，这一切都是一种体验。试想一下你作为一个人去任何地方的体验，去商店、餐厅或者任何地方，整个体验就是……什么叫品牌？品牌就是感知。而感知是什么呢？如果你走进一家商店（随便挑你喜欢的品牌），你所感受到的气味、音乐、店员的态度、他们的微笑等等，所有这些加在一起，就是对那个品牌的感知。所以，如果你通过产品的视角去思考这个问题——这听起来可能有点反直觉或者不太明显——但我是把所有东西结合在一起去考虑的。假设我们是卖运动鞋的（当然我们不卖），提到这个品牌的运动鞋，我们就不点名其他品牌了，但是——
Matt: 如果你想点名也可以，或者总是可以把话题转回到 GPU 上。
Ivan: 对，就像如果你去这里纽约的实体店，那是个很美的商店，店员非常友善，一切在美学上都很悦目，你就是纯粹享受那整个体验，而且那双鞋确实也不错，对吧？所以你必须把所有这些元素结合在一起，这也是我思考这个问题的方式。你必须有一款好产品，你也必须具备所有这些体验，所有这些因素必须融合在一起。当然这也有风险，我们在很多初创公司身上看到过这种情况：如果产品本身不行，缺乏实质性的支撑，但你拥有其他所有花哨的东西，那你就会陷入困境。但如果产品足够好，哪怕只是持平甚至更好，那就太棒了，再加上所有这些良好的体验……我相信这是保持持续增长的关键驱动力。
Matt: 太棒了。你一分钟前刚提到 Twitter 和 X。在你们的整个计划中，它占多大比重？
Ivan: 很难去量化它。
Matt: 像我曾在较大的公司工作过，如果我在前东家提出这个，他们会问我们怎么去衡量它？我完全不知道该怎么衡量。
Ivan: 但我能说的是，我以前在 Twitter 上从来不怎么活跃。我从 2009 年就注册了账号，但一直没怎么用过，直到去年假期期间，我发了一条有点小火（semi-viral）的推文。
Matt: 你当时发了什么来着？
Ivan: 当时那条推文是：如果你在这些假期休息，你就是 NGMI（Not Going to Make It，你没戏了）。
Matt: 是的。
Ivan: 我当时真的是这么想的。
Matt: 对。
Ivan: 推文大概就是这样，我甚至都没多想，推文里还有个拼写错误。这并不是在搞什么“引战（wage-baiting）”，完全不是。我当时的想法是，我们现在正处于一个超级周期（super cycle）之中，而超级周期不会永远持续下去。所以，如果你在这个超级周期期间停下来休息，你就是在将市场拱手让人（ceding market）。你真正在做的就是这个。而且，这条推文主要是针对创始人、高管和技术领袖的，而不是针对那些对此无法产生重大影响的普通员工——大家都需要休息。结果人们对这条推文的解读五花八门，有的人在上面拉屎（to poop on it too），说“你应该去死”、“你是个资本家”之类的。它之所以变得那么火……其实也就是有点热度吧，是因为有个人回复说——
Matt: “老兄，我从来都没听说过你”，或者类似的话。
Ivan: 然后我基本上回复说：“这就是为什么你要继续工作的原因。”这就很完美了，我立马就回复了。总之不过多谈论这件事了。从那之后我注意到，人们无论是否喜欢你的推文，或者是否强烈反对，这对他们怎么看待你的公司其实都有积极的影响。我们发现，即使是那些完全反对我帖子的人，最终也成为了我们的客户，前提是他们需要这条产品线。当然不是每个人都会这样。但这件事让我觉得很有趣：哦，仅仅因为某人不赞同我的观点，并不意味着他们就不会喜欢这个产品，因为总的来说，这一切都是在建立知名度。
Matt: 这正是后来我在 Twitter 世界里花了很多时间试图向你学习的地方。是的，这非常有趣，对吧？对任何 AI 开发者或 AI 创始人来说都是如此。所以，最终要创造内部流入的 PLG 动作是所有这些因素的组合。我们讨论了会议和 meetups，Twitter 也很重要。还有什么大家应该知道的吗？我们谈到了客户服务。你刚才提到你们目前没有销售人员。
Ivan: 我们完全没有销售人员。是的。所以我认为关键在于你如何体验这个产品，对吧？一旦你看到了这个产品，你是如何体验它的？就像你进入产品的门户：网站、登录流程或任何其他东西。我们可以清楚地把很多这种事情修补好。我并不是说我们在这些方面做得最好，但它是存在的。然后，产品里面有哪些功能集？我能很容易地获取想要的东西吗？我们的 SDK 真的非常非常好，大家都很喜欢它们的人体工程学设计，所以那部分非常棒。然后还有一件事，这甚至在推特上也是公开的。我们所有的案例研究都是外包给第三方做的，我们不参与其中，他们提到的一点就是：我们的回复速度非常非常快。这是一件非常公开的事情，这也是我个人的核心特质以及我学会的工作方式。我最初的“第一份真正的工作”是做系统管理员，我的工作是修打印机、电脑之类的。我学到的一点——我也经常跟我的整个团队强调——就是你必须做到第一响应非常快。只要第一响应非常快，人们就会平静下来。他们知道自己已经把问题转移给了别人，而且有人已经确认收到了。所以当他们得到确认后，他们就觉得安心了。然后你只需要承诺在 X 时间内解决问题或给出回复即可。在那个时间点之前，他们都会保持平静。接下来你要做的就是：要么在给定的时间内解决问题；要么在那个时间到来之前联系他们，给他们发信息或者沟通，并给出一个新的时间节点。这就是客户支持的终极解决方案，仅此而已，没有比这更复杂的了。当然，有一些关键的例外情况，比如系统真的宕机了，用户完全无法工作了，那是完全另一回事。但对于其他所有非紧急问题，只要你这么做，你就会拥有世界上最快乐的客户，因为他们不需要再去操心他们的问题了，你替他们操心。你可以一直这样跟进，直到问题解决。最关键的一点是，如果我说某个东西需要两天来修复或部署，如果在过了一天半之后我发现两天内弄不完，我会在一天半的时候对他们说：“嘿，这个需要再延期两天。”他们也会觉得没问题。你在他们想到问题之前就提前想到了。这并不神奇。我是说，这能带来神奇的体验，但这并不是一件非常复杂的事情，但我发现人们在直觉上并不理解这一点。所以，这就是我当年学到的东西，也是我们公司今天所做的事情。这就是为什么我们有非常非常开心的用户和客户。
Matt: 好的。太精彩了。现在让我们转回更偏技术的内容。我们刚才讨论了 sandbox 的概念。请从技术角度带我们梳理一下 sandbox 究竟是什么。
Ivan: 好的，这里面有很多东西可以聊。我对 sandbox 的看法是，它是计算资源消耗的“人体工程学”（ergonomics）。因为这里面包含许多不同的层级，我基本上把它分为三个层面：基础设施层（infrastructure）、原语层（primitive）和工具层（tooling），这三者结合在一起。我所说的基础设施是指：它的启动速度非常非常快吗？你能同时启动很多个吗？比如我们能够在 60 毫秒内启动。所以这是创建它们的速率。我们可以在 70 秒内启动 5 万个 sandbox，也就是不到一分半钟。一旦它们启动起来了，你能保持多少个在运行？我们有客户每天产生数十亿个 sandbox 实例。所以这些都是非常不简单的大型基础设施挑战。
Matt: 为什么初始化一个新的 sandbox 的速度以及能初始化多少个 sandbox 这么重要呢？
Ivan: 同样，这取决于用户和使用场景。如果你是一个长时间在后台运行的 agent，大家都希望它快，没人喜欢等待。你不想等一个回复。要明确一点，所有人都希望越快越好。所以越快越好是共识，但通常你要求它非常非常快的背后是有实际原因的。特别是在……我本想说对于后台 agent 而言，后台 agent 可能会工作 10 分钟或一个小时什么的。所以增加那一毫秒的延迟可能并不重要。但我依然认为，从用户的角度来看，哪怕是一秒钟的等待也会让人有些不舒服。你不想要那种感觉。所以如果是 60 毫秒或者 90 毫秒，可能感觉就没那么明显。但你绝对希望启动时间能控制在一两秒之内。更有趣的部分，或者说启动速度真正极其关键的地方在于研究人员。当你在做强化学习（RL）或者 eval 时，你基本上有一批分配好的 GPU，而 GPU 比 CPU 贵得多。这里要明确一点：绝大多数的 sandbox 都是 CPU 机器，也就是我们平时工作用的电脑。里面可能有一块显卡，但本质上它是计算资源、RAM、CPU 和里面的硬盘。至少在目前阶段，它们是更便宜的，也更容易获得。
我们来看看这能持续多久
Ivan: 我们来看看这能持续多久。接着是 GPU，这意味着你总是希望 GPU 处于最大利用率，而 CPU 可以在需要时空闲，但你希望，你不希望 GPU 空闲。因此，这意味着你必须确保 CPU 机器（sandbox，沙箱）启动得非常快，因为在训练运行时，你不会把它们一下子全部启动。你会根据你拥有的数量来启动它们，比如一次启动一千个。它们执行任务，然后执行下一个、下一个、下一个。因此，在打开和关闭 CPU 之间，你希望这个时间尽可能短，这样 GPU 利用率就不会下降，对吧？所以这就是为什么这非常非常非常重要。显然，并发数量也取决于后台 agent。比如，大家都知道的 Lovable，他们的用户数量非常惊人。每个用户针对每一个任务（他们可以有多个任务、多个 agent），都需要一个 sandbox。所以想象一下，我不知道他们的用户数量是否有几百万什么的。那你必须有数以百万计的 sandbox 在运行。在强化学习（RL）方面，可能会有一些较小的实验室，他们需要并发 5,000 或 10,000 个，但我们今天接到了一个 500 万并发的请求。也就是在同一时间点有 500 万个。所以能够处理这类事情，属于基础设施（infrastructure）这部分。另外两部分是基元（primitive）和工具（tooling）。基元本质上就是——我们称之为计算机本身：隔离、VM、容器（container）、microVM、isolate 或是别的什么。我们可以详细探讨它们分别是什么，但它们有不同的形态。另外这些东西有什么功能集，对吧？所以大多数情况下，你在 AWS 等地方找到的 VM，通常启动要慢得多，也很难应对那些突发的流量峰值。而且当你设定了特定的尺寸，它们通常就永远保持那个尺寸。举个例子，在 Daytona 中，你可以定义一个尺寸（CPU、RAM、磁盘），然后在它运行时你可以调整大小，所以如果一个 agent 用满了所有的内存或 100% 的 CPU，普通 sandbox 或 VM 会死机。而在我们的情况中，我们可以扩展它。还有其它的东西。对我们来说，它不只是一台 Linux CPU 机器。它可以是 Windows、Mac 或 Android。它可以，你知道，里面可以带一个 GPU，也可以不带 GPU，取决于你需要什么。所以这就是基元。最后一部分是工具（tooling）。工具就是工具。工具要么是为了支持 agent 更好地完成工作，要么是给 agent 提供护栏（guardrails），基本上是为了防止它做蠢事。所以你可以想象，我们有一系列工具：无头（headless）终端、文件操作等等，能让它使用更少的 token，更快地完成任务；还有护栏，比如 secrets manager（密钥管理器）和防火墙等其他东西。因此，这三者的结合——基础设施、基元和工具——本质上构成了我们所说的 sandbox。那么 sandbox 与容器、VM、microVM 之间到底有什么区别呢？
Matt: 所有的这些东西、所有的乐趣，目前大多数 sandbox 提供商用的是 firecracker、VM、microVMs 等，绝大多数——
Ivan: 提醒一下大家 firecracker 是什么。
Matt: Firecracker 它是一种隔离基元。所以它本质上是一种高度精简的 VM 或虚拟机，由 AWS 团队打造，用在 Lambda 里面。因为 Lambda 就像是一堆函数，所以当初的理念是需要一种非常非常快、能够迅速启动并且无状态的东西，它们非常短暂（ephemeral）。所以它们被用来，你知道，当你的网站遇到巨大的……比如如果遇到“黑色星期五”，大量用户涌入你的网站，你可以非常快地启动大量这类虚拟机，从而处理负载，让所有这些人能浏览网站并购买他们想买的东西，对吧？所以那种技术是现成的，它是一个全功能 VM 的高度精简版本。所以它的功能更少，但它能做的事情，它做得非常非常非常出色。所以它可以非常快地启动。它之所以能做到这一点，是因为它可以某种程度上将东西懒加载（lazy load）到内存中。你可以做时间点快照（snapshots）。你可以做所有这些很棒的事情。但它做不到的是，它无法运行——现在我们称之为 sandbox——它无法运行带有 GPU 的 sandbox。这根本行不通。所以你不能用 firecracker 做这个。如果你想要 GPU，你必须用别的东西，比如 cloud hypervisor 或者 QEMU（拼作 Q-E-M-U），这是两种不同的类型。QEMU 几乎是一个完整的 VM。所以它里面包含了所有这些不同的东西。所以用 firecracker 做不到这一点。但举个例子，如果我们需要运行（我们今天早些时候就为一位客户解决了这个问题），他们需要一台机器，里面还带有一个 Android 设备。所以我们能解决这个问题的唯一方法，就是在其中一个 QEMU 里面运行。它在 firecracker 里跑不起来，在容器里跑不起来，在任何其它东西里都跑不起来。所以有许多不同的类型。这些就像是微型虚拟机（microVMs）。也有容器。说起容器，大多数人都知道 Docker。Daytona 最初也是从运行 Docker 容器开始的。我们现在也支持。Docker 的问题在于它们比 VM 的安全性低得多。我们在 Daytona 所做的是，我们用 Sysbox 来对它进行加固（harden），Sysbox 是一种包裹在它外面的类似 VM 的隔离层。它非常适合处理这些机器的密度。它非常快。它允许我们在 Docker 中运行 Docker。有一堆特性，它非常非常擅长。所以这中间是有区别的。此外还有 isolates（隔离区），我们之前讨论过，或者其它应用容器，这是这些容器的抽象，你只运行一个应用。所以这世界上存在所有这些不同的东西，理论上，结合刚刚说的那两个其他要素，它们都可以成为 sandboxes。我们最初的想法（回到刚才的话题），大多数 sandbox 提供商都是从 firecracker 起步的。但是当我们开始看到 agent 有不同的需求和用例时，他们将需要所有这些不同的形态，并通过统一的接口来使用。因此，我们在 Daytona 现在支持容器和所有这些 microVMs，具体取决于你的使用场景。用户不知道，人体工学体验是一样的。就像，“哦，我需要一个 Windows”，它就会启动那个。“我需要一个 Linux”，我就会启动那个。所以我们将继续在相同的基础设施内添加这些东西。有时它会稍微快一点或慢一点，但并发能力会在那里。所有的工具都在那里。所以，你会了解并喜欢上 Daytona 的一切特性都会在那里，只是它们会有不同的规模、速度和配置，具体取决于你的使用场景。
Matt: 为什么快照（snapshots）如此重要？
Ivan: 原因有很多。我们先从商业角度说起吧，这可能是大家最常想到的，那就是暂停（pausing）一个 sandbox。所以如果你是一个应用层公司，你有 1000 万用户，你的 1000 万用户启动了……为了好算账，我们就假设是 1000 万个 sandboxes。这些东西是要花钱的，对吧？因为它们在运行，整个过程都在消耗 CPU、RAM 和硬盘。最昂贵的是 CPU，其次是……RAM 和硬盘几乎是免费的，非常便宜。然后用户派 agent 去做某事。agent 做了一件事，现在在等待回复。它可能在等待人类，或者等待某个服务的回复，取决于它想做什么。理想情况下，你不希望那个 sandbox 闲置运行，因为不管你是 Daytona 的客户还是自己运行，运行这些东西都是有成本的，你现在都在为此付费。因此，你希望做的是暂停它，等待服务或人类的回复，然后再恢复（resume），而且让感觉和体验就像它从未关闭过一样。所以你感觉它从未关闭，但它实际上关闭了。所以这一点，从计算管理角度来看，如果不是纯成本角度的话，可能是第一个原因。第二点是，你可以让你的 agent 采用多条路径。你的 agent 可以说，“哦，在这个时间点我要拍个快照，然后我们要么继续，并且能够回滚（roll back）到这个时间点；要么在这个时间点，我会复制这个 sandbox，拥有两个 sandbox，我可以同时尝试两条路。”显然它可以复制更多，但对吧，这就是为什么你需要这个功能的原因。
Matt: 你提到了性能和速度。与此相关的是，你说你必须重写你自己的调度器（scheduler）。
Ivan: 对。
Matt: 那么，首先调度器是做什么的？然后你是如何去做的？
Ivan: 今天存在的每一个云，无论是 NeoCloud、超大规模云（hyperscale）还是别的什么，它们都是建立在服务器上的，对吧？比如裸金属机器，我不知道，回顾很久以前的历史，我和我的联合创始人在很久很久以前，我们实际上是手工堆叠这些数据中心的服务器的。但它们都只是服务器，就像 CPU、RAM、磁盘，它们基本上就是计算机。而在这些计算机之上，有一层大家都为了各自的原因而构建的软件栈。所以 AWS 有他们的软件栈。Cloudflare 有他们的，它们非常不同。每个人在这之上都有自己的一套东西。所以基本上你要做的是，当你考虑这些机器、这些服务器时，基本上我们做的是把它们切分成小机器，然后把那个 sandbox 给你。所以你在这些大服务器上有这些小机器，它们可以运行一分钟、一秒钟、3 小时等等。你不需要担心这些。基本上，调度器（scheduler）或者说编排器（orchestrator）就是那个主要负责这些的组件。它会说：“哦，在你向我发送请求后，我把你分配到这台服务器，在那里开启那个 sandbox 或小计算机，然后我关闭它，或者终止它，或者给它拍快照”，它负责管理所有这些事情。我们这个领域的其他大多数公司，基本上使用的是现成的调度器。可能是 Kubernetes 或者 Nomad 或者别的什么。当我们决定构建 Daytona 这个 sandbox 产品时，我们不知不觉地、非常天真地觉得：“哦，这些东西行不通”，因为我们曾跟所有的打过交道，我们自己构建过，后来我们又使用了 Kubernetes。我们见过所有这些不同的东西，我们知道什么是好的什么是坏的，或者它们适用于什么场景。没有一个是为这些超快、有状态（stateful）、长时间运行的机器设计的。所以我们觉得我们必须……我们必须重做一次。我们必须重新构建它，因为我们当时的构想（当时还不被大家所知，因为那时候 sandbox 非常短暂，类似于 Lambda 函数），我们就在想，“不，为什么你的 sandbox 默认就该是短暂的？就像你的笔记本电脑，你不希望它死机。你希望它一直工作直到任务完成，并且它必须非常快，具备所有这些特点。”所以我的联合创始人主要构建了我们调度器的初始版本，我们这个调度器是我们所做一切的基础。它给了我们很多东西。除了性能之外，它还使我们能够做一些事情，比如拥有四种不同的隔离提供者。目前我们是唯一一家（作为用户你可能不知道）会根据你的使用场景，为你启动 firecracker、cloud hypervisor 等任意一种，来完成工作的公司。所以无论需要什么，我们都能提供。另一个好处是，既然我们构建了这个，我们就有托管（collocation）提供商，所以我们有裸金属机器。你可以把我们看作是我们自己的云，但我们现在越来越类似于那些 neoclouds（新一代云服务），比如 Base10 还有 Fireworks。因为对我们来说（这也是我们昨天被问到的问题，因为我们接到了对 CPU 数量的巨大需求），就是我们无法获得足够多的 CPU。那我们如何解决这个问题？嗯，我们已经解决了它。我们的调度器可以附加到任何 CPU 机器、任何我们认为足够好的服务器上，它就本质上成为了我们云的一部分。因此，为什么我提到 Base10 和 Fireworks，是因为它们都运行在十几个计算提供商（不管我们怎么称呼它们）之上。既然我们的设计方式是这样的，我们就能做到类似的事情。所以这赋予了我们……我相信这赋予了我们一种优势。
Matt: 那么短暂运行（ephemeral）和长时间运行之间存在根本的技术差异吗？如果你有一个 agent 运行 24 小时，这在 sandbox 需求方面意味着什么？
Ivan: 大多数 sandbox 环境不能永远运行，甚至不能长时间运行的原因，在于这是一个技术问题。如果你想想底层的服务器，这些服务器也必须受到管理和维护，对吧。因此，如果你的 sandbox 可以永远运行，那意味着你永远无法重置、永远无法重启底层的服务器。你无法在不关闭所有 sandboxes 的情况下对其进行更新、打补丁或者执行所有这些操作。所以你解决这个问题的最简单的方法，就是让 sandboxes 有一个终止时间（termination time）。就像它们只会持续一个小时、24 小时，没关系，只要有一个固定的时间。如果那时你决定必须对底层机器做些什么，你只需将那台机器标记为不可调度（non-schedulable）。所以到了某个时间点，那台机器上就什么都没有了。你可以做你想做的，你可以修复它，重启它，随你喜欢。轻而易举就搞定了，对吧？所以因为历史上大多数的工作负载都是短暂的（ephemeral），你不需要费心去解决这个问题，因为你不在乎。大多数工作负载，比如 lambda 函数通常只运行五分钟、十分钟什么的，这不是问题。你从来没有过现在这样的限制或约束。为了拥有可以永远运行的东西，你必须能够在机器之间对 sandbox 本身进行实时迁移（live migrate），这样你就可以重启并管理这些机器。我理解大多数人……有趣的是，即便是技术消费者也会说：“哦，所有的计算资源都是弹性的。”嗯，是的，你从我们或从 AWS 消耗的资源是弹性的，但必须有人切实地去组装一台服务器，开启它，启动它，确保它能工作，对吧？并且要在那储备足够的量。这就是我们视角的差异。为什么大多数起初都是短暂的，是因为这样更简单。我们相信，而且我们也看到了这一点。我想我们现在有 2.5% 的收入来自……或者是 2.5% 的 sandboxes 运行超过 24 小时，但这占了很大一部分收入，大概 20% 的收入。所以从用户的角度来看，这不是一个无关紧要的部分，仅仅因为它能运行更长更长的时间。为了结束这个话题，有时候用户实际上希望它是短暂的。一个是他们不想要任何数据保留。所以他们希望它运行完毕后就消失，无论里面运行了什么，只要他们得到了想要的数据，他们就希望那些数据死掉。所以他们在我们这里把它标记为短暂的（ephemeral）。这意味着我们不会强制它关闭，但当他们杀掉它时，它就不再存在了，它进入了虚无（ether），彻底消失了。
Matt: 听了这一整个关于技术的深度探讨，我脑海中闪过一个想法：似乎有很多人认为他们可以创建自己的 sandbox，这并不难，但听了所有这些，我的想法是，“祝你好运”。
Ivan: 不，所以我们已经多次看到这种情况，我确信你在其他公司也看到过。你知道，每个人都觉得，“哦，我可以在一台机器上启动一个 firecracker。”是的，你可以启动一个，但启动一百万个是个问题。添加所有的这些功能是个问题。保证吞吐量、满足不同的用例，这些全都是不同的问题。我们已经看到，那些说着“哦，我们要自己做”的公司，在 3 个月后、6 个月后、8 个月后回来了。他们会说：“哦，其实，实际上我们现在做不了 X 和 Y。”所以在技术方面有一大堆事情我们可以讨论，我想我们可以以这个作为结尾。那就是 Daytona 做的事情是，如果你看看大多数 sandboxes——这其实是个性能问题。大多数 sandbox 和大多数 VM 实际上使用服务器的 CPU 和 RAM，然后它们从网络驱动器（network drive）使用硬盘。你这样做是有很多原因的。如果那样管理，你的日子会好过得多。为什么更容易呢？这更容易，因为如果一台服务器宕机，所有数据都在共享驱动器上，我可以非常快地重启那台服务器，甚至用户都不会注意到，也没有数据丢失。可能内存里会丢点东西，但在那驱动器上什么都没丢。所以这非常、非常容易管理。然而我们做的是，我们实际上使用的是那台机器本地的 CPU、RAM 和硬盘。这意味着我们会有极大的管理开销。如果那台机器宕机，我们怎么把它重启回来？你必须在用户看不见的后台进行备份。你必须处理所有这些发生的事情。但这也意味着，IOPS（每秒输入输出操作次数）——你往硬盘移动数据的速度，或者 CPU 和 RAM 与之交互的速度——如果是从网络驱动器来说，仅仅给大家一个直观数字，它在数十万级别；如果它是本地驱动器，它是数千万级别。不管具体的数字是多少，差距就是大得惊人，对吧？这是非常非常不同的。所以有的用例根本不在乎这个速度，那挺好的。但我们有新客户，他们的用例就是：“它必须有这么快”，对吧？所以当你到达那个临界点，“哦，我可以用这个，但是等等，现在我需要这种性能。哦，现在我做不到了。”对吧？因此，关于沙箱的复杂性，当人们刚起步时，他们的用例是：“哦，我只需要运行代码”。你可以在任何地方运行代码，非常容易，除了规模化（scale）很难。然后当你需要规模化，随后你需要性能，因为现在 agent 能够做很多事情，那就会开始打破原有的模式了。
Matt: 还有安全性（security）。
Ivan: 是的，我们甚至都没触及安全性这块，但确实如此。
Matt: 太棒了。在结束这次谈话时，让我们把视野拉宽一点。你提到的一件事引起了我的注意。我们经历了一段证据确凿的 GPU 短缺期，但似乎我们可能正走向 CPU 短缺。
Ivan: 是的，这可能正在发生。你们之前的一位嘉宾，也参加过我们的会议的 Dylan Patel，类似 SemiAnalysis 团队，他们写了一份报告，我相信大概是说到 10 月份我们就没有更多的 CPU 了，而人们以前并没有想到这一点。大家觉得一切都是围绕 GPU，都是 GPU 密集型，接着是内存。但基本上现在，因为 agent 需要所有的这些计算机，这些资源非常紧缺。既然强化学习（RL）是我们在过去 18 到 20 个月里在模型上取得大部分进展的途径，你需要所有的 CPU 机器来做这些。既然现在 GPU 变得更强大，它们可以并行处理更多这些 CPU、CPU 机器的工作。然后你看看这个，我前阵子发过一条推文说：“你绝对应该投资（非财务建议），你应该投资英特尔并关注一下他们的股价”，对吧？所以绝对有这个需求，这是大家没有理解或者直觉上没有意识到你会需要的东西。所以，我们经常思考的一点是：“我们能……（这也是暗示我们的产品是如何构建的），我们如何确保我们能满足客户对他们拥有的 CPU 的需求？”因为我不知道这是否会走向像 GPU 那样的极端，因为那是极其极其极端的。但是，未来 CPU 出现短缺的概率相当高。
Matt: 你认为所有这些 agent 技术栈（stack）会如何演变？你觉得我们已经把所有的核心拼图都凑齐了吗？还是你觉得再过两年，整体架构可能会看起来截然不同？
Ivan: 关于这个，我们已经谈到了技术栈和必须完成的工作。身份（identity）部分确实需要解决。再说一次，它基本上解决了，但又没完全解决。所以那里有很多事情要做。实际上，我也非常谨慎，或者说我在思考，人们认为我们拥有的模型、我们拥有的模型技术就是最终状态。我真的、真的不认为这是对的。我觉得……那可能是最令人惊讶的事情了，比如我们会拥有一种新型的模型，它就是比我们现在拥有的更好或者不同，它可能要么需要更少的计算力，要么不使用 GPU，或者不……我不知道。我们已经看到了带有“湿件（wetware）”的东西，人们搞出类似假人脑的东西，然后它学会了玩《毁灭战士》（Doom）。比如之前不是有个苍蝇大脑被复制到计算机里，然后就能像苍蝇一样运作吗？那你能复制一个人脑吗？我说这个不是为了复制我自己，但是你能复制一个通用的人类大脑，然后它就是一个本质上等同于人类和 AI 的 AI 吗？那这对所有技术意味着什么？我的意思是，我现在说的是一些对大众来说比较极端的东西，不要误会我的意思，我不认为这会在明天发生，或者说我彻底疯了。但我不认为我们现在的状态就是最终状态。问题是这种情况是迟早会发生，还是更早会发生？我们的 transformer 还会继续占据未来智能的绝大部分吗？如果是的话，那么它很可能会继续朝着它目前的方向发展。但是如果发生了什么从根本上改变了这一切的事情呢？这是我思考的问题。因为到了那时候，所有的押注——你们的和我们的——都会变得非常非常不同，对吧？
Matt: 好的。哇，Ivan，这太精彩了。非常感谢你今天花时间与我们交流。
Ivan: 谢谢你邀请我。我们聊得很开心。
Matt: 大家好，我是 Matt Turck。感谢收听这期 MAD Podcast。如果你喜欢这期节目，如果你还没有订阅，我们非常感谢您能考虑订阅，或者在您观看或收听这期节目的任何平台上留下积极的评论或留言。这真的非常有助于我们办好播客并邀请到优秀的嘉宾。谢谢，我们下期节目再见。