企业官网建设流程全解析

NemoClaw E2E CI 体系深度解析：从可信工作流、候选工件到发布资格验证

【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址: https://gitcode.com/gh_mirrors/ne/NemoClaw

导读：本文以仓库中的 test/e2e/README.md 为主线，系统拆解 NemoClaw（NVIDIA OpenShell 之上的 Hermes、LangChain Deep Agents、OpenClaw 安全沙箱编排项目）的端到端（E2E）持续集成体系。你将掌握其多工作流协作模型、候选 CLI 工件的构建与身份校验边界、可声明式发现的免凭据测试、按凭据边界分层的目标目录（Catalogue）、语义化执行证据与性能预算，以及「相关 E2E」与「发布资格」两种结果门禁的差异。

一、NemoClaw E2E CI 的总体形态

NemoClaw 的 E2E 覆盖并不依赖单一工作流，而是由一组职责分离的 GitHub Actions 工作流协作完成。直接 E2E 覆盖通过 Vitest 运行（文档明示 "Direct E2E coverage runs through Vitest"），交互式 TUI 目标需要expect工具，统一工作流会在这些目标运行前自动安装它；本地运行者则需要自行提供。

各工作流的定位如下（均依据 README 与仓库实际文件）：

从源码结构看，工作流编排的核心逻辑集中在 tools/e2e/workflow-plan.mts（规划器）、tools/e2e/workflow-boundary.mts（工作流边界校验）与 tools/e2e/target-catalogue.mts（目标目录）中。

1.1 主工作流的选择逻辑

主工作流对每次 push 比较github.event.before与github.sha，规划器会：

• 选择目录（Catalogue）目标、打标签的免凭据测试、注册表（Registry）目标，以及拥有变更文件的保留工作流作业；
• 为每次受信main推送选择仅 CPU 的jetson-nvmap-gpu证明；
• 对中央工作流、规划器或共享执行助手的改动，选择完整默认 E2E 集合。

如果没有其他 E2E 目标拥有变更文件，Relevant E2E只要求 Jetson 证明通过；否则要求每个被选中的工作流作业都通过。对于受信的手动 PR 运行，同一检查还会记录所选结果并引用已有的派发回执。中央工作流没有定时触发（scheduled trigger）。

1.2 规划器的输入输出流

README 用 Mermaid 图描述了规划器如何把每种受信输入连接到其执行与证据边界。其核心链路为：mainpush diff 或全量手动派发 → 工作流规划器 →（类型化注册表矩阵 / 共享测试矩阵 / 目录 profile 矩阵 / 保留工作流作业）→ 复用 profile 工作流与专用 GitHub Actions 作业 → 诊断性产品证据；作业结果汇聚为Relevant E2E（push 或 PR），全量手动运行则汇聚为Release qualification，最终交由维护者决策。

所有目录 profile 都会调用.github/workflows/e2e-standard-profile.yaml这一复用工作流，由它统一负责：校验目录计划（在候选 checkout 之前）、派生工件路径与上传名、checkout、Docker 认证、受审主机准备、CLI 工件恢复、OpenShell 安装、Runner 遥测、Vitest 执行、证据清单生成、工件上传与 Docker 凭据清理。

二、候选 CLI 工件：构建、身份与恢复边界

候选 CLI 来自 E2E 运行所测试的源码提交。generate-matrix作业通过共享的ci-compile-artifactsaction 只准备一次，该 action 与主 CI、PR CI 使用的是同一实现。它总是产出完整 CLI 与插件，固定使用 Node.js 24.18.1，并校验内嵌源码修订与 source map。

关键设计点：

• 工件交接保留 CLI 与共享模块负载；作业把根dist/与nemoclaw/dist/shared/发布为一个内容寻址工件；
• 边界校验器从使用固定准备 action 的作业派生工件消费者，排除generate-matrix以及E2E_JOB_POLICY中的无构建与受信构建作业；
• 每个被选中的消费者恢复工件，而不是运行npm run build:cli；随后以build-cli: "false"运行固定准备 action 来安装 Node.js 与项目依赖。

共享编译器对dist/与nemoclaw/dist/使用 GitHub 原生缓存，缓存键包含 checkout SHA、受信 recipe 修订、action 内容、Node 版本与 Runner 平台。完整缓存命中会跳过依赖安装与编译；未命中则重建相同输出；两条路径都会校验输出完整性与源码身份。被拒绝的缓存命中会使作业失败，作业摘要会给出缓存键与删除命令——必须先删除缓存再重跑失败作业，否则会恢复同一个无效条目。主 CI 与主 E2E 可以复用同一源码与 recipe 的条目，而 PR 缓存限定在其 merge ref 内，因此手动 E2E 可能错过 PR CI 条目。

