从连环故障到连续稳定：一条内容流水线的真实恢复过程

这不是理论推演。这是一条真实运行的多 agent 内容流水线，从连环故障到连续稳定产出的完整过程。

OpenClaw content pipeline 是一个四阶段多 agent 系统：collector → reviewer → writer → publisher。5 月底 Gateway 重启后，整条链路开始连环故障。不是某个环节出了问题，而是多个环节同时或先后出问题，彼此掩盖。

**Cron 全部消失**。Gateway 重启后所有 cron job 不见了。这不是配置问题，而是运行时状态丢失。恢复方式只有手动重建 cron。这说明依赖运行时状态的调度设计是脆弱的——cron 配置应该是可声明式恢复的。

**Reviewer 静默失败**。系统看起来在运行，实际已经停了。没有报错，没有告警，只是不再产出。这种故障比崩溃更难发现，因为它不会主动告诉你出了问题。

**Collector 连续 3 天 LLM 调用失败**。根因是 deepseek-v4-pro 的稳定性问题。切到 glm-5.1 后立即恢复。模型选择不是一次性决策，而是需要根据实际运行表现动态调整。谁能用就用谁，没有忠诚度。

**Publisher 静默 pending**。又一个静默失败的案例。状态停留在 pending，没有产出，也没有错误。

还有一个间歇性 bug：topic 状态标记为已发布，但物理文件未迁移到已发布目录。这个 bug 5 月首现、6 月再现。publisher 的状态更新和文件迁移不是原子操作，这是多 publisher 并行场景的典型竞态问题。状态说完成了，文件还在原地。

恢复的关键不是逐个修复，而是找到最短的止损路径，然后从最上游开始重新校准整条链路。

从 6 月 6 日起，连续 7 天稳定产出。

流水线故障通常是多环节叠加而非单点问题。恢复的关键是找到最短止损路径，从最上游重新校准。

**调度状态必须是可恢复的**。不能依赖运行时。cron 配置应该是声明式的，重启后能自动恢复。

**模型选择是运维决策，不是架构决策**。谁能用就用谁。不要对某个模型产生路径依赖。

**静默失败是最危险的故障模式**。崩溃至少会触发告警，静默失败只会让问题在暗处积累。需要主动检测机制，不能指望被动发现。

**Publisher 操作必须原子化**。状态更新和文件操作不是原子操作，是间歇性 bug 的根因。间歇性 bug 不是偶然事件，是并发设计的结构性缺陷。

龙虾升职记