我是怎么把内容系统从一个全能 Agent 拆成多 Agent

type

Post

status

Published

date

Mar 24, 2026

slug

summary

这篇文章系统总结了我把内容系统从“一个全能 Agent”逐步拆分成多 Agent 流水线的过程。最初我试图让同一个 Agent 同时承担采集、筛选、写作、发布和复盘，但很快发现这样会让判断标准混在一起，系统也会迅速退化成搬运工。后来我把流程拆成 collector、reviewer、writer-core 和多个 publisher，让每个 Agent 只做一件事：collector 负责忠实采集，reviewer 负责主题归并与新增价值判断，writer-core 负责生成平台无关的核心稿，publisher 则分别面向微博、Notion 和 Moltbook 做多端适配和发布。文章重点分析了拆分过程中遇到的几个核心问题，包括采集与筛选不能混做、reviewer 应该“筛主题”而不是“筛素材”、多发布端必须基于一份 core draft 二次适配、以及多平台状态设计为什么比角色命名更重要。最终沉淀出的原则是：多 Agent 的价值不在于角色越多越高级，而在于每一层职责清晰、状态可控、错误可恢复，这样内容系统才不会沦为机械搬运，而会更像一个真正做过、想过、踩过坑之后持续输出判断的系统。

一、背景

这段时间我一直在做一件事：

搭一套能持续产出内容、但又不至于退化成搬运工的多 Agent 内容系统。

我最初的目标并不是做一个“看起来很复杂”的系统，而是想解决一个很实际的问题：

怎么让内容系统既能自动跑起来，又能保留真实经验、判断和复盘感，而不是变成“看到一条发一条”的流水线。

一开始，我直觉上会觉得：

既然有 OpenClaw

有浏览器能力

有 cron

有多 agent

干脆做一个“全能 Agent”就好了

它负责：

采集

判断价值

合并主题

生成文案

发布到微博

发布到 Notion

再发到 Moltbook

最后更新状态、记住经验

听起来很完整。

但真正做起来以后，我很快发现：

多 Agent 系统最容易犯的第一个错误，不是能力不足，而是让一个 Agent 做太多事。

后来我一步步把它拆开，最后形成了现在这条流水线：

collector-moltbook

collector-ops-log

reviewer

writer-core

publisher-weibo

publisher-notion

publisher-moltbook

这篇文章想系统整理一下：

为什么要这么拆

每一层的职责是什么

过程中踩了哪些坑

最后沉淀出了哪些设计原则

二、为什么一开始会想做多 Agent

我做多 Agent，不是为了“证明 multi-agent 很高级”，而是因为内容系统天然存在多个层级。

我真正想实现的不是：

看到一条新闻，转一条

看到一个帖子，总结一条

看到一个热点，再换个说法发一次

我真正想实现的是：

先收集多个来源的信息

再把同一主题的内容归并起来

理解这些内容之间的共识与分歧

基于这些信息形成自己的判断

最后输出有新增价值的表达

一旦目标变成这样，系统就天然会分层：

收集

筛选

归并

写作

发布

复盘

而这时，“一个 Agent 全包”很快就会开始失控。

三、为什么一个全能 Agent 很快会失控

1. 判断标准会混在一起

最早我让一个 Agent 同时负责：

收素材

判断值不值得留

决定今天写什么

写文案

发布

后来发现最直接的问题是：

“值得采集”和“值得发布”根本不是同一件事。

一条内容可能：

值得采集，因为它提供了一个话题线索

不值得直接发，因为还没有新增价值

值得进 Notion 沉淀，但不适合发微博

适合发 Moltbook，但不适合做公开短帖

如果同一个 Agent 同时处理这些判断，它就会不断提前替下游做决定。

最后系统会出现两种极端：

要么太保守，前面就把很多潜在线索过滤掉

要么太宽松，后面一路放行，最后变成搬运工

2. 同一个任务里混了太多目标

collector 的职责本来应该是：

忠实获取信息

标准化信息

尽量少做价值判断

但如果 collector 同时还承担“这条值不值得写”，它就会开始带着下游目标去看素材。

结果就是：

采集阶段开始脑补价值

采集阶段开始提前裁剪

系统在最前面就开始失真

后来我越来越确定一件事：

多 Agent 的关键，不是多几个角色，而是每个角色只做一件事。

四、第一层拆分：collector 和 reviewer 必须分开

这是我最早踩到、也最早确认必须坚持的原则。

为什么采集和筛选必须分开

如果让 collector 既采集又筛选，它会天然倾向于只留下“自己觉得有价值”的内容。

但 LLM 对“有价值”的判断其实并不稳定：

同一条内容，不同时间判断可能不同

同一条内容，换一句提示词结果可能不同

同一条内容，今天觉得平，明天觉得能写

而采集阶段最怕的就是这种不稳定。

所以后来我把这一层明确拆开。

`collector-moltbook`

只负责：

从 Moltbook 收内容

标准化成统一 JSON

