Agent不只烧Token：为什么Agent Sandbox正在变得重要？

去年的行业大会，主基调还围绕在模型能力、推理成本和 AI Coding 上。Agent 很热，但大家追问更多的是它能做什么。到了今年，讨论从能力探索进一步走向生产落地。Agent 像一条新的主线，穿过每一个地方。 在今年的云栖大会上，这种体感格外明显，会场里到处都能听到 Agent，讨论也越来越具体：怎么把 Agent 做出来，怎么让它真正进入业务。 这些问题再往下追，总是会回到并不在聚光灯下的 Infra 上。因为模型决定能力的上限，但决定这些能力最后能不能安全、稳定地落下来，还得是 Infra。 在云栖大会技术主论坛上，阿里云智能集团研发副总裁、弹性计算产品线负责人吴结生发布了智能体沙箱 Agent Sandbox，并将其定义为“面向智能的新型算力形态”。阿里云给出的一个说法是，为每个 Agent 即时创造一个“可控的世界”。 这个世界里要有完整的运行时，也要管住身份、网络和数据，任务停下来以后还能保留状态。 Sandbox 本身并不新鲜，但随着 Agent 从 Demo 走向生产，云平台和开发者工具厂商都在重新审视这一层。动态生成的代码、难以预测的任务时长，以及执行过程中的等待和恢复，正在对运行环境提出新的要求。 在今年云栖大会的一场主题为《Agent Sandbox 助力 Agent 从 Demo 到生产级稳定运行》圆桌对谈中，来自阿里云、AMD、金山办公和前程无忧的几位嘉宾，分别从云平台、底层算力和企业实践的角度，讨论了 Agent 从 Demo 进入生产之后遇到的挑战及实战经验。很多讨论最后都指向了 Agent 需要什么样的运行环境、企业又该怎么选。而 Agent Sandbox，正在成为这两个问题绕不开的一层。 Agent 为什么还需要 Sandbox？ 今天再谈 Sandbox，很容易产生一个疑问：Docker 已经很成熟了，Kubernetes 也用了十多年，为什么还需要 Sandbox？ 一个对开发者来说，最直观的原因就是，代码变得没那么可信了。 放在传统软件里，一段代码是从哪里来的，通常很清楚，要么是公司内部开发，要么是经过审核的第三方依赖，责任链条相当清晰。到了 Agent 这里，它执行的代码可能是模型刚生成的，也可能来自用户输入，甚至刚从网页上抓取的。 金山办公云原生开发运维专家宾哲把这件事概括成一句话：“AI 越强，越要入笼”。 这个“笼子”不是要把原来的容器体系推倒重来。金山办公自己的 Sandbox 底座仍然建立在 Kubernetes 体系上，阿里云 Agent Sandbox 也原生兼容 Kubernetes API。按照阿里云的设计，每个 Sandbox 可以以 Kubernetes Pod 为载体，再运行在 MicroVM 隔离环境里，把风险尽量收在单个执行环境里。 但隔离只是问题的一部分。阿里云智能集团资深技术专家杨皓然在圆桌对谈环节中提到，过去企业里的负载大致可以分成两类：长期运行的微服务，以及有明确生命周期的离线 Job。这两类负载经过多年发展，已经有了比较成熟的调度和治理体系。 Agent 的运行方式明显更随机。它下一步调用什么工具，要跑多少轮，很大程度上由模型动态决定。大量 Agent 还是间歇式执行，任务过程中会等待模型推理，也会等待 Subagent 返回结果。 等的时候，资源怎么办？如果 CPU 和内存一直占着，用户就在为等待时间付费；直接把环境销毁，任务状态又没了。原来更适合长时运行实例的调度方式，到这里就显得不那么合适。 所以阿里云这次在 Agent Sandbox 里同时做了快速创建和休眠恢复。按其公布的数据，Agent Sandbox 每分钟可创建 10 万个沙箱，基于模板创建与冷启动 P99 小于 180 毫秒；资源池预热后，热启动 P99 小于 20 毫秒；深休眠唤醒 P99 低于 600 毫秒。 当运行环境发生变化，压力还会继续往硬件层传导。 AMD 中国区销售副总裁周俊杰提到，传统应用可能持续运行几个月，但一个 Agent 任务可能只运行几十秒，一天内还可能反复创建大量这样的环境。包括 Agent 编排、Tool Calling、RAG 检索、状态管理、Sandbox 运行和安全隔离等大量工作，更多还是落在 CPU 侧。 因此，AMD 在 EPYC 数据中心处理器上重点投入高核心数设计，帮助客户在单一机柜里承载更多 Agent 和 Sandbox；同时通过缓存、带宽、机密计算、内存加密和可信 I/O，提升数据处理效率和安全性。周俊杰把这种变化概括得更直观：未来的数据中心可能不再只是运行应用，还要运行大量“数字员工”。每一个数字员工背后，都需要算力、安全、调度和治理体系共同支撑。 不难发现，Agent 带来的变化已经不只是一种新的应用负载。上面是动态生成的任务，中间需要新的运行时，下面的 CPU、网络和存储也要跟着适配。“所以阿里云也认为，沙箱会成为继 VM 和容器之后的一种新的算力形态”，杨皓然提到。 当问题来到企业这一侧，会变得更加具体：这一层要不要自己做？什么场景值得上 Sandbox？安全、稳定和成本之间又该怎么选？ Agent 进入生产，企业如何选择运行底座 过去一年，阿里云智能集团高级产品解决方案架构师张军 能明显感觉到，客户问的问题变了。 最早，一些企业还是把 Agent 当成普通应用部署，后来开始比较开源方案和供应商方案。真正跑过一段时间以后，问题变成了用户之间怎么隔离，版本怎么平滑更新，长任务怎么休眠和恢复。 这些问题，很多团队一开始都会想着自己补。 前程无忧搜索推荐策略团队负责人林自达提到，他们曾考虑过直接部署 OpenClaw，再自己处理用户隔离、路由和长连接。做下去才发现，工作量很快就从 Agent 本身蔓延到底层。流式连接需要处理路由，多用户需要隔离，后面还要考虑弹性、发版和更新。 对一个应用团队来说，这些事情都能做，但投入多少人长期维护，就是另外一回事。后来，他们重新算了这笔账：团队更应该把人力放在应用和业务上，如果大量时间耗在基础架构，ROI 并不高。 等 AI 招聘助手真正上线后，这笔账会容易算得多。 前程无忧的 HR 用户主要在工作时间使用产品，早上 9 点到 10 点会出现万级规模的脉冲请求。但 HR 并不会一直和 Agent 对话，使用时间又很碎片。前程无忧为每个 HR Session 分配一个独享 Sandbox，再根据使用状态切换活跃、浅休眠和深休眠。用户离开时环境可以休眠，回来后仍能恢复此前的会话数据。相关数据还会归档，用于后续审计和产品分析。 按照林自达给出的时间线，这个项目用了一个月完成 POC，随后又用三个月打磨 MVP。到这个阶段，Sandbox 已经不只是把代码“关起来”，它还承担了空闲成本控制。据介绍，进入生产后，系统可以支撑万级请求，成本也被控制在较低水平，目前单个会员每天的相关成本大约在 1 元左右。 金山办公面对的问题又不太一样。宾哲提到，他们选择 Agent 运行环境时，主要考虑 安全、成本和稳定性，不同业务也会采用不同的运行方式。 比如，面向外部用户的业务更看重安全和稳定，会把 Sandbox 作为底层运行时；一些内部业务更适合 Agent Use Sa