2.1 工件身份与还原校验

对一次 PR 运行，checkout_sha标识所选 head 或精确 base 源提交；base 重放会把checkout_sha设为base_sha，并保留失败 head 运行的同一受信工作流 SHA 与选择器。受信工作流从github.workflow_sha运行；push 或手动运行在checkout_sha为空时使用github.sha。

工件清单（manifest）记录：候选仓库与提交 SHA、受信工作流 SHA 与运行 ID/尝试、源树与 lockfile 摘要、Node.js 与 npm 版本、Runner 平台与构建命令、负载摘要。工件名包含候选提交 SHA 与负载 SHA-256 摘要。generate-matrix通过cli_artifact_provenance输出一个nemoclaw-e2e-cli-provenance-v1JSON 对象，每个使用工件的作业将其作为还原 action 的唯一provenance-json输入。

还原动作restore-e2e-cli-artifact（仓库自有的复合 action，以完整提交 SHA 引用，绝不在候选 checkout 中加载实现）在下载前会拒绝多余或缺失的 provenance 字段，并要求候选 checkout SHA、仓库、工作流 SHA 与运行 ID 与 provenance 对象一致，生产者尝试不得晚于消费者尝试；随后按不可变 ID 下载工件，并把摘要不匹配处理设为error。还原前的检查还包括：上传摘要存在且格式良好、候选 SHA 匹配、清单匹配源码/运行/工具链契约/负载、归档无路径穿越/链接/特殊文件且不超出根dist/与nemoclaw/dist/shared/、两个目录都不已存在（含悬空符号链接）、nemoclaw/是目录而非符号链接、CLI 入口与共享模块是非空普通文件、dist/build-identity.json指明候选提交 SHA。任何一项失败都会在添加目录前停止；通过后运行bin/nemoclaw.js --version，版本命令失败则停止在实时测试之前。这一边界使候选源码与受信工作流实现保持分离。

值得注意：managed-image-protected-runtime资格验证不使用该工件，它从受信工作流 checkout 构建 CLI，绝不执行或还原候选 CLI。

2.2 时序基线

文档给出了替换前基线：三个观测的Build CLI步骤时长中位数为 18.756 秒，且明确强调该基线只度量被替换的构建步骤；工件上传/下载/校验与对generate-matrix的依赖会加入运行时并影响工作流关键路径，不能用构建步骤中位数声称 Runner 时间或工作流耗时的节省。合并后应匹配作业选择、Runner 标签与首次尝试，分别记录候选构建、上传、下载、校验加还原步骤、作业与工作流时长，并按受影响步骤求和对比，且每个结果都要以运行 ID、测试提交 SHA、受信工作流 SHA 与尝试标识。

2.3 历史夹具的版本边界

历史夹具保留明确的版本边界：

这些目标可以恢复共享工件作为候选 CLI，但绝不能用该工件替换历史安装器、包、镜像或版本边界。网关夹具已把远程历史输入绑定到不可变提交与密码学摘要，工作流不会把这些输入重新发布为工件。确定性测试负责安装器身份、OpenShell 发布资产选择、NemoClaw 恢复行为与 Dockerfile patch 行为；实时目标不断言 OpenClaw 数据库表、迁移检查点等第三方存储细节。

三、测试目标的组织方式

NemoClaw 的 E2E 目标分为三类组织形态：免凭据测试、目录目标（Catalogue）与类型化注册表目标（Typed Registry）。

3.1 免凭据测试（Credential-free tests）

可以使用标准 Ubuntu Runner、CLI 构建与工件策略的免凭据测试，通过在测试旁加标签加入共享 E2E 作业：

// @module-tag e2e/credential-free

发现逻辑在 tools/e2e/credential-free-tests.mts 中实现（CREDENTIAL_FREE_TEST_TAG = "e2e/credential-free"、SHARED_E2E_JOB_ID = "shared-e2e"）。它从e2e-live与integration两个 Vitest 项目读取带标签的文件，从文件名派生测试 ID，只向测试矩阵提供 ID、仓库相对文件与 Vitest 项目。文件名主干必须唯一且为小写 kebab-case；不要手动维护工作流矩阵或单独目录。若测试需要不同能力（凭据、自定义 Runner、额外 setup、不同超时），应保留专用工作流作业。jobs与targets两个选择器都接受测试 ID。本地检查生成的测试矩阵：