写入 inbox/

设置：

status = raw
owner = reviewer

它不负责判断“值不值得发”。

`reviewer`

再负责：

去重

判断价值

主题归并

决定哪些内容继续往下流转

这个拆分做完以后，系统立刻稳了很多。

五、第二层升级：reviewer 不应该筛素材，而应该筛主题

这是我整个系统里最关键的一次升级。

一开始 reviewer 只是普通筛选器：

看一条 raw

打个分

决定通过 / 拒绝

但后来我发现，这样还是不够。

因为如果 reviewer 还是逐条判断，那 writer 拿到的仍然是“单条素材”。

而单条素材天然会把系统往这条路上带：

收一条

改一条

发一条

这本质上还是很容易退化成搬运流。

后来我把 reviewer 的职责改成了：

不判断这条能不能发，而是判断今天最值得写的主题是什么。

它的工作变成：

读取多条 raw 素材

按主题聚类

提炼：

大家都在说什么

哪些信息是重复的

哪些观点互相冲突

哪些角度还没说透

最值得补充的新增价值是什么

产出 candidate

这时候 candidate 的含义也变了。

它不再是：

一条待写素材

而变成：

一个已经经过归并、提炼和判断的候选主题

这一步之后，我才真正觉得系统开始脱离“搬运流水线”。

六、第三层拆分：writer 不应该直接写平台稿，而应该先写 core draft

最开始我有一个 writer-publisher-weibo，它做的是：

读取 candidate

改写成微博

直接发出去

这个设计在只有微博的时候还勉强说得过去。

但一旦平台变成：

微博

Notion

Moltbook

问题就立刻暴露出来了。

原因很简单

微博、Notion、Moltbook 根本不是同一种表达环境。

微博需要：

更短

更直接

更快给出判断

适合即时传播

Notion 需要：

更完整

更结构化

适合沉淀

方便以后复用

Moltbook 需要：

更像真实的 field notes

有过程感

有 agent 社区里的经验交流感

不是微博短帖，也不是知识库文档

如果 writer 直接写微博稿，那再想拿去发 Notion 或 Moltbook，效果一定会变差。

于是后来我把写作层拆成：

`writer-core`

只做一件事：

把 candidate 写成一份平台无关的核心稿（core draft）

这份 core draft 不是终稿，而是一份母稿。

它应该具备：

明确主题

核心判断

支撑判断的关键信息

可延展方向

足够的信息密度

但不带过强的平台口吻

这一步让我真正接受了一件事：

“一份理解，多端发布” 的关键，不是多个平台共用同一份终稿，而是多个平台共用同一份母稿。

七、第四层拆分：publisher 必须按平台拆开

有了 core draft 之后，发布层就必须拆开。

后来我把它分成：

publisher-weibo

publisher-notion

publisher-moltbook

`publisher-weibo`

负责：

读取 core draft

适配成微博版本

执行发布

写 publish-record

更新 publish_state.weibo

`publisher-notion`

负责：

读取 core draft

整理成适合沉淀的结构

调 Notion API 发布

写 publish-record

更新 publish_state.notion

`publisher-moltbook`

负责：

读取 core draft

改写成更适合 Moltbook 的表达

调 Moltbook API 发布

写 publish-record

更新 publish_state.moltbook

这样之后，一个主题就变成：

reviewer → writer-core → 多个 publisher 各自适配

这才是真正意义上的多平台分发。

八、过程中踩过的关键坑

1. schema 不能一开始拍脑袋定完

一开始我写了很多 example：

content-item.example.json

draft-item.example.json

publish-record.example.json

但后来很快发现，schema 不能只靠想象设计。

最明显的问题有两个

问题一：单条素材和候选主题混在一起

最开始 content-item 更像单条素材。

后来 reviewer 产出的其实已经不是“单条素材”，而是“候选主题”。

我没有立刻新建 topic-item，而是先做兼容，在 extra 中加入：

merged_source_ids

consensus

differences

unsaid_angle

new_value

recommended_angle

这是一个很典型的经验：

先让 schema 兼容真实流转，再考虑彻底重构。

问题二：状态不能只有一个总状态

一开始只有：

candidate

drafted

published

但一旦同一主题要同时发：

微博

Notion

Moltbook

问题就出来了。

比如微博先发了，如果立刻把总状态改成 published，那 Notion 和 Moltbook 后面就接不到。

后来我把状态拆成两层：

总状态

candidate

drafted

published

平台状态

放进：

然后规则变成：

单个平台成功，只更新自己的状态

只有所有目标平台都 success，才把总状态改成 published

这一步对多 publisher 系统至关重要。

2. Notion 发布成功，不只是“能写进去”

一开始我以为：

API 通了

页面建出来了

就算发布成功。

后来才发现，对于真实业务来说，这远远不够。

比如对我的 Notion 内容库来说，发布成功不仅意味着“页面存在”，还意味着：

标题必须是中文

status 必须是 Published

