从Kubernetes到Agent Sandbox：AI智能体的生产化部署正在重塑云原生架构

AI智能体不再是实验室的玩具。当Kubernetes开始原生支持Agent Sandbox、OpenAI为Agents SDK加入沙箱执行引擎时，一个新问题浮出水面：我们现有的云原生基础设施，真的准备好承载自主运行的AI智能体了吗？

Kubernetes v1.36：Agent Sandbox的诞生

Kubernetes v1.36预览版本带来了一个意义重大的新特性——Agent Sandbox。

为什么AI智能体需要专属沙箱？

传统的容器隔离是为"确定性工作负载"设计的：你知道一个Web服务器会做什么，它的行为是可预测的。但AI智能体完全不同：

非确定性行为：同一个提示可能产生完全不同的操作序列
动态工具调用：智能体可能调用文件系统、网络API、数据库等多种外部工具
长时间运行：与无状态的请求-响应不同，智能体可能运行数小时甚至数天
自我迭代：智能体可能基于中间结果修改自己的行为策略

传统的Pod安全策略和Network Policy无法有效约束这种动态行为。Agent Sandbox的核心思想是：为AI智能体提供一个可控的、可审计的、可回收的执行环境。

技术架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
┌─────────────────────────────────┐
│         Agent Sandbox           │
│  ┌──────────────────────────┐   │
│  │  AI Agent Runtime        │   │
│  │  ┌─────┐ ┌─────┐       │   │
│  │  │Tool1│ │Tool2│  ...   │   │
│  │  └─────┘ └─────┘       │   │
│  └──────────────────────────┘   │
│  ┌──────────┐ ┌──────────┐     │
│  │ FS Mount │ │ Network  │     │
│  │ (scoped) │ │ (policy) │     │
│  └──────────┘ └──────────┘     │
│  ┌──────────────────────────┐   │
│  │    Audit Log & Telemetry │   │
│  └──────────────────────────┘   │
└─────────────────────────────────┘

关键设计点：

作用域文件系统：智能体只能访问显式授权的文件和目录
网络策略强化：细粒度控制智能体可以访问哪些API端点
完整审计日志：记录智能体的每一个工具调用和决策
资源配额：CPU/内存/GPU时间的硬性限制，防止失控

OpenAI Agents SDK：从SDK到运行时

几乎同一时间，OpenAI发布了Agents SDK的重大更新，引入了两个核心概念：

1. 原生沙箱执行（Native Sandbox Execution）

以前的Agents SDK本质上是一个"调度器"——它编排工具调用，但实际执行发生在你自己管理的环境里。新版SDK内置了沙箱执行引擎：

代码在隔离环境中运行，不影响宿主系统
文件操作在虚拟文件系统中完成
网络访问受到策略控制

2. 模型原生调度器（Model-Native Harness）

这是一个更深层的架构变化。传统的智能体框架（如LangChain、AutoGPT）是框架驱动的——框架决定何时调用模型、如何处理响应。新的Agents SDK转向模型驱动：

模型本身决定下一步做什么
框架退化为"执行层"，提供工具和安全边界
更自然的推理流程，减少了框架引入的人工约束

两者结合的意义

1
2
传统方式:  用户 → 框架 → 模型 → 框架 → 工具 → 框架 → 用户
新方式:    用户 → 模型 ⟷ 沙箱(工具) → 用户

减少了中间层，智能体的行为更加流畅，同时安全性反而提升了——因为所有操作都在受控沙箱中执行。

CNCF的警告：Kubernetes本身不够

Cloud Native Computing Foundation（CNCF）本周发布了一篇重要的博客文章，直截了当地指出：“Kubernetes alone is not enough to secure LLM workloads”（仅靠Kubernetes不足以保护LLM工作负载）。

CNCF指出的安全缺口

威胁	传统K8s防御	是否有效
Prompt注入攻击	无相关机制	❌
模型投毒	镜像签名只验证容器，不验证模型	❌
训练数据泄露	RBAC无法控制模型内部行为	❌
智能体越权操作	Network Policy粒度不够	⚠️
GPU侧信道攻击	无GPU级隔离	❌
对抗性输入	无输入验证层	❌

CNCF的建议

模型供应链安全：不仅验证容器镜像，还要验证模型权重的完整性和来源
推理层防火墙：在模型和用户之间部署专门的安全层，过滤恶意输入
GPU隔离：使用MIG（Multi-Instance GPU）或类似技术隔离不同租户的GPU工作负载
运行时行为监控：不仅监控容器行为，还要监控模型的输出模式

AI智能体时代的新架构范式

综合Kubernetes Agent Sandbox、OpenAI Agents SDK和CNCF的安全警告，一个新的架构范式正在形成：

传统微服务 vs AI智能体架构

维度	微服务架构	AI智能体架构
行为	确定性	非确定性
生命周期	请求-响应	长时间运行
资源使用	可预测	动态波动（GPU峰值）
安全模型	基于身份和网络	基于行为和意图
调试	日志+链路追踪	决策审计+推理回放
扩缩容	基于QPS	基于并发任务数+GPU利用率

新技术栈的雏形

1
2
3
4
5
应用层:    AI Agent (模型 + 工具 + 记忆)
运行时:    Agent Sandbox (隔离 + 审计)
编排层:    Kubernetes v1.36+ (调度 + 资源管理)
安全层:    推理防火墙 + 模型供应链验证
硬件层:    GPU隔离 (MIG) + 机密计算

对开发者和架构师的建议

学习Agent Sandbox模式：这将成为部署AI智能体的标准实践
重新思考安全边界：传统的"网络边界"思维不适用于AI智能体，需要转向"行为边界"
Kubernetes升级规划：v1.36的Agent相关特性值得提前评估和测试
建设可观测性：AI智能体的调试需要全新的工具——决策审计、推理回放、工具调用链路
评估OpenAI Agents SDK：如果你在构建AI智能体，新SDK的沙箱执行模式值得优先考虑

Jiayun's Blog