Restate A 轮融资：以 2000 万美元押注反对数据库支撑的持久执行

Restate 通过一轮 2000 万美元的 A 轮融资主张：AI 智能体需要持久执行能力，但不必背负传统工作流技术栈的沉重负担。Restate 的 A 轮融资由 Singular 领投，Redpoint Ventures 和 Capital One Ventures 参投。这让这家总部位于柏林的初创公司获得更多资源，以挑战这一领域规模大得多的现有龙头 Temporal。

这笔融资值得关注，因为 Restate 并非只是在既有工作流产品中加入一项智能体功能。其创始团队围绕一个目标构建了存储、复制、共识、故障转移和执行协调能力：让应用程序代码能从中断中恢复，而不依赖独立的数据库或消息代理。

如今，这种方法正面临 AI 开发者无法忽视的问题。智能体会反复调用模型、操作外部工具、等待审批，并沿着不确定的路径分支执行。若在流程接近尾声时发生崩溃，已经完成的工作可能被浪费，或重复执行本应只发生一次的操作。

Temporal 已证明，持久执行能够成为一个重要的基础设施品类。在 Restate 宣布本轮融资前不久，Temporal 以 125.5 亿美元估值融资 5.5 亿美元。Restate 现在必须证明，规模更小、专门化的运行时能够为高频智能体工作负载提供实质上更优的模式。

Restate A 轮融资支持更广泛的运行时押注

Restate 的 A 轮融资旨在推动持久性从少数工作流进入后端应用程序的常规执行路径。

Restate 于 2026 年 9 月 30 日宣布本轮融资。其融资公告将持久执行描述为一种通用后端构建模块，而非仅供复杂工作流使用的工具。

持久执行意味着运行时会记录程序已完成的步骤和结果。在发生崩溃、部署或网络故障后，程序可以恢复执行，而无需重新开始每一项已成功完成的操作。

这种行为对普通的支付、资源配置和数据处理系统同样重要。当软件能够自主选择工具、联系服务并等待人工决策时，其重要性则更为迫切。

一个智能体可能先制定计划、查询多个数据库、调用模型、修改文件，然后请求批准。每个步骤都会增加一个超时或进程故障可能中断执行的位置。

基本的重试逻辑无法完全解决这个问题。重试可能会重复一次购买、通知、数据库变更或其他外部副作用。开发者因此需要幂等性控制，以防重复请求产生第二次结果。

Restate 会在执行日志中记录进度。恢复期间，已完成的操作可以根据其存储结果重放，而未完成的工作则会再次运行。该运行时还协调计时器、状态、信号、队列以及服务间通信。

该公司于 2022 年由 Stephan Ewen 和其他拥有 Apache Flink 构建经验的工程师创立。Flink 通过统一的编程模型提供了有状态流处理能力。Restate 则将类似的雄心应用于异步应用程序逻辑。

AI 并非最初的产品重点。Ewen 告诉 TechCrunch，该运行时最初并非为智能体打造。智能体工作负载后来恰好暴露了该公司所瞄准的可靠性问题。

据 Ewen 称，Restate 最近签下了数份金额达六位数和七位数的客户合同。这些数据由公司自行披露，无法说明总收入、留存率或客户集中度。

不过，这些合同释放出的信号强于实验性集成。它们表明，一些组织正在将智能体可靠性视为生产基础设施，而非开发者便利功能。

Restate 表示，其可服务市场也不止于智能体。控制平面、金融流程、事件驱动服务和 API 编排都包含必须经受中断的工作。

因此，这笔融资支持两项相互关联的主张。AI 智能体创造了即时需求来源，而持久执行最终可以成为标准的后端基础能力。

第二项主张更难成立。基础设施团队很少仅因一种新抽象看起来更简洁，就替换数据库、队列和编排系统。Restate 必须展现出足以证明架构变革合理性的优势。

公司还需要在不同部署、编程语言和云环境中支持严苛的运行需求。当恢复语义在真实生产条件下失效时，可靠性基础设施几乎没有容错余地。

本轮融资为 Restate 赢得了扩展系统并证明这些保障的时间。但它并未解决开发者是否希望将持久性嵌入整个应用程序这一问题。

