用 AI Agent 搭建微信公众号全自动内容 Pipeline：从选题到发布的事件驱动架构实战
一晚上从零搭建了一套 AI 驱动的内容自动化系统，从选题筛选到文章发布全流程覆盖。本文分享完整的架构设计、踩坑经验和关键代码。
前言
作为一个技术自媒体运营者，最头疼的事情不是写文章本身，而是整个内容生产流程：
- 每天从几十个信息源里筛选值得写的选题
- 选题确定后要做深度调研，不能写水文
- 写完还要排版、配图、发布到多个平台
如果这些重复性工作能让 AI 自动完成，人只需要在关键节点做决策把关，那效率会提升多少？
答案是：我们用一晚上搭好了这套系统。
整体架构
事件驱动 + 人工卡点
这套系统不是"一键生成文章"的玩具，而是一个事件驱动 + 人工卡点交替推进的工程化 Pipeline：
定时触发 → AI筛选选题 → 【人工确认】→ AI深度调研+大纲 → 【人工确认】→ AI撰写全文 → 【人工确认】→ 自动发布
关键设计原则：AI 负责执行，人负责决策。 三道人工卡点保证内容质量。
三层分离架构
┌─────────────────────────────────────┐
│ Skill 层（编排入口） │
│ SKILL.md 定义10种事件处理规则 │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Agent 层（思考执行） │
│ Strategist │ Architect │ Scribe │
│ 选题筛选 │ 调研+大纲 │ 撰写全文 │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ 工具层（基础设施抽象） │
│ db.py（14个子命令）+ config.py │
│ Agent 不接触任何凭证和数据库连接 │
└─────────────────────────────────────┘
为什么要三层分离？
- 安全：Agent 通过工具脚本间接操作数据库，不接触 Supabase 密钥
- 可测：每层可以独立测试和替换
- 可维护：换数据库只改工具层，Agent 层和 Skill 层不用动
核心机制：Sub-Agent 接力
这是整套系统最关键的技术验证点。
问题
主 Agent 负责编排，具体任务（选题/调研/写作）交给 Sub-Agent 执行。但 Sub-Agent 完成后怎么通知主 Agent 继续下一步？
方案
利用 OpenClaw 的 sessions_spawn 机制：
# 主 Agent spawn 一个 Sub-Agent 执行调研任务
sessions_spawn(
task="根据选题进行深度调研，生成文章大纲",
label="architect-article-42",
mode="run"
)
Sub-Agent 完成后，系统自动推送完成事件到主 Session。主 Agent 通过 label 识别来源，按 Skill 规则决定下一步。
验证结果
02:42 spawn Sub-Agent → 执行调研任务
02:43 Sub-Agent 完成 → 系统推送完成事件
02:43 主 Agent 收到事件 → 解析输出 → 接力下一步
✅ 全链路通过
这个接力机制是整套 Pipeline 能跑起来的基石。
三个 AI 角色设计
Strategist（策略师）—— 选题筛选
- 输入：radar_outbox 表中的当日 AI 热点话题（由 HuggingFace Space 自动抓取）
- 任务：从几十个话题中筛选 3-5 个最值得写的
- 输出：带评分和理由的选题列表
- 特点：纯判断，不搜索，不创作，确保筛选的客观性
Architect（架构师）—— 深度调研 + 大纲
- 输入：确认后的选题
- 任务：先调研（搜索引擎 + 官方文档），再生成大纲
- 输出：带信息源标注的详细大纲
- 关键约束：必须先调研后大纲，调研深度是核心价值
Scribe（撰稿人）—— 内容写作
- 输入：确认后的大纲 + 调研材料
- 任务：撰写完整文章
- 输出：符合公众号风格的 Markdown 全文
- 写作规范：禁止 AI 味重的表达（"在当今..."、"让我们..."），要求干货密度
数据层设计
使用 Supabase 作为数据存储，核心表结构：
-- 文章主表
CREATE TABLE articles (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
status TEXT DEFAULT 'topic_selected', -- 状态机
topic_source JSONB, -- 选题来源
outline TEXT, -- 大纲
content TEXT, -- 正文
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- 状态流转：
-- topic_selected → outline_draft → outline_confirmed
-- → writing → review → published
状态机设计确保每篇文章都有清晰的生命周期，任何时候都知道它在哪个阶段。
工具脚本层
db.py 封装了 14 个子命令，覆盖 Pipeline 全流程：
# 获取今日热点话题
python3 db.py get-radar-topics --limit 20
# 保存选题
python3 db.py save-selections --article-id 42 --topics '[...]'
# 创建文章
python3 db.py create-article --title "xxx" --topic-source '{...}'
# 保存大纲/正文
python3 db.py save-outline --article-id 42 --outline "..."
python3 db.py save-content --article-id 42 --content "..."
# 查询状态
python3 db.py get-active-articles
Agent 只需要调用这些命令，不需要知道 Supabase 的 URL、Key 或者 SQL 语法。
踩坑与经验
1. Sub-Agent 的 streamTo 限制
最初想用 streamTo="parent" 实现实时流式输出，发现这个参数只支持 ACP runtime。但 push-based 的完成事件已经够用，不影响核心流程。
2. Skill 作为编排入口的好处
最初设计是让主 Agent 记住所有流程规则。后来改为写在 SKILL.md 里，主 Agent 每次查阅执行。好处是：
- 流程修改只改 SKILL.md，不用重新训练 Agent
- 调试时一目了然，知道 Agent 该做什么
- 多个事件类型的处理规则不会混淆
3. Agent 不该直接操作数据库
第一版设计让 Agent 直接用 SQL 操作 Supabase。问题很明显：
- Agent 需要记住 SQL 语法和表结构
- 凭证暴露在对话上下文中
- 出错难以排查
改成工具脚本层后，Agent 只需要 python3 db.py xxx，干净利落。
总结
这套系统的核心思想是：让 AI 做 AI 擅长的事（筛选、调研、写作），让人做人擅长的事（决策、把关、定方向）。
技术栈：
- 编排：OpenClaw + Skill 事件驱动
- 执行：Sub-Agent（Strategist / Architect / Scribe）
- 存储：Supabase（PostgreSQL）
- 抽象：Python 工具脚本层
- 交互：Discord 频道（审核和确认）
从方案设计到代码框架，一个晚上完成。下一步是接入真实数据源跑起来，到时候再分享实战效果。
如果你也在做内容自动化，欢迎交流。 关注我，后续会分享更多 AI Agent 实战经验。
标签：AI Agent, 内容自动化, 事件驱动架构, OpenClaw, Supabase, 微信公众号, Sub-Agent
浙公网安备 33010602011771号