OpenClaw多Agent协同：选题创作审核的全流程自动化-平芜编程栈

1. 全流程自动化不是梦：这个系统到底想解决什么问题

做自媒体内容，尤其是日更号，最耗人的不是写作本身，而是选题、创作、审核这一串流水线。我见过太多团队卡在同一个死循环里：编辑花半天找选题，写手熬夜赶稿，主编审稿又嫌质量不够，一改又是半天。最后日更变成周更，周更变成随缘更。

我刚开始搭OpenClaw多Agent协同的初衷就一句话：把人从重复性判断里解放出来。OpenClaw本身是一套多Agent编排框架，核心思路是把“选题-创作-审核”拆成三个独立Agent，每个Agent负责一个环节，通过消息队列和共享状态进行协作，把原来需要三个人接力完成的事情，用一套自动化流水线跑完。这个系统解决的不只是“快”，而是让内容生产的每个环节都有据可查、有标准可依，产出质量和稳定性肉眼可见地提升。

这套东西适合谁参考？如果你是一个人在做多个平台的账号，或者团队里有明确的分工但总是卡在流程衔接上，再或者你手里有大量内容需求但人力不够，都可以参考这个方案。尤其是对“爆款依赖个人灵感”这件事感到焦虑的博主，多Agent协同能把灵感从偶然变成流程。

当然，一开始我只想靠脚本做关键词搜集，然后塞给AI写稿。真正做下来才发现，单Agent处理不了全流程的复杂性，因为选题、创作、审核对上下文和判断标准的要求完全不同。这也是我转向OpenClaw多Agent架构的根本原因——让专业的人干专业的事，在AI世界里同样成立。

2. 整体设计思路拆解：为什么必须拆成多个Agent

2.1 单一Agent的瓶颈：上下文污染与标准冲突

先说我踩过的第一个坑。最早我用一个大模型对话窗口，把所有指令一次性塞进去，让它“既是选题策划，又是写作编辑，又是审核专家”。结果很典型：写出来的稿子总是带着一股“半成品味”，要么是选题角度太大太空，要么是内容结构只能看不能用，最难受的是让它审核自己写的内容，永远都是“基本合格，略有不足”——因为是同一个上下文，它根本没有外部视角。

问题本质在于上下文污染。选题环节需要的是信息广度（热点、搜索量、竞争程度），创作环节需要的是表达张力（结构、语气、案例密度），审核环节需要的是标准确定（事实核查、违禁词、标题吸引力）。这三套需求在同一上下文中拉扯，效果就是什么都做不好。而且，责任边界模糊之后，出了问题根本定位不到是哪个环节崩了。

拆成多Agent之后，每个Agent只维护与自己作业相关的上下文状态。比如“选题Agent”只需要接收历史内容库和当日热点数据，输出选题建议；“创作Agent”则不关心热点从哪来，只接收选题卡的规范字段，输出待审核稿件；“审核Agent”更是纯粹，只拿一套审核规则去对照稿件，逐项打分打标签。上下文互不污染，问题可定位，这是多Agent架构最直接的红利。

2.2 OpenClaw协同模型：黑话不多，理解成“流水线+工单系统”就够

OpenClaw的协同机制，我理解下来核心是四件事：Agent注册、任务编排、状态同步、结果回传。每个Agent跑在独立的工作节点上，它们之间不直接调用，而是通过一个“协同总线”交换数据。这个总线很像一个小型工单系统——选题Agent把“选题卡”写到队列里，创作Agent监听队列拿到选题卡开始写作，写完把稿件放到审核队列，审核Agent再取走。

这比“AI调用AI”简单也更稳。直接调用的问题是失败重试逻辑难写，而且链路一长，任何一个环节超时，整个流程就挂掉了。改成工单模式之后，每个环节都有独立的确认和重试机制。比如审核Agent认为稿件不合格，可以打回创作队列并附上修改意见，而不是整个流程从零开始。这个打回动作在OpenClaw里就是一个带状态标签的消息，不涉及复杂的记忆网络或长文本传递。

