chore(i18n): refresh zh-CN translations

2026-04-21 08:46:16 +00:00 · 2026-04-21 08:46:16 +00:00 · 251a2689bc
commit 251a2689bc
parent e77f812e67
2 changed files with 235 additions and 136 deletions
--- a/docs/zh-CN/channels/bluebubbles.md
+++ b/docs/zh-CN/channels/bluebubbles.md
@ -1,43 +1,42 @@
 ---
 read_when:
    - 设置 BlueBubbles 渠道
-    - Webhook 配对故障排除
+    - 故障排除 webhook 配对
    - 在 macOS 上配置 iMessage
-summary: 通过 BlueBubbles macOS 服务器使用 iMessage（REST 发送/接收、正在输入、回应、配对、高级操作）。
+summary: 通过 BlueBubbles macOS 服务器接入 iMessage（REST 发送/接收、正在输入、表情回应、配对、高级操作）。
 title: BlueBubbles
 x-i18n:
-    generated_at: "2026-04-21T03:02:46Z"
+    generated_at: "2026-04-21T08:44:48Z"
    model: gpt-5.4
    provider: openai
-    source_hash: b3d8d617fc86ca1b191ff4dd2ae26b464e4d3f456a79c67b484a3a76d75de0d2
+    source_hash: 30ce50ae8a17140b42fa410647c367e0eefdffb1646b1ff92d8e1af63f2e1155
    source_path: channels/bluebubbles.md
    workflow: 15
 ---

 # BlueBubbles（macOS REST）

-状态：通过 HTTP 与 BlueBubbles macOS 服务器通信的内置插件。由于其 API 更丰富且设置比旧版 `imsg` 渠道更简单，**推荐用于 iMessage 集成**。
+状态：这是一个通过 HTTP 与 BlueBubbles macOS 服务器通信的内置插件。由于相比旧版 `imsg` 渠道拥有更丰富的 API 和更简单的设置方式，**推荐用于 iMessage 集成**。

 ## 内置插件