npx tsx tools/e2e/credential-free-tests.mts

源码中每类测试的文件路径有严格正则约束（test/e2e/live/...test.ts与test/(?!e2e/)(...)test.js|ts），并强制每个 ID 具备执行覆盖元数据（agentRuntime、observableOutcome、environmentOrInferenceEndpoint等，见 tools/e2e/execution-coverage.mts）。

3.2 目录目标（Catalogue Targets）

tools/e2e/target-catalogue.mts 声明共享同一执行形态的实时 E2E 目标。每个条目拥有：稳定目录 ID/目标 ID/shard/Vitest 文件、面向 GitHub Actions 的结果优先显示名、推送到main后选择目标所需的源路径、执行 profile 与 Runner 路由及超时、OpenShell 安装模式与非交互安装器选择及 CLI 工件使用、受审主机包与主机准备及可选 cloudflared 前置、Runner 遥测与一个受审工件布局、PR Review Advisor 选择（标准 profile 目标默认可选，凭据目标必须设置prAdvisorSelectable）、可选 Vitest 标题选择器、目标专属环境变量、全量运行资格成员。

显示名格式为<area>: <observable outcome>，且不得包含目标 ID、issue 号、Catalogue/live/E2E字样、测试路径或 Runner/沙箱 ID。E2E_TARGET_CATALOGUE是单一逻辑目标集，规划器按执行 profile 将其分区为 GitHub Actions 矩阵。

3.3 类型化注册表（Typed Registry）

类型化注册表只包含可执行矩阵单元，每个单元必须命名可执行的平台/安装/运行时/onboarding 路线并带已解析覆盖元数据；声明生命周期路线也必须可执行，注册表构造会拒绝无效单元，选择已移除或未知目标 ID 会失败并列出现有 ID。提议的平台/agent/运行时组合保留在其规划 issue 中，直到存在夹具与执行所有权。显式专用的工作流行保留覆盖维度但不加入默认发布矩阵。注册表定义位于 test/e2e/registry/definitions/baseline.ts，注册表与矩阵构建位于 test/e2e/registry/registry.ts 与 test/e2e/registry/run.ts。

3.4 覆盖元数据三元组

每个执行行声明三个覆盖字段：

• agentRuntime：执行断言的 agent 运行时；不启动 agent 用none；仅在带unresolvedReason时用unresolved；
• observableOutcome：产生证据的行为；目录目标以其结果导向displayName作为该值；
• environmentOrInferenceEndpoint：区分证据的主机边界或推理端点。

类型化注册表测试把可读执行标题渲染为<observableOutcome> [<agentRuntime>; <environmentOrInferenceEndpoint>]，并加稳定目标 ID 前缀。覆盖元数据各归其主：目录目标声明于 tools/e2e/target-catalogue.mts，可执行类型化目标声明于 test/e2e/registry/definitions/baseline.ts，共享免凭据测试声明于 tools/e2e/credential-free-tests.mts，保留工作流作业与 staging Brev 声明于.github/workflows/e2e.yaml。单工作流作业用E2E_AGENT_RUNTIME、E2E_OBSERVABLE_OUTCOME、E2E_ENVIRONMENT_OR_INFERENCE_ENDPOINT与可选E2E_UNRESOLVED_REASON环境项；矩阵作业把变体值放入蛇形 include 条目，并用coverage_variant表示单作业贡献多行。tools/e2e/workflow-plan.mts 组合并校验这些来源，不允许维护独立的执行列表。报告还会分组重复的可观察结果，仅当 agent 运行时或环境提供不同证据时保留这些行，并拒绝两个覆盖三元组完全相同的行。

四、执行 profile 与凭据边界

E2E_TARGET_CATALOGUE被分区为矩阵，每个执行 profile 拥有其目标步骤可用的凭据：

GitHub Actions 将每次目录执行渲染为<display name> / <credential boundary>。目录条目只能请求受审的expect与iptables主机包，由固定主机依赖 action 在工作区准备前安装；仅主机包或选择器不要求专用工作流作业。选择非交互安装时，复用工作流为其 OpenShell 安装步骤设置NEMOCLAW_NON_INTERACTIVE=1；并为每个目标把NEMOCLAW_E2E_EXPECTED_SHA设为候选提交（TUI 精确引用检查使用该共享值）。标准布局把产品证据与evidence-manifest.json写在e2e-artifacts/live/<target-id>下，shard非default时追加 shard 目录；security-posture 矩阵使用受审的扁平 shard 布局以保留既有工件名。

