chore(i18n): refresh zh-CN translations

docs/zh-CN/ci.md

@@ -1,81 +1,81 @@
 ---
 read_when:
-    - 你需要了解某个 CI 作业为什么会运行，或者为什么没有运行
+    - 你需要了解某个 CI 作业为什么会运行或没有运行
     - 你正在调试失败的 GitHub Actions 检查
-summary: CI 作业图、范围门禁，以及本地等效命令
+summary: CI 作业图、作用域门禁以及本地等效命令
 title: CI 流水线
 x-i18n:
-    generated_at: "2026-04-23T05:24:47Z"
+    generated_at: "2026-04-23T13:33:19Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 5c89c66204b203a39435cfc19de7b437867f2792bbfa2c3948371abde9f80e11
+    source_hash: 730bba64e0867f41b47e4896f8255b6d23e6530bb91d349abb25b35a43152e9e
     source_path: ci.md
     workflow: 15
 ---
 
 # CI 流水线
 
-CI 会在每次推送到 `main` 以及每个拉取请求上运行。它使用智能范围控制，在仅有不相关区域发生变更时跳过高开销作业。
+CI 会在每次推送到 `main` 以及每个拉取请求时运行。它使用智能作用域划分，在只改动无关区域时跳过高开销作业。
 
-QA Lab 在主智能范围工作流之外拥有专用的 CI 通道。`Parity gate` 工作流会在匹配的 PR 变更和手动触发时运行；它会构建私有 QA 运行时，并比较模拟的 GPT-5.4 和 Opus 4.6 智能体包。`QA-Lab - All Lanes` 工作流会在 `main` 上每晚运行，也支持手动触发；它会将模拟 parity gate、实时 Matrix 通道和实时 Telegram 通道作为并行作业展开。实时作业使用 `qa-live-shared` 环境，而 Telegram 通道使用 Convex 租约。`OpenClaw Release Checks` 也会在发布批准前运行同样的 QA Lab 通道。
+QA Lab 在主智能作用域工作流之外有专用的 CI 通道。`Parity gate` 工作流会在匹配的 PR 变更和手动触发时运行；它会构建私有 QA 运行时，并比较模拟的 GPT-5.4 和 Opus 4.6 智能体包。`QA-Lab - All Lanes` 工作流会在 `main` 上每晚运行，并支持手动触发；它会将模拟 parity gate、实时 Matrix 通道和实时 Telegram 通道作为并行作业展开。实时作业使用 `qa-live-shared` environment，Telegram 通道使用 Convex 租约。`OpenClaw Release Checks` 也会在发布批准前运行相同的 QA Lab 通道。
 
 ## 作业概览
 
-| 作业 | 用途 | 运行时机 |
+| 作业 | 目的 | 运行时机 |
 | -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ |
-| `preflight` | 检测是否仅为文档变更、变更范围、变更的扩展，并构建 CI 清单 | 始终在非草稿推送和 PR 上运行 |
-| `security-scm-fast` | 通过 `zizmor` 进行私钥检测和工作流审计 | 始终在非草稿推送和 PR 上运行 |
-| `security-dependency-audit` | 针对 npm 安全公告执行无需安装依赖的生产锁文件审计 | 始终在非草稿推送和 PR 上运行 |
+| `preflight` | 检测是否仅有文档变更、变更的作用域、变更的扩展，并构建 CI 清单 | 始终在非草稿推送和 PR 上运行 |
+| `security-scm-fast` | 通过 `zizmor` 检测私钥和审计工作流 | 始终在非草稿推送和 PR 上运行 |
+| `security-dependency-audit` | 针对 npm advisory 执行无依赖的生产 lockfile 审计 | 始终在非草稿推送和 PR 上运行 |
 | `security-fast` | 快速安全作业的必需聚合作业 | 始终在非草稿推送和 PR 上运行 |
-| `build-artifacts` | 构建 `dist/`、Control UI、已构建产物检查，以及可复用的下游产物 | 与 Node 相关的变更 |
+| `build-artifacts` | 构建 `dist/`、Control UI、内置产物检查，以及可供下游复用的产物 | 与 Node 相关的变更 |
 | `checks-fast-core` | 快速 Linux 正确性通道，例如 bundled/plugin-contract/protocol 检查 | 与 Node 相关的变更 |
 | `checks-fast-contracts-channels` | 分片的渠道契约检查，并提供稳定的聚合检查结果 | 与 Node 相关的变更 |
