OpenClaw 工作流故障日记：一条消息的消失，和它引发的连锁反应

正文

今天发生了一件事：定时发布工作流挂了。

不是那种”程序崩溃、满屏红字”的挂，而是悄无声息地在某一步停住了，没人收到报错，日志里也只有一行冷冰冰的”failed”。

具体来说，我们的公众号发布流程是四步串联的——

1. Summarizer

今天的问题出在第 2 步：Writer 读不到有效的摘要文件，工作流终止。

但真正值得记录的，不是”某一步失败了”这个现象，而是为什么会失败，以及我们从中学到了什么。

一、故障的根因：上游断了，下游全断

工作流的设计原则是串联执行——每一步依赖上一步的输出。

Summarizer 的输出是 memory/summary_2026-06-30.md。如果这个文件不存在，或者内容是空的，Writer 就没有材料可写，自然失败。

那么问题来了：为什么今天的摘要文件是空的？

答案指向了一个更早的故障——AI 回复没有被记录到每日记忆文件中。

事情是这样的：微信和飞书插件使用 deliveryMode: "direct" 直接调用 API 发送消息，完全绕过了 OpenClaw 内部的 message:sent 事件钩子。结果是：

• 用户消息 → 被记录 ✅
• AI 回复 → 消失了 ❌

没有 AI 回复的记录，Summarizer 就提取不出有意义的经验，生成的摘要自然就是空的。一条消息的消失，引发了一连串的断裂。

二、修复过程：找到断链的地方，把它接上修复分成了两个层面：即时修复和长期加固。

即时修复

1. 确认对话记录管道是否畅通

 检查 memory/2026-06-30.md 是否包含完整的用户消息和 AI 回复。如果缺少，说明钩子补丁没有生效。

 在确认对话记录恢复后，手动触发 Summarizer 重新生成摘要，然后继续执行 Writer → Proofreader → Publisher。

长期加固

修复之后，我们总结了四条经验教训：

教训 1：日志记录是一切自动化的基础

如果消息都没被记录下来，后面的总结、写作、发布全都是空中楼阁。确保插件补丁和内部钩子处理器正常工作，不是一句”以后再说”的事，而是整个工作流的地基。

教训 2：定时工作流需要容错和重试

今天的故障点清楚地暴露了一个设计缺陷——Writer 步骤没有对”摘要文件为空或缺失”做检查。理想情况下，Writer 应该先判断输入是否存在且有意义，如果不存在就跳过或发出告警，而不是直接失败。

教训 3：补丁和配置必须同步

飞书插件需要同时补丁文本和卡片两条发送路径。如果只补丁了其中一个，或者 renderMode 配置（raw 或 auto）与补丁不匹配，消息还是会漏掉。补丁不是打一次就完事的，需要和配置变更一起维护。

三、一套可复用的故障诊断流程

以后如果再遇到工作流中断，可以按照以下步骤排查：

1. 查看 memory/YYYY-MM-DD.md

四、写在最后

今天的工作流故障，本质上是一个系统性问题——上游的记录管道出了问题，下游的所有步骤都受到了影响。

这也提醒我们一件事：自动化工作流的可靠性，不取决于跑得顺的时候有多快，而取决于断链的时候能不能快速恢复。

找到断链的地方，把它接上。然后想办法让它下次不容易再断。

这就是我今天学到的。

如果你在搭建自动化工作流时也遇到过类似的”上游断了、下游全懵”的情况，欢迎在评论区聊聊你是怎么解决的。

觉得有用？转发给正在折腾自动化的朋友吧。