先说结论

2026年9月23日上午，云栖大会「构建 Agent Infra——Agent Sandbox 重磅发布与技术架构揭秘」论坛（闭幕报幕用的别名是「容器和沙箱分论坛」，两者为同一场）用五场演讲加一场圆桌回答了一个问题：当 Agent 从 Demo 走进生产，基础设施到底缺什么。开场讲者、阿里云容器与沙箱研发负责人易立给出的答案是把沙箱升级为一种新算力形态——现场公布的数字是每分钟创建 10 万个沙箱、单 Region 百万级在线、冷启动 P99 小于 180 毫秒、热启动小于 20 毫秒、深休眠唤醒 P99 小于 600 毫秒、存算优化后 TCO 降低 70%（嘉宾口径，与阿里云官网同期商业化公告互证）。但这场论坛真正值得记下来的不是发布数字，而是两个客户（前程无忧、金山办公）和一位芯片厂商（AMD）共同勾勒的约束条件：Agent 生产化的瓶颈已经不是模型能力，而是运行环境能否安全隔离、算力能否随需伸缩、成本能否随业务收敛。这三件事在传统容器时代各有解法，叠到一起却构成一个「不可能三角」——金山办公的宾哲原话是，安全、稳定、成本三者很难同时兼得，他们用工程手段把三角形的每条边拉到「够用而且可控」。

需要说明的一处覆盖缺口：议程第二项「Agent Sandbox 重磅发布及技术解析」（杨秋弟、杨皓然）不在本次转写素材中（后一位讲者开场提到「产品和技术大佬们刚分享过」证实该场在现场发生），本文不覆盖该场细节；其余议程讲者与现场逐场核对相符。

一、为什么是沙箱：从四个计算环节到第四种算力

易立开场把时间轴拉开：过去十年云原生解决了「应用如何在云上高效执行」，而 Agent 正在重新定义应用本身。他把模型能力的计算拆成四个环节——预训练拓展模型、后训练（尤其强化学习）拓展经验、推理时思考、Agent Loop 扩展行动——并称计算重心正从预训练一路外溢到执行过程。他引用的统计是「2020 年以来前沿模型预训练规模每隔约 5.2 个月翻倍」（转写将来源识别为「IPAC AI」，应为 Epoch AI；外部口径为约 5-6 个月，嘉宾数字属合理转述），还提到「昨天听到更大规模的千问四将发布」（嘉宾称，未经核实）。

落到基础设施，四个环节指向同一个结论：强化学习需要海量并行的安全沙箱供模型试错，Agent 执行需要强隔离、高弹性、有状态、低成本的运行环境。易立由此宣布 Agent Sandbox 正式发布，并给出四个需求定义——强隔离（动态执行生成代码、访问外部工具，需端到端隔离）、高弹性（海量沙箱瞬时就绪）、有状态（多轮执行保留文件与上下文）、低成本（Agent 大量时间在等待，需休眠唤醒降费）。产品提供两种接入：面向开发者的 E2B 兼容 API（应用可无缝迁移上云）与面向企业平台的 Kubernetes 原生 API，共用同一算力底座（生命周期、模板、会话管理，Agent Identity 身份认证，Agentic FS/Bucket 文件卷管理）。E2B 是开源沙箱基础设施（外部核实其在 GitHub 有 1.3 万以上 star，官方称沙箱为约 150 毫秒级启动的小型 VM），论坛上多位讲者把它称为 Agent 沙箱领域「公认的事实标准」——这背后是一次生态卡位：兼容既有开发者习惯，比功能列表更能构筑护城河。

底座层面，易立还盘点了 ACK 的配套升级：单集群规模从 5 万节点提到 10 万、在线沙箱规模 20 万；真武 M890 超节点的拓扑感知调度让客户推理吞吐提升 40%（嘉宾称）；推理网关按 KV Cache 命中率路由请求，真实客户场景节省 50% 计算资源；冷启动优化让千问3-235B 的推理引擎启动时间从 13 分钟降到 3 秒。这些数字全部为嘉宾口径，但其指向的机制是一致的：让昂贵算力的每一份都花在有效计算上。

二、休眠唤醒经济学：Agent 的成本账和微服务完全不同

阿里云的邓彬（转写识别为「邓斌」，按议程校正）从业务侧把「为什么必须新算力形态」讲得最直白。他给出一个算术：假如企业有一万名员工，每人都有一只云端数字助手（现场以 OpenClaw 的中文昵称「小龙虾」代指这类个人 Agent），每只 2 核 4G，那就是 2 万核 4 万 G 的常驻负载——「成本是无法接受的」。而 Agent 的实际负载形状是：初期没有请求、负载极低，长时间在等模型推理或等人交互。传统容器靠超卖摊薄成本，但超卖解决不了「一万个几乎空转的实例」。

