跑了 182 篇文章后，我把自媒体 Agent 拆成了 5 层

182 篇文章、1557 条发布记录、7 个平台，每天早上 4 点自动开跑。

这套自媒体 Agent 已经连续跑了一个多月，踩过的坑足够写一本小册子。

先说结论：让它能无人值守的，不是某个万能提示词，而是把流程拆成 5 层，再用代码把每层的出口焊死。

这篇讲清两件事：为什么这样设计，以及你 clone 之后怎么把它用起来。

一、让 Agent 自己看着办，一定会翻车

最早我也是让 Agent 打开网页、点发布、看到“成功”就记一笔。

三天后对账，问题全出来了。

知乎提示发布成功，实际只保存了草稿。头条点了按钮，管理列表里根本没有这篇。51CTO 前台被 WAF 挡住，Agent 把“页面打不开”当成了发布失败。

这些不是模型笨。是网页返回的信号本来就有歧义。

模型擅长写作、归纳和语义判断，不擅长在模糊反馈里做确定性判断。

所以我定了一条规矩：能用代码判断的，一律不交给模型。

这条规矩后来变成了整套系统的地基。

二、五层结构：把确定性收进代码

拆完之后，整套系统只有五层。每层只做一件事，层与层之间用文件或退出码说话。

入口层解决“谁都能发”的问题。所有平台、所有文章都走同一个脚本，先干跑再真发。

状态机解决“顺序”的问题。登录、标题、正文、发布、验收，每一步都有前置条件。跳过登录去发布，脚本会直接拦下。

适配器解决“平台差异”的问题。CSDN 的编辑器、华为云的 TinyMCE、头条的标题计数器，全部封在各自文件里。平台改版时，只动一个适配器。

事实源解决“状态打架”的问题。一篇文章在哪个平台是什么状态，只写进一个 JSON。定时任务的时间、脚本、启用状态，只写进一个 JSON。

观测层解决“到底成没成”的问题。每轮留日志，每篇留 URL，每天出看板。失败不是一句“抱歉”，而是一个能回填的状态。

这五层里，模型只在两个位置出现：选题写作，以及排查失败原因。其余全部是确定性代码。

三、五条硬门禁，把“看起来成功”挡在门外

光有分层还不够。平台会给你假信号，所以每条出口都要有门禁。

1. 图片先上公网，再发布。 本地截图先传到对象存储并改写成公网 URL，平台抓不到图时不会留下裂图。
2. 发布后必须视觉验收。 打开前台文章，核对标题、正文和图片。只有验收通过，状态才能写 published。
3. 终态只允许三种。 published 是有 URL 且验收通过，verify_needed 是有 URL 但没验收，submitted 是无 URL 审核中。绝不把“点了按钮”记成发布成功。
4. 质量门禁先拦一道。 标题按头条口径不超过 29 字，受众可见度必须大于 12，整体吸引力不足 90 分就重写。
5. 合规检查不能省。 每个平台适配器必须实现同一组步骤和检查项，缺一个就不允许上线。

第三条是最值钱的一条。

它把“成功”从一个形容词变成了三个可验证的状态。看板上的数字因此可信，补发和对账也才有了依据。

发布入口长这样：

