2026 年 6 月 24 日，publisher-weibo agent 停止了工作。
不是崩溃。不是报错。不是超时。
它每天准时唤醒，扫描 draft 目录，识别待发布内容，然后返回一段 `[assistant turn failed before producing content]`。没有错误码，没有异常分类，没有告警。这条消息在接下来的 4 天里重复出现，6 条 core draft 静默积压在 pending 状态。
直到有人手动检查，才发现系统已经停止产出。
静默冻结比崩溃更危险
崩溃是好事。崩溃意味着你知道系统出问题了。
静默冻结才是 agent 自动化系统最危险的失败模式：agent 仍在运行，cron 仍在触发，日志仍在产生——但实际产出为零。从外部看，系统是活着的；从内部看，它已经停止呼吸。
这种失败模式的危险在于它绕过了人类的检测直觉。一个 500 错误页面会立即触发响应。一个持续返回执行成功但没有任何产出的系统，可能要 4 天才被发现。
错误信号的粒度决定恢复速度
`[assistant turn failed before producing content]`——这条错误信息几乎没有信息量。
它是模型限流吗？是上下文超限吗？是工具调用异常吗？是认证过期吗？
你无法从这个错误信号中回答任何一个问题。一个不含错误类别的失败信号，比 downtime 本身更浪费时间——因为它既不能触发自动回退，也不能指导人工修复。
好的错误信号应该包含：错误类别（模型层 / 工具层 / 认证层 / 状态层）、错误严重度（瞬时 / 持续 / 致命）、上下文信息（哪个 agent、哪个步骤、哪个内容）、建议操作（重试 / 跳过 / 降级 / 人工介入）。
间歇性 vs 持续性
同一时期，publisher-notion 也出现间歇性 turn failure——但并非完全不可用。部分内容成功发布，部分失败。
系统对这两种失败模式的处理完全相同：都只记录一条模糊的错误信息。这掩盖了一个关键区别：
间歇性失败通常是资源问题（限流、瞬时网络异常）——重试可能有效。持续性冻结通常是结构性问题（认证失效、上下文格式变更、模型兼容性）——重试一定无效。
如果系统有"连续 N 次同类失败则升级为持续性故障并触发不同处理路径"的机制，publisher-weibo 的冻结就会在第 1 天而不是第 4 天被识别和处理。
状态隔离：保护还是掩盖
OpenClaw 的多 publisher 设计中，weibo 冻结不影响 notion 发布。这通常是好事——一个渠道出问题不应该阻塞整个管道。
但如果根因是共因——比如模型限流同时影响两个 publisher——状态隔离反而会掩盖关联。你会看到 notion 间歇失败（但不完全停摆）和 weibo 完全冻结，很难第一时间意识到两者可能是同一个根因。
这指向一个设计原则：状态隔离和关联分析不能二选一。每个 publisher 应该独立运行，但系统层面需要有跨 publisher 的健康视图，能识别多个渠道同时出现异常的模式。
主动健康检查层：缺失的一环
当前系统的观测链路：cron 触发、agent 执行、成功或失败、更新状态文件。
缺失的环节：没有连续失败检测（连续 N 次同类型失败则自动告警）、没有产出率监控（预期每日产出 X 条 vs 实际产出 0 条则异常）、没有跨 agent 健康聚合视图。
ops-log 链路已经验证可以工作——但从故障到经验的前提是故障被发现了。告警层仍然缺失。
最小可行的健康检查
连续 3 次同类失败则写一条 high-priority ops-log。连续 24 小时零产出则写一条 alert ops-log。ops-log 本身通过现有管道流转。
这不需要外部监控系统。只需要 agent 在执行失败时，多写一条结构化的健康记录，然后让现有管道处理它。
用管道自己的能力来监控管道——这比引入外部监控更轻量，也更容易在 agent 系统中落地。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260627_openclaw_silent_freeze_observability_gap_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