解法是把计费颗粒度对齐负载形状：无请求时自动休眠，CPU 和内存全部释放，只收磁盘费用；请求来了再唤醒，唤醒时间压到 600 毫秒内，用户「没有特别大的感知」。罗晶（转写自述名有误，按议程校正）在容器版产品分享中给出对应数字：自动休眠唤醒加灵活存储策略，最多可让算力闲置成本降低 70%（嘉宾称）。

前程无忧的林自达（转写识别为「林子达」，按议程校正）把这个机制用到了极致。他们的 AI 招聘助手为每个 HR 会话分配一个独享沙箱，按使用状态分浅休眠与深休眠：HR 是早九晚五的碎片化使用，早高峰 9-10 点会打出万级规模的脉冲请求，其余时间大量沙箱处于休眠。会话数据挂在 LakeBase（嘉宾称其前身为 PolarFS 演进）上，保留 180 天——HR 从深休眠状态唤醒后，过去 180 天的所有交互数据完整可用。整套体系跑下来，林自达给出的成本口径是「一个会员每天成本大概一块钱」（嘉宾称，与商业模式相关）。从工程细节到商业定价，这条链路说明的是同一件事：当计费单位从「实例时长」走向「任务成本」，休眠唤醒不是锦上添花，而是 Agent 商业模式能否成立的前提。AMD 的周俊杰在圆桌上把这层逻辑推到硬件侧：客户衡量标准正在从「一台服务器多少钱」变成「完成一个 agent task 需要多少成本」。

对读者的可迁移启发是：任何为 Agent 设计的系统，成本模型都要贴着负载的间歇性重新设计——常驻等待是微服务时代的假设，不是 Agent 时代的。

三、毫秒级交付的真相：把「拉」变成「领」

「每分钟 10 万沙箱、冷启动 P99 小于 180 毫秒」这类数字容易被当成营销话术，但罗晶的架构拆解给出了可复述的机制。单个沙箱的资源组装链路很长——创建 VM、拉镜像、分配网络存储——端到端冷创建耗时天然难以满足低延时业务。阿里云的思路是把资源准备动作前置化：构建多级 VM 预热池，L1 是客户自运维的业务就绪池（SandboxSet），可以百毫秒级从中「申领」（claim）一个现成沙箱；L2 是平台侧 VM 预热池，负责异步补货；L3 是大弹性计算资源池提供算力供给。冷创建的 create 动作被替换成就绪池的 claim 动作——把「现炒」变成「料理包」，用户不关心背后是哪种（宾哲在金山办公的分享里用了同一个比喻）。

大规模并发的另一半瓶颈在镜像分发：大量沙箱集中启动时会并发拉取容器镜像，撑爆系统吞吐。方案是把「从中心化 OSS 拉镜像」转化为「基于云盘快照创盘并挂载」，配合热点镜像分层预热与 lazy load 按需加载，官方称支持千万级镜像缓存秒级加载。这套组合拳的结果就是分钟级 10 万沙箱吞吐。

金山办公的实践补充了弹性另一半：水位管理。他们的业务有明显潮汐（白天高峰、晚上低谷），用两个控制器配合——CronHPA 按时间节点规律扩容（早高峰前拉高水位、深夜收缩），AHPA 按历史负载预测下一段流量动态设置预热数量。宾哲的比喻是「餐厅老板看天气预报，明天暴雨今晚多备一倍的菜」：从凌晨的十几个到早高峰的一千个，水位始终比流量快半步。CronHPA 与 AHPA 均为 ACK 官方弹性能力（外部核实），CronHPA 已进入最新开源的 Agent Sandbox 项目。

这条机制链的通用启发：弹性系统的核心杠杆不是更快地创建，而是重新分配「准备」与「使用」的时序——凡是有预热池的场景，延迟都被转移到了无人感知的时刻。

四、四道栅栏：把「能联网」变成「可治理」

安全是这场论坛着墨最重的部分，因为它恰好是 Agent 与传统负载分野最尖锐的地方。金山办公宾哲的开场判断很扎心：传统软件安全模型里代码是谁写的可以追溯——内部开发、审计过的第三方库，责任链条清晰；而 Agent 执行的代码可能来自三个不可信来源：模型推理自己写的、用户输入的、外部网页抓下来的。他提到今年年初国家计算机病毒中心曾发文提醒 AI 时代的相关风险（嘉宾称）。

