配了三年代理编码，每次想让 AI agent 在 CI 里跑个集成测试都要把整个 runner 交出去——今天 Docker Sandboxes 用 microVM 把这件事彻底隔开了

配了三年代理编码，每次想让 AI agent 在 CI 里跑个集成测试都要把整个 runner 交出去——今天 Docker Sandboxes 用 microVM 把这件事彻底隔开了

问题：AI agent 进 CI，手里握着一把钥匙

让 AI coding agent 在 CI 里干活，这事听起来很美：发现 bug 自己修、测试没过自己调、不用等人类介入。但真上手的团队，几乎都在同一堵墙上撞了一周。

核心矛盾是这样的：agent 需要真实权限——安装依赖、启动数据库、跑任意 shell 命令。但 GitHub-hosted runner 的权限边界，就是整台机器的权限边界。一旦 agent 被提示注入攻击，或者单纯判断失误，爆炸半径就是你的所有密钥、所有网络访问权限、所有能 reach 到的生产环境。

要么把 agent 锁死到毫无用处，要么把 runner 完全交出去——二选一，两边都是坑。

解法：microVM 隔离，让 agent 住进自己的虚拟机

2026 年 7 月，GitHub Agentic Workflows（gh-aw）通过 Docker Sandboxes 引入了 docker-sbx 运行时。这是目前第一个不需要接入第三方 sandbox API 就能实现的方案。

隔离的核心逻辑：

• microVM，不是容器：每个 sandbox 有自己的内核、文件系统、网络栈，不是共享内核的容器隔离。agent 在里面拿到完整的 root 权限和私有 Docker daemon，但完全没有路径回到 host 的 Docker socket 或文件系统。
• 网络代理拦截：所有出口流量经过 host 侧代理，localhost 和云元数据端点（169.254.169.254 这条经典的 SSRF 窃密路径）默认被屏蔽。授权的外部调用由代理自动注入 auth header，agent 进程本身不持有原始 token。
• 三档网络策略：Open（全部允许，适合原型）、Balanced（默认拒绝，按需放行 AI API / 包仓库 / 代码托管）、Locked Down（白名单模式）。
• safe-outputs 拆分：PR 创建发生在独立的 job 里，运行在 sandbox 外部，使用范围收窄的 GitHub token，强制 draft 模式，文件写入限制在 src/**。agent 在 sandbox 里几乎可以为所欲为，但最终什么能进入你的主干，由人类说了算。

一个真实案例：Java 21 服务 + Testcontainers PostgreSQL 集成测试，agent 发现了一个邮件格式化的 bug 并修了它、提了 draft PR，整个流程在标准 ubuntu-24.04 runner 上用了 11 分 16 秒跑完。没有特殊的底层基础设施需求。

三个现实障碍

1. 自托管 runner 暂时用不了

microVM 层依赖 KVM 虚拟化，普通 macOS/Windows 自托管 runner 跑不起来。如果你的团队跑在标准 Linux 虚拟机上，需要确认虚拟化支持。

2. 大项目性能数据尚缺

Docker 官方没有发布 cold-start 和吞吐 benchmark。有第三方评测提到大项目存在性能退化，这个在正式上生产前值得自己跑一轮压测。

3. 治理是按 workflow 配置的

Docker AI Governance（单独付费层）提供的 org 级网络/工具策略和审计日志是 fleet-wide 的。基础 sandbox runtime 本身是按单个 workflow 配置的，多 repo 大规模铺开时需要提前设计治理路径。

三步下一步

第一步（5 分钟）：跑通官方 demo

运行以下命令，在 workflow_dispatch 上跑一遍 sandbox-explorer 模板：

gh extension install github/agentic-workflows
gh aw compile –runtime docker-sbx

看看 microVM 启动时间和基础网络策略是否满足你的需求。

第二步：改造现有的 agent-driven CI 流程

把现有的 agent job 拆成 sandboxed agent + safe-outputs 两段，YAML 配置包含：agent 使用 docker-sbx 运行时、网络允许列表、safe-outputs 限制 draft PR 和文件路径。

第三步：开 Monitor 模式观察网络流量

在 Balanced 策略下运行一段时间，看 agent 实际访问了哪些端点，再收紧到 Locked Down。白名单没列全之前不要开 Enforce，避免 CI 莫名 fail。

一句话总结：AI coding agent 进 CI 最大的安全风险是全权委托，Docker Sandboxes 把这件事变成了授予受限空间加独立复核，不是银弹，但让之前无法落地的场景第一次可以安全地跑起来。

如果你现在让 agent 在 CI 里跑集成测试还是直接给 full runner 权限，是时候换思路了。