Why Every AI Agent Needs Its Own Computer | Ivan Burazin (Daytona)

我们现在正处在某种 super cycle（超级周期）的一部分，而 super cycle 不会永远持续下去。所以如果你是被这个 super cycle 推着走而暂停思考，本质上你就是在追逐市场。这就是你在做的事。我会去问 Claude，你能从我们的银行把数据取过来吗？然后它就像是，哦可以啊，你登录一下并给我访问权限。

我当时的反应是：登录然后把权限给你？不，我不会给你访问权限。对我来说，这立刻就在根本上打破了整个论点。所以你要给它一台属于它自己的机器。当我想到 agent（智能体）时，我会把它们看作 digital knowledge workers（数字知识工作者）；而作为知识工作者，要做任何事情，你确实都需要一台电脑。

我的观点是，每个 agent 都至少需要一个 sandbox（沙箱），有时候还需要更多。

Claire Matturk，欢迎来到 MAD podcast。今天我的嘉宾是 Ivan Borozin，Daytona 的 CEO，也是 agent infrastructure（智能体基础设施）领域讨论度最高的 startup（初创公司）之一。如果你最近在每一次 AI agent 对话里都听到 sandbox 这个词，同时又在暗自纳闷它到底是什么意思、为什么突然变得这么重要，那么这一期就是为你准备的。我们会从第一性原理讲起：为什么一个 agent 归根结底需要一台电脑？也会一路深入到技术深水区：为什么 Daytona 必须放弃 Kubernetes，自己重写调度器，以及为什么全球 CPU 短缺可能会比很多人想象得更快到来。

Ivan 还拆解了在他看来完整的 agent stack（智能体技术栈）：models（模型）、sandboxes、tools（工具）、MCP、memory（记忆）、orchestration（编排），以及这些部分各自将走向何方。在这个过程中，Ivan 也分享了不少很有意思的 go-to-market（市场进入）和 distribution（分发）经验——这些都是他在 16 年打造 developer tool（开发者工具）startup 的过程中学到的。请欣赏这场与 Daytona 的 Ivan 的对话。嘿，Ivan，欢迎你来。

很高兴来到这里。

你曾说过，每个 agent 都需要属于它自己的电脑。解释这个想法，最简单的方式是什么？

嗯，当我想到 agent 时，我会把它们看作 digital knowledge workers，而作为知识工作者，要做任何事情——或者我应该说，要做任何复杂一点的事情——你都需要一台电脑。比如你和我可以通过一场对话完成一些事，但通常我们还是需要某种工具；在我们的世界里，这通常就是电脑，它能带来更高的生产力，也让我们能够真正把事情做成。所以我也是用同样的视角来看这件事。对我来说，agents 本质上就只是 digital knowledge workers。

很好。所以是在一台电脑上运行，而这整个概念就是 Sandbox。作为这场对话的开场，什么是 Sandbox？

当然。Sandbox 这个词最初其实来自“隔离”这个概念。也就是要确保有一个安全的地方，让这里说的 agent 能在里面运行、执行各种操作；但从另一面看，它本质上又是一台电脑，是一台完整的电脑，agent 可以在上面安装工具、访问 web、运行脚本、运行代码，总之做任何完成任务所需的事。所以最简短的回答是：sandbox 本质上就是我们所说的，面向 AI agents 的 composable computers（可组合计算机）。

对。所以从某种意义上说，整个 OpenClaw 和 Mac mini 的例子，是否可以作为一个很好的类比，来说明 sandbox 是什么样子——也就是把 Mac mini 看作 sandbox？

没错。所以我认为 OpenClaw Mac mini 这件事，确实帮助很多人理解了我们到底在做什么。就像是，“哦，现在我懂了。我懂了。”对吧？

所以它需要一台电脑。这里那个例子里，是一台 Mac Mini，来执行各种不同的事情。所以没错，这对提升认知度的帮助确实很大。