他们的答案是「沙箱不神秘，本质就是 Kubernetes Pod」——Namespace 隔离、cgroup 资源限制、network policy、security 基线，这些云原生能力已经用了十年，金山做的事情是「把传统云原生能力为 AI 重新组合」：非特权容器、seccomp 命令限制（转写误识为「secure compare」）、根文件系统只读，再叠加 microVM 级隔离避免共享内核风险。真正的增量在沙箱外围的四道栅栏：第一道，运行域与网络域双重隔离——沙箱集群与应用集群各自独立控制面（api server、etcd、scheduler 全独立）、独立节点池、禁止直连，两个集群各一个 VPC 物理隔离，让不可信代码「连隔壁有谁都不知道」；第二道，所有访问路径收敛到 PrivateLink 私网链接的受控闸口，除此之外默认隔离；第三道，沙箱访问内网一律走公网——宾哲的比喻是「沙箱就是网吧里的一批电脑，分配给用户的终端设备访问我们就该走公网」；第四道，实例之间默认禁止调用，每个 Pod 按 VM 级对待，爆炸半径收敛到单个 Pod 或单 VM，审计流只进不出、全量落库。这套设计的教训来自实战——宾哲透露业务初期曾在内网撞穿沙箱，「你问 AI 帮我做点坏事，它把我们的底裤都扒光了」。

身份是另一条安全主线。邓彬举了两个例子：其一，ERP 系统里老板和员工的权限必须不同，Agent 调用工具时如何继承人的权限？答案是 Agent Identity 把每次工具调用与身份权限绑定，「老板是老板的权限，员工是员工的权限」。其二，一家短剧客户把 API Key 内置在沙箱里，担心「有人让模型查我的 key 是什么」；凭证外置后模型感知不到 Key——但邓彬随即自我设限：「这是不是绝对安全？也不一定。」这种不把单点方案说成终极答案的表述，比数字更可信。

成本与安全最终在「分级」处合流。金山办公把沙箱分成三舱：对外业务用 ACS 算力、安全标准拉满的「商务仓」；内部可控业务用固定节点超卖的「经济仓」；需要 Web Coding、编译运行的用高性能「头等仓」。宾哲的总结是「安全不是一刀切，而是根据风险定价，把每一份算力花在刀刃上」。

五、规模化之后：单集群的天花板与多集群舰队

当沙箱从几千个涨到几十万个，单 Kubernetes 集群会撞上三重上限：大量创建、销毁、休眠唤醒带来的控制面吞吐上限；计算存储网络的资源上限；以及故障域集中——业务被锁死在单个故障域里「无法逃逸」。阿里云庄宇的答案是 ACK One Fleet：把多个 ACK 集群变成一套对业务透明的沙箱基础设施。技术上值得记的是两个设计。其一是五类调度因子——子集群容量上限、水位均衡（看比例而非绝对数）、创建请求分离（控制发往各子集群的创建速度，防止冲击控制面产生限流排队）、预热池感知（优先命中预热资源）、集群优先级（主 Region 优先、备地域兜底）——调度不再是简单轮询，而是在容量、负载、启动速度、故障风险之间做全局择优。其二是 E2B 链路的控制面与数据面分离：创建、休眠、唤醒等生命周期操作经过 Fleet 统一调度并记入全局路由表，而 HTTP、WebSocket、gRPC 数据交互不经过 Fleet 中转、直达沙箱所在子集群——舰队保持轻量，数据面随子集群横向扩展，故障影响限制在各自的故障域内。官方口径是单个 Fleet 实例可支撑 60 万以上沙箱运行（嘉宾称），金山办公已用它实现集群间秒级切流容灾。外部核实：ACK One 的多集群管理基于开源项目 Karmada——该由华为云发起的项目已于 2026 年 9 月从 CNCF 毕业，现场陈述属实。对业务的接入成本，庄宇称近乎零改造：E2B 用户只换 endpoint，K8s 用户继续提交 CR，认证、配额、全局调度、路由全部由 Fleet 承担。

六、两份生产账本：一个月 POC，与「不重复造轮子」

前程无忧的故事几乎是一个标准样本。他们 2025 年 10 月前自研的 Agent 框架被林自达自嘲为「蠢」——没有 loop、无法自我纠正、人力投入大（「手搓 harness 很绝望」）；2026 年初 OpenClaw 出圈后曾认真评估四人团队自研部署，「后来想着还好」——沙箱把路由、隔离、弹性都解决了，团队回归应用开发。时间线是：2 月启动对接，一个月 POC 走通（skill+MCP），三个月打磨最小可用功能，6-8 月完成对外售卖。更有意思的是数据飞轮：对话日志归档到 MaxCompute 做审计与分析，用户在对话框里「骂」出来的功能缺失直接反哺产品迭代——「AI 时代完全不需要埋点了，用户自己会表达困惑」。