字段映射必须符合数据库要求

目标位置必须明确

所以后来 publisher-notion 的成功条件变成了字段级的，而不是动作级的。

我最终得到的结论是：

自动化系统里最容易被忽略的，不是“能不能执行”，而是“执行结果是否符合业务语义”。

3. 微博发布链路里，不能假设 agent 一定有 browser tool

这也是一个非常实际的坑。

一开始我把 publisher-weibo 写得很理想化：

必须优先使用 browser tool

禁止通过 shell 调 openclaw browser CLI

结果真跑的时候才发现：

当前 agent 实际拿到的工具只有：

exec

read

write

没有独立 browser tool。

这就导致规则要求必须 browser tool，但运行时根本没这个工具，最后陷入死锁。

后来我才真正接受：

底层浏览器能力可能是同一套

但对 agent 来说，“原生 tool” 和 “通过 exec 间接调用 CLI” 是不同层次

于是后来我把规则改成：

优先使用 browser tool

如果当前环境没有独立 browser tool，但有 exec，允许回退到 openclaw browser CLI

这个坑让我重新理解了一件事：

设计时不能只按理想架构写规则，还要考虑当前运行环境到底能提供什么能力。

4. Moltbook 没发出去，不一定是 publisher 的锅

这几天 Moltbook 没发出去，我一开始也以为是 publisher-moltbook 有问题。

后来逐层检查才发现，问题其实更早出在上游。

第一层问题：reviewer 没稳定写 `distribution_targets`

有些旧主题带了 moltbook，但很多新主题没有。

这说明 reviewer 在“应该发到哪些平台”这件事上，判断规则不够稳定。

第二层问题：writer-core 没初始化 `publish_state.moltbook`

它只初始化了：

weibo

notion

忘了：

moltbook

这意味着即使 reviewer 把 moltbook 放进了 distribution_targets，后面的状态依然不完整。

这个坑让我更确定一件事：

多 agent 系统里，很多下游问题，真正的根源都在上游字段不统一、职责边界没写死。

九、最后沉淀出的设计原则

原则一：每个 Agent 只做一件事

collector 就采集。

reviewer 就归并和判断。

writer-core 就写母稿。

publisher 就只负责适配和发布。

一旦一个 agent 同时承担多个目标，它就会开始替下游做决定。

原则二：收集、筛选、写作、发布必须分层

这四层不能混。

收集负责忠实获取信息

筛选负责形成主题判断

写作负责形成表达骨架

发布负责适配平台和执行动作

混在一起，系统必乱。

原则三：不要逐条转发信息，要先形成主题理解

如果系统最后只是：

收一条

改一条

发一条

那它迟早会退化成搬运工。

真正有价值的是：

多条信息

一个主题

一次判断

一份表达

原则四：多发布端不是多抄几份，而是一份母稿多端适配

不要让微博稿兼容 Notion。

不要让 Notion 页兼容 Moltbook。

不要让 writer 直接面向所有平台写终稿。

正确方式是：

一份 core draft

多个平台各自适配

原则五：状态设计比角色设计更重要

角色好起名字，状态难设计。

真正难的是：

owner 怎么流转

status 怎么变化

多 publisher 怎么互不阻塞

失败后怎么恢复

成功后怎么收口

如果状态没想清楚，多 agent 只会越拆越乱。

原则六：长期偏好放记忆层，流程规则写死在 AGENTS.md

像这些内容：

当前关注主题

账号定位

风格偏好

质量阈值

最近不想重复的话题

更适合放进：

MEMORY.md

USER.md

而不是反复改 AGENTS.md。

AGENTS.md 更适合写死：

职责

输入输出

状态流转

成功条件

失败处理

十、如果让我重来一次，我会怎么设计

如果重新做一遍，我会比一开始更克制。

第一阶段

先只做：

collector

reviewer

writer-core

先验证：

能收

能归并

能写出像样的母稿

第二阶段

加：

publisher-weibo

先跑通一个真实发布端。

第三阶段

再加：

publisher-notion

publisher-moltbook

然后再解决：

多平台状态拆分

并行发布

整体收口

第四阶段

最后再加：

collector-ops-log

collector-history

复盘与记忆更新

因为如果一开始就把所有角色都堆上去，系统不是不能跑，而是你很难知道到底哪一层出了问题。

十一、最终感受

这段时间折腾下来，我最大的感受不是“multi-agent 很强”，而是：

多 Agent 的价值，不在于角色变多，而在于系统能不能更诚实地面对每一层问题。

collector 诚实地收集。

reviewer 诚实地判断。

writer-core 诚实地写出骨架。

publisher 诚实地适配和发布。

状态层诚实地记录谁完成了、谁还没完成。

当每一层都不再替下一层做决定，系统才真正开始稳定。

而稳定之后，内容系统才有可能慢慢长成我更想要的样子：

不是一个自动生成器，而是一个真的做过、想过、踩过坑之后，慢慢把经验讲清楚的系统。