AI Agent 内容自动化运营实战：Cron + 多 Agent 协作，每天零人工干预发布 6 篇

wesley028
5 阅读1分钟

AI Agent 内容自动化运营实战：Cron + 多 Agent 协作，每天零人工干预发布 6 篇

📖 本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。

我在用 OpenClaw 运营一套「全自动内容发布系统」已经差不多一个月了。系统每天自动在 6 个平台发布内容——知乎、掘金、微博、V2EX、CSDN、头条——几乎不需要我手动干预。

这篇文章分享这套系统的工程架构，以及踩坑过程中学到的东西。

背景：为什么需要「内容自动化」

作为一个做 AI Agent 实战的独立创作者，我每天需要：

  • 写公众号文章（主阵地）
  • 把文章改写成各平台适配版本（调性、格式、引流块都不同）
  • 在各平台发布
  • 监控发布状态，处理错误

这些工作如果手动做，每天至少 3-4 小时。但如果用 AI Agent 团队 + Cron 调度，可以把人工干预压缩到接近零。

系统架构总览

CEO Agent（战略指挥）
  ├── wechat-mp-agent（公众号内容生产）
  ├── cross-platform-publisher（多平台分发）
  │     ├── zhihu-publisher（知乎）
  │     ├── juejin-publisher（掘金）
  │     ├── weibo-publisher（微博）
  │     ├── v2ex-publisher（V2EX）
  │     ├── csdn-publisher（CSDN）
  │     └── toutiao-publisher（头条）
  └── daily-traffic-review（复盘 Agent）

每个 Agent 都有独立的 workspace、SOUL.md（人格提示词）、TOOLS.md（工具清单），通过 OpenClaw 的 Cron 系统按时调度。

核心技术：OpenClaw Cron 调度

OpenClaw 的 Cron 系统支持把自然语言任务变成定时触发的 Agent 指令。每个 Agent 的触发时间错开，避免并发冲突：

10:00 CST  → 知乎引流发布
11:00 CST  → 微博引流发布
13:00 CST  → CSDN 引流发布
14:00 CST  → 掘金引流发布
15:00 CST  → V2EX 引流发布
16:00 CST  → 头条引流发布
22:00 CST  → CEO 每日复盘

Cron Job 的 Payload 是一段结构化的任务描述，包含：

  1. 今日可用素材库（公众号已发文章链接）
  2. 引流块模板
  3. 发布前检查清单（避免重复发文、检查 Cookie 状态）
  4. 发布后日志写入路径

关键工程实践

1. 防止重复发布：daily-traffic-log 检查

每个发布 Agent 启动时，第一步是读 daily-traffic-log.md，检查今天这个平台是否已经发过。这个文件是所有 Agent 共享的「发布账本」：

| 2026-03-27 | 掘金 | 实战复盘：6人Agent Team险些全军覆没 | ✅ 成功 | ... |

Agent 读取后，会跳过已发过的文章，选新的角度或等明天。没有这个机制，多 Agent 并发很容易重复发同一篇文章。

2. 平台差异化适配：SOUL.md 人格隔离

每个平台的内容风格差异很大：

平台风格核心差异
掘金技术深度Markdown + 代码块 + 技术标签
微博轻量互动140字内 + 话题标签 + 情绪共鸣
V2EX极客社区讨论帖形式，拒绝硬广，低调引流
头条大众阅读故事感强，有结论，接地气
知乎专业观点回答问题形式，有数据有案例
CSDN技术博客SEO 标题 + 代码示例 + 教程结构

每个发布 Agent 的 SOUL.md 里都写明了对应平台的调性要求。这样同一批素材，各 Agent 改写出来的文章就有明显差异，不会让读者觉得像机器批量复制。

3. Cookie 状态管理

各平台的 Cookie 有效期不同，是最容易踩坑的地方。我的处理方式：

  1. 发布前检测：Agent 先用 Cookie 调一个轻量 API（如获取用户信息），确认 Cookie 有效
  2. 失败时降级：发布失败时，生成本地草稿 + 记录 ⚠️ Cookie 过期 到日志
  3. 定期提醒：CEO Agent 每周 Review 日志，发现连续失败时通知我手动刷新 Cookie

遇到过最狗血的情况：某平台 Cookie 过期，Agent 把文章内容写完了，发布时才报错，草稿只能本地存着等我手动操作。后来改成「先验证 Cookie，再生成内容」，省了很多无效工作量。

4. 掘金 API 发布流程

掘金提供了相对完善的 RESTful API，但坑不少：

Step 1：上传图片（如有）

POST https://api.juejin.cn/imagex/set_upload_auth_token

Step 2：创建草稿

POST https://api.juejin.cn/content_api/v1/article_draft/create
Body: {
  "title": "文章标题",
  "brief_content": "摘要（前100字）",
  "mark_content": "Markdown正文",
  "category_id": "6809637767543259144",  // AI/机器学习
  "tag_ids": ["6809640398105870343"],     // AI
  "cover_image": ""  // 不传图片
}

Step 3：发布草稿

POST https://api.juejin.cn/content_api/v1/article/publish
Body: { "draft_id": "xxx", "sync_to_org": false }

注意：category_id 和 tag_ids 需要提前查询，不能随意填。AI/机器学习分类的 category_id 是 6809637767543259144。

鉴权方式：把 sessionid Cookie 放在 Header 里：

Cookie: sessionid=xxxxx; sessionid_ss=xxxxx

踩过的最大坑：「完成」的定义

刚开始搭这套系统时，最大的问题不是技术，而是 Agent 报告「发布成功」但实际上没有发布。

原因有几种：

  1. API 返回了 200，但业务层面失败了（文章进审核队列/被拦截）
  2. Agent 生成了草稿，但没有调发布接口，只报告「草稿已创建」
  3. Cookie 过期时，部分 API 不返回 401，而是返回空数据

现在的处理方式：Agent 必须验证「读者可见」才算完成。具体做法：

  • 发布后等 2-3 秒，再调「获取文章详情」接口
  • 检查文章状态字段（审核通过/发布中/被拒）
  • 日志中区分 ✅ 成功、⏳ 审核中、⚠️ 发布失败

这个小改动让系统的「假完成」问题从 30% 降到接近 0。

实际效果（运行一个月数据）

  • 平均每天：5-6 个平台发布，总计 5-6 篇文章
  • 人工干预频率：每 3-4 天刷新一次 Cookie（约 5 分钟）
  • 内容质量：偶尔需要手动 Review，约 10% 的文章有明显问题
  • 引流效果：公众号「Wesley AI 日记」稳定增长，主要来源是掘金和头条

下一步计划

  1. 自动 Cookie 刷新：接入浏览器自动化，定期续期 Cookie
  2. 内容质量检测：加一个 content-reviewer Agent，发布前自动打分
  3. 效果追踪：每周自动统计各平台流量，调整发布策略

总结

Cron + 多 Agent 协作的核心价值不是「省时间」（虽然确实省了），而是让内容运营变得可持续。以前靠手动发布，一旦我忙起来就断更；现在系统自动跑，我只需要保证公众号主阵地的内容质量。

如果你也在做内容运营，想了解更多这套系统的细节，欢迎关注公众号「Wesley AI 日记」——所有踩坑记录都在那里。

📖 本文首发于微信公众号「Wesley AI 日记」 📚 AI Agent 实战系列（微信搜索「Wesley AI 日记」关注）：

👆 微信搜索「Wesley AI 日记」关注，不错过每一篇更新。

avatar
文章
阅读
粉丝