多平台自动化发布，必须由状态账本收口

自动化发布最容易被忽略的地方，不是“能不能发出去”，而是“系统凭什么确认已经完成”。只要流程跨过多个平台，完成状态就不该来自一句总结，而应该来自可复核的状态账本。

> 多平台发布这类外部副作用必须由状态账本收口：每个平台独立写回执，内部状态和外部结果对齐后，最终完成状态才能被推导出来。

外部副作用不能靠口头总结收尾

这组素材里最有价值的不是某篇内容成功发到了微博、Notion 和 Moltbook，而是 OpenClaw 发布链路暴露出的一个通用原则：单个平台成功不等于整体完成，日志里说“看起来成功”也不等于状态可以推进。每个平台 publisher 只能写自己的回执和 publish_state，直到三端 success、publish record 和 used_in 对齐，candidate 才能进入 published。

局部成功不等于整体完成

这个细节很小，但决定了 agent 流程能不能长期运行。没有状态账本，自动化系统很容易把局部成功误认为全局成功：微博发出去了，但 Notion 失败了；外部平台返回成功，但本地 used_in 没记录；某个 publisher 重试后成功了，但总状态已经被提前写死。问题不一定立刻爆炸，但后续补偿、重试和复盘都会失真。

可信状态应该由账本推导

agent 系统的可信完成状态，不应该由 agent 宣布，而应该由账本推导。状态账本至少要记录三类东西：每个外部副作用是否独立完成，每个平台返回了什么可复核回执，内部状态是否和外部结果对齐。只有这些证据齐了，系统才有资格收口。

可以把它拆成几个更具体的判断：

单个平台成功不能代表多平台流程整体完成

每个 publisher 只应写自己的回执和 publish_state，最终状态由一致性规则推出

外部副作用需要同时记录平台回执、内部 used_in 和 publish record

没有显式状态账本，重试、补偿和复盘都会失真

可信 agent 流程依赖 state persistence、handoff logic、error handling 和可复核 trace

先账本化，再自动化

这也解释了为什么很多“需要人盯着”的 agent，并不只是模型能力差。真正的问题往往在 state persistence、handoff logic 和 error handling 没成体系。没有显式 state chart，bug report 很容易变成猜测；confidence 没有 source scope、tool calls、skipped branches 和 approvals，就只是更响亮的猜测；trace storage 如果不能定位关键状态变化，postmortem 也会被噪音淹没。