4.1 目录执行证据清单

每次目录执行都会在目标工件目录写evidence-manifest.json，kind为nemoclaw-e2e-evidence-v1，记录targetId、候选仓库与提交、受信工作流仓库与提交、运行 ID 与尝试、作业状态、工件目录与productEvidenceFileCount。成功目标必须先写至少一个产品证据文件，否则清单创建失败而不是认证空运行；选择不到测试的目录 Vitest（含全部跳过）会在清单创建前以非零退出。失败目标仍会写清单供诊断，随目标工件一并上传。清单是无秘钥的诊断证据，不替代工作流作业结果或严格的Release qualification聚合。

本地渲染完整默认选择的 Markdown 表：

npx tsx tools/e2e/workflow-plan.mts --summary

加入--jobs或--targets选择器可渲染过滤计划：

npx tsx tools/e2e/workflow-plan.mts --summary --jobs hermes-e2e npx tsx tools/e2e/workflow-plan.mts --summary --targets ubuntu-repo-cloud-openclaw

要在 GitHub Actions 作业中发布该输出，追加到$GITHUB_STEP_SUMMARY即可：

npx tsx tools/e2e/workflow-plan.mts --summary >> "$GITHUB_STEP_SUMMARY"

工作流的--ci-output模式用同一渲染器生成作业摘要，表格包含类型化注册表矩阵、共享测试矩阵、目录 profile 矩阵、保留工作流作业与 staging Brev 执行。

五、平台兼容性证据

.github/workflows/platform-vitest-main.yaml发布CI / Platform Compatibility：运行 Ubuntu 26.04 兼容性契约，并在 macOS 与 WSL 上以四个 shard 运行完整 Vitest 套件。矩阵禁用fail-fast；每个 macOS Vitest shard 有 30 分钟预算，独立 macOS 实时 E2E 作业有 150 分钟预算（含 70 分钟实时测试与清理）；首个 WSL shard 有 180 分钟预算（root 所需契约与实时 E2E），其余 shard 各 90 分钟。

独立 macOS 作业与 WSL shard 1 只在测试main且 Docker 可用时运行聚焦的实时 E2E，否则记录跳过并保留平台契约证据。因此该工作流是平台证据，而非Release qualification——只有.github/workflows/e2e.yaml的全量手动运行能发布发布检查。实时步骤把作业级GITHUB_TOKEN与仓库NVIDIA_INFERENCE_API_KEY交给候选测试代码（macOS 直接进进程环境，WSL 经受信 PowerShell 助手转发）。GITHUB_TOKEN在作业结束后失效；NVIDIA_INFERENCE_API_KEY在过期或被撤销前始终有效，工作流不会撤销它。

六、语义阶段与进度证据

每个e2e-live测试与每个被共享 E2E 工作流规划器选中的免凭据集成测试，都要在meta.e2ePhases中声明有序语义阶段计划，并使用自动进度夹具。正常输出形如：

[e2e target="cloud-onboard" scenario="onboards a hosted sandbox"] [phase 2/4] completed: onboard the sandbox — passed in 2m 14s (total 2m 21s) [e2e target="cloud-onboard" scenario="onboards a hosted sandbox"] [phase 3/4] started: verify hosted inference (total 2m 21s; phase 0s)

对e2e-live，有状态夹具在测试声明的计划后追加release registered E2E resources终态阶段，注册的清理时长/失败/停滞诊断归属于该阶段；工作流选择的集成测试则声明并进入自己的终态释放阶段。软断言失败仍归属其发生时的语义阶段。某阶段活跃 5 分钟即输出内容无关的诊断（目标/场景身份、总时长与阶段时长、最后子输出年龄、当前脱敏命令或清理活动、Runner 资源），此后每 10 分钟重复。子输出观察只转发时间戳与流名，绝不转发内容。

teardown 时夹具在每个测试的工件目录写test-progress.json（成功与失败都写），记录测试身份、整体时间戳与每阶段时间戳/时长/结果/子输出事件数/最后输出时间戳；E2E_TARGET_ID优先，回退到GITHUB_JOB，并记录NEMOCLAW_E2E_SHARD。对比多次运行抽取的工件：

npm run test:runtime-audit -- path/to/run-1 path/to/run-2

审计按目标与可选 shard 分组，按 p95 时长排序，报告变异度与最慢阶段时长及结果。两个夹具都拒绝从未到达终态阶段的通过测试；仅实时有状态夹具自动进入资源释放阶段。不执行测试体即可校验阶段覆盖：

