Harbor 接入 Docker Sandboxes：让 AI 编程代理的评测跑在隔离微虚拟机里
开源的代理评测框架 Harbor 新增 Docker Sandboxes 后端，每个评测任务都跑在独立的微虚拟机中，不再共享同一个容器。这样做既隔离了 AI 生成代码的执行环境，也能通过统一网络策略让评测结果可复现。目前该功能已进入稳定版，本地可免费使用，云端按 Docker Cloud Sandboxes 计费。
发生了什么：评测任务从「共享容器」改为「一任务一微虚拟机」
Docker 宣布，开源代理评测框架 Harbor 现已支持 Docker Sandboxes。改动之后，每个评测任务都在各自的微虚拟机（microVM，带独立内核的轻量虚拟机）里运行，而不是像过去那样所有任务共用一个容器。任务既可以在本地跑，也可以放到 Docker Cloud Sandboxes 上跑。
对做 AI 编程工具、尤其是氛围编程（vibe coding）类产品的团队来说，这是个实际影响评测流程的更新：评测环境从「能跑就行」变成了可隔离、可复现的基础设施问题。
Docker 表示，他们已在云端对 Harbor 做过 64 个并发任务的测试。这是公告里唯一一个具体的规模数字。
为什么评测编程代理必须隔离
评测一个编程代理，意味着要让它安装软件包、修改文件、执行命令，而基准测试会把这类操作重复成千上万次。Docker 工程师把这件事直接描述为「大规模运行由 AI 编写、且不可信的代码」。
更麻烦的是「奖励破解」（reward hacking）：代理并不真正完成任务，而是通过篡改测试、或者覆盖记录分数的文件，来让自己拿到及格分。Harbor 的角色是协调整个评测流程——运行任务、收集分数、记录日志，并支持 Terminal-Bench 等基准测试。它因此需要一个既隔离、又一致的执行环境。
隔离与网络策略是怎么做的
每个任务都跑在 Docker Sandbox 中。这是一个拥有独立内核的微虚拟机，代理的所有活动都被限制在虚拟机内部，碰不到宿主机、其他任务，也碰不到环境之外的任何东西。
在 Docker Cloud Sandboxes 中，网络策略可以分阶段配置：任务在环境搭建阶段可以拉取依赖，随后的代理运行阶段则限制其互联网访问。这样每个代理都在相同的网络条件下接受评测，解决了通常导致结果无法复现的问题。
得益于对 Docker Compose 的支持，Harbor 还能在单个云沙箱内运行多容器任务，让服务与边车容器（sidecar，随主服务一起部署的辅助容器）共享同一个微虚拟机。
官方没有给出哪些数据
公告没有提供启动开销、单任务成本，也没有评测分数波动的基准数据。唯一的具体规模数据就是前面提到的 64 个并发任务；如果需要更高的上限，得通过 Docker 官方渠道申请。对单任务延迟或成本敏感的团队，只能自己先测一遍。
至于沙箱内的奖励破解——例如代理改写自己有写权限的测试文件——网络限制堵住了一条作弊路径，但公告没有说明这类行为如何防范。
版本、依赖与运行方式
该集成此前已在 Docker Sandboxes 的夜间构建中提供，Docker 表示已于 10 月 23 日进入稳定版。Harbor 通过 sbx 扩展安装，夜间构建版本固定为 0.24.1.dev202610150414。
在云端运行需要：一个已开启云端访问权限的 Docker 账户，以及一个具备 Cloud Sandboxes 权限的个人访问令牌（PAT）。Harbor 会从 SBX_DOCKER_USERNAME 和 SBX_DOCKER_PAT 两个环境变量中读取这些信息。
运行时用 -e sbx 标志选择沙箱环境，例如：
harbor run -t hello-world/hello-world -a oracle -e sbx
本地选项免费，云端扩展则取决于 Docker Cloud Sandboxes 服务。
本地与云端的差别
已在用 Harbor 的团队可以立刻在夜间构建版上试用，或者等 10 月 23 日的稳定版。本地运行需要先执行 sbx login 登录 Docker Sandboxes CLI，然后在 Harbor 命令中加上 --ek target=local 参数。
需要注意，本地集成目前只支持公共模式和无网络模式，具体取决于机器上已有的沙箱策略。用于保障评测公平性的细粒度网络策略目前只在云沙箱中提供，因此需要这类控制的团队应规划走云端方案。
在沙箱后端版图里的位置
这次集成同时扩展了两边：Harbor 的沙箱后端列表进一步扩大，Docker Sandboxes 能接入的代理运行时范围也变宽了。
Harbor 此前已支持一批云沙箱提供商，包括 Daytona、Modal、E2B、Runloop、Tensorlake、LangSmith、Blaxel、Novita Sandbox、EC2 和 Beam，细节可在其 GitHub 仓库查看。Docker 之前最新加入的是 LangSmith 沙箱：安装 langsmith 扩展即可在 LangSmith 的生产沙箱中运行评测任务，操作界面与 Daytona、E2B、Modal 完全一致。
Harbor 的云部署文档推荐 Daytona 作为首选，原因之一是它支持通过 docker-compose.yaml 做多容器部署，而 Modal、E2B 和 Runloop 目前不具备这一能力。
Docker Sandboxes 正从本地开发工具扩展为一套代理运行基础设施：Harbor 用它做可重现的 AI 代理评估，NanoClaw 借助它一键部署，GitHub Agentic Workflows 也将其列入受支持的运行时。这些变化的共同点是，代理不再直接接触宿主机的 Docker 守护进程，而是运行在独立的 MicroVM 中。
其他代理平台也在接入 Docker Sandboxes
Docker 正在将沙箱能力扩展到 Harbor 之外的更多代理平台。
NanoCo 已与 Docker 达成合作：只需一条命令，就能把基于 Claw 的代理平台 NanoClaw 部署到 Docker 的 MicroVM 沙箱中。
GitHub Agentic Workflows 则在 2026 年 7 月将 Docker Sandboxes 加入受支持的代理运行时列表，该功能随 gh-aw 0.82.9 版本发布。
独立守护进程带来的实际好处
按 Docker 操作指南的说明，每个沙箱都运行自己的 Docker 守护进程。这对开发者意味着：代理可以执行基于 Testcontainers 的集成测试，而不需要把宿主机的 Docker Socket 挂载进容器。
挂载宿主 Socket 一直是个高风险做法：一旦代理行为失控，就等于把整台机器的容器控制权交了出去。独立守护进程既避免了这一暴露面，也让测试环境更接近真实、更容易复现。
从本地沙箱走向云端
Harbor 的这次集成，建立在 9 月 24 日发布的 Cloud Sandboxes 功能之上。该版本把本地沙箱隔离能力延伸到 Docker 管理的云基础设施，代理工作流因此不再依赖开发者本机的运行状态，即使笔记本电脑关机也能继续执行。
据第三方报道，云沙箱的默认会话时长为 1 小时，最长可延至 24 小时；处于暂停状态的沙箱不计计算费用。
同一版本还推出了以 OCI 镜像形式打包的 Kits，Docker 已承诺将 Kits 规范提交给 CNCF，交由社区维护。