任何在云端运行代码的 Agent 都需要某种形式的沙箱。Brian Giori（Amplitude 工程师）写了篇长文，复盘他们为 Amplitude 自建 Agent 平台沙箱层的完整架构，是一篇相当硬核的工程实践。
建还是买
团队首先明确回答了"要不要自己建"这个问题。Vendor 方案（E2B、Daytona 等）下午就能跑起来，冷启动做得好，按秒计费，但代价是：数据主权（虽然部分支持托管私有化部署）、端到端控制权（只能用到 vendor 提供的能力）、以及深度定制能力（偏离标准路径后越来越难）。
Amplitude 选择自建，原因是他们需要严格的数据隔离、自定义的与现有集群绑定的网络策略，以及与 Agent 平台本身深度契合的沙箱开发体验。
核心架构
每个 Agent 运行获得独立的短生命周期微 VM Pod。Agent 平台拥有完整的生命周期管理，网络默认锁定，Secrets 永远不进入 Pod。
控制面是单一的 SandboxBackend 接口，工具和 Agent 运行时持有一个 backend 实例，不直接操作 Kubernetes。这个接口在云环境用 Kubernetes 实现，本地开发则启动 Docker 容器。
公开的方法很精简：get_or_create() 创建或返回沙箱，reset() 删除并重建，delete() 清理。一个沙箱的实际控制通过一个运行在 Pod 内 PID 1 位置的 FastAPI 服务器代理，每次调用都在后台自动刷新 idle-TTL。
Secrets 注入
Secrets 通过独立的代理层注入。这个代理运行在沙箱外，维护所有敏感的凭证信息，当 Pod 启动时通过一个 per-sandbox 的 proxy token 授权，只在需要时才把具体的 secret 注入到 Pod 的文件系统，从不把原始凭证暴露给 Pod 内的任何进程。
Plugin 系统
每个沙箱支持插件机制，在 Pod 就绪后、返回给调用方之前，运行每个插件的 setup()。典型的插件用途包括：克隆特定代码仓库、写入配置文件、预装特定的 CLI 工具等。
这个设计让沙箱的初始状态可以根据不同任务需求高度定制，而不需要为每种场景维护不同的基础镜像。
Amplitude 是数据分析平台，文章是他们在生产环境验证过的架构。