最近在补 AI Agent 最容易被一句“工具调用成功”带过的两块基础设施：
- 执行边界：Agent 能跑 shell ，不代表应该碰到宿主机。
- 交付证据：控制器返回成功，不代表用户真的能访问网站。
于是拆成了两个 MIT 开源项目：
- Sandbox：每个 Runtime 都是 Kubernetes 上的 gVisor Pod ，默认 non-root 、只读根文件系统、无 ServiceAccount token 、default-deny NetworkPolicy 。Control Plane 或 Runtime 不可用时直接失败，不会偷偷降级到宿主机执行。
- Site：Agent 通过 HTTP / CLI / MCP 提交部署，Operator 等工作负载 Ready 后，会自己请求真实地址，把 HTTP 状态码和响应体 SHA-256 写入
status.verification。也就是把 “deployed” 从一句话变成可检查的测量结果。
Sandbox 在本地参考环境里的实测：冷启动 p50 2.497s / p95 2.789s ，热执行 p50 35.72ms / p95 48.08ms 。完整方法和“不代表什么”也写进了 benchmark report ，没有拿单机数据冒充云上多租户结论。
两个项目都还是 alpha ，我比较想听反对意见，尤其是：
- 这个 trust boundary 有没有看起来安全、实际可绕过的地方？
make quickstart的本地环境成本是否太高？- 对 Agent 来说，HTTP 状态码 + body digest 够不够称为“部署证据”？下一层应该验证什么？
项目地址：
- Sandbox: https://github.com/hullwork/sandbox
- Site: https://github.com/hullwork/site
- 架构总览: https://hullwork.github.io/
欢迎直接挑刺，具体到 threat model 、Kubernetes 边界和使用体验都行。
Select Language