Telegram forum topic、群 session 和 thread key 应该怎么一起看

OpenClaw 最近的 Groups 和 Channel Routing 文档里，有一个很容易被忽略但很值的细节：

• Telegram forum topic 会把 :topic:<threadId> 编进 group session key

这意味着在 OpenClaw 眼里：

• 同一个 Telegram 群
• 不同 forum topic

已经不是同一条会话。

官方当前 key 形态是什么

文档现在明确给出的形态是：

• agent:<agentId>:telegram:group:<groupId>:topic:<threadId>

这和普通群 key：

• agent:<agentId>:telegram:group:<groupId>

已经是两种不同 bucket。

这对实际使用意味着什么

最重要的结果有两个：

1. 一个 topic 里的命令和状态不会天然影响另一个 topic
2. 群内多条讨论线可以各自保留上下文

这对支持群、项目群、社区群都很值，因为 forum topic 天然就在扮演：

• 子线程

为什么这不只是显示层区别

很多人第一次看到 forum topic，会以为只是：

• UI 上多了个 thread

但 OpenClaw 这里已经把它放进 session key 了。
这说明官方当前理解的是：

• topic 本身就是上下文隔离边界

而不是：

• 同一群里的视觉分组

mention 和 activation 还怎么生效

即便进了 topic 维度，前面的群规则仍然成立：

• groupPolicy
• group allowlist
• mention gating

也就是说，topic 不会绕过群入口治理。
它改变的是：

• 一旦触发后，上下文落在哪个 session key

什么情况下最值得利用这条边界

下面这些场景尤其适合把 topic 当正式会话边界来看：

• 一个大群里并行多个项目
• 同一个群里分 FAQ / support / bug / release topic
• 社区里需要让机器人在多个话题保持各自上下文

这时候 topic 化会比“一个群一个总会话”稳很多。

常见误会

1. 以为同群 topic 一定会共享全部上下文

不会。
topic key 已经把它们拆开了。

2. 以为 topic 能替代 allowlist 或 mention 规则

也不会。
topic 只是在通过前序群规则后，决定：

• 会话到底落到哪个桶里

推荐延伸阅读

• 回复机器人消息也算 mention 吗，pending history 又什么时候会进上下文
• groupPolicy、allowlist 和 mention gating 的顺序应该怎么理解
• 共享群入口更稳的放开顺序：allowlist、mention、activation 和 broadcast