Mattermost 应将频道消息与线程消息的 requireMention 分开控制
OpenClaw News Editorial Desk
一项 OpenClaw Mattermost 配置诉求是：频道主消息可以要求 mention，但线程内回复不应被同一条规则一刀切拦住。
为什么这件事重要
在很多 Mattermost 使用场景里，频道消息和线程消息承担的是两种不同语义。频道里噪音更大，要求 mention 是合理的；但线程往往代表已经建立上下文的持续对话，如果仍然要求每次回复都重新 mention，体验就会明显变差。
这意味着：单一的全局 requireMention 规则虽然实现简单，但在运维体验上反而会制造误判。
运维真正想要的行为
目标其实很直接：
- 频道顶层消息继续要求 mention
- 但在线程里，已经进入对话后的回复不必每次再次显式 mention
这样既能控制频道噪音，也不会让线程追问看起来像“机器人坏了”。
常见误判形态
当单一 requireMention 规则被套用到所有场景时，常见现象是：
- 机器人会正确忽略未 mention 的频道主消息
- 但它也会一并忽略线程中的后续回复
- 用户看到的感受不是“策略生效”，而是“线程能力不稳定”
- 支持侧开始排查投递链路，实际上问题可能只是策略粒度不够
这也是为什么它属于高意图 troubleshooting 题：表面像消息丢失，实质可能是配置边界不合理。
如何确认是不是同一类问题
在把它归因到同一问题前，先确认下面几点：
- Mattermost 集成本身是健康的
- 显式 mention 时机器人可以正常响应
- 漏回复主要集中在线程内追问
- 在线程里补一个新的 mention 后，行为会发生变化
如果这几条都成立，更像是策略粒度问题，而不是传输或 webhook 故障。
这不是什么
先排除几种更简单的解释：
- Mattermost 机器人本身离线或断连
- channel 绑定配置错误
- 用户回复没有真正落在线程上下文里
- 消息被别的权限或 mention 规则拦住
- 机器人根本没有收到这条事件
如果命中这些情况，问题就在消息投递或路由，而不是 mention 策略的作用域。
为什么团队容易误诊
这个问题容易被误读，是因为用户肉眼看到的是“同一段对话”。人会自然认为：既然机器人已经在这个线程里回过一次，后面就该自动继续。
但如果顶层消息和线程消息被同一种策略处理，那么线程中的继续追问仍可能被拦掉，即便从用户视角看，这段对话早就已经开始了。
上游支持前的临时建议
在配置层还不能把频道与线程的 mention 策略拆开之前，可以先这样止损：
- 明确告诉使用者：线程内继续追问时仍需显式 mention
- 机器人密集交互尽量放在规则更可预测的频道场景
- 不要把“已有线程上下文”直接视为必然触发条件
- 让支持人员先区分“策略忽略”与“投递失败”
最实用的一条经验是：机器人在线程里回过一次，不代表后续每次都能自动接上。
排查与响应顺序
如果用户反馈“机器人在线程里突然不回了”，建议按这个顺序检查：
- 先验证机器人是否还能响应一条新的、明确 mention 的消息
- 对比频道顶层消息与线程内消息的表现差异
- 测试在线程里补一次新的 mention 是否恢复响应
- 只有这些都做完，再升级到日志或投递链路排查
这样可以避免在错误层面浪费排障时间。
Source
- 候选问题来自内部 editorial queue