-当前的 OpenClaw 发布版本已内置 BlueBubbles，因此普通打包构建
-不需要单独执行 `openclaw plugins install` 步骤。
+当前的 OpenClaw 发布版本已内置 BlueBubbles，因此普通的打包构建**不需要**单独执行 `openclaw plugins install` 步骤。

 ## 概览

 - 通过 BlueBubbles 辅助应用在 macOS 上运行（[bluebubbles.app](https://bluebubbles.app)）。
- 推荐/已测试：macOS Sequoia（15）。macOS Tahoe（26）可用；目前在 Tahoe 上编辑功能已损坏，群组图标更新也可能显示成功但不会同步。
+- 推荐/已测试：macOS Sequoia（15）。macOS Tahoe（26）可用；目前在 Tahoe 上编辑功能失效，群组图标更新也可能显示成功但不会同步。
 - OpenClaw 通过其 REST API 与之通信（`GET /api/v1/ping`、`POST /message/text`、`POST /chat/:id/*`）。
 - 传入消息通过 webhook 到达；传出回复、正在输入指示、已读回执和 tapback 都通过 REST 调用完成。
- 附件和贴纸会作为入站媒体被接收（并在可能时呈现给智能体）。
+- 附件和贴纸会作为入站媒体接收（并在可能时展示给智能体）。
 - 配对/允许列表的工作方式与其他渠道相同（`/channels/pairing` 等），使用 `channels.bluebubbles.allowFrom` + 配对码。
- 回应会像 Slack/Telegram 一样作为系统事件呈现，因此智能体可以在回复前“提及”它们。
+- 表情回应会像 Slack/Telegram 一样作为系统事件呈现，因此智能体可以在回复前“提到”它们。
 - 高级功能：编辑、撤回、回复线程、消息效果、群组管理。

 ## 快速开始

 1. 在你的 Mac 上安装 BlueBubbles 服务器（按照 [bluebubbles.app/install](https://bluebubbles.app/install) 上的说明操作）。
-2. 在 BlueBubbles 配置中启用 web API，并设置密码。
+2. 在 BlueBubbles 配置中，启用 Web API 并设置密码。
 3. 运行 `openclaw onboard` 并选择 BlueBubbles，或手动配置：

   ```json5
@ -58,13 +57,13 @@ x-i18n:

 安全说明：

- 始终设置 webhook 密码。
- 始终要求进行 webhook 身份验证。无论 loopback/proxy 拓扑如何，除非 BlueBubbles webhook 请求包含与 `channels.bluebubbles.password` 匹配的 password/guid（例如 `?password=<password>` 或 `x-password`），否则 OpenClaw 会拒绝该请求。
- 在读取/解析完整 webhook 请求体之前，会先检查密码身份验证。
+- 始终设置一个 webhook 密码。
+- webhook 身份验证始终是必需的。无论 local loopback/代理拓扑如何，OpenClaw 都会拒绝 BlueBubbles webhook 请求，除非它们包含与 `channels.bluebubbles.password` 匹配的密码/guid（例如 `?password=<password>` 或 `x-password`）。
+- 密码验证会在读取/解析完整 webhook 请求体之前进行。

-## 保持 Messages.app 存活（VM / 无头设置）
+## 保持 Messages.app 处于活跃状态（VM / 无头设置）

-某些 macOS VM / 常开设置可能会导致 Messages.app 进入“空闲”状态（传入事件会停止，直到应用被打开/切到前台）。一个简单的变通方法是使用 AppleScript + LaunchAgent **每 5 分钟触发一次 Messages**。
+某些 macOS VM / 常开设置中，Messages.app 可能会进入“空闲”状态（传入事件会停止，直到应用被打开/切到前台）。一个简单的解决方法是使用 AppleScript + LaunchAgent **每 5 分钟轻触一次 Messages**。

 ### 1）保存 AppleScript

@ -127,7 +126,7 @@ end try
 说明：

 - 这会**每 300 秒**运行一次，并且**在登录时**运行。
- 第一次运行时可能会触发 macOS **Automation** 提示（`osascript` → Messages）。请在运行该 LaunchAgent 的同一用户会话中批准这些提示。
+- 首次运行时，可能会触发 macOS 的**自动化**提示（`osascript` → Messages）。请在运行该 LaunchAgent 的同一用户会话中批准它们。

 加载它：

@ -149,8 +148,8 @@ openclaw onboard
 - **Server URL**（必填）：BlueBubbles 服务器地址（例如 `http://192.168.1.100:1234`）
 - **Password**（必填）：BlueBubbles Server 设置中的 API 密码
 - **Webhook path**（可选）：默认为 `/bluebubbles-webhook`
- **私信策略**：pairing、allowlist、open 或 disabled
- **允许列表**：电话号码、电子邮件地址或聊天目标
+- **私信 policy**：pairing、allowlist、open 或 disabled
+- **Allow list**：电话号码、电子邮件地址或聊天目标

 你也可以通过 CLI 添加 BlueBubbles：

@ -163,8 +162,8 @@ openclaw channels add bluebubbles --http-url http://192.168.1.100:1234 --passwor
 私信：

 - 默认：`channels.bluebubbles.dmPolicy = "pairing"`。
- 未知发送者会收到一个配对码；在获批前其消息会被忽略（代码会在 1 小时后过期）。
- 通过以下方式批准：
+- 未知发件人会收到一个配对码；在获得批准前，消息会被忽略（配对码 1 小时后过期）。
+- 批准方式：
  - `openclaw pairing list bluebubbles`
  - `openclaw pairing approve bluebubbles <CODE>`
 - 配对是默认的令牌交换方式。详情见：[Pairing](/zh-CN/channels/pairing)
@ -172,16 +171,16 @@ openclaw channels add bluebubbles --http-url http://192.168.1.100:1234 --passwor
 群组：

 - `channels.bluebubbles.groupPolicy = open | allowlist | disabled`（默认：`allowlist`）。
- 当设置为 `allowlist` 时，`channels.bluebubbles.groupAllowFrom` 用于控制谁可以在群组中触发。
+- 当设置为 `allowlist` 时，`channels.bluebubbles.groupAllowFrom` 用于控制群组中谁可以触发。

 ### 联系人姓名增强（macOS，可选）

-BlueBubbles 的群组 webhook 通常只包含原始参与者地址。如果你希望 `GroupMembers` 上下文改为显示本地联系人姓名，可以在 macOS 上选择启用本地通讯录增强：
+BlueBubbles 的群组 webhook 通常只包含原始参与者地址。如果你希望 `GroupMembers` 上下文显示本地联系人姓名而不是这些地址，可以选择在 macOS 上启用本地通讯录增强：

 - `channels.bluebubbles.enrichGroupParticipantsFromContacts = true` 启用查找。默认值：`false`。
- 只有在群组访问、命令授权和提及门控允许该消息通过后，才会执行查找。
- 仅会增强未命名的电话参与者。
- 当找不到本地匹配项时，原始电话号码仍会作为回退值保留。
+- 只有在群组访问、命令授权和提及门控都已允许消息通过后，才会执行查找。
+- 仅增强未命名的电话参与者。
+- 如果找不到本地匹配项，仍会回退为原始电话号码。

 ```json5
 {
@ -195,10 +194,10 @@ BlueBubbles 的群组 webhook 通常只包含原始参与者地址。如果你

 ### 提及门控（群组）

-BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致：
+BlueBubbles 支持群聊提及门控，与 iMessage/WhatsApp 行为一致：

 - 使用 `agents.list[].groupChat.mentionPatterns`（或 `messages.groupChat.mentionPatterns`）来检测提及。
- 当某个群组启用了 `requireMention` 时，智能体只会在被提及时响应。
+- 当某个群组启用了 `requireMention` 时，智能体仅在被提及时才会响应。
 - 来自已授权发送者的控制命令会绕过提及门控。

 按群组配置：
@ -211,7 +210,7 @@ BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致
      groupAllowFrom: ["+15555550123"],
      groups: {
        "*": { requireMention: true }, // 所有群组的默认值
-        "iMessage;-;chat123": { requireMention: false }, // 特定群组的覆盖设置
+        "iMessage;-;chat123": { requireMention: false }, // 对特定群组的覆盖
      },
    },
  },
@ -221,12 +220,12 @@ BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致
 ### 命令门控

 - 控制命令（例如 `/config`、`/model`）需要授权。
- 使用 `allowFrom` 和 `groupAllowFrom` 来判断命令授权。
+- 使用 `allowFrom` 和 `groupAllowFrom` 来确定命令授权。
 - 已授权发送者即使在群组中未提及，也可以运行控制命令。

-### 按群组设置系统提示词
+### 按群组设置 system prompt

-`channels.bluebubbles.groups.*` 下的每个条目都接受一个可选的 `systemPrompt` 字符串。对于该群组中的每一次消息处理轮次，这个值都会被注入到智能体的系统提示词中，因此你可以在不编辑智能体提示词的情况下，为每个群组设置不同的人设或行为规则：
+`channels.bluebubbles.groups.*` 下的每个条目都接受一个可选的 `systemPrompt` 字符串。对于该群组中的每一轮消息处理，这个值都会注入到智能体的 system prompt 中，因此你可以为不同群组设置不同的人设或行为规则，而无需编辑智能体提示词：

 ```json5
 {
@ -234,7 +233,7 @@ BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致
    bluebubbles: {
      groups: {
        "iMessage;-;chat123": {
-          systemPrompt: "Keep responses under 3 sentences. Mirror the group's casual tone.",
+          systemPrompt: "将回复控制在 3 句话以内。模仿这个群组的随意语气。",
        },
      },
    },
@ -242,11 +241,11 @@ BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致
 }
 ```

-该键会匹配 BlueBubbles 报告的群组 `chatGuid` / `chatIdentifier` / 数字 `chatId` 中的任意一种，而 `"*"` 通配符条目会为所有没有精确匹配的群组提供默认值（与 `requireMention` 和按群组工具策略使用相同模式）。精确匹配始终优先于通配符。私信会忽略该字段；请改用智能体级别或账户级别的提示词自定义。
+该键会匹配 BlueBubbles 上报的群组 `chatGuid` / `chatIdentifier` / 数字 `chatId`，而 `"*"` 通配符条目会为每个没有精确匹配的群组提供默认值（与 `requireMention` 和按群组工具策略使用相同的模式）。精确匹配始终优先于通配符。私信会忽略此字段；请改用智能体级别或账户级别的提示词自定义。

-#### 示例：线程回复和 tapback 回应（Private API）
+#### 示例：线程回复与 tapback 表情回应（Private API）

-启用 BlueBubbles Private API 后，入站消息会带有短消息 ID（例如 `[[reply_to:5]]`），智能体可以调用 `action=reply` 以在线程中回复特定消息，或调用 `action=react` 来添加 tapback。按群组设置的 `systemPrompt` 是确保智能体选择正确工具的可靠方式：
+启用 BlueBubbles Private API 后，入站消息会带有短消息 ID（例如 `[[reply_to:5]]`），智能体可以调用 `action=reply` 将回复串到特定消息下，或者调用 `action=react` 添加一个 tapback。按群组设置 `systemPrompt` 是让智能体始终选择正确工具的可靠方式：

 ```json5
 {
@ -255,13 +254,14 @@ BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致
      groups: {
        "iMessage;+;chat-family": {
          systemPrompt: [
-            "When replying in this group, always call action=reply with the",
-            "[[reply_to:N]] messageId from context so your response threads",
-            "under the triggering message. Never send a new unlinked message.",
+            "在这个群组中回复时，始终使用上下文中的",
+            "[[reply_to:N]] messageId 调用 action=reply，",
+            "这样你的回复会串在线程中并位于触发消息下方。",
+            "绝不要发送一条新的未关联消息。",
            "",
-            "For short acknowledgements ('ok', 'got it', 'on it'), use",
-            "action=react with an appropriate tapback emoji (❤️, 👍, 😂, ‼️, ❓)",
-            "instead of sending a text reply.",
+            "对于简短确认（“好的”“收到”“在处理了”），请使用",
+            "action=react 并配合合适的 tapback emoji（❤️、👍、😂、‼️、❓），",
+            "而不是发送文本回复。",
          ].join(" "),
        },
      },
@ -270,24 +270,24 @@ BlueBubbles 支持群聊中的提及门控，与 iMessage/WhatsApp 行为一致
 }
 ```

-Tapback 回应和线程回复都需要 BlueBubbles Private API；其底层机制参见 [高级操作](#advanced-actions) 和 [消息 ID](#message-ids-short-vs-full)。
+tapback 表情回应和线程回复都需要 BlueBubbles Private API；底层机制请参见 [Advanced actions](#advanced-actions) 和 [Message IDs](#message-ids-short-vs-full)。

 ## ACP 会话绑定

-BlueBubbles 聊天可以转换为持久化的 ACP 工作区，而无需更改传输层。
+BlueBubbles 聊天可以转为持久化的 ACP 工作区，而无需更改传输层。

 快速操作流程：

 - 在私信或允许的群聊中运行 `/acp spawn codex --bind here`。
- 之后，该 BlueBubbles 会话中的消息会路由到已生成的 ACP 会话。
- `/new` 和 `/reset` 会在原地重置同一个已绑定的 ACP 会话。
+- 同一个 BlueBubbles 会话中的后续消息会路由到所创建的 ACP 会话。
+- `/new` 和 `/reset` 会就地重置同一个已绑定的 ACP 会话。
 - `/acp close` 会关闭 ACP 会话并移除绑定。

 也支持通过顶层 `bindings[]` 条目配置持久绑定，使用 `type: "acp"` 和 `match.channel: "bluebubbles"`。

 `match.peer.id` 可以使用任何受支持的 BlueBubbles 目标形式：

- 规范化的私信句柄，例如 `+15555550123` 或 `user@example.com`
+- 标准化的私信句柄，例如 `+15555550123` 或 `user@example.com`
 - `chat_id:<id>`
 - `chat_guid:<guid>`
 - `chat_identifier:<identifier>`
@ -328,9 +328,9 @@ BlueBubbles 聊天可以转换为持久化的 ACP 工作区，而无需更改传

 ## 正在输入 + 已读回执

- **正在输入指示**：会在生成回复之前和期间自动发送。
+- **正在输入指示**：会在生成回复之前和生成过程中自动发送。
 - **已读回执**：由 `channels.bluebubbles.sendReadReceipts` 控制（默认：`true`）。
- **正在输入指示**：OpenClaw 会发送输入开始事件；BlueBubbles 会在发送后或超时后自动清除输入状态（通过 DELETE 手动停止并不可靠）。
+- **正在输入指示**：OpenClaw 会发送开始输入事件；BlueBubbles 会在发送消息后或超时后自动清除输入状态（通过 DELETE 手动停止并不可靠）。

 ```json5
 {
@ -352,10 +352,10 @@ BlueBubbles 聊天可以转换为持久化的 ACP 工作区，而无需更改传
    bluebubbles: {
      actions: {
        reactions: true, // tapback（默认：true）
-        edit: true, // 编辑已发送消息（macOS 13+，在 macOS 26 Tahoe 上已损坏）
+        edit: true, // 编辑已发送消息（macOS 13+，在 macOS 26 Tahoe 上失效）
        unsend: true, // 撤回消息（macOS 13+）
-        reply: true, // 通过消息 GUID 进行线程回复
-        sendWithEffect: true, // 使用 iMessage 效果发送（slam、loud 等）
+        reply: true, // 按消息 GUID 进行线程回复
+        sendWithEffect: true, // 消息效果（slam、loud 等）
        renameGroup: true, // 重命名群聊
        setGroupIcon: true, // 设置群聊图标/照片（在 macOS 26 Tahoe 上不稳定）
        addParticipant: true, // 向群组添加参与者
@ -370,19 +370,19 @@ BlueBubbles 聊天可以转换为持久化的 ACP 工作区，而无需更改传

 可用操作：

- **react**：添加/移除 tapback 回应（`messageId`、`emoji`、`remove`）
+- **react**：添加/移除 tapback 表情回应（`messageId`、`emoji`、`remove`）
 - **edit**：编辑已发送消息（`messageId`、`text`）
 - **unsend**：撤回消息（`messageId`）
- **reply**：回复特定消息（`messageId`、`text`、`to`）
+- **reply**：回复指定消息（`messageId`、`text`、`to`）
 - **sendWithEffect**：使用 iMessage 效果发送（`text`、`to`、`effectId`）
 - **renameGroup**：重命名群聊（`chatGuid`、`displayName`）
 - **setGroupIcon**：设置群聊图标/照片（`chatGuid`、`media`）—— 在 macOS 26 Tahoe 上不稳定（API 可能返回成功，但图标不会同步）。
- **addParticipant**：向群组添加某人（`chatGuid`、`address`）
- **removeParticipant**：从群组移除某人（`chatGuid`、`address`）
+- **addParticipant**：向群组添加成员（`chatGuid`、`address`）
+- **removeParticipant**：从群组移除成员（`chatGuid`、`address`）
 - **leaveGroup**：退出群聊（`chatGuid`）
 - **upload-file**：发送媒体/文件（`to`、`buffer`、`filename`、`asVoice`）
-  - 语音备忘录：将 **MP3** 或 **CAF** 音频与 `asVoice: true` 一起设置，可作为 iMessage 语音消息发送。BlueBubbles 在发送语音备忘录时会将 MP3 转换为 CAF。
- 旧别名：`sendAttachment` 仍然可用，但 `upload-file` 是规范操作名称。
+  - 语音备忘录：将 **MP3** 或 **CAF** 音频与 `asVoice: true` 一起使用，即可作为 iMessage 语音消息发送。BlueBubbles 在发送语音备忘录时会将 MP3 转换为 CAF。
+- 旧别名：`sendAttachment` 仍然可用，但 `upload-file` 是规范操作名。

 ### 消息 ID（短 ID 与完整 ID）

@ -390,19 +390,116 @@ OpenClaw 可能会显示_短_消息 ID（例如 `1`、`2`）以节省 token。

 - `MessageSid` / `ReplyToId` 可以是短 ID。
 - `MessageSidFull` / `ReplyToIdFull` 包含提供商的完整 ID。
- 短 ID 保存在内存中；在重启或缓存清除后可能失效。
- 操作接受短或完整 `messageId`，但如果短 ID 不再可用，将会报错。
+- 短 ID 存储在内存中；在重启或缓存清除后可能失效。
+- 操作可以接受短或完整的 `messageId`，但如果短 ID 已不可用，将会报错。

 对于持久化自动化和存储，请使用完整 ID：

 - 模板：`{{MessageSidFull}}`、`{{ReplyToIdFull}}`
- 上下文：入站载荷中的 `MessageSidFull` / `ReplyToIdFull`
+- 上下文：入站负载中的 `MessageSidFull` / `ReplyToIdFull`

 模板变量请参见 [Configuration](/zh-CN/gateway/configuration)。

+## 合并拆分发送的私信（一次输入中的命令 + URL）
+
+当用户在 iMessage 中将命令和 URL 一起输入时——例如 `Dump https://example.com/article`——Apple 会将这次发送拆成**两次独立的 webhook 投递**：
+
+1. 一条文本消息（`"Dump"`）。
+2. 一个 URL 预览气泡（`"https://..."`），并附带 OG 预览图片作为附件。
+
+在大多数设置中，这两个 webhook 会相隔约 0.8–2.0 秒到达 OpenClaw。如果不进行合并，智能体在第 1 轮只会收到命令本身并回复（通常是“把 URL 发给我”），直到第 2 轮才看到 URL——而此时命令上下文已经丢失。
+
+`channels.bluebubbles.coalesceSameSenderDms` 会让私信启用同一发送者连续 webhook 的合并，从而在一轮智能体处理内统一处理。群聊仍然按单条消息分组，以保留多用户会话结构。
+
+### 何时启用
+
+在以下情况下启用：
+
+- 你提供的 Skills 期望在一条消息中收到 `命令 + 负载`（dump、paste、save、queue 等）。
+- 你的用户会把 URL、图片或长内容与命令一起粘贴发送。
+- 你可以接受私信轮次的额外延迟（见下文）。
+
+在以下情况下保持禁用：
+
+- 你需要最小化单词私信命令触发的延迟。
+- 你的所有流程都是无需后续负载的一次性命令。
+
+### 启用方式
+
+```json5
+{
+  channels: {
+    bluebubbles: {
+      coalesceSameSenderDms: true, // 选择启用（默认：false）
+    },
+  },
+}
+```
+
+启用此标志后，如果没有显式设置 `messages.inbound.byChannel.bluebubbles`，防抖窗口会扩大到 **2500 ms**（不进行合并时默认是 500 ms）。之所以需要更宽的窗口，是因为 Apple 的拆分发送节奏为 0.8–2.0 秒，无法适配更紧的默认值。
+
+若要自行调整窗口：
+
+```json5
+{
+  messages: {
+    inbound: {
+      byChannel: {
+        // 2500 ms 对大多数设置都适用；如果你的 Mac 较慢
+        // 或存在内存压力（观察到的间隔可能会超过 2 秒），可提高到 4000 ms。
+        bluebubbles: 2500,
+      },
+    },
+  },
+}
+```
+
+### 权衡
+
+- **私信控制命令会增加延迟。** 启用此标志后，私信控制命令消息（如 `Dump`、`Save` 等）现在会在分发前最多等待一个防抖窗口，以防后续还有负载 webhook 到来。群聊命令仍然是即时分发。
+- **合并输出有边界限制**——合并后的文本上限为 4000 个字符，并会明确添加 `…[truncated]` 标记；附件上限为 20 个；来源条目上限为 10 个（超过后保留第一条和最新条目）。每个来源 `messageId` 仍会进入入站去重逻辑，因此稍后如果 MessagePoller 重放其中任意单个事件，也会被识别为重复。
+- **按渠道选择启用。** 其他渠道（Telegram、WhatsApp、Slack、…）不受影响。
+
+### 场景与智能体实际看到的内容
+
+| 用户输入内容 | Apple 投递内容 | 标志关闭（默认） | 标志开启 + 2500 ms 窗口 |
+| --- | --- | --- | --- |
+| `Dump https://example.com`（一次发送） | 2 个 webhook，相隔约 1 秒 | 两轮智能体处理：“Dump” 单独一轮，然后 URL 一轮 | 一轮处理：合并后的文本 `Dump https://example.com` |
+| `Save this 📎image.jpg caption`（附件 + 文本） | 2 个 webhook | 两轮处理 | 一轮处理：文本 + 图片 |
+| `/status`（独立命令） | 1 个 webhook | 即时分发 | **最多等待一个窗口后再分发** |
+| 单独粘贴 URL | 1 个 webhook | 即时分发 | 即时分发（桶中只有一个条目） |
+| 文本 + URL 作为两条刻意分开的消息发送，间隔数分钟 | 2 个 webhook，超出窗口 | 两轮处理 | 两轮处理（窗口已过期） |
+| 快速刷屏（窗口内 >10 条小私信） | N 个 webhook | N 轮处理 | 一轮处理，输出有边界限制（保留首条 + 最新条，应用文本/附件上限） |
+
+### 拆分发送合并的故障排除
+
+如果该标志已开启，但拆分发送仍然表现为两轮处理，请逐层检查：
+
+1. **确认配置已实际加载。**
+
+   ```
+   grep coalesceSameSenderDms ~/.openclaw/openclaw.json
+   ```
+
+   然后执行 `openclaw gateway restart`——该标志会在防抖器注册表创建时读取。
+
+2. **确认你的设置有足够宽的防抖窗口。** 查看位于 `~/Library/Logs/bluebubbles-server/main.log` 的 BlueBubbles 服务器日志：
+
+   ```
+   grep -E "Dispatching event to webhook" main.log | tail -20
+   ```
+
+   测量 `"Dump"` 这类文本分发与后续 `"https://..."; Attachments:` 分发之间的时间间隔。将 `messages.inbound.byChannel.bluebubbles` 提高到足以覆盖这个间隔。
+
+3. **会话 JSONL 时间戳 ≠ webhook 到达时间。** 会话事件时间戳（`~/.openclaw/agents/<id>/sessions/*.jsonl`）反映的是 Gateway 网关将消息交给智能体的时间，**不是** webhook 到达时间。带有 `[Queued messages while agent was busy]` 标签的排队第二条消息，意味着第二个 webhook 到达时第一轮仍在运行——此时合并桶已经刷新。应根据 BB 服务器日志来调整窗口，而不是根据会话日志。
+
+4. **内存压力拖慢了回复分发。** 在较小的机器（8 GB）上，智能体轮次可能耗时很长，以至于在回复完成前合并桶就已刷新，URL 因而作为排队的第二轮到达。检查 `memory_pressure` 和 `ps -o rss -p $(pgrep openclaw-gateway)`；如果 Gateway 网关的 RSS 超过约 500 MB 且压缩器处于活动状态，请关闭其他高负载进程，或升级到更大的主机。
+
+5. **回复引用发送走的是另一条路径。** 如果用户是将 `Dump` 作为对现有 URL 气泡的**回复**发送的（iMessage 会在 `Dump` 气泡上显示 “1 Reply” 徽标），那么 URL 位于 `replyToBody` 中，而不是位于第二个 webhook 中。此时合并逻辑不适用——这是 Skills/提示词层面的问题，不是防抖器的问题。
+
 ## 分块流式传输

-控制回复是作为单条消息发送，还是以分块方式流式发送：
+控制响应是作为单条消息发送，还是按块流式发送：

 ```json5
 {
@ -417,8 +514,8 @@ OpenClaw 可能会显示_短_消息 ID（例如 `1`、`2`）以节省 token。
 ## 媒体 + 限制

 - 入站附件会被下载并存储到媒体缓存中。
- 入站和出站媒体都通过 `channels.bluebubbles.mediaMaxMb` 限制媒体大小（默认：8 MB）。
- 出站文本会按 `channels.bluebubbles.textChunkLimit` 进行分块（默认：4000 个字符）。
+- 入站和出站媒体都可通过 `channels.bluebubbles.mediaMaxMb` 设置媒体上限（默认：8 MB）。
+- 出站文本会按 `channels.bluebubbles.textChunkLimit` 分块（默认：4000 个字符）。

 ## 配置参考

@ -429,21 +526,22 @@ OpenClaw 可能会显示_短_消息 ID（例如 `1`、`2`）以节省 token。
 - `channels.bluebubbles.enabled`：启用/禁用该渠道。
 - `channels.bluebubbles.serverUrl`：BlueBubbles REST API 基础 URL。
 - `channels.bluebubbles.password`：API 密码。
- `channels.bluebubbles.webhookPath`：Webhook 端点路径（默认：`/bluebubbles-webhook`）。
+- `channels.bluebubbles.webhookPath`：webhook 端点路径（默认：`/bluebubbles-webhook`）。
 - `channels.bluebubbles.dmPolicy`：`pairing | allowlist | open | disabled`（默认：`pairing`）。
- `channels.bluebubbles.allowFrom`：私信允许列表（句柄、电子邮件、E.164 号码、`chat_id:*`、`chat_guid:*`）。
+- `channels.bluebubbles.allowFrom`：私信允许列表（handles、电子邮件、E.164 号码、`chat_id:*`、`chat_guid:*`）。
 - `channels.bluebubbles.groupPolicy`：`open | allowlist | disabled`（默认：`allowlist`）。
 - `channels.bluebubbles.groupAllowFrom`：群组发送者允许列表。
- `channels.bluebubbles.enrichGroupParticipantsFromContacts`：在 macOS 上，在门控通过后可选地从本地通讯录增强未命名的群组参与者。默认：`false`。
+- `channels.bluebubbles.enrichGroupParticipantsFromContacts`：在 macOS 上，在门控通过后，可选择从本地“通讯录”中增强未命名的群组参与者。默认：`false`。
 - `channels.bluebubbles.groups`：按群组配置（`requireMention` 等）。
 - `channels.bluebubbles.sendReadReceipts`：发送已读回执（默认：`true`）。
 - `channels.bluebubbles.blockStreaming`：启用分块流式传输（默认：`false`；流式回复必需）。
- `channels.bluebubbles.textChunkLimit`：出站分块大小，单位为字符（默认：4000）。
- `channels.bluebubbles.sendTimeoutMs`：通过 `/api/v1/message/text` 发送出站文本时每个请求的超时时间（毫秒，默认：30000）。在 macOS 26 设置中，如果 Private API iMessage 发送可能在 iMessage 框架内部停滞 60+ 秒，请调高此值；例如 `45000` 或 `60000`。探测、聊天查找、回应、编辑和健康检查目前仍保持较短的 10 秒默认值；后续计划扩展到回应和编辑。按账户覆盖：`channels.bluebubbles.accounts.<accountId>.sendTimeoutMs`。
+- `channels.bluebubbles.textChunkLimit`：出站分块的字符数上限（默认：4000）。
+- `channels.bluebubbles.sendTimeoutMs`：通过 `/api/v1/message/text` 发送出站文本时每个请求的超时时间（毫秒，默认：30000）。在 macOS 26 环境中，如果 Private API 的 iMessage 发送会在 iMessage 框架内部卡住 60 多秒，可提高该值；例如设为 `45000` 或 `60000`。探测、聊天查询、表情回应、编辑和健康检查目前仍保持较短的 10 秒默认值；后续计划将更宽的超时覆盖到表情回应和编辑。按账户覆盖：`channels.bluebubbles.accounts.<accountId>.sendTimeoutMs`。
 - `channels.bluebubbles.chunkMode`：`length`（默认）仅在超过 `textChunkLimit` 时拆分；`newline` 会先按空行（段落边界）拆分，再按长度分块。
- `channels.bluebubbles.mediaMaxMb`：入站/出站媒体上限，单位 MB（默认：8）。
- `channels.bluebubbles.mediaLocalRoots`：允许出站使用本地媒体路径的绝对本地目录显式允许列表。默认情况下，除非配置此项，否则会拒绝本地路径发送。按账户覆盖：`channels.bluebubbles.accounts.<accountId>.mediaLocalRoots`。
- `channels.bluebubbles.historyLimit`：用于上下文的最大群组消息数（0 表示禁用）。
+- `channels.bluebubbles.mediaMaxMb`：入站/出站媒体大小上限（MB，默认：8）。
+- `channels.bluebubbles.mediaLocalRoots`：显式允许的绝对本地目录列表，这些目录中的本地媒体路径可用于出站发送。默认情况下，本地路径发送会被拒绝，除非已配置此项。按账户覆盖：`channels.bluebubbles.accounts.<accountId>.mediaLocalRoots`。
+- `channels.bluebubbles.coalesceSameSenderDms`：将同一发送者连续的私信 webhook 合并为一轮智能体处理，使 Apple 的“文本 + URL”拆分发送能作为单条消息到达（默认：`false`）。场景、窗口调优和权衡请参见[合并拆分发送的私信](#coalescing-split-send-dms-command--url-in-one-composition)。启用后，如果未显式设置 `messages.inbound.byChannel.bluebubbles`，默认入站防抖窗口会从 500 ms 扩大到 2500 ms。
+- `channels.bluebubbles.historyLimit`：用于上下文的群组消息最大数量（设为 0 则禁用）。
 - `channels.bluebubbles.dmHistoryLimit`：私信历史记录上限。
 - `channels.bluebubbles.actions`：启用/禁用特定操作。
 - `channels.bluebubbles.accounts`：多账户配置。
@ -457,35 +555,36 @@ OpenClaw 可能会显示_短_消息 ID（例如 `1`、`2`）以节省 token。

 为了获得稳定路由，优先使用 `chat_guid`：

- `chat_guid:iMessage;-;+15555550123`（群组首选）
+- `chat_guid:iMessage;-;+15555550123`（群组推荐）
 - `chat_id:123`
 - `chat_identifier:...`
 - 直接句柄：`+15555550123`、`user@example.com`
-  - 如果某个直接句柄尚不存在私信聊天，OpenClaw 将通过 `POST /api/v1/chat/new` 创建一个。这要求启用 BlueBubbles Private API。
+  - 如果某个直接句柄没有现有私信聊天，OpenClaw 会通过 `POST /api/v1/chat/new` 创建一个。这要求启用 BlueBubbles Private API。

 ## 安全

- Webhook 请求通过将 `guid`/`password` 查询参数或标头与 `channels.bluebubbles.password` 进行比对来验证身份。
- 请妥善保管 API 密码和 webhook 端点（将它们视为凭证）。
- BlueBubbles webhook 身份验证没有 localhost 绕过。如果你代理 webhook 流量，请确保请求端到端携带 BlueBubbles 密码。这里的 `gateway.trustedProxies` 不能替代 `channels.bluebubbles.password`。参见 [Gateway security](/zh-CN/gateway/security#reverse-proxy-configuration)。
- 如果要将 BlueBubbles 服务器暴露到局域网之外，请启用 HTTPS + 防火墙规则。
+- webhook 请求通过比较查询参数或请求头中的 `guid`/`password` 与 `channels.bluebubbles.password` 来进行身份验证。
+- 请妥善保管 API 密码和 webhook 端点（将其视为凭证）。
+- BlueBubbles webhook 身份验证没有 localhost 旁路。如果你代理 webhook 流量，请在整个请求链路中保留 BlueBubbles 密码。这里的 `gateway.trustedProxies` 不能替代 `channels.bluebubbles.password`。参见 [Gateway 网关安全](/zh-CN/gateway/security#reverse-proxy-configuration)。
+- 如果要将 BlueBubbles 服务器暴露到你的局域网之外，请启用 HTTPS + 防火墙规则。

 ## 故障排除

 - 如果正在输入/已读事件停止工作，请检查 BlueBubbles webhook 日志，并确认 Gateway 网关路径与 `channels.bluebubbles.webhookPath` 匹配。
- 配对码会在一小时后过期；请使用 `openclaw pairing list bluebubbles` 和 `openclaw pairing approve bluebubbles <code>`。
- 回应需要 BlueBubbles private API（`POST /api/v1/message/react`）；请确认服务器版本提供此功能。
- 编辑/撤回需要 macOS 13+ 和兼容的 BlueBubbles 服务器版本。在 macOS 26（Tahoe）上，由于 private API 变更，编辑目前已损坏。
+- 配对码会在一小时后过期；使用 `openclaw pairing list bluebubbles` 和 `openclaw pairing approve bluebubbles <code>`。
+- 表情回应需要 BlueBubbles private API（`POST /api/v1/message/react`）；请确认服务器版本已提供该接口。
+- 编辑/撤回需要 macOS 13+ 和兼容的 BlueBubbles 服务器版本。在 macOS 26（Tahoe）上，由于 private API 变更，编辑功能目前失效。
 - 群组图标更新在 macOS 26（Tahoe）上可能不稳定：API 可能返回成功，但新图标不会同步。
- OpenClaw 会根据 BlueBubbles 服务器的 macOS 版本自动隐藏已知损坏的操作。如果在 macOS 26（Tahoe）上仍显示 edit，请使用 `channels.bluebubbles.actions.edit=false` 手动禁用。
- 状态/健康信息请使用：`openclaw status --all` 或 `openclaw status --deep`。
+- OpenClaw 会根据 BlueBubbles 服务器的 macOS 版本自动隐藏已知失效的操作。如果在 macOS 26（Tahoe）上仍然显示 edit，请手动通过 `channels.bluebubbles.actions.edit=false` 禁用它。
+- 已启用 `coalesceSameSenderDms`，但拆分发送（例如 `Dump` + URL）仍然作为两轮到达：请查看[拆分发送合并的故障排除](#split-send-coalescing-troubleshooting)清单——常见原因包括防抖窗口过窄、误将会话日志时间戳当作 webhook 到达时间，或使用了回复引用发送（其使用 `replyToBody`，而不是第二个 webhook）。
+- 查看状态/健康信息：`openclaw status --all` 或 `openclaw status --deep`。

-有关一般渠道工作流参考，请参见 [Channels](/zh-CN/channels) 和 [Plugins](/zh-CN/tools/plugin) 指南。
+有关渠道工作流的一般参考，请参见 [Channels](/zh-CN/channels) 和 [Plugins](/zh-CN/tools/plugin) 指南。

 ## 相关内容

- [Channels Overview](/zh-CN/channels) — 所有受支持的渠道
- [Pairing](/zh-CN/channels/pairing) — 私信身份验证与配对流程
- [Groups](/zh-CN/channels/groups) — 群聊行为与提及门控
- [Channel Routing](/zh-CN/channels/channel-routing) — 消息的会话路由
- [Security](/zh-CN/gateway/security) — 访问模型与加固
+- [Channels 概览](/zh-CN/channels) —— 所有支持的渠道
+- [Pairing](/zh-CN/channels/pairing) —— 私信身份验证与配对流程
+- [Groups](/zh-CN/channels/groups) —— 群聊行为与提及门控
+- [Channel Routing](/zh-CN/channels/channel-routing) —— 消息的会话路由
+- [Security](/zh-CN/gateway/security) —— 访问模型与加固措施
--- a/docs/zh-CN/concepts/messages.md
+++ b/docs/zh-CN/concepts/messages.md
@ -1,29 +1,29 @@
 ---
 read_when:
    - 解释入站消息如何变成回复
-    - 说明会话、队列模式或流式传输行为
+    - 澄清会话、队列模式或流式传输行为
    - 记录推理可见性及其使用影响
 summary: 消息流、会话、队列处理和推理可见性
 title: 消息
 x-i18n:
-    generated_at: "2026-04-21T04:19:34Z"
+    generated_at: "2026-04-21T08:44:50Z"
    model: gpt-5.4
    provider: openai
-    source_hash: ddf88b91f3489bfdfb4a84f8a287a1ec0b0d71a765dfe27c666c6f43d0145022
+    source_hash: 4f535d01872e7fcf0f3d99a5c5ac01feddbf7fb562ff61d9ccdf18f109f9922f
    source_path: concepts/messages.md
    workflow: 15
 ---

 # 消息

-本页汇总介绍 OpenClaw 如何处理入站消息、会话、队列、流式传输以及推理可见性。
+本页整合说明 OpenClaw 如何处理入站消息、会话、队列处理、流式传输以及推理可见性。

 ## 消息流（高级概览）

 ```text
 入站消息
-  -> 路由/绑定 -> 会话键
-  -> 队列（如果某次运行处于活动状态）
+  -> routing/bindings -> 会话键
+  -> 队列（如果某个运行处于活动状态）
  -> 智能体运行（流式传输 + 工具）
  -> 出站回复（渠道限制 + 分块）
 ```
@ -31,20 +31,20 @@ x-i18n:
 关键调节项位于配置中：

 - `messages.*` 用于前缀、队列处理和群组行为。
- `agents.defaults.*` 用于分块流式传输和分块默认值。
+- `agents.defaults.*` 用于分块流式传输和分块默认设置。
 - 渠道覆盖项（`channels.whatsapp.*`、`channels.telegram.*` 等）用于上限和流式传输开关。

-完整 schema 请参见 [Configuration](/zh-CN/gateway/configuration)。
+完整 schema 请参见 [配置](/zh-CN/gateway/configuration)。

 ## 入站去重

-渠道在重连后可能会重复投递同一条消息。OpenClaw 会维护一个短生命周期缓存，按 channel/account/peer/session/message id 建立键，因此重复投递不会再次触发智能体运行。
+渠道在重连后可能会重复投递同一条消息。OpenClaw 会保留一个短时缓存，以 channel/account/peer/session/message id 为键，因此重复投递不会再次触发智能体运行。

 ## 入站防抖

-来自**同一发送者**的快速连续消息，可以通过 `messages.inbound` 合并为单次智能体轮次。防抖按每个 channel + conversation 的范围生效，并使用最新消息来进行回复线程关联/ID 处理。
+来自**同一发送者**的快速连续消息可以通过 `messages.inbound` 被合并到同一个智能体轮次中。防抖按每个 channel + conversation 的范围生效，并使用最新的一条消息来处理回复线程关联 / ID。

-配置（全局默认值 + 每渠道覆盖）：
+配置（全局默认值 + 每个渠道的覆盖项）：

 ```json5
 {
@ -61,29 +61,29 @@ x-i18n:
 }
 ```

-注意：
+说明：

- 防抖仅适用于**纯文本**消息；媒体/附件会立即刷新。
- 控制命令会绕过防抖，以保持其独立性。
+- 防抖仅适用于**纯文本**消息；媒体 / 附件会立即刷新处理。
+- 控制命令会绕过防抖，以保持其独立性——**但**如果某个渠道明确选择加入同发送者私信合并（例如 [BlueBubbles `coalesceSameSenderDms`](/zh-CN/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition)），那么私信命令会在防抖窗口内等待，以便拆分发送的内容可并入同一个智能体轮次。

 ## 会话和设备

 会话由 Gateway 网关拥有，而不是由客户端拥有。

- 私聊会收敛到智能体主会话键。
- 群组/渠道会拥有各自的会话键。
- 会话存储和转录记录位于 Gateway 网关主机上。
+- 私聊会折叠到智能体主会话键。
+- 群组 / 渠道会获得各自独立的会话键。
+- 会话存储和转录记录保存在 Gateway 网关主机上。

-多个设备/渠道可以映射到同一会话，但历史记录不会完全同步回每个客户端。建议：长对话使用一个主设备，以避免上下文分叉。控制 UI 和 TUI 始终显示由 Gateway 网关支持的会话转录，因此它们是真实来源。
+多个设备 / 渠道可以映射到同一个会话，但历史不会完全同步回每一个客户端。建议：长对话尽量使用一个主设备，以避免上下文分叉。Control UI 和 TUI 始终显示由 Gateway 网关支持的会话转录，因此它们是事实来源。

-详情： [Session management](/zh-CN/concepts/session)。
+详情参见：[会话管理](/zh-CN/concepts/session)。

-## 入站正文和历史上下文
+## 入站消息体和历史上下文

-OpenClaw 将**提示正文**与**命令正文**分开：
+OpenClaw 将**提示正文**与**命令正文**分开处理：

- `Body`：发送给智能体的提示文本。它可能包含渠道信封和可选的历史包装。
- `CommandBody`：用于指令/命令解析的原始用户文本。
+- `Body`：发送给智能体的提示文本。它可能包含渠道封装信息和可选的历史包装。
+- `CommandBody`：用于指令 / 命令解析的原始用户文本。
 - `RawBody`：`CommandBody` 的旧别名（为兼容性保留）。

 当某个渠道提供历史记录时，它会使用共享包装：
@ -91,25 +91,25 @@ OpenClaw 将**提示正文**与**命令正文**分开：
 - `[Chat messages since your last reply - for context]`
 - `[Current message - respond to this]`

-对于**非私聊**（群组/渠道/房间），**当前消息正文**会带上发送者标签前缀（与历史记录条目使用相同风格）。这能让实时消息与排队/历史消息在智能体提示中保持一致。
+对于**非私聊**（群组 / 渠道 / 房间），**当前消息正文**会带上发送者标签前缀（与历史条目使用相同风格）。这样可让实时消息与排队 / 历史消息在智能体提示中保持一致。

-历史缓冲区是**仅待处理**的：它们包含未触发运行的群组消息（例如受提及门控的消息），并且**不包括**已经在会话转录中的消息。
+历史缓冲区是**仅待处理**的：它们包含未触发运行的群组消息（例如，受提及门控限制的消息），并且**不包含**已经进入会话转录的消息。

-指令剥离仅应用于**当前消息**部分，因此历史记录保持完整。包装历史记录的渠道应将 `CommandBody`（或 `RawBody`）设置为原始消息文本，并将 `Body` 保留为合并后的提示。历史缓冲区可通过 `messages.groupChat.historyLimit`（全局默认值）以及每渠道覆盖项（如 `channels.slack.historyLimit` 或 `channels.telegram.accounts.<id>.historyLimit`）进行配置（设为 `0` 可禁用）。
+指令剥离仅适用于**当前消息**部分，因此历史保持完整。包装历史的渠道应将 `CommandBody`（或 `RawBody`）设为原始消息文本，并将 `Body` 保持为合并后的提示。历史缓冲区可通过 `messages.groupChat.historyLimit`（全局默认值）以及每个渠道的覆盖项配置，例如 `channels.slack.historyLimit` 或 `channels.telegram.accounts.<id>.historyLimit`（设为 `0` 可禁用）。

-## 队列和后续消息
+## 队列处理和后续消息

-如果某次运行已经处于活动状态，入站消息可以排入队列、引导进入当前运行，或收集为后续轮次。
+如果某个运行已处于活动状态，入站消息可以排队、导入当前运行，或收集到后续轮次中。

- 通过 `messages.queue`（以及 `messages.queue.byChannel`）进行配置。
+- 通过 `messages.queue`（以及 `messages.queue.byChannel`）配置。
 - 模式：`interrupt`、`steer`、`followup`、`collect`，以及 backlog 变体。

-详情： [Queueing](/zh-CN/concepts/queue)。
+详情参见：[队列处理](/zh-CN/concepts/queue)。

 ## 流式传输、分块和批处理

 分块流式传输会在模型生成文本块时发送部分回复。
-分块会遵守渠道文本限制，并避免拆分围栏代码块。
+分块会遵守渠道文本限制，并避免拆分带围栏的代码块。

 关键设置：

@ -117,37 +117,37 @@ OpenClaw 将**提示正文**与**命令正文**分开：
 - `agents.defaults.blockStreamingBreak`（`text_end|message_end`）
 - `agents.defaults.blockStreamingChunk`（`minChars|maxChars|breakPreference`）
 - `agents.defaults.blockStreamingCoalesce`（基于空闲时间的批处理）
- `agents.defaults.humanDelay`（块回复之间拟人化的停顿）
- 渠道覆盖：`*.blockStreaming` 和 `*.blockStreamingCoalesce`（非 Telegram 渠道需要显式设置 `*.blockStreaming: true`）
+- `agents.defaults.humanDelay`（在分块回复之间模拟人类停顿）
+- 渠道覆盖项：`*.blockStreaming` 和 `*.blockStreamingCoalesce`（非 Telegram 渠道需要显式设置 `*.blockStreaming: true`）

-详情： [Streaming + chunking](/zh-CN/concepts/streaming)。
+详情参见：[流式传输 + 分块](/zh-CN/concepts/streaming)。

 ## 推理可见性和 token

 OpenClaw 可以显示或隐藏模型推理：

- `/reasoning on|off|stream` 用于控制可见性。
- 如果模型产生了推理内容，这些内容仍会计入 token 使用量。
- Telegram 支持将推理流式输出到草稿气泡中。
+- `/reasoning on|off|stream` 控制可见性。
+- 推理内容一旦由模型生成，仍会计入 token 用量。
+- Telegram 支持将推理流式显示到草稿气泡中。

-详情： [Thinking + reasoning directives](/zh-CN/tools/thinking) 和 [Token use](/zh-CN/reference/token-use)。
+详情参见：[Thinking + reasoning directives](/zh-CN/tools/thinking) 和 [Token 使用](/zh-CN/reference/token-use)。

 ## 前缀、线程和回复

 出站消息格式由 `messages` 统一管理：

 - `messages.responsePrefix`、`channels.<channel>.responsePrefix` 和 `channels.<channel>.accounts.<id>.responsePrefix`（出站前缀级联），以及 `channels.whatsapp.messagePrefix`（WhatsApp 入站前缀）
- 通过 `replyToMode` 和每渠道默认值处理回复线程
+- 通过 `replyToMode` 和每个渠道默认值实现回复线程关联

-详情： [Configuration](/zh-CN/gateway/configuration-reference#messages) 和各渠道文档。
+详情参见：[配置](/zh-CN/gateway/configuration-reference#messages) 和各渠道文档。

 ## 静默回复

 精确的静默标记 `NO_REPLY` / `no_reply` 表示“不要发送用户可见的回复”。
-OpenClaw 会按会话类型解析该行为：
+OpenClaw 会按会话类型解析这一行为：

- 私聊默认不允许静默，并会将纯静默回复重写为简短的可见回退文本。
- 群组/渠道默认允许静默。
+- 私聊默认不允许静默，并会将纯静默回复重写为简短的可见回退内容。
+- 群组 / 渠道默认允许静默。
 - 内部编排默认允许静默。

 默认值位于 `agents.defaults.silentReply` 和
@ -156,7 +156,7 @@ OpenClaw 会按会话类型解析该行为：

 ## 相关内容

- [Streaming](/zh-CN/concepts/streaming) — 实时消息传递
- [Retry](/zh-CN/concepts/retry) — 消息传递重试行为
- [Queue](/zh-CN/concepts/queue) — 消息处理队列
- [Channels](/zh-CN/channels) — 消息平台集成
+- [流式传输](/zh-CN/concepts/streaming) —— 实时消息传递
+- [重试](/zh-CN/concepts/retry) —— 消息投递重试行为
+- [队列](/zh-CN/concepts/queue) —— 消息处理队列
+- [渠道](/zh-CN/channels) —— 消息平台集成