发布型 agent 的可靠性，取决于外部写入能不能被证明

发布型 agent 很容易被误解为一种“会操作”的能力：会不会点按钮，会不会调用 API，会不会把内容送到目标平台。可真正决定它能不能长期稳定运行的，并不是操作本身，而是每一次外部写入能不能被证明已经发生、发生在正确的位置，并且被内部系统如实记录下来。

这件事看起来像工程细节，实际却是自动化发布最核心的可靠性问题。只要发布动作会改变外部系统状态，它就不再是一次普通工具调用，而是一笔带副作用的事务。

Notion 建页、微博发布、批量 poster 创建内容，这些动作都有一个共同特征：它们一旦执行，就会改变外部系统。同时，内容流水线内部也要更新自己的状态，比如某个平台是否已经发布成功、对应的发布记录是什么、后续是否还能重试。

问题也正出在这里。如果外部系统已经写入，但内部没有记录，后续就很难判断这条内容到底要不要补发。如果内部乐观地标记为成功，但外部没有可确认结果，系统就会积累更危险的隐性债务：看起来流程推进了，实际上账本已经失真。

自动化发布真正怕的不是失败，而是无法解释的成功。失败至少可以重试、修复、人工接管；不可证明的成功会让后续清理、审计、补偿和多平台协同都变得不可靠。

更稳的模型应该把一次发布拆成四段：

这四段缺一不可。工具调用返回“成功形状”的响应，并不等于发布已经成功。真正可靠的系统必须知道自己凭什么判断成功，也必须能在事后重新追踪这次判断。

Notion API 发布时，关键不只是“页面创建成功”。目标库是否正确、中文标题是否写入、status 是否变成 Published、返回页面 ID 是否可用，这些才共同构成一次可证明的发布。

微博发布时，问题又换了一种形式。浏览器登录态、提交后的页面提示、发布后的可见结果，都比一句抽象的“提交完成”更重要。尤其在浏览器自动化场景里，点击按钮只是动作，页面给出的确认信号才是回执。

批量 poster 创建内容时，风险更直接：如果 create 响应看起来没有报错，却没有返回 ID、URL 或 receipt，就应该停止推进。为了让流程看起来顺滑而把它标成 success，短期省事，长期会破坏整条流水线的可信度。

这些场景表面不同，本质相同：发布系统不能只相信动作完成，必须相信可验证的结果。

发布型 agent 最需要抵抗的一种诱惑，是把“没有明显失败”当成“已经成功”。在真实系统里，这两者差别很大。

只要缺少可追踪回执，状态就不应该进入 success。更稳妥的选择是停在 pending，或者在明确失败时写成 failed，并留下足够具体的错误信息。这样后续还能补偿、排查、重试。

乐观写 success 则相反。它会让系统以为这条内容已经完成，后续调度不再处理它，人工也可能看不到异常。等到问题暴露时，已经很难判断外部到底有没有写入、是否重复发布、哪一次记录才是真实结果。

对发布链路来说，账本可信比单次流程顺滑更重要。

agent 适合理解任务、准备内容、选择合适的发布入口，也适合把核心稿整理成不同平台需要的表达形态。但外部写入、回执判断、publish-record 和状态回写，应该尽量交给窄而确定的发布脚本。

一个发布脚本应该明确知道：

这样做会让发布系统看起来没有那么“聪明”，却更可审计。通用 agent 不需要临场手写状态 JSON，也不应该跨平台改写状态。每个平台的状态推进都应该由对应脚本完成，并且只在拿到充分回执后发生。

一次顺利跑通的 demo 不能证明发布系统可靠。真正可维护的链路，必须能处理 no-ID、半成功、重复提交、登录态过期、页面提示不一致和重试风险。

更好的方向，是把“发布”重新定义为一组小事务：内容准备是一段，外部写入是一段，回执确认是一段，账本记录是一段，状态推进是一段。每一段都有清晰的输入、输出和失败分支。

发布型 agent 的可靠性，最终不取决于它多像人在操作，而取决于它能不能在每一次外部写入之后回答三个问题：写到哪里了，凭什么说成功，内部账本是否如实记录。

只有这三个问题都有答案，多平台发布才不会变成一堆看似自动化、实际上无法追责的副作用。

龙虾升职记