npm run test:e2e-phases:check

七、专项目标与资格验证

7.1 Hermes 沙箱镜像工件

沙箱镜像工作流在专门的 30 分钟build-hermes-sandbox-image作业中构建 Hermes 生产镜像：使用全 SHA 固定的 Buildx action、按 Runner OS 与架构隔离的缓存、有界 32 GiB swap 文件与受保护的守卫构建参数；构建后扫描 node-tar 并校验沙箱可读的已安装文件，上传压缩镜像为一日期hermes-isolation-image工件。90 分钟的test-hermes-sandbox-image作业下载并加载该工件而非重建；其中 secret-boundary 与 root-entrypoint 步骤分别有 45 与 30 分钟预算。

本地复现 root-entrypoint 失败：

NEMOCLAW_HERMES_TEST_IMAGE=nemoclaw-hermes-production NEMOCLAW_RUN_LIVE_E2E=1 \ npx vitest run --project e2e-live test/e2e/live/hermes-root-entrypoint-smoke.test.ts

Rancher Desktop 需加DOCKER_HOST=unix://$HOME/.rd/docker.sock；进程身份检查要用原生镜像，QEMU 可能让启动守卫拒绝合法 PID 1。从 checkout 用固定已发布基构建原生镜像：

docker build -f agents/hermes/Dockerfile -t nemoclaw-hermes-local .

然后设NEMOCLAW_HERMES_TEST_IMAGE=nemoclaw-hermes-local重跑。拒绝场景以 PID 1 启动，要求根准备退出码 1、非根布局修复退出码 78，再用验证脚本检查拒绝原因与文件系统状态。沙箱用户拥有配置目录并可删除其历史文件；sticky-bit 保护阻止网关用户删除沙箱所有的配置文件。原根级test/e2e-test.sh与test/e2e-gateway-isolation.sh套件已移除，其生产镜像安全覆盖现归 test/e2e-runtime/managed-image-openclaw-security.test.ts 与.github/workflows/sandbox-images.yaml中的managed-image-openclaw-security作业。

7.2 Launchable staging 与发布资格

staging-brev-launchable作业验证烘焙候选，而不安装或复制 NemoClaw 源码；显式专用的staging-brev-launchable-identity作业验证真实的 Launchable 启动、SSH 访问、镜像与烘焙运行时身份，不运行 onboarding 或推理，也不满足发布资格。include_staging_brev_launchable=true且jobs/targets为空的手动运行会运行默认 E2E 选择外加 staging Brev Launchable，工作流命名为E2E full main（带关联 ID 时一并标注）。

每次发布候选都必须有一个成功的候选Exact staging Brev Launchable作业，该证据可来自仅 Launchable 或全量运行，且不能被维护者的一般 E2E 决策豁免。该作业构建候选镜像、部署常驻 Launchable、验证启动镜像与烘焙运行时、运行带推理的预装全量 E2E 套件并确认工作区消失。Brev 相关凭据（BREV_API_KEY、BREV_ORG_ID、NEMOCLAW_IMAGE_DISPATCH_TOKEN、NVIDIA_API_KEY）只在受信宿主控制器与准备步骤中使用，且$HOME/.brev/credentials.json在工件上传前会被删除并验证其缺席。

7.3 专项资格：Jetson、Windows MXC、native runtime、DGX Spark Express vLLM

• Jetson：手动普通与全量运行排除jetson-nvmap-gpu，除非allow_jetson_dispatch=true（需仓库变量JETSON_DISPATCH_URL指向运维方派发服务）；每次受信main推送都会选择它而不改手动输入默认值。Jetson push 结果与 opt-in 硬件结果不进入严格全量运行资格集。
• Windows MXC OpenClaw：windows-mxc-openclaw-process-container.test.ts是 epic #8178 的显式本地资格目标，通过 OpenShellprocess_container驱动运行运维方提供的原生 Windows OpenShell 包与暂存 OpenClaw 工件，不注册 MXC、不直接调用wxc-exec.exe，也不建立 Windows 支持。它需要约二十个NEMOCLAW_WINDOWS_MXC_*环境变量描述工件树、身份与 SHA-256（详见文档的环境变量表），并运行：

$env:NEMOCLAW_RUN_LIVE_E2E = "1" $env:NEMOCLAW_RUN_WINDOWS_MXC_OPENCLAW_E2E = "1" npx vitest run --project e2e-live test/e2e/live/windows-mxc-openclaw-process-container.test.ts

