Harbor 接入 Docker Sandboxes，AI 代理评估转入 MicroVM 隔离模式

一句话结论

Harbor 支持 Docker Sandboxes，评估任务在 MicroVM 中隔离运行，本地免费但细粒度网络策略仅限云端。

关键要点

• Harbor 通过 sbx 扩展支持 Docker Sandboxes，每个评估任务在独立的微虚拟机（MicroVM）中运行，不再共享容器。
• Docker 已在云端对 Harbor 进行了 64 个并发任务的测试；如需更高并发上限，可通过 Docker 官方联系渠道申请。
• 集成功能于 10 月 23 日进入稳定版；夜间构建版本固定为 0.24.1.dev202610150414。
• 本地集成仅支持公共模式和无网络模式；细粒度网络策略（允许设置期拉取依赖、限制代理运行期互联网访问）仅与云沙箱绑定。
• 云端运行需启用云端访问权限的 Docker 账户，并通过环境变量 SBX_DOCKER_USERNAME 和 SBX_DOCKER_PAT 认证。

背景与事实

开源代理评估框架 Harbor 宣布支持 Docker Sandboxes。这一变更使得每个评估任务都能在各自的微虚拟机（microVM）中运行。此前，评估任务可能共享同一个容器环境，现在则运行在隔离的环境中。这种隔离提升了性能，因为编码代理（coding agent）在执行任务时会安装软件包、编辑文件并执行命令，基准测试会重复执行这些操作数千次。Docker 工程师将此描述为大规模运行由 AI 编写的不可信代码。

Harbor 负责协调管理工作，包括运行任务、收集分数和记录日志。它支持 Terminal-Bench 等基准测试，并且需要一个既隔离又一致的执行环境。特别值得注意的是“奖励破解”（reward hacking）现象：代理可能通过篡改测试或覆盖记录其分数的文件来获得及格分数，而非真正地完成任务。在 Docker Sandbox 中，每个任务运行在拥有独立内核的微虚拟机中，编码代理的活动仅限于虚拟机内部，不会触及主机、其他任务或任何环境外的内容。

该功能已集成到 Docker Sandboxes 的夜间构建版本中，并于 10 月 23 日进入稳定版。Harbor 可以通过 sbx 扩展进行安装，夜间构建版本固定为 0.24.1.dev202610150414。在云端运行需要一个已启用云端访问权限的 Docker 账户，以及一个具有 Cloud Sandboxes 权限的个人访问令牌。Harbor 会从 SBX_DOCKER_USERNAME 和 SBX_DOCKER_PAT 环境变量中读取这些信息。运行时，可以通过 -e sbx 标志选择沙箱环境，命令示例为：harbor run -t hello-world/hello-world -a oracle -e sbx。

该公告未包含有关启动开销、每项任务成本或评估分数波动的基准数据。唯一一个具体的规模数据是 Docker 在 Cloud Sandboxes 上测试的 64 个并发任务。如果需要更高的上限，可以通过 Docker 的官方联系渠道提出申请。对每项任务的延迟或成本较为敏感的团队需要自行进行度量。

影响分析

对于中文开发者与从业者而言，这项集成意味着 AI 代理评估的安全性基线显著提升。由于每个任务运行在拥有独立内核的 MicroVM 中，恶意或失控的代理代码无法逃逸至主机或其他任务，消除了传统容器化评估中常见的侧信道攻击和宿主污染风险。这为大规模并行运行不可信 AI 代码提供了更可靠的沙箱保障。然而，必须明确这是基于架构隔离的分析判断：本地运行虽然免费且门槛低，但仅支持公共或无网络模式，缺乏细粒度控制。若团队需要保障评测公平性，例如允许在设置阶段拉取依赖但严格限制代理运行阶段的互联网访问，则必须采用云端方案。因此，具备敏感网络控制需求的评估场景将产生额外的云端服务成本，开发者需权衡隔离级别与预算限制。

适用边界

该结论在“仅需基本隔离且无网络依赖”的本地测试场景下成立，因为本地集成支持公共模式和无网络模式。然而，该结论在“需要细粒度网络策略控制”或“需要高并发扩展（超过 64 个任务）”的场景下不完全适用或存在限制。细粒度网络策略仅与云沙箱深度绑定，本地环境无法实现“设置期拉取、运行期限制”的动态网络控制。此外，若团队需要超过 64 个并发任务的上限，或关注单任务延迟与成本的具体数值，当前公告未提供基准数据，需自行度量或通过官方渠道申请更高配额，因此直接引用“64 并发”作为性能上限并不严谨。

孤本观察

Harbor 的云部署文档建议将 Daytona 作为最佳选择，因其支持 docker-compose.yaml 多容器部署，而 Docker 集成也支持通过 Docker Compose 在单个云沙箱内运行多容器任务，让服务和边车（sidecars）共享同一个微虚拟机。这体现了沙箱后端生态的趋同性：各提供商正在向支持复杂容器拓扑演进。但需警惕，网络限制仅消除了一条作弊途径，本文并未说明如何防止沙箱内的“奖励破解”行为，例如代理修改其可写入的测试文件，因此沙箱隔离不等于评估逻辑的完全防篡改。

来源：InfoQ 中文 AI