kern 用 3.5 毫秒容器承接 Agent 代码，但它没有假装自己是虚拟机

开源项目 kern 发布了一套无守护进程、始终无 Root 的容器与资源运行时。项目称它能从 OCI 镜像约 3.5 毫秒启动一个隔离环境，静态二进制约 1.52MB，并提供 Python、Node 和 MCP 接口，直接面向 Agent 与 AI 生成代码执行。

一句话结论：kern 的价值不是把 Docker 再缩小一次，而是把“一次任务一个临时容器”做得足够轻；它的可信度也来自主动承认 Linux 内核边界不能替代微型虚拟机。

kern 不运行 dockerd 或共享 Socket。每个 box 都是独立进程树，使用用户、PID、挂载、网络、UTS 和 IPC namespace，配合 pivot_root、seccomp、能力裁剪及 cgroup v2。默认网络是隔离回环，设备拒绝访问，文件系统使用写时复制或只读根。

项目把 box 与 run 分开：前者提供隔离和资源配额，后者只给宿主进程设置 CPU、内存等限制，不是沙箱。这个区分很重要，因为很多工具把“有限额”误写成“安全执行”。对于不可信代码，还要显式使用强化配置，要求只读根、丢弃能力、seccomp 允许列表和真正生效的资源上限。

项目最适合的是团队自己选择运行的 Agent 代码、CI 步骤、构建脚本和本地代码单元。它明确不建议把来自陌生租户的主动恶意代码放在与其他客户共享的同一内核上；内核提权漏洞依然可能逃逸，无特权用户 namespace 本身也有历史攻击面。面向敌对多租户时，Firecracker 一类 microVM 仍多一层硬件虚拟化边界。

1.52MB 也不是凭空来的。项目只依赖 Rust 的 libc crate，拉取镜像时调用系统的 curl 和 tar，自己解析 OCI 清单与层元数据。小依赖面有利于审计，但手写 JSON、镜像层和归档处理同样扩大了项目自己的正确性责任。当前 CLI 尚未到 1.0，GPU 隔离仍在路线图上。

对 Agent 平台而言，启动快不是唯一指标。真正要看的是网络是否默认关闭、挂载是否越界、输出与超时能否截断、镜像是否验证、密钥是否离开环境变量，以及沙箱失败时系统是否拒绝继续。kern 至少把这些问题放进了公开威胁模型。

关键事实

• 项目报告 OCI 容器冷启动约 3.5 毫秒，空闲时无常驻守护进程。
• 默认无 Root，使用 namespace、seccomp、能力裁剪和 cgroup v2。
• 提供 Python、Node 与 MCP 封装，面向一次性代码执行。
• 共享 Linux 内核，不适合作为敌对多租户的虚拟机替代品。

OC 判断

Agent 沙箱最危险的宣传是把“容器启动成功”当成“代码已经安全”。kern 的速度值得关注，但更重要的是它把 opt-out、挂载风险和 microVM 分界写得很直白。真正采用前，仍需复跑对抗测试并固定版本，不能只信 README 基准。

为什么重要

• 对 Agent 开发者：每次调用创建新环境的成本可能降到可接受范围。
• 对平台团队：容器、资源限制和虚拟机是不同层次的控制点。
• 对开源生态：小体积减少依赖，也把更多解析与安全责任集中到项目自身。

参考来源

• GitHub：getkern/kern
• kern Security Model