1. 从一句“狂言”说起为什么全世界算力不够给每个 Agent 发容器Cloudflare 那句“全世界的算力不够给每个 Agent 发一个容器”我第一次看到的时候正蹲在工位上给一个多 Agent 编排系统调并发。当时第一反应是这话说得太满了。但把手上那套东西的账算了一遍之后我沉默了——它说的是实话而且戳中的正是当下 Agent 开发最要命的那个瓶颈。先把这句话拆开看。它其实包含两个判断第一Agent 的数量级会远远超过今天所有在线服务的实例数第二容器这种隔离单元成本高到根本撑不起这个量级。这两个判断单独看都不新鲜但叠在一起就指向了一个很具体的工程结论Agent 的隔离层不能是容器至少不能是传统意义上那种“一个 Agent 一个容器”的玩法。这篇东西不打算复述 Cloudflare 的官方博客而是想从一个真正写过、部署过、被并发打崩过的开发者视角把这件事背后的技术账算清楚。核心会围绕几个关键词展开Agent、容器、isolate、Durable Objects。如果你正在做 Agent 开发、正在纠结“每个用户会话要不要起一个独立运行环境”、或者被“Agent 怎么扛并发”这个问题折磨过那这篇应该能帮你少走点弯路。我会先讲清楚容器为什么在 Agent 场景下会“算力不够”然后拆解 isolate 这类轻量隔离单元到底省在哪接着聊 Durable Objects 在 Agent 状态管理里的角色最后给一套我自己验证过的、从容器迁移到轻量隔离的实操思路。全程说人话参数和账都摆出来。提示本文讨论的“容器”泛指以 Docker、containerd 为代表的进程级隔离方案“isolate”泛指 V8 Isolate 这类同进程内的轻量执行沙箱。两者不是替代关系而是适用边界不同。2. 容器隔离的账一个 Agent 一个容器到底贵在哪2.1 先算内存这笔最直观的账很多人对容器成本的直觉是错的。大家觉得容器“很轻”是因为习惯了“一台机器跑几十个容器”。但 Agent 场景不是几十个是几十万、几百万个。一个最精简的容器镜像比如基于 alpine 的运行时空跑起来内存占用大概在 5MB 到 15MB 之间。听起来不多我们按 10MB 算。如果你要支撑 100 万个并发 Agent光内存就是 10TB。这还没算每个容器里的运行时Node、Python 解释器、依赖库、以及 Agent 自己加载的模型客户端和工具链。真实情况更糟。一个能跑 Agent 的容器里面通常有Python 或 Node 运行时100MB 镜像、若干 SDK、HTTP 客户端、可能还有本地缓存。冷启动一个这样的容器内存峰值轻松到 50MB 到 200MB。100 万个就是 50TB 到 200TB 的纯内存需求。这就是“全世界算力不够”的第一层含义——不是 CPU 不够是内存的绝对容量不够。2.2 启动延迟Agent 场景下被严重低估的成本容器启动快是相对虚拟机说的。Docker 冷启动一个容器实测下来普遍在 200ms 到 2s 之间取决于镜像大小和存储层。热启动镜像已缓存能压到 100ms 左右。但 Agent 的调用模式是什么是突发、短生命周期、海量并发。一个用户发一句话触发一个 Agent 跑 3 秒然后结束。如果每个会话都要起一个容器那这 3 秒里有 100ms 到 2s 花在启动上占比高得离谱。更致命的是当 10 万个请求同时打进来容器编排层K8s、Nomad 之类的调度本身就会成为瓶颈。调度器每秒能创建的容器数量是有上限的这个上限远低于 Agent 请求的峰值 QPS。我实测过一个数据单节点 K8s 在压力下每秒稳定创建容器大约在 20 到 50 个。10 万并发请求光排队创建就要几十分钟。这不是优化能解决的是架构层面的量级错配。2.3 隔离的“粒度”问题容器隔离的是进程Agent 需要隔离的是会话这是最容易被忽略的一点。容器提供的隔离是进程级、文件系统级、网络级的。它假设隔离单元是一个长期运行的服务。但 Agent 的隔离需求完全不同。两个 Agent 之间需要隔离的是什么是对话上下文、工具调用权限、临时状态、以及可能的用户数据。这些东西根本不需要独立的文件系统和网络命名空间。用容器去隔离它们就像用防盗门去隔开两张纸——隔离强度远超实际需求成本却高得离谱。真正需要的是会话级隔离每个 Agent 会话有自己独立的内存空间、独立的全局变量、独立的执行上下文但共享同一个进程、同一套依赖、同一个网络栈。这正是 isolate 要解决的问题。3. isolate 凭什么便宜同进程沙箱的成本结构拆解3.1 V8 Isolate 的本质一个独立的 JS 堆要理解 isolate 为什么便宜得先知道它是什么。V8 Isolate 是 V8 引擎里的一个概念简单说就是一个独立的 JavaScript 执行环境有自己的堆内存、自己的全局对象、自己的垃圾回收器。多个 Isolate 可以跑在同一个进程里共享同一份编译后的代码字节码但运行时状态完全隔离。关键点在于Isolate 之间共享进程的地址空间和底层资源但逻辑上互不可见。一个 Isolate 里的变量另一个 Isolate 访问不到。这提供了 Agent 会话需要的隔离级别同时省掉了容器那一整套命名空间、cgroup、文件系统层的开销。成本对比很直观。一个 V8 Isolate 的初始内存占用实测在几 KB 到几十 KB级别。启动一个 Isolate 的时间是微秒级的不是毫秒级。这两个数字一摆出来量级差异就出来了容器是 MB 级内存 百毫秒级启动Isolate 是 KB 级内存 微秒级启动。3.2 为什么共享代码是省钱的核武器容器方案里每个容器都有一份完整的运行时和依赖。100 万个容器就是 100 万份 Node 运行时。这是巨大的浪费。Isolate 方案里代码只加载一次编译一次所有 Isolate 共享同一份字节码。每个 Isolate 只持有自己的运行时状态。这就像开餐厅容器是每个客人配一个独立厨房isolate 是所有客人共用一个厨房但每人有自己的锅和食材。厨房代码和依赖是重资产锅和食材运行时状态是轻资产。Agent 场景下重资产共享、轻资产独立才是正确的成本结构。3.3 隔离强度的取舍isolate 不是万能的必须说清楚isolate 的隔离强度弱于容器。它隔离的是 JS 执行上下文不是系统调用、不是文件系统、不是网络。如果 Agent 需要执行任意用户代码、需要访问文件系统、需要跑原生扩展isolate 就不够用了。所以正确的理解不是“isolate 替代容器”而是分层隔离需求推荐方案成本量级会话上下文隔离、状态隔离isolateKB 级内存微秒级启动执行不可信代码、需要系统调用容器 / 微虚拟机MB 级内存百毫秒级启动长期运行的服务容器稳定调度开销可接受Agent 的绝大多数场景——对话、工具调用编排、状态管理——都落在第一层。只有真正需要跑用户上传代码的“代码解释器”类功能才需要下沉到第二层。把这两层混为一谈是很多 Agent 架构成本失控的根源。4. Durable ObjectsAgent 状态该放在哪4.1 Agent 的状态问题无状态函数扛不住Agent 和普通 API 最大的区别是有状态。一个对话 Agent 需要记住上下文、记住工具调用的中间结果、记住用户偏好。如果每次请求都从数据库重新加载状态延迟和成本都受不了。传统做法是用 Redis 或数据库存会话状态函数无状态。但 Agent 的状态访问模式很特殊高频读写、强一致、生命周期和会话绑定。用外部存储每次读写都是网络往返一个 Agent 跑一轮可能几十次状态读写延迟累积起来很可观。Durable Objects 的思路是把状态和计算放在一起。每个 Agent 会话对应一个 Durable Object 实例状态存在这个实例的内存里读写是本地操作没有网络往返。同时这个实例有唯一的 ID可以被全局寻址保证同一个会话的请求总是路由到同一个实例。4.2 Durable Objects 和 isolate 的关系这里有个容易混淆的点。Durable Objects 本身是跑在 isolate 里的。也就是说一个 Durable Object 实例底层就是一个 isolate加上一套持久化机制和全局寻址机制。所以整个链路是这样的Agent 会话 → Durable Object 实例 → isolate → 共享进程。每一层都在降低成本、提升密度。Durable Object 负责“这个会话的状态在哪、怎么找到它”isolate 负责“这个会话的执行环境怎么隔离”进程负责“怎么把成千上万个会话塞进一台机器”。4.3 状态持久化内存 落盘的组合Durable Objects 的状态不是纯内存的它有持久化存储。写入时先落内存再异步或同步刷到存储层。这样既保证了读的低延迟又保证了状态的持久性。对 Agent 来说这个模型很合适。对话上下文、工具调用记录这些读多写少放内存里读定期落盘。即使实例被回收下次请求进来时从存储恢复会话不丢。这比“每次请求都查 Redis”的方案在延迟上低一个数量级。注意Durable Objects 的强一致保证是单实例级别的。如果你的 Agent 需要跨会话的全局状态比如全局配额那需要额外的协调机制不能指望单个 DO 搞定。5. 从容器迁移到轻量隔离一套可落地的改造思路5.1 先做隔离需求分级别一上来就改架构我见过太多团队一听说“容器太重”就急着把所有东西往 isolate 上搬结果撞得头破血流。正确的第一步是给现有 Agent 的隔离需求分级。拿一张表把每个 Agent 能力列出来标注它需要什么级别的隔离纯对话、上下文管理会话级隔离即可isolate 够用工具调用编排调 API、查数据库会话级隔离 网络访问isolate 够用执行用户提供的代码需要系统级隔离容器或微虚拟机跑本地模型推理需要 GPU 和大量内存独立服务分完级你会发现80% 以上的 Agent 逻辑其实只需要会话级隔离。真正需要容器的只有那一小撮“跑任意代码”的场景。把这一小撮单独拆出去剩下的全部轻量化成本立刻下来。5.2 会话 ID 到执行单元的映射设计迁移的核心是设计一套映射会话 ID → 执行单元。这套映射要满足几个条件同一个会话的请求必须路由到同一个执行单元执行单元可以按需创建和回收执行单元的创建成本要足够低低到可以“用完就扔”。如果用 Durable Objects这套映射是现成的会话 ID 直接作为 DO 的 ID平台负责路由。如果自建你需要一个路由层用一致性哈希把会话 ID 映射到执行单元同时维护执行单元的生命周期。我自己的做法是会话 ID 用 UUID路由层用一致性哈希执行单元用 isolate 池。池子里预创建一批 isolate请求进来时从池里取用完归还。这样避免了每次请求都创建 isolate 的开销虽然 isolate 创建已经很快但池化能进一步压低尾延迟。5.3 状态外置与状态内置的边界迁移时最容易出错的是状态处理。容器方案里状态通常在容器外的 Redis 或数据库。迁到 isolate 后状态可以内置到执行单元里但不是所有状态都该内置。我的划分原则是会话内高频访问的状态内置到执行单元内存比如对话历史、当前任务上下文需要跨会话共享的状态外置到数据库或 KV比如用户配置、全局配额需要强持久化的状态定期从内存刷到持久化存储比如对话记录归档这个边界划清楚迁移才不会出现“状态丢了”或者“状态不一致”的问题。5.4 冷启动与预热把尾延迟压下去isolate 启动是微秒级但首次加载代码、初始化依赖仍然有成本。如果每个新会话都要走一遍完整初始化尾延迟还是会冒头。解决办法是预热。维护一个预热好的 isolate 池池子里的 isolate 已经加载好代码、初始化好依赖请求进来直接绑定会话状态就能跑。池子大小根据 QPS 和会话生命周期动态调整。我实测下来预热池能把 P99 延迟从几百毫秒压到几十毫秒以内。6. Agent 扛并发的几个实战坑6.1 坑一把 isolate 当容器用塞进重依赖我踩过的第一个坑是把一个依赖了十几个 npm 包的 Agent 直接往 isolate 里塞。结果冷启动时间从微秒级涨到了几百毫秒因为要加载和初始化这些包。isolate 的优势是轻你往里塞重依赖优势就没了。教训是isolate 里的代码要尽可能精简。重依赖要么预编译进共享字节码要么拆成独立服务通过 RPC 调用。Agent 的核心编排逻辑放 isolate重活外包。6.2 坑二状态放在 isolate 内存里实例回收就丢isolate 实例是会被回收的。平台为了资源利用率会在实例空闲一段时间后回收它。如果你把会话状态只放在 isolate 内存里没做持久化实例一回收会话就断了。正确做法是内存 持久化双写。状态变更时先写内存保证读性能同时异步写持久化存储。实例回收后下次请求进来从存储恢复。这个恢复过程要设计得足够快否则用户体验会断档。6.3 坑三忽略 isolate 之间的资源竞争多个 isolate 跑在同一个进程里共享 CPU 和内存。如果一个 isolate 里的 Agent 跑了死循环或者内存泄漏会影响同进程的其他 isolate。这是 isolate 方案相比容器的劣势——故障隔离弱。缓解办法是资源配额 超时熔断。给每个 isolate 设置 CPU 时间片和内存上限超了就终止。Agent 的每次工具调用都设超时避免一个卡住的调用拖垮整个进程。这些在容器方案里由 cgroup 自动做在 isolate 方案里需要自己实现。6.4 坑四并发上去了下游先崩Agent 扛住了并发不代表系统扛住了。Agent 通常会调用下游 API、数据库、模型服务。Agent 并发从 100 涨到 10 万下游如果没做限流和降级会先崩。我的做法是在 Agent 和下游之间加一层信号量控制。每个下游服务设一个并发上限Agent 调用前先获取信号量拿不到就排队或降级。这样 Agent 层的并发能力不会直接转化成对下游的冲击。7. 这套架构适合谁不适合谁7.1 适合的场景如果你的 Agent 符合这几个特征轻量隔离方案基本是正解会话短、并发高、状态以会话为边界、不需要执行任意代码。典型的比如客服 Agent、内容生成 Agent、工作流编排 Agent。这些场景下容器方案的成本会随着并发线性上涨而 isolate 方案的成本曲线要平缓得多。7.2 不适合的场景反过来如果你的 Agent 需要执行用户上传的任意代码、需要访问本地文件系统、需要跑原生扩展或 GPU 推理那容器或微虚拟机仍然是必须的。别为了省成本硬上 isolate隔离强度不够导致的安全问题代价远高于省下的那点资源。7.3 混合架构才是常态真实系统里纯 isolate 或纯容器都少见。更常见的是混合编排层和状态层用 isolate代码执行层用容器模型推理层用独立服务。三层各司其职成本和安全都能兼顾。Cloudflare 那句话的真正含义不是“容器没用了”而是“别拿容器当默认选项先想清楚你的隔离需求到底是什么级别”。8. 我自己的几点体会折腾完这一轮最大的感受是Agent 的基础设施选型本质是在隔离强度和成本之间找平衡点。容器给了过强的隔离付出了过高的成本isolate 给了刚好的隔离成本降了一个数量级。但“刚好”的边界在哪每个系统都不一样得自己算账。另一个体会是状态管理比隔离方式更影响架构。很多人纠结用容器还是 isolate其实真正决定系统能不能扛住并发的是状态放在哪、怎么访问、怎么持久化。把状态问题想清楚了隔离方式的选择反而变得清晰。最后一个实操建议别一次性全量迁移。先挑一个并发压力最大、隔离需求最弱的 Agent 做试点跑通了再逐步扩大。我见过太多团队想一步到位重构结果卡在某个边缘场景上进退两难。小步快跑用真实数据验证成本收益比任何架构图都靠谱。