AI 智能体沙箱化：Kubernetes 上的自托管实践

随着 AI 智能体（agent）的能力持续增强，单纯执行一段生成代码已远不足以满足需求——安装依赖、编译软件、浏览网页、运行模糊测试、启动服务、长时间自主运行等任务，对执行环境提出了截然不同的要求。AWS、Azure、GCP 等主流云厂商近期已悄然将控制平面从 runc 迁移至硬件强制隔离，这一趋势反映出传统容器运行时在 agent 场景下的局限。

新一代智能体沙箱的出现

围绕「为 agent 提供一个隔离、有状态、可丢弃的工作环境」这一理念，社区涌现出一批专用沙箱方案。E2B、Blaxel 以及 Kubernetes SIGs 的 agent-sandbox 项目均属此类尝试。其中 Agent-Sandbox 以 Kubernetes 为底座，向应用层暴露 REST API 与 MCP server，使 agent 无需理解 CRD、Pod、Namespace 等概念即可创建、使用、删除沙箱，定位为托管沙箱平台的开源自托管替代品。

Edera 的定位：有状态计算原语

Edera 并非要取代 Kubernetes 或另起一套 agent 框架，而是在沙箱被视作一等公民之后，为运行时补充 Kubernetes 难以表达的语义：快照、回滚、分叉、对象能力、工作负载身份等。在该视角下，沙箱不再等同于「启动一个新容器」，而是一段可暂停、可恢复、可快照、可克隆成多条独立执行轨迹的活体计算状态。

「丢进 VM」并非万能答案

传统思路往往以虚拟机隔离收尾，但 Trail of Bits 的近期实验对这一假设构成挑战：研究人员让 GPT-5.6-Cyber 自主尝试逃逸一个 QEMU/KVM 虚拟机。该智能体在大约 12 小时内，结合已知 CVE、未合入发行版的漏洞乃至此前未公开的缺陷，连续三次成功逃逸，并自主撰写 PoC 代码、在失败路径上回溯后串联不同漏洞。实验同时显示 Firecracker 是明显更难的目标，但仍导致宿主机内核崩溃。这意味着隔离必须作为整体设计属性来评估：hypervisor、客户机内核、设备模拟、网络栈、宿主机内核、可暴露凭据等共同决定安全边界。Edera 使用基于 Xen 的虚拟化栈（亦可选用不含 QEMU 的 KVM），攻击面与失败模式与 QEMU 不同，但同样无法回避「足够强的 agent 会主动探测并攻击宿主机侧软件」这一根本问题。

Kubernetes 的能力边界

Kubernetes 在「声明应当运行什么」方面极为擅长，但对「操控运行中进程状态」并无原生支持。当 agent 工作流需要持久化、快照、回放、分支等操作语义时，标准抽象变得笨拙。把执行状态当作一等公民来管理，把运行时与编排层解耦，正是 Agent-Sandbox、Edera 等项目试图弥合的鸿沟。在 agent 可被授权自主运行数小时的场景下，这些原语既是提升效率的运维工具，也是调查、收敛与恢复不可预测行为的重要手段。