Cloud 托管 Sandbox
Appaloft Cloud 提供一个开箱即用的托管 Execution Sandbox：不需要注册自己的服务器，也能创建、连接、 在其中执行命令/文件/进程操作，并在使用结束后清理。它和自托管 Appaloft 使用的是同一套 Sandbox operation 与 SDK；Cloud 只是额外提供托管 worker、隔离策略和凭据代理，让你不用自己运维底层机器。
与自托管 Sandbox 的关系
Sandbox 本身是 Appaloft 的公共能力：创建、暂停/恢复、执行命令、文件传输、进程与端口管理、快照和 清理都通过同一套 CLI/HTTP/API/SDK 完成，不区分 Cloud 或自托管。Cloud 托管 Sandbox 的区别只在于 谁提供底层机器：
- 自托管：Sandbox 运行在你注册到 Appaloft 的服务器上，由你负责机器本身的可用性和成本。
- Cloud 托管：Sandbox 运行在 Appaloft Cloud 提供或代管的 worker 上；你只拿到一个 scoped Sandbox handle，看不到也不需要管理底层 VPS/SSH/Docker 细节。
如果你的组织已经在 Appaloft Cloud 中注册了自己的服务器，Cloud 也可以把 Sandbox 放到这些已注册 服务器上运行，行为与”Cloud 托管 worker”一致，只是底层机器换成了你自己的注册服务器。
隔离模型
Cloud 托管 Sandbox 首批可用的隔离等级是如实标记的 container-trusted：一个真实的容器边界，但不
承诺对抗恶意多租户级别的强隔离。更强的隔离等级（例如基于 gVisor 的沙箱运行时）会在可用并通过验收
后逐步开放；页面会在隔离等级变化时更新说明，不会静默把 container-trusted 包装成”完全安全隔离”
去宣传。
高风险或异常使用模式的 Sandbox 创建请求可能被 admission 策略拒绝，或被要求使用更高隔离等级。
凭据与网络边界
- Cloud 不会把底层 VPS、SSH、Docker 或服务器凭据字段暴露给调用方；你得到的始终是一个 scoped Sandbox handle 和 Appaloft 签发的 token，而不是可以直接连接底层机器的凭据。
- Sandbox 需要访问外部服务（例如模型 API、Git 凭据）时，Cloud 通过短期、目的绑定的凭据授予下发， 不会把长期密钥明文注入到 Sandbox 环境变量或日志中；凭据代理未就绪时请求会显式失败，而不是退化 成明文注入。
- Sandbox 默认没有任意公网出站权限；需要访问特定外部服务时，通过显式声明的凭据/网络能力获得, 而不是打开整个 Sandbox 的出站网络。
配额与可用性
Sandbox 的并发数量、运行时长（TTL）、资源规格等由你组织当前的 entitlement 决定。达到配额上限时， 创建/恢复请求会返回明确的配额错误，而不是排队等待或静默降级；具体配额数值请以 Cloud Console 中 组织设置页面展示的当前值为准，本页不维护会随定价调整而变化的具体数字。
常见问题
Sandbox 和部署（Deployment）是同一个概念吗？ 不是。Deployment 面向长期运行的应用；Sandbox 面向 短时、交互式或 Agent 驱动的执行环境，有自己的暂停/恢复/快照/清理生命周期。两者可以共存，但不要 把 Sandbox 当作部署目标使用。
普通 Docker 容器和 Cloud 托管 Sandbox 有什么区别？ Cloud 托管 Sandbox 在容器边界之上叠加了 租户隔离、admission 策略、凭据代理和审计；一个裸容器不提供这些保证。
相关任务
- Agent 与 Sandbox 分组下的 Agent Workspace 页面：了解 Agent Workspace 如何使用 Sandbox 承载 运行环境。
- CLI/HTTP/API 参考：
sandboxesoperation 的完整命令与字段说明。