type
Post
status
Published
date
Mar 31, 2026
slug
summary
复盘一次真实的 AI 内容自动发布故障：表面现象是微博没有按时发出，真正根因却不是 cron、不是内容、也不是平台风控，而是 browser 插件未被加载，导致 publisher-weibo 在运行时失去真实发布能力并静默停在 pending。
tags
OpenClaw
AI Agent
内容自动化
多平台发布
故障分析
运维实战
可靠性工程
自动恢复
category
技术分享
icon
password
js
这是一篇关于内容自动发布链路的真实复盘：表面现象是“今天为什么没有发微博”，真正根因却不是 cron、不是内容、也不是微博风控，而是 browser 能力在运行环境里静默失效。
先说结论
这次故障的直接现象是：publisher-weibo 的定时任务按时触发了，当天也确实存在可发内容，但微博没有自动发出去，内容状态一直停在 pending。
真正的根因是：publisher-weibo 依赖的 browser 能力在运行时不可用，导致真实发布步骤无法执行；同时流程又没有把这类能力缺失可靠地回写成 failed，于是任务看起来像“跑过了”，实际上只是静默停住。
一、故障背景
当天的内容流水线里，有两条已经进入微博分发阶段的内容：
topic_20260331_skill_supply_chain_security
topic_20260331_verification_vs_confirmation
两条内容都已经满足微博分发条件：candidate 状态为 drafted，distribution_targets 包含 weibo，对应 core draft 已存在。也就是说，从内容准备角度看，发布动作本来应该继续往下执行。
二、第一层排查：不是 cron 没触发
先查的是最容易怀疑的部分：定时任务有没有启动，publisher-weibo 有没有真正收到任务。结论很清楚：9:20 的 publisher-weibo daily publish 确实被 cron 正常触发，对应 agent session 也已经创建。
它还正常读取了 AGENTS.md、TASK_TEMPLATE.md、MEMORY.md、schema 文件、两条候选内容以及对应 core draft。
问题不是任务没跑，而是任务跑到中途停住了。
三、第二层排查：不是没有内容可发
接着看候选文件本身。当时两条内容的 weibo 状态都还是 pending，但内容本身明显是完整的，尤其 skill_supply_chain_security 甚至已经有 MoltBook 成功记录。
这说明问题不是“今天没有候选内容”，而是“有内容，但 publisher-weibo 没把真实发布动作走完”。
四、真正的根因：browser tool 当时根本不可用
继续查 publisher-weibo 的会话日志和 OpenClaw 运行日志后，故障点终于显形。最关键的一条日志是：agents.publisher-weibo.tools.allow allowlist contains unknown entries (browser)。
这句话翻译成人话就是：对于当天 9:20 运行的 publisher-weibo 来说，browser 并不是一个可用工具。
而任务模板又要求微博真实发布必须优先使用 browser tool，不能改走 shell，也必须先检查登录态。于是链路进入了一个典型死角：它知道必须走 browser，但 browser 在当时的环境里不可用，它又不能按规则绕路，最后流程只能停住。
五、为什么 browser 会不可用
继续往下查，发现并不是 OpenClaw 删除了 browser 功能，而是 browser 插件没有真正加载进 Gateway。最开始看到的是：@openclaw/browser-plugin 状态是 disabled，openclaw help 里也没有 browser 子命令。
进一步查配置后发现，虽然 browser 相关 entry 已经被打开，但 plugins.allow 里缺少 browser。也就是说，browser 配置表面存在，但它没有进入最终允许加载的插件集合。
真正根因不是 browser 没配置，而是 browser 没被允许加载。
六、修复动作：不是只开开关，而是把插件真正放进白名单
- 确认 browser 相关配置开启：browser.enabled = true，plugins.entries.browser.enabled = true。
- 把 browser 明确加入 plugins.allow。
- 重启 Gateway，让 browser 插件用新配置重新注册。
- 验证恢复结果：browser 插件重新变成 loaded，openclaw browser 命令恢复可见，browser control service 开始正常监听。
七、补发微博：验证修复是否有效
环境修好之后，没有停在“理论上应该可以了”。而是做了两步验证：先人工补发当天漏掉的微博，再手动重跑 publisher-weibo 的 cron，验证它能否先查重、再补记录、再继续自动发布。
最终结果是：一条内容被识别为已发过并补齐记录，另一条内容成功自动发布。两条内容都把 weibo 状态更新为 success。
八、这次故障真正暴露的问题
- 运行环境能力缺失：browser 插件没加载，publisher-weibo 因此失去真实发布能力。
- 失败没有被可靠回写：当 browser tool 不可用时，流程没有明确写回 failed 和 last_error，而是静默留在 pending。
自动化系统最危险的故障，往往不是直接报错，而是任务表面上跑过了，状态却没有告诉你它其实已经失效。
九、后续建议
- 对关键依赖做前置自检。像 browser 这种能力，任务启动前就应该检查是否可用。
- 遇到能力缺失时必须写回 last_error。至少让外部一眼能看出不是“今天没内容”，而是“当前环境缺少发布能力”。
- 保留查重和补记逻辑。真正成熟的自动发布系统，不只是能发，而是能查重、能补记、能容错、能恢复。
一句话总结：这次不是微博没内容可发，而是 publisher-weibo 在 browser 插件失效时静默停在了 pending；修复 browser 插件加载后，链路已经恢复正常，并通过手动重跑任务完成了自动发布验证。