十年来的正确之选十年来Kubernetes一直是正确之选。它最初为快速、无状态的Web请求构建能组织容器、扩展服务为平台团队提供通用术语抽象底层复杂性让工程师专注服务。如今多数云原生基础设施基于它构建Amazon Elastic Kubernetes Service (EKS) 使其成为AWS上企业团队默认选择。旧模式的工作负载当时典型工作负载是无状态的HTTP请求快速输入输出、用完即弃。用户操作触发请求服务响应后容器任务完成。Kubernetes针对此模式优化系统设计基于单个工作单元短暂、无状态且可互换的假设。智能体工作负载的不同智能体是长时间运行的有状态进程能跨时间推理、调用工具等工作流可能运行数分钟甚至数小时涉及多个外部系统生成中间输出。新的执行基础设施围绕智能体语义设计。2026年3月Kubernetes SIG Apps发布关于Agent Sandbox介绍表明智能体执行不适合旧模式。智能体执行的实际需求具体需满足四点执行环境毫秒级配置实现隔离任务生命周期内持久状态管理多智能体工作协调原语执行上下文凭证和密钥管理。生产环境中的问题实践中Kubernetes和EKS暴露不匹配问题。Pod驱逐会终止智能体任务且无清晰恢复路径自动扩展以CPU利用率为信号会误判智能体状态新环境配置时间长影响推理循环和用户体验。利用率数据显示成本问题严峻智能体工作负载加剧此问题。安全问题的变化智能体工作负载改变威胁模型受损智能体暴露风险大标准容器命名空间无法控制风险内核级隔离等成为基本要求。部署智能体团队的发现2025年末Ramp工程团队介绍构建内部后台编码智能体Inspect过程其架构要求与四个原语一致。Inspect推出后Ramp仓库约30%拉取请求由其编写关键启示在于执行层。生态系统的追赶与问题Kubernetes解决了原本问题但基础设施默认模式难改。Kubernetes社区的Agent Sandbox项目证实需全新抽象。专门为智能体设计的基础设施采用尚处早期企业编排模式不匹配缺乏有效工具。当下的结构优势弥补差距的基础设施已存在认识到智能体执行是一流计算模式的团队将获结构优势未转变的团队智能体系统可能不可靠。