为什么 AI 智能体提高了丢失进度的代价

AI 智能体让执行历史成为有价值的状态，因为它们的执行路径更长、更不可预测，且重复执行的成本更高。

传统的请求-响应软件通常在数秒内完成。如果一个无状态请求失败，应用程序可以拒绝它，或重试一项范围有限的操作。

一个智能体可能持续运行数小时。它可以调用多个模型、使用外部 API、运行代码、创建子智能体、暂停以等待反馈，并修改其计划。

最终输出取决于通向该结果的具体历史。由于模型响应具有概率性，重复同一提示并不能保证做出相同的决策。

即使周围的计算资源消失，持久运行时仍能保留操作进度。它不能让智能体的推理变得正确，但可以防止基础设施故障抹去已完成的工作。

以编辑代码仓库的编程智能体为例。它可能检查文件、启动沙箱、运行测试、请求批准并推送变更。重新启动整个序列可能产生不同的补丁，或重复执行外部操作。

细粒度检查点可以减少处于风险中的工作量。然而，检查点也会带来开销。每项被记录的操作都可能涉及序列化、网络通信、复制和持久存储。

这正是 Restate 持久执行提出其核心技术承诺的地方。该公司表示，其运行时能够记录单个智能体步骤，同时仅增加毫秒级延迟。

Restate 的 Replit 案例研究提供了一个具体示例。Replit Agent 可以跨多个轮次工作，并在用户引导、暂停或取消时执行数千项操作。

根据 Restate 发布的 Replit 部署案例，Replit 最初使用 Temporal，之后将其智能体编排迁移至 Restate。Replit 的总裁兼 AI 负责人表示，公司希望获得一个更快、且开发者乐于使用的运行时。

Restate 表示，Replit 对新架构进行了约六周测试。随后，该公司先切换一小部分流量，并在接下来的两到三周内逐步扩大部署范围。

迁移后，一次推广活动的峰值据称接近每个 Restate 单元每秒 25,000 次持久操作。这一结果来自供应商的客户案例研究，而非独立基准测试。

这一用例仍说明了智能体为何改变基础设施方程。Replit 的工作负载包含数千项小型操作，而不只是少数几个大型工作流阶段。

如果每一步都需要通过队列进行远程调度，并交由独立工作线程执行，协调延迟便会不断累积。如果步骤保留在智能体进程内，运行时就必须在不失去一致性的情况下保存其进度。

Restate 试图占据这一中间地带。它将应用程序代码保留在普通服务中，同时通过其运行时记录操作日志。

该公司还提供 Virtual Objects，用于表示由键寻址的持久化有状态实体。因此，一个智能体会话可以保留状态，并串行化相互冲突的变更，而无需开发者构建独立的锁定系统。

Durable Coroutines 允许并发分支在一个进程内运行，同时记录它们的进度。对于智能体而言，这些分支可能包括并行搜索、工具调用或子智能体任务。

人工审批带来了另一项要求。进程不应在等待响应数小时或数天时持续消耗计算资源。Restate 可以挂起执行，并在持久信号到达后恢复执行。

这些能力并不能取代智能体框架。开发者仍需选择模型、工具、提示、权限、评估方法和用户控制机制。

持久性则位于这些选择之下。当进程、机器或网络发生故障时，它记录已经发生的事情，并协调下一步应发生什么。

压力正落在每一家为关键工作销售智能体平台的供应商身上。聊天演示可以容忍一次失败的会话，但生产环境中的编程、安全、金融或运营智能体不能。

Restate 自建存储，而不是从数据库租用它

Restate 的决定性押注是，只有当存储与执行协调共享一套专用架构时，持久执行才能变得更轻量。

许多基础设施产品将工作流状态持久化到外部数据库中。这种方法受益于成熟的存储系统、熟悉的运维实践和经过充分验证的复制能力。

但它也可能增加组件和网络边界。执行引擎必须将其内部状态转换为数据库事务，同时协调队列、工作线程、计时器和恢复机制。

Restate 选择了不同的设计。其服务器以单个二进制文件运行，不需要独立的数据库、缓存或消息代理。

