OpenClaw Bug：Mattermost 在 replyToMode="all" 时 Markdown 格式会丢失

OpenClaw 新近暴露出一个很典型、也很影响体验的 Mattermost 问题：当 replyToMode 配成 "all" 时，Markdown 格式可能会整体失效。

也就是说，本来应该正常渲染的：

加粗
斜体
列表
行内 code
代码块

到了 Mattermost 里，可能全都变成普通文本。

来源 issue： openclaw/openclaw#51755

TL;DR

如果你的 Mattermost 配置里是这样：

{
  "channels": {
    "mattermost": {
      "replyToMode": "all"
    }
  }
}

那么 OpenClaw 在发送回复时，可能会把 Markdown 结构压平，导致格式完全不渲染。

目前 issue 里给出的临时绕过方法非常直接：

把 replyToMode 从 "all" 改成 "off"

按反馈，这样可以恢复 Markdown 的正常渲染。

这个 bug 的表现是什么

根据 issue 描述，复现路径很短：

把 Mattermost 配成 replyToMode: "all"
发送一条带 Markdown 的消息
让 OpenClaw 回应
观察 Mattermost 中实际呈现的效果

受影响的格式包括：

加粗
斜体
列表
代码块

报告中的环境是：

OpenClaw 版本：2026.3.13
频道：Mattermost
模式：DM

为什么这不是“小问题”

表面看它像是样式问题，但实际不是。

在真正的聊天工作流里，Markdown 承担的是“结构表达”作用。格式一丢，结果会变成：

回复更难读
步骤说明更难扫
命令/日志更难区分
故障排查内容更容易误读

如果你的团队真把 Mattermost 当工作界面，这类问题不是 cosmetic bug，而是明确的可用性回退。

一个非常关键的线索：直接调 Mattermost API 是正常的

issue 里有个很重要的细节：如果直接通过 Mattermost API 并带 root_id 发消息，Markdown 是能正常保留的。

这意味着排查方向应该更多指向 OpenClaw 自己的 reply 处理链路，而不是 Mattermost 平台本身。

换句话说：

Mattermost 本身看起来是能渲染这些 Markdown 的
问题很可能发生在 OpenClaw 处理 replyToMode: "all" 这条逻辑路径时

这类线索很有价值，因为它能直接缩小修复范围。

谁最可能被这个问题打中

如果 issue 的行为稳定复现，那最受影响的通常会是这几类用户：

高频使用 Mattermost 渠道的人
依赖 回复/线程语义 的部署
配置了 replyToMode: "all"
经常让机器人输出列表、步骤、代码片段的人

相反，如果你本来就用 replyToMode: "off"，可能压根不会碰到。

当前最稳的绕过方案

就目前信息看，最稳妥的处理方式还是 issue 里提到的配置回退：

{
  "channels": {
    "mattermost": {
      "replyToMode": "off"
    }
  }
}

改完后，按你的部署方式重启或重载 OpenClaw gateway。

这当然会牺牲掉 "all" 模式带来的回复行为，但它是现在恢复可读输出的最低风险方案。

怎么判断自己是不是命中了同一个问题

建议做一个非常短的 A/B 测试。

测试 A：保留当前配置

维持 replyToMode: "all"
发一个强制结构化输出的 prompt，比如：
- “请用一个加粗标题、一个 3 项列表、一个 fenced code block 回复我”
看 Mattermost 里最终渲染效果

测试 B：改成 workaround

把 replyToMode 改成 "off"
重启 / 重载 OpenClaw
用同样的 prompt 再测一次
对比渲染差异

如果只有改成 "off" 后格式才恢复，那你大概率就是踩中了同一个 bug。

上游大概率该往哪里修

从 issue 现有线索看，修复点很可能在 OpenClaw 的 reply 处理流程里。

比较值得优先检查的是：

Markdown 是否在 reply 包装阶段被转成了纯文本
是否有某一层对内容做了错误的 escaping / normalize
replyToMode: "all" 与 replyToMode: "off" 的 Mattermost 发送路径是否并不一致

最好分别对这些内容做回归测试：

加粗 / 斜体
有序 / 无序列表
行内代码
fenced code block
引用块

因为格式 bug 经常不是“全坏”，而是某几类元素被意外吃掉。

给运维方的建议

如果你现在在跑 OpenClaw + Mattermost，我会建议你立刻做这几件事：

先检查是否启用了 replyToMode: "all"
发一条格式化测试消息
如果格式异常，先改回 "off"
持续跟踪上游 issue 的正式修复

如果你的团队很依赖机器人输出的可读性，我会把这个问题按“真实生产问题”对待，而不是当成一个无关紧要的 UI 瑕疵。

一份更适合值班场景的快速处理清单

如果你想低摩擦处理这类事故，建议按这个顺序做：

先确认异常是否只在 replyToMode: "all" 下出现
保存一份变更前/变更后的消息样例，方便内部留档
将 Mattermost 配置临时回退到 "off"
重启或重载 gateway
用同一条 Markdown 测试 prompt 再跑一次
记录 OpenClaw 的具体版本，并把上游 issue 链接写进故障记录

这样做的好处是：你不仅有临时 workaround，还有一条可逆、可验证、可向团队解释的处置链路。

搜索入口补强

真实搜索里，运维更常搜的是症状，而不是完整 issue 标题，比如：

OpenClaw Mattermost markdown 失效
replyToMode all markdown 丢失
Mattermost 机器人加粗列表代码块不渲染
OpenClaw Mattermost 回复变纯文本
replyToMode off 恢复 markdown Mattermost

如果你是从这些搜索词进来的，最快判断路径是：

如果 Markdown 只在 replyToMode="all" 时出问题
- 那你大概率命中的就是本文讨论的这类故障。
如果改成 "off" 以后仍然不渲染
- 那更像是更广义的 Mattermost 渲染链路问题，不一定是这篇说的同一类 bug。
如果直接调 Mattermost API 正常，但 OpenClaw 回复不正常
- 优先看 OpenClaw 的 reply 处理链路，而不是先怪 Mattermost。
如果回退到 "off" 后立刻恢复
- 那对生产环境来说，已经足够支撑先回退止血，再等上游正式修复。

按“症状 → 分流”的方式判断，通常比一上来钻配置细节更快。

哪些情况大概率不是这篇在说的问题

如果你遇到的是下面这些情况，这篇文章大概率不对症：

你根本没在用 Mattermost
Mattermost 原生发帖和 OpenClaw 回复都一起失去格式
你的问题核心是消息发不出去，而不是格式不渲染
问题是加了自定义代理 / formatter / 插件之后才出现的

这几种情况更应该先查 Mattermost 本身的渲染行为、插件干扰或自定义传输链路，而不是先假设命中了 replyToMode: "all" 这个回归。

3 步运维摘要

如果你只有 2 分钟，优先按这个顺序做：

先用 replyToMode: "all" 跑一条带 Markdown 的测试回复
再改成 "off"，用完全相同的测试再跑一次
如果格式恢复，就把 "off" 作为生产止血方案先落地，并持续跟踪上游修复

如果第 2 步改完也没变化，这篇文章大概率不是你的准确命中页。如果第 3 步能恢复可读性，就足够支撑先回退配置。

哪些场景不该继续硬扛等待上游修复

如果机器人输出经常用于下面这些场景，我不建议继续忍：

值班排障
部署步骤说明
事故总结
需要同事直接复制执行的命令

因为在这些场景里，Markdown 失真不是“丑一点”，而是会直接降低可读性和可信度。

Source

原始问题报告： openclaw/openclaw#51755