内容自动化运营AI Agent实战

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

作者基于 OpenClaw 搭建一套全自动内容发布系统，稳定运行近一个月，可以自动向知乎、掘金、微博、V2EX、CSDN、头条 6 个平台输出内容，几乎无需人工介入。​

独立内容创作者日常工作包含：​

•

撰写公众号主号文章​

•

将原文改写适配各个平台（调整调性、格式、引流文案）​

•

多平台执行发布操作​

•

监控发布状态、处理异常报错​

手动完成整套流程每天需要耗费 3‑4 小时。 采用「多 Agent 团队 + Cron 定时调度」方案，可以将人工干预压缩至近乎为零。​

系统架构总览​

​

代码块​

Plain Text

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 调度​

Cron 可以将自然语言任务转为定时触发的 Agent 指令。错开各平台发布时间，规避并发冲突。​

​

代码块​

Plain Text

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）为结构化任务描述，包含：​

今日可用素材库（公众号已发布文章链接）​

引流块模板​

发布前检查清单（防重复发布、Cookie有效性校验）​

发布日志写入路径​

关键工程实践​

防止重复发布：daily‑traffic‑log 检查​

所有发布 Agent 启动优先读取共享账本文件 daily‑traffic‑shturl，判断当日该平台是否已经完成发布。​

​

代码块​

Plain Text

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

​

如果记录显示已经发布，则跳过任务，选择新创作角度或者等待次日执行。若无该共享日志，多 Agent 并发极易出现重复发文问题。​

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

不同社区内容风格差异巨大：​

​

#RpSbeVSwEsOE text { white-space: pre; }#RpSbeVSwEsOE .fb0 { stroke: var(--N900-FG, 0.15); }#RpSbeVSwEsOE .fb0 {stroke: rgba(31,35,41, 0.15)}#RpSbeVSwEsOE .fx0 { stroke-miterlimit: 10; }#RpSbeVSwEsOE .fx0 {stroke-miterlimit: 10}#RpSbeVSwEsOE .fa1 { fill: rgb(187, 191, 196); }#RpSbeVSwEsOE .fa1 {fill: rgb(187, 191, 196)}#RpSbeVSwEsOE .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#RpSbeVSwEsOE .fx1 {font-style: normal}#RpSbeVSwEsOE .fx2 { text-anchor: middle; }#RpSbeVSwEsOE .fx2 {text-anchor: middle}#RpSbeVSwEsOE .fx3 { dominant-baseline: central; }#RpSbeVSwEsOE .fx3 {dominant-baseline: central}#RpSbeVSwEsOE .fx4 { stroke: none; }#RpSbeVSwEsOE .fx4 {stroke: none}#RpSbeVSwEsOE .fc0 { fill: var(--text-caption); }#RpSbeVSwEsOE .fc0 {fill: #646a73}#RpSbeVSwEsOE .fa2 { fill: var(--text-link-disabled); }#RpSbeVSwEsOE .fa2 {fill: rgb(187, 191, 196)}#RpSbeVSwEsOE .fx5 { font: 700 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#RpSbeVSwEsOE .fx5 {font-style: normal}#RpSbeVSwEsOE .fx6 { text-anchor: start; }#RpSbeVSwEsOE .fx6 {text-anchor: start}#RpSbeVSwEsOE .fx7 { dominant-baseline: alphabetic; }#RpSbeVSwEsOE .fx7 {dominant-baseline: alphabetic}#RpSbeVSwEsOE .fc1 { fill: rgb(0, 0, 0); }#RpSbeVSwEsOE .fc1 {fill: rgb(0, 0, 0)}#RpSbeVSwEsOE .fx8 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#RpSbeVSwEsOE .fx8 {font-style: normal}#RpSbeVSwEsOE .fb1 { fill: var(--N900-FG, 0.15); }#RpSbeVSwEsOE .fb1 {fill: rgba(31,35,41, 0.15)}#RpSbeVSwEsOE .fa3 { fill: var(--bg-body); }#RpSbeVSwEsOE .fa3 {fill: #fff}ABC1234567平台风格核心差异掘金微博V2EX头条知乎CSDN技术深度轻量互动极客社区大众阅读专业观点技术博客Markdown、代码块、技术标签140字以内、话题标签、情绪向表达讨论帖形式，拒绝硬广，低调引流故事化表达，结论前置，通俗易懂问答形式，搭配数据与案例SEO标题、代码示例、教程式结构

