故障排除

    按顺序检查：

    - `groupPolicy`
    - 频道允许列表（`channels.slack.channels`）— **键必须是频道 ID**（`C12345678`）或工作区限定的频道目标（`team:<team-id>:channel:<channel-id>`），而不是名称（`#channel-name`）。在 `groupPolicy: "allowlist"` 下，基于名称的键会静默失败，因为频道路由默认以 ID 优先。要查找 ID：在 Slack 中右键点击频道 → **复制链接** — URL 末尾的 `C...` 值就是频道 ID。
    - `requireMention`
    - 每个频道的 `users` 允许列表
    - `messages.groupChat.visibleReplies`：普通的群组/频道请求默认使用 `"automatic"`。如果你选择了 `"message_tool"`，并且日志显示助手文本但没有 `message(action=send)` 调用，说明模型错过了可见的 message-tool 路径。在此模式下，最终文本保持私密；请检查 Gateway 详细日志中被抑制的负载元数据，或者如果你希望所有普通的助手最终回复都通过旧路径发布，则将其设置为 `"automatic"`。
    - `messages.groupChat.unmentionedInbound`：如果设置为 `"room_event"`，未提及的允许频道闲聊将作为环境背景信息，除非代理调用 `message` 工具，否则保持静默。参见 [环境房间事件](../ambient-room-events.md)。

```json5
{
  messages: {
    groupChat: {
      visibleReplies: "automatic",
    },
  },
}
```

    有用的命令：

```bash
openclaw channels status --probe
openclaw logs --follow
openclaw doctor
```

    当准备阶段拒绝入站事件时，info 级别日志会记录
    `Slack inbound event rejected during preparation`，并包含原因和路由 ID。
    记录描述的是尝试：被拒绝的 `message` 事件之后仍可能出现
    同一帖子的成功 `app_mention` 事件。自发消息循环预防保持静默。

    检查：

    - `channels.slack.dm.enabled`
    - `channels.slack.dmPolicy`（或旧版 `channels.slack.dm.policy`）
    - 配对审批 / 允许列表条目（`dmPolicy: "open"` 仍然需要 `channels.slack.allowFrom: ["*"]`）
    - 群组 DM 使用 MPIM 处理；启用 `channels.slack.dm.groupEnabled`，如果已配置，将 MPIM 包含在 `channels.slack.dm.groupChannels` 中
    - Slack Assistant DM 事件：提及 `drop message_changed` 的详细日志通常意味着
      Slack 发送了一个经过编辑的 Assistant 线程事件，而消息元数据中
      没有可恢复的人类发送者

```bash
openclaw pairing list slack
```

症状：应用的 **Messages** 选项卡中的每条顶级消息都落在同一个会话（主会话，或一个 `slack:direct:<userId>` 会话）上，而不是它自己的 `:thread:<rootTs>` 会话，尽管 Slack 将每条消息显示为独立的线程。

按顺序检查：

- manifest 使用带有 `assistant:write` 的 `features.agent_view`，并订阅了 `app_context_changed`。仍然使用 `features.assistant_view` 的应用会获得 Assistant View 线程，而一旦应用切换到 Agent View，Slack 无法将其移回。
- 自应用安装以来，OpenClaw 已检测到 Agent View 信号：打开应用的 **Messages** 选项卡一次，或从 Agent View 撰写器中发送一条 DM。在详细日志中，对于 Agent View 应用，打开 Messages 选项卡时出现 `slack suggested prompts update failed for channel D...: internal_error` 是预期的，并可作为证据。
- 在 HTTP 模式下，Gateway 自启动以来已收到至少一个签名事件；日志中的 `slack app id <id> learned from signed event` 确认可以读取持久标记。Socket Mode 在启动时从 app token 读取应用 ID，因此不需要事件。
- 出现 `Slack Agent View state failed to open`、`persist` 或 `load` 等警告，意味着持久标记无法存储或读取。运行进程中已检测到的信号仍然有效。重启后，当 OpenClaw 成功读取存储的标记或检测到新信号时，Agent View 会恢复。

参见 [Agent View DM](threads-and-sessions.md#agent-view-dms)。

此 normal 级别诊断意味着 Slack 接受了 `processing`，但拒绝了最终的 `active` 更新。启用 [详细日志](../../logging.md) 以检查 Slack API 失败。该诊断不会改变现有的重试或清理行为。

被拒绝或不受支持的 `processing` 写入不会触发此诊断。已接受的 `active` 写入不保证 Slack Desktop 已刷新其工作指示器。

验证 Slack 应用设置中的 bot + app token 和 Socket Mode 启用状态。App-Level Token 需要 `connections:write`，Bot User OAuth Token 机器人令牌必须与 app token 属于同一个 Slack 应用/工作区。

如果 `openclaw channels status --probe --json` 显示 `botTokenStatus` 或 `appTokenStatus: "configured_unavailable"`，则 Slack 账户已配置，但当前运行时无法解析通过 SecretRef 引用的值。

诸如 `slack socket mode failed to start; retry ...` 之类的日志是可恢复的启动失败。缺少 scope、token 被撤销和无效认证会快速失败。`slack token mismatch ...` 日志意味着 bot token 和 app token 似乎属于不同的 Slack 应用；请修复 Slack 应用凭据。

验证：

- 签名密钥
- webhook 路径
- Slack Request URL（Events + Interactivity + Slash Commands）
- 每个 HTTP 账户唯一的 `webhookPath`
- 公共 URL 终止 TLS 并将请求转发到 Gateway 路径
- Slack 应用的 `request_url` 路径与 `channels.slack.webhookPath`（默认为 `/slack/events`）完全匹配

如果账户快照中出现 `signingSecretStatus: "configured_unavailable"`，则 HTTP 账户已配置，但当前运行时无法解析通过 SecretRef 引用的签名密钥。