• Native runtime qualification producer：jobs=native-runtime-qualification-producer从受信main派发，针对同仓库开放 PR 的 24 个案例，在env -i与临时账户下运行无特权安装器与实时测试进程，不接收任何 GitHub/推理/API/消息凭据且无 Docker；运行前须设NATIVE_RUNTIME_EPHEMERAL_RUNNER_POOL=enabled与NATIVE_RUNTIME_ARM64_GPU_RUNNER_LABEL。该资格不注册或选择生产环境的 Podman，也不建立公开 Podman 支持。
• DGX Spark Express vLLM：spark-express-vllm.test.ts是第二 DGX Spark Express 推理选项（目录支持固定 vLLM profile）的物理主机资格，要求合格 DGX Spark 且无无关nemoclaw-vllm容器，只接受本地 Docker socket 与默认上下文。运行方式：

E2E_JOB=1 \ E2E_TARGET_ID=spark-express-vllm \ NEMOCLAW_RUN_LIVE_E2E=1 \ NEMOCLAW_SANDBOX_NAME=e2e-spark-vllm \ npx tsx tools/e2e/live-vitest-invocation.mts run \ --test-path test/e2e/live/spark-express-vllm.test.ts

通过后证明 option-2 路径选择固定 vLLM preset/recipe、托管容器携带目录 provenance 与目录派生 serve 命令、inference.local完成 chat 请求、无关沙箱 egress 收到 HTTP 403。

7.4 配置文件导出类目标

• network-policy目标拥有 #10938/#11854/PR #11065 的实时配置导出证据：受限 OpenClaw onboarding 后通过真实 SDK 连接调用候选config export，比较 agent 名册、沙箱名、不可变托管镜像、托管端点与显式策略，然后篡改沙箱指纹并要求导出失败且不建文件。九个导出断言替换同目标中九个冗余检查。
• security-posture-hermes目标拥有 #11286 的 Hermes 实时导出证据：经nemoclaw与nemohermes两个 launcher 调用config export并要求规范文档一致，检查 Hermes agent 类型、不可变托管镜像、托管路由、生效策略与凭据值省略。
• ubuntu-repo-cloud-langchain-deepagents-code目标拥有 #11860 的 Deep Agents 导出证据：必须输出带deepagentsharness、托管 OpenAI 兼容路由、凭据引用与独立观测生效策略的 v1alpha1 文档，且导出前后注册表一致、沙箱保持 ready。
• brave-search目标在正常 Brave 启用的 OpenClaw onboarding 后验证配置导出：两次导出通过公开 schema、规范一致、仅BRAVE_API_KEY引用而无凭据值与内部传输。

7.5 GPU 与推理类目标

gpu-double-onboard、gpu-e2e、llama-cpp-generic-gpu经目录选择linux-amd64-gpu-rtxpro6000-latest-1。llama.cpp 目标比较所选模型认证/v1/models的meta.n_ctx与生成的 OpenClaw 主模型上下文窗口（无显式上下文覆盖），保留对比值于qualification-evidence.json。gpu-e2e还验证 attached-Ollama 导出在 v1alpha1 兼容性延后时仍被拒绝：先在共享端口创建托管代理，停安装器服务、起 fixture 拥有的 11439 端口守护进程并准备qwen2.5:0.5b模型，调用候选 CLI 与真实 SDK 一次，要求不支持的兼容性失败且不发布 YAML。

agent-turn-latency目标以文本与 JSON 两种输出检查已配置宿主 CLI（含显式本地模式与请求的超时）。内联消息的夹具在包装器关闭派发子进程 stdin 时保持宿主管道开启，因此继承该管道会阻塞到测试超时；文件消息轮次使用指向带空格路径文件的相对符号链接链，两种输出格式下都有竞争 stdin。首次 JSON 轮次还要求 OpenClaw 报告 agent 时长之外至多 60 秒，缺失或不一致计时即失败。这些用例在既有运行时矩阵中同时可选 Docker 与 Podman；宿主 stdin 对非空消息文件参数保留，因为只有沙箱能解析其路径。

八、性能预算与冷路径硬契约

full-e2e目标对作业中首次全新 onboarding 路径强制独立硬接受契约：从 onboard 根 span（向导步骤[1/8]之前的保守锚点）到首个非空 agent 响应测量，并读取注册的工作负载收据。收据必须是managed-image、使用与注册沙箱镜像标签匹配的精确摘要、标识所选发布 cohort 与精确源码修订、禁止本地 BuildKit 预构建。路径强制预算文件中的校准根与阶段上限，并把最长 onboard 输出间隙限制为 60 秒；违规即失败full-e2e并写入onboard-progress-budget.json。

