Docker

Building Reproducible AI Evaluation Workflows with Docker Sandboxes

8.5内容质量
Building Reproducible AI Evaluation Workflows with Docker Sandboxes

TL;DR · AI 摘要

Docker Sandboxes与SBX Kit结合可构建可重复AI评估流程，通过分离评估定义与执行环境确保结果一致性。

核心要点

  • 使用Docker Sandboxes可消除环境差异导致的评估不一致问题
  • SBX AI Evaluation Kit提供结构化评估记录和运行时证据
  • YAML配置文件实现评估定义与执行环境的解耦

结构提纲

按章节快速跳转。

  1. §引言

    当前AI评估面临环境不一致导致的可重复性挑战。

  2. ·核心机制

    通过Docker Sandboxes实现执行环境标准化。

  3. ›SBX Kit架构

    SBX AI Evaluation Kit包含执行器抽象和证据记录模块。

  4. ·实践应用

    展示如何通过YAML配置定义评估流程。

  5. ›执行分离

    Executor抽象层实现评估定义与执行环境解耦。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • 可重复AI评估架构
    • 核心组件
      • Docker Sandboxes
      • SBX Kit
    • 关键机制
      • Executor抽象层
      • YAML配置
    • 执行流程
      • 命令解析
      • 沙箱执行
      • 证据记录

金句 / Highlights

值得收藏与分享的关键句。

#Docker#AI评估#SBX Kit#可重复工作流程
打开原文

使用 Docker 沙盒构建可复现的 AI 评估工作流程 | Docker

Docker Captain

使用 Docker 沙盒构建可复现的 AI 评估工作流程

发布于 2026 年 9 月 2 日

Karan Verma

AI 评估从未如此容易上手。但要可靠地复现它却是个难题。如今开发者可以接触到比以往任何时候都更多的基准测试、评估库、模型 API 和代理框架。但即使保持提示词、模型和评分方法不变，也不一定就能保证运行结果的可复现性。执行环境同样至关重要。

Python 依赖项会变化。本地工具会逐渐偏离初始状态。搭建步骤可能未被记录。在某台机器上成功的流程，在另一台机器上可能表现不同。大多数关于评估的讨论都集中在应该测量什么：基准测试、评分方法或判断模型。相比之下，很少有人关注这些评估是如何执行的。但正是这个执行层，往往决定了数周或数月后其他人是否能复现相同的工作流程。

当我开始探索 Docker 沙盒时，并不是为了构建另一个评估框架。我有一个更简单的问题：

Docker 沙盒和 SBX 工具包能否让评估工作流程更容易重新运行、检查和比较？

这个问题最终演变成了 SBX AI 评估工具包，这是一个开源的 Docker 沙盒混入工具包，专注于可重复执行、结构化评估记录和运行时证据。当前实现不会执行 AI 模型或自动生成评估判断。相反，它会一致地执行配置的命令，并保留实际运行过程的证据。

实际应用

在实际应用中，工作流程首先需要通过执行块选择评估命令的运行位置：

code
execution:
  executor: sbx
  command:
    - python3
    - -c
    - print("hello from sbx")

当使用 executor: sbx 时，执行器会将命令委托给 Docker 沙盒，并将运行时证据写入生成的制品中。

该仓库也打包为 SBX 混入工具包，因此可以在启动 Claude 沙盒时应用：

code
sbx run claude --kit .

执行器会读取配置的执行器设置，并将命令委托给 SBX，在沙盒内部执行：

code
python run_evaluation.py

从文档到可执行工作流程

每个评估都在 YAML 文件中定义，该文件描述了评估内容和要运行的命令。仓库会验证该定义，执行它，并生成结构化的 JSON 结果记录。区别在于记录的内容。书面评估记录的是某人计划要做的事情。而基于执行的评估记录的是实际发生的事情。

将评估与执行分离

我希望评估定义能够独立于其运行位置。在本地开发期间编写的工作流程，不应该仅仅因为之后在 Docker 沙盒中执行就需要修改。

