2026年7月，GitHub Agentic Workflows正式将Docker Sandboxes纳入支持的代理运行时。这意味着在CI环境中，AI编码代理可以对其运行环境拥有广泛的控制权——包括运行Docker容器——同时整个环境被隔离在microVM中，并配有网络策略和密钥注入机制，符合当前AI隔离的最佳实践建议。
代理隔离为何关键
实用的编码代理远不止读取仓库和生成补丁那么简单。它们会安装工具、执行任意shell命令、运行项目代码、启动数据库，偶尔还会对"清理"这个词产生一些出人意料的解读。这些能力让代理变得真正有用，但直接访问CI运行器也会让每一个错误产生更大的影响范围。
现在，随着sbx的集成，代理的边界变成了一个可丢弃的环境：内部拥有相当大的自由度，对外部资源的访问则被严格限制。
实际运行示例
作者搭建了一个小型示例来验证实际效果。代理在GitHub托管的Ubuntu运行器上运行，进入Docker Sandbox（sbx），使用Testcontainers配合PostgreSQL执行Java集成测试套件，发现一个有意植入的bug，修复它，然后开启一个草稿pull request。GitHub Agentic Workflows开箱即用地提供了这一集成，无需为actions做任何自定义配置。
GitHub Actions仍然是底层的CI系统：它负责调度任务、提供Ubuntu运行器、管理权限和密钥，并记录执行结果。
gh-aw与docker-sbx的架构
GitHub Agentic Workflows（通常缩写为gh-aw）是一个开源的GitHub CLI扩展和编译器。你可以用Markdown文件描述一个代理工作流：YAML frontmatter配置执行参数，正文部分定义代理的任务。运行gh aw compile会将源文件编译成带有.lock.yml后缀的标准GitHub Actions工作流。
整个链路如下：
- Markdown工作流文件 →
gh aw compile→ 生成的GitHub Actions .lock.yml - 在ubuntu-24.04上运行 → Docker Sandbox microVM → Copilot代理及其工具
docker-sbx属于gh-aw的代理运行时配置。runs-on字段仍然选择ubuntu-24.04，编译后的文件也是标准的GitHub Actions工作流。它会安装沙箱工具、进行认证、检查运行器、在沙箱中启动代理，最后清理所有资源。该集成随gh-aw 0.82.9版本发布。
配置示例
以下是示例中sandbox-explorer.md的配置：
---name: "Docker Sandboxes sample: exploratory test"on: workflow_dispatch:runs-on: ubuntu-24.04permissions: contents: read copilot-requests: writeengine: copilotnetwork: allowed: - defaults - github - containers - javasandbox: agent: id: awf runtime: docker-sbx sudo: truetools: edit: bash: [":*"]safe-outputs: create-pull-request: title-prefix: "&q"这份配置展示了几个关键点：网络策略通过network.allowed精确控制代理可访问的域；sandbox.agent.runtime指定使用docker-sbx运行时；sudo: true允许代理在沙箱内获得超级用户权限；tools定义了代理可用的工具集。
对于希望在CI中安全运行AI编码代理的团队来说，这种模式提供了一个值得参考的基线：代理拥有完成任务所需的自由度，但所有操作都被限制在可丢弃的隔离环境中，外部影响被降到最低。
热门跟贴