作者：varkm

先给结论：内容创作不需要你每天坐在电脑前写2-3小时。用定时调度 + 多Agent协作框架，可以把单篇文章的人工介入时间压缩到15-20分钟——选个题、过一遍终审，剩下的全交给自动化。

这不是理论推演，是我自己跑了三十多篇文章后总结的完整方案。从选题到发布，七个Agent角色自动接力，质量有reviewer把关，crash能自动恢复。下面从架构到踩坑，完整拆给你看。

一、从手动到自动：一篇稿子到底有多烦

手动发一篇稿子，流程是这样的：

选题 → 搜索资料 → 写初稿 → 自查事实 → 排版 → 互相审核 → 上传平台 → 发布

每一步都要你亲自盯着。写初稿1小时，排版30分钟，审校来回改又是30分钟——还没有算上搜索资料的时间。一天一篇，大半个下午就没了。更难受的是，这些步骤大部分是机械重复的：格式转换、上传、构建，每次都一样，但每次都得手动做。

AI Agent能解决一部分问题——让它帮你写初稿、做调研。但单个Agent有上限：context会被压缩，中间产物容易丢，质量没法保证。你以为写完了一篇好文章，结果排版后发现格式全乱了。

真正的解法是把整个流程拆成流水线，每个环节一个专职Agent，用定时任务触发，用看板系统串联。这就是"内容工厂"的核心思路：不是让一个Agent干所有事，而是让一群Agent各司其职，自动接力。

二、架构设计：四个组件撑起一座工厂

整套架构只有四个核心组件，职责分明：

定时调度器（Cron）：按时间表触发任务，支持三种模式——cron表达式（每天8:30）、一次性定时（2026-06-20T09:00）、间隔触发（每2小时）。它是整个工厂的"开工铃"。

编排器（Orchestrator）：收到触发后，把一个选题拆成多个子任务，分配给不同Agent。它不干活，只负责拆活、排队、传递产物。

Worker Agent池：每个Agent只干一件事。写稿的只写稿，审校的只审校，构建的只构建。职责越单一，出错率越低。

质量门禁（Reviewer）：贯穿流水线始终。任何产物发布前必须过reviewer审核，不通过就阻断下游，打回重做。

数据流长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

定时触发 → 编排器创建任务链
                ↓
    ┌─── 写作Agent ──→ 初稿(Markdown)
    │                      ↓
    │              ┌─ Reviewer审核 ──┐
    │              ↓                  ↓
    │     博客构建Agent        公众号排版Agent
    │              ↓                  ↓
    │     格式Review            格式Review
    │              ↓                  ↓
    │              └──→ 部署Agent ←───┘
    │                      ↓
    └────────────── 双渠道发布完成

为什么用看板（Kanban）做任务管理，而不是代码里直接串函数调用？三个原因：

1. 持久化：任务状态存在数据库里。Agent进程crash了，任务不会丢，重新调度就行。
2. 依赖链：用parents字段声明依赖关系，父任务完成前子任务自动等待，不需要你手动写轮询逻辑。
3. 可观测：每个任务有完整的状态流转记录——什么时候创建、谁在做、结果如何，全都能追溯。

三、Cron定时调度实战：三种模式覆盖所有场景

定时调度器支持三种触发模式，对应不同的自动化场景：

创建一个定时任务的基本配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 每天早上8:30自动触发选题→写稿pipeline
schedule: "30 8 * * *"           # cron表达式
name: "daily-content-pipeline"
deliver: "local"                  # 结果只存本地，不打扰主会话

prompt: |
  今天的热点技术话题调研。
  从搜索趋势中选一个适合深度解读的选题，
  生成选题报告保存到 ~/output/today-topic.json。
  不要直接写文章，只做选题。

这里有个关键设计原则：cron只负责触发，不要在cron里塞完整流程。 我最初图省事，把选题、写稿、审核全塞进一个cron任务的prompt里。结果context太长，中间某个步骤出了bug，整个流程就断了，而且无法复用。

正确做法是分层：

1
2
3
4
5
6
7

# 第1层：cron每天触发选题
schedule: "30 8 * * *"
prompt: "调研今日技术热点，选题保存到JSON"

# 第2层：选题完成后，编排器读取JSON
# 拆分成写作→审校→发布整条链
# 这层不是cron，是编排器的自动响应

另外两个实用配置项：

隔离会话（sessionTarget）：自动化任务一定要用隔离会话，不要污染主会话。主会话是你日常对话的地方，如果定时任务的结果全往里灌，很快就会被噪音淹没。隔离会话意味着每次触发都是干净的上下文，不携带历史包袱。

no_agent模式：有些定时任务不需要AI参与。比如监控某个API返回值的变化——用脚本直接检查就行，不需要启动Agent会话。这种模式只跑脚本，有变化才发通知，没变化就安静，省token又干净。

四、多Agent Pipeline实战：七个角色一条龙

这是整篇文章最核心的部分。完整的文章发布pipeline有七个步骤，六个Agent角色：