好处还体现在审计上。因为所有流转都有事件记录，某天如果发现某篇稿子数据异常，我可以通过OpenClaw的控制台回放那一篇稿子的完整流转链路：选题卡是谁生成的、基于什么数据、创作Agent用了什么风格模板、审核Agent标记了哪几条问题。整个链路可在事后复核，这一点对账号安全非常重要。

2.3 为什么选“规则+模型”双驱动，而不是全靠AI判断

再往深一层说，我在设计OpenClaw协同逻辑的时候，刻意没有把判断权全交给大模型。核心原则是：能用规则解决的问题绝不用模型，模型只处理真正需要语义理解的环节。

举例来说，选题环节里有一项是“判断关键词是否与账号定位相关”。如果用纯模型判断，每次结果可能都有轻微浮动，而且你需要不断调试提示词。我的做法是先在规则层维护一个“核心词库+扩展同义词库”，用词法匹配去过滤明显无关的选题。只有通过词法匹配的候选词，才进入大模型排序阶段。这样一来，模型只需要在约20%的候选词上做语义理解，既省Token又稳。

创作环节也有类似的混合机制。比如标准的结构段落、常用开头句式、结尾引导关注的模板，这些是固定规则，直接通过模板拼接；只有“根据选题卡填充具体案例和论证逻辑”这部分走模型。审核环节更不能全信模型，违禁词、敏感词、平台限流词全部走规则库和词表匹配，模型只负责“可读性”和“吸引力”这种主观向的评价。双驱动架构的最大好处是：即使模型升级或者提示词变化，系统的底线（合规）依然被规则层牢牢守住。

3. 核心细节解析：选题、创作、审核三个Agent分别怎么设计

3.1 选题Agent：把玄学变成基于数据的筛选漏斗

选题这个环节最容易被低估。很多人觉得选题就是看看热搜、翻翻评论，但真正要做的是三层漏斗：海选、初筛、排序。

海选阶段，选题Agent每天按规定时间拉取多个源的数据，包括平台热搜榜、关键词搜索趋势、同领域头部账号的最新内容。这里有个技术细节：不同平台的数据结构差异很大，热搜榜有的是按热度值排序，有的是按时间排序，还有的只给Top50，需要为每个数据源写独立的解析适配器。我的做法是统一转换成“候选选题条目”数据结构，字段包括：关键词、来源平台、热度指数、抓取时间、原文链接。这样后续流程只用处理一种格式，大大降低复杂度。

初筛阶段走规则层，过滤条件是可配置的。比如：关键词长度少于2个字不要（太泛）；已经在历史内容库里出现过的同类选题不要（避免自相残杀）；热度指数低于设定阈值的不要（说明流量天花板低）；与账号核心定位词库匹配度过低的不要。配置这些规则的关键在于“阈值动态化”。我一开始用固定阈值，结果发现周中和周末的热度高值差异很大，后来改成按“过去7天热度中位数”动态计算阈值，效果明显更稳。

排序阶段交给模型语义理解。给选题Agent的提示词里，要求它从三个维度打分并输出理由：时效性（这个选题现在发和三天后发，效果差异有多大）、独特性（同领域账号是否已经密集写过这个角度）、可延展性（这个选题能否拆成3篇文章，而不是一锤子买卖）。

每个初筛通过的选题都会生成一张结构化选题卡，包含上述所有字段和打分结果。我个人实践中还会加一个“内容缺口”字段，让选题Agent对比历史内容库，标出这个选题与旧内容的差异化点，避免同质化。这张选题卡就是整个流水线的“第一张工单”，后续创作Agent只认这个标准格式。

3.2 创作Agent：结构化模板+模型填充，防跑偏也防AI味

创作Agent拿到选题卡之后，第一件事不是打开模型写文章，而是先匹配写作模板。我根据账号类型预先设计了多种模板，每个模板定义了一篇文章的骨架。以干货分享型文章为例，模板的大致结构是：

开头（80-120字）：场景痛点切入，带出核心关键词。
背景阐述（150-300字）：当前领域现状，说明这个主题为什么此时值得关注。
核心方法/步骤（主体，按需分3-5小节）：每一步都包含“原理+操作+案例”。
常见坑与解决（150-300字）：从真实反馈里选典型的2-3个问题。
收尾（80-120字）：行动建议或延伸思考，不做硬广。