对。因为再展开讲一下，OpenClaw 作为一个 framework（框架）和 system（系统），是帮助 agent 在你的电脑上做各种事情的。基本上，如果它失控了，你会希望自己能够“杀掉”它；因此你可以直接拔掉 Mac mini，就像你也可以某种程度上终止一个 sandbox 一样。这个理解是不是——

算是吧。不过这里面有几件我自己会考虑的事。我的 OpenClaw 跑的其实不是一台实体的 Mac mini，而本质上是一个 sandbox，也就是一台虚拟的 Mac mini。我之所以没有——通常人们运行这类东西，不管是 Claude code 还是 OpenClaw，往往都是直接跑在自己的电脑上，因为这样它就能帮他们整理邮件、搜索他们手头的各种文档之类的。但这里存在一个很高的安全风险，因为有一次我们在做董事会会议演示时，我会问 Claude：“你能去把我们银行里的数据取过来吗？”

然后它就像是在说：“可以，你登录一下并给我访问权限。”我当时就想，登录并给你权限？不，我绝不会给你这个权限。对我来说，这从根本上就直接打破了整个设想。所以你应该给它一台属于它自己的机器。我个人是给了它一个独立的 Daytona account，还给了它一个自己的电话号码；之所以必须给它自己的电话号码，是因为它要通过 2FA（双重身份验证）才能登录银行——对这家银行来说，除了通过电话号码做 2FA 之外，没有别的方式。所以它必须像一名员工一样，具备所有这些东西，像一个 digital employee（数字员工）那样，才能去访问这些资源。这样一来，风险就变成：既然它有了自己的电脑，也有了自己的账户，而这些账户本身又有限制，那么它就只能查看我银行里的数据，不能动用我银行里的钱。唯一的例外是我们确实给了它一张信用卡，不过那张卡有比如每天 100 美元之类的额度限制。

所以到了那个阶段，如果它是在 sandbox 里运行，你真正需要担心的风险基本就只剩下：它会不会把这些数据拿走，然后泄露到别的地方？这个我们之后可以再谈，但本质上最坏会发生的情况也就是这个；而且正如你说的，如果有需要，你可以把整台机器直接干掉。

一台机器。而且这里有一个关于 stateful（有状态）与 stateless（无状态）的现象级概念，你能不能帮我们拆解一下？

所以，基本上当我们和别人聊我们正在构建的东西时，他们会说，哦，这不就是任何 hyperscalers（超大规模云服务商）里本来就有的吗？答案是否定的。之所以是否定，是因为它们原本被构建出来的目标——也就是部署 apps——本质上都是 stateless（无状态）的。比如说，随便拿一个你的网站也好，或者任何 web apps 都行，你并不希望它在运行过程中被动态改变。假设你是一家公司——我们就拿 eBay 来举例，因为他们就在这栋楼里，所以我先想到他们。如果你是 eBay 的一名工程师，你会想，哦，你有一个新的更新，比如一个按钮放到这里，或者这个功能改成那样，你希望这个状态是固定的，你不希望它在运行中被动态改掉，对吧？数据库可能会变，信息可能会变，但我们不希望 app 本身发生变化，对吧？正是基于这些前提，人们才构建了这些 hyperscalers；那就是你进入这个体系时所面对并在其上继续构建的底层架构。

我给人们的最简单类比是，假设你在造一辆卡车，对吧？你有一家卡车工厂。它的重量、发动机类型、底盘等等，都是为了缓慢但稳定且安全地运输某种货物而设计的，对吧？另一方面，你也可以有一辆跑车，它当然也有四个轮子，也有发动机之类的，但它是为完全不同的事情而造的。它是为了跑得非常快。

所以，底盘的构造方式、发动机的设计方式、重量平衡方式都完全不同。因此，这两者都能做很多事情，但它们在根本上不是同一种东西。而对于一家想同时构建这两类产品的公司来说，它们会是完全分开的平台。对吧？

明白。所以 sandbox（沙箱）本质上是一种新的 primitive（基础原语），这样说对吗？还是说 sandbox 其实有一段历史？sandbox 以前就存在吗？

