niceeval 0.12.1 → 0.12.2-canary.31

package/docs-site/zh/tutorials/docker-in-docker.mdx

@@ -0,0 +1,295 @@
+---
+title: "让 Sandbox 使用 Docker"
+sidebarTitle: "Docker 与 DinD"
+description: "根据任务信任边界选择 Docker socket、raw privileged DinD 或受管 rootless DinD，并为 Agent 准备 Docker CLI 与 daemon。"
+---
+
+当评估任务要求 Agent执行 `docker build`、`docker run`或 `docker compose`时，先按任务的信任边界
+选择 Docker access：
+
+| 模式 | 什么时候用 | 启动成本 | 安全边界 |
+| --- | --- | --- | --- |
+| Docker socket | 可信 Agent、个人开发机、已有 daemon，优先启动速度 | 最低，共用已有 daemon | Agent拥有该 daemon的完整控制权。rootful socket通常等价宿主 root |
+| Raw privileged DinD | 一次性 VM或专用 runner，需要独立 image、network和 cache | 每个 Sandbox启动 inner daemon | outer container是 raw privileged，不是安全隔离方案 |
+| Managed rootless DinD | 不可信 Agent、共享宿主、并发评估、需要资源准入和强杀恢复 | 最高，需要宿主 profile | privileged限制在受管 rootless user namespace或专用 VM，并有 watchdog与容量契约 |
+
+三种模式都要求镜像预装 Docker CLI。两种 DinD模式只接受从官方
+`docker:<version>-dind`派生的兼容镜像。镜像需要 Docker daemon、Node和评估工具，
+但不需要自定义 NiceEval `ENTRYPOINT`。NiceEval负责启动与监督 inner daemon、
+Sandbox保活、容器内 TTL和 `docker info`探活，不会向任意镜像动态安装 Docker。
+
+不能直接把未经派生的 `docker:<version>-dind`写成 `source.image`。该镜像没有 NiceEval supervisor
+需要的 Node，也没有被测 Agent的工具。创建时会以
+`dind-image-incompatible: missing node`失败。请使用下面的 Dockerfile，或先发布等价的派生镜像，
+再让 `source`引用它。
+
+## 方案一：直接挂 Docker socket
+
+先准备只有 CLI、Node和评估工具的镜像：
+
+```dockerfile title="sandbox/Dockerfile"
+FROM docker:29-cli
+
+RUN apk add --no-cache ca-certificates git nodejs npm python3 \
+  && addgroup -g 1000 node \
+  && adduser -D -u 1000 -G node node
+```
+
+在 Experiment里显式填写宿主 Unix socket。NiceEval不会从进程环境或 Docker context猜这个路径：
+
+```ts title="experiments/docker-socket.ts"
+import { defineExperiment } from "niceeval";
+import { codexAgent } from "niceeval/adapter";
+import { dockerSandbox } from "niceeval/sandbox";
+
+export default defineExperiment({
+  agent: codexAgent(),
+  model: "gpt-5.4",
+  sandbox: dockerSandbox({
+    source: {
+      type: "dockerfile",
+      context: new URL("../sandbox/", import.meta.url),
+    },
+    user: "node",
+    dockerAccess: {
+      mode: "socket",
+      socketPath: "/var/run/docker.sock",
+    },
+  }),
+});
+```
+
+NiceEval会解析 symlink、确认最终目标是 Unix socket，把它挂到 Sandbox内固定的
+`/var/run/docker.sock`，并按 socket的数值 GID给 `node`添加补充组。启动 Agent前，NiceEval会确认
+镜像没有预设 Docker endpoint或 context，而且默认 `docker info`与显式访问这个 Unix socket得到同一个
+daemon。CLI缺失、用户无法访问 socket或镜像把默认 endpoint改到别处时，Sandbox创建失败。
+
+这项检查只固定 Agent启动时的默认用法，不是安全边界。Agent之后仍可显式传 `docker --host`访问另一个
+endpoint。不可信任务需要依赖 managed模式的网络策略，而不是依赖 Docker CLI的默认值。
+
+<Warning>
+  这不是隔离方案。Agent可以通过 socket创建 privileged容器、挂宿主目录，并操作同一 daemon上的
+  其它容器、image、volume和 network。不要给不可信 Agent挂 rootful宿主 socket。
+</Warning>
+
+## 方案二：Docker-in-Docker
+
+DinD让每个外层 Sandbox拥有自己的 inner daemon。先创建镜像：
+
+```dockerfile title="sandbox/Dockerfile"
+FROM docker:29-dind
+
+RUN apk add --no-cache ca-certificates git nodejs npm python3 \
+  && addgroup -g 1000 node \
+  && adduser -D -u 1000 -G node node \
+  && addgroup node docker
+```
+
+生产评估应把 `FROM`钉到审核过的 digest，并把被测 Agent需要的固定 CLI烘焙进镜像。
+
+### NiceEval 如何启动 DinD
+
+选择 `dockerAccess: { mode: "dind", ... }` 就同时选择了 NiceEval 的 DinD 镜像协议。
+provider 会覆盖派生镜像的原有 `ENTRYPOINT` 和 `CMD`，先检查 `docker-init`、
+`node`、`docker`、`dockerd-entrypoint.sh`、`timeout` 和 `tail`，再启动自己的
+supervisor。supervisor 同时监督官方 `dockerd-entrypoint.sh dockerd`与 Sandbox 保活进程。
+任一进程提前退出都会停止 outer container，而不会留下一台看似存活但无法使用
+Docker 的 Sandbox。
+
+inner daemon 只监听 `/var/run/docker.sock`，不开放 2375/2376 TCP endpoint。
+Agent 仍以 `user: "node"` 运行。上面 Dockerfile 在构建期把 `node` 加入
+`docker` 组，因此不需要 `chown root:node` 或 `chmod 666` socket。如果镜像缺少工具、
+用户不在 `docker` 组、daemon 提前退出或 readiness 超时，NiceEval 会在删除创建失败的
+容器前收集有界日志尾部并报出可操作的原因。
+
+派生镜像不要设置 `DOCKER_HOST` 或 `DOCKER_CONTEXT`。NiceEval 会先确认默认 context，
+再核对不带 endpoint 选项的 `docker info` 与显式 `/var/run/docker.sock` 是否到达同一个 daemon。
+这项 compatibility check 通过后，才会执行作者声明的 readiness。
+
+这个协议不承诺保留任意 service image 的启动语义。如果你要评测一个必须依赖自己
+`ENTRYPOINT` / `CMD` 的服务组，应该使用 Compose Sandbox，由 Compose 声明服务进程。
+
+### 在 setup 中准备 Attempt 运行时
+
+Dockerfile 只烘焙固定工具、只读归档和项目初始文件。需要 inner daemon 的操作放进 Sandbox 级
+`setup`，不要放进镜像 `ENTRYPOINT`。下面的 setup 可以导入离线 image、把项目初始文件复制到可写
+workspace，并运行项目自己的 smoke check：
+
+```ts title="lib/dind-sandbox.ts"
+import { dockerfileSandbox } from "niceeval/sandbox";
+
+export const dindSandbox = dockerfileSandbox({
+  context: new URL("../sandbox/", import.meta.url),
+  user: "node",
+  dockerAccess: {
+    mode: "dind",
+    isolation: "raw-privileged",
+  },
+  readiness: {
+    command: ["docker", "info"],
+    user: "node",
+    timeoutMs: 30_000,
+  },
+}).setup(async (sandbox, ctx) => {
+  ctx.progress({ message: "准备 inner Docker 运行时" });
+  const result = await sandbox.runCommand("prepare-inner-runtime", [], {
+    user: "root",
+    stream: true,
+  });
+  if (result.exitCode !== 0) {
+    throw new Error(result.stderr || "inner Docker 运行时准备失败");
+  }
+});
+```
+
+NiceEval 会先启动并验证 inner daemon，再执行这个 setup，最后运行 Agent。setup 非零退出时，
+Attempt 在 `sandbox.create` 阶段记为 `errored`，不会把半成品 Sandbox 交给 Agent。固定内容留在 image layer，
+每个 Attempt 只复制或导入必须写入 tmpfs 或 inner data-root 的状态，可以减少重复安装和网络漂移。
+
+### Raw privileged DinD
+
+在一次性 VM或专用 runner上，可以显式选择 raw privileged：
+
+```ts title="experiments/dind-raw.ts"
+import { defineExperiment } from "niceeval";
+import { codexAgent } from "niceeval/adapter";
+import { dockerSandbox } from "niceeval/sandbox";
+
+export default defineExperiment({
+  agent: codexAgent(),
+  model: "gpt-5.4",
+  sandbox: dockerSandbox({
+    source: {
+      type: "dockerfile",
+      context: new URL("../sandbox/", import.meta.url),
+    },
+    user: "node",
+    dockerAccess: {
+      mode: "dind",
+      isolation: "raw-privileged",
+    },
+  }),
+});
+```
+
+必填的 `raw-privileged`字面量是风险授权。NiceEval不会把 raw模式描述成 rootless，也不会在失败时
+自动改用 managed profile。
+
+### Managed rootless DinD
+
+共享宿主或不可信 Agent使用 managed模式。它在 inner daemon之外增加 profile attestation、单容器
+资源限制、跨进程容量准入、独占外层网络和 watchdog恢复：
+
+```ts title="experiments/dind-managed.ts"
+import { defineExperiment } from "niceeval";
+import { codexAgent } from "niceeval/adapter";
+import { dockerSandbox } from "niceeval/sandbox";
+
+const GiB = 1024 ** 3;
+const MiB = 1024 ** 2;
+
+export default defineExperiment({
+  agent: codexAgent(),
+  model: "gpt-5.4",
+  maxConcurrency: 4,
+  sandbox: dockerSandbox({
+    source: {
+      type: "dockerfile",
+      context: new URL("../sandbox/", import.meta.url),
+    },
+    user: "node",
+    dockerAccess: {
+      mode: "dind",
+      isolation: "managed-rootless",
+      profile: "default",
+    },
+    resources: {
+      cpus: 4,
+      memoryBytes: 6 * GiB,
+      pidsLimit: 2048,
+      readOnlyRootfs: true,
+      tmpfs: {
+        "/var/lib/docker": { sizeBytes: 3 * GiB, mode: 0o711, executable: true },
+        "/home/sandbox/workspace": {
+          sizeBytes: 2 * GiB,
+          mode: 0o755,
+          uid: 1000,
+          gid: 1000,
+          executable: true,
+        },
+        "/home/node": { sizeBytes: 512 * MiB, mode: 0o700, uid: 1000, gid: 1000 },
+        "/tmp": { sizeBytes: 1024 * MiB, mode: 0o1777 },
+        "/run": { sizeBytes: 128 * MiB, mode: 0o755 },
+      },
+    },
+  }),
+});
+```
+
+profile缺失、拼错、attestation失败或容量不足时，NiceEval会在模型调用前失败，绝不降级成 raw
+privileged。宿主部署完成后先检查 profile：
+
+```bash
+npx niceeval docker profile list
+npx niceeval docker profile doctor default --smoke
+npx niceeval exp dind-managed
+```
+
+`doctor --smoke`会在该 profile上启动一次 DinD容器，并实际运行内层
+`docker run --rm alpine:3.20 true`。它证明 profile支持 nested Docker，但不会检查项目自己的
+Dockerfile。项目镜像仍由默认 `docker info` readiness验证。
+
+### 为 DinD 设置运行并发
+
+`resources.memoryBytes` 限制一台 Sandbox，不会自动设置 Run 的并发数。DinD 还会占用 inner
+image、BuildKit、tmpfs 和 page cache，默认并发对本机可能过高。先用较小并发完成 smoke run：
+
+```bash
+pnpm exec niceeval exp dind-managed --max-concurrency 2
+```
+
+再根据宿主的可用内存、CPU 和磁盘吞吐逐步增加。可以先用
+`可用内存 ÷ memoryBytes` 估算保守上限，同时为宿主 Docker、NiceEval 和其它进程留余量。
+Experiment 只服务这类重型 Sandbox 时，也可以直接设置 `maxConcurrency`。
+
+### 定位 DinD 创建失败
+
+创建失败后使用终端给出的 Attempt 定位符，不要直接翻运行产物：
+
+```bash
+pnpm exec niceeval show @1ABC234DEF
+```
+
+常见错误与处理方式：
+
+| 公开错误 | 处理方式 |
+| --- | --- |
+| `DOCKER_HOST must be unset` 或 `DOCKER_CONTEXT must be unset` | 删除镜像里的 endpoint/context 环境变量，让默认 endpoint 指向 `/var/run/docker.sock` |
+| `dind-image-incompatible: missing ...` | 从固定版本 `docker:<version>-dind` 派生，并补齐错误列出的工具 |
+| `permission denied` | 在构建期把 `user` 对应的 Agent 用户加入镜像内 `docker` 组 |
+| Docker access compatibility timeout | 从 `niceeval show` 给出的有界 `dockerd.log` 尾部检查 daemon 启动、socket 与 storage driver |
+| 启动前提示 orphan Sandbox | 先用 `niceeval sandbox list --orphans` 只读核对，再显式运行 `niceeval sandbox prune` |
+
+## 在 Eval里验证 Docker任务
+
+三种模式对 Eval暴露相同的 Docker CLI用法：
+
+```ts title="evals/docker-compose.eval.ts"
+import { defineEval } from "niceeval";
+import { commandSucceeded } from "niceeval/expect";
+
+export default defineEval({
+  description: "Agent can repair and start a Docker Compose project",
+  async test(t) {
+    await t.send("修复 Compose 项目，然后启动服务并确认健康检查通过。");
+
+    t.check(
+      await t.sandbox.runCommand("docker", ["run", "--rm", "alpine:3.20", "true"]),
+      commandSucceeded(),
+    );
+  },
+});
+```
+
+socket模式的命令操作显式选择的外层 daemon。两种 DinD模式操作 Sandbox内的 inner daemon。
+`sandbox`也可以直接写在 `defineEval({ sandbox: ... })`里。多条 Eval共用配置时写在 Experiment上。