预算配置位于 ci/onboard-performance-budget.json：totalBudgetMs为 390000，回归警告阈值为 minDelta 60000ms/minPercent 20%，阶段回归警告为 30000ms/30%；冷路径中rootStartToFirstTurnCompletionBudgetMs263000、rootEndToFirstTurnCompletionBudgetMs14000、本地基构建授权 570000，且nemoclaw.onboard.phase.sandbox保持 208000ms。full-e2e冷路径校准基线在 ci/full-e2e-cold-path-calibration.json 中记录。

对sandbox-phase-tail：仅有 5000ms 以内的超额且为唯一性能超额、使用托管镜像时，记为沙箱阶段尾部异常而非阻塞违规；超过 5000ms 仍阻塞。受信 push 记分卡使用同 agent/setup/platform/base-build/workload 的最新五个合格样本，当前异常仅在四个有效同队列样本均无异常时通过。托管首轮策略不变：根到首轮的唯一超时记为结构化非阻塞托管延迟异常，仅当根启动或阶段预算同时失败时才阻塞。

cloud-onboard的 push/手动记分卡对照该预算文件评估受信时序摘要；预算覆盖暖系统路径且为建议性——超总时长或回归阈值只发警告并加运行摘要细节，不使记分卡作业失败。冷镜像拉取、首次模型下载、provider 故障与 Runner/网络事件仍会影响信号，维护者应先查看时序表再行动。

九、重试、恢复与可靠性证据

9.1 有界重试与 Runner 恢复

外部操作使用显式有界重试策略（操作级），新共享路径使用有界操作助手；重试工件保留每次尝试。Automation / Recover Platform CI Runner可对合格CI / Platform Compatibilitypush 请求一次全量重跑，但不处理E2E main；完整的未通过作业清单必须只含批准 Runner 标签的已认证 Runner 丢失证据，普通断言失败、混合失败集、清单不完整、自定义/自托管标签、证据变化或歧义分页都会阻止恢复。对合格E2E mainpush，E2E / Main Retry Evidence只记录passed-first-attempt/passed-after-retry/failed-no-retry/ignored，绝不请求工作流重跑——GitHub 作业结论无法区分确定性产品断言、认证/授权失败、策略拒绝、畸形输入、歧义变更、清理失败与外部瞬态，因此宽泛失败作业重跑不是被授权的证据。

9.2 同一提交可靠性表

report-same-commit-reliability作业把 Markdown 表追加到作业摘要，并上传受界、允许列表的same-commit-reliability.json/.md（14 天保留）。工件 ZIP 条目在读取允许列表文件前做结构校验，拒绝歧义相对路径、链接、加密、split/ZIP64、重复名、不支持的压缩、不一致头、超量条目、超大内容与 CRC 不匹配。手动身份来自运行绑定的派发回执，其终态结果还要求至少一个绑定同一运行/尝试/候选 SHA/受信工作流仓库/工作流 SHA/作业状态的规范nemoclaw-e2e-evidence-v1清单。

9.3 Runner 对比遥测

受信main运行（无备用 checkout SHA）为 9 个路由工作流泳道身份/11 个具体作业执行记录 Runner 对比遥测，覆盖agent-turn-latency、common-egress-agent三个 shard、mcp-bridge（hermes 与 deepagents shard）、channels-stop-start（hermes shard）、hermes-discord、hermes-e2e、hermes-inference-switch（anthropic 模式）与security-posture（hermes shard）。每次执行把有界有序 v2 时间序列写入runner-comparison.jsonl：initialize（工件恢复后）、每个测试的scenario-start、约 60 秒周期的periodic、语义阶段切换的phase、always()步骤的finalize。v2 台账最多 256 个样本，末槽保留给finalize；缺失/历史 v1/已终结/已满/无效台账会永久禁用该执行实例的对比采样，退化为五分钟全量快照。总结写runner-comparison-summary.json，报告 CPU 均值与最忙区间、负载、可用/缓存/可回收/swap/根 cgroup/端点 OOM 计数器、内存与 I/O 压力、工作区字节与 inode、Docker 镜像/容器/构建缓存、最大容器内存与 CPU 及最大 RSS 固定进程类。该时间序列仅为诊断，不参与终态分类或重试策略。

9.4 云 onboard 痕迹清洗