所以我会主张这么说：有一个人本来可能算是推动了这件事的人，虽然他说是他做的，但也有人说是别人做的。总之，很早以前有一家叫 CodeSandbox 的公司，那时候我们还在和我们自己的公司 CodeAnywhere 竞争；它们都属于某种类似 replete 这个领域的东西——也就是这些基于云的 ID。之所以叫 CodeSandbox，我觉得大概是因为这个名字听起来挺可爱，就像一个装代码的盒子，你的 ID 就住在里面。而他们其实算是最早的一批。那个团队当时就已经在用 micro VMs（微型虚拟机），做 snapshotting（快照）、forking（分叉）以及我们今天仍然在使用的这些事情。所以这大概就是它的来源之一，虽然那可能已经是十年前的事了，但当时这种用法，或者说它能给人类开发者带来的价值，还没有真正显现出来。还有一整篇文章在谈所谓 local hosts（本地主机）的终结，而人们已经讨论这件事很多年了——我自己都谈了二十年。基本上，开发者会说，你想拿走我的 local hosts，那得从我冰冷的尸体上跨过去。

但现在 agents（智能体）已经出现了，local hosts 实际上已经不再是——首先，出于很多原因，你并不想要那种东西。所以我们终于走到这一步了。于是，最初围绕 sandboxes 的那套技术和 thesis（论点）现在看起来终于开始开花结果了。而且

围绕 sandboxes 的最大加速器，其实就是 agents（智能体），对吧？

没错，就是这个问题。说到 agent（智能体），首先，如果你真的想在自己的电脑上运行一个 agent，当然可以，随你。尽管去做。但这里会有一堆问题。

其中一个是，比如说在你的 laptop 上。现在 Twitter 上有这么个现象，大家都把自己的 laptop 一直开着。对。人们就是——

那、那是什么？对，对。我看到你发推说那个了——

哦，那是因为我一直都把我的 laptop 开着。这就是我的一种风格，跟那个没关系。不过我这么做已经很久了。但有些人这么做，是因为他们想让 clot 或者 open clot 跑完。对。

因为如果你把它合上，它就——

对。

对，你就把它 terminate（终止）了。对。要么就是 pause（暂停）或者 stop（停止）之类的。所以问题在于，只要你的 laptop 还是这种状态，它就不具备持续、不间断工作的能力。

这是一方面。另一方面是你没法做 concurrency（并发）。你最多只能做到你的 laptop 所拥有的那点 compute（算力）范围内的多任务，而这通常会相当有限。所以你可能会想一次性拉起 10 个、20 个、50 个、100 个，甚至 100,000 个，不管那个数字是多少。而这就非常困难。

所以理想情况下，你其实真的会想把它放到某个远程的地方去运行。这样你可以在 laptop 上开始，在 phone 上继续，而且做事的还是同一台 computer、同一个 agent，对吧？所以这其实体现的是一种观念转变：我们现在已经认定，它不再运行在我们的 local host 上也完全没问题；但反过来说，对那个 agent 而言，那依然是它的 local host，所以对它来说，那仍然是一台 computer，就像 laptop 对我们一样。

所有 agent 都需要一个 sandbox 吗，还是说那只是某一类特定 agent 才需要的东西？

我的观点是，每个 agent 至少都会在某些时候需要一个 sandbox，有时甚至不止一个，我们可以展开讲。当然，也有一些场景并不需要。我大体上会把 agent 类比为人类：同样地，我们不借助电脑也能完成一些有成效的工作。所以确实存在这样一种情况——这有点像最早那类 chatbot，基本上你只是和一个 agent 对话，它进行 inference（推理），也就是它单纯思考，然后给你提供价值。所以我不知道，很多人会把它用于情感支持之类的用途。

在大多数这类情况下，其实不需要电脑。它通过和你来回交流已经积累了足够多的数据，于是就能在某种程度上理解你并给出反馈，但这只是较小的一部分。如果我们去看生产力提升主要发生在哪些最大的 verticals（垂直领域）里，比如 healthcare、financial services 之类，其中大多数工作都是通过电脑完成的。所以，如果你希望 agent 去做所有这些事情，那么 agent 就需要这些电脑来执行。