-| `checks-node-extensions` | 覆盖整个扩展套件的完整 bundled-plugin 测试分片 | 与 Node 相关的变更 |
-| `checks-node-core-test` | 核心 Node 测试分片，不包含渠道、bundled、契约和扩展通道 | 与 Node 相关的变更 |
-| `extension-fast` | 仅针对发生变更的 bundled plugins 的聚焦测试 | 带有扩展变更的拉取请求 |
-| `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-node-extensions` | 针对整个扩展套件的完整内置插件测试分片 | 与 Node 相关的变更 |
+| `checks-node-core-test` | Core 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-node` | 使用共享构建产物的 macOS TypeScript 测试通道 | 与 macOS 相关的变更 |
 | `macos-swift` | macOS 应用的 Swift lint、构建和测试 | 与 macOS 相关的变更 |
 | `android` | 两个 flavor 的 Android 单元测试，以及一个 debug APK 构建 | 与 Android 相关的变更 |
 
 ## 快速失败顺序
 
-作业的排序方式确保廉价检查会在高开销作业运行前先失败：
+作业按顺序排列，以便让便宜的检查先失败，再运行昂贵的检查：
 
-1. `preflight` 决定哪些通道会存在。`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`。
+1. `preflight` 决定哪些通道实际存在。`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`。
 
-范围逻辑位于 `scripts/ci-changed-scope.mjs` 中，并由 `src/scripts/ci-changed-scope.test.ts` 中的单元测试覆盖。
-CI 工作流编辑会验证 Node CI 作业图以及工作流 lint，但仅凭这些编辑本身不会强制触发 Windows、Android 或 macOS 原生构建；这些平台通道仍然只会在对应平台源码发生变更时运行。
-Windows Node 检查的范围仅限于 Windows 专用的进程/路径包装器、npm/pnpm/UI 运行器辅助工具、包管理器配置，以及执行该通道的 CI 工作流表面；不相关的源码、plugin、安装 smoke 和仅测试类变更仍然保留在 Linux Node 通道中，这样它们就不会为已经由常规测试分片覆盖的内容占用一个 16 vCPU 的 Windows worker。
-独立的 `install-smoke` 工作流通过它自己的 `preflight` 作业复用同一个范围脚本。它根据更窄的 changed-smoke 信号计算 `run_install_smoke`，因此 Docker/安装 smoke 会针对安装、打包、容器相关变更、bundled extension 生产代码变更，以及 Docker smoke 作业所覆盖的核心 plugin/channel/Gateway 网关/插件 SDK 表面运行。仅测试和仅文档编辑不会占用 Docker worker。它的 QR 包 smoke 会强制 Docker 的 `pnpm install` 层重新运行，同时保留 BuildKit 的 pnpm store 缓存，因此它仍然能测试安装过程，而不必在每次运行时重新下载依赖。它的 gateway-network e2e 会复用该作业中先前构建的运行时镜像，因此在不新增 Docker 构建的前提下增加了真实的容器到容器 WebSocket 覆盖。本地 `test:docker:all` 会预构建一个共享的 `scripts/e2e/Dockerfile` built-app 镜像，并在 E2E 容器 smoke 运行器之间复用它；可复用的 live/E2E 工作流也遵循相同模式，在 Docker 矩阵之前构建并推送一个带 SHA 标签的 GHCR Docker E2E 镜像，然后在设置了 `OPENCLAW_SKIP_DOCKER_BUILD=1` 的情况下运行该矩阵。QR 和安装器 Docker 测试保留了它们各自以安装为重点的 Dockerfile。另一个独立的 `docker-e2e-fast` 作业会在 120 秒命令超时限制下运行受限的 bundled-plugin Docker 配置：setup-entry 依赖修复加上 synthetic bundled-loader 故障隔离。完整的 bundled 更新/渠道矩阵仍然保留为手动/完整套件，因为它会重复执行真实的 npm update 和 doctor 修复流程。
+作用域逻辑位于 `scripts/ci-changed-scope.mjs`，并由 `src/scripts/ci-changed-scope.test.ts` 中的单元测试覆盖。
+CI 工作流编辑会验证 Node CI 作业图和工作流 lint，但不会仅因这些改动就强制触发 Windows、Android 或 macOS 原生构建；这些平台通道仍只针对平台源码变更生效。
+Windows Node 检查的作用域限定在 Windows 专用的进程/路径包装器、npm/pnpm/UI 运行器辅助工具、包管理器配置，以及执行该通道的 CI 工作流表面；无关的源码、插件、install-smoke 和仅测试变更仍保留在 Linux Node 通道中，这样就不会为了正常测试分片已经覆盖的内容而占用一个 16 vCPU 的 Windows worker。
+独立的 `install-smoke` 工作流通过它自己的 `preflight` 作业复用同一个作用域脚本。它根据更窄的 changed-smoke 信号计算 `run_install_smoke`，因此 Docker/install smoke 会在安装、打包、与容器相关的变更、内置扩展生产变更，以及 Docker smoke 作业所覆盖的 core plugin/channel/Gateway 网关/Plugin SDK 表面变更时运行。仅测试和仅文档编辑不会占用 Docker worker。它的 QR 包 smoke 会强制 Docker `pnpm install` 层重新运行，同时保留 BuildKit pnpm store cache，因此仍然会验证安装流程，而不必在每次运行时重新下载依赖。它的 gateway-network e2e 会复用该作业前面已构建的运行时镜像，因此在不增加另一轮 Docker 构建的情况下，增加了真实的容器到容器 WebSocket 覆盖。本地 `test:docker:all` 会预构建一个共享的 live-test 镜像，以及一个共享的 `scripts/e2e/Dockerfile` built-app 镜像，然后在 `OPENCLAW_SKIP_DOCKER_BUILD=1` 下并行运行 live/E2E smoke 通道；默认并发数为 4，可通过 `OPENCLAW_DOCKER_ALL_PARALLELISM` 调整。对启动或 provider 敏感的通道会在并行池之后独占运行。可复用的 live/E2E 工作流也遵循共享镜像模式：在 Docker 矩阵之前先构建并推送一个带 SHA 标签的 GHCR Docker E2E 镜像，然后在矩阵中以 `OPENCLAW_SKIP_DOCKER_BUILD=1` 运行。QR 和安装器 Docker 测试保留各自以安装为重点的 Dockerfile。另有一个单独的 `docker-e2e-fast` 作业，会在 120 秒命令超时下运行受限的内置插件 Docker 配置：setup-entry 依赖修复，以及 synthetic bundled-loader 故障隔离。完整的 bundled update/channel 矩阵仍然是手动/完整套件，因为它会反复执行真实的 npm update 和 doctor 修复流程。
 
-本地 changed-lane 逻辑位于 `scripts/changed-lanes.mjs` 中，并由 `scripts/check-changed.mjs` 执行。这个本地门禁在架构边界方面比宽泛的 CI 平台范围更严格：核心生产代码变更会运行 core prod typecheck 加 core tests，核心仅测试类变更只会运行 core test typecheck/tests，扩展生产代码变更会运行 extension prod typecheck 加 extension tests，而扩展仅测试类变更只会运行 extension test typecheck/tests。公共插件 SDK 或 plugin-contract 变更会扩大到扩展验证，因为扩展依赖这些核心契约。仅包含发布元数据的版本号变更会运行有针对性的 version/config/root-dependency 检查。未知的根目录/配置变更会安全地退回到所有通道。
+本地 changed-lane 逻辑位于 `scripts/changed-lanes.mjs`，由 `scripts/check-changed.mjs` 执行。这个本地门禁在架构边界方面比宽泛的 CI 平台作用域更严格：core 生产变更会运行 core 生产 typecheck 加 core 测试，core 仅测试变更只会运行 core 测试 typecheck/测试，扩展生产变更会运行扩展生产 typecheck 加扩展测试，而扩展仅测试变更只会运行扩展测试 typecheck/测试。公开的 Plugin SDK 或 plugin-contract 变更会扩大到扩展验证，因为扩展依赖这些 core 契约。仅有发布元数据的版本号变更会运行有针对性的版本/配置/root 依赖检查。未知的 root/配置变更会以安全优先方式落到所有通道。
 
-在 push 上，`checks` 矩阵会增加仅在 push 上运行的 `compat-node22` 通道。在拉取请求上，这个通道会被跳过，矩阵只聚焦于常规测试/渠道通道。
+在 push 上，`checks` 矩阵会增加仅 push 运行的 `compat-node22` 通道。在拉取请求中，该通道会被跳过，矩阵则保持聚焦于常规测试/渠道通道。
 
-最慢的 Node 测试族已被拆分或平衡，因此每个作业都保持较小规模：渠道契约将注册表和核心覆盖拆分为总计六个加权分片，bundled plugin 测试在六个扩展 worker 间平衡分布，auto-reply 以三个平衡 worker 运行，而不是六个过小的 worker，agentic Gateway 网关/plugin 配置则分散到现有的仅源码 agentic Node 作业中，而不是等待已构建产物。广泛的浏览器、QA、媒体和杂项 plugin 测试使用各自专用的 Vitest 配置，而不是共享的 plugin 通用配置。广泛的 agents 通道使用共享的 Vitest 文件并行调度器，因为它主要受导入/调度影响，而不是由某个单独的慢测试文件主导。`runtime-config` 与 infra core-runtime 分片一起运行，以避免共享运行时分片承担尾部耗时。`check-additional` 会把 package-boundary compile/canary 工作放在一起，并将运行时拓扑架构与 gateway watch 覆盖分开；边界守卫分片会在一个作业内并发运行其较小且彼此独立的守卫。Gateway 网关 watch、渠道测试以及 core support-boundary 分片会在 `dist/` 和 `dist-runtime/` 已构建完成后，在 `build-artifacts` 内并发运行，保留它们原有的检查名称作为轻量校验作业，同时避免额外占用两个 Blacksmith worker 和第二个产物消费者队列。
-Android CI 会同时运行 `testPlayDebugUnitTest` 和 `testThirdPartyDebugUnitTest`，然后构建 Play debug APK。third-party flavor 没有单独的 source set 或 manifest；它的单元测试通道仍会使用 SMS/通话日志 BuildConfig 标志编译该 flavor，同时避免在每次与 Android 相关的 push 上重复执行 debug APK 打包作业。
-`extension-fast` 仅在 PR 上运行，因为 push 已经会执行完整的 bundled plugin 分片。这样既能为评审提供已变更 plugin 的反馈，也不会在 `main` 上为 `checks-node-extensions` 已经覆盖的内容额外占用一个 Blacksmith worker。
+最慢的 Node 测试族已被拆分或平衡，以保持每个作业都足够小：渠道契约把 registry 和 core 覆盖拆成总共六个带权重的分片，内置插件测试在六个扩展 worker 之间平衡，自动回复以三个平衡 worker 运行而不是六个很小的 worker，而 agentic Gateway 网关/plugin 配置会分散到现有的仅源码 agentic Node 作业中，而不是等待已构建产物。宽泛的浏览器、QA、媒体和杂项插件测试使用各自专用的 Vitest 配置，而不是共享的插件兜底配置。宽泛的智能体通道使用共享的 Vitest 文件级并行调度器，因为它受导入/调度主导，而不是由单个慢测试文件主导。`runtime-config` 与 infra core-runtime 分片一起运行，以避免共享运行时分片独自承担尾部耗时。`check-additional` 将 package-boundary compile/canary 工作放在一起，并把运行时拓扑架构与 gateway watch 覆盖分开；边界防护分片会在单个作业内部并发运行其小型独立防护。Gateway watch、渠道测试以及 core support-boundary 分片会在 `dist/` 和 `dist-runtime/` 已构建完成后，在 `build-artifacts` 内部并发运行；这样既保留了它们原有的检查名称作为轻量校验作业，又避免了额外两个 Blacksmith worker 和第二个产物消费者队列。
+Android CI 会同时运行 `testPlayDebugUnitTest` 和 `testThirdPartyDebugUnitTest`，然后构建 Play debug APK。第三方 flavor 没有单独的 source set 或 manifest；它的单元测试通道仍会带着 SMS/通话日志 BuildConfig 标志编译该 flavor，同时避免在每次与 Android 相关的 push 上重复执行一个 debug APK 打包作业。
+`extension-fast` 仅在 PR 上运行，因为 push 运行已经会执行完整的内置插件分片。这样可以为代码审查提供已变更插件的反馈，同时不会在 `main` 上为 `checks-node-extensions` 已经覆盖的内容额外占用一个 Blacksmith worker。
 
-当同一个 PR 或 `main` 引用上有新的 push 到达时，GitHub 可能会将被替代的作业标记为 `cancelled`。除非同一引用的最新运行也失败，否则应将其视为 CI 噪声。聚合分片检查使用 `!cancelled() && always()`，因此它们仍会报告正常的分片失败，但不会在整个工作流已经被替代后继续排队。
-CI 并发键已进行版本化（`CI-v7-*`），因此 GitHub 侧旧队列组中的僵尸任务不会无限期阻塞较新的 main 运行。
+当同一 PR 或 `main` ref 上有更新的 push 到来时，GitHub 可能会将被替代的作业标记为 `cancelled`。除非同一 ref 的最新运行也失败，否则请将其视为 CI 噪声。聚合分片检查使用 `!cancelled() && always()`，因此它们仍会正常报告分片失败，但不会在整个工作流已经被替代后继续排队。
+CI 并发键已版本化为 `CI-v7-*`，这样 GitHub 端旧队列组中的僵尸任务就不会无限期阻塞较新的 main 运行。
 
 ## 运行器
 
 | 运行器 | 作业 |
 | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `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 测试分片、bundled plugin 测试分片、`android` |
-| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`，它仍然对 CPU 足够敏感，以至于 8 vCPU 节省下来的成本不如带来的损失；`install-smoke` 的 Docker 构建，其中 32 vCPU 的排队时间带来的成本不如收益 |
+| `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、自动响应；`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-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` |
@@ -83,18 +83,18 @@ CI 并发键已进行版本化（`CI-v7-*`），因此 GitHub 侧旧队列组中
 ## 本地等效命令
 
 ```bash
-pnpm changed:lanes   # 检查针对 origin/main...HEAD 的本地 changed-lane 分类器
-pnpm check:changed   # 智能本地门禁：按边界通道运行变更范围内的 typecheck/lint/tests
-pnpm check          # 快速本地门禁：生产 tsgo + 分片 lint + 并行快速守卫
+pnpm changed:lanes   # 检查 origin/main...HEAD 的本地 changed-lane 分类器
+pnpm check:changed   # 智能本地门禁：按边界通道运行变更相关的 typecheck/lint/测试
+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 check:docs     # 文档格式化 + lint + 失效链接检查
+pnpm build          # 当 CI 产物/build-smoke 通道相关时，构建 dist
 node scripts/ci-run-timings.mjs <run-id>  # 汇总总耗时、排队时间和最慢的作业
 ```

docs/zh-CN/reference/test.md

@@ -1,50 +1,51 @@
 ---
 read_when:
     - 运行或修复测试
-summary: 如何在本地运行测试（`vitest`），以及何时使用 `force` / `coverage` 模式
+summary: 如何在本地运行测试（vitest），以及何时使用 force/coverage 模式
 title: 测试
 x-i18n:
-    generated_at: "2026-04-21T21:27:19Z"
+    generated_at: "2026-04-23T13:33:17Z"
     model: gpt-5.4
     provider: openai
-    source_hash: ed665840ef2c7728da8ec923eb3ea2878d9b20a841cb2fe4116a7f6334567b8e
+    source_hash: 2897f6a58720b43c749dc7ea410369a529bb8f72c50f8d9e55f114bf39ccb1a9
     source_path: reference/test.md
     workflow: 15
 ---
 
 # 测试
 
-- 完整测试工具集（测试套件、live、Docker）：[测试](/zh-CN/help/testing)
+- 完整测试工具包（测试套件、实时、Docker）：[测试](/zh-CN/help/testing)
 
