你让 AI 助手持续几天处理一项工作：记住前面的对话，等待新消息，失败后重试，并在约定时间继续执行。难点往往不在 AI 会不会回答，而在它能不能一直记得自己做到哪里。普通程序一旦重启、迁移或闲置关闭，内存里的消息和进度就可能消失。Rivet 想解决的，正是这副“持久骨架”的问题。
据项目方 rivet-dev 的 GitHub 仓库，Rivet Actors 面向 AI agents、协作应用和 durable execution——也就是任务跨越多次运行、故障或等待后，仍能接着执行。需要说明的是，目前材料全部来自项目方，尚无独立测试或第三方信源交叉印证。
给每个 Agent 一个长期住址
Rivet 的核心是 Actor。Actor 是一种拥有独立状态、通过消息与外界交互的计算单元。可以把它理解成一间带档案柜的工作室：消息送进来，Actor 在里面处理；相关记录则留在自己的柜子里。
项目方建议为每个 Agent、会话或用户建立一个 Actor。它是长期运行的轻量级进程，活跃时持续工作，空闲时休眠，并支持缩容至零。这样，系统不必让每个 Agent 永远占着一份运行资源，又能在新消息到来时恢复工作。
这和常见的“无状态”请求不同。无状态服务每次接到请求，近似从零开始；有状态服务则记得此前的数据和进度。长对话、多人协作文档和跨步骤任务尤其依赖这种连续性。
记忆不能只放在脑子里
Rivet Actors 的状态驻留在内存中，让计算和数据处在一起。项目方同时称状态可以持久化，并提到可使用 SQLite——一种嵌入程序内部的轻量数据库——或自带数据库。持久化的意思，是把运行状态可靠保存下来，让进程重启或迁移后仍有机会恢复，而不是让 Agent 的消息和任务进度随进程一起消失。
不过，仓库中“自动持久化”的概括，与“使用 SQLite 或自带数据库”的具体关系并未完全讲清。哪些状态自动保存、何时落盘、不同数据库如何保证一致性，现有材料没有展开。
示例代码展示了一个直观流程：Actor 从队列接收用户消息，把消息加入自身状态，调用模型生成回复，再把生成中的文本实时广播给客户端。这里的队列负责暂存待处理消息，避免异步请求一拥而上；示例所用的 openai("gpt-5") 只是代码选择，不能据此推断 Rivet 与该模型存在合作、绑定或专门优化。
不只是保存聊天记录
Rivet 把长任务常用的几样能力放进同一种运行单元。WebSockets 提供实时双向通信，适合流式回复或多人协作；workflows 把任务拆成多个步骤，并在失败时自动重试；durable message queues 保存尚未处理的异步消息；timers 和 cron scheduling 则负责延时与周期任务。
这套组合的意义，在于生命周期由同一个 Actor 承接。一个 Agent 可以记住上下文，也可以排队等待工具调用，某一步失败后重试，或者在未来某个时间继续工作。项目方还列出沙箱编排、工作流、协作文档、按租户数据库和聊天室等用途。例如，一份协作文档可以对应一个 Actor，由它保存文档状态，并向所有连接者广播变化。
为什么现在值得看
Agent 从一次问答走向长任务后，模型只是系统的一部分。真正棘手的工作常常发生在模型调用之间：消息要保存，步骤要衔接，失败要恢复，空闲时还不能一直烧资源。Rivet 的思路，是用一个统一的 Actor 同时承接状态、存储、网络、队列和调度，减少这些能力彼此脱节的机会。
项目方给出的对照数据称，Rivet Actor 冷启动约为 20 毫秒，而其测试中的 Kubernetes Pod 约为 6 秒、Virtual Machine 约为 30 秒。仓库补充了部分环境：Actor 使用 Node.js 与 FoundationDB；Pod 在预置 AWS EKS 节点上启动 Node.js 24 Alpine 镜像；虚拟机则是 AWS EC2 t3.nano 启动至可通过 SSH 连接。
这些数字只能视为项目方在特定配置下的结果。Actor、容器 Pod 和完整虚拟机并不是天然等价的对象，测试口径也不足以支持普遍的性能结论。类似“无限扩展”“即时读写”等表述同样属于项目方的营销性概括，不应直接理解为生产环境保证。
Rivet 还宣称 Actor 可以部署到靠近用户的全球边缘节点，或放在特定法律管辖区。这为低延迟和数据位置控制提供了一个方向，但现有材料没有披露节点覆盖、可用区域或实际部署限制。
局限与未知
- 目前只有 rivet-dev 官方仓库这一处信源，尚无独立实测来验证其可靠性、生产成熟度和成本优势。
- 持久化的边界、故障恢复机制以及自带数据库的接入细节，在现有材料中没有充分说明。
- 冷启动等对照数据依赖特定环境，不能直接推广到其他配置，也不宜据此断言 Rivet 普遍快于 Kubernetes 或虚拟机。