OpenClaw 运维复盘：5 个真实故障，没有一个是因为模型不行

跑了一段时间 OpenClaw 之后，我意识到一件事：大多数 agent 系统的文档只教你怎么写 prompt，不教你怎么运维。而真正让你睡不着觉的，从来不是 prompt 的问题。

以下是 5 个来自生产环境的真实故障。

生成了但没送到

stock_assistant 的 cron 每天准时跑完，报告也生成了，但飞书上什么都没收到。排查了一圈才发现：outbound 没配置。

这是一个很容易忽略的盲区。Cron 成功运行只意味着"生成"这一步完成了，投递是另一条独立的链路，有自己独立的故障模式。如果你只监控 cron 状态，你会以为一切正常。

投递链路是独立故障点，必须单独监控。

写盘风暴

Gateway 启动后 2 分钟内连续写盘 10 次。每次状态变更都直接持久化，没有任何合并或延迟写入策略。

配置迁移本身是正常的。但没有节流的写盘意味着两件事：SSD 寿命在加速消耗，而且在高并发下可能出现写入不一致。不是每次状态变更都值得一次 fsync。

写盘需要合并和延迟策略，这是一个容易被忽略的基础设施问题。

删 agent 不是删目录

清理 deal-agent 时发现，一个 agent 在系统中的依赖涉及四层：cron 定时任务、workspace 目录、credentials 凭证、routing 路由。删目录只清理了其中一层。

剩下的三层怎么办？幽灵 cron 会继续触发，过期凭证可能引发认证失败，残留路由会把消息发给不存在的 agent。Agent 的生命周期管理必须按依赖顺序从外到内清理——cron → routing → credentials → workspace。漏掉任何一层，系统都会在某个你没想到的地方翻车。