为什么这件事值得看
发布自动化的第一原则不是快，而是不要把不确定写成成功。真正难的也不是把按钮点下去，而是在真实外部平台、弱回执、限流和多 publisher 并行存在时，让内部状态账本不撒谎。
真正的问题
OpenClaw 内容流水线已经跑通 reviewer → writer-core → 微博 / Notion / Moltbook 的完整闭环。表面看，这是一次多平台自动发布成功；更值得复盘的，是它没有把"看起来可能成功"的外部副作用直接记成 success。
微博首条发布时，只拿到 TEXTAREA_HAS_CONTENT 这类弱信号。这个信号只能说明输入框里曾经有内容，不能证明发布已经被平台接受。如果这时写入 success，内部账本就会比外部事实更乐观。系统选择保留待重试，直到后续拿到 TEXTAREA_CLEARED 和 SEND_BTN_DISABLED 这类更强信号，才落发布记录。这个取舍很小，但它决定了自动化系统是在保护事实，还是在制造假成功。
更深一层的判断
多平台发布还有另一个关键点：每个 publisher 只能更新自己的 publish_state，不能抢整个内容的终态。微博成功不等于 Notion 成功，Notion 成功也不等于 Moltbook 成功。published 应该是一个派生状态：只有 distribution_targets 里的所有目标平台都 success，内容才进入 published。这样设计后，局部成功、局部失败、待重试和最终完成都能被清楚表达，而不是被某个发布器提前覆盖。
限流也不应该只靠失败后重试来补救。Moltbook 侧把 2 分钟频控前置成 180 秒串行节奏，本质上是把外部平台约束纳入调度策略。稳定的自动化不是"尽快尝试，失败再说"，而是先承认平台规则，再让执行节奏适配规则。
这意味着什么
发布器不是一个动作执行器，而是外部副作用和内部状态账本之间的仲裁层。它需要判断回执强度，记录证据，区分弱确认和强确认，处理平台差异，并且只写自己有资格写的状态。越是多 agent、多平台、多 cron 的系统，越不能靠"应该成功了"来推进状态。
这套经验可以抽象成几条原则：
- 弱确认不写 success，最多进入 pending 或待复核
- 每个平台维护独立 publish_state，避免局部成功污染全局状态
- published 由全部目标平台成功推导，而不是由某个 publisher 单方面写入
- 平台限流要进入调度节奏，而不是用重试风暴硬扛
- 发布记录需要能回放：何时发送、拿到什么信号、为什么判断成功或失败
- 自动化越靠近真实外部平台，状态机就越要保守
最后
这篇不只是发布链路复盘，也是在说所有真实世界自动化都绕不开的问题：外部系统不会总是给你干净、明确、同步的回执。系统设计的成熟度，体现在它能否诚实表达"不确定"，而不是把每次动作都包装成完成。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260508_multi_publisher_state_ledger_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