-- `pnpm test:force`：终止任何仍在占用默认控制端口的残留 Gateway 网关进程，然后使用隔离的 Gateway 网关端口运行完整的 Vitest 测试套件，这样服务器测试就不会与正在运行的实例冲突。当之前的 Gateway 网关运行导致端口 `18789` 仍被占用时，请使用这个命令。
-- `pnpm test:coverage`：通过 V8 覆盖率运行单元测试套件（经由 `vitest.unit.config.ts`）。这是一个针对已加载文件的单元覆盖率门禁，不是针对整个仓库所有文件的覆盖率。阈值为：行数 / 函数 / 语句覆盖率 70%，分支覆盖率 55%。由于 `coverage.all` 为 false，这个门禁衡量的是单元覆盖率测试套件中已加载的文件，而不是把每个拆分测试通道中的源文件都视为未覆盖。
-- `pnpm test:coverage:changed`：仅对自 `origin/main` 以来变更的文件运行单元覆盖率。
-- `pnpm test:changed`：当 diff 只涉及可路由的源码 / 测试文件时，会将变更的 Git 路径展开为有作用域的 Vitest 测试通道。配置 / 设置变更仍会回退到原生 root projects 运行，以便在需要时对 wiring 变更进行更广泛的重跑。
-- `pnpm changed:lanes`：显示相对于 `origin/main` 的 diff 所触发的架构通道。
-- `pnpm check:changed`：针对相对于 `origin/main` 的 diff 运行智能变更门禁。它会将核心改动与核心测试通道一起运行，将扩展改动与扩展测试通道一起运行，将仅测试改动限制为仅测试类型检查 / 测试，并将公开的插件 SDK 或插件契约变更扩展到扩展验证，同时让仅发布元数据的版本变更保留为有针对性的版本 / 配置 / 根依赖检查。
-- `pnpm test`：通过有作用域的 Vitest 测试通道路由显式的文件 / 目录目标。未指定目标的运行会使用固定分片组，并展开为叶子配置以进行本地并行执行；扩展组始终会展开为按扩展划分的分片配置，而不是一个巨大的 root-project 进程。
-- 完整运行和扩展分片运行会更新 `.artifacts/vitest-shard-timings.json` 中的本地时序数据；后续运行会利用这些时序来平衡慢分片和快分片。设置 `OPENCLAW_TEST_PROJECTS_TIMINGS=0` 可忽略该本地时序产物。
-- 选定的 `plugin-sdk` 和 `commands` 测试文件现在会通过专用的轻量通道路由，这些通道只保留 `test/setup.ts`，而运行时负担较重的用例仍保留在原有通道上。
-- 选定的 `plugin-sdk` 和 `commands` 辅助源码文件也会将 `pnpm test:changed` 映射到这些轻量通道中的显式同级测试，因此小型辅助文件编辑无需重新运行依赖重运行时的重型测试套件。
-- `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`：使用 V8 覆盖率运行单元测试套件（通过 `vitest.unit.config.ts`）。这是一个针对已加载文件的单元覆盖率门禁，而不是整个仓库所有文件的覆盖率。阈值为：行数 / 函数 / 语句 70%，分支 55%。由于 `coverage.all` 为 false，该门禁会统计被单元覆盖率套件加载的文件，而不是将每个拆分测试通道中的源文件都视为未覆盖。
+- `pnpm test:coverage:changed`：仅针对自 `origin/main` 以来发生变更的文件运行单元覆盖率。
+- `pnpm test:changed`：当差异只涉及可路由的源文件 / 测试文件时，会将变更过的 git 路径展开为有范围限制的 Vitest 通道。配置 / 设置变更仍会回退到原生根项目运行方式，因此在需要时，接线层修改会触发更广泛的重跑。
+- `pnpm changed:lanes`：显示相对于 `origin/main` 的差异所触发的架构通道。
+- `pnpm check:changed`：针对相对于 `origin/main` 的差异运行智能变更门禁。它会将核心改动与核心测试通道一起运行，将扩展改动与扩展测试通道一起运行，将仅测试改动限制为测试类型检查 / 测试本身，将公开的插件 SDK 或插件契约变更扩展为扩展验证，并将仅发布元数据的版本号变更限制在有针对性的版本 / 配置 / 根依赖检查上。
+- `pnpm test`：通过有范围限制的 Vitest 通道来路由显式指定的文件 / 目录目标。未指定目标的运行会使用固定的分片组，并展开到叶子配置，以便在本地并行执行；扩展组始终会展开为按扩展划分的分片配置，而不是单个巨大的根项目进程。
+- 完整测试和扩展分片运行会更新 `.artifacts/vitest-shard-timings.json` 中的本地计时数据；后续运行会使用这些计时信息来平衡慢分片和快分片。设置 `OPENCLAW_TEST_PROJECTS_TIMINGS=0` 可忽略本地计时产物。
+- 部分 `plugin-sdk` 和 `commands` 测试文件现在会通过专用轻量通道进行路由，这些通道只保留 `test/setup.ts`，而运行时负载较重的用例仍保留在原有通道中。
+- 部分 `plugin-sdk` 和 `commands` 辅助源文件也会将 `pnpm test:changed` 映射到这些轻量通道中的显式同级测试，因此对小型辅助文件的修改可以避免重跑依赖重型运行时的测试套件。
+- `auto-reply` 现在也拆分为三个专用配置（`core`、`top-level`、`reply`），因此 reply 测试框架不会拖慢较轻量的顶层状态 / token / helper 测试。
+- 基础 Vitest 配置现在默认使用 `pool: "threads"` 和 `isolate: false`，并在整个仓库配置中启用了共享的非隔离运行器。
 - `pnpm test:channels` 运行 `vitest.channels.config.ts`。
-- `pnpm test:extensions` 和 `pnpm test extensions` 运行所有扩展 / 插件分片。重量级渠道扩展和 OpenAI 会作为专用分片运行；其他扩展组保持批量处理。对单个内置插件通道使用 `pnpm test extensions/<id>`。
-- `pnpm test:perf:imports`：启用 Vitest 导入耗时 + 导入明细报告，同时仍对显式文件 / 目录目标使用有作用域的通道路由。
-- `pnpm test:perf:imports:changed`：相同的导入性能分析，但仅针对自 `origin/main` 以来变更的文件。
-- `pnpm test:perf:changed:bench -- --ref <git-ref>`：针对相同的已提交 Git diff，将已路由的 changed 模式路径与原生 root-project 运行进行基准对比。
-- `pnpm test:perf:changed:bench -- --worktree`：无需先提交，即可对当前工作树变更集进行基准测试。
+- `pnpm test:extensions` 和 `pnpm test extensions` 会运行所有扩展 / 插件分片。重量级渠道扩展和 OpenAI 会作为专用分片运行；其他扩展组则保持批量运行。对单个内置插件通道，请使用 `pnpm test extensions/<id>`。
+- `pnpm test:perf:imports`：启用 Vitest 的导入耗时 + 导入明细报告，同时仍对显式指定的文件 / 目录目标使用有范围限制的通道路由。
+- `pnpm test:perf:imports:changed`：与上面相同的导入分析，但仅针对自 `origin/main` 以来发生变更的文件。
+- `pnpm test:perf:changed:bench -- --ref <git-ref>`：对已路由的 changed 模式路径与原生根项目运行进行基准比较，两者使用相同的已提交 git 差异。
+- `pnpm test:perf:changed:bench -- --worktree`：对当前工作区的变更集进行基准比较，无需先提交。
 - `pnpm test:perf:profile:main`：为 Vitest 主线程写入 CPU profile（`.artifacts/vitest-main-profile`）。
-- `pnpm test:perf:profile:runner`：为单元测试运行器写入 CPU + heap profile（`.artifacts/vitest-runner-profile`）。
-- Gateway 网关集成测试：通过 `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` 或 `pnpm test:gateway` 显式启用。
-- `pnpm test:e2e`：运行 Gateway 网关端到端冒烟测试（多实例 WS / HTTP / 节点配对）。在 `vitest.e2e.config.ts` 中默认使用 `threads` + `isolate: false` 和自适应 worker；可通过 `OPENCLAW_E2E_WORKERS=<n>` 调整，并设置 `OPENCLAW_E2E_VERBOSE=1` 以输出详细日志。
-- `pnpm test:live`：运行提供商 live 测试（minimax / zai）。需要 API 密钥，并设置 `LIVE=1`（或提供商特定的 `*_LIVE_TEST=1`）才会取消跳过。
-- `pnpm test:docker:openwebui`：启动 Docker 化的 OpenClaw + Open WebUI，通过 Open WebUI 登录，检查 `/api/models`，然后通过 `/api/chat/completions` 运行一次真实的代理聊天。需要可用的 live 模型密钥（例如 `~/.profile` 中的 OpenAI），会拉取外部 Open WebUI 镜像，并不像常规单元 / e2e 测试套件那样预期具有 CI 稳定性。
-- `pnpm test:docker:mcp-channels`：启动一个预置数据的 Gateway 网关容器和第二个客户端容器，后者会启动 `openclaw mcp serve`，然后通过真实的 stdio bridge 验证路由会话发现、转录读取、附件元数据、live 事件队列行为、出站发送路由，以及类 Claude 风格的渠道 + 权限通知。Claude 通知断言会直接读取原始 stdio MCP 帧，因此这个冒烟测试反映的是 bridge 实际发出的内容。
+- `pnpm test:perf:profile:runner`：为单元测试运行器写入 CPU + 堆 profile（`.artifacts/vitest-runner-profile`）。
+- Gateway 网关集成：通过 `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` 或 `pnpm test:gateway` 选择性启用。
+- `pnpm test:e2e`：运行 Gateway 网关端到端冒烟测试（多实例 WS/HTTP/node 配对）。在 `vitest.e2e.config.ts` 中默认使用 `threads` + `isolate: false` 与自适应 worker；可通过 `OPENCLAW_E2E_WORKERS=<n>` 调整，并设置 `OPENCLAW_E2E_VERBOSE=1` 以输出详细日志。
+- `pnpm test:live`：运行提供商实时测试（minimax/zai）。需要 API key，并且需要设置 `LIVE=1`（或提供商专用的 `*_LIVE_TEST=1`）来取消跳过。
+- `pnpm test:docker:all`：先各构建一次共享的实时测试镜像和 Docker E2E 镜像，然后默认以并发数 4 运行 Docker 冒烟测试通道，并设置 `OPENCLAW_SKIP_DOCKER_BUILD=1`。可通过 `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` 调整。对启动流程或提供商更敏感的通道会在并行池之后独占运行。每个通道的日志会写入 `.artifacts/docker-tests/<run-id>/`。
+- `pnpm test:docker:openwebui`：启动 Docker 化的 OpenClaw + Open WebUI，通过 Open WebUI 登录，检查 `/api/models`，然后通过 `/api/chat/completions` 运行一次真实的代理聊天。需要可用的实时模型 key（例如 `~/.profile` 中的 OpenAI），会拉取外部 Open WebUI 镜像，并且不像常规单元 / e2e 测试套件那样预期具有 CI 稳定性。
+- `pnpm test:docker:mcp-channels`：启动一个已注入种子数据的 Gateway 网关容器，以及第二个会生成 `openclaw mcp serve` 的客户端容器，然后通过真实的 stdio bridge 验证路由会话发现、转录读取、附件元数据、实时事件队列行为、出站发送路由，以及 Claude 风格的渠道 + 权限通知。Claude 通知断言会直接读取原始 stdio MCP 帧，因此该冒烟测试反映的是 bridge 实际发出的内容。
 
 ## 本地 PR 门禁
 