创建一条完整pipeline，编排器的配置长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# 编排器：创建任务链时预声明所有依赖关系
pipeline:
  - id: writer
    assignee: content-writer
    body: |
      选题：{{topic}}
      字数：2500-3500
      输出：~/output/{{slug}}.md

  - id: reviewer
    assignee: reviewer
    parents: [writer]          # ← writer完成后才启动
    body: |
      审校 ~/output/{{slug}}.md
      checklist: 事实核查/PII脱敏/AI味检测

  - id: blog-builder
    assignee: blog-builder
    parents: [reviewer]        # ← 审校通过才构建
    body: |
      将通稿转为博客Markdown
      hugo build 并验证页面数

  - id: mp-creator
    assignee: mp-creator
    parents: [reviewer]        # ← 与blog-builder并行！
    body: |
      通稿转公众号HTML
      生成封面，上传草稿

  - id: blog-review
    assignee: reviewer
    parents: [blog-builder]

  - id: mp-review
    assignee: reviewer
    parents: [mp-creator]

  - id: deployer
    assignee: deployer
    parents: [blog-review, mp-review]   # ← 双审核通过才上线

注意看T3和T4：它们的parent都是reviewer（T2），这意味着审校通过后，博客构建和公众号排版同时启动，不需要等一个做完再做另一个。这就是fan-out并行——同一条稿子，两个渠道同时加工。

而T7部署Agent的parents同时依赖blog-review和mp-review。只有两个渠道都通过了终审，才会触发部署。这是"双保险"设计：确保博客上线之前，两个渠道的格式都已经过了独立审核。

parents依赖链的运作机制：每个子任务创建时处于"等待"状态，只有当所有parent任务都标记为"完成"后，才会自动变成"就绪"状态，等待调度器分配执行。如果某个parent被reviewer打回（标记为blocked），所有下游子任务都会被冻结——不会出现"文章还没审完就发布上线"的情况。

reviewer作为质量门禁的打回机制：reviewer发现问题时不应该直接标记任务完成，而应该标记为blocked，附上具体问题和修改建议。这样下游任务永远不会启动。被blocked的任务修复后会重新进入流程。这个机制确保了自动化不会牺牲质量——没有人工"放行"，有问题的内容走不到发布环节。

五、踩坑实录：四个血泪教训

理论看着很美，实操全是坑。以下每一条都是我亲身踩过的。

坑1：写作Agent不会自动触发下游pipeline。

我最初的想法很天真：写完稿子，Agent自然会去创建审校任务、构建任务……结果写完就写完了，下游什么都没发生。

原因很简单：单个Agent不知道自己在pipeline里的位置。它的任务是"写一篇文章"，写完就done了。如果你不在编排阶段就把整条链创建好，下游任务根本不存在。

解法：必须由编排器预先创建所有任务（包括依赖关系），而不是指望写作Agent自己往后串。写作Agent只管写，编排器管串联。

坑2：cron任务里塞了完整流程，一崩全崩。

有一阵子我想偷懒，把选题→调研→写稿→排版全塞进一个cron任务。跑了三天就出事：某个步骤的API超时，后面的流程全卡住了。更麻烦的是，这种"巨石型"任务出bug后几乎没法调试——你得从一大坨日志里找到是哪个环节挂的。

解法：cron只做最轻的一层——触发选题。后面的写作、审校、发布全交给编排器拆分的专职Agent。每一层独立，crash了只影响自己这一步，重启就好。

坑3：context压缩导致中间产物丢失。

多Agent协作时，信息传递是个大问题。写作Agent把调研数据、大纲、参考链接都放在context里，但传给审校Agent时context被压缩了——参考链接没了，审校Agent不知道原始数据来源，没法做事实核查。

解法：所有中间产物必须立即持久化到文件，而不是存在context里。写作Agent写完稿子存到~/output/xxx.md，task的metadata里记录文件路径。下游Agent从文件读取，不依赖context传递。把context当临时工作台，把文件系统当持久存储。

坑4：reviewer只查格式不查内容完整性。

我的reviewer一开始配置得太粗放——只检查格式（日期格式对不对、标签有没有、代码块有没有标语言），不检查内容。结果有篇文章少了整个"踩坑"章节就过了审。因为格式上一切正常，reviewer找不到问题。

解法：task body里必须写死文章大纲（每章标题+预计字数）。reviewer对照大纲逐章检查——该有的章节在不在、核心论点有没有展开。格式检查可以自动化，但内容完整性检查必须靠结构化大纲来约束。

六、效果与思考

跑通这套pipeline后，我的实际体感是这样的：

效率：从每篇2-3小时压缩到15-20分钟人工介入。我每天早上看一眼选题报告，选一个顺眼的，说"就这个"，然后该干嘛干嘛。等我中午回来，稿子已经写完、审完、排好版了，我只需要过一遍终审。

质量保障：reviewer机制确保自动化不等于粗制滥造。每一篇稿子都要过两轮审核——内容审核和格式审核。有事实错误、有AI味、有PII泄露的稿件根本走不到发布环节。三十多篇文章下来，没出过质量事故。

但也有局限。选题仍然需要人工判断——自动化能做的是"搜热点"，但"这个热点值不值得写"还是得人来拍板。追热点话题也一样，突发新闻的时效性需要人工决策，自动pipeline的反应周期还是太慢。

这套方案的真正价值不在于"全自动"，而在于"标准化"。把重复劳动交给机器，把判断决策留给人。你不再是流水线上的工人，而是工厂的质检员和调度员。

未来我打算加入两个能力：一是基于搜索趋势的自动选题（减少人工选题频率），二是竞品内容自动分析（写之前先看看别人怎么写的，找差异化角度）。但这两件事的前提都是先把基础设施跑稳——地基不牢，加再多自动化也只是加速出错。

关注 varkm，一起学习，一起成长。