金山办公的选型逻辑则揭示了开源生态的位置：今年 3 月起收到大量沙箱需求，当时各云厂产品与自身业务强绑定，调研一圈后选择 Agent Sandbox 开源项目做底座，理由四条——K8s 生态融合、E2B 协议兼容、开源可二次开发、算力可控。外部核实：kubernetes-sigs 下的 agent-sandbox 项目真实存在（Sandbox CRD、Claim、WarmPool 等概念与罗晶演讲中的编排层描述一致，支持 gVisor/Kata 运行时）。邓彬的忠告与此呼应：「不要重复造 harness 的轮子——企业的核心数据资产不是 harness，是 skill 和 MCP。把 code base 丢进沙箱、集成 MCP 和 skill，可能比你辛苦两个月写的 harness 效果好很多。」（嘉宾观点）

七、圆桌：不敢交给 Agent 的事，与 AI 原生组织的两块地基

圆桌（InfoQ 王一鹏主持）最有价值的部分反而是「反方」。哪些场景适合 Agent，几位嘉宾的标准高度趋同：目标明确、需要动态决策/多工具调用、有人工兜底。杨皓然的「光谱论」更完整：左端确定流程用工作流就好，右端上下文组织不好、爆炸半径难控的也不适合，中间地带才是 Agent 的价值区。而「不敢交给 Agent」的两个回答值得记录：林自达说他们 CEO 很早抛出一个问题——招聘双方都用 AI 沟通时，「到底是人在找工作还是 AI 在找工作」；所以沟通问答不敢做太智能化，「特别害怕两边 AI 自己成交，约好明天面试，结果对方回来说那是我的助理去的」。宾哲的边界在运维：增删改操作不敢完全交给 AI，「稳定性是运维的基石，容不得差错」，人执行、AI 辅助决策，且「未来很长一段时间都不会完全交出去」。

关于规模化落地，杨皓然给出三个条件，其中第三个最少被谈却最本质：其一，成本要继续降——他用电气化类比，电便宜、电网发达，电器才普及，token 与沙箱执行成本要足够低才会涌现现在无法设想的应用；其二，Agent 治理合规要更快成熟，像微服务那样有完善配套；其三是体验要为 AI 重新设计——今天的云产品为人操作设计（看文档、看 dashboard、问同事），未来的使用者是 Agent，它看不了 dashboard、没有同事可问，错误上下文的获取方式要变（比如给 CLI 和 hint，而不是给人看的控制台）。这句话指向一个深层转变：云的「用户」正在从人变成 Agent。

至于 AI 原生组织，林自达的两个「很现实」比宏大叙事更有用：企业要有会用 AI 的人才——「把工具摆在这儿，真有人会用吗？会写 skill 吗？发现 skill 不好会去优化吗？」；企业要有可被消费的上下文——他类比工业 4.0：企业所有环节是否都能像工业 4.0 那样，写个 CLI、配个 MCP 就能查到数据。「前面两个没有，就甭想。」周俊杰的收束则给了一个时间尺度：「未来三到五年，不是 Agent 替换人，而是每个人拥有一个非常强大的 Agent 团队；基础设施要让这些 Agent 像现有云服务一样稳定可靠、规模化运行。」

结语

这场论坛的完整逻辑链可以压缩成三句话。第一，负载形状变了：Agent 是动态决策、强隔离需求、间歇执行的负载，K8s 为长时实例设计的调度模型天然不适配，所以沙箱成为 VM 与容器之后的新算力形态（杨皓然称这是阿里云内部的明确判断，业界新兴开源项目的方向也一致）。第二，工程范式变了：毫秒级交付靠预热池前置化，成本可控靠休眠唤醒对齐负载间歇性，安全可控靠多层隔离加身份绑定——三者共同把「能跑」变成「可运营」。第三，衡量单位变了：从实例时长到单任务成本，从部署了多少 Agent 到多少业务流程能通过 Agent 高效运行。对正在评估 Agent 基础设施的团队，可观察的指标已经写在这些案例里：冷启动 P99、预热池命中率、休眠占比与唤醒延迟、单任务成本曲线、故障域数量与切流时间。而当所有云产品都要为 Agent 而非人重新设计交互时，这场基础设施的换轨才刚刚开始。

（注：本文事实与数字除标注外部核实外均为论坛嘉宾口径；转写中的人名、产品名已按官方议程与公开资料校正，个别无法确认的表述在文中以「嘉宾称/转写疑似」标注。）