YC W23 孵化的开源基础设施项目 Rivet 近期发布了基于 3.0.3 版本的 AI Agent 编排器。官方直接拿传统沙盒当靶子，亮出一组悬殊的指标：单个 Rivet Actor 实例仅占用 72 KB 内存（对比沙盒的 512 MiB），p99 冷启动只需 4.99 ms（对比沙盒的 1.70 s），并且通过 S3 上的 SQLite 实现了 1.07 ms 的 p99 持久化写入，存储成本比 AWS EBS gp3 三副本低 10.4 倍。
顺着官方基准测试仓库和架构文档拆下去，这套数据背后藏着两处关键的技术错位。Rivet 并不是一个能直接平替 E2B 等代码安全沙盒的隔离容器，而是一个可私有化部署（BYOC）的 Cloudflare Durable Objects 开源替代品；至于在对象存储上跑出 SSD 速度，靠的也不是突破 S3 的物理延迟极限。
1.07 毫秒的 S3 写入是怎么跑出来的
但凡和 AWS S3 打过交道的后端工程师都清楚，对象存储的首字节延迟通常在几十毫秒量级。用 S3 直接挂载 SQLite 还要跑出 1.07 ms 的 p99 写入，在物理规律上就讲不通。
答案在于对象存储根本不在 Rivet 的同步写入路径上。
当一个 Actor 往内置的 SQLite 写数据时，写操作实际发往跨 3 个可用区的控制平面本地磁盘。只要拿到多数派（3 个节点中的 2 个，含跨可用区）确认，系统立刻向客户端返回成功。这个阶段的 p50 延迟是 0.69 ms，p99 是 1.07 ms。至于对象存储，则是控制平面随后在后台把数据批量异步刷进去的；日常读取时，热数据页直接由本地 SSD 响应（p99 为 1.36 ms），冷数据页才按需从对象存储拉取。
更有意思的是跑分环境与宣传口径的出入。尽管首页大字主打 S3，但在 2026 年 11 月 5 日发布的 Rivet 3.0.3 官方基准测试中，底层实际跑在 Azure eastus2 区域的 3 台控制平面虚拟机上，搭配的是 Azure Blob Storage 本地冗余存储。
那 10.4 倍的存储成本优势，也只是单纯拿 AWS S3 Standard 的标价去对比 3 副本 EBS gp3 的目录价。如果真在生产环境高频读写，对象存储的 PUT/GET 请求费、跨可用区复制流量费，以及前面顶着热数据的本地 SSD 磁盘成本，都得重新算进账单里。
72KB 对决 512MB：一场苹果比橘子的跑分
在宣传材料里，Rivet 把 Actor 和传统沙盒（以 E2B 为基准）放在同一张表格里正面对比。一边是 72.4 KB 内存和 4.99 ms 启动，另一边是 512 MiB 内存和 1.70 s 启动。数字看着像降维打击，但两边的测试条件和架构职责完全不在一个图层上。
把测试脚本和文档放在一起对照，能看出三个维度的口径错位：
- 内存统计口径72.4 KB 是在 2026 年 9 月用 Rust RivetKit SDK 测出来的单 Actor 增量常驻内存（RSS），而官方 README 主推的却是内存开销大得多的 TypeScript/Node.js 示例；至于对面的 512 MiB，只是 E2B 虚拟机的默认内存配额上限，既不是实际消耗，也不是最低启动要求。
- 并发测试条件4.99 ms（p50 为 4.30 ms，1500 个样本）是单次串行发请求创建空 Actor 的耗时；而被拿来对比的 1.70 s 第三方数据，是同时并发拉起 100 个沙盒、并且包含在里头执行完第一条 Shell 命令的总时间。
- 架构安全边界Rivet 之所以能把单实例压到几十 KB，是因为成千上万个 Actor 共享同一个 Node.js 或 Rust 进程。共享进程意味着没有操作系统级别的隔离。
在真实的 AI Agent 架构里，这两者根本不是替代关系，而是上下游。Rivet Actor 管的是对话记忆、WebSocket 实时广播和状态调度；一旦 Agent 需要写一段 Python 脚本或者跑 Shell 命令，Rivet 的标准架构文档里写得很明白，照样得外接 E2B、Daytona 这类外部沙盒，或者调用它自家的安全执行环境 agentOS。那 72.4 KB 里，并不包含代码执行沙盒和大模型上下文膨胀的开销。
游戏房间的借尸还魂，与架构师的真实账单
为什么一家初创公司能把高密度状态进程玩得这么熟？翻看这家公司的履历就能找到脉络。
Rivet 是 YC W23 孵化的项目，最早的定位是多人游戏领域的 Heroku，专门给游戏开发者做开房间、玩家匹配、长连接托管和 DDoS 防护。过去两年大模型兴起，团队敏锐地抓住了底层架构的同构性：一个多人在线游戏房间，和一个 AI Agent 会话，在基础设施眼里几乎是同一件事。它们都需要维持一条或多条 WebSocket 实时长连接，都在内存里揣着高频更新的状态，都要求在没人说话时立刻休眠省钱、来消息时毫秒级唤醒。
《韩非子》里讲，形名参同，上下和调。Rivet 把当年管游戏房间的底层引擎抽出来，换上 Agent、Workflow 和 agentOS 的名头，完成了一次相当丝滑的赛道切换。在 AI 基础设施经常把简单问题复杂化的今天，这种把成熟游戏服架构平移过来解决 Agent 状态持久化的方法，确实切中了无状态函数（Serverless Functions）难以维持长会话的痛点。
把游戏房间改造成 Agent 账房是真聪明，但把账房吹成防弹铁笼就是营销了。
对于正在做技术选型的架构师来说，剥掉营销话术之后，Rivet 真正的坐标是一个开源、无厂商锁定、可装进自家 VPC 的 Cloudflare Durable Objects。
| 平台方案 | 计费模式与起步门槛 | 核心优势与适用边界 |
|---|---|---|
| Rivet 3.0 | 控制平面订阅（0 / 10 / 120 / 900 美元/月）+ 节点包月（1vCPU/4GB 为 16.80 美元/月），支持 BYOC | 原生 Node/Bun/Rust 运行时，无内存与 10GB 存储硬上限，数据不出自有云 |
| Cloudflare DO | 最低 5 美元/月（含 100 万请求与 40 万 GB-s），超量按请求与容量时长计费 | 免运维全球边缘分发，但绑定定制 V8 运行时，有 128MB 内存与 10GB SQLite 限制 |
| Temporal Cloud | 无基础月费，按动作数计费（50 美元/百万次起，量大降至 25 美元）+ 历史存储费 | 擅长复杂多步骤容错重放，但非针对单实体高频 WebSocket 实时交互设计 |
Rivet 在 2026 年 11 月初已经放弃了早年按唤醒时长（每千个活跃 Actor 小时 0.05 美元）的计费方式，改成了更像传统 SaaS 的控制平面订阅加计算节点包月。如果你的团队因为数据合规要求不能把状态放在 Cloudflare 公有云上，或者受不了 Durable Objects 的 128 MB 内存上限和定制运行时限制，Rivet 提供了一个只要有对象存储桶就能自己在 Kubernetes 或裸金属服务器上跑起来的替代方案。
- 风险.Rivet 3.0 虽然已在 2026 年 11 月 1 日转正，但多区域部署（multi-region）、Serverless 托管和访问控制列表（ACLs）这三项关键能力在 3.0 中仍处于缺失待定状态，连官方都建议依赖这些特性的老用户先停留在 2.x 版本。
回到开头那组诱人的跑分。如果你需要一个能在自家 VPC 里同时挂起几十万个 Agent 对话状态、自带实时广播和本地数据库的轻量级协调器，Rivet 3.0 的共享进程模型确实能帮你省下大笔服务器账单；但指望用这 72 KB 的进程直接去跑大模型写出来的未知代码，你还是得老老实实给每个会话配一个几百兆的安全沙盒。接下来真正决定 Rivet 能不能在企业级生产环境站稳的，不是它比沙盒快多少倍的宣传表，而是它什么时候能把 3.0 欠下的多区域容灾、权限控制和 agentOS 的真实隔离强度补齐。