把 agent 做成可以崩溃、可以恢复的进程

这几年关于 agent 可靠性的讨论,大部分停在 prompt 层:更细的系统提示、更清楚的工具描述、更谨慎的报错文案。Restate 的 Giselle van Dongen 在 AI Engineer World’s Fair 2026 收尾日的分享,把这个问题挪去了另一层,基础设施层。她的判断很直接:agent 崩溃后能不能从原地接着跑,不该指望模型记住发生了什么,该指望一层持久化的事件日志。

原视频:https://www.youtube.com/watch?v=I2cbIws9j10(约 05:05:04 开始)

三次浪潮里被跳过的一层

Giselle 开场引用了 Andrej Karpathy 前一周的一条判断:人和 LLM 交互的方式正在经历三次浪潮。第一次浪潮里,LLM 像一个网站,你提问,它想几秒钟,给你答案。第二次浪潮是 agent,一个装在电脑上的 app,带着几个工具,能替你干点活。第三次浪潮正在发生,agent 变成持久化的、异步的实体,长期运行的进程,能接触工具、接触组织里的其他 agent、接触上下文。

用例正在从单个 agent 转向连接组织各部分的 agent 平台,基础设施这一层理应跟着进化。Giselle 观察到,当前大部分创新堆在 agent SDK 和 memory 这类工具上,这些工具适合快速搭 demo,但没法把组织里分散的各个部件真正连起来。想做更复杂的 agentic 系统,retry 逻辑、恢复逻辑这些东西必须写,而且很难写对——但没有它们,长期运行、有状态、分布式的进程根本没法在生产里稳定跑起来。

Restate 就是奔着这层去的。这是一个开源框架,官方定义是”灵活的持久化基础”,可以拿来搭任何后端,不是专为 agent 做的,但 agent 本质上也是一种后端,所以用起来很合适。它的设计思路一部分来自 Apache Flink 这个流处理引擎,一部分来自 Meta 内部事件基础设施团队的前架构师。

Restate 到底是什么

持久化执行(durable execution)是这套系统的第一块拼图,用来保证 agent 单次运行出了问题也能扛得住。设想一个 agent 跑了一周然后崩溃,你想要的不是让它从头再来,而是精确回到失败的那一刻继续。

做法是把 Restate 服务器架在 agent 服务前面,像一个消息代理或者代理服务器。请求进来,Restate 转发给你的服务,同时打开一条常驻连接,这条连接就是 agent 的生命线。agent 做事的每一步都会把事件发给 Restate,这些事件攒成一份日志。失败之后,就靠这份日志把进程拉回原来的位置——相当于把一个普通函数,变成一个长期运行、持久化、有状态的函数,你不用自己写那堆复杂的恢复逻辑。

Giselle 现场演示了这一点。一个接入 Slack 的深度研究 agent,在 Slack 里问”AI 有什么新进展”,Restate 自带的界面,她称之为”agent 的驾驶舱”,显示出所有注册的 agent 和正在跑的执行。计划 agent 先调用一次 LLM,列出几个子话题等待批准,批准后并行拉起多个研究子 agent,最后由一个写手 agent 汇总,是经典的深度研究工作流。演示里她故意注入了一个工具报错,某次网页搜索因为 API 挂了失败。页面左侧的日志清楚显示了这次失败和随后的重试,恢复靠的是日志里记录的进度,而非整个流程推倒重来。

代码层面,写 Restate 应用的基本单位是 HTTP handler,靠 SDK 变得持久化。每个 handler 拿到一个 context 对象作为第一个参数,你在这个对象上做的每个动作都会变成一个发往 Restate 的事件。把一次 LLM 调用包进 SDK 内置的持久化步骤里,这一步就变成了可恢复的。就算两小时后崩溃、两个月后崩溃,都能精确恢复到这一步。

它不只用来兜底失败,也能处理”需要人审批”这种可能拖几周的场景。做法是创建一份活在日志里的挂起点,人没点确认按钮之前,进程就一直挂着。如果跑在 serverless 上,挂起期间根本不占用函数执行时间。人一点确认,进程就从原来的地方接着走。

会话隔离:两个人不该踩到同一份状态

这是整场分享里分量最重的一块。Giselle 提出一个判断:workflow 这套模型,并不适合拿来描述真正的 agent。按 Karpathy 的说法,agent 更像一个活得更久、带记忆的持久化实体,workflow 那种一串步骤顺序执行的模型配不上这个定义。Restate 给出的答案是虚拟对象,可以理解成一个有状态的 actor。它有一个唯一 ID,比如一个会话 ID;有一份只属于这个 ID、彼此隔离的键值状态;还有一组能对这个会话执行持久化操作的 handler。

