AI Agent 自动化运营管线实战：从选题到发布的编排、状态机与验证协议 | RiseClaw玄策

Agent 生态正从「能对话」走向「能干活」。OpenClaw 爆火之后，不少开发者开始琢磨同一件事：把内容营销自动化交给 agent——选题、写稿、审核、发布、回流数据。跑起来的不少，跑稳的不多。这篇以开源项目 RiseClaw玄策 的运营管线为实例，只讲工程实现：任务编排为什么需要状态机、人机协作门怎么做成机器可校验的契约、agent 的产出怎么验证。代码和踩坑都真实，不含概念科普。

一、先承认问题：一坨脚本撑不住自动化运营

内容运营是多步骤长流程：选题 → 写稿 → SEO/GEO → 机器审核 → 人工审核 → 用户确认 → 定时发布 → 结果核验 → 数据回流。三个特征决定脚本串联必然失控：

1. 异步等待是常态。人工审核可能等半天，登录过期要等扫码，平台审核结果要等几个小时。脚本只能 sleep 轮询，挂久了不是超时就是资源泄漏。
2. 中断是常态。浏览器崩、进程重启、平台改版，任何一环断掉，从头重跑会重复发帖——对内容平台这是事故。
3. 多方参与。人拍板、agent 干活、平台是唯一事实源。口头约定「发前确认」，在自动化里等于没约定。

结论：长流程自动化需要的是状态机 + 契约 + 验证协议，不是更长的脚本。下面按这三块拆解。

二、设计一：任务状态机与单一事实源

每篇内容一个 task_id，一份 task.json 作为单一事实源，状态机七个状态，流转全部留痕：

assigned → drafting → reviewing → user_confirming
        → scheduled → publishing → published
                                  ↘ blocked（可恢复）

关键设计有三点：

状态流转写库，不写日志。日志会轮转，状态不会。每次流转更新 task.json 的 status 与时间戳，任何人接手读到的都是当前事实：

{
  "task_id": "20260905-demo-1",
  "status": "user_confirming",
  "revision": 2,
  "audit": { "rounds": [{ "round": 2, "result": "pass" }] }
}

断点续跑靠步骤级 checkpoint。流程引擎为每个步骤记录 done / running / blocked / skipped。中断后 resume 自动跳过 done 步骤，只重跑断点。消灭「重跑即重复发帖」事故源。

blocked 是可恢复态。登录过期、审核被拒、平台异常，全部进入 blocked 并落一条待办（带恢复提示），由人或下一轮巡检触发 resume。挂起等待是被禁止的——等待必须变成一条可被拾取的记录。

三、设计二：人机协作门是契约，不是聊天

三个协作点全部契约化：

审核轮。审核是 task.json 里的 rounds 数组：每轮结论（pass / reject）、驳回理由、改稿要求结构化落盘。agent 改稿读的是上一轮驳回结构，不是聊天记录。

发布许可门。「可以发了」必须是一个机器可校验的字段。只有一条路径能写入 publish_cron_name（用户确认 + 排期后由许可链写入），发布执行器逐字校验：

def gate_publish(task, cron_name: str) -> bool:
    # 许可字段必须由确认��写入，且与本次触发器逐字一致
    return task.get("publish_cron_name") == cron_name

未过许可门就发布，视作红线违规进审计日志——「谁批准的」从口头问答变成可追溯字段。

待办信箱。一切需要人介入的事件（扫码登录、审核待批、平台拒绝）落待办库并通知，agent 不轮询不挂起。用户处理完待办，验证通过才允许关闭——防止「点了完成但实际没登录」的假闭环。

四、设计三：结果验证协议——平台事实说了算

agent 说「发布成功」不算数，平台事实才算数。这条协议来自一个真实 bug：发布脚本模板拼接文章 URL，缺用户名段，返回链接 404，agent 却自认发布成功。由此固化三条规则：

规则一：真实捕获优先，拼接只是降级路径。URL 从页面真实跳转捕获，捕获不到才降级拼接，且必须打「未验证」标记：

import re

SCHEME = "https"
CANONICAL_RE = rf"^{SCHEME}://blog\.csdn\.net/[^/]+/article/details/\d+$"

def canonical_url(captured, article_id, username):
    if captured and re.match(CANONICAL_RE, captured):
        return captured, True   # 真实捕获，已验证
    return (f"{SCHEME}://blog.csdn.net/{username}"
            f"/article/details/{article_id}", False)  # 降级拼接，未验证

规则二：双源交叉核验。带登录态访问自己的文章会被重定向到编辑器（作者行为），公开可达性必须用无登录态 HTTP 客户端核验；平台侧状态再到管理页读状态码：已发布 / 审核中 / 审核未通过 / 仅自己可见，四态四处置。

规则三：错误分类决定重试策略。暂时性错误（网络超时、CDP 不可达）可以重试；永久性错误（平台审核拒绝）重试只会重复提交，必须直接 blocked 转人工。当晚事故里，审核拒绝被当可重试错误重发三次——重试无逐次留痕，排查只能靠时间戳倒推。

五、一条真实发布轨迹

一次真实任务的时间线（管线留痕）：

20:25  任务下发，热点匹配 + 同构检测通过
20:36  初稿完成，机器门禁（字数/密度）通过
20:51  人工审核 round 2 通过 → 待用户确认
21:04  用户确认 + 排期，许可门写入 → 发布
21:04  发布成功，article_id 捕获，URL 为拼接值（bug 点）
21:10  无登录态核验：文章公开可达，但回写 URL 404 → blocked
21:22  URL 生成修复 + 回归，待办验证后 resolve
次日22:00  数据回流：指标入库，闭环

从下发到数据回流约 26 小时，历经人工审核、用户确认、一次 blocked 恢复，无人盯守。

六、三条工程教训

1. URL 与外部标识永远真实捕获。模板拼接的 URL 看起来对，验证时才炸；拼接只配做降级路径。
2. 等待落库，禁止挂起。所有需要人介入的点都变成待办记录，流程正常退出。挂起等待的进程既耗资源又不可恢复。
3. 机器门禁读配置，不写死规则。外链政策、关键词表这类会变的东西，一旦硬编码进校验脚本，政策一改就出现「指令与门禁打架」，最后只能在运行时打补丁——那是 agent营销团队类自动化管线失控的开始。

做到这三条，agent 自动化运营才从「演示能跑」变成「每天能跑」。想在真实运营管线里看这些设计的完整实现（状态机/许可门/验证协议/多平台发布），可以读读 RiseClaw玄策 的源码，欢迎交流工程细节。