​

每个发布 Agent 的 SOUL.md 写明对应平台的调性约束。同一套原始素材，经由不同 Agent 改写，产出差异化内容，规避机器批量复制感。​

Cookie 状态管理​

各个平台 Cookie 有效期不一致，属于高频故障点。处理策略：​

发布前预检测：调用轻量接口（获取用户信息）校验 Cookie 是否有效；​

失败降级逻辑：发布失败，本地生成草稿，日志标记 ⚠️ Cookie 过期；​

定期巡检提醒：CEO Agent 每周扫描日志，连续失败则通知人工刷新 Cookie。​

​

踩坑案例：早期实现为先写内容后发布，Cookie过期时，Agent完整生成内容，发布阶段报错，只能留存本地草稿，造成算力浪费。优化改为先校验Cookie，再生成内容。​

​

掘金 API 发布流程​

掘金 RESTful API 实操流程： Step1：上传图片（如有配图）​

​

代码块​

Plain Text

POST https://api.juejin.cn/imagex/set\_upload\_auth\_token​

​

Step2：创建文章草稿​

​

代码块​

Plain Text

POST https://api.juejin.cn/content\_api/v1/article\_draft/create​

Body: {​

"title": "文章标题",​

"brief_content": "摘要（前100字）",​

​

Step3：正式发布草稿​

​

代码块​

Plain Text

POST https://api.juejin.cn/content\_api/v1/article/publish​

Body: { "draft_id": "xxx", "sync_to_org": false }​

​

​

注意：category_id、tag_ids 需要提前查询获取，不可随意填写；AI/机器学习分类ID固定为 6809637767543259144。​

​

鉴权方式，请求头带入 Cookie：​

​

代码块​

Plain Text

​

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

系统早期最大问题：Agent 返回“发布成功”，实际文章并未对外可见。 常见根因：​

HTTP 返回200，业务逻辑失败：文章进入审核队列、被平台拦截；​

Agent 只调用创建草稿接口，未执行真正发布，误报完成；​

Cookie 过期，接口不返回401错误，直接返回空数据。​

修复方案：必须验证「读者可见」才算任务完成​

发布完成后等待2‑3秒，调用文章详情接口；​

读取文章状态字段，区分：审核通过 / 发布中 / 驳回；​

日志标准化标记：✅成功、⏳审核中、⚠️发布失败。​

该优化将系统“假完成”错误率从30%下降至接近0。​

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

•

日均：向5‑6个平台产出5‑6篇内容​

•

人工干预：每3‑4天刷新一次Cookie，单次耗时约5分钟​

•

内容质量：约10%文章存在明显缺陷，需要人工复核​

•

引流表现：公众号「Wesley AI 日记」稳步增长，流量主要来自掘金、头条​

下一步计划​

自动 Cookie 刷新：集成浏览器自动化，自动续期登录凭证​

增加内容审核 Agent：发布前对稿件自动打分质检​

数据效果追踪：每周自动统计各平台流量数据，迭代发布策略​

总结​

Cron + 多 Agent 协作，价值不止是节省工时，更重要是实现内容运营的可持续性。 手动运营很容易因为忙碌断更；自动化系统持续运转，创作者只需要聚焦公众号主阵地内容质量。​

​

本文为 Wesley AI 日记 AI Agent 实战系列，更多踩坑复盘可关注公众号。​

​

​