OpenClaw 中文文档
本页内容

本页内容

查看 Markdown以纯文本查看本页在 ChatGPT 中打开针对本页提问在 Claude 中打开针对本页提问

主流消息传递

Slack 线程和会话

Slack 对话如何映射到 OpenClaw 会话，以及回复的位置。

线程、会话与回复标签

  • DM 路由为 direct；通道为channel； MPIM 为 group。
  • Slack 路由绑定接受原始对等 ID 加上 Slack 目标形式，例如 channel:C12345678、user:U12345678 和 <@U12345678>。
  • 使用默认 session.dmScope=main 时，普通 Slack DM 会崩溃到代理主会话。代理视图根和现有助理视图线程保持隔离为 :thread:<threadTs> 会话；请参阅 Agent 查看 DM。
  • 频道会话：agent:<agentId>:slack:channel:<channelId>。
  • 普通顶层频道消息会留在按频道划分的会话中，即使 replyToMode 不是 off 也是如此。
  • Slack 频道、MPIM、Agent View 和 Assistant View 的线程回复会使用父级 Slack thread_ts 作为会话后缀（:thread:<threadTs>）。普通 DM 回复线程仍然只是基于 DM 主会话的 UI 表现。
  • 当 OpenClaw 需要将符合条件的顶级通道根播种到 agent:<agentId>:slack:channel:<channelId>:thread:<rootTs> 中时，该根预计将启动可见的 Slack 线程，因此根和后续线程回复共享一个 OpenClaw 会话。这适用于 app_mention 事件、显式机器人或配置的提及模式匹配，以及具有非 off replyToMode 的 requireMention: false 通道。
  • channels.slack.thread.historyScope 默认值为 thread；thread.inheritParent 默认值为 false。
  • channels.slack.thread.initialHistoryLimit 控制新线程会话启动时获取的现有线程消息数量（默认 20；将 0 设置为禁用）。房间线程播种也受 historyLimit 的限制。
  • channels.slack.implicitMentions.replyToBot 控制是否允许回复机器人自己的消息时绕过提及门控（默认 true）。
  • channels.slack.implicitMentions.threadParticipation 控制机器人已回复的线程中的后续操作是否绕过提及门控（默认 true）。将其设置为 false 以要求在这些后续操作中明确提及新的内容。 openclaw doctor --fix 将以前的 channels.slack.thread.requireExplicitMention 密钥迁移到此正标志。
  • 账户级覆盖位于 channels.slack.accounts.<id>.implicitMentions；共享默认值位于 channels.defaults.implicitMentions。
  • requireMentionInBotThreads 覆盖此机器人启动的线程中的提及门控：false 允许未提及的回复；无论隐式回复或参与信号如何，true 都需要提及。在 Slack 根、帐户或通道范围中配置它。省略它以保留上面的隐式提及行为。其他人发起的线程保持其正常策略。请参阅 bot 创建的线程设置。

回复线程控制：

  • channels.slack.channels.<id>.replyToMode：Slack channel/private-channel 消息的每通道覆盖
  • channels.slack.replyToMode：off|first|all|batched（默认 off）
  • channels.slack.replyToModeByChatType：按 direct|group|channel 区分
  • 直聊的旧版回退：channels.slack.dm.replyToMode

支持手动回复标签：

  • [[reply_to_current]]
  • [[reply_to:<id>]]

对于来自 message 工具的显式 Slack thread replies，设置 replyBroadcast: true，并配合 action: "send" 和 threadId 或 replyTo，以请求 Slack 也将该 thread reply 广播到父频道。这会映射到 Slack 的 chat.postMessage reply_broadcast 标志，并且仅支持文本或 Block Kit 发送，不支持媒体上传。

当 message 工具调用在 Slack 线程内运行并针对同一频道时，OpenClaw 通常会根据有效帐户、聊天类型或每个频道 replyToMode 继承当前 Slack 线程。自动回复和同一通道 send 或 upload-file 呼叫使用相同的每通道覆盖。在 action: "send" 或 action: "upload-file" 上设置 topLevel: true 以强制使用新的父通道消息。 threadId: null 被接受为相同的顶级选择退出。

Agent 查看 DM

