panxiao81/gitea-dynamic-runner
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

调研并验证 AI agent sandbox 作为 runner provider #21

New Issue
Open
opened 2026-09-17 08:32:20 +00:00 by panxiao81 · 2 comments
panxiao81 commented 2026-09-17 08:32:20 +00:00
Owner
Copy Link
Copy Source

背景

AI agent sandbox 与一次性 CI runner 具有相同的核心生命周期：接收任务、创建隔离执行环境、注入短期能力、运行不可信代码、流式状态与日志、超时/取消、最终销毁。应优先复用成熟 sandbox provider，而不是自行实现 microVM 管理器。

本 ticket 与 #20 配合：#20 验证底层 standalone containerd + Kata；本 ticket 验证是否存在可直接提供更高层生命周期 API 的 agent sandbox。

第一优先级：Docker Sandboxes (sbx)

Docker Sandboxes 在 Linux/KVM 上为每个 sandbox 创建独立 microVM、filesystem、network 和 Docker daemon。其 -docker template 将 /var/lib/docker 放在独立 sparse block volume 上，避开 virtiofs 作为 overlayfs upper 的问题，与我们的 Docker + kind 场景高度吻合。

验证内容：

  • Ubuntu 24.04 LXC 中 /dev/kvm 透传后能否安装并启动 sbx
  • 使用 shell kit/template 创建无 host workspace mount 的 sandbox
  • sandbox 内 Docker daemon 使用 overlay2
  • kind create cluster smoke test
  • create/exec/stop/rm/prune 的退出码、幂等性、超时和孤儿回收
  • 是否存在稳定的本地 daemon API；若只有 CLI，评估其作为 provider adapter 后端的可维护性
  • headless 登录、自动化使用、版本升级、许可与对 Docker 账号的依赖
  • 冷启动、内存和磁盘占用

风险：产品处于 Early Access，安装需要 Docker 登录，公开集成面当前主要是 CLI；不能在未确认自动化与许可边界前作为长期核心依赖。

第二优先级：OpenSandbox + Kata

OpenSandbox 提供开源的 OpenAPI lifecycle contract 和 SDK，支持异步 create、get/list/delete、pause/resume、TTL、重启后 timer 恢复、诊断、资源限制及内部 execd。Docker backend 可以配置 Kata OCI runtime，因此可能形成：

runner scheduler → OpenSandbox API → Docker backend → Kata runtime → microVM

验证内容：

  • Docker backend 指定 Kata runtime 后可否稳定创建和删除 sandbox
  • TTL、server 重启恢复、删除重试与 orphan cleanup 是否满足 CI 语义
  • runner OCI image 能否作为长运行 entrypoint，并由 scheduler 只观察生命周期
  • 如何为 sandbox 提供 block-backed /var/lib/docker，确保 overlay2/kind 可用
  • 是否可以禁用不需要的 execd、proxy、snapshot 等 agent-specific 能力，保持部署轻量

参考但暂不部署

kubernetes-sigs/agent-sandbox

Sandbox/SandboxClaim/SandboxTemplate/SandboxWarmPool CRD 的生命周期、claim、TTL、pause/resume 和 warm pool 设计很值得借鉴，也可直接结合 Kata RuntimeClass；但它要求 Kubernetes，会重新引入维护第二集群的问题，因此当前只作为协议与状态机参考。

E2B runtime

E2B 是完整开源 Firecracker sandbox 平台，提供快照恢复、lazy memory、COW rootfs、API/data-plane 分离与节点 orchestrator，架构高度匹配。但自托管栈包含 Nomad、Postgres/Redis、对象存储以及更多控制面组件，对当前单 runner host 明显过重。

OpenSandbox 标准

即使最终不部署 OpenSandbox server，其 lifecycle OpenAPI、状态机、TTL/renew、runtime provider interface 和 diagnostics contract 也可作为我们内部 provider API 的参考，避免自行发明语义。

排除项

  • Daytona OSS：上游已宣布停止维护并迁至私有代码库
  • Ignite：已归档
  • 只封装 Firecracker API、仍要求调用方自行管理网络/磁盘/恢复的库：不能解决当前问题
  • 过新的单人/小型项目在缺少故障恢复验证前不进入主路径

验收标准

  • Docker Sandboxes 完成 Docker overlay2 + kind 实机 smoke test
  • 明确 sbx 是否有可依赖的 headless/API/许可路径
  • OpenSandbox + Kata 完成最小 create/delete/TTL smoke test，或记录明确阻塞
  • 对比 #20 的直接 containerd + Kata：部署复杂度、冷启动、资源占用、恢复能力、API 稳定性
  • 选出长期 provider，并将未选方案及原因记录到设计文档
