一个 agent 常驻要烧多少内存？Rivet 的答案是 72KB

把 agent 做成长期在线的服务，最贵的不是模型调用，而是「每个 agent 占一个沙箱或容器」的常驻开销。11 月 5 日登上 Hacker News 首页的 Rivet（6,624 星，Apache 2.0，YC W23）把这笔记账重新算了一遍：按仓库自述口径，每个 Actor 只要 72KB 内存，多个 Actor 共享一个节点进程，一台服务器能放几十万个；冷启动 p99 4.99 毫秒，无镜像拉取、无虚拟机启动。

它的模型是 Actor：每个 Actor 是带内存状态、SQLite 数据库、WebSocket 实时通道与调度的长驻进程，按 key 寻址，一个 agent、一个会话、一个用户、一个租户各建一个。对照它在 README 里给的参照系：沙箱方案每个 agent 要 512MiB 内存、1.70 秒启动且多数时间空转，Rivet 的 Actor 跑在共享进程里，空闲即休眠、休眠不花钱，下次请求唤醒且状态不丢。状态持久化的做法很有想象空间：SQLite 由 S3 支撑，按 SSD 速度读写（自述写入 p99 1.07 毫秒、读取 p99 1.36 毫秒，成本约为复制型 SSD 的十分之一）。

三件套构成整个产品：Actors（长驻进程加状态加实时加调度）、Agents（每个 agent 一个持久进程，记忆扛得住重启）、Workflows（持久工作流）。部署的依赖清单短得惊人：只需要一个对象存储桶，不用 Postgres、不用 FoundationDB、不用 NATS，控制平面实例通过桶互相发现；S3、GCS、Azure Blob、MinIO、Cloudflare R2、Hetzner 都行，单机试用还能用本地文件后端。跑在原生 Node.js 与 Bun 上，无自定义运行时；自托管方案从 Docker Compose 到 Kubernetes 到 Railway 都有，也有 Rivet Cloud 全托管与 BYOC（控制平面进你自己的 VPC）。

和本站写过的 Orkas、Codync 区分一下：那两篇讲「一队 agent 怎么协作」，Rivet 讲的是「一个 agent 的运行时底座」，解决常驻、便宜、可恢复这三件事。泼冷水的部分照例要有：72KB 与毫秒级数字全是官方自测口径，S3 当数据库的延迟与一致性取舍要自己压测；「一个桶」是真省事，但控制平面本身仍要运维，不是零运维。想试的话，给 coding agent 的启动提示词都备好了：npx skills add rivet-dev/skills。