package/docs-site/zh/tutorials/eval-groups.mdx

@@ -0,0 +1,207 @@
+---
+title: "用评估组复用 Sandbox"
+sidebarTitle: "评估组"
+description: "用 defineEvalGroup 显式声明兼容成员：同组按稳定 ID 串行复用一台 Sandbox，不同组继续并行，并把公共准备放到正确的 Sandbox Layer。"
+---
+
+一批评估用例共用同一套重工具链时，你通常同时需要两件事：不要为每道题重复创建
+Sandbox，也不要为了复用而把整批任务都降成串行。`defineEvalGroup()` 把兼容的评估用例
+划入同一个物理复用边界。同组真实派发的 Attempt 稳定串行并复用一台 Sandbox；不同组和
+未分组的评估用例仍可使用其它并发位。
+
+| 你会得到什么 | 运行行为 |
+| --- | --- |
+| 公共准备少付几次 | Sandbox 创建和组级 `setup()` 每个组内实例只执行一次 |
+| 组内稳定串行 | Runner 按规范化 Eval ID 排序，同组同时只派发一条 Attempt |
+| 组间保留吞吐 | 不同组和未分组评估用例可以并行 |
+| 结果仍能单独比较 | 每条 Attempt 继续拥有自己的断言、判定、用量和文件改动 |
+
+评估组只安排本轮需要真实运行的 Attempt。已经沿用的结果不会进入组内 Sandbox，
+`--rerun`、`attempts` 和首过即停仍按 Experiment 的既有规则工作。
+
+## 先选对复用方式
+
+| 任务 | 使用方式 |
+| --- | --- |
+| 一组或几组兼容的评估需要复用同一台 Sandbox，并希望其它组并行 | `defineEvalGroup()` |
+| Experiment 选中的普通评估都能互换顺序，只想开几条复用泳道 | `sandboxReuse: true` |
+| 每条 Attempt 都需要全新的 `$HOME`、`/tmp` 和后台进程 | 不复用 Sandbox，只调并发 |
+
+同一个 Experiment 不能同时选中评估组并声明 `sandboxReuse: true`。评估组已经拥有自己的
+复用边界；两者同时出现会在 Provider 创建 Sandbox 前报
+`eval-group-sandbox-reuse-conflict`。
+
+## 第 1 步：把组文件放在成员旁边
+
+把 `eval-group.ts` 放进 `evals/` 下的具名目录。目录路径就是评估组 ID：
+
+```text
+evals/
+└── workflow/
+    ├── eval-group.ts          # 评估组 ID：workflow
+    ├── 01-index/
+    │   └── eval.ts            # 评估用例 ID：workflow/01-index
+    └── 02-query/
+        └── eval.ts            # 评估用例 ID：workflow/02-query
+```
+
+NiceEval 只发现 `evals/**/eval-group.ts`。不要把文件写成 `*.eval-group.ts`，也不要放在
+`evals/eval-group.ts`；后者没有可用的组 ID。
+
+## 第 2 步：用工厂返回对象声明成员
+
+每个成员照常默认导出 `defineEval()` 或 `defineScoreEval()` 的返回值。组文件导入这些返回值，
+再把兼容成员列入同一个闭合集合：
+
+```ts
+// evals/workflow/eval-group.ts
+import { defineEvalGroup } from "niceeval";
+import buildIndex from "./01-index/eval.ts";
+import queryIndex from "./02-query/eval.ts";
+
+export default defineEvalGroup({
+  evals: [buildIndex, queryIndex],
+  onUnavailable: "stop-group",
+});
+```
+
+`evals` 必须非空。它只接受工厂实际返回的对象，不接受评估用例 ID、目录前缀、`glob`、
+`tag` 或 `selector`。NiceEval 也不会自动收集同目录文件；成员增删和顺序变化都会明确出现在
+`eval-group.ts` 的 diff 中。
+
+`evals` 数组只声明成员，不声明业务顺序。Runner 始终按规范化 Eval ID 稳定排序；只调整
+数组位置不会改变调度行为或组指纹。需要“先构建、后查询”这类结果依赖时，把两个步骤放进
+同一条 Eval。Eval Group 的业务排序 API 还没有实现。
+
+`onUnavailable` 是必填策略。`"stop-group"` 在物理 Sandbox 无法创建、重置或准备时停止
+该组后续派发；`"replace-sandbox"` 会先退休当前实例，并让下一条 slot 尝试建立替代实例。
+省略策略会在加载 `eval-group.ts` 时直接报错，避免运行器替作者猜测失败后的成本与副作用。
+
+一条评估用例最多属于一个组，同一组也不能重复列出同一条。Experiment 与 CLI 仍负责筛选
+评估用例；选中 `workflow/02-query` 不会自动把 `workflow/01-index` 拉进本轮运行。
+
+## 第 3 步：让 Experiment 提供可复用的 Sandbox
+
+大多数项目由 Experiment 选择 Provider 和 `template`，评估组只负责拥有复用队列：
+
+```ts
+// experiments/codex.ts
+import { defineExperiment } from "niceeval";
+import { codexAgent } from "niceeval/adapter";
+import { e2bSandbox } from "niceeval/sandbox";
+
+export default defineExperiment({
+  evals: ["workflow/"],
+  agent: codexAgent(),
+  sandbox: e2bSandbox({
+    template: "codex",
+    lifetimeMs: 60 * 60_000,
+  }),
+  maxConcurrency: 4,
+});
+```
+
+这里不要写 `sandboxReuse: true`。`maxConcurrency: 4` 是整个 Experiment 的上限，不会让
+同组同时跑四条；它允许其它评估组或未分组评估用例使用剩余并发位。
+
+评估组只支持 Sandbox 型 Agent 和支持复用的 Provider。Direct Agent 与 `localSandbox()`
+不能运行评估组。
+
+## 第 4 步：先检查组 ID 和选择结果
+
+先用 `--dry` 确认选择结果，不会创建 Sandbox：
+
+```bash
+npx niceeval exp codex --dry
+```
+
+上面的最小项目会显示：
+
+```text
+plan: 2 个 attempt · 2 个 eval × 1 个运行配置 · attempts 1
+codex  workflow/01-index [group workflow]   new
+codex  workflow/02-query [group workflow]   new
+```
+
+确认两条选中 Eval 都显示相同的组 ID 后再运行：
+
+```bash
+npx niceeval exp codex
+```
+
+当前调度器按规范化 Eval ID 排列成员；`attempts` 大于 1 时，同一成员的各次 Attempt 连续
+进入组内泳道，再进入下一个成员。这只是稳定的调度规则，不是跨 Eval 的数据依赖契约。
+首过即停或结果沿用没有实际派发的槽位会直接跳过。
+
+## 把公共准备放到评估组
+
+一次 Sandbox 规划可以同时接收 Experiment、评估组和评估用例三层声明，但三层中只能有
+一层提供 template。常见分工如下：
+
+| 声明位置 | 适合放什么 | 执行频次 |
+| --- | --- | --- |
+| Experiment 的 `sandbox` | 随 Agent 或模型配置变化的 Provider `template` | 每个组内 Sandbox 一次 |
+| 评估组的 `sandbox` + `.setup()` | 同组共用的工具链、公共 Checkout、构建缓存预热 | 每个组内 Sandbox 一次 |
+| 评估组的 `sandbox` + `.prepare()` | 每条 Attempt 都要恢复的组级 Fixture | 每条真实 Attempt 一次 |
+| 成员自己的 `sandbox` + `.prepare()` | 只属于这道题的 Starter、依赖和公开素材 | 每条真实 Attempt 一次 |
+
+评估组可以提供自己的 `SandboxLayer`：
+
+```ts
+import { defineEvalGroup } from "niceeval";
+import { sandboxLayer } from "niceeval/sandbox";
+import buildIndex from "./01-index/eval.ts";
+import queryIndex from "./02-query/eval.ts";
+
+export default defineEvalGroup({
+  evals: [buildIndex, queryIndex],
+  sandbox: sandboxLayer().setup(async (sandbox, ctx) => {
+    ctx.progress({ message: "准备组内公共工具链" });
+    await sandbox.runCommandOrThrow("npm", ["install", "--global", "tsx@4.22.4"]);
+  }),
+  onUnavailable: "stop-group",
+});
+```
+
+组内生命周期与 Agent Context 都能读取 `ctx.evalGroup.id` 和
+`ctx.evalGroup.definitionHash`。公共函数也可能服务未分组评估，所以类型把 `evalGroup`
+保留为可选字段。需要在 `workdir` 外隔离缓存或服务命名空间时，先检查字段是否存在，再使用
+组 ID 派生键。
+
+成员不能提供 `template`，也不能声明 `.setup()` 或 `.teardown()`。把实例级生命周期移到
+评估组或 Experiment；成员只保留不含 `template` 与生命周期、仅声明 `.prepare()` 的
+`SandboxLayer`。
+
+## 不要把评估组当成任务依赖图
+
+每条 Attempt 之间，NiceEval 会把 `workdir` 重置到公共准备完成时的状态。前一道题写进
+`workdir` 的文件不会成为后一道题的输入；`$HOME`、`/tmp`、全局安装和后台进程则可能保留。
+无法接受这些残留时，不要复用 Sandbox。
+
+评估组也不会保证前一道题一定执行。结果沿用、CLI 过滤、预算耗尽和中断都可能让成员不进入
+本轮 Sandbox。后一项必须读取前一项文件时，把两个步骤写进同一条评估用例；只有共享状态本来
+就在 `workdir` 外，而且每条评估用例都能独立得到有效判定时，才把它们放进同一组复用。
+
+## 常见错误
+
+| 错误 | 修正方式 |
+| --- | --- |
+| `eval-group-member-unresolved` | 从评估入口导入工厂原本返回的默认对象，不要重建对象或写字符串 ID |
+| `eval-group-member-overlap` | 每条评估用例只放进一个组，并且只列一次 |
+| `eval-group-member-layer` | 把成员的 `template`、`.setup()` 和 `.teardown()` 移到评估组或 Experiment |
+| 加载时提示缺少 `onUnavailable` | 显式选择 `"stop-group"` 或 `"replace-sandbox"`，不要省略失败策略 |
+| `eval-group-sandbox-reuse-conflict` | 从 Experiment 删除 `sandboxReuse: true` |
+| `eval-group-direct-agent` | 改用 Sandbox 型 Agent，或让这个 Experiment 不再选择分组评估 |
+| `sandbox.reuse-unavailable` | 换成支持 Sandbox 复用的 Provider |
+| `eval-group-incompatible` | 让成员得到相同的物理 Sandbox 计划，或按兼容的 `template` 拆组 |
+
+## 接着看
+
+- [用 Plugin 复用完整评估条件](/zh/tutorials/plugins)——把组、实验或成员需要的声明组合成
+  显式 occurrence，同时保留评估组的 Docker Sandbox 复用边界。
+- [复用 Sandbox](/zh/tutorials/sandbox-reuse)——整批普通评估用例适合使用
+  `sandboxReuse: true` 时的生命周期和残留边界。
+- [调好并发](/zh/tutorials/concurrency)——评估组怎样与全局、Experiment 并发上限一起工作。
+- [Sandbox Provider 配置](/zh/tutorials/sandbox-providers)——选择 `template`、设置寿命并编写
+  `SandboxLayer`。
+- [重跑与沿用](/zh/tutorials/rerun-and-cache)——哪些 Attempt 会进入本轮组内队列。