回到 Slack 研究 agent 的例子:如果一次研究要跑 10 分钟,用户不该被迫等它跑完才能补充一句”重点看前沿模型”。虚拟对象负责保存这次会话的聊天记录,让追加信息随时能送进去。真正的难点在并发上。如果要同时跑几千个会话,必须保证不同 agent 的状态不会互相覆盖:两条 Slack 消息同时触发两个 agent,谁都可能把对方的会话状态写坏。Restate 的解法是给每个会话 key 上一把锁,同一个 key 同一时间只允许一次执行在跑,第二个请求排在后面等,不会两边同时写。

隔离状态只是第一层,演示里 Giselle 还往上加了一层。用户发一句”重点看前沿模型”,系统先用一次 LLM 调用判断这句话跟正在跑的研究相不相关,相关就以信号的方式注入到正在跑的 agent 循环里。用户如果说”别管那个了,去研究 AI 政策”,系统判断新话题和旧的不相关,就取消当前执行,另开一个去跑新话题。这次取消是顺着调用链一路往下发的信号:如果 agent 已经拉起了子 agent,子 agent 先被取消,再取消上一层的控制器,相当于把整个调用栈往回倒。agent 也因此有了”回滚”的能力。

推送,不是轮询

前面说的持久化恢复、会话隔离、信号取消,底层其实是同一套架构在支撑。Restate 的核心是一套事件驱动的分布式日志。客户端在一侧,服务在另一侧,中间是一份记录所有日志事件的日志,加一个事件循环。事件循环根据事件类型做决定:把状态写进内嵌的状态存储、设一个定时器,或者把请求发给另一个 agent。这套设计的灵感很大程度上来自 Meta 内部核心事件基础设施层,部分设计者后来把它做成了更通用的开源方案。

有一个细节很容易被忽略,却是这场分享里我最喜欢的一个架构选择:大多数工作流编排器走轮询模式,服务不停去问编排服务器有没有新任务;Restate 反过来走推送模式,由它主动把调用推给服务。轮询和推送的差别,好比你不停打电话问快递到了没有,和快递员直接按你家门铃。推送模型把延迟压得很低。官方给出的数字是一个 10 步的 workflow,p99 延迟能做到 45 毫秒,传统编排器动辄几百毫秒起步的轮询间隔是常见对照。这个数字意味着把持久化保证用在一个高频调用的函数上,用户几乎感觉不到编排层的存在。推送模型对 serverless 也友好,因为它本来就是发请求、顺带把函数叫醒的模式。

部署上,Restate 是单个二进制文件,状态存储内嵌在里面,想做高可用直接多开几份实例,定期往对象存储打快照就行。官方给了六种语言的 SDK,也接了大多数主流 agent 框架。即便不用这些集成,直接拿任意 LLM SDK 手写 agent、把关键步骤包进 Restate 的 SDK 构件里也能用。它是开源的,可以自托管,也有部署在自己云账户里、数据不出账户的选项,以及一个全托管云服务。

这场分享在当天的位置

这一场是当天 Harness Engineering 赛道里,从基础设施可靠性角度切入的一场。同一天更早的主舞台开场,Barr Yaron 讲的是那份年度问卷:agent 拿到写权限的速度已经超过企业管住它的办法。企业目前手里能拿出的管控手段,基本还是人工审批加权限开关。两场分享其实站在同一个问题的两个楼层。Barr 讲的是治理层,谁能让 agent 做什么;Giselle 讲的是基础设施层,agent 做事的时候会不会崩、崩了怎么办。治理解决不了可靠性,可靠性也替代不了治理,这两层缺一个,agent 拿到再大的权限也立不住。

我的判断

把这场分享放回本地关于 agent 架构的笔记里看,不算孤例。此前对比 Hermes 的 delegate 机制和 OpenClaw 的 subagent 系统时,记录过同一组矛盾:同步阻塞换来强隔离,异步推送换来能中途调整方向的灵活性。OpenClaw 靠的是把结果以消息形式推回父 agent,外加一个能在子任务跑着的时候插一句引导消息的机制。这和 Restate 里注入信号、取消重跑的设计几乎是同一个思路,只是换了一层实现。虚拟对象按会话 key 排队执行的做法,也和多 agent 协作里给会话分配锁、避免并发写坏状态的老问题对上了号。不同项目在各自的问题上,收敛到了同一个答案。

真正值得记住的一点是,Restate 展示的日志不只是用来崩溃恢复,它也是一份能让人看见 agent 每一步在干什么的记录。这比事后翻聊天记录猜哪里出了错,要可靠得多。如果你的 agent 已经拿到了写权限,团队现在唯一能拿出手的可观测手段还是出问题了去问模型发生了什么。这本身就是个信号:比起再打磨一版更聪明的 prompt,团队更缺的是一层能替你记账的基础设施。