Rivet 在 HN 发布：一个 agent 一张“合租床位”，状态存进 S3

作者：陈一帆

11 月 5 日，Rivet（YC W23）在 Hacker News 发布新版本：不给每个 AI agent 起沙箱，而是让它变成一个轻量 actor，数据和记忆落在对象存储上。官方给出的数字是 72 KB 内存、4.99 毫秒冷启动，但仍是自家基准；评论区则在追问跨可用区流量成本和隔离强度。

2026 年 11 月 5 日，Rivet 团队（Nathan 与 Nicholas，YC 2023 冬季批次）在 Hacker News 发了一条 Launch HN，把自家的 actor 编排平台重新对准 AI agent。要改的就一句话：不再给每个 agent 起一个沙箱，而是让每个 agent 变成一个轻量 actor，数据放到 S3 上 。截至 11 月 7 日，帖子拿到 118 分、58 条评论 。

差别在于每个 agent 占多少资源

主流的 agent 托管方式是一人一间房：每个 agent 一个 VM 或容器，独立、干净，但一间房就是一间房的成本，而且 agent 大部分时间在等模型返回，房间里基本没人。Rivet 的做法更像合租床位：许多 actor 挤在同一个 node 进程里，各自有内存状态和一个小 SQLite，空闲时打包休眠、不占资源，下一个请求来了再把状态铺回去 。

官方给的对比是 72 KB 对 512 MiB 内存、4.99 毫秒对 1.70 秒 p99 冷启动 。这里需要说明：后两个数不是 Rivet 测的。512 MiB 取自 E2B 2026 年 11 月 4 日计费文档里的默认配额，1.70 秒取自 ComputeSDK 10 月 30 日的第三方沙箱基准；前两个数出自 Rivet 自家跑在 3.0.3 上的基准，原始样本和复现脚本都放出来了，但目前还没有第三方复测 。厂商自测和独立验证之间，还差一步。

长驻进程，是它真正的卖点

一个 Rivet Actor 就是一个一直活着的进程，内存里存上下文，自带 SQLite、WebSocket 和定时调度。一次 agent 回合要跑很久，中间还要给多个客户端推流，这种场景下“进程别死、状态别丢”比“启动快”更要紧 。

存储上有个折中：写入先在三个可用区的 SSD 上确认两份，S3 只在后台批量归档，不在写路径上。官方报的数是 1.07 毫秒 p99 durable write、1.36 毫秒读，缓存没命中要回源对象存储时是 138 毫秒 。用 S3 做底座的好处是便宜，官方按 AWS 标价算的存储成本约为三副本 EBS gp3 的十分之一 。

这套东西不是为 agent 从零写的。团队在 2023 年做的是多人游戏服务器编排（Diep、Krunker），从 Redis 上糊 Lua 脚本起步，中途换过 FoundationDB，后来发现用户往 actor 里堆的东西——会话记录、产物文件、整个 POSIX 文件系统——比 Postgres 里多出一个数量级，旧数据躺在 SSD 上白烧钱，才转向 S3 。

许可与商业化

Rivet 用 Apache 2.0 开源，可以完整自托管：控制面是一个 Rust 二进制，唯一依赖是对象存储桶，不跑数据库也不用消息总线 。商业侧有三条路——自托管、托管的 Rivet Cloud（AWS 或 GCP 上的专用集群）、以及把控制面开进你自己 VPC 的 BYOC 。

评论区说了什么

正面的一手体验来自 fastball：他们把一个原来跑在 Cloudflare Durable Objects 上的模块迁到了自己 VPC 里的 Rivet，觉得挺顺 。作者也在帖里提到 Amp 原先卡在 Durable Objects 的限制上，一个周末迁完并走本地部署 。这类说法目前只有当事方自述。

质疑也很具体。esafak 的第一反应是“agent 的主要瓶颈是在等模型，不是编排速度”，作者回应说这套架构面向的是同时跑几十上百个 agent 的场景 ；chicagobuss 顺着写路径算了一笔账，跨可用区传输在 AWS 上大约每 GB 0.04 美元起，量大了这笔钱会浮出来 ；SriniK 则直问安全边界，V8/WASM 隔离和 E2B 那种 microVM 不是一回事 。还有 minraws 直接吐槽上手体验糟糕，“我的 Claude/Codex 和我一样困惑该怎么用” 。Nathan 在回复里也没把话说满：沙箱不会消失，不同负载会走向不同架构 。

放在哪一格

拿它和 Cloudflare Durable Objects 比最近——同样是虚拟 actor 模型，Rivet 强调没有 128 MB 内存上限、没有 10 GB SQLite 上限、跑在原生 Node.js 或 Bun 上，而且能自托管 。和 Akka、Orleans 那一路是同源思路，只是持久化从 JSON 存储换成了 SQLite 。至于 LangGraph 这类 agent 框架，并不在同一层：Rivet 底层是通用 actor 平台，agent 只是可选的上层库 。

以陈一帆的判断，这类项目值得盯的不是“能不能替掉沙箱”，而是它把“跑 agent 的主循环”和“跑 agent 写出来的代码”拆开了。拆开之后，一个进程可以撑住很长的对话、多人同时连、隔天再唤醒；真要执行不可信的代码，还是把沙箱当工具挂给它 。什么时候这层 actor 变成默认选项、什么时候还得回到真沙箱，取决于接下来有没有人公布独立压测和真实生产数据——目前这两样都还缺。

转载说明

本文根据以下公开资料整理，原文及配图出处见下方。

• [S1] Launch HN: Rivet (YC W23) – Scale and Orchestrate Agents on S3
• [S2] Rivet - The Orchestrator for Agentic Workloads
• [S3] https://hn.algolia.com/api/v1/search?query=Rivet%20S3%20agents&tags=story
• [S4] https://hn.algolia.com/api/v1/items/50381687
• 配图 1：来源：GitHub（图片署名见原文） · 图片出处
• 配图 2：来源：Rivet（图片署名见原文） · 图片出处
• 配图 3：来源：Rivet（图片署名见原文） · 图片出处