这一描述听上去可能比其底层工程更简单。Restate 并未消除存储，而是将专门的存储功能直接整合进运行时。

新事件会进入一个名为 Bifrost 的嵌入式复制日志。运行时将这些事件转换为状态索引，并使用嵌入式键值数据库 RocksDB 在本地存储。

Restate 会定期将这些索引的快照复制到对象存储。节点保留近期的复制数据，而较旧状态则可以主要存放在成本较低的对象存储中。

该公司的架构说明将此描述为延迟、基础设施成本和本地磁盘使用量之间的平衡。没有任何配置能同时最大化这三项指标。

复制意味着多个节点会保留恢复近期进度所需的信息。共识决定集群接受哪些事件，而故障转移则让另一个节点能在发生故障后继续执行。

嵌入这些机制让 Restate 能围绕执行日志进行优化，而不是围绕通用数据库查询进行优化。该公司表示，之所以构建自己的复制日志，是因为现有选项无法提供所需的延迟和重新配置特性。

这是 Restate 轻量化主张背后的核心机制。一个智能体步骤可以直接流向运行时，进入其日志，并在完成复制后获得确认。

智能体进程不必将每一项小操作都调度为独立的远程活动。在 Restate 使相关进度具备持久性时，它可以继续运行。

Restate 也采用面向推送的调用模型。运行时通过 HTTP 调用已部署函数，而不是要求专用 worker 轮询任务队列。

这种模型适用于 serverless 环境和普通容器。但它也带来了棘手的流量控制问题，因为运行时发送工作的速度可能快于服务接收工作的速度。

Restate 表示，它会在 dispatcher 中处理这一问题。其双向流协议既支持短时操作，也支持长时间挂起的函数。

如果 Restate 的说法能在不同工作负载中成立，其优势在于提供细粒度持久化，而无需将 agent 工作的每一行都视为重量级工作流活动。

这一区别至关重要。只记录主要阶段的 agent 仍可能丢失许多中间工具调用。记录每一个微小步骤能带来更好的恢复能力，但前提是延迟和资源消耗仍在可接受范围内。

该架构同样会影响运维。单个二进制文件可减少团队需要部署的服务数量，但生产集群仍需要持久卷、对象存储、监控、容量规划以及经过验证的恢复机制。

“单个二进制文件”不应被理解为“没有运维负担”。即使供应商将组件打包在一起，分布式存储依然是分布式存储。

Restate Cloud 可以承担其中一部分责任。其自带云部署模式会在客户自己的云账户和私有网络中部署托管环境。

这一选项也回应了 agent 的另一项顾虑。编程和企业 agent 可能会处理源代码、凭据、文档及其他敏感信息，而客户并不希望这些数据跨越公共边界。

因此，该架构将性能、部署和数据控制联系在一起。Restate 需要在这三方面都形成优势，才能让自身方案区别于一个换上新营销包装的小型工作流引擎。

Restate 与 Temporal 的较量，本质是执行粒度之争

Restate 与 Temporal 的核心竞争并不只是创业公司对阵既有厂商，而是无处不在的细粒度持久化，对阵成熟的工作流中心化模型。

Temporal 是最关键的比较对象，因为它已拥有可观的采用规模、融资实力和生产环境经验。其工作流通过事件历史保存状态，而 worker 则负责执行应用活动。

这一模型为开发者划定了编排与外部工作之间的明确边界。它支持必须在中断后保持一致恢复的长周期业务流程。

Temporal 的规模也表明，这一类别已不再小众。该公司于 2026 年 9 月 14 日宣布完成一轮 5.5 亿美元融资，估值为 125.5 亿美元。

Temporal 表示，其年化收入运行率已超过 2.5 亿美元，同比增长超过 200%。公司还称，截至 8 月其开源版本安装量达到 4300 万次。

这些由公司自行披露的指标，为 Restate 的 2000 万美元融资提供了参照。Restate 面对的并不是一家产品过时、市场验证不足且增长停滞的既有厂商。

Temporal 也直接支持 AI 工作负载。其生态系统包含面向 agent 的集成和部署模式，并积累了多年服务其他关键应用的运维经验。