-在本地进行 PR 合并 / 门禁检查时，运行：
+在本地执行 PR 合并 / 门禁检查时，请运行：
 
 - `pnpm check:changed`
 - `pnpm check`
@@ -53,12 +54,12 @@ x-i18n:
 - `pnpm test`
 - `pnpm check:docs`
 
-如果 `pnpm test` 在高负载主机上出现偶发失败，在将其视为回归之前先重跑一次，然后用 `pnpm test <path/to/test>` 进行定位。对于内存受限的主机，使用：
+如果 `pnpm test` 在负载较高的主机上偶发失败，请先重跑一次，再将其视为回归；然后使用 `pnpm test <path/to/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)
 
@@ -66,12 +67,12 @@ 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 次）：
 
-- minimax 中位数 1279 ms（最小 1114，最大 2431）
-- opus 中位数 2454 ms（最小 1224，最大 3170）
+- minimax 中位数 1279ms（最小 1114，最大 2431）
+- opus 中位数 2454ms（最小 1224，最大 3170）
 
 ## CLI 启动基准测试
 
@@ -98,17 +99,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、最小 / 最大值、退出码 / signal 分布，以及最大 RSS 汇总。可选的 `--cpu-prof-dir` / `--heap-prof-dir` 会为每次运行写入 V8 profile，因此计时和 profile 捕获使用的是同一个 harness。
+输出内容包括每个命令的 `sampleCount`、平均值、p50、p95、最小值 / 最大值、exit-code/signal 分布，以及最大 RSS 汇总。可选的 `--cpu-prof-dir` / `--heap-prof-dir` 会为每次运行写入 V8 profile，因此计时和 profile 采集使用的是同一个测试框架。
 
 保存输出约定：
 
-- `pnpm test:startup:bench:smoke` 会将定向冒烟产物写入 `.artifacts/cli-startup-bench-smoke.json`
+- `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: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` 刷新
@@ -116,19 +117,19 @@ x-i18n:
 
 ## 新手引导 E2E（Docker）
 
-Docker 是可选的；只有在进行容器化的新手引导冒烟测试时才需要它。
+Docker 是可选的；只有在需要容器化新手引导冒烟测试时才需要它。
 
-在干净的 Linux 容器中的完整冷启动流程：
+在干净的 Linux 容器中执行完整冷启动流程：
 
 ```bash
 scripts/e2e/onboard-docker.sh
 ```
 
-这个脚本会通过伪终端驱动交互式向导，验证 config / workspace / session 文件，然后启动 Gateway 网关并运行 `openclaw health`。
+该脚本会通过 pseudo-tty 驱动交互式向导，验证 config/workspace/session 文件，然后启动 Gateway 网关并运行 `openclaw health`。
 
 ## QR 导入冒烟测试（Docker）
 
-确保 `qrcode-terminal` 能在受支持的 Docker Node 运行时中加载（默认 Node 24，兼容 Node 22）：
+确保 `qrcode-terminal` 能在受支持的 Docker Node 运行时下加载（默认 Node 24，兼容 Node 22）：
 
 ```bash
 pnpm test:docker:qr

docs/zh-CN/tools/plugin.md

@@ -1,32 +1,28 @@
 ---
 read_when:
     - 安装或配置插件
-    - 了解插件发现与加载规则
+    - 了解插件发现和加载规则
     - 使用与 Codex/Claude 兼容的插件包
 sidebarTitle: Install and Configure
-summary: 安装、配置和管理 OpenClaw 插件
-title: Plugins
+summary: 安装、配置并管理 OpenClaw 插件
+title: 插件
 x-i18n:
-    generated_at: "2026-04-23T06:43:53Z"
+    generated_at: "2026-04-23T13:33:18Z"
     model: gpt-5.4
     provider: openai
-    source_hash: dc944b53654552ca5cf6132c6ef16c71745a7bffc249daccaee40c513e04209c
+    source_hash: 63aa1b5ed9e3aaa2117b78137a457582b00ea47d94af7da3780ddae38e8e3665
     source_path: tools/plugin.md
     workflow: 15
 ---
 
-# Plugins
+# 插件
 
-Plugins 为 OpenClaw 扩展新能力：渠道、模型提供商、
-工具、Skills、语音、实时转录、实时语音、
-媒体理解、图像生成、视频生成、网页抓取、网页
-搜索等。有些插件是**核心**插件（随 OpenClaw 一起发布），另一些
-是**外部**插件（由社区发布到 npm）。
+插件可为 OpenClaw 扩展新能力：渠道、模型提供商、工具、Skills、语音、实时转写、实时语音、媒体理解、图像生成、视频生成、网页抓取、网页搜索等。有些插件是 **核心** 插件（随 OpenClaw 一起提供），另一些是 **外部** 插件（由社区发布到 npm）。
 
 ## 快速开始
 
 <Steps>
-  <Step title="查看已加载内容">
+  <Step title="查看已加载的内容">
     ```bash
     openclaw plugins list
     ```
@@ -34,10 +30,10 @@ Plugins 为 OpenClaw 扩展新能力：渠道、模型提供商、
 
   <Step title="安装插件">
     ```bash
-    # 从 npm
+    # 从 npm 安装
     openclaw plugins install @openclaw/voice-call
 
-    # 从本地目录或归档文件
+    # 从本地目录或归档文件安装
     openclaw plugins install ./my-plugin
     openclaw plugins install ./my-plugin.tgz
     ```
@@ -49,12 +45,12 @@ Plugins 为 OpenClaw 扩展新能力：渠道、模型提供商、
     openclaw gateway restart
     ```
 
-    然后在你的配置文件中通过 `plugins.entries.\<id\>.config` 进行配置。
+    然后在你的配置文件中，通过 `plugins.entries.\<id\>.config` 进行配置。
 
   </Step>
 </Steps>
 
-如果你更喜欢原生聊天控制，请启用 `commands.plugins: true` 并使用：
+如果你更喜欢以聊天原生方式控制，可启用 `commands.plugins: true` 并使用：
 
 ```text
 /plugin install clawhub:@openclaw/voice-call
@@ -62,20 +58,16 @@ Plugins 为 OpenClaw 扩展新能力：渠道、模型提供商、
 /plugin enable voice-call
 ```
 
-安装路径使用与 CLI 相同的解析器：本地路径/归档、显式
-`clawhub:<pkg>`，或裸包规范（优先 ClawHub，然后回退到 npm）。
+安装路径使用与 CLI 相同的解析器：本地路径/归档文件、显式 `clawhub:<pkg>`，或裸包规范（优先 ClawHub，随后回退到 npm）。
 
-如果配置无效，安装通常会默认失败关闭，并提示你运行
-`openclaw doctor --fix`。唯一的恢复例外是一个较窄的内置插件
-重装路径，适用于选择加入
-`openclaw.install.allowInvalidConfigRecovery` 的插件。
+如果配置无效，安装通常会以安全失败方式结束，并提示你运行
+`openclaw doctor --fix`。唯一的恢复例外，是为选择启用
+`openclaw.install.allowInvalidConfigRecovery`
+的插件提供的一条有限的内置插件重装路径。
 
-打包版 OpenClaw 安装不会急切安装每个内置插件的
-运行时依赖树。当某个 OpenClaw 自有的内置插件因
-插件配置、旧版渠道配置或默认启用的 manifest 而处于激活状态时，
-启动修复只会在导入该插件前修复它声明的运行时依赖。
-外部插件和自定义加载路径仍然必须通过
-`openclaw plugins install` 安装。
+打包后的 OpenClaw 安装不会预先安装每个内置插件的完整运行时依赖树。当某个 OpenClaw 自带的内置插件通过插件配置、旧版渠道配置或默认启用的清单处于活动状态时，启动修复只会在导入该插件之前修复它所声明的运行时依赖。外部插件和自定义加载路径仍必须通过
+`openclaw plugins install`
+安装。
 
 ## 插件类型
 
@@ -86,9 +78,9 @@ OpenClaw 可识别两种插件格式：
 | **原生** | `openclaw.plugin.json` + 运行时模块；在进程内执行 | 官方插件、社区 npm 包 |
 | **Bundle** | 与 Codex/Claude/Cursor 兼容的布局；映射到 OpenClaw 功能 | `.codex-plugin/`、`.claude-plugin/`、`.cursor-plugin/` |
 
-两者都会显示在 `openclaw plugins list` 中。有关 Bundle 的详细信息，请参阅 [Plugin Bundles](/zh-CN/plugins/bundles)。
+两者都会显示在 `openclaw plugins list` 中。有关 bundle 的详细信息，请参阅 [插件 Bundle](/zh-CN/plugins/bundles)。
 
-如果你在编写原生插件，请从 [Building Plugins](/zh-CN/plugins/building-plugins)
+如果你要编写原生插件，请从 [构建插件](/zh-CN/plugins/building-plugins)
 和 [插件 SDK 概览](/zh-CN/plugins/sdk-overview) 开始。
 
 ## 官方插件
@@ -97,14 +89,14 @@ OpenClaw 可识别两种插件格式：
 
 | 插件 | 包 | 文档 |
 | --------------- | ---------------------- | ------------------------------------ |
-| Matrix          | `@openclaw/matrix`     | [Matrix](/zh-CN/channels/matrix)           |
-| Microsoft Teams | `@openclaw/msteams`    | [Microsoft Teams](/zh-CN/channels/msteams) |
-| Nostr           | `@openclaw/nostr`      | [Nostr](/zh-CN/channels/nostr)             |
-| Voice Call      | `@openclaw/voice-call` | [Voice Call](/zh-CN/plugins/voice-call)    |
-| Zalo            | `@openclaw/zalo`       | [Zalo](/zh-CN/channels/zalo)               |
-| Zalo Personal   | `@openclaw/zalouser`   | [Zalo Personal](/zh-CN/plugins/zalouser)   |
+| Matrix | `@openclaw/matrix` | [Matrix](/zh-CN/channels/matrix) |
+| Microsoft Teams | `@openclaw/msteams` | [Microsoft Teams](/zh-CN/channels/msteams) |
+| Nostr | `@openclaw/nostr` | [Nostr](/zh-CN/channels/nostr) |
+| Voice Call | `@openclaw/voice-call` | [Voice Call](/zh-CN/plugins/voice-call) |
+| Zalo | `@openclaw/zalo` | [Zalo](/zh-CN/channels/zalo) |
+| Zalo Personal | `@openclaw/zalouser` | [Zalo Personal](/zh-CN/plugins/zalouser) |
 
-### 核心（随 OpenClaw 一起发布）
+### 核心（随 OpenClaw 一起提供）
 
 <AccordionGroup>
   <Accordion title="模型提供商（默认启用）">
@@ -115,9 +107,9 @@ OpenClaw 可识别两种插件格式：
     `vercel-ai-gateway`, `volcengine`, `xiaomi`, `zai`
   </Accordion>
 
-  <Accordion title="Memory 插件">
-    - `memory-core` — 内置的 Memory 搜索（默认通过 `plugins.slots.memory`）
-    - `memory-lancedb` — 按需安装的长期 Memory，带自动召回/捕获（设置 `plugins.slots.memory = "memory-lancedb"`）
+  <Accordion title="内存插件">
+    - `memory-core` — 内置内存搜索（通过 `plugins.slots.memory` 默认启用）
+    - `memory-lancedb` — 按需安装的长期记忆，支持自动回忆/捕获（设置 `plugins.slots.memory = "memory-lancedb"`）
   </Accordion>
 
   <Accordion title="语音提供商（默认启用）">
@@ -125,12 +117,12 @@ OpenClaw 可识别两种插件格式：
   </Accordion>
 
   <Accordion title="其他">
-    - `browser` — 用于 browser 工具、`openclaw browser` CLI、`browser.request` Gateway 网关方法、browser 运行时以及默认 browser 控制服务的内置 browser 插件（默认启用；替换前请先禁用）
-    - `copilot-proxy` — VS Code Copilot Proxy bridge（默认禁用）
+    - `browser` — 内置浏览器插件，用于浏览器工具、`openclaw browser` CLI、`browser.request` Gateway 网关方法、浏览器运行时以及默认浏览器控制服务（默认启用；替换前请先禁用）
+    - `copilot-proxy` — VS Code Copilot Proxy 桥接（默认禁用）
   </Accordion>
 </AccordionGroup>
 
-想找第三方插件？请参阅 [Community Plugins](/zh-CN/plugins/community)。
+在找第三方插件？请参阅 [社区插件](/zh-CN/plugins/community)。
 
 ## 配置
 
@@ -148,28 +140,26 @@ OpenClaw 可识别两种插件格式：
 }
 ```
 
