做了两个给 AI Agent 用的基础设施项目： gVisor 沙箱 + 可验证的网站部署，求挑刺

最近在补 AI Agent 最容易被一句“工具调用成功”带过的两块基础设施：

1. 执行边界：Agent 能跑 shell ，不代表应该碰到宿主机。


2. 交付证据：控制器返回成功，不代表用户真的能访问网站。

于是拆成了两个 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 边界和使用体验都行。