chore(i18n): refresh zh-CN translations

2026-05-01 23:05:10 +00:00 · 2026-05-01 23:05:10 +00:00 · bdb5d0e24f
commit bdb5d0e24f
parent e48dd0d46f
4 changed files with 561 additions and 368 deletions
--- a/docs/zh-CN/channels/access-groups.md
+++ b/docs/zh-CN/channels/access-groups.md
@ -0,0 +1,189 @@
+---
+read_when:
+    - 在多个消息渠道中配置相同的允许列表
+    - 共享私信和群组发送者访问规则
+    - 审查消息渠道访问控制
+summary: 用于消息渠道的可复用发送者允许名单
+title: 访问组
+x-i18n:
+    generated_at: "2026-05-01T23:03:17Z"
+    model: gpt-5.5
+    provider: openai
+    source_hash: fc7bc1d4fb80e5c5d4e72b190d49821aa93ced575eafcf89864ac800e8558f94
+    source_path: channels/access-groups.md
+    workflow: 16
+---
+
+访问组是你定义一次、并通过 `accessGroup:<name>` 从渠道允许列表引用的具名发送者列表。
+
+当同一批人应被允许使用多个消息渠道，或一个受信任集合应同时应用于私信和群组发送者授权时，请使用它们。
+
+访问组本身不会授予访问权限。只有当允许列表字段引用某个组时，该组才有意义。
+
+## 静态消息发送者组
+
+静态发送者组使用 `type: "message.senders"`。
+
+```json5
+{
+  accessGroups: {
+    operators: {
+      type: "message.senders",
+      members: {
+        "*": ["global-owner-id"],
+        discord: ["discord:123456789012345678"],
+        telegram: ["987654321"],
+        whatsapp: ["+15551234567"],
+      },
+    },
+  },
+}
+```
+
+成员列表按消息渠道 ID 作为键：
+
+| 键        | 含义                                                                 |
+| ---------- | ----------------------------------------------------------------------- |
+| `"*"`      | 对引用该组的每个消息渠道检查的共享条目。 |
+| `discord`  | 仅用于 Discord 允许列表匹配时检查的条目。                    |
+| `telegram` | 仅用于 Telegram 允许列表匹配时检查的条目。                   |
+| `whatsapp` | 仅用于 WhatsApp 允许列表匹配时检查的条目。                   |
+
+条目会使用目标渠道的常规 `allowFrom` 规则进行匹配。OpenClaw 不会在渠道之间转换发送者 ID。如果 Alice 同时有 Telegram ID 和 Discord ID，请将两个 ID 都列在相应的键下。
+
+## 从允许列表引用组
+
+在消息渠道路径支持发送者允许列表的任何位置，都可以使用 `accessGroup:<name>` 引用组。
+
+私信允许列表示例：
+
+```json5
+{
+  accessGroups: {
+    operators: {
+      type: "message.senders",
+      members: {
+        discord: ["discord:123456789012345678"],
+        telegram: ["987654321"],
+      },
+    },
+  },
+  channels: {
+    discord: {
+      dmPolicy: "allowlist",
+      allowFrom: ["accessGroup:operators"],
+    },
+    telegram: {
+      dmPolicy: "allowlist",
+      allowFrom: ["accessGroup:operators"],
+    },
+  },
+}
+```
+
+群组发送者允许列表示例：
+
+```json5
+{
+  accessGroups: {
+    oncall: {
+      type: "message.senders",
+      members: {
+        whatsapp: ["+15551234567"],
+        googlechat: ["users/1234567890"],
+      },
+    },
+  },
+  channels: {
+    whatsapp: {
+      groupPolicy: "allowlist",
+      groupAllowFrom: ["accessGroup:oncall"],
+    },
+    googlechat: {
+      spaces: {
+        "spaces/AAA": {
+          users: ["accessGroup:oncall"],
+        },
+      },
+    },
+  },
+}
+```
+
+你可以混合使用组和直接条目：
+
+```json5
+{
+  channels: {
+    discord: {
+      dmPolicy: "allowlist",
+      allowFrom: ["accessGroup:operators", "discord:123456789012345678"],
+    },
+  },
+}
+```
+
+## 支持的消息渠道路径
+
+访问组可用于共享的消息渠道授权路径，包括：
+
+- 私信发送者允许列表，例如 `channels.<channel>.allowFrom`
+- 群组发送者允许列表，例如 `channels.<channel>.groupAllowFrom`
+- 使用相同发送者匹配规则的渠道特定按房间发送者允许列表
+- 复用消息渠道发送者允许列表的命令授权路径
+
+渠道支持取决于该渠道是否通过共享的 OpenClaw 发送者授权辅助工具接入。当前内置支持包括 Discord、Google Chat、Nostr、WhatsApp、Zalo 和 Zalo Personal。静态 `message.senders` 组设计为与渠道无关，因此新的消息渠道应通过使用共享的插件 SDK 辅助工具来支持它们，而不是自定义允许列表展开。
+
+## Discord 渠道受众
+
+Discord 还支持动态访问组类型：
+
+```json5
+{
+  accessGroups: {
+    maintainers: {
+      type: "discord.channelAudience",
+      guildId: "1456350064065904867",
+      channelId: "1456744319972282449",
+      membership: "canViewChannel",
+    },
+  },
+  channels: {
+    discord: {
+      dmPolicy: "allowlist",
+      allowFrom: ["accessGroup:maintainers"],
+    },
+  },
+}
+```
+
+`discord.channelAudience` 表示“允许当前可以查看此服务器渠道的 Discord 私信发送者”。OpenClaw 会在授权时通过 Discord 解析发送者，并应用 Discord `ViewChannel` 权限规则。
+
+当某个 Discord 渠道已经是某个团队的事实来源时使用此功能，例如 `#maintainers` 或 `#on-call`。
+
+要求和失败行为：
+
+- 机器人需要能访问该服务器和渠道。
+- 机器人需要 Discord 开发者门户中的 **Server Members Intent**。
+- 当 Discord 返回 `Missing Access`、无法将发送者解析为服务器成员，或渠道属于另一个服务器时，访问组会失败关闭。
+
+更多 Discord 特定示例：[Discord 访问控制](/zh-CN/channels/discord#access-control-and-routing)
+
+## 安全说明
+
+- 访问组是允许列表别名，不是角色。它们本身不会创建所有者、批准配对请求或授予工具权限。
+- `dmPolicy: "open"` 仍然要求有效的私信允许列表中包含 `"*"`。引用访问组不等同于公共访问。
+- 缺失的组名会失败关闭。如果 `allowFrom` 包含 `accessGroup:operators` 而 `accessGroups.operators` 不存在，则该条目不会授权任何人。
+- 保持渠道 ID 稳定。当渠道同时支持数字/用户 ID 和显示名称时，优先使用数字/用户 ID。
+
+## 故障排除
+
+如果某个发送者本应匹配但被阻止：
+
+1. 确认允许列表字段包含精确的 `accessGroup:<name>` 引用。
+2. 确认 `accessGroups.<name>.type` 正确。
+3. 确认发送者 ID 列在匹配的渠道键下，或列在 `"*"` 下。
+4. 确认该条目使用该渠道的常规允许列表语法。
+5. 对于 Discord 渠道受众，确认机器人可以看到服务器渠道，并且已启用 Server Members Intent。
+
+编辑访问控制配置后运行 `openclaw doctor`。它会在运行时之前捕获许多无效的允许列表和策略组合。
--- a/docs/zh-CN/channels/discord.md
+++ b/docs/zh-CN/channels/discord.md
--- a/docs/zh-CN/channels/groups.md
+++ b/docs/zh-CN/channels/groups.md
@ -2,36 +2,36 @@
 read_when:
    - 更改群聊行为或提及门控
 sidebarTitle: Groups
-summary: 跨各个界面的群聊行为（Discord/iMessage/Matrix/Microsoft Teams/Signal/Slack/Telegram/WhatsApp/Zalo）
+summary: 跨各界面的群聊行为（Discord/iMessage/Matrix/Microsoft Teams/Signal/Slack/Telegram/WhatsApp/Zalo）
 title: 群组
 x-i18n:
-    generated_at: "2026-05-01T18:34:39Z"
+    generated_at: "2026-05-01T23:03:10Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 1a75fe41f3a214c9b7d59db19c1622321d43bc16340ea70a43f1547b45c79cf0
+    source_hash: 5cc33dbbcf5504cae5caa003b7427d99f5c1a2d7c850dedd5d1f58a2fe44fa04
    source_path: channels/groups.md
    workflow: 16
 ---

-OpenClaw 在不同表面上一致处理群聊：Discord、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zalo。
+OpenClaw 在各个入口上一致地处理群聊：Discord、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zalo。

 ## 新手简介（2 分钟）

-OpenClaw “存在于”你自己的消息账号中。没有单独的 WhatsApp bot 用户。如果**你**在某个群组中，OpenClaw 就能看到该群组并在那里响应。
+OpenClaw “驻留”在你自己的消息账号中。没有单独的 WhatsApp bot 用户。如果**你**在某个群组中，OpenClaw 就能看到该群组并在那里回复。

 默认行为：

- 群组受到限制（`groupPolicy: "allowlist"`）。
- 回复需要提及，除非你明确禁用提及门控。
- 群组/渠道中的普通最终回复默认是私密的。可见房间输出使用 `message` 工具。
+- 群组受限制（`groupPolicy: "allowlist"`）。
+- 回复需要提及，除非你显式禁用提及门控。
+- 群组/渠道中的普通最终回复默认是私密的。可见的房间输出使用 `message` 工具。

-换句话说：允许列表中的发送者可以通过提及 OpenClaw 来触发它。
+也就是说：允许列表中的发送者可以通过提及 OpenClaw 来触发它。

 <Note>
-**简而言之**
+**摘要**

- **私信访问权限**由 `*.allowFrom` 控制。
- **群组访问权限**由 `*.groupPolicy` + 允许列表（`*.groups`、`*.groupAllowFrom`）控制。
+- **私信访问**由 `*.allowFrom` 控制。
+- **群组访问**由 `*.groupPolicy` + 允许列表（`*.groups`、`*.groupAllowFrom`）控制。
 - **回复触发**由提及门控（`requireMention`、`/activation`）控制。

 </Note>
@ -48,18 +48,18 @@ otherwise -> reply
 ## 可见回复

 对于群组/渠道房间，OpenClaw 默认使用 `messages.groupChat.visibleReplies: "message_tool"`。
-这意味着智能体仍会处理该轮对话，并可以更新记忆/会话状态，但它的普通最终回答不会自动发回房间。若要可见地发言，智能体会使用 `message(action=send)`。
+这意味着智能体仍会处理该轮对话，并可以更新记忆/会话状态，但它的普通最终回答不会自动发回房间。要可见地发言，智能体会使用 `message(action=send)`。

-如果在当前工具策略下消息工具不可用，OpenClaw 会回退为自动可见回复，而不是静默抑制响应。
-`openclaw doctor` 会警告这种不匹配。
+如果当前工具策略下消息工具不可用，OpenClaw 会回退到自动可见回复，而不是静默抑制响应。
+`openclaw doctor` 会对此不匹配发出警告。

-对于直接聊天和任何其他来源轮次，使用 `messages.visibleReplies: "message_tool"` 可在全局应用相同的仅工具可见回复行为。Harness 也可以选择它作为未设置时的默认值；Codex harness 会为 Codex 模式直接聊天这样做。`messages.groupChat.visibleReplies` 仍然是针对群组/渠道房间的更具体覆盖项。
+对于直接聊天和任何其他来源轮次，使用 `messages.visibleReplies: "message_tool"` 可以全局应用相同的仅工具可见回复行为。Harness 也可以选择将其作为未设置时的默认值；Codex harness 会对 Codex 模式的直接聊天这样做。`messages.groupChat.visibleReplies` 仍然是针对群组/渠道房间的更具体覆盖项。

-这取代了旧模式：强制模型在大多数潜伏模式轮次中回答 `NO_REPLY`。在仅工具模式中，什么都不显示仅仅意味着不调用消息工具。
+这取代了旧模式，即强制模型在大多数潜伏模式轮次中回答 `NO_REPLY`。在仅工具模式中，不做任何可见操作只意味着不调用消息工具。

-在智能体以仅工具模式工作时，仍会发送输入中指示器。这些轮次的默认群组输入模式会从 “message” 升级为 “instant”，因为在智能体决定是否调用消息工具之前，可能永远不会有普通的 assistant 消息文本。显式输入模式配置仍然优先。
+在智能体以仅工具模式工作时，仍会发送正在输入指示器。对于这些轮次，默认群组输入模式会从 “message” 升级为 “instant”，因为在智能体决定是否调用消息工具之前，可能永远不会出现普通助手消息文本。显式输入模式配置仍然优先。

-要恢复群组/渠道房间的旧版自动最终回复：
+要为群组/渠道房间恢复旧版自动最终回复：

 ```json5
 {
@ -83,29 +83,29 @@ otherwise -> reply
 }
 ```

-原生命令斜杠命令（Discord、Telegram，以及其他支持原生命令的表面）会绕过 `visibleReplies: "message_tool"`，并始终可见地回复，以便渠道原生命令 UI 获得它预期的响应。这仅适用于已验证的原生命令轮次；以文本输入的 `/...` 命令和普通聊天轮次仍遵循配置的群组默认值。
+原生命令（Discord、Telegram 以及其他支持原生命令的入口）会绕过 `visibleReplies: "message_tool"`，并始终可见地回复，以便渠道原生命令 UI 获得它预期的响应。这仅适用于经过验证的原生命令轮次；文本输入的 `/...` 命令和普通聊天轮次仍遵循配置的群组默认值。

 ## 上下文可见性和允许列表

-群组安全涉及两种不同的控制：
+群组安全涉及两种不同控制：

 - **触发授权**：谁可以触发智能体（`groupPolicy`、`groups`、`groupAllowFrom`、渠道特定允许列表）。
- **上下文可见性**：哪些补充上下文会注入模型（回复文本、引用、线程历史、转发元数据）。
+- **上下文可见性**：哪些补充上下文会注入模型（回复文本、引用、话题历史、转发元数据）。

-默认情况下，OpenClaw 优先考虑普通聊天行为，并基本按接收时的样子保留上下文。这意味着允许列表主要决定谁可以触发动作，而不是为每段引用或历史片段提供通用脱敏边界。
+默认情况下，OpenClaw 优先保持普通聊天行为，并让上下文基本按接收状态保留。这意味着允许列表主要决定谁可以触发操作，而不是每段引用或历史片段的通用脱敏边界。

 <AccordionGroup>
  <Accordion title="当前行为因渠道而异">
-    - 一些渠道已经在特定路径中对补充上下文应用基于发送者的过滤（例如 Slack 线程种子填充、Matrix 回复/线程查找）。
-    - 其他渠道仍会按接收时的样子传递引用/回复/转发上下文。
+    - 一些渠道已经在特定路径中对补充上下文应用基于发送者的过滤（例如 Slack 话题种子填充、Matrix 回复/话题查找）。
+    - 其他渠道仍会按接收状态传递引用/回复/转发上下文。

  </Accordion>
  <Accordion title="加固方向（计划中）">
-    - `contextVisibility: "all"`（默认）保留当前按接收时处理的行为。
+    - `contextVisibility: "all"`（默认）保留当前按接收状态处理的行为。
    - `contextVisibility: "allowlist"` 将补充上下文过滤为允许列表中的发送者。
    - `contextVisibility: "allowlist_quote"` 是 `allowlist` 加上一个显式引用/回复例外。

-    在此加固模型在各渠道中一致实现之前，预期不同表面会存在差异。
+    在此加固模型在各渠道中一致实现之前，预期不同入口会有差异。

  </Accordion>
 </AccordionGroup>
@ -114,27 +114,30 @@ otherwise -> reply

 如果你想要……

-| 目标 | 要设置的内容 |
+| 目标                                         | 要设置的内容                                               |
 | -------------------------------------------- | ---------------------------------------------------------- |
 | 允许所有群组，但只在 @提及时回复 | `groups: { "*": { requireMention: true } }`                |
-| 禁用所有群组回复 | `groupPolicy: "disabled"`                                  |
-| 仅特定群组 | `groups: { "<group-id>": { ... } }`（没有 `"*"` 键） |
-| 只有你可以在群组中触发 | `groupPolicy: "allowlist"`，`groupAllowFrom: ["+1555..."]` |
+| 禁用所有群组回复                    | `groupPolicy: "disabled"`                                  |
+| 仅允许特定群组                         | `groups: { "<group-id>": { ... } }`（没有 `"*"` 键）         |
+| 只有你可以在群组中触发               | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` |
+| 在多个渠道间复用一组受信发送者 | `groupAllowFrom: ["accessGroup:operators"]`                |
+
+关于可复用的发送者允许列表，请参阅 [访问组](/zh-CN/channels/access-groups)。

 ## 会话键

 - 群组会话使用 `agent:<agentId>:<channel>:group:<id>` 会话键（房间/渠道使用 `agent:<agentId>:<channel>:channel:<id>`）。
- Telegram 论坛主题会在群组 ID 后添加 `:topic:<threadId>`，因此每个主题都有自己的会话。
- 直接聊天使用主会话（如果已配置，也可以按发送者分会话）。
+- Telegram 论坛主题会向群组 id 添加 `:topic:<threadId>`，因此每个主题都有自己的会话。
+- 直接聊天使用主会话（如果已配置，则按发送者分别使用）。
 - 群组会话会跳过 Heartbeat。

 <a id="pattern-personal-dms-public-groups-single-agent"></a>

-## 模式：个人私信 + 公共群组（单个智能体）
+## 模式：个人私信 + 公开群组（单智能体）

-可以，这种方式很适合“个人”流量是**私信**、“公共”流量是**群组**的情况。
+可以。如果你的“个人”流量是**私信**，而你的“公开”流量是**群组**，这种方式效果很好。

-原因：在单智能体模式中，私信通常会落到**主**会话键（`agent:main:main`），而群组始终使用**非主**会话键（`agent:main:<channel>:group:<id>`）。如果你使用 `mode: "non-main"` 启用沙箱隔离，这些群组会话会在配置的沙箱后端中运行，而你的主私信会话仍留在主机上。如果你不选择后端，Docker 是默认后端。
+原因：在单智能体模式中，私信通常落入**主**会话键（`agent:main:main`），而群组始终使用**非主**会话键（`agent:main:<channel>:group:<id>`）。如果你启用沙箱隔离并设置 `mode: "non-main"`，这些群组会话会在配置的沙箱后端中运行，而你的主私信会话仍留在主机上。如果你没有选择后端，Docker 是默认后端。

 这会给你一个智能体“大脑”（共享工作区 + 记忆），但有两种执行姿态：

@ -142,7 +145,7 @@ otherwise -> reply
 - **群组**：沙箱 + 受限工具

 <Note>
-如果你需要真正分离的工作区/人格（“个人”和“公共”绝不能混合），请使用第二个智能体 + 绑定。参见[多智能体路由](/zh-CN/concepts/multi-agent)。
+如果你需要真正独立的工作区/人格（“个人”和“公开”绝不能混用），请使用第二个智能体 + 绑定。参阅 [多智能体路由](/zh-CN/concepts/multi-agent)。
 </Note>

 <Tabs>
@ -170,8 +173,8 @@ otherwise -> reply
    }
    ```
  </Tab>
-  <Tab title="群组只能看到允许列表中的文件夹">
-    想要“群组只能看到文件夹 X”，而不是“没有主机访问权限”？保留 `workspaceAccess: "none"`，并只把允许列表中的路径挂载到沙箱中：
+  <Tab title="群组只能看到一个允许列表文件夹">
+    想要“群组只能看到文件夹 X”，而不是“无主机访问权限”？保留 `workspaceAccess: "none"`，并只将允许列表中的路径挂载进沙箱：

    ```json5
    {
@ -196,20 +199,20 @@ otherwise -> reply
  </Tab>
 </Tabs>

-相关：
+相关内容：

 - 配置键和默认值：[Gateway 网关配置](/zh-CN/gateway/config-agents#agentsdefaultssandbox)
- 调试工具为何被阻止：[沙箱 vs 工具策略 vs 提权](/zh-CN/gateway/sandbox-vs-tool-policy-vs-elevated)
+- 调试工具为什么被阻止：[沙箱 vs 工具策略 vs 提权](/zh-CN/gateway/sandbox-vs-tool-policy-vs-elevated)
 - 绑定挂载详情：[沙箱隔离](/zh-CN/gateway/sandboxing#custom-bind-mounts)

 ## 显示标签

 - UI 标签在可用时使用 `displayName`，格式为 `<channel>:<token>`。
- `#room` 保留用于房间/渠道；群聊使用 `g-<slug>`（小写，空格 -> `-`，保留 `#@+._-`）。
+- `#room` 保留给房间/渠道；群聊使用 `g-<slug>`（小写，空格 -> `-`，保留 `#@+._-`）。

 ## 群组策略

-按渠道控制如何处理群组/房间消息：
+控制每个渠道如何处理群组/房间消息：

 ```json5
 {
@ -256,25 +259,25 @@ otherwise -> reply
 }
 ```

-| 策略 | 行为 |
+| 策略        | 行为                                                     |
 | ------------- | ------------------------------------------------------------ |
-| `"open"`      | 群组绕过允许列表；提及门控仍然适用。 |
-| `"disabled"`  | 完全阻止所有群组消息。 |
+| `"open"`      | 群组绕过允许列表；提及门控仍然适用。      |
+| `"disabled"`  | 完全阻止所有群组消息。                           |
 | `"allowlist"` | 仅允许匹配已配置允许列表的群组/房间。 |

 <AccordionGroup>
-  <Accordion title="各渠道说明">
-    - `groupPolicy` 独立于提及门控（后者需要 @提及）。
+  <Accordion title="每个渠道的说明">
+    - `groupPolicy` 独立于提及门控（后者要求 @提及）。
    - WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo：使用 `groupAllowFrom`（回退：显式 `allowFrom`）。
-    - Signal：`groupAllowFrom` 可以匹配入站 Signal 群组 ID 或发送者电话/UUID。
-    - 私信配对批准（`*-allowFrom` 存储条目）仅适用于私信访问；群组发送者授权仍显式属于群组允许列表。
+    - Signal：`groupAllowFrom` 可以匹配入站 Signal 群组 id，也可以匹配发送者电话/UUID。
+    - 私信配对审批（`*-allowFrom` 存储条目）仅适用于私信访问；群组发送者授权仍显式使用群组允许列表。
    - Discord：允许列表使用 `channels.discord.guilds.<id>.channels`。
    - Slack：允许列表使用 `channels.slack.channels`。
-    - Matrix：允许列表使用 `channels.matrix.groups`。优先使用房间 ID 或别名；已加入房间的名称查找是尽力而为，运行时会忽略未解析的名称。使用 `channels.matrix.groupAllowFrom` 限制发送者；也支持按房间的 `users` 允许列表。
+    - Matrix：允许列表使用 `channels.matrix.groups`。优先使用房间 ID 或别名；已加入房间的名称查找是尽力而为，未解析的名称会在运行时被忽略。使用 `channels.matrix.groupAllowFrom` 来限制发送者；也支持按房间设置的 `users` 允许列表。
    - 群组私信会单独控制（`channels.discord.dm.*`、`channels.slack.dm.*`）。
    - Telegram 允许列表可以匹配用户 ID（`"123456789"`、`"telegram:123456789"`、`"tg:123456789"`）或用户名（`"@alice"` 或 `"alice"`）；前缀不区分大小写。
-    - 默认值是 `groupPolicy: "allowlist"`；如果你的群组允许列表为空，群组消息会被阻止。
-    - 运行时安全：当提供商块完全缺失（不存在 `channels.<provider>`）时，群组策略会回退到故障关闭模式（通常是 `allowlist`），而不是继承 `channels.defaults.groupPolicy`。
+    - 默认是 `groupPolicy: "allowlist"`；如果你的群组允许列表为空，群组消息会被阻止。
+    - 运行时安全：当某个提供商块完全缺失（缺少 `channels.<provider>`）时，群组策略会回退到失败关闭模式（通常是 `allowlist`），而不是继承 `channels.defaults.groupPolicy`。

  </Accordion>
 </AccordionGroup>
@ -282,11 +285,11 @@ otherwise -> reply
 快速心智模型（群组消息的评估顺序）：

 <Steps>
-  <Step title="`groupPolicy`">
+  <Step title="groupPolicy">
    `groupPolicy`（open/disabled/allowlist）。
  </Step>
  <Step title="群组允许列表">
-    群组允许列表（`*.groups`、`*.groupAllowFrom`、渠道专用允许列表）。
+    群组允许列表（`*.groups`、`*.groupAllowFrom`、渠道特定允许列表）。
  </Step>
  <Step title="提及门控">
    提及门控（`requireMention`、`/activation`）。
@ -295,9 +298,9 @@ otherwise -> reply

 ## 提及门控（默认）

-群组消息需要提及，除非按群组覆盖。默认值位于各子系统下的 `*.groups."*"`。
+群组消息需要提及，除非按群组覆盖。默认值按子系统存放在 `*.groups."*"` 下。

-当渠道支持回复元数据时，回复 bot 消息会计为隐式提及。在暴露引用元数据的渠道中，引用 bot 消息也可以计为隐式提及。当前内置场景包括 Telegram、WhatsApp、Slack、Discord、Microsoft Teams 和 ZaloUser。
+当渠道支持回复元数据时，回复机器人消息会算作隐式提及。在暴露引用元数据的渠道上，引用机器人消息也可以算作隐式提及。当前内置情况包括 Telegram、WhatsApp、Slack、Discord、Microsoft Teams 和 ZaloUser。

 ```json5
 {
@ -337,15 +340,15 @@ otherwise -> reply

 <AccordionGroup>
  <Accordion title="提及门控说明">
-    - `mentionPatterns` 是大小写不敏感的安全正则表达式模式；无效模式和不安全的嵌套重复形式会被忽略。
-    - 提供显式提及的界面仍会通过；模式是回退方案。
+    - `mentionPatterns` 是不区分大小写的安全正则表达式模式；无效模式和不安全的嵌套重复形式会被忽略。
+    - 提供显式提及的表面仍会通过；模式是兜底机制。
    - 按智能体覆盖：`agents.list[].groupChat.mentionPatterns`（当多个智能体共享一个群组时很有用）。
    - 只有在可以进行提及检测时（配置了原生提及或 `mentionPatterns`），才会强制执行提及门控。
-    - 将某个群组或发送者加入允许列表不会禁用提及门控；如果所有消息都应触发，请将该群组的 `requireMention` 设为 `false`。
-    - 群聊提示上下文会在每一轮携带解析后的静默回复指令；工作区文件不应重复 `NO_REPLY` 机制。
-    - 允许静默回复的群组会把干净的空模型轮次或仅推理轮次视为静默，等同于 `NO_REPLY`。直接聊天仅在明确允许直接静默回复时才会这样处理；否则空回复仍会作为失败的智能体轮次。
+    - 将群组或发送者加入允许列表不会禁用提及门控；当所有消息都应触发时，将该群组的 `requireMention` 设为 `false`。
+    - 群聊提示词上下文在每轮都会携带已解析的静默回复指令；工作区文件不应重复 `NO_REPLY` 机制。
+    - 允许静默回复的群组会把干净的空模型轮次或仅推理轮次视为静默，等同于 `NO_REPLY`。只有在明确允许直接静默回复时，直接聊天才会这样处理；否则空回复仍会被视为失败的智能体轮次。
    - Discord 默认值位于 `channels.discord.guilds."*"`（可按服务器/渠道覆盖）。
-    - 群组历史上下文在各渠道中统一包装，并且**仅限待处理**（因提及门控而跳过的消息）；使用 `messages.groupChat.historyLimit` 设置全局默认值，使用 `channels.<channel>.historyLimit`（或 `channels.<channel>.accounts.*.historyLimit`）进行覆盖。设为 `0` 可禁用。
+    - 群组历史上下文在各渠道中统一包装，并且是**仅待处理**的（因提及门控而跳过的消息）；使用 `messages.groupChat.historyLimit` 设置全局默认值，并使用 `channels.<channel>.historyLimit`（或 `channels.<channel>.accounts.*.historyLimit`）进行覆盖。设为 `0` 可禁用。

  </Accordion>
 </AccordionGroup>
@ -354,19 +357,19 @@ otherwise -> reply

 某些渠道配置支持限制**特定群组/房间/渠道内**可用的工具。

- `tools`：为整个群组允许/拒绝工具。
- `toolsBySender`：群组内按发送者覆盖。使用显式键前缀：`id:<senderId>`、`e164:<phone>`、`username:<handle>`、`name:<displayName>` 和 `"*"` 通配符。旧版无前缀键仍被接受，并且仅按 `id:` 匹配。
+- `tools`：允许/拒绝整个群组的工具。
+- `toolsBySender`：群组内的按发送者覆盖。使用显式键前缀：`id:<senderId>`、`e164:<phone>`、`username:<handle>`、`name:<displayName>` 和 `"*"` 通配符。旧版无前缀键仍会被接受，并且只按 `id:` 匹配。

-解析顺序（最具体的优先）：
+解析顺序（最具体者优先）：

 <Steps>
-  <Step title="群组 `toolsBySender`">
+  <Step title="群组 toolsBySender">
    群组/渠道 `toolsBySender` 匹配。
  </Step>
  <Step title="群组工具">
    群组/渠道 `tools`。
  </Step>
-  <Step title="默认 `toolsBySender`">
+  <Step title="默认 toolsBySender">
    默认（`"*"`）`toolsBySender` 匹配。
  </Step>
  <Step title="默认工具">
@ -395,15 +398,15 @@ otherwise -> reply
 ```

 <Note>
-群组/渠道工具限制会在全局/智能体工具策略之外额外应用（拒绝仍然优先）。某些渠道对房间/渠道使用不同的嵌套方式（例如 Discord `guilds.*.channels.*`、Slack `channels.*`、Microsoft Teams `teams.*.channels.*`）。
+群组/渠道工具限制会叠加在全局/智能体工具策略之上（拒绝仍然优先）。某些渠道对房间/渠道使用不同的嵌套方式（例如 Discord `guilds.*.channels.*`、Slack `channels.*`、Microsoft Teams `teams.*.channels.*`）。
 </Note>

 ## 群组允许列表

-配置 `channels.whatsapp.groups`、`channels.telegram.groups` 或 `channels.imessage.groups` 时，这些键会作为群组允许列表。使用 `"*"` 可允许所有群组，同时仍然设置默认提及行为。
+配置 `channels.whatsapp.groups`、`channels.telegram.groups` 或 `channels.imessage.groups` 时，键会作为群组允许列表。使用 `"*"` 可允许所有群组，同时仍设置默认提及行为。

 <Warning>
-常见混淆：私信配对审批不等同于群组授权。对于支持私信配对的渠道，配对存储只解锁私信。群组命令仍需要来自配置允许列表的显式群组发送者授权，例如 `groupAllowFrom` 或该渠道记录的配置回退。
+常见混淆：私信配对批准不等同于群组授权。对于支持私信配对的渠道，配对存储只解锁私信。群组命令仍需要来自配置允许列表的显式群组发送者授权，例如 `groupAllowFrom` 或该渠道记录的配置兜底项。
 </Warning>

 常见意图（复制/粘贴）：
@ -463,7 +466,7 @@ otherwise -> reply
 - `/activation mention`
 - `/activation always`

-所有者由 `channels.whatsapp.allowFrom` 决定（未设置时使用 bot 自身的 E.164）。请将命令作为独立消息发送。其他界面目前会忽略 `/activation`。
+所有者由 `channels.whatsapp.allowFrom` 决定（未设置时则为机器人的自身 E.164）。将命令作为独立消息发送。其他表面目前会忽略 `/activation`。

 ## 上下文字段

@ -475,25 +478,25 @@ otherwise -> reply
 - `WasMentioned`（提及门控结果）
 - Telegram 论坛话题还包括 `MessageThreadId` 和 `IsForum`。

-渠道专用说明：
+渠道特定说明：

- BlueBubbles 可以在填充 `GroupMembers` 之前，从本地 Contacts 数据库可选地补充未命名的 macOS 群组参与者信息。此功能默认关闭，并且仅在常规群组门控通过后运行。
+- BlueBubbles 可以选择在填充 `GroupMembers` 之前，从本地 Contacts 数据库补充未命名的 macOS 群组参与者。此功能默认关闭，并且只会在正常群组门控通过后运行。

-智能体系统提示会在新群组会话的第一轮包含群组介绍。它会提醒模型像人一样回复，避免使用 Markdown 表格，尽量减少空行并遵循正常聊天间距，且避免输入字面量 `\n` 序列。来自渠道的群组名称和参与者标签会呈现为围栏代码块中的不受信任元数据，而不是内联系统指令。
+智能体系统提示词会在新群组会话的第一轮包含群组介绍。它会提醒模型像人一样回应、避免使用 Markdown 表格、尽量减少空行并遵循正常聊天间距，以及避免输入字面量 `\n` 序列。来自渠道的群组名称和参与者标签会渲染为受围栏保护的不可信元数据，而不是内联系统指令。

 ## iMessage 细节

 - 路由或加入允许列表时，优先使用 `chat_id:<id>`。
 - 列出聊天：`imsg chats --limit 20`。
- 群组回复始终回到同一个 `chat_id`。
+- 群组回复始终返回到同一个 `chat_id`。

-## WhatsApp 系统提示
+## WhatsApp 系统提示词

-请参阅 [WhatsApp](/zh-CN/channels/whatsapp#system-prompts)，了解规范的 WhatsApp 系统提示规则，包括群组和直接提示解析、通配符行为以及账号覆盖语义。
+请参阅 [WhatsApp](/zh-CN/channels/whatsapp#system-prompts)，了解规范的 WhatsApp 系统提示词规则，包括群组和直接提示词解析、通配符行为以及账号覆盖语义。

 ## WhatsApp 细节

-请参阅 [群组消息](/zh-CN/channels/group-messages)，了解仅限 WhatsApp 的行为（历史注入、提及处理细节）。
+请参阅[群组消息](/zh-CN/channels/group-messages)，了解仅限 WhatsApp 的行为（历史注入、提及处理细节）。

 ## 相关

--- a/docs/zh-CN/channels/pairing.md
+++ b/docs/zh-CN/channels/pairing.md
@ -2,14 +2,14 @@
 read_when:
    - 设置私信访问控制
    - 配对新的 iOS/Android 节点
-    - 审查 OpenClaw 安全态势
-summary: 配对概览：批准谁可以给你发私信 + 哪些节点可以加入
+    - 审查 OpenClaw 的安全态势
+summary: 配对概览：批准谁可以私信你 + 哪些节点可以加入
 title: 配对
 x-i18n:
-    generated_at: "2026-05-01T22:59:39Z"
+    generated_at: "2026-05-01T23:03:13Z"
    model: gpt-5.5
    provider: openai
-    source_hash: b11f4b538b9100e14c3dfe13c7a64995e5cebfc1c459839c6fa7a397f4cfb9ec
+    source_hash: bb68d87c0e1dfe7c9a6a6d9415f4c63625755fb43a2e22a1d1374ff0a63e49c4
    source_path: channels/pairing.md
    workflow: 16
 ---
@ -17,27 +17,27 @@ x-i18n:
 “配对”是 OpenClaw 的显式访问批准步骤。
 它用于两个地方：

-1. **私信配对**（谁被允许与机器人交谈）
+1. **私信配对**（谁被允许与机器人对话）
 2. **节点配对**（哪些设备/节点被允许加入 Gateway 网关网络）

 安全上下文：[安全](/zh-CN/gateway/security)

 ## 1) 私信配对（入站聊天访问）

-当某个渠道配置了私信策略 `pairing` 时，未知发送者会收到一个短代码，并且在你批准之前，其消息**不会被处理**。
+当某个渠道配置了私信策略 `pairing` 时，未知发送者会收到一个短代码，并且在你批准之前，他们的消息**不会被处理**。

 默认私信策略记录在：[安全](/zh-CN/gateway/security)

-`dmPolicy: "open"` 只有在生效的私信允许列表包含 `"*"` 时才是公开的。
+只有当有效的私信允许列表包含 `"*"` 时，`dmPolicy: "open"` 才是公开的。
 设置和验证要求公开开放配置使用该通配符。如果现有
-状态包含带有具体 `allowFrom` 条目的 `open`，运行时仍然只准入
-这些发送者，并且配对存储中的批准不会扩大 `open` 访问范围。
+状态包含 `open` 和具体的 `allowFrom` 条目，运行时仍然只接纳
+这些发送者，并且配对存储中的批准不会扩大 `open` 访问权限。

 配对代码：

 - 8 个字符，大写，不含易混淆字符（`0O1I`）。
 - **1 小时后过期**。机器人只会在创建新请求时发送配对消息（大约每个发送者每小时一次）。
- 待处理的私信配对请求默认每个渠道最多 **3 个**；额外请求会被忽略，直到其中一个过期或被批准。
+- 默认情况下，待处理的私信配对请求上限为**每个渠道 3 个**；更多请求会被忽略，直到其中一个过期或获批。

 ### 批准发送者

@ -47,16 +47,20 @@ openclaw pairing approve telegram <CODE>
 ```

 如果尚未配置命令所有者，批准私信配对代码也会将
-`commands.ownerAllowFrom` 初始化为已批准的发送者，例如 `telegram:123456789`。
-这会为首次设置提供一个显式所有者，用于特权命令和执行审批
-提示。所有者存在后，之后的配对批准只授予私信
+`commands.ownerAllowFrom` 引导设置为已批准的发送者，例如 `telegram:123456789`。
+这会为首次设置提供一个用于特权命令和 exec
+批准提示的显式所有者。已有所有者之后，后续配对批准只授予私信
 访问权限；它们不会添加更多所有者。

 支持的渠道：`bluebubbles`、`discord`、`feishu`、`googlechat`、`imessage`、`irc`、`line`、`matrix`、`mattermost`、`msteams`、`nextcloud-talk`、`nostr`、`openclaw-weixin`、`signal`、`slack`、`synology-chat`、`telegram`、`twitch`、`whatsapp`、`zalo`、`zalouser`。

-### 可复用发送者组
+### 可复用的发送者组

-当同一组可信发送者需要应用到多个消息渠道，或同时应用到私信和群组允许列表时，请使用顶层 `accessGroups`。静态发送者组使用 `type: "message.senders"`，并按每个渠道的常规 `allowFrom` 语法列出成员。
+当同一组受信任发送者需要应用于多个消息渠道，或同时应用于私信和群组允许列表时，
+请使用顶层 `accessGroups`。
+
+静态组使用 `type: "message.senders"`，并在渠道允许列表中通过
+`accessGroup:<name>` 引用：

 ```json5
 {
@ -64,7 +68,6 @@ openclaw pairing approve telegram <CODE>
    operators: {
      type: "message.senders",
      members: {
-        "*": ["global-owner-id"],
        discord: ["discord:123456789012345678"],
        telegram: ["987654321"],
        whatsapp: ["+15551234567"],
@ -78,31 +81,31 @@ openclaw pairing approve telegram <CODE>
 }
 ```

-`"*"` 成员列表由所有消息渠道共享。渠道特定列表会使用该渠道自己的发送者匹配规则进行检查。
+访问组的详细文档在这里：[访问组](/zh-CN/channels/access-groups)

-### 状态存储位置
+### 状态的存储位置

 存储在 `~/.openclaw/credentials/` 下：

 - 待处理请求：`<channel>-pairing.json`
 - 已批准允许列表存储：
-  - 默认账号：`<channel>-allowFrom.json`
-  - 非默认账号：`<channel>-<accountId>-allowFrom.json`
+  - 默认账户：`<channel>-allowFrom.json`
+  - 非默认账户：`<channel>-<accountId>-allowFrom.json`

-账号作用域行为：
+账户作用域行为：

- 非默认账号只读取/写入其作用域内的允许列表文件。
- 默认账号使用渠道作用域的非作用域允许列表文件。
+- 非默认账户只读写其作用域内的允许列表文件。
+- 默认账户使用渠道作用域的无作用域允许列表文件。

-请将这些视为敏感内容（它们控制对你的助手的访问）。
+请将这些文件视为敏感信息（它们控制对你的助手的访问）。

 <Note>
 配对允许列表存储用于私信访问。群组授权是独立的。
 批准私信配对代码不会自动允许该发送者运行群组
-命令或在群组中控制机器人。首次所有者初始化是 `commands.ownerAllowFrom`
-中的独立配置状态，而群组聊天投递仍遵循该
-渠道的群组允许列表（例如 `groupAllowFrom`、`groups`，或视渠道而定的按群组
-或按主题覆盖）。
+命令或在群组中控制机器人。首次所有者引导是
+`commands.ownerAllowFrom` 中的独立配置状态，群聊投递仍然遵循该
+渠道的群组允许列表（例如 `groupAllowFrom`、`groups`，或取决于渠道的按群组
+或按话题覆盖）。
 </Note>

 ## 2) 节点设备配对（iOS/Android/macOS/无头节点）
@ -112,31 +115,31 @@ openclaw pairing approve telegram <CODE>

 ### 通过 Telegram 配对（推荐用于 iOS）

-如果你使用 `device-pair` 插件，可以完全从 Telegram 完成首次设备配对：
+如果你使用 `device-pair` 插件，可以完全通过 Telegram 完成首次设备配对：

-1. 在 Telegram 中，向你的机器人发送消息：`/pair`
-2. 机器人会回复两条消息：一条说明消息，以及一条单独的**设置代码**消息（在 Telegram 中易于复制/粘贴）。
-3. 在你的手机上，打开 OpenClaw iOS 应用 → 设置 → Gateway 网关。
+1. 在 Telegram 中，给你的机器人发送消息：`/pair`
+2. 机器人会回复两条消息：一条说明消息，以及一条单独的**设置代码**消息（便于在 Telegram 中复制/粘贴）。
+3. 在手机上，打开 OpenClaw iOS 应用 → 设置 → Gateway 网关。
 4. 粘贴设置代码并连接。
 5. 回到 Telegram：`/pair pending`（查看请求 ID、角色和作用域），然后批准。

-设置代码是一个 base64 编码的 JSON 载荷，包含：
+设置代码是一个 base64 编码的 JSON 载荷，其中包含：

 - `url`：Gateway 网关 WebSocket URL（`ws://...` 或 `wss://...`）
 - `bootstrapToken`：用于初始配对握手的短期单设备引导令牌

-该引导令牌携带内置配对引导配置文件：
+该引导令牌携带内置的配对引导配置文件：

- 主要移交的 `node` 令牌保持 `scopes: []`
- 任何移交的 `operator` 令牌都限制在引导允许列表内：
+- 主要移交的 `node` 令牌保持为 `scopes: []`
+- 任何移交的 `operator` 令牌都保持受限于引导允许列表：
  `operator.approvals`、`operator.read`、`operator.talk.secrets`、`operator.write`
- 引导作用域检查按角色前缀区分，而不是一个扁平的作用域池：
+- 引导作用域检查按角色加前缀，而不是一个扁平的作用域池：
  operator 作用域条目只满足 operator 请求，非 operator 角色
-  仍必须请求其自身角色前缀下的作用域
- 后续令牌轮换/撤销仍同时受设备已批准
-  角色契约和调用方会话 operator 作用域的限制
+  仍必须在自己的角色前缀下请求作用域
+- 后续令牌轮换/吊销仍然同时受设备已批准的
+  角色契约和调用方会话的 operator 作用域限制

-请在设置代码有效期间像对待密码一样对待它。
+设置代码有效期间，请像对待密码一样对待它。

 ### 批准节点设备

@ -151,13 +154,13 @@ openclaw devices reject <requestId>
 `requestId`。

 <Note>
-已配对的设备不会静默获得更广泛的访问权限。如果它重新连接并请求更多作用域或更广泛的角色，OpenClaw 会保持现有批准不变，并创建一个新的待处理升级请求。批准前，请使用 `openclaw devices list` 比较当前已批准的访问权限和新请求的访问权限。
+已配对的设备不会静默获得更广泛的访问权限。如果它重新连接并请求更多作用域或更宽泛的角色，OpenClaw 会保持现有批准不变，并创建新的待处理升级请求。在批准前，请使用 `openclaw devices list` 比较当前已批准的访问权限与新请求的访问权限。
 </Note>

-### 可选的可信 CIDR 节点自动批准
+### 可选的受信任 CIDR 节点自动批准

-设备配对默认仍为手动。对于严格受控的节点网络，
-你可以选择使用显式 CIDR 或精确 IP 来对首次节点自动批准：
+设备配对默认保持手动。对于严格控制的节点网络，
+你可以通过显式 CIDR 或精确 IP 选择加入首次节点自动批准：

 ```json5
 {
@ -172,8 +175,8 @@ openclaw devices reject <requestId>
 ```

 这只适用于没有请求
-作用域的新 `role: node` 配对请求。Operator、浏览器、Control UI 和 WebChat 客户端仍需要手动
-批准。角色、作用域、元数据和公钥变更仍需要手动
+作用域的全新 `role: node` 配对请求。Operator、浏览器、Control UI 和 WebChat 客户端仍然需要手动
+批准。角色、作用域、元数据和公钥变更仍然需要手动
 批准。

 ### 节点配对状态存储
@ -186,9 +189,9 @@ openclaw devices reject <requestId>
 ### 备注

 - 旧版 `node.pair.*` API（CLI：`openclaw nodes pending|approve|reject|remove|rename`）是一个
-  独立的 Gateway 网关拥有的配对存储。WS 节点仍需要设备配对。
- 配对记录是已批准角色的持久事实来源。活跃
-  设备令牌仍受该已批准角色集限制；已批准角色之外的杂散令牌条目
+  独立的 Gateway 网关所有的配对存储。WS 节点仍然需要设备配对。
+- 配对记录是已批准角色的持久事实来源。活动
+  设备令牌保持受限于该已批准角色集；已批准角色之外的零散令牌条目
  不会创建新的访问权限。

 ## 相关文档