所以，如果你要进行 tool calls（工具调用）、coding，或者任何这类操作，那你就需要一个 sandbox；如果你只是聊天的话——

那大概率就不需要，对。所以比如即便是聊天，我们也许能把事情谈成；但如果你在聊天，而它需要搜索网页，那它仍然得打开一个 browser，或者它必须使用像 parallel 或 exa 之类的东西去获取那些内容——那依然属于一次 tool call。所以这取决于具体 use case。不过，我们所处的这个世界里有一件很有意思的事。先退一步说，第一，我坚信随着时间推移，所有工具最终都会变成 headless（无头）的。它们会在 sandbox 里面还是外面，那是另一回事；但它们都会变成那样，而且对 agent 来说，那是最高效的工作方式。可是绝大多数知识工作，仍然被锁在 Windows 里的 legacy apps（遗留应用）中，范围之广是压倒性的，真的是绝大多数。所以，如果你今天想让一个 agent 端到端地完成一项工作，你实际上就必须给它一台电脑。举个例子，还是那个董事会报告：比如“你能把这个报告拉出来吗？”我们的银行有一个 API，可以把它拉出来，但 API 里只有 spend（支出）数据，没有 incoming revenue（收入）数据，它就是没有暴露出来；或者通过 MCP tool，其实也没有暴露出来。然后 agent 就会说：“哦，我拿不到。”我就说，兄弟，登录进去把它下载下来就行。然后它就去做了，你能看到它打开 browser，往下点之类的。不管怎么说，我们的其他任何数据源也一样：如果它能通过 headless 方式拉取，它就会走 headless；如果不能，它就会登录进去那样操作。所以，如果我们今天想赋予它们能力并获得价值，我们就必须让它们能使用这些工具。

你前几天发过一条很棒的 tweet，里面谈到了作为 agent sandbox 提供方，你实际看到的那些 use cases。你愿意讲讲这个吗？你当时提到了 CodeCommon execution、computer use、browser use，还有 RL environment infra。你想展开说说吗？

当然。基本上，我觉得自从那条 tweet 之后，我已经把它梳理得更清楚了。现在我们有两大类 use cases，或者说两类客户，他们会在不同的 use cases 中使用 Daytona。一类是研究者这一侧，也就是 RL、evals、benchmarks 这些。另一类则是我们所谓的 background agents，或者 long running agents。

所以，当你去理解 background agents 或 long running agents 时，最常见的那类，是以人类作为最终消费者的场景。人会和一个——我们姑且称之为 app layer service（应用层服务）——进行交互，而那个服务里面有一个 agent，然后这个 agent 会去调用 sandbox。所以，像 Harvey 或 Perplexity 之类的，或者 lovable 这一类，都可以看作这种后台型、长时运行型 agent。它们既可以是某种意义上的 headless，也就是 code 和 command execution；也可以是 computer / browser use。这取决于它们需要完成什么。同样的情况也适用于研究者那一侧：像 RL、evals 之类，你可以把 RL 和 evals 用在 coding 上，而那基本就是纯 headless——里面就是 commands 和 command execution；或者你也可以训练它去做现实世界里的事情，那它就确实需要启动一个 Windows、mac 或 Linux 这类 desktop，或者一个 browser，来把整个流程走完。

编码命令执行和在浏览器里使用 computer，本质上像是 agent 的两种工作方式；而要做这两种不同的事，对 sandbox 的消耗方式也不一样。

所以，这算是一个很好的、某种意义上的 sandbox 入门介绍，帮助我们理解 sandbox 在这个新兴 agent stack 整体图景里处在什么位置——我觉得现在大家都在同时摸索这件事。所以这里面有不同的组件，有 file system，有 orchestration（编排），还有别的部分——这些不同的拼图到底是什么？我会试着

