diff --git a/docs/zh-CN/ci.md b/docs/zh-CN/ci.md index 35c3f4c70..208807ff3 100644 --- a/docs/zh-CN/ci.md +++ b/docs/zh-CN/ci.md @@ -1,27 +1,27 @@ --- read_when: - - 你需要了解某个 CI 作业为什么会运行或没有运行 - - 你正在调试失败的 GitHub Actions 检查 -summary: CI 作业图、作用域门禁，以及本地等效命令 + - 你需要了解某个 CI 作业为什么运行了，或者为什么没有运行。 + - 你正在调试失败的 GitHub Actions 检查。 +summary: CI 作业图、范围门控，以及本地命令等效项 title: CI 流水线 x-i18n: - generated_at: "2026-04-26T22:14:42Z" + generated_at: "2026-04-26T22:39:45Z" model: gpt-5.4 provider: openai - source_hash: bad9dde51020fc3833d3848955a01af36e38e281a4c9de128b36b9553f66665e + source_hash: da03ca18ec9d3cc7057ce33d22fc692a2e0735e5bc88fedec7cfc1e144d49cd6 source_path: ci.md workflow: 15 --- -CI 会在每次推送到 `main` 以及每个拉取请求时运行。它使用智能作用域划分，在只有无关区域发生变更时跳过昂贵的作业。 +CI 会在每次推送到 `main` 以及每个拉取请求上运行。它使用智能范围划分，在仅有不相关区域发生变更时跳过高成本作业。 -QA Lab 在主智能作用域工作流之外有专门的 CI 通道。`Parity gate` 工作流会在匹配的 PR 变更以及手动触发时运行；它会构建私有 QA 运行时，并比较模拟的 GPT-5.5 和 Opus 4.6 agentic packs。`QA-Lab - All Lanes` 工作流会在 `main` 上每晚运行，也可以手动触发；它会并行扇出模拟 parity gate、实时 Matrix 通道和实时 Telegram 通道。实时作业使用 `qa-live-shared` environment，Telegram 通道使用 Convex leases。`OpenClaw Release Checks` 也会在发布批准前运行相同的 QA Lab 通道。 +QA Lab 在主智能范围工作流之外有专用的 CI lane。`Parity gate` 工作流会在匹配的 PR 变更和手动触发时运行；它会构建私有 QA 运行时，并比较模拟的 GPT-5.5 和 Opus 4.6 agentic packs。`QA-Lab - All Lanes` 工作流会在 `main` 上每晚运行，并支持手动触发；它会将模拟 parity gate、实时 Matrix lane 和实时 Telegram lane 作为并行作业扇出运行。实时作业使用 `qa-live-shared` environment，而 Telegram lane 使用 Convex leases。`OpenClaw Release Checks` 也会在发布批准前运行相同的 QA Lab lanes。 -`Duplicate PRs After Merge` 工作流是一个供维护者使用的手动工作流，用于合并后清理重复 PR。它默认使用 dry-run，只有在 `apply=true` 时才会关闭显式列出的 PR。在修改 GitHub 之前，它会验证已合并的 PR 确实已合并，并且每个重复 PR 要么具有共同引用的问题，要么存在重叠的变更代码块。 +`Duplicate PRs After Merge` 工作流是一个供维护者使用的手动工作流，用于合并后的重复 PR 清理。它默认是 dry-run，只有在 `apply=true` 时才会关闭显式列出的 PR。在变更 GitHub 状态之前，它会验证已落地的 PR 确实已合并，并验证每个重复 PR 是否具有共享的引用 issue，或存在重叠的变更 hunk。 -`Docs Agent` 工作流是一个由事件驱动的 Codex 维护通道，用于让现有文档与最近已合并的变更保持一致。它没有纯定时调度：在 `main` 上一次成功的、非机器人触发的 push CI 运行可以触发它，也可以通过手动触发直接运行。如果 `main` 已经继续前进，或者在过去一小时内已经创建了另一个未被跳过的 Docs Agent 运行，则 workflow-run 调用会跳过。当它运行时，会审查从上一个未被跳过的 Docs Agent 源 SHA 到当前 `main` 的提交范围，因此每小时一次的运行可以覆盖自上次文档处理以来累积的所有 main 变更。 +`Docs Agent` 工作流是一个事件驱动的 Codex 维护 lane，用于让现有文档与最近落地的变更保持一致。它没有纯定时调度：`main` 上一次成功的、非机器人触发的 push CI 运行可以触发它，手动触发也可以直接运行它。若 `main` 已继续前进，或者过去一小时内已经创建了另一个未被跳过的 Docs Agent 运行，则 workflow-run 触发会被跳过。当它运行时，它会审查从上一个未被跳过的 Docs Agent 源 SHA 到当前 `main` 的提交范围，因此每小时一次运行就可以覆盖自上次文档处理以来累积到 `main` 的所有变更。 -`Test Performance Agent` 工作流是一个由事件驱动的 Codex 维护通道，用于处理慢测试。它没有纯定时调度：在 `main` 上一次成功的、非机器人触发的 push CI 运行可以触发它，但如果该 UTC 日期内另一个 workflow-run 调用已经运行或正在运行，它就会跳过。手动触发会绕过这个按日活动门禁。该通道会构建完整测试套件的分组 Vitest 性能报告，让 Codex 只做小范围、保留覆盖率的测试性能修复，而不是进行大范围重构，然后重新运行完整测试套件报告，并拒绝任何会降低通过基线测试数量的变更。如果基线中存在失败测试，Codex 只能修复明显失败的问题，并且智能体处理后的完整测试套件报告必须通过，之后才会提交任何内容。当 `main` 在机器人推送落地前继续前进时，该通道会对已验证的补丁执行 rebase，重新运行 `pnpm check:changed`，并重试推送；存在冲突的过期补丁会被跳过。它使用 GitHub 托管的 Ubuntu，这样 Codex action 就能与 docs agent 保持相同的 drop-sudo 安全姿态。 +`Test Performance Agent` 工作流是一个事件驱动的 Codex 维护 lane，用于处理慢测试。它没有纯定时调度：`main` 上一次成功的、非机器人触发的 push CI 运行可以触发它，但如果当天 UTC 时间内已有另一个 workflow-run 触发已经运行或正在运行，它就会跳过。手动触发会绕过这个按天统计的活动门控。该 lane 会构建完整测试套件的分组 Vitest 性能报告，让 Codex 仅进行小范围、保持覆盖率不变的测试性能修复，而不是进行大规模重构，然后重新运行完整测试套件报告，并拒绝任何降低通过基线测试数量的更改。如果基线中已有失败测试，Codex 只能修复明显的失败项，并且在提交任何内容之前，智能体处理后的完整测试套件报告必须通过。当机器人推送落地前 `main` 又有新进展时，该 lane 会对已验证的补丁执行 rebase，重新运行 `pnpm check:changed`，并重试推送；存在冲突的过期补丁会被跳过。它使用 GitHub 托管的 Ubuntu，这样 Codex action 就能与 docs agent 保持相同的 drop-sudo 安全策略。 ```bash gh workflow run duplicate-after-merge.yml \ @@ -32,87 +32,87 @@ gh workflow run duplicate-after-merge.yml \ ## 作业概览 -| 作业 | 用途 | 运行时机 | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ | -| `preflight` | 检测是否仅文档变更、变更的作用域、变更的扩展，并构建 CI 清单 | 在所有非 draft 的 push 和 PR 上始终运行 | -| `security-scm-fast` | 通过 `zizmor` 进行私钥检测和工作流审计 | 在所有非 draft 的 push 和 PR 上始终运行 | -| `security-dependency-audit` | 针对 npm advisories 执行无需安装依赖的生产 lockfile 审计 | 在所有非 draft 的 push 和 PR 上始终运行 | -| `security-fast` | 快速安全作业的必需聚合项 | 在所有非 draft 的 push 和 PR 上始终运行 | -| `build-artifacts` | 构建 `dist/`、Control UI、构建产物检查，以及可复用的下游产物 | 与 Node 相关的变更 | -| `checks-fast-core` | 快速 Linux 正确性通道，例如 bundled/plugin-contract/protocol 检查 | 与 Node 相关的变更 | -| `checks-fast-contracts-channels` | 分片的渠道契约检查，并提供稳定的聚合检查结果 | 与 Node 相关的变更 | -| `checks-node-extensions` | 针对整个扩展套件的完整内置插件测试分片 | 与 Node 相关的变更 | -| `checks-node-core-test` | 核心 Node 测试分片，不包括渠道、内置、契约和扩展通道 | 与 Node 相关的变更 | -| `extension-fast` | 仅针对发生变更的内置插件进行聚焦测试 | 带有扩展变更的拉取请求 | -| `check` | 分片后的主要本地门禁等效项：生产类型、lint、守卫、测试类型和严格 smoke | 与 Node 相关的变更 | -| `check-additional` | 架构、边界、扩展表面守卫、包边界以及 gateway-watch 分片 | 与 Node 相关的变更 | -| `build-smoke` | 已构建 CLI 的 smoke 测试和启动内存 smoke 测试 | 与 Node 相关的变更 | -| `checks` | 已构建产物的渠道测试验证器，以及仅在 push 上运行的 Node 22 兼容性检查 | 与 Node 相关的变更 | -| `check-docs` | 文档格式、lint 和失效链接检查 | 文档发生变更 | -| `skills-python` | 面向 Python 支持的 Skills 的 Ruff + pytest | 与 Python Skills 相关的变更 | -| `checks-windows` | Windows 专用测试通道 | 与 Windows 相关的变更 | -| `macos-node` | 使用共享构建产物的 macOS TypeScript 测试通道 | 与 macOS 相关的变更 | -| `macos-swift` | macOS 应用的 Swift lint、构建和测试 | 与 macOS 相关的变更 | -| `android` | 两个 flavor 的 Android 单元测试，以及一次 debug APK 构建 | 与 Android 相关的变更 | -| `test-performance-agent` | 在可信活动之后每日运行的 Codex 慢测试优化 | main CI 成功后或手动触发 | +| Job | 目的 | 运行时机 | +| -------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------- | +| `preflight` | 检测是否仅有文档变更、变更范围、已变更扩展，并构建 CI manifest | 所有非草稿 push 和 PR | +| `security-scm-fast` | 通过 `zizmor` 进行私钥检测和工作流审计 | 所有非草稿 push 和 PR | +| `security-dependency-audit` | 针对 npm advisories 执行无依赖的生产 lockfile 审计 | 所有非草稿 push 和 PR | +| `security-fast` | 快速安全作业的必需聚合项 | 所有非草稿 push 和 PR | +| `build-artifacts` | 构建 `dist/`、Control UI、构建产物检查，以及供下游复用的构建产物 | 与 Node 相关的变更 | +| `checks-fast-core` | 快速 Linux 正确性 lane，例如 bundled/plugin-contract/protocol 检查 | 与 Node 相关的变更 | +| `checks-fast-contracts-channels` | 分片的渠道契约检查，并提供稳定的聚合检查结果 | 与 Node 相关的变更 | +| `checks-node-extensions` | 针对整个扩展套件的完整内置插件测试分片 | 与 Node 相关的变更 | +| `checks-node-core-test` | Core Node 测试分片，不包含渠道、内置、契约和扩展 lane | 与 Node 相关的变更 | +| `extension-fast` | 仅针对已变更内置插件的聚焦测试 | 含扩展变更的拉取请求 | +| `check` | 分片后的主本地门控等效项：生产类型、lint、防护项、测试类型和严格 smoke | 与 Node 相关的变更 | +| `check-additional` | 架构、边界、扩展表面防护、包边界以及 gateway-watch 分片 | 与 Node 相关的变更 | +| `build-smoke` | 已构建 CLI 的 smoke 测试和启动内存 smoke | 与 Node 相关的变更 | +| `checks` | 已构建产物渠道测试的验证器，以及仅在 push 上运行的 Node 22 兼容性检查 | 与 Node 相关的变更 | +| `check-docs` | 文档格式、lint 和失效链接检查 | 文档发生变更 | +| `skills-python` | 面向 Python 支持的 Skills 的 Ruff + pytest | 与 Python Skills 相关的变更 | +| `checks-windows` | Windows 专用测试 lane | 与 Windows 相关的变更 | +| `macos-node` | 使用共享构建产物的 macOS TypeScript 测试 lane | 与 macOS 相关的变更 | +| `macos-swift` | macOS 应用的 Swift lint、构建和测试 | 与 macOS 相关的变更 | +| `android` | 两个 flavor 的 Android 单元测试，以及一个 debug APK 构建 | 与 Android 相关的变更 | +| `test-performance-agent` | 在可信活动之后每日执行的 Codex 慢测试优化 | 主 CI 成功后或手动触发 | ## 快速失败顺序 -作业的排序方式是让低成本检查先失败，再决定是否运行高成本作业： +作业按顺序排列，以便低成本检查能在高成本作业运行前先失败： -1. `preflight` 决定到底存在哪些通道。`docs-scope` 和 `changed-scope` 逻辑是这个作业内部的步骤，不是独立作业。 +1. `preflight` 决定哪些 lane 会存在。`docs-scope` 和 `changed-scope` 逻辑是这个作业内部的步骤，不是独立作业。 2. `security-scm-fast`、`security-dependency-audit`、`security-fast`、`check`、`check-additional`、`check-docs` 和 `skills-python` 会快速失败，而无需等待更重的构建产物和平台矩阵作业。 -3. `build-artifacts` 会与快速 Linux 通道并行运行，这样下游消费者可以在共享构建准备好后立即开始。 -4. 更重的平台和运行时通道会在这之后扇出：`checks-fast-core`、`checks-fast-contracts-channels`、`checks-node-extensions`、`checks-node-core-test`、仅 PR 的 `extension-fast`、`checks`、`checks-windows`、`macos-node`、`macos-swift` 和 `android`。 +3. `build-artifacts` 会与快速 Linux lanes 并行运行，这样下游消费者就能在共享构建完成后立即启动。 +4. 更重的平台和运行时 lanes 会在此之后扇出运行：`checks-fast-core`、`checks-fast-contracts-channels`、`checks-node-extensions`、`checks-node-core-test`、仅限 PR 的 `extension-fast`、`checks`、`checks-windows`、`macos-node`、`macos-swift` 和 `android`。 -作用域逻辑位于 `scripts/ci-changed-scope.mjs`，并由 `src/scripts/ci-changed-scope.test.ts` 中的单元测试覆盖。 -CI 工作流编辑会验证 Node CI 图以及工作流 lint，但本身不会强制触发 Windows、Android 或 macOS 原生构建；这些平台通道仍然只针对平台源码变更进行作用域控制。 -仅涉及 CI 路由的编辑、部分低成本的 core-test fixture 编辑，以及狭义的插件契约辅助工具 / 测试路由编辑，会走一条快速的仅 Node 清单路径：preflight、安全检查，以及单个 `checks-fast-core` 任务。该路径会避开构建产物、Node 22 兼容性、渠道契约、完整 core 分片、内置插件分片以及额外守卫矩阵，前提是变更文件仅限于快速任务可直接覆盖的路由或辅助工具表面。 -Windows Node 检查的作用域限定在 Windows 专用的进程 / 路径包装器、npm/pnpm/UI 运行器辅助工具、包管理器配置，以及执行该通道的 CI 工作流表面；无关的源码、插件、install-smoke 和仅测试变更仍保留在 Linux Node 通道中，这样就不会为了普通测试分片已经覆盖的内容而占用一个 16 vCPU 的 Windows worker。 -独立的 `install-smoke` 工作流通过它自己的 `preflight` 作业复用了同一个作用域脚本。它将 smoke 覆盖拆分为 `run_fast_install_smoke` 和 `run_full_install_smoke`。对于拉取请求，Docker / package 表面、内置插件 package/manifest 变更，以及 Docker smoke 作业所覆盖的 core 插件 / 渠道 / Gateway 网关 / 插件 SDK 表面，会运行快速路径。仅源码的内置插件变更、仅测试编辑以及仅文档编辑不会占用 Docker workers。快速路径会构建一次根 Dockerfile 镜像，检查 CLI，运行 agents delete shared-workspace CLI smoke，运行 container gateway-network e2e，验证一个内置扩展构建参数，并在 240 秒的聚合命令超时内运行受限的内置插件 Docker profile，同时每个场景的 Docker run 也分别受限。完整路径则保留 QR package 安装以及 installer Docker/update 覆盖，用于夜间定时运行、手动触发、workflow-call 发布检查，以及真正触及 installer/package/Docker 表面的拉取请求。`main` 推送（包括 merge commits）不会强制走完整路径；当 changed-scope 逻辑会在 push 上请求完整覆盖时，该工作流仍然只保留快速 Docker smoke，而将完整 install smoke 留给夜间或发布验证。较慢的 Bun 全局安装 image-provider smoke 由单独的 `run_bun_global_install_smoke` 门禁控制；它会在夜间调度和发布检查工作流中运行，手动触发 `install-smoke` 时也可以选择启用，但拉取请求和 `main` 推送不会运行它。QR 和 installer Docker 测试保留各自专注于安装的 Dockerfiles。本地 `test:docker:all` 会预构建一个共享的 live-test 镜像，将 OpenClaw 一次性打包为 npm tarball，并构建两个共享的 `scripts/e2e/Dockerfile` 镜像：一个是供 installer/update/plugin-dependency 通道使用的纯 Node/Git 运行器，另一个是功能镜像，它会把同一个 tarball 安装到 `/app` 中，供普通功能通道使用。调度器会通过 `OPENCLAW_DOCKER_E2E_BARE_IMAGE` 和 `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` 为每个通道选择镜像，然后在 `OPENCLAW_SKIP_DOCKER_BUILD=1` 下运行这些通道；默认主池并发槽数为 10，可通过 `OPENCLAW_DOCKER_ALL_PARALLELISM` 调整；对提供商敏感的尾池并发槽数也为 10，可通过 `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` 调整。重型通道的默认上限分别为 `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`、`OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` 和 `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`，从而避免 npm install 和多服务通道让 Docker 过度承载，同时较轻的通道仍可填满可用槽位。默认情况下，通道启动会错开 2 秒，以避免本地 Docker daemon 出现 create 风暴；可以用 `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` 或其他毫秒值覆盖。本地聚合器会先检查 Docker、移除陈旧的 OpenClaw E2E 容器、输出活动通道状态、持久化通道耗时以支持最长优先排序，并支持 `OPENCLAW_DOCKER_ALL_DRY_RUN=1` 以检查调度器。默认情况下，在首次失败后它会停止继续调度新的池化通道；每个通道都有一个 120 分钟的后备超时，可通过 `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` 覆盖；部分 live/tail 通道使用更严格的单通道上限。`OPENCLAW_DOCKER_ALL_LANES=` 会运行精确指定的调度器通道，包括仅发布使用的通道，例如 `install-e2e`，以及按更新目标拆分的内置更新通道，例如 `bundled-channel-update-acpx`，同时会跳过 cleanup smoke，以便智能体复现某个失败通道。可复用的 live/E2E 工作流会构建并推送一个带 SHA 标签的 bare GHCR Docker E2E 镜像和一个带 SHA 标签的 functional GHCR Docker E2E 镜像，然后以最多三个分块作业运行发布路径 Docker 套件，并设置 `OPENCLAW_SKIP_DOCKER_BUILD=1`，这样每个分块都只拉取自己需要的镜像类型，并通过相同的加权调度器执行多个通道（`OPENCLAW_DOCKER_ALL_PROFILE=release-path`、`OPENCLAW_DOCKER_ALL_CHUNK=core|package-update|plugins-integrations`）。每个分块都会上传 `.artifacts/docker-tests/`，其中包含通道日志、耗时、`summary.json`、阶段耗时以及每个通道的重新运行命令。工作流输入 `docker_lanes` 会针对已准备好的镜像运行所选通道，而不是运行这三个分块作业，这样失败通道的调试就能限制在一个有针对性的 Docker 作业中；如果所选通道是 live Docker 通道，则该定向作业会在本地为该次重跑构建 live-test 镜像。当发布路径套件请求 Open WebUI 时，它会在 plugins/integrations 分块内运行，而不是额外占用第四个 Docker worker；只有 openwebui-only 触发时，Open WebUI 才保留独立作业。定时的 live/E2E 工作流每天运行完整的发布路径 Docker 套件。内置更新矩阵按更新目标拆分，因此重复的 npm update 和 doctor repair 轮次可以与其他内置检查分片并行。 +范围逻辑位于 `scripts/ci-changed-scope.mjs`，其单元测试位于 `src/scripts/ci-changed-scope.test.ts`。 +CI 工作流编辑会验证 Node CI 图和工作流 lint，但不会仅因这些编辑就强制触发 Windows、Android 或 macOS 原生构建；这些平台 lane 仍然只针对平台源码变更进行范围控制。 +仅涉及 CI 路由的编辑、选定的低成本 core-test fixture 编辑，以及窄范围的插件契约辅助工具 / 测试路由编辑，会走一条快速的仅 Node manifest 路径：preflight、安全检查，以及单个 `checks-fast-core` 任务。该路径会跳过构建产物、Node 22 兼容性、渠道契约、完整 core 分片、内置插件分片，以及额外的防护矩阵，前提是变更文件仅限于快速任务可直接覆盖的路由或辅助工具表面。 +Windows Node 检查的范围仅限于 Windows 专用的进程 / 路径包装器、npm/pnpm/UI runner 辅助工具、包管理器配置，以及执行该 lane 的 CI 工作流表面；不相关的源码、插件、install-smoke 和纯测试变更仍保留在 Linux Node lanes 中，这样就不会为已经由常规测试分片覆盖的内容占用一个 16-vCPU 的 Windows worker。 +单独的 `install-smoke` 工作流通过它自己的 `preflight` job 复用相同的范围脚本。它将 smoke 覆盖拆分为 `run_fast_install_smoke` 和 `run_full_install_smoke`。对于 pull request，Docker/包表面、内置插件包 / manifest 变更，以及 Docker smoke 作业所覆盖的 core 插件 / 渠道 / Gateway 网关 / 插件 SDK 表面会走快速路径。仅源码级的内置插件变更、纯测试编辑和纯文档编辑不会占用 Docker workers。快速路径会构建一次根 Dockerfile 镜像，检查 CLI，运行 agents delete shared-workspace CLI smoke，运行容器 `gateway-network` e2e，验证一个内置扩展构建参数，并在 240 秒的聚合命令超时下运行受限的内置插件 Docker profile，其中每个场景的 Docker 运行时间也分别设有上限。完整路径会为每夜定时运行、手动触发、workflow-call 发布检查，以及真正触及 installer/package/Docker 表面的 pull request 保留 QR 包安装和 installer Docker/update 覆盖。推送到 `main`，包括 merge commit，不会强制走完整路径；当 changed-scope 逻辑会在 push 上请求完整覆盖时，该工作流仍保留快速 Docker smoke，而将完整 install smoke 留给夜间运行或发布验证。较慢的 Bun 全局安装 image-provider smoke 由单独的 `run_bun_global_install_smoke` 门控；它会在夜间调度和 release checks 工作流中运行，手动触发 `install-smoke` 时也可选择启用，但 pull request 和 `main` push 不会运行它。QR 和 installer Docker 测试保留各自以安装为重点的 Dockerfile。本地 `test:docker:all` 会预构建一个共享的 live-test 镜像，将 OpenClaw 一次性打包为 npm tarball，并构建两个共享的 `scripts/e2e/Dockerfile` 镜像：一个是用于 installer/update/plugin-dependency lanes 的裸 Node/Git runner，另一个是功能镜像，会将同一个 tarball 安装到 `/app` 中，用于常规功能 lanes。Docker lane 定义位于 `scripts/lib/docker-e2e-scenarios.mjs`，规划逻辑位于 `scripts/lib/docker-e2e-plan.mjs`，runner 仅执行被选中的计划。调度器通过 `OPENCLAW_DOCKER_E2E_BARE_IMAGE` 和 `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` 为每个 lane 选择镜像，然后在 `OPENCLAW_SKIP_DOCKER_BUILD=1` 下运行各个 lane；默认主池槽位数为 10，可通过 `OPENCLAW_DOCKER_ALL_PARALLELISM` 调整，而对 provider 敏感的尾部池槽位数也默认为 10，可通过 `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` 调整。重型 lane 的上限默认分别为 `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`、`OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` 和 `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`，以避免 npm install 和多服务 lane 过度占用 Docker，同时让较轻的 lane 继续填满可用槽位。默认情况下，各 lane 启动会错开 2 秒，以避免本地 Docker daemon 出现 create 风暴；可通过 `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` 或其他毫秒值覆盖。本地聚合流程会先对 Docker 做 preflight，移除过期的 OpenClaw E2E 容器，输出活跃 lane 状态，持久化 lane 用时以便按“最长优先”排序，并支持使用 `OPENCLAW_DOCKER_ALL_DRY_RUN=1` 检查调度器。默认情况下，它会在首次失败后停止调度新的池化 lane，并且每个 lane 都有一个 120 分钟的兜底超时，可通过 `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` 覆盖；选定的 live/tail lanes 使用更严格的单 lane 上限。`OPENCLAW_DOCKER_ALL_LANES=` 会运行精确的调度器 lanes，包括仅限发布的 lanes，如 `install-e2e`，以及拆分的内置更新 lanes，如 `bundled-channel-update-acpx`，同时会跳过 cleanup smoke，以便智能体复现单个失败 lane。可复用的 live/E2E 工作流会询问 `scripts/test-docker-all.mjs --plan-json` 需要哪些包、镜像类型、live 镜像、lane 和凭证覆盖，然后由 `scripts/docker-e2e.mjs` 将该计划转换为 GitHub outputs 和摘要。它会通过 `scripts/package-openclaw-for-docker.mjs` 打包 OpenClaw；如果计划需要 install/update/plugin-dependency lanes，就构建并推送一个带 SHA 标签的 bare GHCR Docker E2E 镜像；如果计划需要 package-installed functionality lanes，则构建一个带 SHA 标签的 functional GHCR Docker E2E 镜像。发布路径的 Docker 套件最多会拆成三个分块 job，在 `OPENCLAW_SKIP_DOCKER_BUILD=1` 下运行，这样每个分块只拉取自己需要的镜像类型，并通过相同的加权调度器执行多个 lane（`OPENCLAW_DOCKER_ALL_PROFILE=release-path`、`OPENCLAW_DOCKER_ALL_CHUNK=core|package-update|plugins-integrations`）。每个分块都会上传 `.artifacts/docker-tests/`，其中包含 lane 日志、耗时、`summary.json`、阶段耗时、调度器计划 JSON，以及每个 lane 的重跑命令。工作流输入 `docker_lanes` 会让选定 lanes 针对已准备好的镜像运行，而不是运行这三个分块 job；这样可以将失败 lane 的调试限制在一个有针对性的 Docker job 中；如果被选中的 lane 是 live Docker lane，该定向 job 会在本地为该次重跑构建 live-test 镜像。当发布路径套件请求 Open WebUI 时，它会在 plugins/integrations 分块中运行，而不是再额外占用第四个 Docker worker；只有 openwebui-only dispatch 时，Open WebUI 才会保留独立 job。定时的 live/E2E 工作流每天运行完整的发布路径 Docker 套件。内置更新矩阵按更新目标拆分，以便重复的 npm update 和 doctor repair 过程可以与其他内置检查一起分片执行。 -本地 changed-lane 逻辑位于 `scripts/changed-lanes.mjs`，并由 `scripts/check-changed.mjs` 执行。这个本地门禁在架构边界方面比宽泛的 CI 平台作用域更严格：core 生产变更会运行 core prod 类型检查加 core 测试，core 仅测试变更只运行 core test 类型检查 / 测试，扩展生产变更会运行 extension prod 类型检查加 extension 测试，而扩展仅测试变更只运行 extension test 类型检查 / 测试。公开的插件 SDK 或插件契约变更会扩大为扩展验证，因为扩展依赖这些 core 契约。仅发布元数据的版本号变更会运行定向的版本 / 配置 / 根依赖检查。未知的根目录 / 配置变更会以安全优先方式落入所有通道。 +本地 changed-lane 逻辑位于 `scripts/changed-lanes.mjs`，并由 `scripts/check-changed.mjs` 执行。这个本地门控在架构边界方面比宽泛的 CI 平台范围更严格：core 生产变更会运行 core prod typecheck 加 core tests，core 纯测试变更只运行 core test typecheck/tests，扩展生产变更会运行 extension prod typecheck 加 extension tests，而扩展纯测试变更只运行 extension test typecheck/tests。公开的插件 SDK 或插件契约变更会扩展到扩展验证，因为扩展依赖这些 core 契约。仅发布元数据的版本号变更会运行定向的版本 / 配置 / 根依赖检查。未知的 root/config 变更会以安全优先方式退回到所有 lanes。 -在 push 上，`checks` 矩阵会增加仅 push 运行的 `compat-node22` 通道。在拉取请求上，该通道会被跳过，矩阵只保留普通测试 / 渠道通道。 +在 push 上，`checks` 矩阵会增加仅限 push 的 `compat-node22` lane。在 pull request 上，该 lane 会被跳过，矩阵会继续聚焦于常规测试 / 渠道 lanes。 -最慢的 Node 测试家族会被拆分或平衡，以便每个作业都保持较小规模，同时避免过度占用 runners：渠道契约会作为三个加权分片运行，内置插件测试会在六个扩展 workers 之间平衡分布，小型 core 单元通道会成对组合，auto-reply 会以四个平衡 worker 运行，其中 reply 子树被拆分为 agent-runner、dispatch 和 commands/state-routing 分片，而 agentic Gateway 网关 / 插件配置则会分散到现有的仅源码 agentic Node 作业中，而不是等待构建产物。广义的浏览器、QA、媒体以及杂项插件测试使用它们各自专用的 Vitest 配置，而不是共享的插件兜底配置。扩展分片作业一次最多运行两个插件配置组，每组使用一个 Vitest worker，并分配更大的 Node heap，这样导入密集型的插件批次就不会产生额外的 CI 作业。广义的 agents 通道使用共享的 Vitest 文件级并行调度器，因为它主要受导入 / 调度支配，而不是由某个单独的慢测试文件主导。`runtime-config` 与 infra core-runtime 分片一起运行，以避免共享运行时分片独占尾部耗时。基于 include-pattern 的分片会使用 CI 分片名称记录耗时条目，因此 `.artifacts/vitest-shard-timings.json` 可以区分完整配置和经过过滤的分片。`check-additional` 会把 package-boundary compile/canary 工作保留在一起，并将运行时拓扑架构与 gateway watch 覆盖拆开；boundary guard 分片会在一个作业内部并发运行其小型且相互独立的守卫。Gateway 网关 watch、渠道测试以及 core support-boundary 分片会在 `dist/` 和 `dist-runtime/` 已构建完成后，在 `build-artifacts` 内部并发运行，从而保留它们原有的检查名称，作为轻量级 verifier 作业，同时避免额外占用两个 Blacksmith workers 和第二条 artifact-consumer 队列。 -Android CI 会同时运行 `testPlayDebugUnitTest` 和 `testThirdPartyDebugUnitTest`，然后构建 Play debug APK。第三方 flavor 没有单独的源码集或 manifest；它的单元测试通道仍会在启用 SMS/call-log BuildConfig 标志的情况下编译该 flavor，同时避免在每次与 Android 相关的 push 上重复执行 debug APK 打包作业。 -`extension-fast` 仅在 PR 上运行，因为 push 运行已经执行了完整的内置插件分片。这样既能为评审提供已变更插件的快速反馈，又不会在 `main` 上为了 `checks-node-extensions` 已经覆盖的内容额外占用一个 Blacksmith worker。 +最慢的 Node 测试族会被拆分或重新平衡，以便每个 job 都保持较小规模而不过度占用 runner：渠道契约分成三个加权分片运行，内置插件测试在六个扩展 worker 上做负载均衡，小型 core 单元 lane 会成对组合，自动回复会作为四个平衡 worker 运行，并且 reply 子树会拆分为 agent-runner、dispatch 以及 commands/state-routing 分片，agentic Gateway 网关 / 插件配置会分散到现有的仅源码 agentic Node jobs 中，而不是等待构建产物。广泛的浏览器、QA、媒体和杂项插件测试使用其专用的 Vitest 配置，而不是共享的插件兜底配置。扩展分片 job 每次最多运行两个插件配置组，每组使用一个 Vitest worker，并配备更大的 Node heap，这样导入密集型插件批次就不会产生额外的 CI jobs。广泛的 agents lane 使用共享的 Vitest 文件级并行调度器，因为它主要受导入 / 调度支配，而不是由某个单独的慢测试文件主导。`runtime-config` 与 infra core-runtime 分片一起运行，以防共享运行时分片承担尾部压力。基于 include pattern 的分片会使用 CI 分片名称记录耗时条目，因此 `.artifacts/vitest-shard-timings.json` 可以区分整个配置与筛选后的分片。`check-additional` 会将 package-boundary 的 compile/canary 工作保持在一起，并将运行时拓扑架构与 gateway watch 覆盖分离；边界防护分片会在一个 job 内并发运行其体量较小、相互独立的防护项。Gateway watch、渠道测试以及 core support-boundary 分片会在 `build-artifacts` 中于 `dist/` 和 `dist-runtime/` 构建完成后并发运行，同时保留其旧的检查名称作为轻量级 verifier jobs，从而避免再占用两个额外的 Blacksmith workers 和第二条 artifact-consumer 队列。 +Android CI 会同时运行 `testPlayDebugUnitTest` 和 `testThirdPartyDebugUnitTest`，然后构建 Play debug APK。第三方 flavor 没有单独的 source set 或 manifest；它的单元测试 lane 仍会在启用 SMS/call-log BuildConfig 标志的情况下编译该 flavor，同时避免在每次与 Android 相关的 push 上重复执行 debug APK 打包 job。 +`extension-fast` 仅在 PR 上运行，因为 push 运行已经执行了完整的内置插件分片。这样既能为评审保留已变更插件的反馈，又不会在 `main` 上额外占用一个 Blacksmith worker 去做 `checks-node-extensions` 已经覆盖过的内容。 -当同一个 PR 或 `main` 引用上有更新的推送到达时，GitHub 可能会将被替代的作业标记为 `cancelled`。除非同一引用上的最新运行也失败，否则应将其视为 CI 噪声。聚合分片检查使用 `!cancelled() && always()`，因此它们仍会报告正常的分片失败，但不会在整个工作流已经被替代后继续排队。 -CI 并发键是带版本号的（`CI-v7-*`），这样 GitHub 侧旧队列组中的僵尸任务就不会无限期阻塞更新的 main 运行。 +当同一个 PR 或 `main` ref 上有更新的 push 到来时，GitHub 可能会将被取代的作业标记为 `cancelled`。除非同一 ref 上最新的一次运行也失败，否则应将其视为 CI 噪音。聚合分片检查使用 `!cancelled() && always()`，因此它们仍会报告正常的分片失败，但不会在整个工作流已经被取代后继续排队。 +CI 并发 key 采用了带版本号的形式（`CI-v7-*`），这样 GitHub 端旧队列组中的僵尸任务就不会无限期阻塞更新的 `main` 运行。 -## Runners +## 运行器 -| 运行器 | 作业 | +| 运行器 | Jobs | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`、快速安全作业及其聚合项（`security-scm-fast`、`security-dependency-audit`、`security-fast`）、快速 protocol/contract/bundled 检查、分片的渠道契约检查、除 lint 外的 `check` 分片、`check-additional` 分片及其聚合项、Node 测试聚合验证器、文档检查、Python Skills、workflow-sanity、labeler、auto-response；install-smoke preflight 也使用 GitHub 托管的 Ubuntu，这样 Blacksmith 矩阵可以更早进入排队 | +| `ubuntu-24.04` | `preflight`、快速安全作业及其聚合项（`security-scm-fast`、`security-dependency-audit`、`security-fast`）、快速 protocol/contract/bundled 检查、分片的渠道契约检查、除 lint 之外的 `check` 分片、`check-additional` 分片及聚合项、Node 测试聚合验证器、文档检查、Python Skills、workflow-sanity、labeler、auto-response；install-smoke preflight 也使用 GitHub 托管的 Ubuntu，以便 Blacksmith 矩阵能更早排队 | | `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`、build-smoke、Linux Node 测试分片、内置插件测试分片、`android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`，因为它对 CPU 仍然足够敏感，以至于 8 vCPU 的成本高于节省；install-smoke Docker 构建，因为 32 vCPU 的排队时间成本高于节省 | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`，它对 CPU 仍足够敏感，以至于 8 vCPU 的成本高于其节省；install-smoke Docker 构建，其中 32-vCPU 的排队时间成本高于其节省 | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `openclaw/openclaw` 上的 `macos-node`；fork 会回退到 `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `openclaw/openclaw` 上的 `macos-swift`；fork 会回退到 `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | 在 `openclaw/openclaw` 上运行的 `macos-node`；fork 会回退到 `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | 在 `openclaw/openclaw` 上运行的 `macos-swift`；fork 会回退到 `macos-latest` | -## 本地等效命令 +## 本地等效项 ```bash -pnpm changed:lanes # 检查 origin/main...HEAD 的本地变更通道分类器 -pnpm check:changed # 智能本地门禁：按边界通道运行变更相关的 typecheck/lint/tests -pnpm check # 快速本地门禁：生产 tsgo + 分片 lint + 并行快速守卫 +pnpm changed:lanes # 检查针对 origin/main...HEAD 的本地 changed-lane 分类器 +pnpm check:changed # 智能本地门控：按边界 lane 执行变更相关的 typecheck/lint/tests +pnpm check # 快速本地门控：生产 tsgo + 分片 lint + 并行快速防护项 pnpm check:test-types -pnpm check:timed # 相同门禁，但带每个阶段的耗时 +pnpm check:timed # 相同门控，但带有各阶段耗时 pnpm build:strict-smoke pnpm check:architecture pnpm test:gateway:watch-regression pnpm test # vitest 测试 pnpm test:channels pnpm test:contracts:channels -pnpm check:docs # 文档格式 + lint + 失效链接 -pnpm build # 当 CI artifact/build-smoke 通道相关时构建 dist -pnpm ci:timings # 汇总最近一次 origin/main push CI 运行 +pnpm check:docs # 文档格式 + lint + 失效链接检查 +pnpm build # 当 CI 构建产物 / build-smoke lanes 相关时，构建 dist +pnpm ci:timings # 汇总最新一次 origin/main push CI 运行 pnpm ci:timings:recent # 比较最近成功的 main CI 运行 -node scripts/ci-run-timings.mjs # 汇总总耗时、排队时间和最慢的作业 -node scripts/ci-run-timings.mjs --latest-main # 忽略 issue/comment 噪声并选择 origin/main push CI +node scripts/ci-run-timings.mjs # 汇总总耗时、排队时间和最慢的 jobs +node scripts/ci-run-timings.mjs --latest-main # 忽略 issue/comment 噪音并选择 origin/main push CI node scripts/ci-run-timings.mjs --recent 10 # 比较最近成功的 main CI 运行 pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json diff --git a/docs/zh-CN/help/testing.md b/docs/zh-CN/help/testing.md index e99f7ae53..06d8587ad 100644 --- a/docs/zh-CN/help/testing.md +++ b/docs/zh-CN/help/testing.md @@ -1,151 +1,150 @@ --- read_when: - 在本地或 CI 中运行测试 - - 为模型/提供商缺陷添加回归测试 + - 为模型 / 提供商缺陷添加回归测试 - 调试 Gateway 网关 + 智能体行为 -summary: 测试工具包：unit/e2e/live 测试套件、Docker 运行器，以及每项测试覆盖的内容 +summary: 测试工具包：单元 / e2e / live 测试套件、Docker 运行器，以及每类测试覆盖的内容 title: 测试 x-i18n: - generated_at: "2026-04-26T22:14:43Z" + generated_at: "2026-04-26T22:39:47Z" model: gpt-5.4 provider: openai - source_hash: 425a86fc79b306f1957308c4060874d8d10a5ac61fb29b6cb91b7df3f445db91 + source_hash: 4499f5092819a250971610ce3e31191b871cd2a1d2915bb7479f9439cea94dcd source_path: help/testing.md workflow: 15 --- -OpenClaw 有三个 Vitest 测试套件（unit/integration、e2e、live）以及一小组 Docker 运行器。本文档是一份“我们如何测试”的指南： +OpenClaw 有三个 Vitest 测试套件（单元 / 集成、e2e、live）以及一小组 Docker 运行器。本文档是关于“我们如何测试”的指南： -- 每个测试套件覆盖什么内容（以及它刻意**不**覆盖什么）。 -- 常见工作流应运行哪些命令（本地、推送前、调试）。 -- live 测试如何发现凭证，以及如何选择模型/提供商。 -- 如何为真实世界中的模型/提供商问题添加回归测试。 +- 每个测试套件覆盖什么内容（以及它刻意 _不_ 覆盖什么）。 +- 常见工作流（本地、推送前、调试）应运行哪些命令。 +- live 测试如何发现凭证并选择模型 / 提供商。 +- 如何为真实世界中的模型 / 提供商问题添加回归测试。 ## 快速开始 -大多数时候： +大多数情况下： -- 完整门禁（预期在推送前运行）：`pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- 在配置充足的机器上更快地运行本地完整测试套件：`pnpm test:max` -- 直接进入 Vitest 观察循环：`pnpm test:watch` -- 现在直接按文件定位也会路由扩展/渠道路径：`pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- 当你正在迭代单个失败用例时，优先使用定向运行。 -- Docker 支持的 QA 站点：`pnpm qa:lab:up` -- Linux VM 支持的 QA 通道：`pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- 完整门禁（预期在推送前执行）：`pnpm build && pnpm check && pnpm check:test-types && pnpm test` +- 在配置宽裕的机器上更快地运行本地完整测试套件：`pnpm test:max` +- 直接使用 Vitest 观察模式循环：`pnpm test:watch` +- 现在直接按文件路径定向也支持 extension / channel 路径：`pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- 当你在迭代修复单个失败用例时，优先先运行有针对性的测试。 +- 基于 Docker 的 QA 站点：`pnpm qa:lab:up` +- 基于 Linux VM 的 QA 通道：`pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -当你改动了测试，或想获得更高信心时： +当你修改了测试或想获得更高信心时： - 覆盖率门禁：`pnpm test:coverage` - E2E 测试套件：`pnpm test:e2e` -当调试真实提供商/模型时（需要真实凭证）： +当你在调试真实提供商 / 模型时（需要真实凭证）： -- live 测试套件（模型 + Gateway 网关工具/图像探测）：`pnpm test:live` -- 安静地仅运行一个 live 文件：`pnpm test:live -- src/agents/models.profiles.live.test.ts` +- live 测试套件（模型 + Gateway 网关工具 / 图像探测）：`pnpm test:live` +- 安静地只跑一个 live 文件：`pnpm test:live -- src/agents/models.profiles.live.test.ts` - Docker live 模型扫描：`pnpm test:docker:live-models` - - 现在每个选定模型都会运行一次文本轮次以及一次小型类文件读取探测。元数据声明支持 `image` 输入的模型还会运行一个极小的图像轮次。隔离提供商故障时，可使用 `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` 或 `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` 禁用额外探测。 - - CI 覆盖：每日的 `OpenClaw Scheduled Live And E2E Checks` 和手动的 `OpenClaw Release Checks` 都会调用可复用的 live/E2E 工作流，并设置 `include_live_suites: true`，其中包含按提供商分片的独立 Docker live 模型矩阵任务。 - - 如需更聚焦的 CI 重跑，可分发 `OpenClaw Live And E2E Checks (Reusable)`，并设置 `include_live_suites: true` 与 `live_models_only: true`。 - - 将新的高信号提供商密钥添加到 `scripts/ci-hydrate-live-auth.sh`、`.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` 以及它的 scheduled/release 调用方中。 + - 现在每个选中的模型都会运行一次文本轮次外加一个小型的文件读取风格探测。元数据声明支持 `image` 输入的模型还会额外运行一个微型图像轮次。在隔离提供商故障时，可通过 `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` 或 `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0` 关闭这些额外探测。 + - CI 覆盖：每日执行的 `OpenClaw Scheduled Live And E2E Checks` 和手动执行的 `OpenClaw Release Checks` 都会调用可复用的 live / E2E 工作流，并设置 `include_live_suites: true`，其中包含按提供商分片的独立 Docker live 模型矩阵任务。 + - 对于聚焦型 CI 重跑，可调度 `OpenClaw Live And E2E Checks (Reusable)`，并设置 `include_live_suites: true` 和 `live_models_only: true`。 + - 将新的高信号提供商 secrets 添加到 `scripts/ci-hydrate-live-auth.sh`、`.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` 以及其定时 / 发布调用方中。 - 原生 Codex 绑定聊天冒烟测试：`pnpm test:docker:live-codex-bind` - - 在 Codex app-server 路径上运行一个 Docker live 通道，使用 `/codex bind` 绑定一个合成 Slack 私信，会执行 `/codex fast` 和 `/codex permissions`，然后验证普通回复和图像附件会通过原生插件绑定路由，而不是 ACP。 + - 在 Codex app-server 路径上运行一个 Docker live 通道，绑定一个合成的 Slack 私信并执行 `/codex bind`，运行 `/codex fast` 和 `/codex permissions`，然后验证普通回复和图像附件都是通过原生插件绑定而不是 ACP 路由的。 - Codex app-server harness 冒烟测试：`pnpm test:docker:live-codex-harness` - - 通过插件自有的 Codex app-server harness 运行 Gateway 网关智能体轮次，验证 `/codex status` 和 `/codex models`，并且默认会执行图像、cron MCP、sub-agent 和 Guardian 探测。隔离其他 Codex app-server 故障时，可使用 `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0` 禁用 sub-agent 探测。若要专门检查 sub-agent，请禁用其他探测：`OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`。 - 除非设置了 `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`，否则该命令会在 sub-agent 探测后退出。 -- Crestodian 救援命令冒烟测试：`pnpm test:live:crestodian-rescue-channel` - - 这是对消息渠道救援命令表面的一个可选“多重保险”检查。它会执行 `/crestodian status`，排队一个持久化模型变更，回复 `/crestodian yes`，并验证审计/配置写入路径。 + - 通过插件拥有的 Codex app-server harness 运行 Gateway 网关智能体轮次，验证 `/codex status` 和 `/codex models`，并且默认执行图像、cron MCP、子智能体和 Guardian 探测。在隔离其他 Codex app-server 故障时，可通过 `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0` 关闭子智能体探测。若要聚焦检查子智能体，请关闭其他探测：`OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`。 + 除非设置了 `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`，否则该命令会在子智能体探测后退出。 +- Crestodian rescue command 冒烟测试：`pnpm test:live:crestodian-rescue-channel` + - 针对消息渠道 rescue command 表面的可选加固检查。它会执行 `/crestodian status`，排队一个持久模型变更，回复 `/crestodian yes`，并验证审计 / 配置写入路径。 - Crestodian planner Docker 冒烟测试：`pnpm test:docker:crestodian-planner` - - 在一个无配置容器中运行 Crestodian，并在 `PATH` 上提供伪造的 Claude CLI，验证模糊 planner 回退会转换为带审计的强类型配置写入。 + - 在一个无配置容器中运行 Crestodian，并在 `PATH` 中放置一个伪造的 Claude CLI，验证模糊 planner 回退会转换为一条带审计记录的类型化配置写入。 - Crestodian 首次运行 Docker 冒烟测试：`pnpm test:docker:crestodian-first-run` - - 从一个空的 OpenClaw 状态目录启动，将裸 `openclaw` 路由到 Crestodian，应用 setup/model/agent/Discord plugin + SecretRef 写入，验证配置，并检查审计条目。相同的 Ring 0 设置路径也会在 QA Lab 中通过 `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup` 覆盖。 -- Moonshot/Kimi 成本冒烟测试：设置 `MOONSHOT_API_KEY` 后，运行 `openclaw models list --provider moonshot --json`，然后对 `moonshot/kimi-k2.6` 运行一个隔离的 `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` - 。验证 JSON 报告的是 Moonshot/K2.6，并且 assistant transcript 存储了标准化后的 `usage.cost`。 + - 从空的 OpenClaw 状态目录启动，将裸 `openclaw` 路由到 Crestodian，应用 setup / model / agent / Discord 插件 + SecretRef 写入，验证配置，并检查审计条目。相同的 Ring 0 设置路径也在 QA Lab 中通过 `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup` 覆盖。 +- Moonshot / Kimi 成本冒烟测试：设置 `MOONSHOT_API_KEY` 后，运行 `openclaw models list --provider moonshot --json`，然后针对 `moonshot/kimi-k2.6` 运行一个隔离的 `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json`。验证 JSON 报告的是 Moonshot / K2.6，且 assistant transcript 中存储了标准化的 `usage.cost`。 -提示：当你只需要一个失败用例时，优先通过下文描述的 allowlist 环境变量来收窄 live 测试范围。 +提示：当你只需要一个失败用例时，优先使用下文描述的 allowlist 环境变量来收窄 live 测试范围。 ## QA 专用运行器 -当你需要 QA-lab 级别的真实环境时，这些命令与主测试套件并列存在： +当你需要 QA-lab 级别的真实性时，这些命令位于主测试套件旁边： -CI 会在专用工作流中运行 QA Lab。`Parity gate` 会在匹配的 PR 上运行，也可通过手动分发使用 mock 提供商运行。`QA-Lab - All Lanes` 会在 `main` 上夜间运行，也可通过手动分发运行，其中 mock parity gate、live Matrix 通道以及 Convex 托管的 live Telegram 通道会作为并行任务执行。`OpenClaw Release Checks` 会在发布审批前运行相同的通道。 +CI 会在专用工作流中运行 QA Lab。`Parity gate` 会在匹配的 PR 上以及通过手动调度运行，使用 mock 提供商。`QA-Lab - All Lanes` 会在 `main` 上每晚运行，并可通过手动调度运行，其中 mock parity gate、live Matrix 通道和由 Convex 管理的 live Telegram 通道作为并行任务执行。`OpenClaw Release Checks` 会在发布批准前运行同样的通道。 - `pnpm openclaw qa suite` - 直接在主机上运行基于仓库的 QA 场景。 - - 默认会用隔离的 Gateway 网关工作进程并行运行多个选定场景。`qa-channel` 默认并发为 4（受所选场景数量限制）。使用 `--concurrency ` 调整工作进程数量，或使用 `--concurrency 1` 回到旧的串行通道。 - - 任何场景失败时都会以非零状态退出。若你想保留产物但不希望退出码失败，请使用 `--allow-failures`。 - - 支持 `live-frontier`、`mock-openai` 和 `aimock` 三种提供商模式。`aimock` 会启动一个本地 AIMock 支持的提供商服务器，用于实验性 fixture 和协议 mock 覆盖，而不会替代具备场景感知能力的 `mock-openai` 通道。 + - 默认情况下，会使用隔离的 Gateway 网关工作进程并行运行多个选定场景。`qa-channel` 默认并发数为 4（受所选场景数量限制）。使用 `--concurrency ` 可调整工作进程数量，或使用 `--concurrency 1` 以采用较早的串行通道。 + - 当任一场景失败时会以非零状态退出。如果你想保留工件但不希望以失败退出码结束，可使用 `--allow-failures`。 + - 支持提供商模式 `live-frontier`、`mock-openai` 和 `aimock`。`aimock` 会启动一个本地的、由 AIMock 支持的提供商服务器，用于实验性的夹具和协议 mock 覆盖，而不会替代具备场景感知能力的 `mock-openai` 通道。 - `pnpm openclaw qa suite --runner multipass` - - 在一次性的 Multipass Linux VM 中运行同一个 QA 测试套件。 + - 在一次性 Multipass Linux VM 中运行同一个 QA 测试套件。 - 与主机上的 `qa suite` 保持相同的场景选择行为。 - - 复用与 `qa suite` 相同的提供商/模型选择标志。 - - live 运行会转发那些对来宾环境实际可行的受支持 QA 认证输入：基于环境变量的提供商密钥、QA live 提供商配置路径，以及存在时的 `CODEX_HOME`。 - - 输出目录必须保持在仓库根目录下，以便来宾可通过挂载的工作区回写。 + - 复用与 `qa suite` 相同的提供商 / 模型选择标志。 + - live 运行会转发对 guest 来说实际可用的受支持 QA 认证输入：基于环境变量的提供商密钥、QA live 提供商配置路径，以及存在时的 `CODEX_HOME`。 + - 输出目录必须保持在仓库根目录下，以便 guest 能通过挂载的工作区写回内容。 - 会将常规 QA 报告 + 摘要以及 Multipass 日志写入 `.artifacts/qa-e2e/...`。 - `pnpm qa:lab:up` - - 启动 Docker 支持的 QA 站点，用于面向操作员风格的 QA 工作。 + - 启动基于 Docker 的 QA 站点，用于偏操作员风格的 QA 工作。 - `pnpm test:docker:npm-onboard-channel-agent` - - 从当前检出构建一个 npm tarball，在 Docker 中全局安装，运行非交互式 OpenAI API-key 新手引导，默认配置 Telegram，验证启用插件时会按需安装运行时依赖，运行 doctor，并针对一个 mock OpenAI 端点执行一次本地智能体轮次。 - - 使用 `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` 可通过 Discord 运行相同的打包安装通道。 + - 从当前 checkout 构建一个 npm tarball，在 Docker 中全局安装，以非交互方式运行 OpenAI API 密钥新手引导，默认配置 Telegram，验证启用插件会按需安装运行时依赖，运行 doctor，并针对一个 mock 的 OpenAI 端点执行一次本地智能体轮次。 + - 使用 `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` 可在 Discord 上运行相同的打包安装通道。 - `pnpm test:docker:session-runtime-context` - - 为嵌入式运行时上下文 transcript 运行一个确定性的已构建应用 Docker 冒烟测试。它会验证隐藏的 OpenClaw 运行时上下文被作为非展示型自定义消息持久化，而不会泄漏到可见的用户轮次中；随后植入一个受影响的损坏 session JSONL，并验证 `openclaw doctor --fix` 会将其重写到当前活动分支并创建备份。 + - 运行一个确定性的已构建应用 Docker 冒烟测试，用于嵌入式运行时上下文 transcript。它会验证隐藏的 OpenClaw 运行时上下文会以非展示型自定义消息持久化，而不会泄漏到可见的用户轮次中；随后会植入一个受影响的损坏会话 JSONL，并验证 `openclaw doctor --fix` 会将其重写到当前活动分支并保留备份。 - `pnpm test:docker:npm-telegram-live` - 在 Docker 中安装一个已发布的 OpenClaw 软件包，运行已安装软件包的新手引导，通过已安装的 CLI 配置 Telegram，然后复用 live Telegram QA 通道，并将该已安装软件包作为被测 Gateway 网关。 - - 默认使用 `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`。 - - 使用与 `pnpm openclaw qa telegram` 相同的 Telegram 环境变量凭证或 Convex 凭证来源。对于 CI/发布自动化，设置 `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex`，并同时设置 `OPENCLAW_QA_CONVEX_SITE_URL` 与角色密钥。如果在 CI 中存在 `OPENCLAW_QA_CONVEX_SITE_URL` 和 Convex 角色密钥，Docker 包装器会自动选择 Convex。 - - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` 仅为这个通道覆盖共享的 `OPENCLAW_QA_CREDENTIAL_ROLE`。 - - GitHub Actions 将此通道暴露为手动维护者工作流 `NPM Telegram Beta E2E`。它不会在合并时运行。该工作流使用 `qa-live-shared` 环境和 Convex CI 凭证租约。 + - 默认为 `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`。 + - 与 `pnpm openclaw qa telegram` 使用相同的 Telegram 环境变量凭证或 Convex 凭证来源。对于 CI / 发布自动化，设置 `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex`，并同时设置 `OPENCLAW_QA_CONVEX_SITE_URL` 和角色 secret。如果在 CI 中存在 `OPENCLAW_QA_CONVEX_SITE_URL` 和一个 Convex 角色 secret，Docker 包装器会自动选择 Convex。 + - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` 可仅为这一通道覆盖共享的 `OPENCLAW_QA_CREDENTIAL_ROLE`。 + - GitHub Actions 将这个通道作为手动维护者工作流 `NPM Telegram Beta E2E` 暴露。它不会在合并时运行。该工作流使用 `qa-live-shared` 环境和 Convex CI 凭证租约。 - `pnpm test:docker:bundled-channel-deps` - - 在 Docker 中打包并安装当前 OpenClaw 构建，配置 OpenAI 后启动 Gateway 网关，然后通过配置编辑启用内置渠道/plugins。 - - 验证 setup 发现阶段不会安装尚未配置的 plugin 运行时依赖；首次配置后的 Gateway 网关或 doctor 运行会按需安装每个内置 plugin 的运行时依赖；第二次重启不会重新安装已经激活的依赖。 - - 还会安装一个已知较旧的 npm 基线版本，在运行 `openclaw update --tag ` 之前启用 Telegram，并验证候选版本的更新后 doctor 会修复内置渠道运行时依赖，而无需 harness 侧的 postinstall 修复。 + - 在 Docker 中打包并安装当前 OpenClaw 构建版本，配置 OpenAI 后启动 Gateway 网关，然后通过配置编辑启用内置的渠道 / 插件。 + - 验证 setup 发现流程不会安装未配置插件的运行时依赖；首次配置后的 Gateway 网关或 doctor 运行会按需安装每个内置插件的运行时依赖；第二次重启不会重新安装已激活的依赖。 + - 还会安装一个已知较旧的 npm 基线版本，在运行 `openclaw update --tag ` 前启用 Telegram，并验证候选版本在更新后的 doctor 中会修复内置渠道的运行时依赖，而无需 harness 侧的 postinstall 修复。 - `pnpm test:parallels:npm-update` - - 在 Parallels 来宾环境中运行原生打包安装更新冒烟测试。每个选定平台都会先安装所请求的基线软件包，然后在同一来宾中运行已安装的 `openclaw update` 命令，并验证已安装版本、更新状态、gateway 就绪状态以及一次本地智能体轮次。 - - 在迭代单个来宾时，使用 `--platform macos`、`--platform windows` 或 `--platform linux`。使用 `--json` 获取摘要产物路径和每个通道的状态。 - - 默认情况下，OpenAI 通道会使用 `openai/gpt-5.5` 作为 live 智能体轮次验证模型。若要有意验证其他 OpenAI 模型，请传递 `--model ` 或设置 `OPENCLAW_PARALLELS_OPENAI_MODEL`。 - - 将较长的本地运行包裹在主机超时中，以防 Parallels 传输卡住而耗尽剩余测试窗口： + - 在 Parallels guest 上运行原生打包安装更新冒烟测试。每个选中的平台会先安装请求的基线软件包，然后在同一个 guest 中运行已安装的 `openclaw update` 命令，并验证安装版本、更新状态、网关可用性以及一次本地智能体轮次。 + - 在迭代单个 guest 时，使用 `--platform macos`、`--platform windows` 或 `--platform linux`。使用 `--json` 获取摘要工件路径和各通道状态。 + - 默认情况下，OpenAI 通道使用 `openai/gpt-5.5` 作为 live 智能体轮次验证模型。若你有意验证其他 OpenAI 模型，可传入 `--model ` 或设置 `OPENCLAW_PARALLELS_OPENAI_MODEL`。 + - 请为长时间本地运行包裹主机超时，以防 Parallels 传输停顿耗尽剩余测试窗口： ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json ``` - - 该脚本会将嵌套通道日志写入 `/tmp/openclaw-parallels-npm-update.*`。在认定外层包装器卡住之前，请检查 `windows-update.log`、`macos-update.log` 或 `linux-update.log`。 - - 在冷启动来宾中，Windows 更新可能会在更新后 doctor/运行时依赖修复阶段花费 10 到 15 分钟；只要嵌套的 npm 调试日志仍在推进，这仍属于健康状态。 - - 不要将这个聚合包装器与单独的 Parallels macOS、Windows 或 Linux 冒烟通道并行运行。它们共享 VM 状态，可能在快照恢复、软件包服务或来宾 gateway 状态上发生冲突。 - - 更新后验证会运行常规内置 plugin 表面，因为即使智能体轮次本身只检查简单的文本响应，语音、图像生成和媒体理解等能力门面仍然是通过内置运行时 API 加载的。 + - 该脚本会将嵌套通道日志写入 `/tmp/openclaw-parallels-npm-update.*` 下。不要在看到外层包装器似乎卡住时立刻下结论，先检查 `windows-update.log`、`macos-update.log` 或 `linux-update.log`。 + - Windows 更新在冷 guest 上可能会花费 10 到 15 分钟执行更新后 doctor / 运行时依赖修复；只要嵌套的 npm 调试日志仍在推进，这仍属于健康状态。 + - 不要将这个聚合包装器与单独的 Parallels macOS、Windows 或 Linux 冒烟通道并行运行。它们共享 VM 状态，可能会在快照恢复、软件包分发或 guest Gateway 网关状态上发生冲突。 + - 更新后的验证会运行常规的内置插件表面，因为语音、图像生成和媒体理解等能力外观层即使在智能体轮次本身只检查简单文本响应时，也仍通过内置运行时 API 加载。 - `pnpm openclaw qa aimock` - 仅启动本地 AIMock 提供商服务器，用于直接协议冒烟测试。 - `pnpm openclaw qa matrix` - - 针对一次性的 Docker 支持 Tuwunel homeserver 运行 Matrix live QA 通道。 - - 这个 QA 主机目前仅供仓库/开发使用。打包后的 OpenClaw 安装不包含 `qa-lab`，因此不会暴露 `openclaw qa`。 - - 仓库检出会直接加载内置运行器；不需要单独的 plugin 安装步骤。 - - 会配置三个临时 Matrix 用户（`driver`、`sut`、`observer`）以及一个私有房间，然后以真实 Matrix plugin 作为被测传输层启动一个 QA gateway 子进程。 - - 默认使用固定稳定版 Tuwunel 镜像 `ghcr.io/matrix-construct/tuwunel:v1.5.1`。当你需要测试其他镜像时，可使用 `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE` 覆盖。 - - Matrix 不暴露共享的凭证来源标志，因为该通道会在本地配置一次性用户。 - - 会将 Matrix QA 报告、摘要、observed-events 产物以及合并的 stdout/stderr 输出日志写入 `.artifacts/qa-e2e/...`。 + - 针对一次性的、基于 Docker 的 Tuwunel homeserver 运行 Matrix live QA 通道。 + - 这个 QA 主机目前仅供仓库 / 开发使用。打包后的 OpenClaw 安装不包含 `qa-lab`，因此不会暴露 `openclaw qa`。 + - 仓库 checkout 会直接加载内置运行器；不需要单独的插件安装步骤。 + - 会预配三个临时 Matrix 用户（`driver`、`sut`、`observer`）以及一个私有房间，然后启动一个 QA Gateway 网关子进程，并使用真实的 Matrix 插件作为 SUT 传输层。 + - 默认使用固定的稳定版 Tuwunel 镜像 `ghcr.io/matrix-construct/tuwunel:v1.5.1`。当你需要测试其他镜像时，可通过 `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE` 覆盖。 + - Matrix 不暴露共享凭证来源标志，因为该通道会在本地预配一次性用户。 + - 会将 Matrix QA 报告、摘要、observed-events 工件以及合并后的 stdout / stderr 输出日志写入 `.artifacts/qa-e2e/...`。 - 默认会输出进度，并通过 `OPENCLAW_QA_MATRIX_TIMEOUT_MS`（默认 30 分钟）强制执行硬性运行超时。清理由 `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS` 限制，失败信息中会包含恢复命令 `docker compose ... down --remove-orphans`。 - `pnpm openclaw qa telegram` - - 使用环境变量中的 driver 和 SUT bot token，针对真实私有群组运行 Telegram live QA 通道。 - - 需要 `OPENCLAW_QA_TELEGRAM_GROUP_ID`、`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` 和 `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`。群组 id 必须是数字类型的 Telegram chat id。 - - 支持 `--credential-source convex` 以使用共享池化凭证。默认使用 env 模式，或设置 `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` 以启用池化租约。 - - 当任何场景失败时会以非零状态退出。若你想保留产物但不希望退出码失败，请使用 `--allow-failures`。 - - 需要同一私有群组中的两个不同 bot，并且 SUT bot 必须公开一个 Telegram 用户名。 - - 为了实现稳定的 bot-to-bot 观察，请在 `@BotFather` 中为两个 bot 都启用 Bot-to-Bot Communication Mode，并确保 driver bot 可以观察群组中的 bot 流量。 - - 会将 Telegram QA 报告、摘要和 observed-messages 产物写入 `.artifacts/qa-e2e/...`。回复类场景会包含从 driver 发送请求到观测到 SUT 回复的 RTT。 + - 使用环境变量中的 driver 和 SUT bot token，针对一个真实私有群组运行 Telegram live QA 通道。 + - 需要 `OPENCLAW_QA_TELEGRAM_GROUP_ID`、`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` 和 `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`。group id 必须是数字形式的 Telegram chat id。 + - 支持 `--credential-source convex` 以使用共享凭证池。默认使用环境变量模式，或者设置 `OPENCLAW_QA_CREDENTIAL_SOURCE=convex` 以启用池化租约。 + - 当任一场景失败时会以非零状态退出。如果你想保留工件但不希望以失败退出码结束，可使用 `--allow-failures`。 + - 要求在同一个私有群组中使用两个不同的 bot，并且 SUT bot 必须暴露一个 Telegram 用户名。 + - 为了获得稳定的 bot 对 bot 观测，请在 `@BotFather` 中为两个 bot 启用 Bot-to-Bot Communication Mode，并确保 driver bot 能观察群组中的 bot 流量。 + - 会将 Telegram QA 报告、摘要以及 observed-messages 工件写入 `.artifacts/qa-e2e/...`。回复类场景会包含从 driver 发送请求到观测到 SUT 回复之间的 RTT。 -live 传输通道共享同一个标准契约，这样新传输不会逐渐偏离： +live 传输通道共享一个标准契约，因此新增传输方式时不会发生漂移： -`qa-channel` 仍然是广泛的合成 QA 测试套件，不属于 live 传输覆盖矩阵的一部分。 +`qa-channel` 仍然是宽泛的合成 QA 测试套件，不属于 live 传输覆盖矩阵的一部分。 -| 通道 | Canary | Mention gating | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | -| ---- | ------ | -------------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| 通道 | Canary | 提及门控 | Allowlist 阻止 | 顶层回复 | 重启恢复 | 线程跟进 | 线程隔离 | Reaction 观测 | 帮助命令 | +| ---- | ------ | -------- | -------------- | -------- | -------- | -------- | -------- | ------------- | -------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### 通过 Convex 共享 Telegram 凭证（v1） -当为 `openclaw qa telegram` 启用 `--credential-source convex`（或 `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`）时，QA lab 会从 Convex 支持的池中获取独占租约，在通道运行期间为该租约发送心跳，并在关闭时释放租约。 +当为 `openclaw qa telegram` 启用 `--credential-source convex`（或 `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`）时，QA lab 会从一个由 Convex 支持的池中获取独占租约，在通道运行期间为该租约发送心跳，并在关闭时释放该租约。 参考 Convex 项目脚手架： @@ -154,12 +153,12 @@ live 传输通道共享同一个标准契约，这样新传输不会逐渐偏离 必需的环境变量： - `OPENCLAW_QA_CONVEX_SITE_URL`（例如 `https://your-deployment.convex.site`） -- 为所选角色提供一个密钥： +- 所选角色对应的一个 secret： - `maintainer` 使用 `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` - `ci` 使用 `OPENCLAW_QA_CONVEX_SECRET_CI` - 凭证角色选择： - CLI：`--credential-role maintainer|ci` - - 环境默认值：`OPENCLAW_QA_CREDENTIAL_ROLE`（在 CI 中默认是 `ci`，否则默认是 `maintainer`） + - 环境变量默认值：`OPENCLAW_QA_CREDENTIAL_ROLE`（在 CI 中默认是 `ci`，否则为 `maintainer`） 可选环境变量： @@ -168,12 +167,12 @@ live 传输通道共享同一个标准契约，这样新传输不会逐渐偏离 - `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS`（默认 `90000`） - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS`（默认 `15000`） - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX`（默认 `/qa-credentials/v1`） -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID`（可选跟踪 id） +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID`（可选的追踪 id） - `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` 允许在仅限本地开发时使用 loopback `http://` Convex URL。 -在正常运行中，`OPENCLAW_QA_CONVEX_SITE_URL` 应使用 `https://`。 +正常运行时，`OPENCLAW_QA_CONVEX_SITE_URL` 应使用 `https://`。 -维护者管理命令（池添加/删除/列出）明确要求使用 `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`。 +维护者管理命令（池添加 / 删除 / 列表）必须专门使用 `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`。 供维护者使用的 CLI 辅助命令： @@ -184,87 +183,87 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -在 live 运行前使用 `doctor`，可检查 Convex site URL、broker 密钥、端点前缀、HTTP 超时以及 admin/list 可达性，而不会打印密钥值。在脚本和 CI 工具中使用 `--json` 获取机器可读输出。 +在 live 运行前使用 `doctor`，可检查 Convex site URL、broker secrets、endpoint prefix、HTTP 超时以及 admin / list 可达性，同时不会打印 secret 值。在脚本和 CI 工具中可使用 `--json` 获取机器可读输出。 默认端点契约（`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`）： - `POST /acquire` - 请求：`{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - 成功：`{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - 资源耗尽/可重试：`{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - 资源耗尽 / 可重试：`{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - 请求：`{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - 成功：`{ status: "ok" }`（或空的 `2xx`） - `POST /release` - 请求：`{ kind, ownerId, actorRole, credentialId, leaseToken }` - 成功：`{ status: "ok" }`（或空的 `2xx`） -- `POST /admin/add`（仅限 maintainer 密钥） +- `POST /admin/add`（仅限 maintainer secret） - 请求：`{ kind, actorId, payload, note?, status? }` - 成功：`{ status: "ok", credential }` -- `POST /admin/remove`（仅限 maintainer 密钥） +- `POST /admin/remove`（仅限 maintainer secret） - 请求：`{ credentialId, actorId }` - 成功：`{ status: "ok", changed, credential }` - 活跃租约保护：`{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list`（仅限 maintainer 密钥） +- `POST /admin/list`（仅限 maintainer secret） - 请求：`{ kind?, status?, includePayload?, limit? }` - 成功：`{ status: "ok", credentials, count }` Telegram 类型的负载结构： - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` 必须是数字类型的 Telegram chat id 字符串。 -- `admin/add` 会为 `kind: "telegram"` 验证此结构，并拒绝格式错误的负载。 +- `groupId` 必须是数字形式的 Telegram chat id 字符串。 +- 对于 `kind: "telegram"`，`admin/add` 会验证此结构，并拒绝格式错误的负载。 ### 向 QA 添加一个渠道 向 Markdown QA 系统添加一个渠道，严格来说只需要两样东西： 1. 该渠道的传输适配器。 -2. 一个用于执行渠道契约的场景包。 +2. 一个用于验证渠道契约的场景包。 -当共享的 `qa-lab` 主机可以承载流程时，不要新增顶层 QA 命令根。 +当共享的 `qa-lab` 主机可以承载该流程时，不要添加新的顶层 QA 命令根。 `qa-lab` 负责共享主机机制： - `openclaw qa` 命令根 -- suite 启动和拆除 -- worker 并发 -- 产物写入 +- 测试套件启动和拆除 +- 工作进程并发 +- 工件写入 - 报告生成 - 场景执行 -- 针对旧版 `qa-channel` 场景的兼容别名 +- 对旧版 `qa-channel` 场景的兼容别名 -运行器 plugins 负责传输契约： +运行器插件负责传输契约： -- 如何将 `openclaw qa ` 挂载到共享 `qa` 根命令之下 -- 如何为该传输配置 gateway +- `openclaw qa ` 如何挂载到共享的 `qa` 根命令下 +- 如何为该传输配置网关 - 如何检查就绪状态 - 如何注入入站事件 -- 如何观察出站消息 +- 如何观测出站消息 - 如何暴露 transcript 和标准化传输状态 -- 如何执行传输支持的操作 +- 如何执行基于传输的操作 - 如何处理传输特定的重置或清理 新渠道的最低采用门槛是： -1. 保持 `qa-lab` 作为共享 `qa` 根命令的拥有者。 +1. 保持由 `qa-lab` 负责共享的 `qa` 根命令。 2. 在共享的 `qa-lab` 主机接缝上实现传输运行器。 -3. 将传输特定机制保留在运行器 plugin 或渠道 harness 内部。 +3. 将传输特定机制保留在运行器插件或渠道 harness 内部。 4. 将运行器挂载为 `openclaw qa `，而不是注册一个相互竞争的根命令。 - 运行器 plugins 应在 `openclaw.plugin.json` 中声明 `qaRunners`，并从 `runtime-api.ts` 导出匹配的 `qaRunnerCliRegistrations` 数组。 - 保持 `runtime-api.ts` 轻量；延迟 CLI 和运行器执行应位于独立入口点之后。 -5. 在带主题的 `qa/scenarios/` 目录下编写或改造 Markdown 场景。 + 运行器插件应在 `openclaw.plugin.json` 中声明 `qaRunners`，并从 `runtime-api.ts` 导出匹配的 `qaRunnerCliRegistrations` 数组。 + 保持 `runtime-api.ts` 轻量；惰性 CLI 和运行器执行应留在独立入口点之后。 +5. 在具有主题划分的 `qa/scenarios/` 目录下编写或改造 Markdown 场景。 6. 为新场景使用通用场景辅助函数。 -7. 除非仓库正在进行有意迁移，否则保持现有兼容别名继续可用。 +7. 除非仓库正在执行有意迁移，否则保持现有兼容别名继续可用。 决策规则很严格： -- 如果某个行为可以在 `qa-lab` 中表达一次，就把它放在 `qa-lab`。 -- 如果某个行为依赖单一渠道传输，就把它保留在该运行器 plugin 或 plugin harness 中。 -- 如果某个场景需要超过一个渠道可复用的新能力，请添加通用辅助函数，而不是在 `suite.ts` 中添加渠道特定分支。 -- 如果某个行为只对某一种传输有意义，就让场景保持传输特定性，并在场景契约中明确表达。 +- 如果某个行为可以在 `qa-lab` 中统一表达一次，就把它放进 `qa-lab`。 +- 如果某个行为依赖于单一渠道传输，就把它保留在该运行器插件或插件 harness 中。 +- 如果某个场景需要多个渠道都可使用的新能力，应添加通用辅助函数，而不是在 `suite.ts` 中增加渠道特定分支。 +- 如果某个行为只对单一传输有意义，就保持该场景是传输特定的，并在场景契约中明确说明。 -新场景推荐使用的通用辅助函数名称是： +新场景优先使用的通用辅助函数名称是： - `waitForTransportReady` - `waitForChannelReady` @@ -279,7 +278,7 @@ Telegram 类型的负载结构： - `formatTransportTranscript` - `resetTransport` -现有场景仍可使用兼容别名，包括： +现有场景仍可使用的兼容别名包括： - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -288,20 +287,20 @@ Telegram 类型的负载结构： - `resetBus` 新的渠道工作应使用通用辅助函数名称。 -兼容别名的存在是为了避免一次性“flag day”迁移，而不是作为新场景编写的范式。 +兼容别名的存在是为了避免一次性强制迁移，而不是作为新场景编写的范式。 -## 测试套件（各自运行位置） +## 测试套件（分别在哪里运行） -可以把这些测试套件理解为“真实性逐步增加”（同时不稳定性/成本也逐步增加）： +可以把这些测试套件理解为“真实性逐步提升”（同时不稳定性 / 成本也逐步增加）： -### Unit / integration（默认） +### 单元 / 集成（默认） - 命令：`pnpm test` -- 配置：未定向运行使用 `vitest.full-*.config.ts` 分片集合，并且可能将多项目分片展开为按项目划分的配置，以便并行调度 -- 文件：核心/unit 清单位于 `src/**/*.test.ts`、`packages/**/*.test.ts`、`test/**/*.test.ts`，以及由 `vitest.unit.config.ts` 覆盖的白名单 `ui` node 测试 +- 配置：未定向运行使用 `vitest.full-*.config.ts` 分片集，并且可能会将多项目分片展开为按项目划分的配置，以便并行调度 +- 文件：核心 / 单元测试清单位于 `src/**/*.test.ts`、`packages/**/*.test.ts`、`test/**/*.test.ts`，以及 `vitest.unit.config.ts` 覆盖的白名单 `ui` Node 测试 - 范围： - - 纯 unit 测试 - - 进程内 integration 测试（gateway 认证、路由、工具、解析、配置） + - 纯单元测试 + - 进程内集成测试（Gateway 网关认证、路由、工具、解析、配置） - 针对已知缺陷的确定性回归测试 - 预期： - 在 CI 中运行 @@ -309,341 +308,343 @@ Telegram 类型的负载结构： - 应该快速且稳定 - + - - 未定向的 `pnpm test` 会运行 12 个更小的分片配置（`core-unit-fast`、`core-unit-src`、`core-unit-security`、`core-unit-ui`、`core-unit-support`、`core-support-boundary`、`core-contracts`、`core-bundled`、`core-runtime`、`agentic`、`auto-reply`、`extensions`），而不是一个庞大的原生根项目进程。这样可以降低高负载机器上的峰值 RSS，并避免 auto-reply/扩展工作拖慢无关测试套件。 - - `pnpm test --watch` 仍然使用原生根 `vitest.config.ts` 项目图，因为多分片 watch 循环并不现实。 - - `pnpm test`、`pnpm test:watch` 和 `pnpm test:perf:imports` 会先通过作用域通道对显式文件/目录目标进行路由，因此 `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` 不必承担完整根项目启动的成本。 - - `pnpm test:changed` 会在差异仅触及可路由的源码/测试文件时，将变更的 git 路径扩展到相同的作用域通道；配置/setup 改动仍会回退到更广泛的根项目重跑。 - - `pnpm check:changed` 是窄范围工作下常规的智能本地门禁。它会将差异归类到 core、core tests、extensions、extension tests、apps、docs、release metadata、live Docker tooling 和 tooling，然后运行匹配的 typecheck/lint/test 通道。公共插件 SDK 和 plugin-contract 变更会额外包含一次扩展验证，因为扩展依赖这些 core 契约。仅包含发布元数据的版本提升会运行定向版本/配置/根依赖检查，而不是完整测试套件，并带有一项保护措施，用于拒绝顶层 version 字段以外的 package 变更。 - - live Docker ACP harness 改动会运行一个聚焦的本地门禁：live Docker 认证脚本的 shell 语法、live Docker 调度器 dry-run、ACP bind unit 测试以及 ACPX 扩展测试。只有当差异被限制在 `scripts["test:docker:live-*"]` 时才会包含 `package.json` 变更；依赖、导出、版本和其他 package 表面改动仍会使用更广泛的保护措施。 - - 来自 agents、commands、plugins、auto-reply 辅助函数、`plugin-sdk` 及类似纯工具区域的轻导入 unit 测试，会通过 `unit-fast` 通道运行，该通道会跳过 `test/setup-openclaw-runtime.ts`；有状态/运行时较重的文件仍保留在现有通道中。 - - 部分 `plugin-sdk` 和 `commands` 辅助源码文件也会把 changed 模式运行映射到这些轻量通道中的显式同级测试，因此辅助函数改动可以避免为该目录重跑完整的重型测试套件。 - - `auto-reply` 具有专门的分桶，用于顶层 core 辅助函数、顶层 `reply.*` integration 测试，以及 `src/auto-reply/reply/**` 子树。CI 还会将 reply 子树进一步拆分为 agent-runner、dispatch 和 commands/state-routing 分片，这样就不会由某一个重导入分桶独占完整的 Node 尾部耗时。 + - 未定向的 `pnpm test` 会运行十二个更小的分片配置（`core-unit-fast`、`core-unit-src`、`core-unit-security`、`core-unit-ui`、`core-unit-support`、`core-support-boundary`、`core-contracts`、`core-bundled`、`core-runtime`、`agentic`、`auto-reply`、`extensions`），而不是启动一个巨大的原生根项目进程。这可以降低高负载机器上的峰值 RSS，并避免 auto-reply / extension 工作拖慢无关测试套件。 + - `pnpm test --watch` 仍使用原生根 `vitest.config.ts` 项目图，因为多分片 watch 循环并不现实。 + - `pnpm test`、`pnpm test:watch` 和 `pnpm test:perf:imports` 会先通过定向通道处理显式文件 / 目录目标，因此 `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` 可以避免承担完整根项目启动成本。 + - `pnpm test:changed` 会在差异仅涉及可路由的源文件 / 测试文件时，将变更的 git 路径展开到相同的定向通道；配置 / setup 编辑仍会回退到更宽泛的根项目重跑。 + - `pnpm check:changed` 是针对小范围工作的常规智能本地门禁。它会将差异归类为 core、core tests、extensions、extension tests、apps、docs、发布元数据、live Docker 工具以及工具链，然后运行匹配的类型检查 / lint / 测试通道。公共 Plugin SDK 和插件契约变更会额外包含一次 extension 验证，因为 extensions 依赖这些核心契约。仅涉及发布元数据的版本升级会运行定向的版本 / 配置 / 根依赖检查，而不是完整测试套件，并通过一个保护机制拒绝顶层版本字段之外的 package 变更。 + - live Docker ACP harness 编辑会运行一个聚焦型本地门禁：对 live Docker 认证脚本做 shell 语法检查、执行 live Docker 调度器 dry-run、运行 ACP bind 单元测试以及 ACPX extension 测试。只有当差异仅限于 `scripts["test:docker:live-*"]` 时，才会包含 `package.json` 变更；依赖、导出、版本和其他 package 表面编辑仍会使用更宽泛的保护措施。 + - 来自 agents、commands、plugins、auto-reply 辅助函数、`plugin-sdk` 以及类似纯工具区域的轻导入单元测试，会路由到 `unit-fast` 通道，该通道会跳过 `test/setup-openclaw-runtime.ts`；有状态 / 运行时较重的文件仍保留在现有通道中。 + - 选定的 `plugin-sdk` 和 `commands` 辅助源文件也会将 changed 模式运行映射到这些轻量通道中的显式同级测试，因此辅助函数编辑无需为该目录重跑完整的重型测试套件。 + - `auto-reply` 为顶层 core 辅助函数、顶层 `reply.*` 集成测试以及 `src/auto-reply/reply/**` 子树提供了专用分桶。CI 还会进一步将 reply 子树拆分为 agent-runner、dispatch 和 commands / state-routing 分片，这样导入较重的单个分桶就不会独占整个 Node 收尾阶段。 - - 当你修改消息工具发现输入或 compaction 运行时上下文时，请同时保留两层覆盖。 - - 为纯路由和标准化边界添加聚焦的辅助函数回归测试。 - - 保持嵌入式运行器 integration 测试套件健康： + - 当你修改消息工具发现输入或压缩运行时上下文时，请同时保留两个层级的覆盖。 + - 为纯路由和标准化边界添加聚焦型辅助函数回归测试。 + - 保持嵌入式运行器集成测试套件健康： `src/agents/pi-embedded-runner/compact.hooks.test.ts`、 `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` 和 `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`。 - - 这些测试套件会验证作用域 id 和 compaction 行为仍然通过真实的 `run.ts` / `compact.ts` 路径流动；仅有辅助函数测试不足以替代这些 integration 路径。 + - 这些测试套件验证带作用域的 id 和压缩行为仍会通过真实的 `run.ts` / `compact.ts` 路径流转；仅辅助函数测试不足以替代这些集成路径。 - 基础 Vitest 配置默认使用 `threads`。 - - 共享的 Vitest 配置固定为 `isolate: false`，并在根项目、e2e 和 live 配置中使用非隔离运行器。 - - 根 UI 通道保留其 `jsdom` setup 和优化器，但同样运行在共享的非隔离运行器上。 - - 每个 `pnpm test` 分片都从共享 Vitest 配置继承相同的 `threads` + `isolate: false` 默认值。 - - `scripts/run-vitest.mjs` 默认会为 Vitest 子 Node 进程添加 `--no-maglev`，以减少大型本地运行期间的 V8 编译抖动。若要与原生 V8 行为进行比较，请设置 `OPENCLAW_VITEST_ENABLE_MAGLEV=1`。 + - 共享 Vitest 配置固定为 `isolate: false`，并在根项目、e2e 和 live 配置中使用非隔离运行器。 + - 根 UI 通道保留其 `jsdom` setup 和优化器，但也运行在共享的非隔离运行器上。 + - 每个 `pnpm test` 分片都继承共享 Vitest 配置中的相同 `threads` + `isolate: false` 默认值。 + - `scripts/run-vitest.mjs` 默认会为 Vitest 子 Node 进程添加 `--no-maglev`，以减少大型本地运行期间的 V8 编译抖动。设置 `OPENCLAW_VITEST_ENABLE_MAGLEV=1` 可对比原生 V8 行为。 - `pnpm changed:lanes` 会显示某个差异会触发哪些架构通道。 - - pre-commit hook 仅负责格式化。它会重新暂存已格式化文件，不会运行 lint、typecheck 或测试。 - - 当你需要智能本地门禁时，请在交接或 push 前显式运行 `pnpm check:changed`。公共插件 SDK 和 plugin-contract 变更会包含一次扩展验证。 - - 当变更路径可以清晰映射到更小的测试套件时，`pnpm test:changed` 会通过作用域通道进行路由。 + - pre-commit hook 只负责格式化。它会重新暂存格式化后的文件，不会运行 lint、类型检查或测试。 + - 在交接或 push 前，当你需要智能本地门禁时，请显式运行 `pnpm check:changed`。公共 Plugin SDK 和插件契约变更会额外包含一次 extension 验证。 + - `pnpm test:changed` 会在变更路径能够清晰映射到较小测试套件时，通过定向通道运行。 - `pnpm test:max` 和 `pnpm test:changed:max` 保持相同的路由行为，只是使用更高的 worker 上限。 - - 本地 worker 自动扩缩容刻意保持保守，并会在主机负载平均值已经较高时回退，因此默认情况下，多个并发 Vitest 运行造成的破坏会更小。 - - 基础 Vitest 配置将项目/配置文件标记为 `forceRerunTriggers`，以便在测试接线发生变化时，changed 模式重跑仍然保持正确。 - - 配置会在支持的主机上保持启用 `OPENCLAW_VITEST_FS_MODULE_CACHE`；如果你希望为直接性能分析指定一个明确的缓存位置，请设置 `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`。 + - 本地 worker 自动扩缩容有意保持保守；当主机负载平均值已经较高时会回退，因此默认情况下多个并发 Vitest 运行造成的影响会更小。 + - 基础 Vitest 配置将项目 / 配置文件标记为 `forceRerunTriggers`，这样当测试接线发生变化时，changed 模式重跑仍然正确。 + - 该配置会在受支持主机上保持启用 `OPENCLAW_VITEST_FS_MODULE_CACHE`；如果你希望为直接性能分析指定一个明确的缓存位置，可设置 `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`。 - - `pnpm test:perf:imports` 会启用 Vitest 导入时长报告以及导入拆解输出。 - - `pnpm test:perf:imports:changed` 会将同样的性能分析视图限定到自 `origin/main` 以来发生变更的文件。 - - 分片耗时数据会写入 `.artifacts/vitest-shard-timings.json`。 - 整体配置运行会使用配置路径作为键；include-pattern CI 分片会附加分片名称，以便可以分别跟踪过滤后的分片。 - - 当某个热点测试的大部分时间仍耗费在启动导入上时，请将重依赖放在狭窄的本地 `*.runtime.ts` 接缝之后，并直接 mock 这个接缝，而不是仅为了通过 `vi.mock(...)` 传递它们，就深度导入运行时辅助函数。 - - `pnpm test:perf:changed:bench -- --ref ` 会针对该已提交差异，将已路由的 `test:changed` 与原生根项目路径进行比较，并输出墙钟时间以及 macOS 最大 RSS。 - - `pnpm test:perf:changed:bench -- --worktree` 会通过将变更文件列表路由到 `scripts/test-projects.mjs` 和根 Vitest 配置，对当前脏工作树进行基准测试。 - - `pnpm test:perf:profile:main` 会为 Vitest/Vite 启动和转换开销写入主线程 CPU profile。 - - `pnpm test:perf:profile:runner` 会在禁用文件级并行的情况下，为 unit 测试套件写入运行器 CPU + heap profile。 + - `pnpm test:perf:imports` 会启用 Vitest 导入耗时报告以及导入拆解输出。 + - `pnpm test:perf:imports:changed` 会将相同的性能分析视图限定到自 `origin/main` 以来发生变化的文件。 + - 分片计时数据会写入 `.artifacts/vitest-shard-timings.json`。 + 整个配置运行使用配置路径作为键；include-pattern CI 分片会追加分片名，以便单独跟踪被过滤的分片。 + - 当某个热点测试仍把大部分时间花在启动导入上时，应将重型依赖放在一个狭窄的本地 `*.runtime.ts` 接缝之后，并直接 mock 该接缝，而不是为了传给 `vi.mock(...)` 而深度导入运行时辅助函数。 + - `pnpm test:perf:changed:bench -- --ref ` 会针对该已提交差异，对比定向的 `test:changed` 与原生根项目路径，并打印墙钟时间和 macOS 最大 RSS。 + - `pnpm test:perf:changed:bench -- --worktree` 会将当前未提交工作树中的变更文件列表路由到 `scripts/test-projects.mjs` 和根 Vitest 配置，从而进行基准测试。 + - `pnpm test:perf:profile:main` 会为 Vitest / Vite 启动和 transform 开销写出主线程 CPU profile。 + - `pnpm test:perf:profile:runner` 会在禁用文件并行的情况下，为单元测试套件写出运行器 CPU + 堆 profile。 -### 稳定性（gateway） +### 稳定性（Gateway 网关） - 命令：`pnpm test:stability:gateway` -- 配置：`vitest.gateway.config.ts`，强制使用单个 worker +- 配置：`vitest.gateway.config.ts`，强制单 worker - 范围： - - 启动一个默认启用诊断功能的真实 loopback Gateway 网关 - - 通过诊断事件路径驱动合成的 gateway 消息、memory 和大负载 churn + - 默认启动一个启用了诊断功能的真实 loopback Gateway 网关 + - 通过诊断事件路径驱动合成的网关消息、内存和大负载抖动 - 通过 Gateway 网关 WS RPC 查询 `diagnostics.stability` - 覆盖诊断稳定性 bundle 持久化辅助函数 - - 断言记录器保持有界、合成 RSS 样本保持在压力预算之下，并且每个 session 的队列深度会回落到零 + - 断言记录器保持有界、合成 RSS 样本保持在压力预算之下，且每个会话的队列深度会回落到零 - 预期： - - 对 CI 安全且无需密钥 + - 可安全用于 CI，且无需密钥 - 这是用于稳定性回归跟进的窄通道，不可替代完整的 Gateway 网关测试套件 -### E2E（gateway 冒烟） +### E2E（Gateway 网关冒烟） - 命令：`pnpm test:e2e` - 配置：`vitest.e2e.config.ts` -- 文件：`src/**/*.e2e.test.ts`、`test/**/*.e2e.test.ts`，以及位于 `extensions/` 下的内置 plugin E2E 测试 +- 文件：`src/**/*.e2e.test.ts`、`test/**/*.e2e.test.ts`，以及 `extensions/` 下内置插件的 E2E 测试 - 运行时默认值： - - 使用 Vitest `threads` 且 `isolate: false`，与仓库其余部分保持一致。 + - 使用 Vitest `threads` 且设置 `isolate: false`，与仓库其他部分保持一致。 - 使用自适应 worker（CI：最多 2 个，本地：默认 1 个）。 - - 默认以 silent 模式运行，以减少控制台 I/O 开销。 -- 常用覆盖方式： - - `OPENCLAW_E2E_WORKERS=` 用于强制指定 worker 数量（上限为 16）。 - - `OPENCLAW_E2E_VERBOSE=1` 用于重新启用详细控制台输出。 + - 默认以静默模式运行，以减少控制台 I/O 开销。 +- 常用覆盖项： + - 使用 `OPENCLAW_E2E_WORKERS=` 强制指定 worker 数量（上限为 16）。 + - 使用 `OPENCLAW_E2E_VERBOSE=1` 重新启用详细控制台输出。 - 范围： - - 多实例 gateway 端到端行为 - - WebSocket/HTTP 表面、节点配对和更重的网络交互 + - 多实例网关端到端行为 + - WebSocket / HTTP 表面、节点配对以及更重的网络行为 - 预期： - - 会在 CI 中运行（当流水线启用时） + - 会在 CI 中运行（当在流水线中启用时） - 不需要真实密钥 - - 比 unit 测试有更多活动部件（可能更慢） + - 比单元测试有更多可变因素（可能更慢） ### E2E：OpenShell 后端冒烟 - 命令：`pnpm test:e2e:openshell` - 文件：`extensions/openshell/src/backend.e2e.test.ts` - 范围： - - 通过 Docker 在主机上启动一个隔离的 OpenShell gateway - - 从临时本地 Dockerfile 创建一个沙箱 - - 通过真实的 `sandbox ssh-config` + SSH exec，执行 OpenClaw 的 OpenShell 后端 - - 通过沙箱 fs bridge 验证远端规范文件系统行为 + - 通过 Docker 在主机上启动一个隔离的 OpenShell 网关 + - 从一个临时本地 Dockerfile 创建一个沙箱 + - 通过真实的 `sandbox ssh-config` + SSH exec 运行 OpenClaw 的 OpenShell 后端 + - 通过沙箱文件系统桥验证远端规范文件系统行为 - 预期： - - 仅按需启用；不属于默认 `pnpm test:e2e` 运行的一部分 + - 仅按需启用；不属于默认的 `pnpm test:e2e` 运行 - 需要本地 `openshell` CLI 和可用的 Docker daemon - - 使用隔离的 `HOME` / `XDG_CONFIG_HOME`，然后销毁测试 gateway 和沙箱 -- 常用覆盖方式： - - `OPENCLAW_E2E_OPENSHELL=1`：在手动运行更广泛的 e2e 测试套件时启用此测试 - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`：指向非默认 CLI 二进制或包装脚本 + - 使用隔离的 `HOME` / `XDG_CONFIG_HOME`，之后会销毁测试网关和沙箱 +- 常用覆盖项： + - 在手动运行更宽泛的 e2e 测试套件时，设置 `OPENCLAW_E2E_OPENSHELL=1` 可启用该测试 + - 设置 `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` 可指向非默认的 CLI 二进制或包装脚本 ### live（真实提供商 + 真实模型） - 命令：`pnpm test:live` - 配置：`vitest.live.config.ts` -- 文件：`src/**/*.live.test.ts`、`test/**/*.live.test.ts`，以及位于 `extensions/` 下的内置 plugin live 测试 +- 文件：`src/**/*.live.test.ts`、`test/**/*.live.test.ts`，以及 `extensions/` 下内置插件的 live 测试 - 默认：由 `pnpm test:live` **启用**（设置 `OPENCLAW_LIVE_TEST=1`） - 范围： - - “这个提供商/模型**今天**是否真的能在真实凭证下工作？” + - “这个提供商 / 模型 _今天_ 是否真的能在真实凭证下工作？” - 捕获提供商格式变化、工具调用怪癖、认证问题和速率限制行为 - 预期： - - 按设计并不具备 CI 稳定性（真实网络、真实提供商策略、配额、故障） - - 会花钱 / 占用速率限制 - - 优先运行收窄后的子集，而不是“全部都跑” + - 按设计不具备 CI 稳定性（真实网络、真实提供商策略、配额、故障） + - 会花钱 / 消耗速率限制 + - 优先运行收窄后的子集，而不是“全部” - live 运行会加载 `~/.profile` 以获取缺失的 API 密钥。 -- 默认情况下，live 运行仍会隔离 `HOME`，并将配置/认证材料复制到临时测试 home 中，这样 unit fixture 就不会修改你真实的 `~/.openclaw`。 -- 只有在你明确需要 live 测试使用真实 home 目录时，才设置 `OPENCLAW_LIVE_USE_REAL_HOME=1`。 -- `pnpm test:live` 现在默认使用更安静的模式：它会保留 `[live] ...` 进度输出，但会隐藏额外的 `~/.profile` 提示，并静默 gateway 启动日志/Bonjour 噪声。如果你想恢复完整启动日志，请设置 `OPENCLAW_LIVE_TEST_QUIET=0`。 -- API 密钥轮换（按提供商区分）：设置逗号/分号格式的 `*_API_KEYS` 或 `*_API_KEY_1`、`*_API_KEY_2`（例如 `OPENAI_API_KEYS`、`ANTHROPIC_API_KEYS`、`GEMINI_API_KEYS`），或者通过 `OPENCLAW_LIVE_*_KEY` 进行每次 live 的覆盖；测试会在速率限制响应时重试。 -- 进度/心跳输出： - - live 测试套件现在会将进度行输出到 stderr，因此即使 Vitest 控制台捕获较安静，长时间的提供商调用也会明显显示为活动中。 - - `vitest.live.config.ts` 会禁用 Vitest 控制台拦截，因此在 live 运行期间，提供商/gateway 进度行会立即流式输出。 - - 使用 `OPENCLAW_LIVE_HEARTBEAT_MS` 调整 direct-model 心跳。 - - 使用 `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` 调整 gateway/probe 心跳。 +- 默认情况下，live 运行仍会隔离 `HOME`，并将配置 / 认证材料复制到一个临时测试 home 中，这样单元测试夹具就不会修改你真实的 `~/.openclaw`。 +- 仅当你明确需要 live 测试使用真实 home 目录时，才设置 `OPENCLAW_LIVE_USE_REAL_HOME=1`。 +- `pnpm test:live` 现在默认使用更安静的模式：会保留 `[live] ...` 进度输出，但会隐藏额外的 `~/.profile` 提示，并静音 Gateway 网关启动日志 / Bonjour 噪音。如果你想恢复完整启动日志，可设置 `OPENCLAW_LIVE_TEST_QUIET=0`。 +- API 密钥轮换（按提供商区分）：设置逗号 / 分号格式的 `*_API_KEYS` 或 `*_API_KEY_1`、`*_API_KEY_2`（例如 `OPENAI_API_KEYS`、`ANTHROPIC_API_KEYS`、`GEMINI_API_KEYS`），或者通过 `OPENCLAW_LIVE_*_KEY` 做每次 live 运行覆盖；测试会在遇到速率限制响应时重试。 +- 进度 / 心跳输出： + - live 测试套件现在会将进度行输出到 stderr，因此即使 Vitest 控制台捕获处于安静模式，长时间的提供商调用也仍能显示为活跃状态。 + - `vitest.live.config.ts` 会禁用 Vitest 控制台拦截，因此提供商 / 网关进度行会在 live 运行期间立即流式输出。 + - 使用 `OPENCLAW_LIVE_HEARTBEAT_MS` 调整直接模型心跳。 + - 使用 `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` 调整 Gateway 网关 / 探测心跳。 ## 我应该运行哪个测试套件？ -使用这张决策表： +使用这个决策表： -- 编辑逻辑/测试：运行 `pnpm test`（如果你改动很多，再运行 `pnpm test:coverage`） -- 修改 gateway 网络 / WS 协议 / 配对：额外运行 `pnpm test:e2e` -- 调试“我的 bot 挂了”/提供商特定故障/工具调用：运行收窄后的 `pnpm test:live` +- 编辑逻辑 / 测试：运行 `pnpm test`（如果你改动很多，再加上 `pnpm test:coverage`） +- 触及 Gateway 网关网络 / WS 协议 / 配对：额外运行 `pnpm test:e2e` +- 调试“我的 bot 挂了” / 提供商特定故障 / 工具调用：运行收窄后的 `pnpm test:live` -## live（会触网的）测试 +## live（触网）测试 -关于 live 模型矩阵、CLI 后端冒烟测试、ACP 冒烟测试、Codex app-server harness，以及所有媒体提供商 live 测试（Deepgram、BytePlus（国际版）、ComfyUI、image、music、video、media harness）——再加上 live 运行的凭证处理——请参见[测试 — live 测试套件](/zh-CN/help/testing-live)。 +关于 live 模型矩阵、CLI 后端冒烟测试、ACP 冒烟测试、Codex app-server harness，以及所有媒体提供商 live 测试（Deepgram、BytePlus（国际版）、ComfyUI、图像、音乐、视频、媒体 harness）——以及 live 运行的凭证处理——请参阅 [Testing — live suites](/zh-CN/help/testing-live)。 -## Docker 运行器（可选的“可在 Linux 中运行”检查） +## Docker 运行器（可选的“在 Linux 中可用”检查） 这些 Docker 运行器分为两类： -- live 模型运行器：`test:docker:live-models` 和 `test:docker:live-gateway` 只会在仓库 Docker 镜像中运行它们对应的 profile-key live 文件（`src/agents/models.profiles.live.test.ts` 和 `src/gateway/gateway-models.profiles.live.test.ts`），并挂载你的本地配置目录和工作区（如果已挂载，还会加载 `~/.profile`）。对应的本地入口点是 `test:live:models-profiles` 和 `test:live:gateway-profiles`。 -- Docker live 运行器默认采用更小的冒烟上限，以便完整的 Docker 扫描仍然可行： +- live 模型运行器：`test:docker:live-models` 和 `test:docker:live-gateway` 只会在仓库 Docker 镜像中运行其对应的 profile-key live 文件（`src/agents/models.profiles.live.test.ts` 和 `src/gateway/gateway-models.profiles.live.test.ts`），同时挂载你的本地配置目录和工作区（如果已挂载，也会加载 `~/.profile`）。对应的本地入口点是 `test:live:models-profiles` 和 `test:live:gateway-profiles`。 +- Docker live 运行器默认采用较小的冒烟上限，以便完整的 Docker 扫描仍然可行： `test:docker:live-models` 默认使用 `OPENCLAW_LIVE_MAX_MODELS=12`，而 `test:docker:live-gateway` 默认使用 `OPENCLAW_LIVE_GATEWAY_SMOKE=1`、 `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`、 `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` 和 - `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`。当你明确想运行更大规模的穷尽扫描时，可覆盖这些环境变量。 -- `test:docker:all` 会先通过 `test:docker:live-build` 构建一次 live Docker 镜像，将 OpenClaw 一次性打包为 npm tarball，然后构建/复用两个 `scripts/e2e/Dockerfile` 镜像。裸镜像只是用于 install/update/plugin-dependency 通道的 Node/Git 运行器；这些通道会挂载预构建的 tarball。功能镜像则会把同一个 tarball 安装到 `/app` 中，用于基于已构建应用的功能通道。这个聚合运行器使用加权本地调度器：`OPENCLAW_DOCKER_ALL_PARALLELISM` 控制进程槽位数量，而资源上限会阻止重型 live、npm-install 和多服务通道同时启动过多。默认值为 10 个槽位、`OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`、`OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` 和 `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`；只有当 Docker 主机有更多余量时，才调整 `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` 或 `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`。该运行器默认会执行 Docker 预检查，移除陈旧的 OpenClaw E2E 容器，每 30 秒打印一次状态，将成功通道的耗时存储在 `.artifacts/docker-tests/lane-timings.json` 中，并在后续运行时利用这些耗时优先启动更长的通道。使用 `OPENCLAW_DOCKER_ALL_DRY_RUN=1` 可在不构建、不运行 Docker 的情况下打印加权通道清单。 + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`。当你明确想要进行更大范围的穷举扫描时，可覆盖这些环境变量。 +- `test:docker:all` 会先通过 `test:docker:live-build` 构建一次 live Docker 镜像，再通过 `scripts/package-openclaw-for-docker.mjs` 将 OpenClaw 打包一次为 npm tarball，然后构建 / 复用两个 `scripts/e2e/Dockerfile` 镜像。裸镜像仅作为 Node / Git 运行器，用于 install / update / plugin-dependency 通道；这些通道会挂载预构建的 tarball。功能镜像则会把同一个 tarball 安装到 `/app` 中，用于已构建应用的功能通道。Docker 通道定义位于 `scripts/lib/docker-e2e-scenarios.mjs`；规划逻辑位于 `scripts/lib/docker-e2e-plan.mjs`；`scripts/test-docker-all.mjs` 负责执行选定计划。这个聚合运行器使用加权本地调度器：`OPENCLAW_DOCKER_ALL_PARALLELISM` 控制进程槽位，而资源上限会防止重型 live、npm 安装和多服务通道同时全部启动。默认值是 10 个槽位、`OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`、`OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` 和 `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`；仅当 Docker 主机拥有更多余量时，才调整 `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` 或 `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`。运行器默认会执行 Docker 预检，移除过期的 OpenClaw E2E 容器，每 30 秒打印一次状态，将成功通道的计时数据存入 `.artifacts/docker-tests/lane-timings.json`，并在后续运行中利用这些计时数据优先启动更长的通道。使用 `OPENCLAW_DOCKER_ALL_DRY_RUN=1` 可仅打印加权通道清单，而不构建或运行 Docker；或者使用 `node scripts/test-docker-all.mjs --plan-json` 打印所选通道、package / 镜像需求以及凭证的 CI 计划。 - 容器冒烟运行器：`test:docker:openwebui`、`test:docker:onboard`、`test:docker:npm-onboard-channel-agent`、`test:docker:update-channel-switch`、`test:docker:session-runtime-context`、`test:docker:agents-delete-shared-workspace`、`test:docker:gateway-network`、`test:docker:browser-cdp-snapshot`、`test:docker:mcp-channels`、`test:docker:pi-bundle-mcp-tools`、`test:docker:cron-mcp-cleanup`、`test:docker:plugins`、`test:docker:plugin-update` 和 `test:docker:config-reload` 会启动一个或多个真实容器，并验证更高层级的集成路径。 -live 模型 Docker 运行器还只会绑定挂载所需的 CLI 认证主目录（如果运行未收窄，则会挂载所有受支持的主目录），然后在运行前将它们复制到容器 home 中，这样外部 CLI OAuth 就可以刷新令牌，而不会修改主机认证存储： +live 模型 Docker 运行器还会仅绑定挂载所需的 CLI 认证 home 目录（如果运行未收窄，则挂载所有受支持的目录），然后在运行前将它们复制到容器 home 中，这样外部 CLI OAuth 就可以刷新令牌，而不会修改宿主机的认证存储： - 直接模型：`pnpm test:docker:live-models`（脚本：`scripts/test-live-models-docker.sh`） -- ACP 绑定冒烟测试：`pnpm test:docker:live-acp-bind`（脚本：`scripts/test-live-acp-bind-docker.sh`；默认覆盖 Claude、Codex 和 Gemini，严格的 Droid/OpenCode 覆盖可通过 `pnpm test:docker:live-acp-bind:droid` 和 `pnpm test:docker:live-acp-bind:opencode` 运行） +- ACP 绑定冒烟测试：`pnpm test:docker:live-acp-bind`（脚本：`scripts/test-live-acp-bind-docker.sh`；默认覆盖 Claude、Codex 和 Gemini，对 Droid / OpenCode 的严格覆盖可使用 `pnpm test:docker:live-acp-bind:droid` 和 `pnpm test:docker:live-acp-bind:opencode`） - CLI 后端冒烟测试：`pnpm test:docker:live-cli-backend`（脚本：`scripts/test-live-cli-backend-docker.sh`） - Codex app-server harness 冒烟测试：`pnpm test:docker:live-codex-harness`（脚本：`scripts/test-live-codex-harness-docker.sh`） - Gateway 网关 + dev 智能体：`pnpm test:docker:live-gateway`（脚本：`scripts/test-live-gateway-models-docker.sh`） - Open WebUI live 冒烟测试：`pnpm test:docker:openwebui`（脚本：`scripts/e2e/openwebui-docker.sh`） -- onboarding 向导（TTY、完整脚手架）：`pnpm test:docker:onboard`（脚本：`scripts/e2e/onboard-docker.sh`） -- Npm tarball onboarding/渠道/智能体冒烟测试：`pnpm test:docker:npm-onboard-channel-agent` 会在 Docker 中全局安装打包后的 OpenClaw tarball，通过 env-ref onboarding 配置 OpenAI，并默认配置 Telegram，验证 doctor 会修复已激活 plugin 的运行时依赖，并运行一次 mock OpenAI 智能体轮次。可通过 `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz` 复用预构建 tarball，通过 `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` 跳过主机构建，或通过 `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` 切换渠道。 -- 更新渠道切换冒烟测试：`pnpm test:docker:update-channel-switch` 会在 Docker 中全局安装打包后的 OpenClaw tarball，从 package `stable` 切换到 git `dev`，验证持久化渠道和 plugin 在更新后仍可工作，然后切回 package `stable` 并检查更新状态。 -- session 运行时上下文冒烟测试：`pnpm test:docker:session-runtime-context` 会验证隐藏运行时上下文 transcript 的持久化，以及 doctor 对受影响的重复 prompt-rewrite 分支的修复。 -- Bun 全局安装冒烟测试：`bash scripts/e2e/bun-global-install-smoke.sh` 会打包当前工作树，在隔离 home 中使用 `bun install -g` 安装，并验证 `openclaw infer image providers --json` 返回的是内置 image 提供商，而不是卡住。可通过 `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz` 复用预构建 tarball，通过 `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` 跳过主机构建，或通过 `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local` 从已构建 Docker 镜像复制 `dist/`。 -- 安装 Docker 冒烟测试：`bash scripts/test-install-sh-docker.sh` 会在其 root、update 和 direct-npm 容器之间共享一个 npm 缓存。更新冒烟测试默认使用 npm `latest` 作为稳定基线，然后升级到候选 tarball。非 root 安装器检查会保持隔离的 npm 缓存，以防 root 拥有的缓存条目掩盖用户本地安装行为。设置 `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache` 可在本地重跑之间复用 root/update/direct-npm 缓存。 -- Install Smoke CI 会通过 `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1` 跳过重复的 direct-npm 全局更新；当需要覆盖直接 `npm install -g` 时，请在本地不带该环境变量运行脚本。 -- Agents 删除共享工作区 CLI 冒烟测试：`pnpm test:docker:agents-delete-shared-workspace`（脚本：`scripts/e2e/agents-delete-shared-workspace-docker.sh`）默认构建根 Dockerfile 镜像，在隔离容器 home 中植入两个智能体和一个工作区，运行 `agents delete --json`，并验证 JSON 有效以及工作区保留行为。可通过 `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1` 复用 install-smoke 镜像。 +- 新手引导向导（TTY，完整脚手架）：`pnpm test:docker:onboard`（脚本：`scripts/e2e/onboard-docker.sh`） +- npm tarball 新手引导 / 渠道 / 智能体冒烟测试：`pnpm test:docker:npm-onboard-channel-agent` 会在 Docker 中全局安装已打包的 OpenClaw tarball，通过 env-ref 新手引导配置 OpenAI，并默认配置 Telegram，验证 doctor 会修复已激活插件的运行时依赖，并运行一次 mocked OpenAI 智能体轮次。可使用 `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz` 复用预构建 tarball，使用 `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` 跳过宿主机重建，或使用 `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` 切换渠道。 +- 更新渠道切换冒烟测试：`pnpm test:docker:update-channel-switch` 会在 Docker 中全局安装已打包的 OpenClaw tarball，将渠道从 package `stable` 切换到 git `dev`，验证持久化的渠道和插件在更新后仍可用，然后再切回 package `stable` 并检查更新状态。 +- 会话运行时上下文冒烟测试：`pnpm test:docker:session-runtime-context` 会验证隐藏运行时上下文 transcript 的持久化，以及 doctor 对受影响的重复 prompt-rewrite 分支的修复。 +- Bun 全局安装冒烟测试：`bash scripts/e2e/bun-global-install-smoke.sh` 会打包当前工作树，在隔离的 home 中使用 `bun install -g` 安装，并验证 `openclaw infer image providers --json` 返回的是内置图像提供商，而不是卡住。可使用 `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz` 复用预构建 tarball，使用 `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` 跳过宿主机构建，或使用 `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local` 从已构建的 Docker 镜像复制 `dist/`。 +- Installer Docker 冒烟测试：`bash scripts/test-install-sh-docker.sh` 会在其 root、update 和 direct-npm 容器之间共享同一个 npm 缓存。更新冒烟测试默认使用 npm `latest` 作为稳定基线，然后升级到候选 tarball。非 root 安装器检查会保持隔离的 npm 缓存，以防 root 拥有的缓存条目掩盖用户本地安装行为。设置 `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache` 可在本地重跑之间复用 root / update / direct-npm 缓存。 +- Install Smoke CI 会通过 `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1` 跳过重复的 direct-npm 全局更新；当你需要直接 `npm install -g` 覆盖时，请在本地运行脚本且不要设置该环境变量。 +- 智能体删除共享工作区 CLI 冒烟测试：`pnpm test:docker:agents-delete-shared-workspace`（脚本：`scripts/e2e/agents-delete-shared-workspace-docker.sh`）默认会构建根 Dockerfile 镜像，在隔离的容器 home 中植入两个共享同一工作区的智能体，运行 `agents delete --json`，并验证 JSON 合法性及工作区保留行为。可通过 `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1` 复用 install-smoke 镜像。 - Gateway 网关网络（两个容器，WS 认证 + 健康检查）：`pnpm test:docker:gateway-network`（脚本：`scripts/e2e/gateway-network-docker.sh`） -- Browser CDP 快照冒烟测试：`pnpm test:docker:browser-cdp-snapshot`（脚本：`scripts/e2e/browser-cdp-snapshot-docker.sh`）会构建源码 E2E 镜像加一个 Chromium 层，以原始 CDP 启动 Chromium，运行 `browser doctor --deep`，并验证 CDP 角色快照覆盖 link URL、经 cursor 提升的可点击元素、iframe 引用和 frame 元数据。 -- OpenAI Responses `web_search` 最小推理回归测试：`pnpm test:docker:openai-web-search-minimal`（脚本：`scripts/e2e/openai-web-search-minimal-docker.sh`）会通过 Gateway 网关运行一个 mock OpenAI 服务器，验证 `web_search` 会将 `reasoning.effort` 从 `minimal` 提升到 `low`，然后强制提供商 schema 拒绝，并检查原始细节是否出现在 Gateway 网关日志中。 -- MCP 渠道桥接（植入的 Gateway 网关 + stdio bridge + 原始 Claude notification-frame 冒烟测试）：`pnpm test:docker:mcp-channels`（脚本：`scripts/e2e/mcp-channels-docker.sh`） -- Pi bundle MCP 工具（真实 stdio MCP 服务器 + 嵌入式 Pi profile allow/deny 冒烟测试）：`pnpm test:docker:pi-bundle-mcp-tools`（脚本：`scripts/e2e/pi-bundle-mcp-tools-docker.sh`） -- Cron/subagent MCP 清理（真实 Gateway 网关 + stdio MCP 子进程在隔离 cron 和一次性 subagent 运行后的清理）：`pnpm test:docker:cron-mcp-cleanup`（脚本：`scripts/e2e/cron-mcp-cleanup-docker.sh`） -- Plugins（安装冒烟、ClawHub 安装/卸载、市场更新，以及 Claude bundle 启用/检查）：`pnpm test:docker:plugins`（脚本：`scripts/e2e/plugins-docker.sh`） +- 浏览器 CDP 快照冒烟测试：`pnpm test:docker:browser-cdp-snapshot`（脚本：`scripts/e2e/browser-cdp-snapshot-docker.sh`）会构建源码 E2E 镜像和一个 Chromium 层，以原始 CDP 启动 Chromium，运行 `browser doctor --deep`，并验证 CDP 角色快照覆盖链接 URL、光标提升的可点击元素、iframe 引用和 frame 元数据。 +- OpenAI Responses `web_search` 最小推理回归测试：`pnpm test:docker:openai-web-search-minimal`（脚本：`scripts/e2e/openai-web-search-minimal-docker.sh`）会通过 Gateway 网关运行一个 mocked OpenAI 服务器，验证 `web_search` 会将 `reasoning.effort` 从 `minimal` 提升为 `low`，然后强制提供商 schema 拒绝，并检查原始细节出现在 Gateway 网关日志中。 +- MCP 渠道桥接（已植入的 Gateway 网关 + stdio bridge + 原始 Claude notification-frame 冒烟测试）：`pnpm test:docker:mcp-channels`（脚本：`scripts/e2e/mcp-channels-docker.sh`） +- Pi 内置 MCP 工具（真实 stdio MCP 服务器 + 嵌入式 Pi 配置文件 allow / deny 冒烟测试）：`pnpm test:docker:pi-bundle-mcp-tools`（脚本：`scripts/e2e/pi-bundle-mcp-tools-docker.sh`） +- Cron / subagent MCP 清理（真实 Gateway 网关 + 在隔离的 cron 和一次性 subagent 运行后拆除 stdio MCP 子进程）：`pnpm test:docker:cron-mcp-cleanup`（脚本：`scripts/e2e/cron-mcp-cleanup-docker.sh`） +- 插件（安装冒烟测试、ClawHub 安装 / 卸载、marketplace 更新，以及 Claude-bundle 启用 / 检查）：`pnpm test:docker:plugins`（脚本：`scripts/e2e/plugins-docker.sh`） 设置 `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` 可跳过 live ClawHub 区块，或通过 `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` 和 `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID` 覆盖默认 package。 -- Plugin update unchanged 冒烟测试：`pnpm test:docker:plugin-update`（脚本：`scripts/e2e/plugin-update-unchanged-docker.sh`） -- Config reload 元数据冒烟测试：`pnpm test:docker:config-reload`（脚本：`scripts/e2e/config-reload-source-docker.sh`） -- 内置 plugin 运行时依赖：`pnpm test:docker:bundled-channel-deps` 默认会构建一个小型 Docker 运行器镜像，在主机上构建并打包一次 OpenClaw，然后将该 tarball 挂载到每个 Linux 安装场景中。可通过 `OPENCLAW_SKIP_DOCKER_BUILD=1` 复用镜像，在完成一次新的本地构建后通过 `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` 跳过主机重建，或通过 `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz` 指向现有 tarball。完整 Docker 聚合运行器会先将这个 tarball 预打包一次，然后把内置渠道检查分片为独立通道，包括 Telegram、Discord、Slack、Feishu、memory-lancedb 和 ACPX 的独立更新通道。直接运行内置通道时，使用 `OPENCLAW_BUNDLED_CHANNELS=telegram,slack` 可收窄渠道矩阵，或使用 `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx` 收窄更新场景。该通道还会验证 `channels..enabled=false` 和 `plugins.entries..enabled=false` 会抑制 doctor/运行时依赖修复。 -- 在迭代过程中，如需收窄内置 plugin 运行时依赖检查范围，可禁用无关场景，例如： +- 插件更新未变化冒烟测试：`pnpm test:docker:plugin-update`（脚本：`scripts/e2e/plugin-update-unchanged-docker.sh`） +- 配置热重载元数据冒烟测试：`pnpm test:docker:config-reload`（脚本：`scripts/e2e/config-reload-source-docker.sh`） +- 内置插件运行时依赖：`pnpm test:docker:bundled-channel-deps` 默认会构建一个小型 Docker 运行器镜像，在宿主机上构建并打包一次 OpenClaw，然后将该 tarball 挂载到每个 Linux 安装场景中。可通过 `OPENCLAW_SKIP_DOCKER_BUILD=1` 复用该镜像，在完成一次新的本地构建后通过 `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` 跳过宿主机重建，或通过 `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz` 指向一个现有 tarball。完整 Docker 聚合运行器会预先打包这个 tarball 一次，然后将内置渠道检查切分为独立通道，其中包括 Telegram、Discord、Slack、Feishu、memory-lancedb 和 ACPX 的独立更新通道。直接运行内置通道时，可使用 `OPENCLAW_BUNDLED_CHANNELS=telegram,slack` 收窄渠道矩阵，或使用 `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx` 收窄更新场景。该通道还会验证 `channels..enabled=false` 和 `plugins.entries..enabled=false` 会抑制 doctor / 运行时依赖修复。 +- 在迭代时收窄内置插件运行时依赖，可禁用无关场景，例如： `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`。 -手动预构建并复用共享功能镜像的方法如下： +如需手动预构建并复用共享功能镜像： ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -设置后，诸如 `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE` 这样的测试套件专用镜像覆盖仍然优先生效。当 `OPENCLAW_SKIP_DOCKER_BUILD=1` 指向远程共享镜像时，如果本地尚不存在，脚本会先拉取该镜像。QR 和安装器 Docker 测试仍保留各自的 Dockerfile，因为它们验证的是 package/安装行为，而不是共享的已构建应用运行时。 +设置后，诸如 `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE` 之类的套件特定镜像覆盖项仍然优先生效。当 `OPENCLAW_SKIP_DOCKER_BUILD=1` 指向远程共享镜像时，如果本地尚不存在，脚本会先拉取该镜像。QR 和 installer Docker 测试仍保留各自的 Dockerfile，因为它们验证的是 package / install 行为，而不是共享的已构建应用运行时。 -live 模型 Docker 运行器还会以只读方式绑定挂载当前检出内容，并将其暂存到容器内的临时工作目录中。这样既能保持运行时镜像精简，又能让 Vitest 针对你精确的本地源码/配置运行。暂存步骤会跳过大型本地专用缓存和应用构建输出，例如 `.pnpm-store`、`.worktrees`、`__openclaw_vitest__`，以及应用本地的 `.build` 或 Gradle 输出目录，这样 Docker live 运行就不会花上几分钟复制机器特定的产物。 -它们还会设置 `OPENCLAW_SKIP_CHANNELS=1`，这样 gateway live 探测就不会在容器内启动真实的 Telegram/Discord 等渠道工作进程。 -`test:docker:live-models` 仍然运行 `pnpm test:live`，因此当你需要从该 Docker 通道中收窄或排除 gateway live 覆盖时，也要一并传入 `OPENCLAW_LIVE_GATEWAY_*`。 -`test:docker:openwebui` 是一个更高层级的兼容性冒烟测试：它会启动一个启用了 OpenAI 兼容 HTTP 端点的 OpenClaw gateway 容器，针对该 gateway 启动一个固定版本的 Open WebUI 容器，通过 Open WebUI 登录，验证 `/api/models` 暴露了 `openclaw/default`，然后通过 Open WebUI 的 `/api/chat/completions` 代理发送一个真实的聊天请求。 -首次运行可能会明显更慢，因为 Docker 可能需要拉取 Open WebUI 镜像，而 Open WebUI 也可能需要完成自己的冷启动设置。 -这个通道需要一个可用的 live 模型密钥，而 `OPENCLAW_PROFILE_FILE`（默认是 `~/.profile`）是在 Docker 化运行中提供该密钥的主要方式。 +live 模型 Docker 运行器还会以只读方式绑定挂载当前 checkout，并将其暂存到容器内的临时工作目录中。这样可以保持运行时镜像精简，同时仍然让 Vitest 针对你本地精确的源码 / 配置运行。 +暂存步骤会跳过大型的本地专用缓存和应用构建输出，例如 +`.pnpm-store`、`.worktrees`、`__openclaw_vitest__`，以及应用本地的 `.build` 或 Gradle 输出目录，这样 Docker live 运行就不会花上数分钟复制机器特定的工件。 +它们还会设置 `OPENCLAW_SKIP_CHANNELS=1`，这样 Gateway 网关 live 探测就不会在容器内启动真实的 Telegram / Discord / 等渠道工作进程。 +`test:docker:live-models` 仍然运行 `pnpm test:live`，因此当你需要从该 Docker 通道中收窄或排除 Gateway 网关 live 覆盖时，也要一并传递 `OPENCLAW_LIVE_GATEWAY_*`。 +`test:docker:openwebui` 是更高层级的兼容性冒烟测试：它会启动一个启用了 OpenAI 兼容 HTTP 端点的 OpenClaw 网关容器，针对该网关启动一个固定版本的 Open WebUI 容器，通过 Open WebUI 登录，验证 `/api/models` 暴露 `openclaw/default`，然后通过 Open WebUI 的 `/api/chat/completions` 代理发送一个真实聊天请求。 +首次运行可能会明显更慢，因为 Docker 可能需要拉取 Open WebUI 镜像，而且 Open WebUI 可能需要完成自身的冷启动设置。 +该通道要求提供可用的 live 模型密钥，而 `OPENCLAW_PROFILE_FILE`（默认为 `~/.profile`）是在 Docker 化运行中提供该密钥的主要方式。 成功运行会打印一个小型 JSON 负载，例如 `{ "ok": true, "model": "openclaw/default", ... }`。 -`test:docker:mcp-channels` 是刻意设计为确定性的，不需要真实的 Telegram、Discord 或 iMessage 账号。它会启动一个已植入的 Gateway 网关容器，再启动第二个容器来生成 `openclaw mcp serve`，然后通过真实的 stdio MCP bridge 验证路由对话发现、transcript 读取、附件元数据、live 事件队列行为、出站发送路由，以及 Claude 风格的渠道 + 权限通知。通知检查会直接检查原始 stdio MCP frame，因此这个冒烟测试验证的是 bridge 实际发出的内容，而不仅仅是某个特定客户端 SDK 恰好暴露出的内容。 -`test:docker:pi-bundle-mcp-tools` 是确定性的，不需要 live 模型密钥。它会构建仓库 Docker 镜像，在容器内启动一个真实的 stdio MCP probe 服务器，通过嵌入式 Pi bundle MCP 运行时将该服务器实例化，执行该工具，然后验证 `coding` 和 `messaging` 会保留 `bundle-mcp` 工具，而 `minimal` 和 `tools.deny: ["bundle-mcp"]` 会将其过滤掉。 -`test:docker:cron-mcp-cleanup` 是确定性的，不需要 live 模型密钥。它会启动一个带有真实 stdio MCP probe 服务器的已植入 Gateway 网关，运行一个隔离的 cron 轮次和一个 `/subagents spawn` 一次性子智能体轮次，然后验证 MCP 子进程会在每次运行后退出。 +`test:docker:mcp-channels` 被刻意设计为确定性的，不需要真实的 Telegram、Discord 或 iMessage 账户。它会启动一个已植入的 Gateway 网关容器，启动第二个容器来运行 `openclaw mcp serve`，然后验证路由后的会话发现、transcript 读取、附件元数据、live 事件队列行为、出站发送路由，以及通过真实 stdio MCP bridge 传输的 Claude 风格渠道 + 权限通知。通知检查会直接检查原始 stdio MCP frame，因此该冒烟测试验证的是 bridge 实际发出的内容，而不只是某个特定客户端 SDK 恰好暴露出来的内容。 +`test:docker:pi-bundle-mcp-tools` 是确定性的，不需要 live 模型密钥。它会构建仓库 Docker 镜像，在容器内启动一个真实的 stdio MCP probe 服务器，通过嵌入式 Pi 内置 MCP 运行时将该服务器实体化，执行该工具，然后验证 `coding` 和 `messaging` 会保留 `bundle-mcp` 工具，而 `minimal` 和 `tools.deny: ["bundle-mcp"]` 会将其过滤掉。 +`test:docker:cron-mcp-cleanup` 是确定性的，不需要 live 模型密钥。它会启动一个已植入的 Gateway 网关和一个真实的 stdio MCP probe 服务器，运行一个隔离的 cron 轮次和一个 `/subagents spawn` 一次性子智能体轮次，然后验证 MCP 子进程会在每次运行后退出。 手动 ACP 自然语言线程冒烟测试（非 CI）： - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- 保留这个脚本用于回归/调试工作流。它未来可能还会再次用于 ACP 线程路由验证，所以不要删除它。 +- 请保留此脚本用于回归 / 调试工作流。后续在验证 ACP 线程路由时可能还需要它，因此不要删除。 -有用的环境变量： +常用环境变量： -- `OPENCLAW_CONFIG_DIR=...`（默认：`~/.openclaw`）会挂载到 `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...`（默认：`~/.openclaw/workspace`）会挂载到 `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...`（默认：`~/.profile`）会挂载到 `/home/node/.profile`，并在运行测试前加载 -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` 用于只验证从 `OPENCLAW_PROFILE_FILE` 加载的环境变量，使用临时配置/工作区目录，且不挂载外部 CLI 认证 -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...`（默认：`~/.cache/openclaw/docker-cli-tools`）会挂载到 `/home/node/.npm-global`，用于在 Docker 内缓存 CLI 安装 -- `$HOME` 下的外部 CLI 认证目录/文件会以只读方式挂载到 `/host-auth...` 下，然后在测试开始前复制到 `/home/node/...` +- `OPENCLAW_CONFIG_DIR=...`（默认：`~/.openclaw`）挂载到 `/home/node/.openclaw` +- `OPENCLAW_WORKSPACE_DIR=...`（默认：`~/.openclaw/workspace`）挂载到 `/home/node/.openclaw/workspace` +- `OPENCLAW_PROFILE_FILE=...`（默认：`~/.profile`）挂载到 `/home/node/.profile`，并在运行测试前加载 +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` 用于仅验证来自 `OPENCLAW_PROFILE_FILE` 的环境变量，使用临时配置 / 工作区目录，且不挂载外部 CLI 认证目录 +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...`（默认：`~/.cache/openclaw/docker-cli-tools`）挂载到 `/home/node/.npm-global`，用于 Docker 内缓存的 CLI 安装 +- `$HOME` 下的外部 CLI 认证目录 / 文件会以只读方式挂载到 `/host-auth...` 下，然后在测试开始前复制到 `/home/node/...` - 默认目录：`.minimax` - 默认文件：`~/.codex/auth.json`、`~/.codex/config.toml`、`.claude.json`、`~/.claude/.credentials.json`、`~/.claude/settings.json`、`~/.claude/settings.local.json` - - 收窄后的提供商运行只会挂载从 `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` 推断出的所需目录/文件 + - 收窄后的提供商运行只会挂载从 `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` 推断出的所需目录 / 文件 - 可通过 `OPENCLAW_DOCKER_AUTH_DIRS=all`、`OPENCLAW_DOCKER_AUTH_DIRS=none`，或类似 `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` 的逗号列表手动覆盖 - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` 用于收窄运行范围 - `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` 用于在容器内过滤提供商 -- `OPENCLAW_SKIP_DOCKER_BUILD=1` 用于复用现有的 `openclaw:local-live` 镜像，以支持那些不需要重建的重跑 +- `OPENCLAW_SKIP_DOCKER_BUILD=1` 用于在无需重建时复用现有 `openclaw:local-live` 镜像 - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` 用于确保凭证来自 profile 存储（而非环境变量） -- `OPENCLAW_OPENWEBUI_MODEL=...` 用于选择 gateway 为 Open WebUI 冒烟测试暴露的模型 -- `OPENCLAW_OPENWEBUI_PROMPT=...` 用于覆盖 Open WebUI 冒烟测试使用的 nonce 检查提示词 +- `OPENCLAW_OPENWEBUI_MODEL=...` 用于选择在 Open WebUI 冒烟测试中由网关暴露的模型 +- `OPENCLAW_OPENWEBUI_PROMPT=...` 用于覆盖 Open WebUI 冒烟测试中使用的 nonce 检查提示词 - `OPENWEBUI_IMAGE=...` 用于覆盖固定的 Open WebUI 镜像标签 ## 文档完整性检查 -编辑文档后运行文档检查：`pnpm check:docs`。 -当你还需要页内标题检查时，运行完整的 Mintlify 锚点校验：`pnpm docs:check-links:anchors`。 +在修改文档后运行文档检查：`pnpm check:docs`。 +当你还需要检查页内标题时，运行完整的 Mintlify 锚点校验：`pnpm docs:check-links:anchors`。 -## 离线回归（对 CI 安全） +## 离线回归测试（CI 安全） -这些是“不依赖真实提供商”的“真实流水线”回归测试： +这些是在没有真实提供商的情况下运行的“真实流水线”回归测试： -- Gateway 网关工具调用（mock OpenAI，真实 gateway + Agent loop）：`src/gateway/gateway.test.ts`（用例：“runs a mock OpenAI tool call end-to-end via gateway agent loop”） -- Gateway 网关向导（WS `wizard.start`/`wizard.next`，强制写入配置 + 认证）：`src/gateway/gateway.test.ts`（用例：“runs wizard over ws and writes auth token config”） +- Gateway 网关工具调用（mock OpenAI，真实网关 + Agent loop）：`src/gateway/gateway.test.ts`（用例：“runs a mock OpenAI tool call end-to-end via gateway agent loop”） +- Gateway 网关向导（WS `wizard.start` / `wizard.next`，强制写入配置 + 认证）：`src/gateway/gateway.test.ts`（用例：“runs wizard over ws and writes auth token config”） ## 智能体可靠性评估（Skills） -我们已经有一些对 CI 安全的测试，其行为类似于“智能体可靠性评估”： +我们已经有一些可安全用于 CI 的测试，其行为类似“智能体可靠性评估”： -- 通过真实 gateway + Agent loop 的 mock 工具调用（`src/gateway/gateway.test.ts`）。 -- 用于验证会话接线和配置影响的端到端向导流程（`src/gateway/gateway.test.ts`）。 +- 通过真实 Gateway 网关 + Agent loop 的 mock 工具调用（`src/gateway/gateway.test.ts`）。 +- 验证会话接线和配置效果的端到端向导流程（`src/gateway/gateway.test.ts`）。 -对于 Skills（见 [Skills](/zh-CN/tools/skills)），目前仍缺少的部分有： +针对 Skills（参见 [Skills](/zh-CN/tools/skills)），目前仍缺少的是： -- **决策能力：** 当提示词中列出 Skills 时，智能体是否会选择正确的 Skill（或避免选择无关的 Skill）？ -- **合规性：** 智能体在使用前是否会读取 `SKILL.md`，并遵循要求的步骤/参数？ +- **决策能力：** 当 prompt 中列出 Skills 时，智能体是否会选择正确的 Skills（或避开无关的 Skills）？ +- **合规性：** 智能体是否会在使用前读取 `SKILL.md`，并遵循所需步骤 / 参数？ - **工作流契约：** 断言工具顺序、会话历史延续和沙箱边界的多轮场景。 -未来的评估应优先保持确定性： +未来的评估应首先保持确定性： -- 一个使用 mock 提供商的场景运行器，用于断言工具调用 + 顺序、Skill 文件读取以及会话接线。 -- 一小组面向 Skill 的场景（使用 vs 避免、门控、prompt injection）。 -- 只有在对 CI 安全的测试套件就位之后，才添加可选的 live 评估（显式启用、由环境变量控制）。 +- 一个使用 mock 提供商的场景运行器，用于断言工具调用 + 顺序、Skills 文件读取以及会话接线。 +- 一小组以 Skills 为中心的场景（使用 vs 避免、门控、提示注入）。 +- 仅在 CI 安全测试套件就位后，才添加可选的 live 评估（按需启用、受环境变量门控）。 -## 契约测试（plugin 和渠道结构） +## 契约测试（插件和渠道形状） -契约测试用于验证每个已注册 plugin 和渠道都符合其接口契约。它们会遍历所有已发现的 plugin，并运行一组结构和行为断言。默认的 `pnpm test` unit 通道会刻意跳过这些共享接缝和冒烟文件；当你修改共享渠道或提供商表面时，请显式运行契约命令。 +契约测试用于验证每个已注册的插件和渠道都符合其接口契约。它们会遍历所有已发现的插件，并运行一组关于形状和行为的断言。默认的 `pnpm test` 单元测试通道会有意跳过这些共享接缝和冒烟文件；当你修改共享渠道或提供商表面时，请显式运行契约命令。 ### 命令 - 所有契约测试：`pnpm test:contracts` -- 仅渠道契约：`pnpm test:contracts:channels` -- 仅提供商契约：`pnpm test:contracts:plugins` +- 仅渠道契约测试：`pnpm test:contracts:channels` +- 仅提供商契约测试：`pnpm test:contracts:plugins` -### 渠道契约 +### 渠道契约测试 位于 `src/channels/plugins/contracts/*.contract.test.ts`： -- **plugin** - 基本 plugin 结构（id、name、capabilities） -- **setup** - 向导设置契约 +- **plugin** - 基本插件形状（id、name、capabilities） +- **setup** - 设置向导契约 - **session-binding** - 会话绑定行为 - **outbound-payload** - 消息负载结构 - **inbound** - 入站消息处理 -- **actions** - 渠道操作处理器 +- **actions** - 渠道 action 处理器 - **threading** - 线程 ID 处理 -- **directory** - 目录/成员表 API +- **directory** - 目录 / roster API - **group-policy** - 群组策略执行 -### 提供商 Status 契约 +### 提供商 Status 契约测试 位于 `src/plugins/contracts/*.contract.test.ts`。 - **status** - 渠道 Status 探测 -- **registry** - plugin registry 结构 +- **registry** - 插件注册表形状 -### 提供商契约 +### 提供商契约测试 位于 `src/plugins/contracts/*.contract.test.ts`： -- **auth** - 认证流程契约 -- **auth-choice** - 认证选项/选择 +- **auth** - 认证流契约 +- **auth-choice** - 认证选项 / 选择 - **catalog** - 模型目录 API -- **discovery** - plugin 设备发现 -- **loader** - plugin 加载 +- **discovery** - 插件发现 +- **loader** - 插件加载 - **runtime** - 提供商运行时 -- **shape** - plugin 结构/接口 +- **shape** - 插件形状 / 接口 - **wizard** - 设置向导 ### 何时运行 - 修改 plugin-sdk 导出或子路径后 -- 添加或修改渠道 plugin 或提供商 plugin 后 -- 重构 plugin 注册或设备发现后 +- 添加或修改渠道或提供商插件后 +- 重构插件注册或发现逻辑后 契约测试会在 CI 中运行，并且不需要真实 API 密钥。 ## 添加回归测试（指南） -当你修复了一个在 live 中发现的提供商/模型问题时： +当你修复了在 live 中发现的提供商 / 模型问题时： -- 如果可能，添加一个对 CI 安全的回归测试（mock/stub 提供商，或捕获精确的请求结构转换） -- 如果它天然只能在 live 中复现（速率限制、认证策略），就让 live 测试保持收窄，并通过环境变量显式启用 -- 优先针对能捕获该缺陷的最小层级： - - 提供商请求转换/重放缺陷 → 直接模型测试 - - gateway 会话/历史/工具流水线缺陷 → gateway live 冒烟测试或对 CI 安全的 gateway mock 测试 -- SecretRef 遍历保护措施： - - `src/secrets/exec-secret-ref-id-parity.test.ts` 会从 registry 元数据（`listSecretTargetRegistryEntries()`）中为每个 SecretRef 类派生一个采样目标，然后断言 traversal-segment exec id 会被拒绝。 - - 如果你在 `src/secrets/target-registry-data.ts` 中新增了一个 `includeInPlan` SecretRef 目标族，请更新该测试中的 `classifyTargetClass`。该测试会在目标 id 未分类时刻意失败，以确保新类别不会被静默跳过。 +- 如果可能，添加一个对 CI 安全的回归测试（mock / stub 提供商，或捕获精确的请求形状转换） +- 如果它本质上只能通过 live 测试验证（速率限制、认证策略），就保持 live 测试足够收窄，并通过环境变量按需启用 +- 优先瞄准能捕获该缺陷的最小层级： + - 提供商请求转换 / 重放缺陷 → 直接模型测试 + - Gateway 网关会话 / 历史 / 工具流水线缺陷 → Gateway 网关 live 冒烟测试或对 CI 安全的 Gateway 网关 mock 测试 +- SecretRef 遍历保护栏： + - `src/secrets/exec-secret-ref-id-parity.test.ts` 会从注册表元数据（`listSecretTargetRegistryEntries()`）中为每个 SecretRef 类派生一个采样目标，然后断言遍历段 exec id 会被拒绝。 + - 如果你在 `src/secrets/target-registry-data.ts` 中新增了一个 `includeInPlan` SecretRef 目标族，请更新该测试中的 `classifyTargetClass`。该测试会在遇到未分类的目标 id 时有意失败，以确保新类别不会被静默跳过。 ## 相关内容 diff --git a/docs/zh-CN/reference/test.md b/docs/zh-CN/reference/test.md index a2b4e9e15..2c84b1a3d 100644 --- a/docs/zh-CN/reference/test.md +++ b/docs/zh-CN/reference/test.md @@ -1,54 +1,54 @@ --- read_when: - 运行或修复测试 -summary: 如何在本地运行测试（vitest），以及何时使用 force/coverage 模式 +summary: 如何在本地运行测试（`vitest`），以及何时使用 `force` / `coverage` 模式 title: 测试 x-i18n: - generated_at: "2026-04-26T22:14:40Z" + generated_at: "2026-04-26T22:39:43Z" model: gpt-5.4 provider: openai - source_hash: 676abe8e753d49719f3bc333680e50e0a0ec9f82c5c85b5ef7c1ec55452f10ed + source_hash: 57a5eff6e46662960a9b06a1f6883bb22b3fd8598de6338b4e7da3fa1b90b492 source_path: reference/test.md workflow: 15 --- - 完整测试工具包（测试套件、live、Docker）：[测试](/zh-CN/help/testing) -- `pnpm test:force`：终止任何仍在占用默认控制端口的残留 Gateway 网关进程，然后使用隔离的 Gateway 网关端口运行完整的 Vitest 测试套件，以避免服务器测试与正在运行的实例发生冲突。当之前的 Gateway 网关运行导致端口 18789 仍被占用时，请使用此命令。 -- `pnpm test:coverage`：通过 `vitest.unit.config.ts` 使用 V8 覆盖率运行单元测试套件。这是一个针对已加载文件的单元覆盖率门禁，而不是整个仓库的全文件覆盖率。阈值为行数 / 函数 / 语句 70%，分支 55%。由于 `coverage.all` 为 false，该门禁只统计被单元覆盖率测试套件加载的文件，而不会把拆分测试通道中的每个源文件都视为未覆盖。 -- `pnpm test:coverage:changed`：仅针对自 `origin/main` 以来发生变更的文件运行单元覆盖率。 -- `pnpm test:changed`：当差异只涉及可路由的源码 / 测试文件时，会将变更过的 Git 路径展开为有范围限制的 Vitest 通道。配置 / 设置变更仍会回退到原生根项目运行，以便在需要时对接线类改动进行更广泛的重跑。 -- `pnpm test:changed:focused`：用于内层循环的变更测试运行。它只会根据直接修改的测试、同级 `*.test.ts` 文件、显式源码映射以及本地导入图运行精确目标。较广泛的变更 / 配置 / 包变更会被跳过，而不会扩展为完整的变更测试回退运行。 -- `pnpm changed:lanes`：显示相对于 `origin/main` 的差异所触发的架构通道。 -- `pnpm check:changed`：对相对于 `origin/main` 的差异运行智能变更门禁。它会对 core 工作运行 core 测试通道，对扩展工作运行扩展测试通道，对纯测试工作仅运行测试类型检查 / 测试，将公开 Plugin SDK 或插件契约的变更扩展为一次扩展验证，并将仅涉及发布元数据的版本变更保持在有针对性的版本 / 配置 / 根依赖检查范围内。 -- `pnpm test`：通过有范围限制的 Vitest 通道来路由显式的文件 / 目录目标。未指定目标的运行会使用固定分片组，并展开为叶子配置以进行本地并行执行；扩展组始终会展开为各扩展的分片配置，而不是一个巨大的根项目进程。 -- 完整测试、扩展测试和 include-pattern 分片运行会更新 `.artifacts/vitest-shard-timings.json` 中的本地耗时数据；后续整配置运行会使用这些耗时来平衡快慢分片。include-pattern CI 分片会将分片名附加到耗时键名上，这样在不过度覆盖整配置耗时数据的前提下，筛选后的分片耗时仍然可见。设置 `OPENCLAW_TEST_PROJECTS_TIMINGS=0` 可忽略本地耗时产物。 -- 选定的 `plugin-sdk` 和 `commands` 测试文件现在会通过专用的轻量通道运行，这些通道只保留 `test/setup.ts`，而运行时较重的用例仍留在原有通道中。 -- 具有同级测试的源文件会优先映射到该同级测试，然后才回退到更宽泛的目录 glob。`test/helpers/channels` 和 `test/helpers/plugins` 下的辅助代码编辑会使用本地导入图来运行导入它们的测试，而不是在依赖路径明确时广泛重跑所有分片。 -- `auto-reply` 现在也被拆分为三个专用配置（`core`、`top-level`、`reply`），这样 reply harness 就不会主导较轻量的顶层状态 / token / helper 测试。 -- 基础 Vitest 配置现在默认使用 `pool: "threads"` 和 `isolate: false`，并在整个仓库配置中启用了共享的非隔离运行器。 +- `pnpm test:force`：终止任何仍在占用默认控制端口的残留 Gateway 网关进程，然后使用隔离的 Gateway 网关端口运行完整的 Vitest 测试套件，避免服务器测试与正在运行的实例发生冲突。当先前的 Gateway 网关运行导致端口 `18789` 仍被占用时，使用此命令。 +- `pnpm test:coverage`：通过 `vitest.unit.config.ts` 使用 V8 coverage 运行单元测试套件。这是一个基于已加载文件的单元 coverage 检查，而不是覆盖整个仓库所有文件的 coverage。阈值为：行数 / 函数 / 语句 70%，分支 55%。由于 `coverage.all` 为 false，该检查只统计被单元 coverage 套件加载的文件，而不会把所有拆分测试通道中的源文件都视为未覆盖。 +- `pnpm test:coverage:changed`：只针对相对于 `origin/main` 发生变更的文件运行单元 coverage。 +- `pnpm test:changed`：当 diff 只涉及可路由的源文件 / 测试文件时，将 Git 变更路径展开为有范围限制的 Vitest 测试通道。配置 / setup 变更仍会回退到原生根项目运行方式，因此接线类修改在需要时会更广泛地重新运行测试。 +- `pnpm test:changed:focused`：用于内循环的变更测试运行。它只会基于直接修改的测试文件、同级 `*.test.ts` 文件、显式源文件映射以及本地导入图来运行精确目标。广泛的 / 配置 / package 变更会被跳过，而不是扩展为完整的变更测试回退运行。 +- `pnpm changed:lanes`：显示相对于 `origin/main` 的 diff 所触发的架构测试通道。 +- `pnpm check:changed`：对相对于 `origin/main` 的 diff 运行智能变更检查。它会将核心代码与核心测试通道一起运行，将扩展代码与扩展测试通道一起运行，仅测试变更则只运行测试类型检查 / 测试；对于公开的 插件 SDK 或插件契约变更，会额外扩展一次扩展校验；对于仅包含发布元数据的版本号提升，则保持在有针对性的版本 / 配置 / 根依赖检查范围内。 +- `pnpm test`：将显式传入的文件 / 目录目标路由到有范围限制的 Vitest 测试通道。未指定目标时，会使用固定的分片组，并展开到叶子配置以便在本地并行执行；扩展组始终会展开为各个扩展 / 插件的分片配置，而不是使用一个巨大的根项目进程。 +- 完整测试、扩展测试和 include-pattern 分片运行会把本地耗时数据更新到 `.artifacts/vitest-shard-timings.json`；后续整套配置运行会利用这些耗时数据来平衡慢分片和快分片。include-pattern CI 分片会把分片名称附加到耗时键名中，因此筛选后的分片耗时仍可见，而不会覆盖整套配置的耗时数据。设置 `OPENCLAW_TEST_PROJECTS_TIMINGS=0` 可忽略本地耗时产物。 +- 部分 `plugin-sdk` 和 `commands` 测试文件现在会路由到专用的轻量测试通道，只保留 `test/setup.ts`，而运行时负担较重的用例仍保留在原有测试通道中。 +- 带有同级测试的源文件会优先映射到该同级测试，然后才会回退到更宽泛的目录 glob。`test/helpers/channels` 和 `test/helpers/plugins` 下的辅助文件变更会使用本地导入图来运行导入它们的测试，而不是在依赖路径明确时广泛运行所有分片。 +- `auto-reply` 现在还拆分为三个专用配置（`core`、`top-level`、`reply`），这样 reply harness 就不会主导较轻量的顶层 Status / token / helper 测试。 +- 基础 Vitest 配置现在默认使用 `pool: "threads"` 和 `isolate: false`，并在整个仓库配置中启用共享的非隔离运行器。 - `pnpm test:channels` 运行 `vitest.channels.config.ts`。 -- `pnpm test:extensions` 和 `pnpm test extensions` 会运行所有扩展 / 插件分片。较重的渠道插件、browser 插件以及 OpenAI 作为专用分片运行；其他插件组保持批量运行。单个内置插件通道请使用 `pnpm test extensions/`。 -- `pnpm test:perf:imports`：启用 Vitest 导入时长和导入细分报告，同时仍对显式文件 / 目录目标使用有范围限制的通道路由。 -- `pnpm test:perf:imports:changed`：相同的导入性能分析，但仅针对自 `origin/main` 以来发生变更的文件。 -- `pnpm test:perf:changed:bench -- --ref `：对比同一份已提交 Git 差异下，路由后的 changed 模式路径与原生根项目运行的性能。 -- `pnpm test:perf:changed:bench -- --worktree`：对当前工作树变更集进行基准测试，无需先提交。 +- `pnpm test:extensions` 和 `pnpm test extensions` 会运行所有扩展 / 插件分片。重量级渠道插件、浏览器插件以及 OpenAI 会作为专用分片运行；其他插件组保持批量运行。对单个内置插件测试通道，使用 `pnpm test extensions/`。 +- `pnpm test:perf:imports`：启用 Vitest 导入耗时 + 导入拆解报告，同时对显式文件 / 目录目标仍使用有范围限制的测试通道路由。 +- `pnpm test:perf:imports:changed`：与上面相同的导入性能分析，但仅针对相对于 `origin/main` 发生变更的文件。 +- `pnpm test:perf:changed:bench -- --ref `：针对同一份已提交的 Git diff，对路由后的 changed 模式路径与原生根项目运行做基准对比。 +- `pnpm test:perf:changed:bench -- --worktree`：先不提交，直接对当前 worktree 的变更集做基准对比。 - `pnpm test:perf:profile:main`：为 Vitest 主线程写入 CPU profile（`.artifacts/vitest-main-profile`）。 -- `pnpm test:perf:profile:runner`：为单元测试运行器写入 CPU + 堆 profile（`.artifacts/vitest-runner-profile`）。 -- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`：串行运行每个完整测试套件的 Vitest 叶子配置，并写入分组耗时数据以及每个配置的 JSON / 日志产物。Test Performance Agent 会将其作为尝试修复慢测试前的基线。 -- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`：比较一次以性能为重点的变更前后的分组报告。 -- Gateway 网关集成：通过 `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` 或 `pnpm test:gateway` 选择启用。 -- `pnpm test:e2e`：运行 Gateway 网关端到端冒烟测试（多实例 WS/HTTP/节点配对）。在 `vitest.e2e.config.ts` 中默认使用 `threads` + `isolate: false` 和自适应 workers；可通过 `OPENCLAW_E2E_WORKERS=` 调整，并设置 `OPENCLAW_E2E_VERBOSE=1` 以输出详细日志。 -- `pnpm test:live`：运行提供商 live 测试（minimax/zai）。需要 API 密钥和 `LIVE=1`（或提供商特定的 `*_LIVE_TEST=1`）才能取消跳过。 -- `pnpm test:docker:all`：构建共享的 live 测试镜像，将 OpenClaw 一次性打包为 npm tarball，构建 / 复用一个裸 Node/Git 运行器镜像以及一个功能镜像，后者会将该 tarball 安装到 `/app`，然后通过加权调度器在设置了 `OPENCLAW_SKIP_DOCKER_BUILD=1` 的情况下运行 Docker 冒烟通道。裸镜像（`OPENCLAW_DOCKER_E2E_BARE_IMAGE`）用于安装器 / 更新 / 插件依赖通道；这些通道会挂载预构建 tarball，而不是使用复制的仓库源码。功能镜像（`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`）用于常规的已构建应用功能通道。`OPENCLAW_DOCKER_ALL_PARALLELISM=` 控制进程槽位，默认值为 10；`OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=` 控制对提供商敏感的尾部池，默认值为 10。重型通道上限默认为 `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`、`OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` 和 `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`；提供商上限默认是每个提供商一个重型通道，具体为 `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`、`OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` 和 `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`。在更大主机上可使用 `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` 或 `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`。默认情况下，通道启动会错开 2 秒，以避免本地 Docker 守护进程创建风暴；可通过 `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=` 覆盖。运行器默认会预检查 Docker，清理陈旧的 OpenClaw E2E 容器，每 30 秒输出一次活动通道状态，在兼容通道之间共享提供商 CLI 工具缓存，默认对瞬时 live 提供商失败重试一次（`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=`），并将通道耗时存储在 `.artifacts/docker-tests/lane-timings.json` 中，以便后续运行按最长优先排序。使用 `OPENCLAW_DOCKER_ALL_DRY_RUN=1` 可仅打印通道清单而不运行 Docker，使用 `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=` 可调整状态输出频率，使用 `OPENCLAW_DOCKER_ALL_TIMINGS=0` 可禁用耗时复用。对仅需要确定性 / 本地通道的情况可使用 `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip`，对仅需要 live 提供商通道的情况可使用 `OPENCLAW_DOCKER_ALL_LIVE_MODE=only`；对应的包别名为 `pnpm test:docker:local:all` 和 `pnpm test:docker:live:all`。仅 live 模式会将主 live 通道和尾部 live 通道合并为一个按最长优先的池，以便提供商桶能将 Claude、Codex 和 Gemini 工作混合打包。除非设置了 `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`，否则运行器会在首次失败后停止调度新的池化通道；每个通道都有 120 分钟的后备超时，可通过 `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` 覆盖；部分 live / tail 通道使用更严格的单通道上限。CLI 后端 Docker 设置命令也有自己的超时设置：`OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS`（默认 180）。每个通道的日志和 `summary.json` 阶段耗时会写入 `.artifacts/docker-tests//`。 -- `pnpm test:docker:browser-cdp-snapshot`：构建一个基于 Chromium 的源码 E2E 容器，启动原始 CDP 和一个隔离的 Gateway 网关，运行 `browser doctor --deep`，并验证 CDP 角色快照包含链接 URL、由光标提升的可点击元素、iframe 引用和 frame 元数据。 -- CLI 后端 live Docker 探针可以作为聚焦通道运行，例如 `pnpm test:docker:live-cli-backend:codex`、`pnpm test:docker:live-cli-backend:codex:resume` 或 `pnpm test:docker:live-cli-backend:codex:mcp`。Claude 和 Gemini 也有对应的 `:resume` 和 `:mcp` 别名。 -- `pnpm test:docker:openwebui`：启动 Docker 化的 OpenClaw + Open WebUI，通过 Open WebUI 登录，检查 `/api/models`，然后通过 `/api/chat/completions` 运行一次真实的代理聊天。需要可用的 live 模型密钥（例如 `~/.profile` 中的 OpenAI），会拉取外部 Open WebUI 镜像，且不像常规 unit/e2e 测试套件那样被视为 CI 稳定。 -- `pnpm test:docker:mcp-channels`：启动一个带种子数据的 Gateway 网关容器和第二个客户端容器，后者会启动 `openclaw mcp serve`，然后验证经路由的会话发现、转录读取、附件元数据、live 事件队列行为、出站发送路由，以及通过真实 stdio bridge 传递的 Claude 风格渠道和权限通知。Claude 通知断言会直接读取原始 stdio MCP 帧，因此该冒烟测试反映的是 bridge 实际发出的内容。 +- `pnpm test:perf:profile:runner`：为 unit runner 写入 CPU + heap profile（`.artifacts/vitest-runner-profile`）。 +- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`：串行运行完整测试套件中的每个 Vitest 叶子配置，并写出分组耗时数据以及每个配置的 JSON / 日志产物。测试性能智能体会将其作为尝试修复慢测试之前的基线。 +- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`：对比性能优化变更前后的分组报告。 +- Gateway 网关集成测试：通过 `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` 或 `pnpm test:gateway` 显式启用。 +- `pnpm test:e2e`：运行 Gateway 网关端到端 smoke 测试（多实例 WS / HTTP / 节点配对）。在 `vitest.e2e.config.ts` 中默认使用 `threads` + `isolate: false` 和自适应 workers；可通过 `OPENCLAW_E2E_WORKERS=` 调整，并设置 `OPENCLAW_E2E_VERBOSE=1` 输出详细日志。 +- `pnpm test:live`：运行提供商 live 测试（minimax / zai）。需要 API key，并设置 `LIVE=1`（或特定提供商的 `*_LIVE_TEST=1`）才能取消跳过。 +- `pnpm test:docker:all`：构建共享的 live-test 镜像，将 OpenClaw 一次性打包为 npm tarball，构建 / 复用一个裸 Node / Git runner 镜像以及一个功能镜像，后者会把该 tarball 安装到 `/app`，然后通过加权调度器在设置 `OPENCLAW_SKIP_DOCKER_BUILD=1` 的情况下运行 Docker smoke 测试通道。裸镜像（`OPENCLAW_DOCKER_E2E_BARE_IMAGE`）用于安装器 / 更新 / 插件依赖测试通道；这些通道会挂载预构建 tarball，而不是使用复制的仓库源码。功能镜像（`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`）用于正常的已构建应用功能测试通道。`scripts/package-openclaw-for-docker.mjs` 是本地 / CI 唯一的 package 打包器。Docker 测试通道定义位于 `scripts/lib/docker-e2e-scenarios.mjs`；规划逻辑位于 `scripts/lib/docker-e2e-plan.mjs`；`scripts/test-docker-all.mjs` 负责执行所选计划。`node scripts/test-docker-all.mjs --plan-json` 会输出由调度器拥有的 CI 计划，其中包括所选测试通道、镜像类型、package / live-image 需求以及凭证检查，而不会实际构建或运行 Docker。`OPENCLAW_DOCKER_ALL_PARALLELISM=` 控制进程槽位，默认值为 10；`OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=` 控制对提供商敏感的尾部池，默认值也为 10。重量级测试通道上限默认分别为 `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`、`OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` 和 `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`；提供商上限默认是每个提供商一个重量级测试通道，通过 `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`、`OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` 和 `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4` 控制。对于更大的主机，可使用 `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` 或 `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`。为避免本地 Docker daemon 在创建时出现风暴，测试通道启动默认错开 2 秒；可通过 `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=` 覆盖。运行器默认会对 Docker 做预检，清理陈旧的 OpenClaw E2E 容器，每 30 秒输出一次活跃测试通道状态，在兼容测试通道之间共享提供商 CLI 工具缓存，对临时性的 live 提供商失败默认重试一次（`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=`），并将测试通道耗时存储到 `.artifacts/docker-tests/lane-timings.json`，供后续运行按最长优先排序。使用 `OPENCLAW_DOCKER_ALL_DRY_RUN=1` 可只打印测试通道清单而不运行 Docker，使用 `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=` 调整状态输出频率，或使用 `OPENCLAW_DOCKER_ALL_TIMINGS=0` 禁用耗时复用。使用 `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` 只运行确定性的 / 本地测试通道，或使用 `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` 只运行 live 提供商测试通道；对应的 package 别名为 `pnpm test:docker:local:all` 和 `pnpm test:docker:live:all`。仅 live 模式会把 main 和 tail 的 live 测试通道合并为一个按最长优先排序的池，这样提供商桶就可以一起打包 Claude、Codex 和 Gemini 的工作。运行器在首次失败后会停止调度新的池化测试通道，除非设置 `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`；每个测试通道都有一个 120 分钟的后备超时，可通过 `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` 覆盖；部分选定的 live / tail 测试通道使用更紧的单通道上限。CLI 后端 Docker 设置命令有单独的超时控制，通过 `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS`（默认 180）。每个测试通道的日志和 `summary.json` 阶段耗时会写入 `.artifacts/docker-tests//`。 +- `pnpm test:docker:browser-cdp-snapshot`：构建一个基于 Chromium 的源码 E2E 容器，启动原始 CDP 和一个隔离的 Gateway 网关，运行 `browser doctor --deep`，并验证 CDP 角色快照包含链接 URL、由光标提升的可点击元素、iframe 引用以及 frame 元数据。 +- CLI 后端 live Docker 探测可以作为聚焦测试通道运行，例如 `pnpm test:docker:live-cli-backend:codex`、`pnpm test:docker:live-cli-backend:codex:resume` 或 `pnpm test:docker:live-cli-backend:codex:mcp`。Claude 和 Gemini 也有对应的 `:resume` 和 `:mcp` 别名。 +- `pnpm test:docker:openwebui`：启动 Docker 化的 OpenClaw + Open WebUI，通过 Open WebUI 登录，检查 `/api/models`，然后通过 `/api/chat/completions` 运行一次真实的代理聊天。需要可用的 live 模型 key（例如 `~/.profile` 中的 OpenAI），会拉取外部 Open WebUI 镜像，并不像常规 unit / e2e 测试套件那样以 CI 稳定性为预期。 +- `pnpm test:docker:mcp-channels`：启动一个带种子数据的 Gateway 网关容器和第二个客户端容器，后者会启动 `openclaw mcp serve`，然后验证路由后的会话发现、transcript 读取、附件元数据、live 事件队列行为、出站发送路由，以及通过真实 stdio bridge 发送的 Claude 风格渠道 + 权限通知。Claude 通知断言会直接读取原始 stdio MCP 帧，因此该 smoke 测试能反映 bridge 实际发出的内容。 -## 本地 PR 门禁 +## 本地 PR 检查门槛 -对于本地 PR 合并 / 门禁检查，请运行： +对于本地 PR 提交 / 合入前检查，运行： - `pnpm check:changed` - `pnpm check` @@ -57,12 +57,12 @@ x-i18n: - `pnpm test` - `pnpm check:docs` -如果 `pnpm test` 在高负载主机上偶发失败，请先重跑一次，再将其视为回归；随后使用 `pnpm test ` 进行隔离。对于内存受限的主机，请使用： +如果 `pnpm test` 在负载较高的主机上出现偶发失败，在将其视为回归之前先重跑一次，然后用 `pnpm test ` 进行隔离。对于内存受限的主机，使用： - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test` - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed` -## 模型延迟基准测试（本地密钥） +## 模型延迟基准测试（本地 keys） 脚本：[`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts) @@ -70,9 +70,9 @@ x-i18n: - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10` - 可选环境变量：`MINIMAX_API_KEY`、`MINIMAX_BASE_URL`、`MINIMAX_MODEL`、`ANTHROPIC_API_KEY` -- 默认提示词：“Reply with a single word: ok. No punctuation or extra text.” +- 默认提示词：“用一个单词回复：ok。不要使用标点或额外文本。” -最近一次运行（2025-12-31，20 次）： +上次运行（2025-12-31，20 次运行）： - minimax 中位数 1279ms（最小 1114，最大 2431） - opus 中位数 2454ms（最小 1224，最大 3170） @@ -102,17 +102,17 @@ x-i18n: - `startup`：`--version`、`--help`、`health`、`health --json`、`status --json`、`status` - `real`：`health`、`status`、`status --json`、`sessions`、`sessions --json`、`agents list --json`、`gateway status`、`gateway status --json`、`gateway health --json`、`config get gateway.port` -- `all`：同时包含这两个预设 +- `all`：同时包含两个预设 -输出包括每个命令的 `sampleCount`、平均值、p50、p95、最小值 / 最大值、退出码 / 信号分布，以及最大 RSS 汇总。可选的 `--cpu-prof-dir` / `--heap-prof-dir` 会为每次运行写入 V8 profile，这样计时和 profile 采集会使用同一个 harness。 +输出内容包括每个命令的 `sampleCount`、avg、p50、p95、min/max、exit-code / signal 分布，以及最大 RSS 汇总。可选的 `--cpu-prof-dir` / `--heap-prof-dir` 会为每次运行写入 V8 profile，因此耗时采集和 profile 捕获使用同一个 harness。 保存输出约定： -- `pnpm test:startup:bench:smoke` 会将目标冒烟产物写入 `.artifacts/cli-startup-bench-smoke.json` -- `pnpm test:startup:bench:save` 会使用 `runs=5` 和 `warmup=1` 将完整测试套件产物写入 `.artifacts/cli-startup-bench-all.json` -- `pnpm test:startup:bench:update` 会使用 `runs=5` 和 `warmup=1` 刷新已提交的基线 fixture，路径为 `test/fixtures/cli-startup-bench.json` +- `pnpm test:startup:bench:smoke` 会将定向 smoke 产物写入 `.artifacts/cli-startup-bench-smoke.json` +- `pnpm test:startup:bench:save` 会使用 `runs=5` 和 `warmup=1`，将完整测试套件产物写入 `.artifacts/cli-startup-bench-all.json` +- `pnpm test:startup:bench:update` 会使用 `runs=5` 和 `warmup=1`，刷新已检入的基线 fixture：`test/fixtures/cli-startup-bench.json` -已提交的 fixture： +已检入的 fixture： - `test/fixtures/cli-startup-bench.json` - 使用 `pnpm test:startup:bench:update` 刷新 @@ -120,19 +120,19 @@ x-i18n: ## 新手引导 E2E（Docker） -Docker 是可选的；只有在进行容器化新手引导冒烟测试时才需要。 +Docker 是可选的；只有在进行容器化的新手引导 smoke 测试时才需要。 -在干净的 Linux 容器中运行完整冷启动流程： +在一个干净的 Linux 容器中运行完整的冷启动流程： ```bash scripts/e2e/onboard-docker.sh ``` -该脚本会通过伪终端驱动交互式向导，验证配置 / 工作区 / 会话文件，然后启动 Gateway 网关并运行 `openclaw health`。 +该脚本会通过 pseudo-tty 驱动交互式向导，验证配置 / workspace / session 文件，然后启动 Gateway 网关并运行 `openclaw health`。 -## QR 导入冒烟测试（Docker） +## QR 导入 smoke 测试（Docker） -确保维护中的 QR 运行时辅助程序能够在受支持的 Docker Node 运行时下加载（默认 Node 24，兼容 Node 22）： +确保维护中的 QR 运行时 helper 能在受支持的 Docker Node 运行时下正确加载（默认 Node 24，兼容 Node 22）： ```bash pnpm test:docker:qr @@ -141,4 +141,4 @@ pnpm test:docker:qr ## 相关内容 - [测试](/zh-CN/help/testing) -- [Testing live](/zh-CN/help/testing-live) +- [测试 live](/zh-CN/help/testing-live)