## 背景 AI agent sandbox 与一次性 CI runner 具有相同的核心生命周期：接收任务、创建隔离执行环境、注入短期能力、运行不可信代码、流式状态与日志、超时/取消、最终销毁。应优先复用成熟 sandbox provider，而不是自行实现 microVM 管理器。 本 ticket 与 #20 配合：#20 验证底层 standalone containerd + Kata；本 ticket 验证是否存在可直接提供更高层生命周期 API 的 agent sandbox。 ## 第一优先级：Docker Sandboxes (`sbx`) Docker Sandboxes 在 Linux/KVM 上为每个 sandbox 创建独立 microVM、filesystem、network 和 Docker daemon。其 `-docker` template 将 `/var/lib/docker` 放在独立 sparse block volume 上，避开 virtiofs 作为 overlayfs upper 的问题，与我们的 Docker + kind 场景高度吻合。 验证内容： - Ubuntu 24.04 LXC 中 `/dev/kvm` 透传后能否安装并启动 `sbx` - 使用 `shell` kit/template 创建无 host workspace mount 的 sandbox - sandbox 内 Docker daemon 使用 overlay2 - `kind create cluster` smoke test - `create/exec/stop/rm/prune` 的退出码、幂等性、超时和孤儿回收 - 是否存在稳定的本地 daemon API；若只有 CLI，评估其作为 provider adapter 后端的可维护性 - headless 登录、自动化使用、版本升级、许可与对 Docker 账号的依赖 - 冷启动、内存和磁盘占用 风险：产品处于 Early Access，安装需要 Docker 登录，公开集成面当前主要是 CLI；不能在未确认自动化与许可边界前作为长期核心依赖。 ## 第二优先级：OpenSandbox + Kata OpenSandbox 提供开源的 OpenAPI lifecycle contract 和 SDK，支持异步 create、get/list/delete、pause/resume、TTL、重启后 timer 恢复、诊断、资源限制及内部 execd。Docker backend 可以配置 Kata OCI runtime，因此可能形成： ```text runner scheduler → OpenSandbox API → Docker backend → Kata runtime → microVM ``` 验证内容： - Docker backend 指定 Kata runtime 后可否稳定创建和删除 sandbox - TTL、server 重启恢复、删除重试与 orphan cleanup 是否满足 CI 语义 - runner OCI image 能否作为长运行 entrypoint，并由 scheduler 只观察生命周期 - 如何为 sandbox 提供 block-backed `/var/lib/docker`，确保 overlay2/kind 可用 - 是否可以禁用不需要的 execd、proxy、snapshot 等 agent-specific 能力，保持部署轻量 ## 参考但暂不部署 ### kubernetes-sigs/agent-sandbox Sandbox/SandboxClaim/SandboxTemplate/SandboxWarmPool CRD 的生命周期、claim、TTL、pause/resume 和 warm pool 设计很值得借鉴，也可直接结合 Kata RuntimeClass；但它要求 Kubernetes，会重新引入维护第二集群的问题，因此当前只作为协议与状态机参考。 ### E2B runtime E2B 是完整开源 Firecracker sandbox 平台，提供快照恢复、lazy memory、COW rootfs、API/data-plane 分离与节点 orchestrator，架构高度匹配。但自托管栈包含 Nomad、Postgres/Redis、对象存储以及更多控制面组件，对当前单 runner host 明显过重。 ### OpenSandbox 标准 即使最终不部署 OpenSandbox server，其 lifecycle OpenAPI、状态机、TTL/renew、runtime provider interface 和 diagnostics contract 也可作为我们内部 provider API 的参考，避免自行发明语义。 ## 排除项 - Daytona OSS：上游已宣布停止维护并迁至私有代码库 - Ignite：已归档 - 只封装 Firecracker API、仍要求调用方自行管理网络/磁盘/恢复的库：不能解决当前问题 - 过新的单人/小型项目在缺少故障恢复验证前不进入主路径 ## 验收标准 - [ ] Docker Sandboxes 完成 `Docker overlay2 + kind` 实机 smoke test - [ ] 明确 `sbx` 是否有可依赖的 headless/API/许可路径 - [ ] OpenSandbox + Kata 完成最小 create/delete/TTL smoke test，或记录明确阻塞 - [ ] 对比 #20 的直接 containerd + Kata：部署复杂度、冷启动、资源占用、恢复能力、API 稳定性 - [ ] 选出长期 provider，并将未选方案及原因记录到设计文档
panxiao81 commented 2026-09-17 08:38:42 +00:00
Author
Owner
Copy Link
Copy Source

更正：Agent Sandbox 不是可选的 microVM provider

kubernetes-sigs/agent-sandbox 源自 Google Cloud/GKE 的 Agent Sandbox 模型；GCP 托管路径的明确隔离 backend 是 GKE Sandbox（gVisor）。它本身是 Kubernetes 上的 Sandbox CRD/controller，不实现 VMM、容器 runtime 或独立计算 backend。

当前 OSS 仓库确实允许在 PodTemplate 中设置任意 RuntimeClass，并新增了 Kata/minikube、Kata on GKE 和 Firecracker VMM 示例；但这属于“把已安装好的 Kata runtime 接到 Pod 上”的可配置集成，不应表述为 Agent Sandbox 自己提供或管理 Kata backend，更不能把它当成 standalone microVM provider。