-| 字段 | 说明 |
+| 字段 | 描述 |
 | ---------------- | --------------------------------------------------------- |
 | `enabled` | 主开关（默认：`true`） |
 | `allow` | 插件允许列表（可选） |
 | `deny` | 插件拒绝列表（可选；拒绝优先） |
 | `load.paths` | 额外的插件文件/目录 |
-| `slots` | 排他性 slot 选择器（例如 `memory`、`contextEngine`） |
-| `entries.\<id\>` | 按插件的开关 + 配置 |
+| `slots` | 独占插槽选择器（例如 `memory`、`contextEngine`） |
+| `entries.\<id\>` | 每个插件的开关 + 配置 |
 
-配置变更**需要重启 Gateway 网关**。如果 Gateway 网关以配置
-监听 + 进程内重启方式运行（默认的 `openclaw gateway` 路径），那么
-配置写入落地后通常会在短时间内自动执行该重启。
+配置更改**需要重启 Gateway 网关**。如果 Gateway 网关以启用配置监视和进程内重启的方式运行（默认的 `openclaw gateway` 路径），则在配置写入后不久，通常会自动执行该重启。
 
 <Accordion title="插件状态：已禁用 vs 缺失 vs 无效">
   - **已禁用**：插件存在，但启用规则将其关闭。配置会被保留。
-  - **缺失**：配置引用了某个插件 id，但在发现阶段未找到。
-  - **无效**：插件存在，但其配置与声明的 schema 不匹配。
+  - **缺失**：配置引用了某个插件 ID，但设备发现未找到该插件。
+  - **无效**：插件存在，但其配置不匹配声明的 schema。
 </Accordion>
 
-## 发现与优先级
+## 发现顺序与优先级
 
-OpenClaw 按以下顺序扫描插件（先匹配者胜出）：
+OpenClaw 按以下顺序扫描插件（先匹配者优先）：
 
 <Steps>
   <Step title="配置路径">
@@ -185,7 +175,7 @@ OpenClaw 按以下顺序扫描插件（先匹配者胜出）：
   </Step>
 
   <Step title="内置插件">
-    随 OpenClaw 一起发布。许多插件默认启用（模型提供商、语音）。
+    随 OpenClaw 一起提供。许多插件默认启用（模型提供商、语音）。
     其他插件则需要显式启用。
   </Step>
 </Steps>
@@ -195,44 +185,44 @@ OpenClaw 按以下顺序扫描插件（先匹配者胜出）：
 - `plugins.enabled: false` 会禁用所有插件
 - `plugins.deny` 始终优先于 allow
 - `plugins.entries.\<id\>.enabled: false` 会禁用该插件
-- 来自工作区的插件**默认禁用**（必须显式启用）
-- 内置插件遵循内建的默认开启集合，除非被覆盖
-- 排他性 slot 可以强制启用该 slot 所选中的插件
+- 来源于工作区的插件**默认禁用**（必须显式启用）
+- 内置插件遵循内建的默认启用集合，除非被覆盖
+- 独占插槽可强制启用该插槽中被选中的插件
 
-## 插件 slots（排他类别）
+## 插件插槽（独占类别）
 
-某些类别是排他的（同一时间只能有一个激活）：
+有些类别是独占的（同一时间只能有一个处于活动状态）：
 
 ```json5
 {
   plugins: {
     slots: {
-      memory: "memory-core", // 或 "none" 以禁用
+      memory: "memory-core", // 或使用 "none" 禁用
       contextEngine: "legacy", // 或某个插件 id
     },
   },
 }
 ```
 
-| Slot | 控制内容 | 默认值 |
+| 插槽 | 控制内容 | 默认值 |
 | --------------- | --------------------- | ------------------- |
-| `memory` | 当前激活的 Memory 插件 | `memory-core` |
-| `contextEngine` | 当前激活的上下文引擎 | `legacy`（内建） |
+| `memory` | 活动内存插件 | `memory-core` |
+| `contextEngine` | 活动上下文引擎 | `legacy`（内建） |
 
 ## CLI 参考
 
 ```bash
 openclaw plugins list                       # 紧凑清单
 openclaw plugins list --enabled            # 仅显示已加载插件
-openclaw plugins list --verbose            # 每个插件的详细行
+openclaw plugins list --verbose            # 每个插件的详细信息行
 openclaw plugins list --json               # 机器可读清单
 openclaw plugins inspect <id>              # 深度详情
 openclaw plugins inspect <id> --json       # 机器可读
 openclaw plugins inspect --all             # 全量表格
-openclaw plugins info <id>                 # inspect 别名
+openclaw plugins info <id>                 # inspect 的别名
 openclaw plugins doctor                    # 诊断
 
-openclaw plugins install <package>         # 安装（优先 ClawHub，然后 npm）
+openclaw plugins install <package>         # 安装（优先 ClawHub，随后 npm）
 openclaw plugins install clawhub:<pkg>     # 仅从 ClawHub 安装
 openclaw plugins install <spec> --force    # 覆盖现有安装
 openclaw plugins install <path>            # 从本地路径安装
@@ -244,7 +234,7 @@ openclaw plugins install <spec> --dangerously-force-unsafe-install
 openclaw plugins update <id-or-npm-spec> # 更新单个插件
 openclaw plugins update <id-or-npm-spec> --dangerously-force-unsafe-install
 openclaw plugins update --all            # 更新全部
-openclaw plugins uninstall <id>          # 移除配置/安装记录
+openclaw plugins uninstall <id>          # 删除配置/安装记录
 openclaw plugins uninstall <id> --keep-files
 openclaw plugins marketplace list <source>
 openclaw plugins marketplace list <source> --json
@@ -253,58 +243,38 @@ openclaw plugins enable <id>
 openclaw plugins disable <id>
 ```
 
-内置插件随 OpenClaw 一起发布。许多插件默认启用（例如
-内置模型提供商、内置语音提供商，以及内置 browser
-插件）。其他内置插件仍需要 `openclaw plugins enable <id>`。
+内置插件随 OpenClaw 一起提供。许多插件默认启用（例如内置模型提供商、内置语音提供商，以及内置浏览器插件）。其他内置插件仍然需要运行 `openclaw plugins enable <id>`。
 
-`--force` 会原地覆盖已安装的插件或 hook pack。对于已跟踪 npm
-插件的常规升级，请使用 `openclaw plugins update <id-or-npm-spec>`。
-它不支持与 `--link` 一起使用，因为 `--link` 会复用源路径，
-而不是复制到受管理的安装目标中。
+`--force` 会就地覆盖现有已安装的插件或 hook 包。对已跟踪的 npm
+插件进行常规升级时，请使用
+`openclaw plugins update <id-or-npm-spec>`。
+它不支持与 `--link` 一起使用，因为后者会复用源路径，而不是复制到受管的安装目标。
 
-`openclaw plugins update <id-or-npm-spec>` 适用于已跟踪的安装。传入
-带 dist-tag 或精确版本的 npm 包规范时，会将包名解析回
-已跟踪的插件记录，并记录新的规范用于后续更新。
-传入不带版本的包名时，会将精确 pin 的安装移回到
-注册表的默认发布线。如果已安装的 npm 插件已经匹配
-解析后的版本和记录的产物标识，OpenClaw 会跳过此次更新，
-不会下载、重装或重写配置。
+当已设置 `plugins.allow` 时，`openclaw plugins install` 会在启用插件之前，将已安装插件的 ID 添加到该允许列表中，因此重启后即可立即加载。
 