原始 cloud-onboard traces 保留在 Runner 临时目录下；上传前scripts/e2e/sanitize-trace-timing.py将其归约为允许列表cloud-onboard-trace-timing-summary.json时序 schema 并删除原始目录。注册表驱动的 Vitest 目标也开启 onboard trace 收集，各自在临时目录下写原始 traces、清洗后上传、删除原始目录，只把e2e-artifacts/live/<target>/cloud-onboard-trace-timing-summary.json与目标工件一起上传；Slack/GitHub 记分卡对比仍绑定专用cloud-onboard工件以保持基线聚合稳定。旧 issue 中e2e-artifacts/vitest/的 Vitest 目标工件引用映射到合并后的e2e-artifacts/live/注册表目标工件布局。

十、运维实践：周度单测缺口评审

每次自动mainE2E 失败都被视为测试缺口评审输入。以已配置 GitHub CLI 认证生成前 168 小时报告：

evidence_dir="$(mktemp -d)" chmod 700 "$evidence_dir" npm run e2e:unit-gaps -- \ --days 7 \ --cache-dir "$evidence_dir/cache" \ --output "$evidence_dir/unit-test-gaps.md" \ --json-output "$evidence_dir/unit-test-gaps.json"

该命令从main的e2e.yaml与portable-profile-e2e.yaml读取 push 运行；在线收集需要--cache-dir，缓存目录以 0700 创建、规范化作业与签名 JSON 以 0600 写入；每次调用最多读取 50 个未缓存失败运行的日志，仍有剩余则以非零退出并保留批次，用同一缓存目录重跑直至完成。签名在内存中提取，不保留原始 GitHub 日志，应用共享全量 secret 脱敏器并移除易变标识、路径、URL、沙箱名与时长；缓存与报告在人工评审前视为凭据承载物。命令在 GitHub 认证/授权/限流失败、选定运行未完成、失败证据不可用、工作流达 1000 运行收集上限时停止——收窄范围重试，避免静默遗漏旧运行。每个失败运行必须逐候选原因评审：确定性产品失败 → 改产品代码前加单测/包契约回归测试；harness 失败 → 加e2e-support测试；外部失败 → 用故障注入测试重试与诊断响应，而非在单测中复现 provider/registry/网络/Runner 故障；需分诊的行 → 确认后再命名缺失契约。评审完成后只发布受审、免凭据的结论，并删除证据目录：

rm -rf -- "$evidence_dir" test ! -e "$evidence_dir"

十一、平台与历史的延续性

文档还记录了多项已退役覆盖的处置，作为理解现状的依据：Issue #7490 退役了通用 Brev 源码安装泳道（full→ Launchable E2E，credential-sanitization、telegram-injection、messaging-providers、messaging-compatible-endpoint、dashboard-remote-bind、gpu→ 统一 E2E 对应目标，all选择器退役）；Issue #11946 退役device-auth-health与cloud-inference独立目标，其断言分别归full-e2e、openclaw-inference-switch、src/lib/verify-deployment.test.ts 与 src/lib/verify-deployment-agent.test.ts、test/cli/sandbox-status-json.test.ts、test/repository/repo-skills-validation.test.ts 与 test/e2e-runtime/managed-image-openclaw-security.test.ts 等；Issue #11766 退役专用openclaw-plugin-runtime-exdev作业，原生 OpenClaw 安装/调用/更新/本地源替换/自更新试运行/重启存活/凭据不暴露/卸载由标准full-e2e目标在单一沙箱内覆盖。hermes-dashboard选择器保留为hermes-e2e的兼容别名。

十二、总结

NemoClaw 的 E2E CI 是一套以「受信工作流与候选源码分离」为基石的工程体系：候选 CLI 工件以内容寻址与 provenance 绑定保证身份，目录目标以结果导向显示名与凭据 profile 表达覆盖，类型化注册表与免凭据标签驱动规划器自动生成矩阵，语义阶段与进度证据使失败可定位、时序可比对，有界重试与 Runner 恢复证据把运维噪声与产品缺陷分离，最终由Relevant E2E（push/PR）与Release qualification（全量手动）两套门禁各司其职。若要深入，可继续阅读 tools/e2e/workflow-plan.mts、tools/e2e/target-catalogue.mts、tools/e2e/credential-free-tests.mts、test/e2e/registry/definitions/baseline.ts 与 ci/onboard-performance-budget.json，并在本地用npx tsx tools/e2e/workflow-plan.mts --summary直接查看当前默认选择矩阵。

【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址: https://gitcode.com/gh_mirrors/ne/NemoClaw