为了将这些关注点分离，我引入了执行器抽象层。评估描述了应该运行什么；执行器决定了在哪里运行。

使用本地执行器时，配置的命令会在主机上运行。使用 SBX 执行器时，命令执行会委托给 Docker 沙盒。在两者之间切换只需更改执行器配置，无需重写周围的评估工作流程。

图1。评估定义与执行环境无关。相同的流程可以使用本地或SBX执行器，同时生成结构相同的运行时证据。

采集证据而非假设

每次执行时，运行器会记录足够的信息以检查实际发生的情况：

  • 所选执行器，
  • 执行的命令，
  • 标准输出（stdout）和标准错误（stderr），
  • 退出代码，
  • 以及执行时间。

这些细节存储在评估产物中。仓库还会生成评估配置的摘要。这在不试图替代完整实验跟踪系统的情况下，创建了评估配置与其生成产物之间的确定性关联。

code
{
  "executor": "sbx",
  "command": ["python3", "-c", "print(\"hello from sbx\")"],
  "stdout": "hello from sbx\n",
  "stderr": "",
  "exit_code": 0,
  "duration_ms": 120.0
}

从单个评估扩展到多个评估

现实中的评估很少只包含一次孤立的运行。团队需要比较提示、验证行为、测量版本间的回归，并测试多种场景。这催生了评估套件的概念。

而不是改变单个评估的运作方式，套件将多个评估定义组合成一个可重复的工作流。每个评估仍然生成自己的结构化产物，而套件同时生成整体运行的聚合摘要。

超越评估的可重用SBX套件

同样的模式不仅限于评估。SBX套件可以打包的不只是开发环境，还可以打包工程工作流所依赖的设置。相同的模型可以支持回归测试、策略检查、安全分析、代码生成实验以及其他依赖一致执行和可检查结果的工作流。

结论

SBX AI评估套件不会替代评估框架、基准或评分系统。它的职责更狭窄：以更容易重新运行和检查的方式执行配置的评估工作流。

我带走的问题很简单：在比较基准分数或选择判断模型之前，是否有人能在可比条件下可靠地运行相同的流程？

你可以在GitHub上的sbx-ai-eval-kit仓库中探索代码、尝试自定义评估YAML，并亲自运行该工作流。

资源

  • SBX AI评估套件 – 源代码、示例评估定义以及本文描述的实现。
  • Docker沙箱文档 – 设置和运行Docker沙箱的官方文档。
  • 使用套件扩展Docker沙箱 – 用可重用套件扩展Docker沙箱的官方文档。

AI代理

AI/ML

Docker沙箱

生成式AI

社区

目录

相关文章

  • 2026年8月18日 17,600个动作：代理安全是系统问题 OpenAI/Hugging Face事件暴露了AI代理安全的新挑战。17,600个攻击者动作展示了为什么AI代理安全不能依赖人工审查。探索在速度上约束、观察和治理代理所需的控制措施。Mark Cavage 立即阅读
  • 2026年9月3日 YOLO模式：无防护的代理自主性 YOLO模式允许AI代理在不请求许可的情况下运行。了解它是什么，为什么有风险，以及如何安全地运行它。Eric Jia和Srini Sekaran 立即阅读
  • Docker Captain 2026年9月2日 使用 Docker 沙箱构建可复现的 AI 评估工作流程 了解 Docker 沙箱如何通过一致的执行环境、结构化的产物和运行时证据，使 AI 评估工作流程更加可复现。Karan Verma 立即阅读
  • 2026年9月2日 深入 Harness：治理多模型、多Harness世界 我们认为未来将是多模型、多Harness的世界。我们认为这需要一种新的信任模型。1988年，Norm Hardy 描述了一个持续多年悄然破坏系统的难题：困惑的副手问题。一个程序使用自身的权限而非你的权限采取行动。今天，每个 AI 代理都扮演着这个副手角色。它… Srini Sekaran 立即阅读