这个结构模板的价值在于逼迫内容形成稳定骨架。很多稿件跑偏，并不是模型能力不行，而是没有给它一个清晰的“轨道”。模板就是轨道。模型只在每一段的要求下做局部生成，生成完之后，通过段落边界检查，确保没有缺节或串节。

指令模板也是关键。创作Agent的提示词里我会动态注入三块信息：选题卡内容（结构化字段）、AI写作约束（不编造数据、不用夸张形容词、不写空话套话）、平台偏好（不同平台字数/格式要求不同，比如微头条偏短句、公众号偏长段落）。然后在提示词中固定一句话：如果选题卡提供的信息不足以支撑某一段的内容，就输出标记“字段缺失”，而不是自行编造。这一点在AI创作中极其重要——宁可让审核环节发现缺失，也不能让模型用幻觉内容填补空洞。

生成之后，创作Agent还会跑一道基础质量自检：段落字数上下限检查（防止有的段落只有一句话）、小标题是否重复、全文是否包含所有模板必需的段落。这道自检消耗很低，主要靠规则和正则，不需要模型参与，目的是在上送到审核队列之前，把明显的机械性问题先滤掉。

3.3 审核Agent：不止是查错，更是质量把关的“机器质检员”

审核Agent的设计可能是最枯燥但最不能省的部分。我把它分成三级审核：

第一级是规则审核，纯代码执行，不调用模型。检查项包括：违禁词和平台敏感词（维护两个词库，一个通用，一个根据平台政策定期更新）、特殊格式（二维码/外链/水印）、重复语句（句子级重复率计算）、字数范围。这一级可以直接拦截掉约三成不合格稿件，而且绝对可解释——每条命中都会记录命中的词或规则编号。

第二级是标准审核，用模型做语义判断。我设计了一个五维评分卡：信息密度（有没有实质信息，还是空话堆砌）、逻辑连贯性（段落之间是否有跳跃）、案例支撑（关键论点是否都有例子或数据支撑）、可读性（句子是不是过长过绕）、标题质量（标题是否足够具体、有无吸引力）。每个维度按1-5分打分，低于预设线（比如信息密度低于4分）则判定不通过。

第三级是交叉审核，这个我建议每个做内容矩阵的人都加上：拿新稿件和历史爆款文章做相似度对比。因为AI生成的稿件有时会悄悄贴近训练数据中的常见写法，造成“既视感过强”，严重影响原创度。我这里是抽3-5篇历史爆款，计算它们的句向量相似度，如果新稿件和某篇旧文的相似段过多，直接打回创作Agent重写相关段落。

审核通过后，系统自动附加审核记录（各维度得分、检查项命中情况）再进入发布队列。如果稿件被打回，创作Agent会收到一份“修改建议单”，里面指明是哪个环节不达标，需要修改哪一部分。这种“打回”机制非常关键，因为多Agent协同的价值不只是提高通过率，更在于形成闭环迭代。

4. 实操过程与核心实现：从框架选型到跑通全流程

4.1 环境搭建与OpenClaw的安装配置

先说明一下，我用的部署环境是纯本地服务器，操作系统选的是Debian稳定版，Python版本要求3.11以上。OpenClaw本身支持主流平台，但我建议有条件的都上Linux服务器，别在本机Windows上跑长期任务，因为多Agent的调度进程需要长时间稳定运行，笔记本一合盖子就断流，体验会很差。

步骤大致如下：

# 创建独立Python环境，避免污染系统环境 python3 -m venv openclaw_env source openclaw_env/bin/activate # 安装OpenClaw主框架 pip install openclaw-core # 验证安装 claw --version

配置层面，核心是一个YAML文件，里面声明三块内容：全局并行度、Agent注册表、队列参数。我的初始配置大致是：

global: parallel_limit: 4 task_timeout: 120 agents: topic_agent: module: agents.topic_agent model: default_llm max_concurrent_tasks: 2 writer_agent: module: agents.writer_agent model: default_llm max_concurrent_tasks: 2 reviewer_agent: module: agents.reviewer_agent model: default_llm max_concurrent_tasks: 1 queue: topic_queue: max_size: 50 draft_queue: max_size: 20