-`--pin` 仅适用于 npm。它不支持与 `--marketplace` 一起使用，因为
-marketplace 安装会持久化 marketplace 来源元数据，
-而不是 npm 规范。
+`openclaw plugins update <id-or-npm-spec>` 适用于已跟踪的安装。传入带有 dist-tag 或精确版本的 npm 包规范时，会把包名解析回已跟踪的插件记录，并记录新的规范以供后续更新。传入不带版本的包名时，会将一个精确固定版本的安装移回注册表的默认发布线。如果已安装的 npm 插件已经与解析后的版本和记录的制品标识匹配，OpenClaw 会跳过更新，不会下载、重新安装或重写配置。
 
-`--dangerously-force-unsafe-install` 是用于处理内置危险代码扫描器
-误报的紧急覆盖开关。它允许插件安装
-和插件更新在遇到内置 `critical` 发现后继续执行，但仍然
-不会绕过插件 `before_install` 策略阻止或扫描失败阻止。
+`--pin` 仅适用于 npm。它不支持与 `--marketplace` 一起使用，因为 marketplace 安装会持久化 marketplace 来源元数据，而不是 npm 规范。
 
-这个 CLI 标志只适用于插件 install/update 流程。由 Gateway 网关支持的 Skills
-依赖安装则使用匹配的 `dangerouslyForceUnsafeInstall` 请求覆盖；
-而 `openclaw skills install` 仍然是独立的 ClawHub Skills 下载/安装流程。
+`--dangerously-force-unsafe-install` 是一个用于紧急处理的覆盖开关，用于应对内置危险代码扫描器的误报。它允许插件安装和插件更新在遇到内置 `critical` 发现后继续执行，但仍不会绕过插件 `before_install` 策略拦截或扫描失败拦截。
 
-兼容的 Bundle 也参与同一套插件 list/inspect/enable/disable
-流程。当前运行时支持包括 Bundle Skills、Claude command-skills、
-Claude `settings.json` 默认值、Claude `.lsp.json` 和 manifest 声明的
-`lspServers` 默认值、Cursor command-skills，以及兼容的 Codex hook
-目录。
+这个 CLI 标志仅适用于插件安装/更新流程。由 Gateway 网关支持的 Skills 依赖安装则使用对应的 `dangerouslyForceUnsafeInstall` 请求覆盖；而 `openclaw skills install` 仍是单独的 ClawHub Skills 下载/安装流程。
 
-`openclaw plugins inspect <id>` 还会报告检测到的 Bundle 能力，
-以及由 Bundle 支持的插件中受支持或不受支持的 MCP 和 LSP server 条目。
+兼容的 bundle 参与同一套插件 list/inspect/enable/disable 流程。当前运行时支持包括 bundle Skills、Claude command-skills、Claude `settings.json` 默认值、Claude `.lsp.json` 和清单声明的 `lspServers` 默认值、Cursor command-skills，以及兼容的 Codex hook 目录。
 
-Marketplace 来源可以是来自
-`~/.claude/plugins/known_marketplaces.json` 的 Claude 已知 marketplace 名称、本地 marketplace 根目录或
-`marketplace.json` 路径、如 `owner/repo` 这样的 GitHub 简写、GitHub 仓库
-URL，或 git URL。对于远程 marketplace，插件条目必须保留在
-克隆的 marketplace 仓库内，并且只能使用相对路径来源。
+`openclaw plugins inspect <id>` 还会报告已检测到的 bundle 能力，以及由 bundle 支持的或不受支持的 MCP 和 LSP 服务器条目。
 
-完整详情参见 [`openclaw plugins` CLI 参考](/zh-CN/cli/plugins)。
+Marketplace 来源可以是 Claude 已知 marketplace 名称（来自
+`~/.claude/plugins/known_marketplaces.json`）、本地 marketplace 根目录或
+`marketplace.json` 路径、形如 `owner/repo` 的 GitHub 简写、GitHub 仓库
+URL，或 git URL。对于远程 marketplace，插件条目必须保留在已克隆的
+marketplace 仓库内，并且只能使用相对路径来源。
+
+有关完整详情，请参阅 [`openclaw plugins` CLI 参考](/zh-CN/cli/plugins)。
 
 ## 插件 API 概览
 
-原生插件会导出一个入口对象，并暴露 `register(api)`。旧版
-插件仍可能使用 `activate(api)` 作为旧版别名，但新插件应
-使用 `register`。
+原生插件会导出一个入口对象，该对象暴露 `register(api)`。较旧的插件可能仍使用 `activate(api)` 作为旧版别名，但新插件应使用 `register`。
 
 ```typescript
 export default definePluginEntry({
@@ -324,26 +294,24 @@ export default definePluginEntry({
 });
 ```
 
-OpenClaw 会加载该入口对象，并在插件激活期间调用 `register(api)`。
-对于旧版插件，加载器仍会回退到 `activate(api)`，
-但内置插件和新的外部插件应将 `register` 视为公共契约。
+OpenClaw 会加载该入口对象，并在插件激活期间调用 `register(api)`。对于较旧的插件，加载器仍会回退到 `activate(api)`，但内置插件和新的外部插件应将 `register` 视为公开契约。
 
-常见注册方法：
+常见的注册方法：
 
 | 方法 | 注册内容 |
 | --------------------------------------- | --------------------------- |
 | `registerProvider` | 模型提供商（LLM） |
 | `registerChannel` | 聊天渠道 |
 | `registerTool` | 智能体工具 |
-| `registerHook` / `on(...)` | 生命周期 hook |
+| `registerHook` / `on(...)` | 生命周期 hooks |
 | `registerSpeechProvider` | 文本转语音 / STT |
 | `registerRealtimeTranscriptionProvider` | 流式 STT |
-| `registerRealtimeVoiceProvider` | 双工实时语音 |
+| `registerRealtimeVoiceProvider` | 双向实时语音 |
 | `registerMediaUnderstandingProvider` | 图像/音频分析 |
 | `registerImageGenerationProvider` | 图像生成 |
 | `registerMusicGenerationProvider` | 音乐生成 |
 | `registerVideoGenerationProvider` | 视频生成 |
-| `registerWebFetchProvider` | 网页抓取 / 爬取提供商 |
+| `registerWebFetchProvider` | 网页抓取 / 抓取提供商 |
 | `registerWebSearchProvider` | 网页搜索 |
 | `registerHttpRoute` | HTTP 端点 |
 | `registerCommand` / `registerCli` | CLI 命令 |
