跳转至

线程与会话

Slack 对话如何映射到 OpenClaw 会话,以及回复落在哪里。

线程、会话和回复标签

  • 私信按 direct 路由;频道按 channel 路由;MPIM 按 group 路由。
  • Slack 路由绑定接受原始对等方 ID,以及 Slack 目标形式,例如 channel:C12345678、user:U12345678 和 <@U12345678>。
  • 在默认 session.dmScope=main 下,普通 Slack 私信会合并到 agent 主会话。Agent View 根消息和现有 Assistant View 线程仍作为 :thread:<threadTs> 会话保持隔离;参见 Agent View 私信。
  • 频道会话:agent:<agentId>:slack:channel:<channelId>。
  • 普通顶层频道消息仍保留在按频道划分的会话中,即使 replyToMode 不是 off。
  • Slack 频道、MPIM、Agent View 和 Assistant View 的线程回复使用父级 Slack thread_ts 作为会话后缀(:thread:<threadTs>)。普通私信回复线程仍然是基础私信会话上的 UI 辅助功能。
  • 当某个顶层频道根消息预计会启动一个可见的 Slack 线程时,OpenClaw 会将符合条件的根消息播种到 agent:<agentId>:slack:channel:<channelId>:thread:<rootTs>,使该根消息及后续线程回复共享同一个 OpenClaw 会话。这适用于 app_mention 事件、显式机器人提及或已配置的提及模式匹配,以及 requireMention: false 且 replyToMode 非 off 的频道。
  • 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 根、账户或频道作用域中配置它。省略它可保留上述隐式提及行为。由其他人启动的线程保持其正常策略。参见 机器人创建的线程设置。

回复线程控制:

  • channels.slack.channels.<id>.replyToMode:针对 Slack 频道/私有频道消息的按频道覆盖
  • channels.slack.replyToMode:off|first|all|batched(默认 off)
  • channels.slack.replyToModeByChatType:按 direct|group|channel 分别设置
  • direct 聊天的旧版回退:channels.slack.dm.replyToMode

支持手动回复标签:

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

对于来自 message 工具的显式 Slack 线程回复,请设置 replyBroadcast: true,并配合 action: "send" 以及 threadId 或 replyTo,以请求 Slack 同时将线程回复广播到父频道。这对应 Slack 的 chat.postMessage reply_broadcast 标志,仅支持文本或 Block Kit 发送,不支持媒体上传。

当 message 工具调用在 Slack 线程内运行并指向同一频道时,OpenClaw 通常会根据生效的账户、聊天类型或按频道 replyToMode 继承当前 Slack 线程。自动回复以及同频道的 send 或 upload-file 调用使用相同的按频道覆盖。请在 action: "send" 或 action: "upload-file" 上设置 topLevel: true,以强制改为发送新的父频道消息。threadId: null 被视为相同的顶层退出选项。

Note

replyToMode="off" 会禁用可选的出站 Slack 回复线程,包括显式 [[reply_to_*]] 标签。Agent View 和 Assistant View 是由 Slack 管理的线程化体验,因此无论此设置如何,其回复和状态都会保留在可见根消息上。它不会压平其他入站 Slack 线程会话。这与 Telegram 不同,在 "off" 模式下显式标签仍会被遵守。Slack 线程会将消息从频道中隐藏,而 Telegram 回复仍以内联形式可见。

Agent View 私信

Slack Agent View(features.agent_view)是 Slack 为 AI 应用提供的消息体验。Slack 会将应用标记为 agent,并且在应用的 消息 标签页中,在顶层输入框中输入的每条消息都会启动一个新的根消息,Slack 会自行对其进行线程化;后续消息属于该根消息的线程内。OpenClaw 将每个根消息视为一个独立会话:

  • 每个根消息都会在 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 相关性顺序中的结构化不可信上下文形式到达 agent;没有 app_context 的私信会清除该轮次的实体,而不是复用过期实体。

Slack 从不说明应用使用的是哪种体验,因此 OpenClaw 会从它看到的以下信号中的第一个记录 Agent View:app_context_changed 事件、携带 app_context 的私信,或当成员打开 消息 标签页时 OpenClaw 发起的无线程 assistant.threads.setSuggestedPrompts 调用。对于 Agent View 应用,Slack 会以 ok 或 internal_error 响应该调用;对于 Assistant View 应用,则以 not_agent_app 响应,因此 ok 和 internal_error 都算作证据;传输失败仍不确定,并会在下次打开时重试。thread_ts 等于自身 ts 的私信会被单独识别为由 Slack 管理的根消息。在看到这些信号之一之前,普通私信根消息遵循普通私信路由。

该标记是持久的,并以账户、工作区和 Slack 应用 ID 作为键,因此在已知应用 ID 后,Agent View 可以在 Gateway 重启后保留。Socket Mode 在启动时从应用 token 读取应用 ID。HTTP 模式在启动后从第一个签名事件中学习它,并记录一次 slack app id <id> learned from signed event。Relay 模式没有应用 ID 来源,因此其标记仅存在于运行中的进程中。位于 features.assistant_view 上的现有应用会保留 Assistant View 线程;请参阅其他清单设置。

最近房间历史

已准入的频道和群组轮次会从 Slack 获取最近窗口,包括在 Gateway 重启之后。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 仍然是权威来源:编辑、删除、保留策略、token 权限范围和可用性决定检索。没有单独的 OpenClaw 消息存档。 恢复不会重写先前的代理转录。 新的最近窗口会尊重活动会话边界;初始线程填充保留其现有的 thread.initialHistoryLimit 行为。当前消息、防抖源消息和后续消息会被排除在最近窗口之外。 初始线程历史仅使用其现有渲染路径一次。当 thread.historyScope: "channel" 时,最近窗口使用频道时间线,而初始线程填充保持独立。

线程范围的历史读取只读取该线程。Slack 按最旧优先返回线程回复,因此自动线程恢复在三页后停止。如果无法到达最近端,OpenClaw 会记录遗漏,而不是将旧前缀呈现为最近内容。过滤和 Slack 分页限制也可能产生更短的窗口。读取失败会省略自动历史,但不会丢弃目标消息。 最近窗口的媒体恢复最多尝试四个图片附件,包括失败的尝试。当前消息和显式回复的媒体保留其各自的限制。

设置 historyLimit: 0 可禁用自动房间历史,包括初始房间线程历史。显式回复和线程发起者上下文保持独立。 现有的 message(action="read") 工具可以在重启或会话重置后分页浏览更早的 Slack 消息,具体取决于 Slack 访问权限和保留策略。

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