对本项目的结论：

  • gVisor 路线不满足需要在 sandbox 内运行 Docker daemon/kind 的目标
  • Agent Sandbox 仍要求 Kubernetes，不能解决“不维护第二集群”的约束
  • Kata 示例只证明 CRD 可以调度到外部 Kata RuntimeClass；底层安装、VMM、存储和节点生命周期仍由 Kubernetes/containerd/Kata 负责
  • 因而将 Agent Sandbox 从 provider 候选中移除，只参考其 SandboxClaim、WarmPool、TTL 与状态机设计

本 ticket 的可执行候选保持为 Docker Sandboxes、OpenSandbox + Kata，以及 #20 的 standalone containerd + Kata。

## 更正：Agent Sandbox 不是可选的 microVM provider `kubernetes-sigs/agent-sandbox` 源自 Google Cloud/GKE 的 Agent Sandbox 模型；GCP 托管路径的明确隔离 backend 是 GKE Sandbox（gVisor）。它本身是 Kubernetes 上的 Sandbox CRD/controller，不实现 VMM、容器 runtime 或独立计算 backend。 当前 OSS 仓库确实允许在 PodTemplate 中设置任意 `RuntimeClass`，并新增了 Kata/minikube、Kata on GKE 和 Firecracker VMM 示例；但这属于“把已安装好的 Kata runtime 接到 Pod 上”的可配置集成，不应表述为 Agent Sandbox 自己提供或管理 Kata backend，更不能把它当成 standalone microVM provider。 对本项目的结论： - gVisor 路线不满足需要在 sandbox 内运行 Docker daemon/kind 的目标 - Agent Sandbox 仍要求 Kubernetes，不能解决“不维护第二集群”的约束 - Kata 示例只证明 CRD 可以调度到外部 Kata RuntimeClass；底层安装、VMM、存储和节点生命周期仍由 Kubernetes/containerd/Kata 负责 - 因而将 Agent Sandbox 从 provider 候选中移除，只参考其 SandboxClaim、WarmPool、TTL 与状态机设计 本 ticket 的可执行候选保持为 Docker Sandboxes、OpenSandbox + Kata，以及 #20 的 standalone containerd + Kata。
panxiao81 commented 2026-09-17 08:40:42 +00:00
Author
Owner
Copy Link
Copy Source

许可证核查：Docker Sandboxes 不适合作为长期核心 provider

docker/sbx-releases 的 LICENSE 仅声明 Copyright © 2026 Docker Inc. All rights reserved，仓库明确标注 Proprietary。它不是 Apache-2.0/MIT 等开放源码组件，release 仓库主要发布二进制、issue 和安装信息。

Docker 当前 FAQ 声明：sbx CLI 可免费用于商业和专业工作、无 per-seat fee；目前只有组织治理（集中网络/文件系统/MCP policy、sign-in enforcement、audit log）需要额外付费。但这属于 Docker 当前产品 entitlement 和服务条款，不是不可撤回的开源授权：

  • 使用必须登录免费 Docker 账号
  • 受 Docker Subscription Service Agreement、产品计划和未来 entitlement 调整约束
  • 无源代码保障，无法自行维护或修复 daemon/provider
  • 自动化 CI 是否允许 service account/headless 长期运行、并发限制和未来定价仍需单独确认

因此调整优先级：

  • sbx 可以作为短期技术验证与行为参考，尤其验证独立 /var/lib/docker block volume 对 kind 的效果
  • 不将其作为 homelab CI 的默认或长期核心 provider
  • 长期候选优先保持开源、可自行维护的 standalone containerd + Kata，以及 OpenSandbox + Kata
  • 若进行 sbx PoC，不应让 workflow、消息协议或镜像格式依赖其私有 CLI/kit 语义
## 许可证核查：Docker Sandboxes 不适合作为长期核心 provider `docker/sbx-releases` 的 LICENSE 仅声明 `Copyright © 2026 Docker Inc. All rights reserved`，仓库明确标注 **Proprietary**。它不是 Apache-2.0/MIT 等开放源码组件，release 仓库主要发布二进制、issue 和安装信息。 Docker 当前 FAQ 声明：`sbx` CLI 可免费用于商业和专业工作、无 per-seat fee；目前只有组织治理（集中网络/文件系统/MCP policy、sign-in enforcement、audit log）需要额外付费。但这属于 Docker 当前产品 entitlement 和服务条款，不是不可撤回的开源授权： - 使用必须登录免费 Docker 账号 - 受 Docker Subscription Service Agreement、产品计划和未来 entitlement 调整约束 - 无源代码保障，无法自行维护或修复 daemon/provider - 自动化 CI 是否允许 service account/headless 长期运行、并发限制和未来定价仍需单独确认 因此调整优先级： - `sbx` 可以作为短期技术验证与行为参考，尤其验证独立 `/var/lib/docker` block volume 对 kind 的效果 - 不将其作为 homelab CI 的默认或长期核心 provider - 长期候选优先保持开源、可自行维护的 standalone containerd + Kata，以及 OpenSandbox + Kata - 若进行 `sbx` PoC，不应让 workflow、消息协议或镜像格式依赖其私有 CLI/kit 语义
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
panxiao81 (Xiao Pan)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: panxiao81/gitea-dynamic-runner#21