别把 Agent 状态塞进临时沙箱：用 Rivet Actors 构建可恢复的有状态后端
很多 Agent 后端从一次性请求开始：收到任务、启动运行环境、调用模型，再把结果返回。等产品加入长对话、后台调度、实时推送和多租户隔离，状态到底放哪里就成了新问题。每次请求都重建上下文会增加编排负担；把整个 Agent 循环绑进短命沙箱，又可能让推理等待时间占用运行资源。
Rivet 将这类问题拆成两层：Actor 承载长期状态与协调逻辑，执行环境按需作为能力提供给 Agent。这不是“另一个模型框架”，而是一个以 Actor 模型组织有状态工作负载的运行时与编排平台。
Actor 适合放什么
Rivet 官方 README 将 Actor 描述为按 key 寻址的长生命周期进程。它可携带内存状态、SQLite 数据库、WebSocket 实时连接和调度能力；项目示例支持在 Node.js、Bun 或 Rust 环境运行。可以把一个 Actor 映射到一个 Agent 会话、用户或租户，让状态归属有明确边界。
这种抽象适合需要“醒来后接着做”的服务：客服 Agent 保存会话摘要，代码助手记录任务进度，或者一个协作应用向多个客户端广播事件。Actor 管理状态和流程；需要执行不可信代码时，再把沙箱当作隔离执行层，而不是把持久记忆也塞进沙箱生命周期里。
官方 README 展示了使用 rivetkit 定义 Actor、用 rivetkit/db 配置 SQLite 的示意：
import { actor } from "rivetkit";
import { db } from "rivetkit/db";
const agent = actor({
db: db({
onMigrate: async (db) => {
await db.execute(
"CREATE TABLE IF NOT EXISTS messages (role TEXT, content TEXT)"
);
},
}),
actions: {
saveMessage: async (c, role: string, content: string) => {
await c.db.execute(
"INSERT INTO messages VALUES (?, ?)",
role,
content
);
},
},
});
这段代码说明的是结构而非完整可直接运行的应用：Actor 定义包含数据库迁移和 action，具体入口、客户端连接方式以及依赖版本仍应以对应版本的 Quickstart 为准。官方示例还展示客户端按 key 获取 Actor、连接后监听事件并调用 action；因此前端或其他服务可通过明确的 Actor 身份与其交互。
持久状态与实时交互合在一个边界里
Rivet README 介绍其 SQLite 数据通过 S3 持久化，并支持节点故障迁移、Actor 间调用、HTTP/WebSocket 网络、定时唤醒，以及 OpenTelemetry 格式的 traces、metrics 和 logs。对 Agent 产品而言，这意味着应用可以把“会话状态”“定时任务”和“向界面推送进度”放进同一套 Actor 组织方式，而不必为每项能力另造一层服务。
但这不代表所有 Agent 都该做成一个 Actor。可按自然隔离边界选择粒度：按会话拆分便于恢复单次任务；按用户拆分适合共享长期偏好；按租户拆分则可能让共享状态更简单，但需要额外考虑租户间并发和访问控制。粒度越细，调度与寻址更明确，也要评估 Actor 数量、状态迁移和连接管理成本。
别把它误当作通用 Linux 沙箱
Rivet 的核心 Actor 与代码沙箱不是同一概念。README 将其 agentOS 描述为基于 V8/WebAssembly 的隔离执行能力，并称可控制网络、文件系统和资源；这与需要完整 Linux 虚拟机、内核级隔离或特定系统依赖的任务并不等价。若 Agent 需要运行任意系统包、访问内核特性或执行高风险代码，应单独评估隔离强度与威胁模型，不能仅凭“sandbox”一词推断安全保证。
项目 README 还列出自托管、Rivet Cloud 与 BYOC 等部署选项。自托管文档描述控制平面可运行在 Docker、Kubernetes 或 VM 上，并以 S3 为依赖；部署决策应结合数据驻留、运维能力和云成本，而不是只看冷启动或内存指标。
什么时候值得试
如果你的 Agent 服务需要长期会话、按用户隔离状态、事件推送或定时恢复，Actor 模型值得做一个小型原型。先选一个最小工作流：创建一个 keyed Actor，保存一条状态记录，再从客户端连接并触发 action；随后验证进程重启、节点迁移和重复请求时的行为。确认这些生命周期语义符合产品要求，再接入模型调用与执行环境。
如果任务只是无状态的单次 API 调用，普通 HTTP 服务可能更简单；如果主要需求是运行不可信代码，专用沙箱产品可能更直接。Rivet 的价值在于把有状态协调变成一等概念，并允许应用按需组合 Actor、持久化、实时通信和执行层，而不是宣称一个运行时适合所有 Agent。
相关链接