去理解这一切。对我来说，其实很有意思的一点是——这个我们后面也会再谈——很多东西今天在现实里本来就已经存在了，所以人们有点把这件事想得太复杂了。我不是说不会出现新的产品、方案和技术去解决它，但这并不是一种全新的、从根本上不同的工作方式。所以当你去看 agent stack 本身时，会觉得：好，首先你有 models，而 models 本质上就是大脑，差不多相当于人的大脑。你告诉它一件事，它会回应、理解，等等。然后在这之下，就是：它能用哪些 tools 来把事情做成？

对。所以这可以是任何东西，比如任何 MCP 或 tool calls 能做的事。它也可以是 sandbox、computer，或者别的什么；就像我们人类也有一整套会使用的工具，从锤子到电脑，以及围绕这些的一切。对吧？

所有这些也都存在。然后还有 memory（记忆）。一个 agent 能不能记住这些事情，就像你会不会记住这些已有的信息？至于那些谈 agent orchestration（agent 编排）的人，这其实就像管理。你管理人，我也管理人。

管理 agents 和管理 humans 是类似的，并没有本质区别。现在的问题只是：你会用什么工具来管理它们？你会用同样的方式去管理吗，比如发一条 Slack 消息，或者用 linear，或者别的什么？这个我们还得再看，也许会出现一个全新的 app，我们之后会弄清楚；但大体上就是这么回事。当然还有 observability（可观测性）——你能不能看到你的 teammate 或 colleague 做了什么，并验证那项工作是否做得好，对吧？所以这是我在一个比较高层次上对这件事的理解。然后，你还可以继续拆分，去看人们正在为此构建的不同类型的解决方案。

对，我们就展开讲讲这些吧。

我在想的一些事情是，这里面也有一些问题是相对更已解决的，另一些则没那么解决。比如 models，我不是说它们已经完全稳固了、不会继续进步；未来可能还会有不同版本的 models。但很明显，那里确实有某种“大脑”存在，我们也已经有处在前沿的领导者，也有人在尝试做不同的事情，这部分大体上已经是既成事实了。至于 tooling，我不知道我会不会花太多时间，因为我们现在其实一直在谈的就是这些——sandbox、computer、MCP tools——这类东西已经有很多了。

目前还没有很好解决的一件事，首先就是 memory（记忆）本身。也就是说，怎么把这件事做好？现在最好的方案基本上就是把内容都丢进 MD 文件里，然后某种程度上让系统能访问这些内容，再对它们做压缩，以及思考要如何取回这些内容。我们前几天聊过这件事，就是那本 Why We Sleep，对吧？而在 Why We Sleep 这本书里，实际上有很多内容都和你如何做 data retention（数据保留）之类的事情有关，而这某种程度上正是我们想在 agent（智能体）这一层去解决的问题。

所以，说到 memory，在我看来真正相当有意思的其实是 model（模型）的 learning（学习）能力。有一点我之前没有真正理解并内化，就是 models 其实现在并不会学习。你使用一个 model，如果你把 memory 问题解决了，它就会记住一些事情，因此它拥有这些事情的 context（上下文），于是它可以说“哦，这是相关 context”，然后因为有这些 context，它就能给出更好的答案；但它实际上并不会在工作过程中真正学会昨天做过的那件事。对吧？所以，到底是谁在解决这个问题，或者我们该怎么解决它呢？

这是否需要某种持续性的 RL（强化学习）式 post-training（后训练）来实现？还是说，我们需要从根本上改变 model，让 models 能做到这一点？我不知道，但这绝对是今天阻碍进展的一个问题，而且我们并不完全清楚该怎么走到那一步，因为和一个实际上不会变得更聪明的对象一起工作，感觉是有点奇怪的，对吧？比如你拿到一个新 model，会觉得“哦，这是个新的”，然后你想把它配置起来；可你让它做同一件事五次，它第六次还是可能搞砸，真的就是第六次也会出错，对吧？所以实际上几乎每一次都是这样。你当然可以尝试把 prompt（提示词）写得更好，也可以给它更多 context，让它别犯错，但它并不会真正学习。我觉得这会是一个非常值得观察的话题，看它之后到底会如何发展。

