Agent高并发架构：从容器到isolate与Durable Objects的轻量隔离实践

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 替代容器”，而是分层：

Agent 的绝大多数场景——对话、工具调用编排、状态管理——都落在第一层。只有真正需要跑用户上传代码的“代码解释器”类功能，才需要下沉到第二层。把这两层混为一谈，是很多 Agent 架构成本失控的根源。

4. Durable Objects：Agent 状态该放在哪

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 做试点，跑通了再逐步扩大。我见过太多团队想一步到位重构，结果卡在某个边缘场景上，进退两难。小步快跑，用真实数据验证成本收益，比任何架构图都靠谱。