@@ -352,20 +320,20 @@ OpenClaw 会加载该入口对象，并在插件激活期间调用 `register(api
 
 类型化生命周期 hook 的 guard 行为：
 
-- `before_tool_call`：`{ block: true }` 为终止结果；低优先级 handler 会被跳过。
-- `before_tool_call`：`{ block: false }` 为 no-op，不会清除更早的 block。
-- `before_install`：`{ block: true }` 为终止结果；低优先级 handler 会被跳过。
-- `before_install`：`{ block: false }` 为 no-op，不会清除更早的 block。
-- `message_sending`：`{ cancel: true }` 为终止结果；低优先级 handler 会被跳过。
-- `message_sending`：`{ cancel: false }` 为 no-op，不会清除更早的 cancel。
+- `before_tool_call`：`{ block: true }` 是终止性的；会跳过更低优先级的处理器。
+- `before_tool_call`：`{ block: false }` 是空操作，不会清除更早的 block。
+- `before_install`：`{ block: true }` 是终止性的；会跳过更低优先级的处理器。
+- `before_install`：`{ block: false }` 是空操作，不会清除更早的 block。
+- `message_sending`：`{ cancel: true }` 是终止性的；会跳过更低优先级的处理器。
+- `message_sending`：`{ cancel: false }` 是空操作，不会清除更早的 cancel。
 
 有关完整的类型化 hook 行为，请参阅 [SDK 概览](/zh-CN/plugins/sdk-overview#hook-decision-semantics)。
 
 ## 相关内容
 
-- [Building Plugins](/zh-CN/plugins/building-plugins) — 创建你自己的插件
-- [Plugin Bundles](/zh-CN/plugins/bundles) — 与 Codex/Claude/Cursor Bundle 的兼容性
-- [Plugin Manifest](/zh-CN/plugins/manifest) — manifest schema
-- [Registering Tools](/zh-CN/plugins/building-plugins#registering-agent-tools) — 在插件中添加智能体工具
-- [Plugin Internals](/zh-CN/plugins/architecture) — 能力模型与加载管线
-- [Community Plugins](/zh-CN/plugins/community) — 第三方列表
+- [构建插件](/zh-CN/plugins/building-plugins) — 创建你自己的插件
+- [插件 Bundle](/zh-CN/plugins/bundles) — 与 Codex/Claude/Cursor bundle 的兼容性
+- [插件清单](/zh-CN/plugins/manifest) — 清单 schema
+- [注册工具](/zh-CN/plugins/building-plugins#registering-agent-tools) — 在插件中添加智能体工具
+- [插件内部原理](/zh-CN/plugins/architecture) — 能力模型和加载流水线
+- [社区插件](/zh-CN/plugins/community) — 第三方列表

docs/zh-CN/tools/thinking.md

@@ -1,132 +1,132 @@
 ---
 read_when:
-    - 调整 thinking、快速模式或 verbose 指令的解析或默认值
-summary: '`/think`、`/fast`、`/verbose`、`/trace` 和推理可见性的指令语法'
-title: Thinking 级别
+    - 调整思考、快速模式或详细模式的指令解析或默认值
+summary: '`/think`、`/fast`、`/verbose`、`/trace` 的指令语法，以及推理可见性'
+title: 思考级别
 x-i18n:
-    generated_at: "2026-04-23T07:26:43Z"
+    generated_at: "2026-04-23T13:33:17Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 66033bb9272c9b9ea8fc85dc91e33e95ce4c469c56a8cd10c19632a5aa8a2338
+    source_hash: 4efe899f7b47244745a105583b3239effa7975fadd06bd7bcad6327afcc91207
     source_path: tools/thinking.md
     workflow: 15
 ---
 
-# Thinking 级别（`/think` 指令）
+# 思考级别（`/think` 指令）
 
-## 它的作用
+## 功能说明
 
-- 任何传入内容中的内联指令：`/t <level>`、`/think:<level>` 或 `/thinking <level>`。
+- 可在任何入站消息正文中使用内联指令：`/t <level>`、`/think:<level>` 或 `/thinking <level>`。
 - 级别（别名）：`off | minimal | low | medium | high | xhigh | adaptive | max`
   - minimal → “think”
   - low → “think hard”
   - medium → “think harder”
   - high → “ultrathink”（最大预算）
-  - xhigh → “ultrathink+”（GPT-5.2 + Codex 模型和 Anthropic Claude Opus 4.7 effort）
-  - adaptive → 由提供商管理的自适应 thinking（Anthropic / Bedrock 上的 Claude 4.6 以及 Anthropic Claude Opus 4.7 支持）
+  - xhigh → “ultrathink+”（GPT-5.2 + Codex 模型以及 Anthropic Claude Opus 4.7 effort）
+  - adaptive → 提供商管理的自适应思考（适用于 Anthropic/Bedrock 上的 Claude 4.6 和 Anthropic Claude Opus 4.7）
   - max → 提供商最大推理（当前为 Anthropic Claude Opus 4.7）
-  - `x-high`、`x_high`、`extra-high`、`extra high` 和 `extra_high` 都会映射为 `xhigh`。
-  - `highest` 会映射为 `high`。
+  - `x-high`、`x_high`、`extra-high`、`extra high` 和 `extra_high` 都映射为 `xhigh`。
+  - `highest` 映射为 `high`。
 - 提供商说明：
-  - Thinking 菜单和选择器由 provider profile 驱动。提供商插件会为所选模型声明确切的级别集，包括诸如二元 `on` 之类的标签。
-  - `adaptive`、`xhigh` 和 `max` 仅会为支持它们的 provider/model profiles 进行展示。对于不支持的级别，键入式指令会被拒绝，并显示该模型的有效选项。
-  - 已存储但不受支持的现有级别会按 provider profile 排名重新映射。`adaptive` 在非自适应模型上会回退到 `medium`，而 `xhigh` 和 `max` 会回退到所选模型支持的最大非 `off` 级别。
-  - 当未设置显式 thinking 级别时，Anthropic Claude 4.6 模型默认使用 `adaptive`。
-  - Anthropic Claude Opus 4.7 默认不使用自适应 thinking。除非你显式设置 thinking 级别，否则其 API effort 默认值仍由提供商决定。
-  - Anthropic Claude Opus 4.7 会将 `/think xhigh` 映射为自适应 thinking 加上 `output_config.effort: "xhigh"`，因为 `/think` 是一个 thinking 指令，而 `xhigh` 是 Opus 4.7 的 effort 设置。
-  - Anthropic Claude Opus 4.7 还公开了 `/think max`；它会映射到同一个由提供商决定的最大 effort 路径。
-  - OpenAI GPT 模型会通过特定于模型的 Responses API effort 支持来映射 `/think`。仅当目标模型支持时，`/think off` 才会发送 `reasoning.effort: "none"`；否则 OpenClaw 会省略已禁用的推理载荷，而不是发送不受支持的值。
-  - 通过 Anthropic 兼容流式路径运行的 MiniMax（`minimax/*`）默认使用 `thinking: { type: "disabled" }`，除非你在模型参数或请求参数中显式设置 thinking。这样可避免 MiniMax 非原生 Anthropic 流格式泄露 `reasoning_content` 增量。
-  - Z.AI（`zai/*`）仅支持二元 thinking（`on`/`off`）。任何非 `off` 级别都会被视为 `on`（映射为 `low`）。
-  - Moonshot（`moonshot/*`）会将 `/think off` 映射为 `thinking: { type: "disabled" }`，并将任何非 `off` 级别映射为 `thinking: { type: "enabled" }`。启用 thinking 时，Moonshot 只接受 `tool_choice` `auto|none`；OpenClaw 会将不兼容的值规范化为 `auto`。
+  - 思考菜单和选择器由 provider profile 驱动。提供商插件会为所选模型声明精确支持的级别集合，包括诸如二元 `on` 之类的标签。
+  - 仅当 provider/model profile 支持时，才会公开 `adaptive`、`xhigh` 和 `max`。如果输入了不支持的级别指令，则会被拒绝，并返回该模型的有效选项。
+  - 已存储但不受支持的现有级别会按 provider profile 的等级进行重映射。在非自适应模型上，`adaptive` 会回退为 `medium`；而 `xhigh` 和 `max` 会回退为所选模型支持的最高非 `off` 级别。
+  - 当未显式设置思考级别时，Anthropic Claude 4.6 模型默认使用 `adaptive`。
+  - Anthropic Claude Opus 4.7 不默认使用 adaptive thinking。其 API effort 默认值仍由提供商控制，除非你显式设置思考级别。
+  - 对于 Anthropic Claude Opus 4.7，`/think xhigh` 会映射为 adaptive thinking 加 `output_config.effort: "xhigh"`，因为 `/think` 是一个思考指令，而 `xhigh` 是 Opus 4.7 的 effort 设置。
+  - Anthropic Claude Opus 4.7 还公开了 `/think max`；它会映射到相同的提供商控制的最大 effort 路径。
+  - OpenAI GPT 模型会通过模型特定的 Responses API effort 支持来映射 `/think`。仅当目标模型支持时，`/think off` 才会发送 `reasoning.effort: "none"`；否则 OpenClaw 会省略禁用推理的负载，而不是发送不受支持的值。
+  - Anthropic 兼容流式路径上的 MiniMax（`minimax/*`）默认使用 `thinking: { type: "disabled" }`，除非你在模型参数或请求参数中显式设置 thinking。这样可以避免 MiniMax 的非原生 Anthropic 流格式泄露 `reasoning_content` 增量。
+  - Z.AI（`zai/*`）只支持二元 thinking（`on`/`off`）。任何非 `off` 级别都会被视为 `on`（映射为 `low`）。
+  - Moonshot（`moonshot/*`）会将 `/think off` 映射为 `thinking: { type: "disabled" }`，并将任何非 `off` 级别映射为 `thinking: { type: "enabled" }`。启用 thinking 时，Moonshot 只接受 `tool_choice` 为 `auto|none`；OpenClaw 会将不兼容的值规范化为 `auto`。
 
 ## 解析顺序
 
-1. 消息中的内联指令（仅应用于该消息）。
-2. 会话覆盖（通过发送仅包含指令的消息设置）。
-3. 按智能体的默认值（配置中的 `agents.list[].thinkingDefault`）。
+1. 消息中的内联指令（仅对该条消息生效）。
+2. 会话覆盖值（通过发送仅包含指令的消息设置）。
+3. 每个智能体的默认值（配置中的 `agents.list[].thinkingDefault`）。
 4. 全局默认值（配置中的 `agents.defaults.thinkingDefault`）。
-5. 回退：如果可用，则使用提供商声明的默认值；否则，对其他在目录中标记为支持推理的模型使用 `low`；再否则使用 `off`。
+5. 回退：优先使用提供商声明的默认值；否则，具备推理能力的模型会解析为 `medium` 或该模型支持的最近非 `off` 级别，而不具备推理能力的模型则保持 `off`。
 
 ## 设置会话默认值
 
-- 发送一条**仅包含指令**的消息（允许空白字符），例如 `/think:medium` 或 `/t high`。
-- 该设置会固定应用于当前会话（默认按发送者区分）；可通过 `/think:off` 或会话空闲重置来清除。
-- 会发送确认回复（`Thinking level set to high.` / `Thinking disabled.`）。如果级别无效（例如 `/thinking big`），命令会被拒绝并给出提示，同时会话状态保持不变。
-- 发送不带参数的 `/think`（或 `/think:`）可查看当前 thinking 级别。
+- 发送一条**仅包含该指令**的消息（允许空白字符），例如 `/think:medium` 或 `/t high`。
+- 这样会在当前会话中生效（默认按发送者区分）；可通过 `/think:off` 或会话空闲重置来清除。
+- 会发送确认回复（`Thinking level set to high.` / `Thinking disabled.`）。如果级别无效（例如 `/thinking big`），该命令会被拒绝并返回提示，同时会话状态保持不变。
+- 发送不带参数的 `/think`（或 `/think:`）可查看当前思考级别。
 
 ## 按智能体应用
 
-- **嵌入式 Pi**：解析后的级别会传递给进程内 Pi 智能体运行时。
+- **嵌入式 Pi**：解析后的级别会传递给进程内的 Pi 智能体运行时。
 
 ## 快速模式（`/fast`）
 
 - 级别：`on|off`。
-- 仅包含指令的消息会切换会话快速模式覆盖，并回复 `Fast mode enabled.` / `Fast mode disabled.`。
+- 仅包含指令的消息会切换会话级快速模式覆盖值，并回复 `Fast mode enabled.` / `Fast mode disabled.`。
 - 发送不带模式的 `/fast`（或 `/fast status`）可查看当前生效的快速模式状态。
 - OpenClaw 按以下顺序解析快速模式：
-  1. 内联 / 仅指令的 `/fast on|off`
-  2. 会话覆盖
-  3. 按智能体的默认值（`agents.list[].fastModeDefault`）
-  4. 按模型配置：`agents.defaults.models["<provider>/<model>"].params.fastMode`
+  1. 内联/仅指令 `/fast on|off`
+  2. 会话覆盖值
+  3. 每个智能体的默认值（`agents.list[].fastModeDefault`）
+  4. 每个模型的配置：`agents.defaults.models["<provider>/<model>"].params.fastMode`
   5. 回退：`off`
-- 对于 `openai/*`，快速模式会通过在支持的 Responses 请求中发送 `service_tier=priority` 映射到 OpenAI 优先处理。
-- 对于 `openai-codex/*`，快速模式会在 Codex Responses 上发送相同的 `service_tier=priority` 标记。OpenClaw 在这两种凭证路径上共用同一个 `/fast` 开关。
-- 对于直接公开的 `anthropic/*` 请求，包括发送到 `api.anthropic.com` 的 OAuth 凭证流量，快速模式会映射到 Anthropic service tiers：`/fast on` 设置 `service_tier=auto`，`/fast off` 设置 `service_tier=standard_only`。
+- 对于 `openai/*`，快速模式会通过在受支持的 Responses 请求上发送 `service_tier=priority`，映射为 OpenAI 优先处理。
+- 对于 `openai-codex/*`，快速模式会在 Codex Responses 上发送相同的 `service_tier=priority` 标志。OpenClaw 会在这两种认证路径之间共用同一个 `/fast` 开关。
+- 对于直接发往公共 `anthropic/*` 的请求，包括发送到 `api.anthropic.com` 的 OAuth 认证流量，快速模式会映射为 Anthropic 服务层级：`/fast on` 设置 `service_tier=auto`，`/fast off` 设置 `service_tier=standard_only`。
 - 对于 Anthropic 兼容路径上的 `minimax/*`，`/fast on`（或 `params.fastMode: true`）会将 `MiniMax-M2.7` 改写为 `MiniMax-M2.7-highspeed`。
-- 当两者同时设置时，显式的 Anthropic `serviceTier` / `service_tier` 模型参数会覆盖快速模式默认值。对于非 Anthropic 代理 base URL，OpenClaw 仍会跳过 Anthropic service-tier 注入。
-- 只有在启用快速模式时，`/status` 才会显示 `Fast`。
+- 当两者同时设置时，显式的 Anthropic `serviceTier` / `service_tier` 模型参数会覆盖快速模式默认值。对于非 Anthropic 代理 base URL，OpenClaw 仍会跳过 Anthropic 服务层级注入。
+- `/status` 仅在快速模式启用时显示 `Fast`。
 
-## Verbose 指令（`/verbose` 或 `/v`）
+## 详细模式指令（`/verbose` 或 `/v`）
 
 - 级别：`on`（最简）| `full` | `off`（默认）。
-- 仅包含指令的消息会切换会话 verbose，并回复 `Verbose logging enabled.` / `Verbose logging disabled.`；无效级别会返回提示而不更改状态。
-- `/verbose off` 会存储一个显式会话覆盖；可在 Sessions UI 中选择 `inherit` 来清除。
-- 内联指令仅影响该消息；否则应用会话 / 全局默认值。
-- 发送不带参数的 `/verbose`（或 `/verbose:`）可查看当前 verbose 级别。
-- 开启 verbose 后，能发出结构化工具结果的智能体（Pi、其他 JSON 智能体）会将每次工具调用作为单独的仅元数据消息回传，并在可用时以前缀 `<emoji> <tool-name>: <arg>`（路径 / 命令）。这些工具摘要会在每个工具启动时立即发送（单独气泡），而不是作为流式增量发送。
-- 工具失败摘要在普通模式下仍然可见，但除非 verbose 为 `on` 或 `full`，否则原始错误详情后缀会被隐藏。
-- 当 verbose 为 `full` 时，工具输出也会在完成后转发（单独气泡，并截断到安全长度）。如果你在运行中切换 `/verbose on|full|off`，后续工具气泡会遵循新设置。
+- 仅包含指令的消息会切换会话详细模式，并回复 `Verbose logging enabled.` / `Verbose logging disabled.`；无效级别会返回提示且不改变状态。
+- `/verbose off` 会存储一个显式的会话覆盖值；可在会话 UI 中选择 `inherit` 来清除。
+- 内联指令仅影响该条消息；否则应用会话/全局默认值。
+- 发送不带参数的 `/verbose`（或 `/verbose:`）可查看当前详细级别。
+- 当详细模式开启时，会输出结构化工具结果的智能体（Pi、其他 JSON 智能体）会将每次工具调用作为单独的仅元数据消息发回；如可用，则以 `<emoji> <tool-name>: <arg>` 作为前缀（路径/命令）。这些工具摘要会在每个工具启动时立即发送（单独气泡），而不是作为流式增量发送。
+- 工具失败摘要在普通模式下仍然可见，但原始错误详情后缀仅会在详细模式为 `on` 或 `full` 时显示。
+- 当详细模式为 `full` 时，工具输出也会在完成后被转发（单独气泡，并截断到安全长度）。如果你在运行过程中切换 `/verbose on|full|off`，后续的工具气泡会遵循新的设置。
 
-## 插件 trace 指令（`/trace`）
+## 插件追踪指令（`/trace`）
 
 - 级别：`on` | `off`（默认）。
-- 仅包含指令的消息会切换会话插件 trace 输出，并回复 `Plugin trace enabled.` / `Plugin trace disabled.`。
-- 内联指令仅影响该消息；否则应用会话 / 全局默认值。
-- 发送不带参数的 `/trace`（或 `/trace:`）可查看当前 trace 级别。
-- `/trace` 比 `/verbose` 更窄：它仅暴露插件拥有的 trace / 调试行，例如 Active Memory 调试摘要。
-- Trace 行可显示在 `/status` 中，也可在正常 assistant 回复后作为后续诊断消息显示。
+- 仅包含指令的消息会切换会话插件追踪输出，并回复 `Plugin trace enabled.` / `Plugin trace disabled.`。
+- 内联指令仅影响该条消息；否则应用会话/全局默认值。
+- 发送不带参数的 `/trace`（或 `/trace:`）可查看当前追踪级别。
+- `/trace` 比 `/verbose` 更窄：它只暴露插件拥有的 trace/debug 行，例如 Active Memory 调试摘要。
+- Trace 行可能会出现在 `/status` 中，也可能作为普通助手回复后的后续诊断消息出现。
 
 ## 推理可见性（`/reasoning`）
 
 - 级别：`on|off|stream`。
-- 仅包含指令的消息会切换是否在回复中显示 thinking blocks。
-- 启用后，推理会作为**单独消息**发送，并以前缀 `Reasoning:` 开头。
-- `stream`（仅 Telegram）：在生成回复期间，将推理流式写入 Telegram 草稿气泡，然后发送不含推理的最终答案。
+- 仅包含指令的消息会切换是否在回复中显示 thinking 块。
+- 启用后，推理会作为一条**单独消息**发送，并以 `Reasoning:` 为前缀。
+- `stream`（仅 Telegram）：在生成回复时，将推理流式输出到 Telegram 草稿气泡中，然后发送不含推理的最终答案。
 - 别名：`/reason`。
 - 发送不带参数的 `/reasoning`（或 `/reasoning:`）可查看当前推理级别。
-- 解析顺序：内联指令，然后会话覆盖，然后按智能体默认值（`agents.list[].reasoningDefault`），最后回退（`off`）。
+- 解析顺序：内联指令、会话覆盖值、每个智能体的默认值（`agents.list[].reasoningDefault`），然后回退为 `off`。
 
 ## 相关内容
 
-- Elevated mode 文档位于 [Elevated mode](/zh-CN/tools/elevated)。
+- Elevated mode 文档见 [Elevated mode](/zh-CN/tools/elevated)。
 
 ## 心跳
 
-- 心跳探测正文是已配置的心跳提示（默认：`Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`）。心跳消息中的内联指令会像往常一样生效（但应避免通过心跳更改会话默认值）。
-- 心跳传递默认仅包含最终载荷。若还要发送单独的 `Reasoning:` 消息（如果可用），请设置 `agents.defaults.heartbeat.includeReasoning: true` 或按智能体设置 `agents.list[].heartbeat.includeReasoning: true`。
+- 心跳探测正文是已配置的心跳提示词（默认：`Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`）。心跳消息中的内联指令会照常生效（但应避免通过心跳修改会话默认值）。
+- 心跳传递默认只发送最终负载。如需同时发送单独的 `Reasoning:` 消息（若可用），请设置 `agents.defaults.heartbeat.includeReasoning: true` 或每个智能体的 `agents.list[].heartbeat.includeReasoning: true`。
 
 ## Web 聊天 UI
 
-- 页面加载时，web 聊天 thinking 选择器会镜像来自传入会话存储 / 配置的会话已存储级别。
-- 选择其他级别会立即通过 `sessions.patch` 写入会话覆盖；不会等到下一次发送，也不是一次性的 `thinkingOnce` 覆盖。
-- 第一个选项始终是 `Default (<resolved level>)`，其中解析后的默认值来自活动会话模型的 provider thinking profile。
-- 选择器使用 Gateway 网关会话行返回的 `thinkingOptions`。浏览器 UI 不会保留自己的 provider regex 列表；特定于模型的级别集由插件负责。
-- `/think:<level>` 仍然可用，并会更新同一个已存储的会话级别，因此聊天指令和选择器会保持同步。
+- Web 聊天思考选择器在页面加载时，会从入站会话存储/配置中镜像该会话已存储的级别。
+- 选择其他级别时，会立即通过 `sessions.patch` 写入会话覆盖值；它不会等到下一次发送，也不是一次性的 `thinkingOnce` 覆盖。
+- 第一个选项始终是 `Default (<resolved level>)`，其中解析后的默认值来自活动会话模型的 provider thinking profile，以及 `/status` 和 `session_status` 使用的相同回退逻辑。
+- 该选择器使用 Gateway 网关 会话行返回的 `thinkingOptions`。浏览器 UI 不维护自己的提供商正则列表；模型特定级别集合由插件负责。
+- `/think:<level>` 仍然可用，并会更新同一个已存储的会话级别，因此聊天指令与选择器会保持同步。
 
 ## Provider profiles
 
-- 提供商插件可以公开 `resolveThinkingProfile(ctx)`，用于定义模型支持的级别和默认值。
-- 每个 profile 级别都有一个已存储的规范 `id`（`off`、`minimal`、`low`、`medium`、`high`、`xhigh`、`adaptive` 或 `max`），并且可以包含一个显示 `label`。二元提供商使用 `{ id: "low", label: "on" }`。
-- 已发布的旧版 hooks（`supportsXHighThinking`、`isBinaryThinking` 和 `resolveDefaultThinkingLevel`）仍保留为兼容性适配器，但新的自定义级别集应使用 `resolveThinkingProfile`。
-- Gateway 网关行会暴露 `thinkingOptions` 和 `thinkingDefault`，以便 ACP / 聊天客户端渲染与运行时验证所用的同一 profile。
+- 提供商插件可以公开 `resolveThinkingProfile(ctx)`，以定义该模型支持的级别及默认值。
+- 每个 profile 级别都有一个存储的规范 `id`（`off`、`minimal`、`low`、`medium`、`high`、`xhigh`、`adaptive` 或 `max`），并且可以包含一个显示用的 `label`。二元提供商使用 `{ id: "low", label: "on" }`。
+- 已发布的旧版钩子（`supportsXHighThinking`、`isBinaryThinking` 和 `resolveDefaultThinkingLevel`）仍保留为兼容性适配器，但新的自定义级别集合应使用 `resolveThinkingProfile`。
+- Gateway 网关 行会公开 `thinkingOptions` 和 `thinkingDefault`，以便 ACP/聊天客户端渲染与运行时校验相同的 profile。