当 AI Agent 开始执行 Shell、读写文件、安装依赖时，风险模型已经和普通聊天应用完全不同。真正值得讨论的，不只是 Agent “能不能运行代码”，而是这些代码究竟运行在哪里、拥有哪些权限，以及异常时会不会越过原本的安全边界。
最近关注到一个开源项目 Hullwork Sandbox，它把这部分能力做成了独立的自托管基础设施。
它解决什么问题
Hullwork Sandbox 把每个 Agent Runtime 放进 Kubernetes Pod，并通过 gVisor RuntimeClass 提供隔离。上层可以使用 Python SDK、CLI 或 MCP Bridge 调用；Workspace、身份、配额和运行时生命周期则由控制面统一管理。
它没有绑定某一种模型或 Agent Framework，因此可以作为通用的执行层接入 Coding Agent、数据分析 Agent或自动化运维 Agent。
我觉得比较好的几个设计
1. 安全约束落到了具体配置
每个 Runtime 以非 root 用户运行，根文件系统只读，不挂载 Kubernetes ServiceAccount Token，使用 default-deny NetworkPolicy，也不会向 Agent 暴露 Docker Socket。
这些配置不意味着“绝对安全”，但至少比一句笼统的“运行在容器里”更容易检查。
2. 异常时 fail closed
如果 Control Plane 或 Runtime 不可用，任务会直接失败，不会悄悄退回宿主机执行。
我认为这是 Agent 基础设施中非常重要的原则。普通服务的降级通常是为了提高可用性，但对未知代码执行来说，错误的 fallback 可能直接绕过安全边界。此时失败通常比越权更便宜。
3. Workspace 与 Runtime 生命周期分离
停止或替换 Runtime 不会删除 Workspace，工作文件可以通过 PVC 保留。这样既能让执行环境保持短生命周期，也能支持 Coding Agent 连续多轮修改同一份代码。
Checkpoint 是显式恢复路径，而不是把进程内存或容器可写层包装成不存在的持久化承诺。
4. 支持 MCP，但不把自己做成 Agent Framework
项目提供 Python SDK、CLI 和 stdio MCP Bridge。对上层 Agent 来说，它看到的是稳定的工具协议；集群权限和运行时细节仍然留在控制面。
这种边界很清晰：模型和编排器可以替换，执行基础设施不需要跟着重写。
可验证比功能列表更重要
安全类开源项目最怕 README 很漂亮，但实际行为难以复核。Hullwork Sandbox 提供了单元与契约测试、源码验证、Quickstart 和本地 E2E。
make quickstart 会创建真实的本地 Kubernetes/gVisor 环境，并检查：
- Runtime 使用 gVisor 内核；
- 进程以非 root 身份运行；
- 根文件系统只读；
- 没有 ServiceAccount Token；
- Workspace 能跨 Runtime 保留；
- 控制面不可用时不会在宿主机执行。
项目还公开 Benchmark 的测试方法和测量边界。相比只放一个漂亮数字，我更看重这种可复核性。
我的看法
Agent 的能力越强，执行层越不应该只是应用里的一个工具函数。它应该成为独立、可审计、失败方式明确的基础设施。
Hullwork Sandbox 目前仍是 0.1.0 alpha，API 稳定性和生产成熟度都需要继续观察。但它选择的问题是对的：先把执行边界做清楚，再谈更强的自主能力。
