跳转至

思考级别

功能说明

  • 在任何入站消息正文中均可使用内联指令：/t <level>、/think:<level>、/thinking <level>。
  • 级别（别名）：off | minimal | low | medium | high | xhigh | adaptive | max | ultra，大致对应 Anthropic 经典的 “think” < “think hard” < “think harder” < “ultrathink” 魔法词阶梯：
  • minimal ~ “think”
  • low ~ “think hard”
  • medium ~ “think harder”
  • high ~ “ultrathink”（最大预算）
  • xhigh ~ “ultrathink+”（GPT-5.2+ 和 Codex 模型，外加 Anthropic Claude Opus 4.7+ 的 effort）
  • adaptive → 提供商管理的自适应思考（支持 Anthropic/Bedrock 上的 Claude 4.6、Anthropic Claude Opus 4.7+，以及 Google Gemini 动态思考）
  • max → 提供商最大推理（Anthropic Claude Opus 4.7+；Ollama 会将其映射到其最高原生 think 力度）
  • ultra → harness 级规划、执行、验证和主动子代理编排；适用于 OpenClaw 和 Claude Code 运行时上的每个模型，以及 Codex 上受支持的原生推理模型
  • x-high、x_high、extra-high、extra high 和 extra_high 映射到 xhigh。
  • highest 映射到 high；maximum 映射到 max。
  • 提供商说明：
  • 思考菜单和选择器由提供商配置文件驱动。提供商插件会为所选模型声明精确的级别集合，包括诸如二值 on 之类的标签。
  • 仅当提供商/模型支持 adaptive、xhigh 和 max 时才会展示这些级别。Ultra 是独立的 harness 模式，不是额外的提供商 API effort。对于不支持的原生级别，键入的指令会被拒绝，并附上该模型的有效选项。
  • 已存储的不支持级别会按提供商配置文件排名重新映射。当 adaptive 不可选时，会使用提供商声明的非 off 默认值；否则其排序回退会保留已启用的思考，通常是 medium。xhigh 和 max 会回退到所选模型支持的最大非 off 级别。
  • Anthropic Claude 4.6 模型在未设置显式思考级别时默认使用 adaptive。
  • Anthropic Claude Opus 4.8 和 Opus 4.7 默认保持思考关闭，除非你显式设置思考级别。Opus 4.8 在启用自适应思考后，其提供商侧 effort 默认值为 high。
  • Anthropic Claude Opus 4.7+ 将 /think xhigh 映射为自适应思考外加 output_config.effort: "xhigh"，因为 /think 是思考指令，而 xhigh 是 Opus 的 effort 设置。
  • Anthropic Claude Opus 4.7+ 也暴露 /think max；它会映射到相同的提供商侧最大 effort 路径。
  • 直接 DeepSeek V4 模型暴露 /think xhigh|max；两者都映射到 DeepSeek 的 reasoning_effort: "max"，而较低的非 off 级别映射到 high。
  • 通过 OpenRouter 路由的 DeepSeek V4 模型暴露 /think xhigh，并发送 OpenRouter 支持的 reasoning.effort 值，而不是 DeepSeek 原生的顶层 reasoning_effort。较低的非 off 级别映射到 high，已存储的 max 覆盖会回退到 xhigh。
  • 支持思考的 Ollama 模型暴露 /think low|medium|high|max。经验证支持完整 effort 的 Ollama Cloud 系列（如 GLM 5.2 和 DeepSeek V4）会发送每个匹配的原生 think 力度，包括 max；其他模型和本地 Ollama 对 /think max 保留兼容的 high 映射。
  • OpenAI GPT 模型通过所选模型和认证路由的 effort 支持来映射 /think。在受支持的 OpenAI Platform/API 密钥路由上，/think off 会发送显式的 reasoning.effort: "none"，包括使用 Codex 运行时的情况。不支持 none 的订阅路由会保留提供商或原生运行时的默认推理行为；在这些路由上，off 不保证零推理。受监督的原生 Codex 线程保留其自身的思考设置。
  • GPT-6 Astra、GPT-5.6 Sol 和 Terra 通过 Codex 运行时暴露原生 /think ultra，可使用 Platform API 密钥或 ChatGPT 订阅认证。OpenClaw 在普通轮次中保留 Ultra；/btw 有意以 off 运行。Codex 负责主动委派和模型特定的推理 effort（Astra 使用 xhigh）。Ultra 不会作为原始 Responses API 推理 effort 发送。其他具有原生推理 effort 的 Codex 模型也可以使用 Ultra：Codex 会选择其支持的推理 effort，同时保留其原生委派策略。没有原生 effort 选项的模型可以通过 OpenClaw 运行时使用宿主引导的 Ultra。
  • OpenClaw 和 Claude Code 运行时为所有模型暴露逻辑上的 /think ultra。它们选择最高受支持的原生 effort，并添加运行范围内的规划和验证指导。仅当 sessions_spawn 可用时才显示委派指导；Ultra 不会授予工具，也不会绕过工具的策略。非推理模型仍是非推理模型，没有 effort 控制的模型保留提供商默认值。
  • 在缓存的 OpenAI 会话中更改 effort 可能会追加一个 configuration_update，同时为提示复用保留原始请求级 effort。最新更新决定有效的 effort；未更改的顶层字段不构成降级。
  • 自定义 OpenAI 兼容目录条目可以通过将 models.providers.<provider>.models[].compat.supportedReasoningEfforts 设置为包含 "xhigh" 来选择使用 /think xhigh。这使用了与出站 OpenAI 推理 effort 有效负载映射相同的 compat 元数据，因此菜单、会话验证、agent CLI 和 llm-task 会与传输行为保持一致。
  • 自 2026.4.26 起，配置过期的 OpenRouter Hunter Alpha 引用会跳过代理推理注入，因为该已退役路由可能通过推理字段返回最终答案文本。
  • Google Gemini 将 /think adaptive 映射到 Gemini 的提供商侧动态思考。Gemini 3 请求省略固定的 thinkingLevel，而 Gemini 2.5 请求发送 thinkingBudget: -1；固定级别仍会映射到该模型系列最接近的 Gemini thinkingLevel 或预算。
  • 在 Anthropic 兼容的流式路径上，MiniMax M2.x（minimax/MiniMax-M2*）默认使用 thinking: { type: "disabled" }，除非你在模型参数或请求参数中显式设置思考。这避免了 M2.x 非原生 Anthropic 流格式泄漏 reasoning_content 增量。MiniMax-M3（及 M3.x）例外：M3 会发出正确的 Anthropic 思考块，并在思考禁用时返回空内容，因此 OpenClaw 将 M3 保留在提供商的省略/自适应思考路径上。
  • Z.AI（zai/*）对大多数 GLM 模型是二值的（on/off）。GLM-5.2 和 GLM-5.3 是例外。GLM-5.2 暴露 /think off|low|high|max，默认值为 off，将 low 和 high 映射到 Z.AI 的 reasoning_effort: "high"，并将 max 映射到 reasoning_effort: "max"。GLM-5.3 暴露 /think low|high|max，默认值为 max，将 off、minimal 和 low 映射到 reasoning_effort: "low"，将 medium 和 high 映射到 "high"，并将 xhigh、adaptive 和 max 映射到 "max"。
  • Moonshot API 的 Kimi K3（moonshot/kimi-k3）始终以 max 思考，发送 reasoning_effort: "max"，省略 K2 的 thinking 字段和固定采样覆盖，并保留 K3 支持的工具选择。Kimi Code K3（kimi/k3 和 kimi/k3-256k）暴露完整的 /think 阶梯，默认值为 high：off 发送 thinking.type: "disabled"，minimal/low 映射到低 effort，medium/high/adaptive 映射到高 effort，xhigh/max 映射到最大 effort。Kimi Code 引用还包括 kimi/kimi-for-coding 和 kimi/kimi-for-coding-highspeed。Kimi K2.7 Code（moonshot/kimi-k2.7-code 和 moonshot/kimi-k2.7-code-highspeed）始终思考，仅暴露 on，并同时省略出站的 thinking 和 reasoning_effort。其他 moonshot/* 模型将 /think off 映射到 thinking: { type: "disabled" }，将任何非 off 级别映射到 thinking: { type: "enabled" }。当 K2 思考启用时，Moonshot 只接受 tool_choice 的 auto|none；OpenClaw 会将不兼容的值规范化为 auto。

解析顺序

  1. 消息上的内联指令（仅适用于该消息）。
  2. 会话覆盖（通过发送仅含指令的消息设置）。
  3. 按代理默认值（配置中的 agents.entries.*.thinkingDefault）。
  4. 按代理模型默认值（配置中的 agents.entries.*.models["<provider>/<model>"].params.thinking）。
  5. 共享模型默认值（配置中的 agents.defaults.models["<provider>/<model>"].params.thinking）。
  6. 全局默认值（配置中的 agents.defaults.thinkingDefault）。
  7. 回退：提供商声明的默认值可用时优先使用；否则，具备推理能力的模型解析为 medium 或该模型最接近的受支持的非 off 级别，不具备推理能力的模型保持 off。

设置模型默认值

使用 params.thinking 为一个已配置模型设置默认值，而无需更改其他模型的默认值。该键必须与你实际选择的提供商和模型匹配，包括自定义提供商暴露出的任何模型路径。

将 <provider>/<model> 替换为已配置模型的完整 ID，然后将此条目合并到现有模型配置中：

{
  agents: {
    defaults: {
      models: {
        "<provider>/<model>": {
          params: { thinking: "high" },
        },
      },
    },
  },
}

提供商必须已经配置，并且模型必须支持所选的思考级别。

要为某个代理更改该模型的默认值，请将相同条目放在 agents.entries.<agent>.models 下。这会覆盖共享模型设置。模型 params.thinking 接受与 /think 相同的别名；false 和 "disabled" 也会选择 off。

内联指令、已保存的会话覆盖或按代理的 thinkingDefault 仍然优先。发送 /think default 可清除已保存的会话覆盖；如果模型默认值仍然不生效，请检查按代理的设置。

设置会话默认值

  • 发送一条仅包含指令的消息（允许空白），例如 /think:medium 或 /t high。
  • 该设置会对当前会话持续生效（默认按发送者）。使用 /think default 清除会话覆盖并继承配置的/提供商的默认值；别名包括 inherit、clear、reset 和 unpin。
  • /think off 会存储显式的 off 覆盖，直到你更改或清除它。上游模型能否禁用思考取决于所选的提供商和认证方式。
  • 会发送确认回复（Thinking level set to high. / Thinking disabled.）。如果级别无效（例如 /thinking big），命令会被拒绝并附提示，且会话状态保持不变。
  • 发送不带参数的 /think（或 /think:）以查看当前思考级别。

按代理应用

  • 嵌入式 OpenClaw：解析后的级别会传递给进程内的 OpenClaw 代理运行时。
  • Claude CLI 后端：具体级别映射到 Claude Code --effort；允许固定预算的模型还会收到匹配的 MAX_THINKING_TOKENS 启动值。adaptive 会移除已配置的 effort 标志和固定预算覆盖，将有效思考交由 Claude Code 的环境、设置和模型默认值处理。参见 CLI 后端。

快速模式 (/fast)

  • 级别：auto|on|off|default。
  • 仅含指令的消息会切换会话快速模式覆盖，并回复 Fast mode set to auto.、Fast mode enabled. 或 Fast mode disabled.。使用 /fast default 清除会话覆盖并继承已配置的默认值；别名包括 inherit、clear、reset 和 unpin。
  • 发送不带模式的 /fast（或 /fast status）以查看当前生效的快速模式状态。
  • OpenClaw 按以下顺序解析快速模式：
  • 当前消息上的内联 /fast auto|on|off 覆盖
  • 仅含指令的消息所存储的会话覆盖（/fast default 会清除这一层）
  • 按代理默认值（agents.entries.*.fastModeDefault）
  • 全局默认值（agents.defaults.fastModeDefault）
  • 按模型配置（agents.defaults.models["<provider>/<model>"].params.fastMode）
  • 回退：off
  • 有效的模型级 params.fastMode / params.fast_mode 值和有效的截止时间键是类型化的代理运行时控制项。它们不算作编写的提供商请求参数，也不会自行选择 OpenClaw 或 Codex。当某个方案依赖于特定运行时，请固定 agentRuntime.id: "openclaw" 或 agentRuntime.id: "codex"。
  • auto 会将会话/配置模式保持为 auto，但每次新的模型调用都会独立解析。在自动截止时间之前开始的调用启用快速模式；之后的重试、回退、工具结果或继续调用以禁用快速模式开始。截止时间默认为 60 秒；在活动模型上设置 agents.defaults.models["<provider>/<model>"].params.fastAutoOnSeconds 可更改它。
  • 对于 openai/*，快速模式映射到 OpenAI API 快速模式（原优先级处理）。OpenClaw 目前会在受支持的 Responses 请求上发送 service_tier=priority。
  • 在 Codex harness 回合中，共享运行时控制项会取代已配置的原生应用服务层级：快速模式开启时发送 priority，关闭时发送 null 以清除 OpenClaw 拥有的层级，auto 则对每次模型调用分别决定。只有在未提供共享快速模式运行控制项时，才会使用已配置的 Codex 层级。参见 Codex harness。
  • 对于直接使用 API 密钥的 anthropic/* 请求，Opus 5 和 Opus 4.8 使用原生 speed=fast。其他受支持的模型使用优先级层级：开启时设置 service_tier=auto，关闭时设置 service_tier=standard_only。Sonnet 5 不支持这两种映射；OAuth 请求不会收到任一字段。
  • 对于 Anthropic 兼容路径上的 minimax/*，/fast on（或 params.fastMode: true）会将 MiniMax-M2.7 重写为 MiniMax-M2.7-highspeed。
  • 当两者都设置时，显式的 Anthropic serviceTier / service_tier 模型参数会覆盖快速模式默认值。对于非 Anthropic 代理基础 URL，OpenClaw 仍会跳过 Anthropic 服务层级注入。
  • /status 报告解析后的 OpenClaw 策略（on、off 或 auto）以及所选的运行时。它不报告已完成请求实际采用或返回的上游服务层级。提供商详情参见 OpenAI Fast mode。
  • 控制界面会禁用已确认对所选请求无效果的快速模式选项。现有已保存偏好仍然可见且可清除。当适用性未知时，控件保持其现有行为；可用性并不承诺供应商权益或更快的响应。

`blocks stay hidden on normal replies, and unclosed reasoning after already visible text is also hidden. If a reply is fully wrapped in a single unclosed opening tag and would otherwise deliver as empty text, OpenClaw removes the malformed opening tag and delivers the remaining text.

Translation: "畸形（malformed）本地模型推理标签会被保守处理。闭合的 <think>...</think> 块在普通回复中保持隐藏；已经可见文本之后未闭合的推理也会隐藏。如果一条回复完全包裹在单个未闭合的起始标签中，并且按原样交付会变成空文本，OpenClaw 会移除该畸形起始标签并交付剩余文本。"

Need "OpenClaw" is brand/product name, keep. Good.

Next:

Translation:

  • 提升模式文档位于 Elevated mode。 (We need translate link text? The link text is prose and can be translated? The URL should remain. The rule: Keep URLs unchanged, translate prose text. Link text "Elevated mode" can be translated to "提升模式", but the link URL remains. However, "Elevated mode" is title of docs. We can translate to "提升模式" perhaps. Also "Slash commands" -> "斜杠命令". "Configuration reference" -> "配置参考".)
  • 斜杠命令 — 在会话中更改推理级别
  • 配置参考 — 在哪里配置推理默认值

Need "thinking level" perhaps "思考级别" or "推理级别"? In context, "thinking" is reasoning. Earlier we used "推理". So "推理级别".

But wait: heading "Related" can be "相关". Link "Elevated mode" maybe should remain English? Since document names are often left. But the rule says translate prose text; link text is prose. I'd translate.

Next:

Heartbeats

  • Heartbeat probe body is the configured heartbeat prompt (default: Follow the heartbeat monitor scratch context when provided. Recurring tasks are automations; create or change their schedules with the automations tool, not heartbeat scratch. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply NO_REPLY.). Inline directives in a heartbeat message apply as usual (but avoid changing session defaults from heartbeats).
  • Heartbeat delivery uses the last outbound-capable non-reasoning payload. Separate reasoning or Thinking payloads remain internal, and a reasoning-only heartbeat result produces no alert.

Translation:

心跳

  • 心跳探测正文是配置好的心跳提示词（默认：Follow the heartbeat monitor scratch context when provided. Recurring tasks are automations; create or change their schedules with the automations tool, not heartbeat scratch. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply NO_REPLY.）。心跳消息中的内联指令照常生效（但避免通过心跳更改会话默认值）。
  • 心跳投递使用最后一个可出站的非推理负载。单独的推理或 Thinking 负载保持内部使用，仅含推理的心跳结果不会产生警报。

Need "prompt" is code? Not code. "heartbeat prompt" maybe "心跳提示词". The default string is code span? It's inside backticks? In original, "default: Follow the heartbeat monitor scratch context when provided. ..." Yes keep exactly. Good.

Next:

Web chat UI

  • Model, thinking-level, and fast-mode overrides can be changed in an existing session with operator.write; administrator access is not required for these three controls. Read-only clients cannot change them.
  • These are session preferences for subsequent turns, not a promise to change an already-running model call. The composer disables the controls while a reply is running and while a model change is being applied.
  • The web chat thinking selector shows the explicit session override, or the inherited configured/provider default when no override is stored.
  • Refreshing, reloading, or compacting a conversation keeps an inherited choice inherited; it does not store the resolved level as an override. While model metadata is loading, refreshes retain the known thinking profile for the same model and runtime.
  • Selecting a level on the effort slider writes an explicit session override immediately via sessions.patch; it does not wait for the next send and it is not a one-shot thinkingOnce override.
  • Sending while model, reasoning, or speed picker changes are still being applied waits for every pending picker patch; if a change fails, the message stays unsent for review.
  • The effort control displays the resolved level, such as Medium or Off. To clear an override and return to inheritance, send /think default.
  • Explicit picker choices use their direct level labels while preserving provider labels when present (for example Maximum for a provider-labeled max option).
  • The picker uses thinkingLevels returned by the gateway session row/defaults, with thinkingOptions kept as a legacy label list. The browser UI does not keep its own provider regex list; plugins own model-specific level sets.
  • /think:<level> still works and updates the same stored session level, so chat directives and the picker stay in sync.

Translation:

Web 聊天界面

  • 在现有会话中，可以使用 operator.write 更改模型、推理级别和快速模式覆盖；这三个控件不需要管理员访问权限。只读客户端无法更改它们。
  • 这些是后续轮次的会话偏好，并非承诺更改已运行的模型调用。当回复正在运行或正在应用模型更改时，编辑器会禁用这些控件。
  • Web 聊天推理选择器显示明确的会话覆盖；若未存储覆盖，则显示继承的已配置/提供方默认值。
  • 刷新、重新加载或压缩会话会保持继承的选择为继承状态；它不会将解析后的级别存储为覆盖。在模型元数据加载期间，刷新会保留同一模型和运行时的已知推理配置。
  • 在努力程度滑块上选择某个级别会立即通过 sessions.patch 写入明确的会话覆盖；它不会等待下次发送，也不是一次性的 thinkingOnce 覆盖。
  • 如果模型、推理或速度选择器的更改仍处于应用状态时发送消息，会等待每个待处理的选择器补丁；如果某项更改失败，消息将保持未发送以供检查。
  • 努力程度控件显示解析后的级别，例如 Medium 或 Off。要清除覆盖并恢复为继承，请发送 /think default。
  • 显式选择器的选择会使用其直接级别标签，同时在存在时保留提供方标签（例如提供方标记为 max 的选项显示为 Maximum）。
  • 选择器使用网关会话行/默认值返回的 thinkingLevels，并保留 thinkingOptions 作为旧版标签列表。浏览器 UI 不维护自己的提供方正则表达式列表；插件拥有模型专属的级别集合。
  • /think:<level> 仍然有效，并更新相同的已存储会话级别，因此聊天指令和选择器保持同步。

Need "fast-mode" perhaps "快速模式". "thinking-level" -> "推理级别". Good.

Need ensure code identifiers unchanged: "operator.write", "sessions.patch", "thinkingOnce", "thinkingLevels", "thinkingOptions", "Medium", "Off", "max", "Maximum", "/think:". Good.

Now we need to ensure all headings have attr_list. Also heading titles translated. Need maybe "## Verbose directives (/verbose or /v)" translated as "## 详细输出指令 (/verbose or /v)" but anchor should be from original English. The attr_list in output must include #verbose-directives-verbose-or-v. Need ensure.

Also need for "Plugin trace directives (/trace)" anchor #plugin-trace-directives-trace. For "Reasoning visibility (/reasoning)" anchor #reasoning-visibility-reasoning. For "Related" #related. For "Heartbeats" #heartbeats. For "Web chat UI" #web-chat-ui.

Need think of exact anchor generation: The original English heading includes parentheses and slash. For "Plugin trace directives (/trace)", slug: "plugin-trace-directives-trace" (removing parentheses and slash). "Reasoning visibility (/reasoning)" -> "reasoning-visibility-reasoning". Good.

Need also consider if "Related" is heading level 2, anchor "related". Good.

Need produce output only translated Markdown, no preamble, no code fence around whole output. We'll provide.

Need think about "minimal" translation: "on" (minimal) -> "on（最小）" maybe "on（最少）" but "minimal" as minimal logging? The original says "Levels: on (minimal) | full | off (default)." So "minimal" describes the "on" level? Actually "on" is minimal? It says verbose levels: on (minimal) | full | off (default). Maybe "on" is minimal? Well we translate as "on（最小）". Good.

Need "Directive-only message" perhaps "仅含指令的消息" or "仅指令消息". Good.

Need "session verbose" maybe "会话的 verbose 模式" or "会话详细输出". Since "verbose" is an English adjective, but a setting name. We can keep "verbose" as is? The instruction says do not translate API names, commands, etc. "verbose" is not a brand but a mode name. In Chinese docs, could leave "verbose" or translate as "详细输出". For clarity, we can say "详细输出（verbose）"? But we already use "verbose" in many places. I think acceptable to keep "verbose" in text as a technical term, since it's a directive name. The rule says "Do NOT translate code identifiers, commands, file paths, API names, or brand/product names". "verbose" is not code but it's a directive/parameter name. I'd keep "verbose" as is, or use "Verbose" with original. But then we need translate prose. We can have "详细模式" but "verbose" remains as a term.

Let's read original first bullet: "- Levels: on (minimal) | full | off (default)." We can translate: "- 级别：on（最小）| full | off（默认）。" That's fine.

"Directive-only message toggles session verbose and replies Verbose logging enabled. / Verbose logging disabled.; invalid levels return a hint without changing state." We translate "session verbose" as "会话的 verbose 模式". Keep.

"/verbose off stores an explicit session override; clear it via the Sessions UI by choosing inherit." "Sessions UI" could be "会话（Sessions）界面" or "Sessions 界面". The rule says keep brand/product names? "Sessions UI" is a UI label; could leave "Sessions UI" as is. But since it's prose, translate as "会话界面" and mention "Sessions"? I'd say "Sessions 界面". Good.

"Internal gateway/webchat clients" -> "内部 gateway/WebChat 客户端" because gateway and webchat are product components? "webchat" might be "WebChat". Keep.

"agents that emit structured tool results" -> "会输出结构化工具结果的代理". "agents" is term, we translate to "代理", that's standard.

"Shell tools show their label without command text" -> "Shell 工具只显示其标签，不显示命令文本." "Shell" is a term, keep.

"separate bubbles" -> "独立气泡".

"streaming deltas" -> "流式增量" or "流式差异". Keep "流式增量".

"Tool failure summaries" -> "工具失败摘要".

"raw error detail suffixes" -> "原始错误详情后缀".

"in-flight" -> "进行中".

"shape" -> "形态" or "形式". Good.

"progress-draft tool lines" -> "进度草稿工具行".

"unabridged non-shell detail" -> "未删节的非 shell 细节".

"Standalone shell summaries require /verbose full for command text; progress drafts require the channel's explicit streaming.*.commandText: "raw" opt-in." Let's be careful: "Standalone shell summaries" maybe "独立的 shell 摘要". "require /verbose full for command text" -> "需要 /verbose full 才能显示命令文本". "progress drafts require the channel's explicit ... opt-in" -> "进度草稿需要渠道显式选择 streaming.*.commandText: "raw"." The phrase "opt-in" could be "选择启用". But keep as "显式选择" or "显式订阅". I'll use "显式选择 ... 作为启用选项". Hmm.

Need "Per-agent agents.entries.*.toolProgressDetail overrides the default." -> "按代理设置的 agents.entries.*.toolProgressDetail 会覆盖默认值。" Good.

Next plugin trace: "Plugin trace directives" heading. "trace" in "plugin trace output" maybe "插件跟踪输出". "Active Memory" is product feature, keep English. "diagnostic message" -> "诊断消息".

Reasoning: "thinking blocks" could be "思考块" or "推理块". Since reasoning visibility, "thinking blocks" are the internal chain-of-thought. We translate as "思考块" to preserve nuance. But we translated "thinking level" to "推理级别". Need consistency: heading "Reasoning visibility" -> "推理可见性". "thinking blocks" -> "思考块" okay.

"separate message prefixed with Thinking" -> "独立消息，前缀为 Thinking" (Backticks around Thinking).

"stream" as a level; we keep as code? In bullet stream is code span. Good.

"when the active channel supports reasoning previews" -> "当活跃渠道支持推理预览时".

"Channel previews remove recognized internal runtime context before delivery" -> "渠道预览会在交付前移除已识别的内部运行时上下文". Good.

"the original reasoning remains unchanged for model replay" -> "原始推理保持不变，供模型重放使用".

"Control UI history shows saved reasoning only for on, with View → Reasoning enabled." Could translate "Control UI" as "Control 界面" (keep Control? It's a product name). "历史记录" for history. "View → Reasoning" is a menu path; keep as is with arrow. We can say "启用 View → Reasoning". Good.

"Visible Control UI reasoning preserves Markdown paragraphs and fenced code blocks, including blank lines inside code." -> "可见的 Control 界面推理保留 Markdown 段落和围栏代码块，包括代码内的空行。" Good.

"Malformed local-model reasoning tags" -> "格式错误的本地模型推理标签". "Malformed" in code contexts often "畸形". I'll use "畸形（malformed）" or "格式错误". Let's pick "格式错误的本地模型推理标签". But "malformed" is an adjective; "畸形" is also fine. In Chinese technical writing "畸形" less common; "格式错误" or "无效" is better. I'll use "格式错误".

"Closed <think>...</think> blocks stay hidden on normal replies" -> "闭合的 <think>...</think> 块在普通回复中保持隐藏". Need keep <think>...</think> as inline code? In original it's backticks around full tag? Actually "<think>...</think>" yes. Keep.

"unclosed reasoning after already visible text is also hidden" -> "已经可见文本之后的未闭合推理也会被隐藏".

"If a reply is fully wrapped in a single unclosed opening tag and would otherwise deliver as empty text, OpenClaw removes the malformed opening tag and delivers the remaining text." -> "如果一条回复完全包裹在单个未闭合的起始标签中，并且否则会按空文本投递，OpenClaw 会移除该格式错误的起始标签并投递剩余文本。" The phrase "would otherwise deliver as empty text" means "否则将作为空文本交付". Good.

"Related" section: - "Elevated mode docs live in Elevated mode." We can say "提升模式文档位于 提升模式。" - "Slash commands — changing the thinking level mid-session" We can say "斜杠命令 — 在会话中更改推理级别" - "Configuration reference — where the thinking defaults are configured" -> "配置参考 — 推理默认值的配置位置" or "—— 配置推理默认值的位置". Good.

Need be careful with "thinking level" in "Related" - Actually original "changing the thinking level mid-session" maybe refers to "reasoning level". We can use "推理级别". The title "Reasoning visibility" uses "reasoning", so yes.

Heartbeats: "Heartbeat probe body is the configured heartbeat prompt" -> "心跳探测正文是配置好的心跳提示词". "Heartbeat" is a concept, can be "心跳". Good. "default: Follow the heartbeat monitor scratch context when provided. ..." Need keep default string exactly in code. We can wrap it in backticks as in original. Not translate inside code. Good. "Inline directives in a heartbeat message apply as usual (but avoid changing session defaults from heartbeats)." -> "心跳消息中的内联指令照常生效（但避免通过心跳更改会话默认值）。" Good. "Heartbeat delivery uses the last outbound-capable non-reasoning payload." -> "心跳投递使用最后一个可出站的非推理负载。" "outbound-capable" maybe "可出站". Good. "Separate reasoning or Thinking payloads remain internal, and a reasoning-only heartbeat result produces no alert." -> "单独的推理或 Thinking 负载保持内部使用，仅含推理的心跳结果不会产生警报。" Good.

Web chat UI: Need "Model, thinking-level, and fast-mode overrides" -> "模型、推理级别和快速模式覆盖". "fast-mode" might be "fast mode" (快速模式). Good. "with operator.write" Keep. "administrator access" -> "管理员访问权限" or "管理员权限". "Read-only clients cannot change them." -> "只读客户端无法更改它们."

"These are session preferences for subsequent turns, not a promise to change an already-running model call." -> "这些是后续轮次的会话偏好，并非承诺更改正在运行的模型调用。" Good. "The composer disables the controls while a reply is running and while a model change is being applied." -> "当回复正在运行或正在应用模型更改时，编辑器会禁用这些控件。" "composer" could be "输入区" or "编辑器". In web chat, "composer" is message input box. Let's translate as "编辑器" or "输入框". Better "编辑器" is common. Maybe "消息编辑器". We'll use "编辑器".

"The web chat thinking selector shows the explicit session override, or the inherited configured/provider default when no override is stored." -> "Web 聊天推理选择器显示明确的会话覆盖；如果未存储覆盖，则显示继承的已配置/提供方默认值。" Good. "Refreshing, reloading, or compacting a conversation keeps an inherited choice inherited; it does not store the resolved level as an override." -> "刷新、重新加载或压缩会话会保持继承的选择为继承状态；它不会将解析后的级别存储为覆盖。" Good. "While model metadata is loading, refreshes retain the known thinking profile for the same model and runtime." -> "在模型元数据加载期间，刷新会保留同一模型和运行时的已知推理配置。" "thinking profile" maybe "推理配置". Good. "Selecting a level on the effort slider writes an explicit session override immediately via sessions.patch; it does not wait for the next send and it is not a one-shot thinkingOnce override." -> "在努力程度滑块上选择某个级别会立即通过 sessions.patch 写入明确的会话覆盖；它不会等待下次发送，也不是一次性的 thinkingOnce 覆盖。" Good. "effort slider" maybe "努力滑块" or "程度滑块". In context of reasoning effort, "effort" is reasoning effort. "努力程度滑块" is okay. "Sending while model, reasoning, or speed picker changes are still being applied waits for every pending picker patch; if a change fails, the message stays unsent for review." -> "如果在模型、推理或速度选择器的更改仍处于应用状态时发送消息，会等待每个待处理的选择器补丁；如果某项更改失败，消息将保持未发送以供检查。" Good. "The effort control displays the resolved level, such as Medium or Off. To clear an override and return to inheritance, send /think default." -> "努力程度控件显示解析后的级别，例如 Medium 或 Off。要清除覆盖并恢复为继承，请发送 /think default。" Good. "Explicit picker choices use their direct level labels while preserving provider labels when present (for example Maximum for a provider-labeled max option)." -> "显式选择器的选择会使用其直接级别标签，同时在存在时保留提供方标签（例如提供方标记为 max 的选项显示为 Maximum）。" Good. "The picker uses thinkingLevels returned by the gateway session row/defaults, with thinkingOptions kept as a legacy label list. The browser UI does not keep its own provider regex list; plugins own model-specific level sets." -> "选择器使用网关会话行/默认值返回的 thinkingLevels，并保留 thinkingOptions 作为旧版标签列表。浏览器 UI 不维护自己的提供方正则表达式列表；插件拥有模型专属的级别集合。" Good. "/think:still works and updates the same stored session level, so chat directives and the picker stay in sync." -> "/think:仍然有效，并更新相同的已存储会话级别，因此聊天指令和选择器保持同步。" Need original has "/think:<level>" with backticks? In original: "-/think:` still works..." Yes keep.

Need perhaps "fast-mode" maybe "快速模式" but "fast-mode overrides" maybe "快速模式覆盖". Good.

Need "thinking-level" maybe "thinking level" but we can call "推理级别". But "reasoning" and "thinking" are used interchangeably. In the original, "thinking-level" in control UI? Actually "thinking selector" and "thinking level" in headings. We can choose "思考级别" or "推理级别"? Since "Reasoning visibility" is about reasoning. The "thinking blocks" are "思考块". "Thinking level" is a configuration of reasoning effort. In Chinese, "推理级别" is more standard. Fine.

Need ensure "Related" heading translation "相关文档" includes anchor #related. Good.

Need "Plugin trace directives (/trace)" anchor: #plugin-trace-directives-trace. We'll include exactly.

Potential issue: "verbatim directive" maybe "Directive-only message" -> "仅指令消息" (a message containing only the directive). Good.

Need "invalid levels return a hint without changing state." -> "无效级别返回提示而不改变状态。" Good.

Need "session verbose override" repeated.

Need "Authorized external channel senders may persist the session verbose override." -> "经授权的外部渠道发送者可以持久化会话 verbose 覆盖。" Good.

Need "Internal gateway/webchat clients need operator.admin to persist it." -> "内部 gateway/WebChat 客户端需要 operator.admin 权限才能持久化它。" Good.

Need "Inline directive affects only that message; session/global defaults apply otherwise." For each section, translated.

Need "Send /trace (or /trace:) with no argument to see the current trace level." Keep.

Need "Trace lines can appear in /status and as a follow-up diagnostic message after the normal assistant reply." -> "跟踪行可能出现在 /status 中，以及作为正常助手回复之后的后续诊断消息。" Good.

Need "Control UI history shows saved reasoning only for on, with View → Reasoning enabled." Need perhaps "Control UI" should be "Control 界面" not "控制界面". **View → Reasoning** is menu item. We keep.

Need "Visible Control UI reasoning preserves Markdown paragraphs and fenced code blocks, including blank lines inside code." "Visible" maybe "可见的". Good.

Need "Alias: /reason." -> "别名：/reason。" Keep.

Need "Resolution order" -> "解析顺序".

Need "Malformed local-model reasoning tags are handled conservatively." -> "格式错误的本地模型推理标签会被保守处理。" Good.

Need "Closed <think>...</think> blocks stay hidden on normal replies" -> "闭合的 <think>...</think> 块在普通回复中保持隐藏" (the exact text "normal replies" maybe "普通回复"). Good.

Need "unclosed reasoning after already visible text is also hidden." -> "已经可见文本之后的未闭合推理也会被隐藏。" Good.

Need "If a reply is fully wrapped in a single unclosed opening tag and would otherwise deliver as empty text, OpenClaw removes the malformed opening tag and delivers the remaining text." -> "如果一条回复完全包裹在单个未闭合的起始标签中，并且否则会作为空文本投递，OpenClaw 会移除该格式错误的起始标签并投递剩余文本。" Good.

Need "Heartbeats" heading "心跳" and anchor #heartbeats. Good.

Need "Web chat UI" heading "Web 聊天界面" or "Web 聊天 UI"? The original heading is "Web chat UI". Since UI is a term, we could translate as "Web 聊天界面". But maybe "UI" is a filename? No. "Web chat UI" in English heading. We can keep "Web chat UI" as a product interface name? Rule: brand/product names like "Ollama", "Docker" keep. "Web chat UI" is not a brand but a generic term. Translate to "Web 聊天界面". Anchor from original heading: "web-chat-ui" (since "UI" becomes "ui"). Good.

Need "fast-mode" maybe "fast mode" but should we translate "fast-mode" as "快速模式"? Yes.

Need "speed picker" -> "速度选择器". Good.

Need "effort control" and "effort slider" -> "努力程度控件/滑块". Good.

Need "thinking profile" maybe "推理配置" or "思考配置". Good.

Need "provider regex list" -> "提供方正则表达式列表". Good.

Need "plugins own model-specific level sets." -> "插件拥有模型专属的级别集合。" "own" as verb "拥有". Good.

Need "legacy label list" -> "旧版标签列表" or "遗留标签列表". "legacy" can be "旧版" or "遗留". Use "旧版" as common. Good.

Need "stored session level" -> "已存储的会话级别". Good.

Need "chat directives and the picker stay in sync" -> "聊天指令和选择器保持同步". Good.

Need "read-only clients" -> "只读客户端". Good.

Need "administrator access" -> "管理员访问权限". Good.

Need "the composer disables the controls while a reply is running and while a model change is being applied." -> "当回复正在运行或正在应用模型更改时，编辑器会禁用这些控件。" Good.

Need "Model, thinking-level, and fast-mode overrides can be changed in an existing session with operator.write" Could be "可以使用 operator.write 在现有会话中更改模型、推理级别和快速模式覆盖". Good.

Need "three controls" -> "这三个控件". Good.

Need "not a promise to change an already-running model call." -> "并非承诺更改已运行的模型调用。" Good.

Need "The web chat thinking selector shows..." -> "Web 聊天推理选择器显示..." Good.

Need "Refreshing, reloading, or compacting a conversation" -> "刷新、重新加载或压缩会话". "compacting a conversation" is a feature "压缩对话" maybe "压缩会话". Good.

Need "keeps an inherited choice inherited" -> "会保持继承的选择为继承状态". Good.

Need "it does not store the resolved level as an override." -> "它不会将解析后的级别存储为覆盖。" Good.

Need "While model metadata is loading, refreshes retain the known thinking profile for the same model and runtime." -> "在模型元数据加载期间，刷新会保留同一模型和运行时的已知推理配置。" Good.

Need "Selecting a level on the effort slider writes an explicit session override immediately via sessions.patch; it does not wait for the next send and it is not a one-shot thinkingOnce override." -> "在努力程度滑块上选择某个级别会立即通过 sessions.patch 写入明确的会话覆盖；它不会等待下次发送，也不是一次性的 thinkingOnce 覆盖。" Good.

Need "Sending while model, reasoning, or speed picker changes are still being applied waits for every pending picker patch; if a change fails, the message stays unsent for review." -> "如果在模型、推理或速度选择器的更改仍处于应用状态时发送消息，会等待每个待处理的选择器补丁；如果某项更改失败，消息将保持未发送以供检查。" Good.

Need "The effort control displays the resolved level, such as Medium or Off. To clear an override and return to inheritance, send /think default." -> "努力程度控件显示解析后的级别，例如 Medium 或 Off。要清除覆盖并恢复为继承，请发送 /think default。" Good.

Need "Explicit picker choices use their direct level labels while preserving provider labels when present (for example Maximum for a provider-labeled max option)." -> "显式选择器的选择会使用其直接级别标签，同时在存在时保留提供方标签（例如提供方标记为 max 的选项显示为 Maximum）。" Good.

Need "The picker uses thinkingLevels returned by the gateway session row/defaults, with thinkingOptions kept as a legacy label list." -> "选择器使用网关会话行/默认值返回的 thinkingLevels，并保留 thinkingOptions 作为旧版标签列表。" Good.

Need "The browser UI does not keep its own provider regex list; plugins own model-specific level sets." -> "浏览器 UI 不维护自己的提供方正则表达式列表；插件拥有模型专属的级别集合。" Good.

Need "/think:still works and updates the same stored session level, so chat directives and the picker stay in sync." -> "/think:` 仍然有效，并更新相同的已存储会话级别，因此聊天指令和选择器保持同步。" Good.

Now, need to be careful about "Levels: on (minimal) | full | off (default)." The "minimal" is outside code, translate. But "on" and "off" are code. We'll do "级别：on（最小）| full | off（默认）。" Good.

"Directive-only message toggles session plugin trace output and replies Plugin trace enabled. / Plugin trace disabled.." -> "仅指令消息切换会话的插件跟踪输出，并回复 Plugin trace enabled. / Plugin trace disabled.。" Good.

Need "/trace is narrower than /verbose: it only exposes plugin-owned trace/debug lines such as Active Memory debug summaries." -> "/trace 比 /verbose 更窄：它只暴露插件拥有的跟踪/调试行，例如 Active Memory 调试摘要。" Good.

Need "Trace lines can appear in /status and as a follow-up diagnostic message after the normal assistant reply." -> "跟踪行可能出现在 /status 中，并作为正常助手回复之后的后续诊断消息出现。" Good.

Need "Reasoning visibility" heading "推理可见性 (/reasoning) {#reasoning-visibility-reasoning}" (or "推理可见性 (/reasoning) {#reasoning-visibility-reasoning}").

Need "Levels: on|off|stream." -> "级别：on|off|stream。" Good.

Need "Directive-only message toggles whether thinking blocks are shown in replies." -> "仅指令消息切换是否在回复中显示思考块。" Good.

Need "When enabled, reasoning is sent as a separate message prefixed with Thinking." -> "启用时，推理会作为独立消息发送，前缀为 Thinking。" Good.

Need "stream: streams reasoning while the reply is generating when the active channel supports reasoning previews, then sends the final answer without reasoning." -> "stream：当活跃渠道支持推理预览时，在回复生成期间流式显示推理，然后发送最终答案，不附带推理。" Good.

Need "Channel previews remove recognized internal runtime context before delivery; the original reasoning remains unchanged for model replay." -> "渠道预览会在交付前移除已识别的内部运行时上下文；原始推理保持不变，供模型重放使用。" Good.

Need "Control UI history shows saved reasoning only for on, with View → Reasoning enabled. off and stream keep it hidden, including after reload." -> "Control 界面历史记录仅对 on 显示已保存的推理，并启用 View → Reasoning。off 和 stream 保持隐藏，包括重新加载之后。" Good.

Need "Visible Control UI reasoning preserves Markdown paragraphs and fenced code blocks, including blank lines inside code." -> "可见的 Control 界面推理保留 Markdown 段落和围栏代码块，包括代码内的空行。" Good.

Need "Alias: /reason." -> "别名：/reason。" Good.

Need "Send /reasoning (or /reasoning:) with no argument to see the current reasoning level." -> "发送不带参数的 /reasoning（或 /reasoning:）可查看当前推理级别。" Good.

Need "Resolution order: inline directive, then session override, then per-agent default (agents.entries.*.reasoningDefault), then global default (agents.defaults.reasoningDefault), then fallback (off)." -> "解析顺序：内联指令，然后是会话覆盖，然后是按代理默认值（agents.entries.*.reasoningDefault），然后是全局默认值（agents.defaults.reasoningDefault），最后是回退值（off）。" Good.

Need "Malformed local-model reasoning tags are handled conservatively." -> "格式错误的本地模型推理标签会被保守处理。" Good.

Need "Closed <think>...</think> blocks stay hidden on normal replies, and unclosed reasoning after already visible text is also hidden." -> "闭合的 <think>...</think> 块在普通回复中保持隐藏；已经可见文本之后的未闭合推理也会被隐藏。" Good.

Need "If a reply is fully wrapped in a single unclosed opening tag and would otherwise deliver as empty text, OpenClaw removes the malformed opening tag and delivers the remaining text." -> "如果一条回复完全包裹在单个未闭合的起始标签中，并且否则会作为空文本投递，OpenClaw 会移除该格式错误的起始标签并投递剩余文本。" Good.

Need "Related" section: "Elevated mode docs live in Elevated mode." -> "提升模式文档位于 提升模式。" Good. "Slash commands — changing the thinking level mid-session" -> "斜杠命令 — 在会话中更改推理级别" Good. "Configuration reference — where the thinking defaults are configured" -> "配置参考 — 推理默认值的配置位置" Good.

Need "Heartbeats" section: "Heartbeat probe body is the configured heartbeat prompt (default: Follow the heartbeat monitor scratch context when provided. Recurring tasks are automations; create or change their schedules with the automations tool, not heartbeat scratch. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply NO_REPLY.). Inline directives in a heartbeat message apply as usual (but avoid changing session defaults from heartbeats)." Translation: "心跳探测正文是配置好的心跳提示词（默认：Follow the heartbeat monitor scratch context when provided. Recurring tasks are automations; create or change their schedules with the automations tool, not heartbeat scratch. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply NO_REPLY.）。心跳消息中的内联指令照常生效（但避免通过心跳更改会话默认值）。" Good.

"Heartbeat delivery uses the last outbound-capable non-reasoning payload. Separate reasoning or Thinking payloads remain internal, and a reasoning-only heartbeat result produces no alert." Translation: "心跳投递使用最后一个可出站的非推理负载。单独的推理或 Thinking 负载保持内部使用，仅含推理的心跳结果不会产生警报。" Good.

Need "Web chat UI" section: We have all.

Now, need to ensure no translation of code blocks? There are no code blocks except inline code. We keep all backtick content exactly. For headings, command names are not code, but we keep them unchanged in heading. We should not translate /verbose to Chinese. Good.

Potential issue: "verbose" in "Verbose logging enabled." is inside code string; keep unchanged. We did.

Need "on (minimal)" - "minimal" inside parentheses after on. We translated "minimal" to "最小". Good.

Need "off (default)" - "默认". Good.

Need "invalid levels return a hint without changing state." -> "无效级别返回提示而不改变状态。" Good.

Need "Authorized external channel senders may persist the session verbose override." -> "经授权的外部渠道发送者可以持久化会话 verbose 覆盖。" Good.

Need "Internal gateway/webchat clients need operator.admin to persist it." -> "内部 gateway/WebChat 客户端需要 operator.admin 权限才能持久化它。" Good.

Need "Inline directive affects only that message; session/global defaults apply otherwise." -> "内联指令只影响该条消息；否则应用会话/全局默认值。" Good.

Need "Send /verbose (or /verbose:) with no argument to see the current verbose level." -> "发送不带参数的 /verbose（或 /verbose:）可查看当前 verbose 级别。" Good.

Need "When verbose is on, agents that emit structured tool results send each tool call back as its own safe metadata-only message." -> "当 verbose 开启时，会输出结构化工具结果的代理会将每次工具调用作为独立的仅元数据安全消息发回。" Good. Maybe "agents" could be "智能体" but "代理" is fine. Could use "agent" in English? The rule says translate prose, so Chinese.

Need "Shell tools show their label without command text." -> "Shell 工具只显示其标签，不显示命令文本。" Good.

Need "These tool summaries are sent as soon as each tool starts (separate bubbles), not as streaming deltas." -> "这些工具摘要会在每个工具启动时立即发送（独立气泡），而不是作为流式增量发送。" Good.

Need "Tool failure summaries remain visible in normal mode, but raw error detail suffixes are hidden unless verbose is full." -> "工具失败摘要仍会在普通模式下可见，但原始错误详情后缀会隐藏，除非 verbose 为 full。" Good.

Need "When verbose is full, tool outputs are also forwarded after completion (separate bubble, truncated to a safe length)." -> "当 verbose 为 full 时，工具输出也会在完成后转发（独立气泡，截断到安全长度）。" Good.

Need "If you toggle /verbose on|full|off while a run is in-flight, subsequent tool bubbles honor the new setting." -> "如果在运行进行中切换 /verbose on|full|off，后续工具气泡会遵循新设置。" Good.

Need "agents.defaults.toolProgressDetail controls the shape of /verbose tool summaries and progress-draft tool lines." -> "agents.defaults.toolProgressDetail 控制 /verbose 工具摘要和进度草稿工具行的形态。" Good.

Need "Use "explain" (default) for compact human labels and "raw" for unabridged non-shell detail." -> "使用 "explain"（默认）获得紧凑的人类可读标签，使用 "raw" 获得未删节的非 shell 细节。" Good.

Need "Standalone shell summaries require /verbose full for command text; progress drafts require the channel's explicit streaming.*.commandText: "raw" opt-in." -> "独立 shell 摘要需要 /verbose full 才能显示命令文本；进度草稿需要渠道显式选择 streaming.*.commandText: "raw"。" Good.

Need "Per-agent agents.entries.*.toolProgressDetail overrides the default." -> "按代理设置的 agents.entries.*.toolProgressDetail 会覆盖默认值。" Good.

Need "The browser UI does not keep its own provider regex list" -> "浏览器 UI 不维护自己的提供方正则表达式列表" Good.

Need "plugins own model-specific level sets." -> "插件拥有模型专属的级别集合。" Good.

Need "The composer disables the controls while a reply is running and while a model change is being applied." -> "当回复正在运行或正在应用模型更改时，编辑器会禁用这些控件。" Maybe "composer" is "消息编辑器" or "输入区". "编辑器" okay.

Need "Refreshing, reloading, or compacting a conversation keeps an inherited choice inherited" -> "刷新、重新加载或压缩会话会保持继承的选择为继承状态" Maybe "compacting" in chat context "压缩对话" more natural. "conversation" could be "对话" not "会话". The doc uses "session" elsewhere. But "conversation" = 对话. Could say "刷新、重新加载或压缩对话". Use "对话" for conversation. Good.

Need "The web chat thinking selector" -> "Web 聊天推理选择器". Good.

Need "The effort control displays..." -> "努力程度控件" good.

Need "Explicit picker choices use their direct level labels while preserving provider labels when present (for example Maximum for a provider-labeled max option)." -> "显式选择器的选择会使用其直接级别标签，同时在存在时保留提供方标签（例如提供方标记为 max 的选项显示为 Maximum）。" Good.

Need "The picker uses thinkingLevels returned by the gateway session row/defaults" -> "选择器使用网关会话行/默认值返回的 thinkingLevels". Could "gateway session row/defaults" be "网关会话行/默认值". Fine.

Need "with thinkingOptions kept as a legacy label list." -> "并保留 thinkingOptions 作为旧版标签列表。" Good.

Need "/think:<level> still works and updates the same stored session level" -> "/think:<level> 仍然有效，并更新相同的已存储会话级别" Good.

Need "so chat directives and the picker stay in sync." -> "因此聊天指令和选择器保持同步。" Good.

Potential challenge: "verbatim directive" not in doc? We have "Directive-only message" repeated. Fine.

Need to ensure Markdown table? None.

Need to preserve blockquote? None.

Need to preserve "NO_REPLY" inside code string, unchanged. Good.

Need to preserve "OpenClaw" exactly. Good.

Need to preserve "Active Memory" exactly. Good.

Need to preserve "Control UI" as "Control 界面" or "Control UI" maybe. I used "Control 界面". That's okay.

Need to preserve "View → Reasoning" (with Unicode arrow). Keep.

Need to preserve "Elevated mode" link text? We translated link text to "提升模式". That's okay. But is "Elevated mode" a document title and should be kept? The rule: "Do NOT translate code identifiers, commands, file paths, API names, or brand/product names". Document title "Elevated mode" is prose? It's a doc name. There is an "elevated.md" file. Link text could be left as "Elevated mode" to avoid confusion, but the instruction says translate prose text. The link text is prose. I'll translate. But maybe if "Elevated mode" is a title of a mode, it's a feature name? "Elevated mode" is a mode, maybe product-specific. The rule says "brand/product names (e.g. Ollama, Docker, GPU, REST, JSON, Token, Prompt, Claude Code)" and "Elevated mode" not brand. We could translate. But if it's a proper mode name, we might keep "Elevated mode" with "提升模式（Elevated mode）"? To be safe, perhaps keep "Elevated mode" as is because it is a heading title of another doc? But "elevated.md" is a file path, and "Elevated mode" is the title. The instruction says translate only prose text; "Elevated mode docs live in Elevated mode." The sentence is prose, link text is prose. I think translate to "提升模式". Good.

Similarly "Slash commands" link text should be "斜杠命令". "Configuration reference" -> "配置参考". Good.

Need maybe "Related" heading anchor: #related. Good.

Need "Verbose directives" heading translation maybe "详细输出指令" or "Verbose 指令". Let's choose "详细输出指令" but include "verbose" concept? The heading in English "Verbose directives" refers to directives that control verbose logging. We can translate to "Verbose 输出指令" or "详细输出指令". In the bullets, we keep "verbose" as a term. I'd use "详细输出指令" to be consistent. But the command names remain. Anchor from original. Let's set: "## 详细输出指令 (/verbose or /v) {#verbose-directives-verbose-or-v}"

Need "Plugin trace directives" -> "插件跟踪指令". Good. Need "Reasoning visibility" -> "推理可见性". Good. Need "Web chat UI" -> "Web 聊天界面". Good.

Need check if "trace" should be "追踪" instead of "跟踪". Both acceptable. Use "跟踪".

Need "size" not relevant.

Need "fast-mode" in first bullet of Web chat UI: "Model, thinking-level, and fast-mode overrides can be changed in an existing session with operator.write; administrator access is not required for these three controls." We translated "Model, thinking-level, and fast-mode overrides" as "模型、推理级别和快速模式覆盖". Is "fast-mode" a codename? Could be "fast mode". Good.

Potential issue: "thinking-level" in original is a specific setting maybe "thinking level" (level of thinking). We use "推理级别". Good.

Need "effort slider" in "Selecting a level on the effort slider" maybe "effort" is "reasoning effort" (努力程度). Good.

Need "sessions.patch" keep.

Need "thinkingOnce" keep.

Need "No preamble, no code fence around whole output." We'll output just the translated Markdown.

Let's assemble the final output with proper headings and anchors.

Double-check exact anchor strings: - "## Verbose directives (/verbose or /v)" -> "#verbose-directives-verbose-or-v". Need perhaps "verbose-or-v" where "v" is a standalone letter. Good. - "## Plugin trace directives (/trace)" -> "#plugin-trace-directives-trace". The original heading has "trace" not "trace-directives"? Let's derive: "Plugin trace directives (/trace)" -> slug from words: "plugin", "trace", "directives", "trace" (because "(/trace)" becomes "trace"), so "plugin-trace-directives-trace". Yes. - "## Reasoning visibility (/reasoning)" -> "reasoning-visibility-reasoning". - "## Related" -> related. - "## Heartbeats" -> heartbeats. - "## Web chat UI" -> web-chat-ui.

Need perhaps the slug should include punctuation "v" not "verbose" because "(/verbose or /v)" has "/v" which becomes "v". Yes.

Potential issue with Markdown attr_list syntax: "## Heading {#anchor}" requires a blank line after? No, attr_list is on same line. Good.

Need "Output ONLY the translated Markdown, no preamble, no code fence around the whole output." We'll deliver raw Markdown.

Let's write final.## 详细输出指令 (/verbose or /v) {#verbose-directives-verbose-or-v}

  • 级别：on（最小）| full | off（默认）。
  • 仅指令消息切换会话的 verbose 模式，并回复 Verbose logging enabled. / Verbose logging disabled.；无效级别返回提示而不改变状态。
  • /verbose off 存储一个明确的会话覆盖；可通过会话（Sessions）界面选择 inherit 来清除它。
  • 经授权的外部渠道发送者可以持久化会话 verbose 覆盖。内部 gateway/WebChat 客户端需要 operator.admin 权限才能持久化它。
  • 内联指令只影响该条消息；否则应用会话/全局默认值。
  • 发送不带参数的 /verbose（或 /verbose:）可查看当前 verbose 级别。
  • 当 verbose 开启时，会输出结构化工具结果的代理会将每次工具调用作为独立的仅元数据安全消息发回。Shell 工具只显示其标签，不显示命令文本。这些工具摘要会在每个工具启动时立即发送（独立气泡），不是作为流式增量发送。
  • 工具失败摘要仍会在普通模式下可见，但原始错误详情后缀会隐藏，除非 verbose 为 full。
  • 当 verbose 为 full 时，工具输出也会在完成后转发（独立气泡，截断到安全长度）。如果在运行进行中切换 /verbose on|full|off，后续工具气泡会遵循新设置。
  • agents.defaults.toolProgressDetail 控制 /verbose 工具摘要和进度草稿工具行的形态。使用 "explain"（默认）获得紧凑的人类可读标签，使用 "raw" 获得未删节的非 shell 细节。独立 shell 摘要需要 /verbose full 才能显示命令文本；进度草稿需要渠道显式选择 streaming.*.commandText: "raw"。按代理设置的 agents.entries.*.toolProgressDetail 会覆盖默认值。
  • /verbose on: 🛠️ Exec
  • /verbose full + explain: 🛠️ Exec: check JS syntax for /tmp/app.js
  • /verbose full + raw: 🛠️ Exec: check JS syntax for /tmp/app.js, node --check /tmp/app.js

插件跟踪指令 (/trace)

  • 级别：on | off（默认）。
  • 仅指令消息切换会话的插件跟踪输出，并回复 Plugin trace enabled. / Plugin trace disabled.。
  • 内联指令只影响该条消息；否则应用会话/全局默认值。
  • 发送不带参数的 /trace（或 /trace:）可查看当前跟踪级别。
  • /trace 比 /verbose 更窄：它只暴露插件拥有的跟踪/调试行，例如 Active Memory 调试摘要。
  • 跟踪行可能出现在 /status 中，并作为正常助手回复之后的后续诊断消息出现。

推理可见性 (/reasoning)

  • 级别：on|off|stream。
  • 仅指令消息切换是否在回复中显示思考块。
  • 启用时，推理会作为独立消息发送，前缀为 Thinking。
  • stream：当活跃渠道支持推理预览时，在回复生成期间流式显示推理，然后发送最终答案，不附带推理。渠道预览会在交付前移除已识别的内部运行时上下文；原始推理保持不变，供模型重放使用。
  • Control 界面历史记录仅对 on 显示已保存的推理，并启用 View → Reasoning。off 和 stream 保持隐藏，包括重新加载之后。
  • 可见的 Control 界面推理保留 Markdown 段落和围栏代码块，包括代码内的空行。
  • 别名：/reason。
  • 发送不带参数的 /reasoning（或 /reasoning:）可查看当前推理级别。
  • 解析顺序：内联指令，然后是会话覆盖，然后是按代理默认值（agents.entries.*.reasoningDefault），然后是全局默认值（agents.defaults.reasoningDefault），最后是回退值（off）。

格式错误的本地模型推理标签会被保守处理。闭合的 <think>...</think> 块在普通回复中保持隐藏；已经可见文本之后的未闭合推理也会被隐藏。如果一条回复完全包裹在单个未闭合的起始标签中，并且否则会作为空文本投递，OpenClaw 会移除该格式错误的起始标签并投递剩余文本。

心跳

  • 心跳探测正文是配置好的心跳提示词（默认：Follow the heartbeat monitor scratch context when provided. Recurring tasks are automations; create or change their schedules with the automations tool, not heartbeat scratch. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply NO_REPLY.）。心跳消息中的内联指令照常生效（但避免通过心跳更改会话默认值）。
  • 心跳投递使用最后一个可出站的非推理负载。单独的推理或 Thinking 负载保持内部使用，仅含推理的心跳结果不会产生警报。

Web 聊天界面

  • 在现有会话中，可以使用 operator.write 更改模型、推理级别和快速模式覆盖；这三个控件不需要管理员访问权限。只读客户端无法更改它们。
  • 这些是后续轮次的会话偏好，并非承诺更改已运行的模型调用。当回复正在运行或正在应用模型更改时，编辑器会禁用这些控件。
  • Web 聊天推理选择器显示明确的会话覆盖；如果未存储覆盖，则显示继承的已配置/提供方默认值。
  • 刷新、重新加载或压缩对话会保持继承的选择为继承状态；它不会将解析后的级别存储为覆盖。在模型元数据加载期间，刷新会保留同一模型和运行时的已知推理配置。
  • 在努力程度滑块上选择某个级别会立即通过 sessions.patch 写入明确的会话覆盖；它不会等待下次发送，也不是一次性的 thinkingOnce 覆盖。
  • 如果在模型、推理或速度选择器的更改仍处于应用状态时发送消息，会等待每个待处理的选择器补丁；如果某项更改失败，消息将保持未发送以供检查。
  • 努力程度控件显示解析后的级别，例如 Medium 或 Off。要清除覆盖并恢复为继承，请发送 /think default。
  • 显式选择器的选择会使用其直接级别标签，同时在存在时保留提供方标签（例如提供方标记为 max 的选项显示为 Maximum）。
  • 选择器使用网关会话行/默认值返回的 thinkingLevels，并保留 thinkingOptions 作为旧版标签列表。浏览器 UI 不维护自己的提供方正则表达式列表；插件拥有模型专属的级别集合。
  • /think:<level> 仍然有效，并更新相同的已存储会话级别，因此聊天指令和选择器保持同步。

提供商配置文件

  • 提供商插件可以暴露 resolveThinkingProfile(ctx) 来定义模型支持的级别和默认值。
  • 代理 Claude 模型的提供商插件应复用来自 openclaw/plugin-sdk/provider-model-shared 的 resolveClaudeThinkingProfile(modelId)，以便直接 Anthropic 目录和代理目录保持一致。
  • 每个配置文件级别都有一个存储的规范 id（off、minimal、low、medium、high、xhigh、adaptive、max 或 ultra），并且可以包含显示 label。二值提供商使用 { id: "low", label: "on" }。
  • 配置文件钩子在可用时会接收合并后的目录事实，包括 reasoning、thinkingLevelMap、compat.thinkingFormat、compat.supportsReasoningEffort 和 compat.supportedReasoningEfforts。使用这些事实，仅在已配置的请求契约支持匹配负载时，才暴露二值或自定义配置文件。thinkingLevelMap 中的 null 条目会在选择默认值之前移除该级别。
  • 需要验证显式 thinking 覆盖的工具插件应使用 api.runtime.agent.resolveThinkingPolicy({ provider, model, agentRuntime }) 以及 api.runtime.agent.normalizeThinkingLevel(...)；它们不应维护自己的提供商/模型级别列表。当工具拥有执行路径时（例如始终嵌入的运行），请传递 agentRuntime。
  • 可以访问已配置自定义模型元数据的工具插件可以将 catalog 传入 resolveThinkingPolicy，以便 compat.supportedReasoningEfforts 的选入项反映在插件端验证中。
  • 已发布的旧版钩子（supportsXHighThinking、isBinaryThinking 和 resolveDefaultThinkingLevel）仍作为兼容性适配器保留，但新的自定义级别集应使用 resolveThinkingProfile。
  • Gateway 行/默认值会暴露 thinkingLevels、thinkingOptions 和 thinkingDefault，以便 ACP/聊天客户端渲染与运行时验证使用的相同配置文件 id 和 label。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 cl/openclaw