Daytona估值破10亿美元：给每个AI Agent一台云电脑

从开发环境到Agent云：Daytona的转身

Agent云初创公司Daytona近日完成新一轮融资，估值达到10亿美元，跻身独角兽行列。本轮融资由FirstMark领投，跟投方包括一批重量级天使投资人——据公司披露，Stripe、Perplexity、Datadog、Mercor等知名科技公司的创始人都在其天使名单之中。

Daytona的定位可以用一句话概括：为每个AI Agent提供一台独立的云计算机。这并不是简单的虚拟机租赁，而是针对Agent工作负载重新设计的运行环境，目标是让Agent在云端拥有持久化、可隔离的执行空间，而不是寄生在某个聊天窗口或临时沙箱里。

为什么Agent需要“自己的电脑”

当前大多数Agent的运行方式相当简陋：调用API、在受限的沙箱中执行代码、会话结束状态即丢失。这种模式在演示阶段够用，一旦进入真实业务流程就暴露出明显短板——Agent无法保留文件系统状态、无法长期运行后台任务、也难以在多个工具之间维持一致的运行环境。

Daytona的思路是把开发者的本地开发体验搬到云端，再交给Agent使用。每个Agent获得一个隔离的计算机实例，可以安装依赖、运行进程、读写文件，并且在会话之间保持状态。这种“Agent原生”的基础设施，与传统的容器编排或函数计算在抽象层级上有本质区别：后者面向无状态服务，前者面向有状态、长时运行的智能体。

状态持久化与有状态计算：传统函数计算（如AWS Lambda）和多数代码沙箱遵循“无状态”设计——每次调用启动全新实例，执行完毕即销毁，状态不跨调用保留。这种模式适合短时、幂等的任务，但对Agent而言却构成瓶颈：Agent往往需要多轮推理、调用工具、读写文件，并在数小时甚至数天内维持上下文。状态持久化意味着文件系统、内存中的进程、已安装的依赖和会话历史都能在Agent“休眠”后恢复，从而支持长时任务和中断续跑。Daytona所强调的“独立云计算机”本质上是将开发者本地工作站的持久性抽象搬到云端，每个Agent拥有专属的根文件系统和进程空间，而非共享的临时沙箱。这要求底层具备快速快照、恢复和隔离能力，也直接推高了单位成本。

明星天使阵容透露的信号

Daytona本轮的天使名单值得单独分析。Stripe创始人的参与指向支付与Agent经济的结合场景；Perplexity创始人的加入则暗示搜索型Agent对持久运行环境的需求；Datadog创始人的背书与可观测性相关——当Agent在云电脑中运行时，监控、日志与调试能力将成为刚需；Mercor作为AI招聘与评估平台，其创始人押注Daytona，可能意味着Agent能力评估需要标准化的运行环境。

这批投资人的共同点是：他们都在构建与Agent直接相关的基础设施或应用层产品，对Agent运行时的痛点有第一手体感。FirstMark作为领投方，此前在开发者工具和数据基础设施领域有长期布局，此次押注延续了其一贯的投资逻辑。

竞争格局与待解问题

Agent云基础设施赛道正在升温。一方面，公有云厂商在推出面向Agent的沙箱服务；另一方面，E2B、Modal等初创公司也在争夺同一批开发者。Daytona的差异化在于“完整计算机”的抽象，而非单一的代码执行沙箱。

不过，10亿美元估值对一个尚处早期阶段的公司而言意味着高预期。需要观察的问题包括：Agent云电脑的单位经济模型能否跑通——为每个Agent维持一台运行中的计算机，成本远高于按需启动的沙箱；开发者是否会为“状态持久化”支付溢价；以及当模型厂商自身开始提供Agent运行时，独立基础设施公司是否会被挤压。

目前Daytona尚未披露具体客户数量和营收数据。明星天使阵容能带来可信度，但Agent基础设施的终局取决于开发者是否真的把生产环境的Agent跑在上面。

单位经济模型（Unit Economics）：指单个客户或单个最小服务单元（此处可理解为“每台Agent云计算机”）的收入与成本结构。对Daytona而言，为每个Agent维持一台常驻计算机意味着持续消耗CPU、内存和存储资源，即使Agent空闲时也可能产生费用；而传统按需沙箱仅在代码执行时计费，空闲成本趋近于零。因此，Daytona需要证明其定价能够覆盖常驻资源的成本，并让开发者愿意为“状态持久化”和“长时运行”支付溢价。关键变量包括资源超卖比例、休眠/唤醒机制的效率以及Agent实际活跃时长占比。若单位经济模型无法跑通，高估值将难以支撑。

E2B与Modal的定位差异：E2B提供面向AI Agent的代码执行沙箱，主打安全隔离和快速启动，开发者可通过API在云端运行AI生成的代码；Modal则侧重无服务器GPU计算与容器化工作流，适合模型推理和批处理任务。两者与Daytona的核心区别在于抽象层级：E2B和Modal更接近“按需执行的沙箱或计算资源”，而Daytona强调“完整计算机”的持久化体验。这一差异决定了各自的目标场景——E2B适合短时、高频的代码解释执行，Modal适合弹性GPU负载，Daytona则瞄准需要长期维护文件系统状态和后台进程的Agent。竞争的关键在于开发者是否愿意为“完整计算机”的便利性承担更高成本。