Restate 的论点更聚焦于架构。它认为，当开发者希望在快速应用路径内部实现持久化时，传统工作流运行时会引入过多开销。

Temporal 的活动通常经由任务队列传递。Worker 轮询获取这些任务，执行后上报结果，工作流才会继续。

这种分离能够提供清晰的故障边界，但也会为每项活动引入调度和网络开销。

Temporal 为较短操作提供 local activities。不过，这些操作需要谨慎处理幂等性，因为 worker 发生故障时，封闭工作流尚未记录完成状态，操作便可能被重复执行。

Restate 通过流式连接以内联方式记录步骤。该公司认为，这更适合包含大量短暂且彼此关联操作的 agent 循环。

Replit 的迁移为 Restate 提供了有价值的竞争案例。不过，单一客户的迁移无法证明其具有普遍优势。

对于看重其生态系统、支持语言、运维知识和明确工作流结构的团队而言，Temporal 可能仍是更优选择。现有客户也面临显著的迁移成本。

Restate 更广泛的原语能够减少自定义协调逻辑，但也引入了另一种编程模型。团队必须理解 journal、durable functions、Virtual Objects、并发控制和重放行为。

DBOS 代表第三条路径。它围绕由数据库支撑的应用模式实现持久化执行，尤其是 Postgres，而不是构建独立的复制运行时。

Inngest 和 Trigger.dev 则提供事件驱动和面向 serverless 的方案。主要云平台也提供与自身环境相连的持久函数服务。

这些替代方案使市场不会演变为两家公司之间的简单竞争。它们也验证了市场对这类软件的基本需求：在无需手写恢复代码的情况下，经受中断。

不过，Temporal 仍是 Restate 必须超越的标杆。其融资规模和披露的增长数据，使它有资源改善 agent 支持、降低使用摩擦，并回应架构层面的批评。

Restate 无法仅凭泛泛的可靠性承诺取胜。这个类别中的每一家严肃服务商都会作出这一承诺。

它的竞争力取决于可衡量的延迟、吞吐量、基础设施复杂度、故障恢复和开发者生产力差异。这些差异必须在供应商主导的基准测试之外依然清晰可见。

Restate 还必须证明，其集成存储没有以牺牲成熟度为代价。专用运行时可以移除外部依赖，但其自身存储层也因此成为客户关键路径的一部分。

因此，主要对手其实是一种架构默认范式。传统上，持久化工作被建模为工作流：通过 worker 和队列分派活动。

Restate 希望开发者将持久化视为普通函数、通信和状态的一种属性。AI agent 为检验这种替代方案能否扩展提供了异常严苛的测试。

存储优势也带来了 Restate 最大的风险

掌控存储路径让 Restate 能更严密地控制性能，但也意味着公司必须为执行之下每一种棘手故障负责。

构建复制日志并非一次性产品功能。它需要持续投入共识、成员变更、恢复、损坏处理、备份、升级和跨区域行为等工作。

外部数据库同样存在复杂性，但许多组织已了解如何运维它们。相比专用运行时，它们可能更愿意面对熟悉的存储故障模式。

Restate 的架构集中了责任。其日志、状态索引、快照流程或重放语义中的缺陷，都可能影响该系统原本应保护的应用。

这家创业公司表示，其高可用集群会在活跃节点之间复制数据，并支持快速故障切换。这些说法仍需在网络分区、集群过载、升级中断和区域性故障情况下持续验证。

关于“恰好一次”的表述也需要谨慎对待。运行时可以确保自身的状态转换只发生一次，但不受控制的外部 API 未必具备同样保证。

当远程服务接受操作却丢失响应时，开发者仍需要幂等键和对账机制。任何编排引擎都无法消除其控制范围之外系统的不确定性。

AI agent 还会引入更多模糊性。恢复已存储的模型响应可以避免不必要的第二次推理，但并不能证明原始响应安全或正确。

可持久化的错误依然是错误。Agent 可以可靠地恢复一个存在缺陷的计划、重复错误假设，或继续走向未经授权的结果。

因此，团队除了持久化执行外，还需要评估、可观测性、权限限制和人工控制。基础设施可靠性与模型可靠性解决的是不同问题。