对。从你的视角来看，memory 是那种 markdown 文件之一，还是说更像是这些文件的某种组合，而不是 database（数据库）？感觉 markdown 文件极其优雅也极其简单，但不知怎么又让人觉得，它没有 database 所能提供的那种稳健性。

我的意思是，不一定从个人角度讲——不过如果从个人角度说，我可能也会改口——但我也倾向于同意你的看法：对于眼前这个问题来说，markdown 看起来确实有点过于简单了，尤其是再考虑到 compression（压缩），以及你如何从里面取到所有这些内容。所以，作为一家为这类事情提供 infrastructure（基础设施）的公司，我们努力去做的是：确保我们能够以一种非常简单的方式，把 agent 访问这些内容并向其中添加内容的能力暴露出来；但至于这个问题本身如何被彻底解决，那不属于我们的——姑且这么说——mandate（职责范围）。

那么在整个 agent harness 这种体系里——我想可以这么说——你刚才描述的那些内容，基本都属于当前 harness 这个概念的范畴。从长期来看，sandboxes（沙箱）会处在什么位置？你觉得这里面很多能力最终都会被构建进 sandbox 里吗，还是说 sandbox 仍然只是整个系统的 execution layer（执行层）？

有两点。所以如果你去看，会有像 sandbox 本身这样的部分。再说一遍，我在这次对话里已经重复很多次了，但如果我们拿 Goldman 里一个普通员工来举例，对吧？你有这个 worker，也就是这个人，在这个语境下我们把它称作 model。你还有他登录进去使用的那台 computer（电脑）。

而 harness 则是一整套塑造这个 model 如何与外界交互、哪些事情能做哪些事情不能做的方式，所以某种意义上，它有点像是“手”，如果要更深入地打这个比方的话。但本质上，Sandbox 的确是在支撑这一切。所以如果你把它想成一台 computer，我还是继续拿 Goldman 来举例吧。虽然我从没在 Goldman 工作过，但这只是我的一种推测。我在一家更大的公司工作过。

所以我的假设是，当你登录那台电脑时，那台电脑里会有很多软件来记录你的操作、限制你的操作、确保你不会泄露数据，并处理这类事情。再次说明，我对 Goldman 没有事先了解，这只是基于这类情况的推测。所以，这些正是我们作为 sandbox（沙箱）提供方几乎肯定会纳入其中的内容。但那个 harness 仍然有它自己的作用，也就是它会引导 model（模型），比如“哦，我现在知道该如何与这台机器交互了”“哦，我知道如何调用某个 tool（工具）了”“哦，我知道如何使用 memory（记忆）了，也知道如何与模型配合工作了”，所以这里面是有价值的。因此我们不会去接管 harness。这基本上是我们很确定永远不会做的事，但我们在 sandbox 里做的一些事情，确实会帮助或支撑整个系统。

很好。我们聊过模型了。那么像那些大型 AI frontier labs（前沿实验室）这样的 model provider（模型提供方），在这个整体图景里处于什么位置？OpenAI 最近发布了一个 agent SDK（agent 软件开发工具包）的公告，那是什么？

对，我的意思是，他们正在大力推进这个领域，像 Claude code 和他们的 agent SDK 一直都是其中的一部分，所以这对他们来说，本质上是要追赶那个市场细分领域。这其中有两类——

东西，对吧：有 OpenAI Agent SDK，也有 Cloud managed agents，它们是不一样的，

对，它们——

不一样。给我们展开讲讲。

Anthropic managed agents 是一种 managed service（托管服务），本质上就是把 model、harness 和 sandbox 全都打包成一个整体。也就是说，整套 stack（技术栈）都会作为服务由对方替你管理。这是一种情况。而如果你只有一个 agent SDK，你就可以使用它，并把它运行在任何 sandbox provider 的环境里、你自己的环境里，或者任何你想运行它的机器上，它也可以连接到相应系统；具体取决于许可或其他条件，你可能会把它连接到提供该 harness 的 model provider，也可能可以在这些东西之间进行替换。所以基本上，一种只是 harness，另一种则是把 model、harness 和 sandbox 全部包含在一起。

