实时与 Docker/Parallels 工作流

Live 与 Docker/Parallels 工作流¶

在调试真实提供商/模型时（需要真实凭据）：

• Live 套件（模型 + 网关工具/图像探针）：pnpm test:live
• 单独运行某个 Live 文件：pnpm test:live -- src/agents/models.profiles.live.test.ts
• 进度卡片刷新：OPENCLAW_LIVE_TEST=1 pnpm test:live -- src/gateway/gateway-progress-refresh.live.test.ts
• 需要 OPENAI_API_KEY，并使用 openai/gpt-5.6-luna 和隔离的 Gateway 状态。
• 先完成前一轮回合，然后在第二轮回合期间、当一条命令仍被保持（held）时进行刷新。原始父级必须更新卡片并保留其最终回复。随后的空闲刷新必须更新卡片，且不得添加聊天消息或恢复待处理的工作。
• Live 子代理交接压力测试： OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_SUBAGENT_STRESS=1 pnpm test:live -- src/agents/subagents/announce/subagent-yield-resume.live.test.ts
• 需要 OPENAI_API_KEY，默认使用 openai/gpt-5.6-luna；可通过 OPENCLAW_LIVE_SUBAGENT_E2E_MODEL 选择其他 OpenAI 模型。
• 固定使用 OpenClaw agent harness，并使用隔离的 Gateway 状态、合成文件以及外部保持的 HTTP 响应。它检查：并发隐藏结果扇出（fanout）、对等待中的子代理树进行仅状态查询、由操作员恢复（保留任务身份并幂等重放）、子代理超时、真实的 HTTP 503 检索失败，以及在其所有者认领运行后取消操作与进行中结果之间的竞争。父级报告将对照被保持的请求、子代理执行情况、任务投递状态和隐藏结果进行校验。503 用例验证：代理回合完成并不代表检索成功。
• 每个用例都会在 .artifacts/qa-e2e/subagent-challenges-*/evidence.json 中增量保留有界运行时事实以及最终助手回复，包括失败运行。设置 OPENCLAW_LIVE_SUBAGENT_EVIDENCE_DIR 可更改输出目录。此 Live 通道不模拟冷进程丢失；重启和丢失接受（lost-acceptance）的所有权由 subagent-orphan-recovery.restart-integration.test.ts 覆盖。
• 默认为两批、每批三个子代理。设置 OPENCLAW_LIVE_SUBAGENT_STRESS_BATCHES（1–5）和 OPENCLAW_LIVE_SUBAGENT_STRESS_CHILDREN（1–6）可更改有界工作量。
• Live Gateway 并发：在 main 分支上以 mode=gateway-concurrency 和 live_openai_candidate=true 触发 OpenClaw Performance。它会在 32 个代理上运行 96 个真实回合，包含 1,000 个预置会话、并发会话活动以及负载阶段的 CPU 剖析数据。Dreaming 被禁用，而常规索引和回顾（recaps）保持启用。结果保留在 Actions 产物中。参见 Gateway 并发基准。
• 运行时性能报告：以 live_openai_candidate=true 触发 OpenClaw Performance 可执行一次真实的 openai/gpt-5.6-luna 代理回合；以 deep_profile=true 触发可生成 Kova CPU/堆/追踪（trace）产物。每日定时运行会通过一个独立的、消费产物的发布者作业，将 mock-provider、deep-profile 和 GPT-5.6 Luna 通道报告发布到 openclaw/clawgrit-reports；发布者认证缺失或无效会导致定时运行和 profile=release 运行失败。手动非 release 触发会保留 GitHub 产物，并将报告发布视为建议性操作。mock-provider 报告还包括源码级网关启动、内存、插件压力、重复假模型 hello 循环以及 CLI 启动数据。
• Docker Live 模型扫描：pnpm test:docker:live-models
• 每个选定的模型都会运行一个文本回合和一个小的类文件读取（file-read-style）探针。元数据声明支持 image 输入的模型还会运行一个微型图像回合。在隔离提供商故障时，可通过 OPENCLAW_LIVE_MODEL_FILE_PROBE=0 或 OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0 禁用这些额外探针。
• CI 覆盖：每日 OpenClaw Scheduled Live And E2E Checks 和手动 OpenClaw Release Checks 都会以 include_live_suites: true 调用可复用的 live/E2E 工作流，其中包含按提供商分片的 Docker Live 模型矩阵作业。
• 如需聚焦的 CI 重跑，请以 include_live_suites: true 和 live_models_only: true 触发 OpenClaw Live And E2E Checks (Reusable)。
• 将新的高信号提供商密钥添加到 scripts/ci-hydrate-live-auth.sh、.github/workflows/openclaw-live-and-e2e-checks-reusable.yml 及其定时/release 调用方中。
• 原生 Codex 绑定会话冒烟测试：pnpm test:docker:live-codex-bind
• 在 Docker 中针对 Codex app-server 路径运行一条 Live 通道，使用 /codex bind 绑定一个合成的 Slack DM，执行 /codex fast 和 /codex permissions，然后验证普通回复和图像附件都通过原生插件绑定路由而非 ACP。
• Codex app-server harness 冒烟测试：pnpm test:docker:live-codex-harness
• 通过插件拥有的 Codex app-server harness 运行网关代理回合，验证 /codex status 和 /codex models，并且默认会执行图像、cron MCP、子代理和 Guardian 探针。在隔离其他故障时，可通过 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，否则该命令会在子代理探针之后退出。
• Codex 按需安装冒烟测试：pnpm test:docker:codex-on-demand
• 在 Docker 中安装打包好的 OpenClaw tarball，运行 OpenAI API 密钥引导（onboarding），并验证 Codex 插件及 @openai/codex 依赖是否已按需下载到受管理的 npm 项目根目录。
• Codex npm 插件 Live 包冒烟测试：pnpm test:docker:live-codex-npm-plugin
• 将候选 OpenClaw 包和精确版本的 Codex 插件安装到 Docker 中，然后使用真实的 OpenAI 密钥执行 CLI 预检和同会话回合。
• 其零重试、中等思考（medium-thinking）的完整执行回合必须发送进度，在随机化的工作区读取和一次精确的产物写入中持续工作，然后发送完成。仅发送进度的最终回合会导致该通道失败。
• Live 插件工具依赖冒烟测试：pnpm test:docker:live-plugin-tool
• 打包一个带有真实 slugify 依赖的 fixture 插件，通过 npm-pack: 安装它，在受管理的 npm 项目根目录下验证该依赖，然后让一个真实的 OpenAI 模型调用插件工具并返回隐藏的 slug。
• OpenClaw 救援命令冒烟测试：pnpm test:live:system-agent-rescue-channel
• 针对消息通道救援命令接口提供可选的双重保险检查。执行 /openclaw status，入队一个持久化模型更改，回复 /openclaw yes，并验证审计/配置写入路径。
• OpenClaw 首次运行 Docker 冒烟测试：pnpm test:docker:system-agent-first-run
• 从空的 OpenClaw 状态目录开始，首先证明打包的 openclaw setup CLI 在没有推理能力时会安全失败（fail closed）。随后通过打包的激活模块测试并激活假的 Claude。只有在之后，一个模糊的打包 CLI 请求才会到达规划器并解析为类型化设置，随后执行一次性模型、代理、Discord 配置和 SecretRef 操作。它会验证配置和审计条目。这是支持性的门禁/操作证据，而非交互式引导或 OpenClaw 代理/工具/审批证明。同一通道也可在 QA Lab 中通过 pnpm openclaw qa suite --scenario system-agent-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，并且助手转录中存储了归一化的 usage.cost。