算力提供方现在可以决定 Orbs 的运行地点。Amp 提供了一套工具，允许团队利用自有基础设施来承载这些沙箱环境。只要基础设施具备快速启动新机器、迅速休眠与恢复实例、长期保持运行状态和支持缩放至零的能力，Orbs 的逻辑就能完整迁移到私有环境内。
运行机制
amp orb provider 是这一流程的核心组件。部署在自己的网络环境中，它保持与 Amp 服务的长连接，监听并接收来自后端的请求。这些请求主要涉及实例的创建（spawn）、暂停（pause）和销毁（delete）。一旦收到指令，Provider 会调用本地预先配置的脚本或程序来处理具体的资源操作。
你可能感兴趣：未命名文章
灵活对接各种环境
如何响应这些请求完全取决于基础设施的特性。开发者只需编写一个分派脚本，将 amp orb provider 指向该脚本即可。比如基于 Docker 的部署场景，脚本可以利用容器引擎来管理生命周期：通过 docker start 或 docker run 来创建或恢复实例，通过 docker stop 实现暂停，通过 docker rm 完成清理。所有操作均通过环境变量传递标识符和配置信息，不需要开放入站端口，网络模型特别简洁。
- Docker 方案适合已有容器编排基础的用户，通过执行 exec 命令启动 amp orb bootstrap 来初始化环境。
- E2B 云原生方案利用 E2B 的 SDK 和模板机制，可以直接调用 Sandbox 类来创建、查询和管理无服务器化的计算环境，配合模板构建可以实现标准化的资源准备。
- K8s 集群通过对接 Kubernetes API，可以将每个 Orb 实例映射为 Pod，充分利用集群的弹性伸缩能力。
- 其他托管服务如 Apple 容器、Modal、Vercel 等，只要能实现异步的实例启停，都能通过适配层接入。
对于复杂的应用逻辑，也可以采用 Node.js 等语言编写分派程序。以 E2B 为例，代码中会先查询是不是存在匹配 ID 的实例，根据当前操作类型决定是新建沙箱还是唤醒现有实例。整个过程通过标准化的环境变量（如 ORB_ID、ORB_TOKEN）传递上下文，确保了与 Amp 核心服务的解耦与互通。这种设计让企业能保留对底层算力与网络隔离的掌控权，同时复用 Amp 提供的高层交互体验。
