Agent工坊

【Agent工坊】Hermes Agent delegate_task 多Agent协作实战:从零搭建内容创作流水线

一个主控Agent + 4个专职子Agent = 日产3篇深度文章的内容工厂。本文提供完整可复制的配置模板和代码。

为什么你需要多Agent流水线

单Agent写文章有三大硬伤:

  1. 上下文窗口爆炸 — 搜索→调研→大纲→写作→审核塞进一个会话,5000行对话后模型开始"遗忘"早期指令
  2. 角色混淆 — 同一个Agent既要当研究员又要当编辑,输出质量在"广度"和"深度"之间摇摆
  3. 无法并行 — 只能串行执行,调研完成才能写大纲,写完才能审,效率极低

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 3writer重新生成

三个关键踩坑

坑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触发。


行动建议

  1. 立即上手:复制上面的 delegate_task 代码,把 researcher 的 goal 改成你的赛道关键词,其他3个Agent直接复用
  2. 先跑通再优化:第一遍不要追求完美,确认4个Agent都能成功输出文件即可
  3. 评分阈值从严格开始:reviewer 的60分及格线不要下调——我们试过50分,结果是大量低质量文章蒙混过关
  4. 监控超时:writer 最容易超时,要有"超时但文件已写出"的处理逻辑

AI创业 #Agent工坊 #Hermes Agent #多Agent协作 #内容创作 #一人公司