Slack 代理视图 （features.agent_view） 是 Slack 针对 AI 应用程序的消息传递体验。 Slack 将应用程序标记为代理，并且在应用程序的 Messages 选项卡中，在顶级编辑器中键入的每条消息都会启动一个新根，Slack 会自行线程化；后续活动属于该根的线程内。 OpenClaw 将每个根视为一个单独的会话：

  • Each 根在 session.dmScope 选择的任何基本会话之上获得 :thread:<rootTs> 后缀，因此即使在默认的 main 范围下，根也保持隔离。对于 per-channel-peer，根看起来像 agent:main:slack:direct:U12345678:thread:1777244748.777299； main 看起来像 agent:main:main:thread:1777244748.777299。
  • 根线程内的后续活动保留在该根的会话上。新的顶级作曲家消息启动新会话。
  • 无论 replyToMode 为何， 回复和线程状态都保留在可见根上，因为 Slack 拥有线程。
  • Slack 的活动视图实体 （app_context） 仅作为 Slack 相关顺序中的结构化不可信上下文到达代理；没有 app_context 的 DM 会清除该回合的实体，而不是重用陈旧的实体。

Slack从不说明应用程序使用哪些体验，所以OpenClaw从它看到的第一个信号记录代理视图：app_context_changed事件，一个DM携带着app_context，或无螺纹assistant.threads.setSuggestedPrompts称呼OpenClaw当会员打开留言选项卡。Slack接听电话ok or internal_error对于 Agent View 应用程序和not_agent_app对于 Assistant View 应用程序，因此两者ok和internal_error算作证据；传输失败仍不确定，并在下次打开时重试。一个DM谁thread_ts等于自己的ts被认为是Slack-自行管理根。在看到这些信号之一之前，一个简单的DM根遵循普通DM路由。

该标记是持久的，并由帐户、工作区和 Slack 应用程序 ID 键入，因此一旦应用程序 ID 已知，代理视图就可以在网关重新启动后继续存在。套接字模式在启动时从应用程序令牌读取应用程序 ID。 HTTP 模式从启动后的第一个签名事件中学习并记录 slack app id <id> learned from signed event 一次。中继模式没有应用程序 ID 源，因此其标记仅存在于正在运行的进程中。 features.assistant_view 上的现有应用程序保留 Assistant View 线程；请参阅 附加清单设置 。

最近房间历史记录

允许的通道和组轮流从 Slack 获取最近的窗口，包括在网关重新启动后。 channels.slack.historyLimit 限制窗口（默认 50，messages.groupChat.historyLimit 作为后备）。帐户覆盖适用。自动观察消息窗口的上限为 200 条消息； JSON 整数最大值 （9007199254740991） 选择 50 条消息默认值。

对于观察到的 DM 上下文，dmHistoryLimit 和 dms.<userId>.historyLimit 使用默认值 0（禁用）和最多 200 条消息。 JSON 整数最大值选择禁用的默认值，包括每个 DM 覆盖。

这些保存的字段还控制用户轮流中的嵌入式会话记录修剪，其中 0 表示不修剪，并且现有的逐出缓冲仍然适用。 Doctor 保留配置的值；观察到的消息上限不会强加新的转录轮次上限。使用 requireMention: true，不满足配置的提及或隐式提及门的消息不会启动代理轮流或自动历史记录读取。

Slack 保持权威：编辑、删除、保留、令牌范围和可用性控制检索。没有单独的 OpenClaw 消息存档。恢复不会重写之前的代理记录。新的最近窗口尊重活动会话边界；初始线程播种保持其现有的 thread.initialHistoryLimit 行为。当前消息、去抖源消息和后续消息均从最近窗口中排除。初始线程历史记录使用其现有渲染路径一次。对于 thread.historyScope: "channel"，最近的窗口使用通道时间线，而初始线程播种保持独立。

线程范围的历史记录仅读取该线程。 Slack 首先返回最早的线程回复，因此自动线程恢复在三页后停止。如果无法到达最近的末尾，OpenClaw 会记录一个遗漏，而不是将旧的前缀显示为最新的。过滤和 Slack 页面限制也可以产生更短的窗口。读取失败会忽略自动历史记录，但不会丢弃所寻址的消息。最近窗口媒体恢复最多尝试四个图像附件，包括失败的尝试。当前消息和明确回复媒体保持各自的限制。

设置 historyLimit: 0 以禁用自动房间历史记录，包括初始房间线程历史记录。显式回复和线程启动上下文保持分离。现有的 message(action="read") 工具可以在重新启动或会话重置后对旧的 Slack 消息进行分页，但需要 Slack 访问和保留。

本页有帮助吗？