把 100 个 agent 同时派出去干活，然后让它们等一个 3 天后才有结果的工具调用——排队编译、人工审批、隔夜的 PR 都行。等完这 3 天回头看内存账单：如果这 100 个 agent 用最传统的「常驻进程」方式跑，按社区实测口径每实例空闲约 700MB 算，它们全程占着约 70GB 内存；如果换成 AWS 刚开源的挂起式运行时 Infinity，按其官方基准的每 agent 约 100KB 算，同样这批等待只占约 10MB。70GB 对 10MB，四个数量级的差距【推算·二手输入，两口径硬件底座与负载假设完全不同，仅供量级对照】。这不是玄学，是「等」这件事的定价问题：agent 的贵，不在思考，在等待。
2026 年 10 月下旬，两条重量级发布把这件事摆上了台面：10 月 23 日 AWS 开源挂起式 agent 运行时 Infinity；10 月 22 日 Google 在 AGNTCon + MCPCon 官宣 Agent Compute Engine（ACE）。加上一直在场的「常驻进程」基线，和按秒计费的云端沙盒 E2B，「agent 等工具时怎么安放」第一次有了四条成型的路线。先把分工说清：本文的标尺只有一把——「等待的经济学」，即等待时占多少内存、恢复有多快、什么规模下划算。至于隔离强度选型，那是另一把尺子，看本站 8 月 19 日的 Agent 隔离方案五强横评（Firecracker / CubeSandbox / agent-sandbox / E2B / Daytona）；Infinity 的单体深评看同批的 Infinity 开源资源篇；本机沙箱装机实操看同批的 Claude Code sandbox-runtime SOP。本文为多信源整理与官方原文实抓，非亲自部署实测，不构成采购建议。
一、挂起派：AWS Infinity，把 agent 变成纯数据
先看发布事实【官方·AWS Open Source Blog】：2026 年 10 月 23 日，AWS 发布 Infinity，它是 AWS 与 UC Berkeley 合作项目 Hydro 之作，Apache-2.0 开源，官方明确定位为早期研究发布（early research release），不是 GA 服务、无 SLA。仓库在 GitHub：github.com/hydro-project/infinity，README 一句话定位是「An agent runtime and tool protocol for principled agent concurrency」，并自比「Infinity does for agents what async did for threads」——async 之于线程，Infinity 之于 agent。
机制上，agent 是一个 stackless 协程，tool call 就是挂起点。执行以「切片（slice）」为单位：载入历史、做一次模型补全、持久化输出、至多派发一个工具调用、切片结束；工具结果到达输入队列后开启下一片。两个切片之间，agent 就是纯数据。官方原话：「Between turns, an agent is pure data, just its conversation history with no task, no stack, and no open connection」——挂起内存接近其历史的大小【官方】。
关键数字是这组【官方·博客基准】：挂起占用约 100KB/agent。但必须带定语：这是 80,000 agent × 20 轮、共 320 万次补全的模拟模型基准（单线程 AMD EPYC 9R14、in-memory stores、每轮补全流式输出约 1.2KB）测出来的。官方顺带给出推算：按此基准，8GB 内存（树莓派 5 的内存口径）可容纳约 75,000 个并发挂起 agent——注意这是从基准线性外推的推算值，未经实测【官方·推算】。真实的长上下文 agent 挂起体积约等于其历史大小，会显著大于 100KB。
它配套的 serverless 参考架构值得照抄【官方】：输入队列用 SQS FIFO（每 thread 一个 MessageGroupId），Lambda 每次投递跑一个切片即退出，Aurora DSQL 存对话历史，DynamoDB 存去重状态，计时器用 SQS delivery delays 加 EventBridge Scheduler，仓库附 CDK constructs 一键开资源。落到本文的主题上：等 3 天的 CI 期间零计算消耗——Lambda 早就退出了，你只为真正的执行付费，等待本身不花一分钱计算成本。
短板要念全：研究发布、无 SLA，官方自己列了开放问题（交错事件推理、调度策略、agent 树 compaction、事件 provenance）；更要紧的是，它对隔离强度没有任何主张——挂起是调度层面的省钱术，不是安全边界【官方未主张】。
二、隔离派：Google ACE，每个 agent 一台微 VM
2026 年 10 月 22 日，Google 在 AGNTCon + MCPCon 官宣 Agent Compute Engine【官方·Google Cloud Blog】。每个 agent 会话独享一个 single-tenant、memory-safe 的硬件隔离 microVM（Cloud Hypervisor），自带专用 guest kernel 与 root 权限。zero-secrets 是它的招牌设计：VM 内存与磁盘不留任何持久密钥、OAuth refresh token 或 service account key，每台 VM 只拿一张会话级短时效 SPIFFE 证书；用户的长期凭据完全不出宿主机，由 Agent Gateway 校验会话 mTLS 身份与出口策略后动态换入——官方的设计目标是「被攻破的沙箱里没有值得偷的东西」。信任锚定在 Titanium IPU：块存储挂载由 IPU 用 instance-bound 密码学授权中介，跨节点/租户边界不可挂载读写【官方·deep dive】。
经济性上有两手【官方】：一是 copy-on-write 内存共享，多个 agent 复用同一个操作系统模板；二是空闲处理——agent 进入思考或等人时，宿主将其转 idle 态并快速 checkpoint，需要时从快照恢复。
这里有一个本文最想提醒的归属问题：流传甚广的「sustained 500 agent activations per second with under 500ms resume latency in a 200,000-agent benchmark test」，在官宣原文里的主体是同场开源的 GKE K8s 执行运行时 Agent Substrate（仓库 github.com/agent-substrate/substrate），不是 ACE 托管服务本体【官方】。ACE 本体的启动时间、密度、定价均未公布；可用性是「未来数月开放 preview」，SLA 未公布【官方】。第三方解读也明确：这些数字来自 Google 及其合作伙伴，未经独立测量【二手·aipolix】。
短板：未 GA、无定价、无 SLA，今天选不了只能等 preview；20 万 agent 测试的方法论未公开；架构重度绑定 Google 云的自有硬件（Titan 芯片与 Titanium IPU），多云玩家的适配成本存疑。
三、常驻派：Claude Code + Docker，诚实声明没有官方基准
先说结论级声明：这一方没有官方并发基准，本文引用的全部是社区口径【二手】。机制基线倒有官方定性——AWS 博客对立项动机的描述：「Most agent harnesses run the agent loop as a sequence of blocking steps... While the agent waits, it holds a process and its memory, and it cannot respond to events.」等 20 分钟的 build、等隔夜审批、等下一条 PR，进程与内存全程占位【官方·AWS 博客定性】。agent 本质是 I/O 密集负载：大部分时间在等 API 响应、命令结果、文件读写，CPU 占用低，内存占位是硬成本【二手】。
社区口径有多重【二手】：CLI 每实例空闲 RSS 约 700MB（GitHub issue #61425，双会话约 1.4GiB）；日常空闲 300-600MB，复杂任务（多进程加 MCP 工具）峰值超 1.5GB；极端案例有单会话从约 900MB 涨到 12.6GB、另一会话 29.9GB 被 OOM killer 击杀；最惊人的是桌面版积累案例——183 个空闲会话进程树加约 2,600 个 MCP sidecar，合计约 160GB RSS，MCP 的成本是「N 会话 × M 服务器」的乘法放大。官方锚点只有两条，且都经第三方转述、引用前需复核原页【官方·转述链】：系统要求至少 4GB RAM；会话 JS 堆过 2.5GB 触发 critical memory warning。修复轨迹倒是说明上限在收敛：2.1.208 修多个长会话泄漏，2.1.238 修无界内存增长【二手·changelog 转述】。
常驻何时反而简单？当 agent 数量是个位数到几十、会话即开即用、MCP 服务器常驻复用时：不需要消息队列、持久化存储、去重状态这些基础设施，运维面最小。社区没有「常驻对挂起」成本交叉点的公开测算【二手·定性】。另外记住隔离上限：容器只是命名空间级隔离、共享内核，防「代码写坏弄脏环境」够用，防「代码被指示主动越权」不够——这是本站 8-19 旧文的定性，也是常驻派隔离上限的依据。
四、云端参照：E2B，把等待也租出去
E2B 自我定位是「The AI Agent Cloud」，pricing 页自述已启动 1B+ 个沙盒；每个 sandbox 独享 Firecracker microVM、独立内核，官方 security 页承诺「never share a kernel, a filesystem, or memory with another customer's sandboxes」【官方】。它对本文标尺的回答最直白：挂起与隔离由厂商实现，用户按沙箱运行秒数付费，暂停与已杀沙箱不计费——等待免费，运行才计费。
费率与套餐【官方·pricing 页 2026-10-26 实抓】：vCPU $0.000014/秒、RAM $0.0000045/GiB·秒，按分配额计而非实际用量；官方 FAQ 算例：默认规格跑 1 小时约 $0.109。套餐分档：Hobby 免费（会话不超过 1 小时、20 并发）；Pro $150/月含 100 并发（会话不超过 24 小时）；Enterprise $3,000/月起，主打多日持久会话与数万并发沙箱。
一处官方口径矛盾，并列不裁决【官方两页对照】：pricing 页把 4GiB 标为默认内存档，docs FAQ 的算例却用「2 vCPU + 512MiB」当默认沙箱——两处不一致，引用时并列写明出处。暂停/恢复速度：每 GiB 暂停约 4 秒、恢复约 1 秒（官方 persistence 文档口径，经二手转述）；冷启动数字未公布。代价照旧：数据与代码出域，8-19 旧文对 E2B 的定性至今成立——最快上线路径，代价是出域。
五、总对比表
| 路线 | 等待时占内存 | 恢复延迟 | 隔离强度 | 运维复杂度 | 适用规模 |
|---|---|---|---|---|---|
| 挂起派 Infinity | 约 100KB/agent（模拟模型基准）【官方；真实长上下文未公布】 | 由队列与持久化存储决定，未公布【无公开口径】 | 无主张：调度隔离非安全边界【官方未主张】 | 高：自建 SQS/Lambda/DSQL/DynamoDB【官方参考架构】 | 数万级挂起（官方推算 75k/8GB，未实测）【官方·推算】 |
| 隔离派 Google ACE | 空闲即 checkpoint 释放宿主内存；单 VM 数字未公布【无公开口径】 | <500ms 与 20 万 agent 测试的主体是 Agent Substrate【官方】；ACE 本体未公布【无公开口径】 | 最强：硬件隔离 microVM + zero-secrets + IPU 锚定【官方】 | 低-中：托管服务但未 GA、无定价【官方】 | 官方自报 20 万 agent 测试，方法论未公开【官方自报】 |
| 常驻派 Claude Code + Docker | 约 700MB RSS/实例空闲【二手】；官方最低 4GB RAM【官方·转述链】 | 进程已在内存，即时【推算】 | 容器=命名空间共享内核【站内旧文定性】 | 最低：无额外基础设施【二手定性】 | 个位数到数十并发【二手定性】 |
| 云端 E2B | 按量租：暂停不计费【官方】 | 恢复约 1s、暂停约 4s/GiB【二手转述官方】；冷启动未公布【无公开口径】 | Firecracker microVM 独立内核【官方】 | 最低：注册即用；代价=数据出域【官方】 | 数万并发沙箱（Enterprise 档）【官方】 |
六、量级推算：70GB 对 10MB 是怎么来的
把四条路线放上同一把尺子，目前只能做量级推算【推算·二手输入】：按每实例约 700MB 的社区口径，100 个常驻会话约 70GB 内存；按 Infinity 官方基准约 100KB/agent，同样 100 个挂起态 agent 约 10MB——70GB 对 10MB，约 7,000 倍。两个口径的硬件底座与负载假设完全不同，仅供量级对照，不构成结论。E2B 侧同样可以立框架但给不出交叉点：按量租无固定投入、成本随用量线性走；自建（Infinity / Agent Substrate）摊销基础设施与运维人力——两者的 TCO 交叉点没有任何公开信源测算过，本文不编数字【推论框架，交叉点无公开口径】。
七、选型结论：什么规模选什么
- 个位数到几十个 agent：常驻就好。 运维面最小，内存问题在 changelog 里慢慢收敛，先干活要紧；数量没到，别为架构焦虑买单。
- 数百到数万个挂起 agent、且有基础设施团队：Infinity 路线。 接受研究发布定位与自建 serverless 栈的复杂度，把等待变成一行队列消息。
- 要强隔离且在 Google 云上：盯住 ACE 的 preview，等不及可以先研究已开源的 Agent Substrate（GKE）。
- 不想运维、接受数据出域、负载突发：E2B 按秒租，暂停不计费，Hobby 与 Pro 档足够试错。
- 通用纪律：先用威胁模型定隔离强度（8-19 旧文那把尺子），再按等待的经济学定安放方式（本文这把尺子），两把尺子别混用。
常见问题
**Q1：**挂起态 agent 真的都只要 100KB 吗？ A1：不是。官方基准用模拟模型、每轮补全约 1.2KB × 20 轮，历史本身很短；官方明言挂起内存「接近其历史大小」，长上下文真实 agent 的挂起体积会显著大于 100KB。结论只能写「基准条件下约 100KB/agent」【官方口径自限定】。
**Q2：**20 万 agent、恢复小于 500ms 是 ACE 的成绩吗？ A2：不是。官宣原文的主体是同场开源的 GKE 执行运行时 Agent Substrate；ACE 托管本体的启动时间、密度、定价均未公布。第三方摘要把它泛指到整个平台，属于转述走样【官方原文为准】。
**Q3：**常驻派真的一个官方数字都没有吗？ A3：没有官方并发基准。可引的只有官方最低 4GB RAM 与 2.5GB 堆告警阈值，且均经第三方转述、引用前建议复核原页；其余全是社区 issue 口径，异常案例达 12.6GB 至 29.9GB【二手】。
**Q4：**E2B 的默认沙箱到底是 4GiB 还是 512MiB？ A4：官方两页不一致：pricing 页标 4GiB 为 Default，docs FAQ 算例用 512MiB。本文并列不裁决。实际影响是成本估算可能差数倍——动手前先在自己账号里跑一遍账单【官方两页对照】。
**Q5：**这四条路线可以混用吗？ A5：可以且常见：交互式会话常驻，长等待任务挂起，不可信代码丢云端沙盒按秒租。要警惕的是用同一把尺子比四条路线——隔离强度看 8-19 旧文，等待的经济学看本文，先定隔离，再定安放。
延伸阅读
- Agent 隔离方案五强横评：8-19 旧文，隔离强度选型的另一把尺子，Firecracker / CubeSandbox / agent-sandbox / E2B / Daytona 五强逐个拆。
- AWS Infinity 开源资源篇：同批开源篇，拆「8GB 为什么能装 7.5 万个挂起 agent」。
- Claude Code sandbox-runtime 装机 SOP：同批实操篇，本机沙箱装机的手把手流程。
参考来源
- AWS Open Source Blog：Introducing Infinity: a runtime for extreme agent concurrency（2026-10-23，作者 Shadaj Laddad）：https://aws.amazon.com/blogs/opensource/introducing-infinity-a-runtime-for-extreme-agent-concurrency/
- GitHub hydro-project/infinity README（最后提交 2026-10-23）：https://github.com/hydro-project/infinity
- Google Cloud Blog：Introducing Agent Compute Engine and expanding agent governance（2026-10-22）；Inside Agent Compute Engine（deep dive）
- GitHub agent-substrate/substrate：https://github.com/agent-substrate/substrate
- E2B pricing 页（2026-10-26 实抓）：https://e2b.dev/pricing ；E2B 计费 FAQ：https://www.e2b.dev/docs/faq/calculate-sandbox-price
- 社区口径：Claude Code 内存 issue #61425 与桌面版 183 会话约 160GB RSS 案例（claudeissues.com 转载页）；jtti VPS 选型文；wpnews.pro 会话内存实测文
- 本站：Agent 隔离方案五强横评（2026-08-19）
本文基于公开资料整理与官方原文实抓（数字截至 2026-10-26），为代表性梳理而非亲自部署实测；Infinity 与 ACE 的基准数字均为厂商自报、未经独立测量；不构成采购建议。