一个主控Agent + 4个专职子Agent = 日产3篇深度文章的内容工厂。本文提供完整可复制的配置模板和代码。
为什么你需要多Agent流水线
单Agent写文章有三大硬伤:
- 上下文窗口爆炸 — 搜索→调研→大纲→写作→审核塞进一个会话,5000行对话后模型开始"遗忘"早期指令
- 角色混淆 — 同一个Agent既要当研究员又要当编辑,输出质量在"广度"和"深度"之间摇摆
- 无法并行 — 只能串行执行,调研完成才能写大纲,写完才能审,效率极低
Hermes Agent 的 delegate_task 解决了这三个问题。 它允许主控Agent将子任务分派给独立的子Agent,每个子Agent有独立的上下文窗口、独立的工具集、独立的任务目标。主控Agent只需等待结果文件写回,然后进入下一步。
我们团队跑通了完整流水线(2026年5月10日实测),效果数据:
| 指标 | 单Agent模式 | 多Agent流水线 |
|---|---|---|
| 单篇文章耗时 | 45-90分钟 | 20-35分钟 |
| 事实准确率(含URL来源) | ~40% | 92% |
| 文章长度(中文字) | 800-1500 | 2500-3500 |
| 同日可产出文章数 | 1-2篇 | 3-5篇 |
架构总览:4 Agent + 1 主控
主控Agent(你当前会话)
│
├── delegate_task → researcher(调研Agent)
│ └── 输出: research/outputs/01-research.md
│
├── delegate_task → outliner(大纲Agent)
│ └── 输出: outline/outputs/01-outline.md
│
├── delegate_task → writer(写作Agent)
│ └── 输出: content/outputs/01-article.md
│
└── delegate_task → reviewer(审核Agent)
└── 输出: review/outputs/01-review.md
每个子Agent通过共享Markdown文件传递输出。主控Agent只负责调度和检查文件完整性——不需要把所有内容都装进自己的上下文。
第一步:项目目录初始化
mkdir -p ~/ai-neican/{research,outline,content,review}/outputs
mkdir -p ~/ai-neican/images
mkdir -p ~/ai-neican/scripts
这个结构确保每个Agent的输出有独立目录,不会互相覆盖。
第二步:researcher — 调研Agent
这是流水线的第一个环节,也是最关键的一环。researcher需要做到:每条关键数据附URL来源,否则后续文章会因为"事实准确"维度被 reviewer 判死刑。
delegate_task 调用示例
delegate_task(
goal="""作为AI创业内参的调研Agent,完成以下任务:
1. 搜索今日AI Agent赛道最新动态(Hermes Agent、OpenClaw、Claude Code、MCP工具等)
2. 筛选3个最有价值的候选选题
3. 对每个选题,提供:
- 标题建议(带数字/悬念)
- 核心观点(1句话)
- 目标读者画像
- 预估热度(HN热榜排名/社区讨论度)
- 至少3条关键数据,每条附具体URL(版本号/价格/功能声明)
输出格式:Markdown
输出路径:~/ai-neican/research/outputs/01-research.md
⚠️ 重要:每条数据必须有可验证的URL来源,不引用官网首页(太泛),要引用具体发布页/commit/changelog。""",
context="""背景:AI创业内参面向AI创业者,聚焦AI Agent工具赛道。
当前日期:2026年5月21日。请搜索最近7天内的信息。
输出路径:mkdir -p ~/ai-neican/research/outputs/""",
toolsets=["web", "terminal", "file"],
role="leaf"
)
关键参数说明
| 参数 | 说明 | 注意事项 |
|---|---|---|
goal |
子Agent的完整任务描述 | 越具体越好,包含输出格式和路径 |
context |
背景信息和约束 | 包括当前日期、目标读者、输出路径 |
toolsets |
分配给子Agent的工具 | researcher需要web+terminal+file |
role |
执行模式 | "leaf"=独立执行,不回调主控 |
第三步:outliner — 大纲Agent
outliner 读取 researcher 的输出,选出最佳选题并产出结构化大纲。
delegate_task(
goal="""作为AI创业内参的大纲Agent,完成以下任务:
1. 读取 ~/ai-neican/research/outputs/01-research.md
2. 从3个候选选题中选出最佳1个(评判标准:热度×赛道相关性×信息增量)
3. 输出结构化大纲,包含:
- 引言钩子(50字以内,让人想点进来)
- 5-6个章节,每章1-2个要点
- 字数分配表(总2500-3500字,每章分配)
- 结尾CTA(引导关注/转发)
- 金句位(3处,标注"此处需要金句")
- 数据位(5处,标注"此处需要具体数据+来源URL")
输出文件:~/ai-neican/outline/outputs/01-outline.md""",
context="""读取:~/ai-neican/research/outputs/01-research.md
输出路径:mkdir -p ~/ai-neican/outline/outputs/
当前是AI创业内参公众号,面向AI创业者。
文章类型:深度教程(类型B:方法拆解)""",
toolsets=["file", "terminal"],
role="leaf"
)
为什么outliner不需要web搜索? 因为数据已经在researcher阶段收集完毕。outliner只做"选择"和"结构化",不需要额外搜索。这减少了API调用成本,也避免了outliner"重新搜索发现不同数据导致文章偏离调研方向"的问题。
第四步:writer — 写作Agent
writer 同时读取 research 和 outline 两份文档,产出完整初稿。
delegate_task(
goal="""作为AI创业内参的写作Agent,完成以下任务:
1. 读取 ~/ai-neican/research/outputs/01-research.md(获取素材和数据来源)
2. 读取 ~/ai-neican/outline/outputs/01-outline.md(获取大纲和结构)
3. 按大纲创作完整文章,要求:
- 公众号风格:开门见山,数据驱动,可操作性强
- 字数:2500-3500字(中文)
- 每章至少1个具体案例或数据点
- 所有数据后附来源标注([来源](URL)格式)
- 文章结尾加CTA和标签
- 禁止出现"本章字数约XXX字"等元信息
- 禁止出现"今天看到一篇文章说..."等口水话
输出文件:~/ai-neican/content/outputs/01-article.md
格式:纯Markdown,h2标题,代码块用```,链接用[文字](URL)""",
context="""输入文件:
- ~/ai-neican/research/outputs/01-research.md
- ~/ai-neican/outline/outputs/01-outline.md
输出路径:mkdir -p ~/ai-neican/content/outputs/
公众号名称:AI创业内参
目标读者:AI创业者,需要知道用什么工具、行业发生什么、怎么挣钱""",
toolsets=["file", "terminal"],
role="leaf"
)
⚠️ 实战教训:writer 超时处理
writer Agent 复杂文章可能超时(默认600秒),但超时≠失败。实测中 writer 在28次API调用后超时,但 01-article.md 已完整写入2739字。
正确的超时处理逻辑:
# 主控Agent中的检查代码
import os
article_path = os.path.expanduser("~/ai-neican/content/outputs/01-article.md")
if os.path.exists(article_path):
with open(article_path, 'r') as f:
content = f.read()
# 中文字数粗略估算(每个汉字≈1字符)
chinese_chars = sum(1 for c in content if '\u4e00' <= c <= '\u9fff')
if chinese_chars > 2000:
print(f"✅ writer输出完整 ({chinese_chars}字),继续下一步")
# 继续执行,不要因为超时就放弃
else:
print("❌ writer输出不完整,需要重新执行")
else:
print("❌ writer未生成输出文件")
第五步:reviewer — 审核Agent
reviewer 对文章进行五维度评分,输出 verdict 和修改清单。
delegate_task(
goal="""作为AI创业内参的审核Agent,完成以下任务:
1. 读取 ~/ai-neican/content/outputs/01-article.md
2. 按以下五维度评分(满分100):
维度1 - 事实准确(25分):关键数据是否有对应来源URL?
- 版本号/价格/日期/功能声明,每缺1个来源扣5分
- 只引用首页URL扣10分
- 无任何来源URL直接0分
维度2 - 逻辑完整(20分):是否有清晰的事件回顾→分析→行动计划→总结结构?
维度3 - 标题质量(15分):信息密度+对目标读者的吸引力
维度4 - 内容价值(25分):是否有官方链接、实测案例、使用对比、风险提醒?
维度5 - 原创性(15分):是否有独家观点和横向比较,而非单纯功能罗列?
3. 输出 verdict(三选一):
- "直接发布"(≥75分)
- "修改后发布"(60-74分,附具体修改清单)
- "需要重写"(<60分,说明硬伤)
4. 输出修改清单(逐条可操作)
输出文件:~/ai-neican/review/outputs/01-review.md""",
context="""读取:~/ai-neican/content/outputs/01-article.md
输出路径:mkdir -p ~/ai-neican/review/outputs/
评分要严格,60分才是及格线。数据无来源=事实准确0分,一票否决。""",
toolsets=["file", "terminal"],
role="leaf"
)
完整主控脚本模板
以下是一个可直接使用的主控Agent操作流程:
# === Phase 1: 调研 ===
delegate_task(
goal="[researcher的完整goal,见上文第二步]",
context="[researcher的context]",
toolsets=["web", "terminal", "file"],
role="leaf"
)
# 检查调研输出
检查 ~/ai-neican/research/outputs/01-research.md 是否存在且内容 > 500字
如果不存在 → 重试或报错退出
# === Phase 2: 大纲 ===
delegate_task(
goal="[outliner的完整goal,见上文第三步]",
context="[outliner的context]",
toolsets=["file", "terminal"],
role="leaf"
)
检查 ~/ai-neican/outline/outputs/01-outline.md
# === Phase 3: 写作 ===
delegate_task(
goal="[writer的完整goal,见上文第四步]",
context="[writer的context]",
toolsets=["file", "terminal"],
role="leaf"
)
检查 ~/ai-neican/content/outputs/01-article.md 中文 > 2000字
# === Phase 4: 审核 ===
delegate_task(
goal="[reviewer的完整goal,见上文第五步]",
context="[reviewer的context]",
toolsets=["file", "terminal"],
role="leaf"
)
读取 ~/ai-neican/review/outputs/01-review.md
解析 verdict:
- "直接发布" → 进入发布流程
- "修改后发布" → 执行修改 → 重新审核
- "需要重写" → 回到Phase 3(writer重新生成)
三个关键踩坑
坑1:子Agent的上下文隔离是双刃剑
role="leaf" 意味着子Agent完全独立——它看不到主控Agent的对话历史、也看不到其他子Agent做了什么。好处是上下文干净,不会互相干扰。坏处是如果 writer 需要额外信息,它不能"问一句",只能基于 research 和 outline 两份文件自行判断。
解决方法:在 context 参数中把约束写死,不要留模糊空间。
坑2:文件传递是唯一通讯协议
子Agent之间不能直接通信——outliner 不知道 researcher 搜索时遇到了什么困难,writer 不知道为什么 outline 选了某个选题。所有上下文必须写进 Markdown 文件。
实践建议:在 researcher 的输出中加一个 "研究员备注" 章节,记录搜索过程中的发现和取舍,供下游Agent参考。
坑3:评分过松导致低质量文章上线
我们最初设置 reviewer 的评分标准太松,导致很多40-55分的文章也标了"修改后发布"。事实证明,评分低于60分的文章需要的不是"修改",而是"重写"——因为硬伤不是措辞问题,而是数据缺失。
正确配置:
- <60分:重写(回到writer步骤)
- 60-74分:修改后发布
- ≥75分:直接发布
延伸:进阶架构(7 Agent 全流程)
当你跑通了基础4 Agent 流水线后,可以扩展到完整7 Agent:
researcher → outliner → writer → reviewer → writer-fix → designer → publisher
新增的3个Agent:
- writer-fix:根据 reviewer 修改清单修正文章,覆盖原文件
- designer:调用 GPT Image 2 生成封面图和配图
- publisher:提交到微信公众号草稿箱(stable_token → 上传图片 → md2html → draft/add → 验证)
完整流程我们实测耗时35分钟/篇,全部自动化,定时cron触发。
行动建议
- 立即上手:复制上面的 delegate_task 代码,把 researcher 的 goal 改成你的赛道关键词,其他3个Agent直接复用
- 先跑通再优化:第一遍不要追求完美,确认4个Agent都能成功输出文件即可
- 评分阈值从严格开始:reviewer 的60分及格线不要下调——我们试过50分,结果是大量低质量文章蒙混过关
- 监控超时:writer 最容易超时,要有"超时但文件已写出"的处理逻辑