python scripts\publish_runner.py --slug <slug> --platform csdn --publish --skip-quality `
  --gitcode-url "https://gitcode.com/OPCTeam/demo_park/tree/main/<slug>"

默认是干跑。不加 --publish，它只告诉你门禁过没过，不会碰你的账号。

四、定时任务：把“每天跑”变成一条命令

能手动跑，不等于能长期跑。

我把所有定时任务写进一个 JSON，再用一个幂等脚本装到 Windows 计划任务里。

powershell -NoProfile -ExecutionPolicy Bypass -File scripts\install_scheduled_tasks.ps1
powershell -NoProfile -ExecutionPolicy Bypass -File scripts\install_scheduled_tasks.ps1 -Status

第一条负责装和对齐，第二条只对照不改。已经一致的任务会跳过，不会重置上次运行时间。

时间不是拍脑袋定的。

按实际发布时间分组，白天 9 点到 17 点发的文章，首日阅读中位数是 145；深夜 21 点到 4 点发的只有 81。

但发文轮的前置步骤要跑两个小时。7 点起跑，首篇 10 点才上线；5 点起跑，末篇仍压不进 10 点。

最后把起点挪到 4 点，3 篇能在 9 点半前发完。

统计放 23 点，是为了避开 4 点到 9 点半的发文窗口，两者都要用浏览器会话。

保活放 9 点、15 点、20 点，是因为登录态大约 24 小时过期，三次触碰能把最大间隔压到 16 小时以内。

知乎补发放 17 点 10 分，是因为账号曾被“可能包含 AI 创作内容”限制 7 天。解封后每天只补 1 篇，避免再次触发同一风控。

还有两个细节值得抄。

发文轮和统计任务用锁互斥。发文期间 9 点的保活会主动跳过，这是设计行为，不是故障。

缺口自愈窗口是“昨天 0 点到现在”，与触发时间无关。改时间不用同步改补跑逻辑。

五、踩过的坑，比架构更值得看

下面这些坑，每一个都真实发生过。它们的共同点是：页面说成功了，实际没有。

知乎那条最典型。

脚本原来把 /p/<id>/edit 当成成功页，于是每次都记录“已发布”，实际只是存了草稿。后来改成读草稿接口的状态，才把真假分开。

头条那条更隐蔽。按钮点了，接口也可能返回成功，但服务端没有生成条目。唯一可信的证据是管理列表里多了一篇。

这也是为什么我一直说：验收要看结果页，不要看操作页。

六、结果、代价，以及你怎么开始

先看结果。

一个多月里，这套流水线产出 182 篇文章，写下 1606 条平台记录，其中 1557 条通过验收。七个平台的发布、阅读统计、看板更新，基本不需要人盯。

再说代价，免得你以为是躺赚。

首次配置有 5 项人工前置：码道 Web 登录、工作区身份、视觉模型、对象存储凭据、平台扫码。它们必须由账号主人完成。

平台会改版，适配器要跟着维护。知乎、头条这类平台还有 AI 内容风控，账号可能被临时限制。

所以它不是“全自动印钞机”，而是一套把重复劳动压到接近零的工程系统。

如果你想把同样的结构用到自己的号上，按下面五步走：

git clone https://atomgit.com/OPCTeam/self-media-agent.git
cd self-media-agent
$env:PYTHONPATH = "$pwd\lib;$pwd"; $env:SELF_MEDIA_HOME = $pwd
python -X utf8 scripts\check_env.py

check_env.py 会把机器依赖和“需要主人协助的人工前置”分开列出来。退出码变成 0，就说明环境就绪。

接下来设置自己的身份，再跑一次带登录探测的自检：

$env:SELF_MEDIA_WORKSPACE = "workspaces/<your-name>"
$env:SELF_MEDIA_AUTHOR = "<your-name>"
python -X utf8 scripts\check_env.py --with-login

想复现“码道 WebUI 生成 + 截图”的创作模式，浏览器打开码道 Web 版即可，不用装软件：

https://devcloud.cn-north-4.huaweicloud.com/chat?source=dmzntgwlb&sourcead=dmzntgwlb1&invitecode=INV-IXhxk5bwWx_qKSP1FcgSuiOEf6ruDXtjvLFiCH9nMs5dZGLapaSSylwt-cKRj5LoT3MlxikWxy8VhqplfvtQjefQOq31Tbp3R3wYP3K535Cn4XTaUzqqExKPYTWvvw4LijV14IS1torXdTGp7oyXb6SR5VxgYTg50jM

仓库在这里，文章、脚本、计划任务定义都在里面：

https://atomgit.com/OPCTeam/self-media-agent

已经发布的案例和可运行的小应用，收在这个公开仓：

https://gitcode.com/OPCTeam/demo_park

最后回到开头那句话。

把不确定的创作交给模型，把确定的流程交给代码。你省下来的不是写作时间，而是每天对账、补发、怀疑“到底发没发”的那几个小时。