好的。而且，我记得 Daytona 是 OpenAI 的 Agents SDK 的合作伙伴之一，对吧？比如说，作为 sandbox provider 之一。没错。这是那个最初 framework（框架）的一部分。

对。好。这算是围绕 agent stack 的整体图景。我们马上会从技术角度更深入地讲 sandboxes 以及它是如何工作的。但先稍微岔开一下，聊聊你的经历和 Daytona 的故事。

所以这不是你第一次创业。讲讲你之前做的那个项目吧。你刚才也提到了一些，那个项目有点有点像 Replit。

对。我们基本上是在 2009 年进入 Cloud IDE 这个领域的，我和联合创始人都是如此。对经历过那个年代的人来说，2009 年几乎没有 Docker，没有 Kubernetes，也没有 VS Code，所以我们不得不把整套 stack 全部自己搭出来。这是我们后来学会去做的事情，也是我们今天仍然在应用的能力。所以我们其实是非常非常非常早期的。我说是我们开启了这个领域，是因为在我们之前启动的那家公司是 Heroku，后来变成了 Heroku，并且干掉了 ID，这件事其实我们可能也应该更早做。所以从某种意义上说，我们是唯一一个把这件事做起来并且做完整的。再往后，像 CodeSandbox、Replit，还有其他一些后来加入的产品，以及 StackBlitz，也就是现在的 Bolt，等等。

后来 Replit 也变了，Bolt 也转向了它们各自的其他方向，而 Replit 现在做得非常好。我们在决定做下一家公司时，选择了一个完全不同的方向。我们已经学到了很多关于如何构建整套 stack 的经验，但当我们启动 Daytona v1——它和今天的形态不一样——时，我们决定不去做 app layer，而是只做基础设施。这大概也是受了 Heroku 的启发，因为 Heroku 的确是往那个方向走的：我们已经学会了底层 orchestration 层面的这些能力，那看起来非常非常有价值，所以我们就沿着这个方向推进，这也就是我们最初启动它的方式。

你发过一条推文，说“我的第一家创业公司教会了我，在 Daytona 里哪些事情绝对不要做”，比如向开发者销售、不做 on prem 方案之类的，展开讲讲这些——

我们确实学到了很多东西。其中一个是 timing。我以前从来没有真正理解过市场 timing。要选对时机非常难，但如果你处在正确的时间点上，你会很快知道。理想情况下，你会希望自己比那个时点稍微早一点，但那非常非常难。不过你肯定不希望完全错位。我们当时大概错了二十年，或者说十五年，所以在这点上显然是错得很离谱。

另一件事是，我当时并不知道 user 和 customer 的区别。所以现在 Daytona 的销售模式 100% 是 PLG motion。CodeAnywhere 这个产品当时也是 PLG motion，但 CodeAnywhere 没有企业 use case 价值，它提供的全是单个开发者层面的价值，而单个开发者并不愿意为这类东西付费。相比之下，我们现在这个产品虽然也是 PLG motion，它也能给单个开发者带来价值，但这个单个开发者很可能是在一家公司内部工作，所以他们会用公司的卡来付费，这就非常非常非常不一样了。不过创业一开始的时候，你并不会知道这些。所以这些绝对是我们在创建这家公司时真正理解到的事情。还有一个差异，虽然我们没展开细说，就是 Daytona V1 是一个管理型的基础设施产品，面向超大型企业里的人类工程师，是一种 enterprise play；而 Daytona v2，也就是 sandbox，则可以说是一种 neo cloud，一种新的云。

虽然 neo cloud 通常是用来指 GPU cloud 的，但我们确实理解到这里面存在企业级机会。所以像 on prem、multi cloud、不同的 observability 管理方式、audit logs，以及所有这些企业所需要的能力，我们要么已经预先内建进去了，要么至少已经明白这些能力将来一定会需要。因此我们从一开始就是按照这个方向来准备产品的。