并行度设置有个原则需要说明：不是越大越好。最开始我把并行度拉到8，结果多个Agent争抢同一个模型服务的上下文窗口，出现大量超时和重复生成。后来调成4，全局任务吞吐量反而更高。所谓“性能”本质上是稳定性的函数，不稳定时的重试成本远高于保守配置的等待成本。

4.2 三个Agent的代码骨架与消息流转实现

每个Agent在OpenClaw里本质是一个继承基类的执行单元。我用一个简单的抽象来说明一下骨架。

# agents/base_agent.py from openclaw.core import Agent, Task class BaseAgent(Agent): def __init__(self, config): super().__init__(config) self.input_queue = config["input_queue"] self.output_queue = config["output_queue"] def process(self, task: Task): raise NotImplementedError def run(self): while True: task = self.input_queue.get() result = self.process(task) if result.should_retry(): self.input_queue.put(task, retry=True) else: self.output_queue.put(result)

# agents/topic_agent.py from agents.base_agent import BaseAgent class TopicAgent(BaseAgent): def process(self, task): raw_candidates = self.fetch_hot_topics() filtered = self.rule_filter(raw_candidates) ranked = self.model_rank(filtered) return TopicCard(ranked)

实际运行中，三个Agent独立消费和产出，消息体用JSON格式。选题卡的一条消息大概是：

{ "card_id": "202501201030_01", "keyword": "AI写作工具选型", "source": "platform_hot_search", "heat_score": 87, "reason": "当前多款AI写作工具密集发布新版本，用户搜索意图高涨且已有内容多为厂商通稿，缺少实操对比视角", "content_gap": "历史内容库暂无同类工具横向测评", "status": "pending_writing" }

创作Agent拉到这条消息后，用自己的模板生成稿件，然后生成一个稿件对象，里面包含文章正文、使用的模板ID、以及每一段的生成参数。审核Agent拿到后，跑完三级检查，更新消息状态为“passed”或“rejected”，并附上审核明细。整个过程里，所有Agent都只操作自己职责范围内的字段，不跨域修改，避免“好心办坏事”。

4.3 关键链路：一条任务从选题到审核的全生命周期跟踪

实操中最有价值的一点是OpenClaw自带执行跟踪机制，每个Task都有状态位。我的工作流里，一条任务的生命周期是：

created：选题Agent写入选题卡到topic_queue。
processing_write：创作Agent从topic_queue拿到消息，正在生成稿件。
awaiting_review：稿件已写入draft_queue，等待审核Agent取走。
review_passed：审核通过，消息带上完整审核记录，等待发布。
review_rejected：审核不通过，消息带上修改意见，回写创作队列，此时状态变为rejected_waiting_retry。
published：接入发布模块后，由发布器读取通过稿件并定时分发。

我通常会在每天早上设置一个定时任务，自动触发整套流水线跑一批选题。当天上午生成选题池，下午生成稿件，晚上审核，深夜自动排队发布。实际跑下来，从选题到审核完成，一篇千字左右的文章大约需要3-5分钟，而人工需要至少1-2小时。相当于说，这套系统一天24小时都在“值班”。

不过要注意，模型生成的稿件并非完全不需要人工介入。我在流水线末端保留了一个“人工抽检”环节，每天随机抽两篇已通过审核的稿件做终审。主要是确认系统标准有没有跑偏。因为审核Agent的标准来自配置，一旦配置规则或者提示词被调偏，整个流程可能在几小时内批量生产“合规但不合格”的内容，定期抽查是防止这种集体跑偏的唯一手段。

5. 常见问题与排障实录：这些坑我替你踩过了

5.1 问题一：Agent队列积压导致任务超时

现象：某天早上醒来，发现系统里积压了几百条“created”状态的任务，创作Agent一直没有消费。

排查过程：查看OpenClaw的日志后发现，创作Agent在等待模型服务返回时发生了超时。进一步定位发现是模型服务的并发连接数被占满了，而OpenClaw的全局并行度设置又比较激进，导致多个任务在排队等待同一个模型连接。

解决办法：限制单个Agent的最大并发数为1-2，同时调大模型服务的连接池容量。另外在消息队列中增加了一个“存活检测”机制，每条消息在超过120秒后自动重新入队，避免死等。

