你的AI代理正在服务器上执行一段代码。可能是解析文件，可能是调用工具，可能是你写系统提示时根本没预料到的操作。什么在阻止它执行rm -rf /？答案是：你的信任。这不算安全，这叫赌博。
Google Cloud NEXT '26的260多项发布里， buried着我认为对真正想部署AI代理的团队最重要的基础设施更新。几乎没人讨论它。
一个没人愿意承认的真相
当前代理式AI的状态很尴尬：我们给了代理权力，却没有安全的容器来约束它。
当代理执行工具调用——运行shell命令、写文件、调用API、生成子进程——这段代码总得在某处运行。大多数现有方案里，这个"某处"是你同时用于其他用途的容器。更糟的是直接跑在虚拟机上。隔离策略基本等于："我们相信模型不会干坏事。"
演示可以这么玩。生产环境这么玩是灾难。
问题会快速叠加：
• 多租户代理应用：一个用户的代理理论上能干扰另一个用户的执行环境
• 自主代理：运行越久、人类监督越少，执行的代码越多，任何错误的爆炸半径越大
• 第三方工具：你不只是跑自己的代码。代理调用外部工具、MCP服务器、返回任意载荷的API
我聊过的每个认真做代理的团队都有类似对话："我们爱这个原型。但 terrified 让它接触真实用户。"
从"笔记本里能跑"到"我愿意拿饭碗担保它能上生产"的鸿沟，几乎完全是信任和隔离问题。
谷歌实际发布了什么
NEXT '26上，谷歌宣布GKE Agent Sandbox正式可用（Generally Available）。
一句话：为AI代理运行不可信代码和工具调用而设计的隔离、一次性执行环境——代理碰不到不该碰的东西。
细节才见真章。
隔离层：GKE Agent Sandbox基于gVisor构建，内核级沙箱，在系统调用到达宿主机前拦截。这是谷歌用来保护Gemini本身的同款技术。不是新实验，是久经考验的基础设施被重新用于代理工作负载。
规模数据：
• 每集群每秒启动300个沙箱
• 首次指令执行时间低于1秒
• 每个沙箱有状态，可附加持久化存储
• 支持GPU和TPU，满足需要硬件加速的代理工作负载
关键设计：沙箱不是共享环境的轻量包装。每个代理执行获得干净、隔离、一次性的计算单元。执行完即销毁。有状态工作负载可附加存储，但计算环境本身不留痕迹。
为什么这改变了游戏规则
现有方案的问题不是"不够安全"，是"安全与可用性二选一"。
你可以用重量级虚拟机实现强隔离，但启动时间以分钟计，成本爆炸，代理的响应延迟让人无法忍受。或者用轻量容器，快是快，但隔离性不足以应对不可信代码。
GKE Agent Sandbox试图同时解决两边：gVisor的拦截开销足够低，能实现亚秒级启动；隔离强度又足以运行真正不可信的代码。
这对几类场景是刚需：
• 代码生成代理：让LLM写代码然后执行验证？你就是在运行不可信代码
• 多步骤研究代理：需要浏览网页、下载文件、解析文档、调用工具——每个动作都可能是攻击向量
• 客户部署的代理：你的SaaS产品里用户能配置自己的工具调用？你在运行用户提供的不可信代码
谷歌自己在用这套方案跑Gemini的代码执行能力。不是实验室玩具，是支撑亿级用户产品的同一套基础设施。
清单：代理隔离的五个硬问题
基于GKE Agent Sandbox的设计和现有方案的对比，拆解生产级代理部署必须面对的五个核心挑战：
1. 启动速度 vs 隔离强度的死亡谷
传统虚拟机启动需要30-60秒，对需要频繁工具调用的代理完全不可接受。容器启动快（毫秒级），但共享内核意味着一个容器逃逸可能影响整个宿主机。
gVisor的折中：用户态内核实现，拦截系统调用时无需完整虚拟机初始化，实现亚秒级冷启动的同时保持进程级隔离。
300 sandboxes/second的集群级吞吐量意味着高并发代理系统不会卡在环境准备上。
2. 状态管理的悖论
一次性沙箱的理想是"执行完即焚"，但真实代理工作负载需要状态：下载的文件、中间计算结果、用户会话数据。
GKE Agent Sandbox的方案：计算环境销毁，但可附加持久化存储卷。隔离性不牺牲实用性。
关键细节：存储附加是显式操作，不是默认行为。开发者必须主动选择让沙箱有状态，降低意外数据残留风险。
3. 硬件加速的隔离难题
AI代理 increasingly 需要GPU/TPU：模型推理、嵌入计算、图像处理。
传统GPU虚拟化方案（如NVIDIA vGPU）复杂且昂贵。gVisor对GPU直通的支持让代理能在隔离环境中使用硬件加速，无需为每个沙箱分配完整物理GPU。
这对成本敏感的多租户场景至关重要——你能想象每个用户代理会话都独占一块A100吗？
4. 第三方工具链的信任崩塌
MCP（Model Context Protocol）服务器正在爆发。你的代理可能调用十几个外部工具，每个都是潜在攻击面。
现有方案的问题：工具调用通常在代理的主执行环境运行，或共享容器。一个恶意的MCP服务器响应可能污染整个代理状态。
沙箱化工具执行意味着每个工具调用获得独立隔离环境。即使工具被攻破，爆炸半径被限制在单次调用。
5. 可观测性的黑洞
隔离环境的副作用：执行日志、性能指标、调试信息散落在一次性容器中，难以聚合分析。
GKE Agent Sandbox与Cloud Logging/Monitoring的集成是必选项而非附加值。生产代理需要知道每个工具调用的延迟、资源消耗、失败模式——无论沙箱是否还存在。
谁应该立刻关注
不是所有团队都需要这个级别的隔离。但如果你符合以下任何画像，现状的"信任模型"正在拖慢你的生产部署：
• 正在构建多租户AI平台，用户能上传自定义工具或代码
• 代理需要执行用户生成的查询（数据分析、代码解释器场景）
• 运行时间超过分钟级的自主代理，人类不在循环中
• 需要符合SOC2/ISO27001等合规要求，现有容器隔离无法通过审计
谷歌的发布时机很有意思。代理式AI正处于从"酷炫演示"到"关键业务系统"的拐点，基础设施层的缺口被暴露出来。GKE Agent Sandbox不是唯一解决方案——AWS有Firecracker，Azure有Hyper-V容器，开源社区有Kata Containers——但它是首个明确以"AI代理工作负载"为核心设计目标、且达到生产可用状态的产品。
一个值得玩味的细节：谷歌选择把这项技术放在GKE（Kubernetes）生态而非作为独立服务。这暗示了他们认为的部署模式——代理执行环境是应用基础设施的一部分，需要与现有CI/CD、服务网格、身份体系集成，而非孤立的"AI服务"。
对于在Kubernetes上已有投资的团队，这意味着更低的采纳门槛。对于还没上K8s的团队，这可能成为推动基础设施升级的催化剂——毕竟，"我们的AI代理需要它"是比"我们需要服务编排"更能让CTO点头的理由。
最后一点冷观察：谷歌用gVisor保护Gemini已经有一段时间，现在把同款技术开放给客户。这种"先自用，后产品化"的路径在云计算领域越来越常见，但也意味着技术的真实成熟度需要时间验证——Gemini的使用模式是否与典型客户工作负载足够相似？300 sandboxes/second的峰值性能在真实网络延迟和存储I/O下能维持多少？
这些问题没有现成答案。但对于那些因为"不知道代理会执行什么代码"而每晚睡不着的工程师来说，至少现在有一个专门为他们设计的选择，而非在" hope 模型 behave"和"重写整个基础设施"之间二选一。
热门跟贴