Restate 提供用于检查和管理执行的运维控制能力。买方仍应测试：当一个 agent 跨越许多服务和嵌套任务时，这些工具是否能呈现足够的上下文。

他们还应审查版本控制行为。一个长时间运行的 agent 可能在新的应用部署修改其代码、提示词、工具或数据契约之前暂停。

运行时必须决定由哪个版本恢复执行。开发者需要针对迁移、不兼容状态和紧急变更制定清晰流程。

Restate 的推送模型还带来了另一个需要测试的领域。细粒度流式处理在服务保持可达时运行良好，但在流量高峰期间，背压变得至关重要。

Dispatcher 必须避免压垮函数，同时保持公平调度和恢复能力。不同工作负载可能还需要针对模型调用、API 和计算密集型工具设置不同限制。

该公司的 Replit 结果表明，该架构能够应对要求严苛的生产部署。不过，这些证据仍是一篇由 Restate 发布的客户案例。

独立基准测试应比较等效的保证条件和故障场景。如果一个系统采用不同的数据复制方式，或测试更简单的工作负载，原始吞吐量意义不大。

商业集中度是另一个尚未解答的问题。Restate 已公布具名客户并披露大型合同，但尚未公布经常性收入或留存率。

A 轮融资让公司拥有更多招聘和开发产品的能力。Temporal 更大规模的融资则同时提高了其在工程、销售、支持和全球运营层面竞争的成本。

Restate 的机会并不要求在所有场景中取代 Temporal。它可以在高频 agent 及其他受益于内联持久化的工作负载中建立强势地位。

风险在于，既有厂商可能在 Restate 建立相当分发能力之前降低自身开销。云平台也可能将足够的持久化能力捆绑进客户已在使用的服务中。

因此，Restate 必须将技术差异转化为可重复的客户成果。更低的延迟固然有价值，但更简单的事故恢复和更快的开发速度可能更具说服力。

三个信号将揭示 Restate 的押注是否奏效

下一项考验在于，Restate 能否将优雅的机制转化为在严苛生产系统中可被独立衡量的采用规模。

第一个信号是来自 Replit 部署的更广泛证据。工程师应关注有关持续吞吐量、尾延迟、故障恢复、升级和运维人员配置的独立细节。

如果这些结果在正常流量和事故期间仍保持强劲，Restate 的细粒度模型将更具可信度。如果证据始终局限于峰值操作次数，架构优势就仍不那么确定。

第二个信号是客户多样性。编程、金融、安全、研究、客户运营和浏览器自动化等领域的 agent 工作负载差异显著。

如果这些类别中出现多项公开部署，将表明 Restate durable execution 是可复用的平台。如果客户集中于单一编程 agent 模式，则意味着产品适配范围较窄。

第三个信号是 Temporal 的回应。新的集成、更简单的部署、更快的本地执行或修订后的 agent 原语，都将表明 Restate 找到了一个有意义的压力点。

强有力的回应将验证问题的存在，同时使 Restate 的商业任务更加艰难。竞争动作有限则会给这家创业公司更多空间来定义一个独特类别。

开发者还应将运行时持久性与围绕智能体的更广泛系统区分开来。即使循环本身可靠，仍取决于模型行为、工具权限、数据质量和人工监督。

最有价值的评估应从真实的故障地图开始。团队可以在一个生产工作流中列出每一次模型调用、外部变更、等待状态、回调和审批。

随后，他们可以测试进程终止、网络中断、重复投递、API 部分成功、代码部署和区域性故障。结果将揭示引擎是否能在不掩盖危险不确定性的前提下保留执行进度。

Restate 的架构值得关注，因为它提出了一项具体且可证伪的主张：持久化执行可以变得足够快速、轻量，从而置于智能体循环内部，而不只是围绕其运行。

这笔 2,000 万美元融资让公司获得了更大机会来证明这一主张。但它并不意味着集成式存储会自动为每个团队带来更高安全性、更快速度或更易用的体验。

对于关注 Restate A 轮融资的开发者而言，实际问题如今可以量化：在真实故障条件下，细粒度持久性是否能减少重复工作和运维复杂度？请用你最长的智能体工作流测试这一问题，再将恢复行为与当前技术栈进行比较。