心得：多Agent系统的瓶颈往往不在Agent本身，而在底层的模型服务。提前为模型服务做好压力测试，比调优Agent参数更重要。

5.2 问题二：审核Agent把好稿子打回

现象：系统上线之后，发现审核不通过率奇高，差不多有一半稿件被判定为“可读性不足”。

排查过程：查看审核记录后发现，“可读性”维度的得分普遍偏低。去查审核Agent的提示词，发现我给了它一条“过于严苛”的示例规则：要求所有句子长度不超过35个字，并且禁止使用书面语中的长状语。这个规则其实是我在人工审稿时针对某一篇特殊文章设定的，结果被写成了通用规则。

解决办法：把审核标准配置化，分“严格模式”和“标准模式”。日常流水线使用标准模式，只有针对品牌合作或重点稿才切换到严格模式。同时提示词里更新了一段话：可读性判断应考虑文章类型和平台特性，而非绝对化的句子长度。

心得：审核规则一定要留“灰度空间”。完全规则化会杀死内容风格，完全模型化又会失去稳定性，这中间那个平衡点是通过调参试出来的。

5.3 常见问题速查表

问题现象	可能原因	快速处理
任务积压不消费	模型服务连接数满	降低并行度，扩大连接池
生成稿件质量突然下滑	模型服务切换版本或提示词被改动	回滚提示词，对比生成结果
审核结果不稳定	审核维度提示词中示例过多	精简示例，改为明确打分标准
重复选题频繁出现	历史内容库未及时更新	确认入库逻辑，检查去重键是否唯一
某平台发布时格式错乱	创作模板未适配平台要求	增加平台维度模板配置

这五个问题覆盖了我在实际运行中最常遇到的场景。说实话，每次跑问题的过程都远比搭框架本身费时间，但一套稳定的系统就是靠这些坑堆出来的。你不踩过一次队列积压，不会真正理解“并行度不是越大越好”；没有看过一次误打回的稿件，也不会知道“审核规则需要灰度”。所以遇到问题不用慌，打开日志，顺着任务状态和时间戳去追，大多数问题都能定位到某一个环节的配置上。

5.4 一条建议：把日志当方法论而不只是排查工具

多Agent系统的日志比传统单机任务要复杂得多。我现在的习惯是，每次调整系统，都先跑一批测试任务，观察日志中每个Agent的耗时分布和状态流转。如果发现某个Agent耗时异常，先别急着改代码，而是看它这个阶段处理的输入是不是有问题。有一次我发现创作Agent耗时忽高忽低，最后定位到是选题卡里某些字段值特别长，导致提示词超过了模型的最大上下文限制，触发了多次自动截断和重试。这种情况发生在跨Agent数据格式设计上，日志能直接反映出来。

6. 运行一段时间后的真实体会

这套OpenClaw多Agent协同系统跑了大概三个月之后，我最大感受是：自动化解放的不只是时间，更是注意力。以前我每天要反复切换“找选题”和“盯质量”两种思维模式，切换本身消耗巨大。现在流程是系统在跑，我只需要在每天早上花十分钟看一下昨日的选题池和审核报告，处理异常即可。内容产出的稳定性和数量都上去了，账号更新节奏从“挤牙膏”变成了“定时定量”。

但我也想说清楚，这套东西不是万能的。它擅长的是把已有方法论流程化、自动化，如果你自己的内容方向还没有跑通，或者在内容创作上完全没有个人观点，那单靠Agent也做不出有灵魂的内容。它有钢性约束：不编造事实、不输出没有数据支撑的论断、不允许语气夸张。这些约束是基于平台合规和账号长期信任积淀做的权衡——系统层面的安全底线必须高于一切，宁可效率低一点，也不能让审核Agent放过一条有风险的内容。

后面我还在考虑两个扩展方向。一是加入数据反馈回路，把发布后的阅读量、互动率回传到选题Agent，让它每周自动修正选题偏好；二是接入视觉素材Agent，让配图也能自动匹配选题卡的风格标签。这样整条内容流水线会更加闭环。不过这些都是后话了，先把核心链路跑稳，再考虑边际扩展。至少现在的状态，已经让我觉得“把内容生产当作一套工程来建设”这条路是走得通的。