很好。而且你在 distribution（分发、渠道拓展）以及打造品牌、吸引 developers（开发者）这方面也非常厉害，这很有意思，对吧？因为这正是很多高度技术型创业项目的典型问题之一。团队成员往往在产品和技术上非常出色、思考也很深入，但 distribution 往往成了事后才考虑的事。你是怎么变得擅长这件事的？对于技术出身的创业者，你能分享哪些经验？

我的意思是，这一切其实都和……我大概一开始在这些方面都很烂，非常非常烂，我都不知道该怎么形容。我们可以从很多角度来讲我们是怎么做到的。其中一点是，我觉得我非常理解大规模的人群，也就是市场想要什么、需要什么、会有什么感受。做到这一点之后，就像是——我一开始并不是天生就懂这个，但你会慢慢学会自己其实在理解 humans（人）这件事上越来越有感觉。对单个个体其实还好，真正更难的是更大规模的人群，也就是聚合起来的人群。

对，aggregate humans（聚合人群）这方面我理解得要好得多。这是一点。另一点是，我小时候特别害羞，很 geeky（极客），之类的。而且我非常怯场，严重得不行。

真的很严重。比如我第一次为自己的 startup（创业项目）做路演时，会紧张得要命。上台前五分钟，我可能要跑十次洗手间，就是那种被这些事情压得喘不过气的感觉。后来有件几乎算是偶然发生的事：我们第一个项目 CodeAnywhere 去参加了世界各地很多 conference（大会）之类的活动做 pitch（路演），这件事很有意思。后来有一次在 after party（会后派对）上，我和其中一个 conference 的创始人聊了起来，当时大概都有点喝多了。他说，哦，你想不想在 Croatia 办一个？我那时正住在那里。我当时就说，fuck，当然要。

那就干吧。于是我就去把这个 conference 搭起来了，地点在 Croatia。有 950 个人来了，这在当时对我们来说已经是非常大的规模了。而我原本请的一位 emcee（主持人）在最后一刻放了鸽子，所以现场没有主持人。

而我又有 stage fright（怯场）。

你说得对。我的意思是，我

只能硬着头皮上了。于是我真的就连续两天当了 emcee，你就这么直接把这件事撞开了。就像是，你只能去做，必须去做。我想说的是，这件事和 go-to-market（市场进入）本身其实不完全一样，但它又是有承接关系的：当我不再有这种 stage fright 之后，你就会开始教学，开始理解什么样的互动会让人兴奋，什么样的不会，什么东西能把人吸引过来，诸如此类。不过这也带来一个问题，因为当时我们说要办一个 conference，其实我们自己都不真正明白 conference 是什么。

所以问题就像是：你要怎么拆解“conference（大会）”到底是什么？好，conference 首先归根结底是一种娱乐形式。于是你会有“show（演出/呈现）”，而这个 show 就是 speakers（演讲者）。那你怎么请到 speakers？然后，为了让 speakers 愿意来，你还得把 audience（观众/参会者）卖给他们。那 audience 是谁？

谁会来？你怎么把他们带来？接着，总得有人为这一切买单。audience 的确会买 tickets（门票），但绝大多数收入其实来自 sponsorships（赞助）。那你又要怎么把这件事卖给 sponsors（赞助商）？

所以你会把这些事情拆开来看，然后开始理解所有这些不同参与方的 incentives（激励），再把它们重新拼起来。我们的 go-to-market motion（市场推进方式）就是这样形成的；我们做 conferences（大会）差不多做了十年。所以某种程度上，你的 iteration cycle（迭代周期）是一年一次；后来我们开始一年办两次，再后来一年办三次，然后每一场 conference 都变得更好，因为迭代周期快得多，feedback loop（反馈回路）也快得多。再后来我们决定做 Daytona 的时候，我们整个 go-to-market strategy（市场策略）最初其实都是围绕 in real life events（线下活动）展开的。所以我们做了 dinners、meetups、drinkups、hackathons，但它们本质上都是 conference 的简化版。