Rivet 开源 Agent 编排器：用 Actor 模型与 S3 分层存储替代沙箱

从游戏后端到 Agent 工作负载

Rivet 由 Nathan 和 Nicholas 创建，2023 年进入 Y Combinator。团队最初为 Diep、Krunker 等多人游戏构建基础设施，在高吞吐匹配、实时消息和快速扩容上做过大量优化。当时 Postgres 无法满足吞吐要求，团队在 Redis 上拼接 Lua 脚本，维护成本变得过高。他们随后把游戏服务器编排器扩展为 Rivet Actors，用轻量 worker 提供内存状态和持久存储。按他们的数据，这套系统支撑过数千万月活用户。

Agent 负载兴起后，Rivet 认为给每个 Agent 跑一个沙箱效率低。沙箱启动慢、大部分时间闲置，还需要完整 VM。Rivet 给出的对比数据显示，Actor 基线内存约 72 KB，最小沙箱约 512 MB；Actor p99 启动约 4.9 毫秒，沙箱 p99 约 1.7 秒。这些数据来自 Rivet 3.0.3 的基准测试，沙箱数据来自 E2B。

S3 上的 SSD 速度：写入和读取分层

Rivet 的存储设计没有把 S3 直接放在写入路径。Actor 的 SQLite 写入会先落到三个可用区中两个的 SSD，确认后写入完成，再在后台批量上传到 S3。读取时优先从 SSD 缓存取数据，未命中则回源到对象存储。团队称这种分层让 S3 不进入写入路径，同时降低延迟和成本。

官方公布的性能指标包括：三可用区持久写入 p99 为 1.07 毫秒，读取 p99 为 1.36 毫秒，从对象存储读取 p99 为 138 毫秒。Rivet 还提到，与 EBS gp3 的复制 SSD 相比，存储成本可低约 10 倍。此前 Rivet 使用 FoundationDB，但用户把大量会话记录、Agent 产物、完整 POSIX 文件系统放入 Actor，数据量比 Postgres 场景大一个数量级，SSD 常因旧数据闲置。改用 S3 作为主存储后，SSD 仅作为缓存层。

部署与约束

Rivet 的部署入口是一个 Rust 二进制，S3 是唯一外部依赖。自托管、Rivet Cloud、BYOC 三种模式运行同一套控制平面。Rivet Cloud 在 AWS 或 GCP 任意区域部署专属集群；BYOC 把控制平面部署到用户 VPC，由 Rivet 托管运维。本地开发与生产环境行为一致。项目采用 Apache 2.0 许可，支持 TypeScript 和 Rust 编写 Actor，也提供 React hooks、OpenTelemetry、定时任务、Actor 间调用、作用域 JWT 等能力。

一个已公开的案例是 Amp。它最初尝试基于 Cloudflare Durable Objects 构建多人 Agent，但受平台限制和支持响应影响未能上线，随后在一个周末迁移到 Rivet Actors 并部署在本地环境。Rivet 将自身定位为 Durable Objects 的开源替代，强调没有 128 MB 内存上限、没有 10 GB SQLite 存储限制，也不会随机驱逐 Actor，并运行原生 Node.js 或 Bun。这些能力是否能在复杂生产环境中持续成立，还需要更多部署验证。