Hermes Kanban 多Agent协作

多Agent协作实战：从写稿到审核的完整Pipeline

一篇AI对比文章，4个Agent接力完成，10步Pipeline自动跑通。中间经历3轮审核修复循环，全程1.5小时零人工介入。完整解析4个Agent分工、依赖链机制、质量门禁设计和模型分级省钱策略。

一篇AI对比文章，4个Agent接力完成，10步Pipeline自动跑通。中间经历3轮审核修复循环，全程1.5小时零人工介入。

先说结论

我们搭了一套多Agent协作的写作Pipeline。

4个专职Agent：写作、审核、博客部署、公众号发布，各司其职。

10步自动流水线：从第一行字写出来，到博客上线、公众号草稿就绪，全自动。

质量门禁：审核不通过，下游任务直接卡住，修好了才放行。

这是系列第3篇。第1篇讲了Kanban+Profile架构，第2篇搭了单个Writer Agent。

这篇是多Agent协作的完整实战——怎么让4个Agent接力干活、互相检查、自动修复。

1. 4个Agent怎么分工

先看全局。每个Agent有自己的Profile（身份配置）和SOUL.md（行为规范）。

Agent职责模型特点
blog-writer写原始文章glm-5.1204K上下文，有记忆
reviewer审核内容质量glm-5.1只审不改，无记忆
blog-creator转Markdown+部署glm-4.7最精简工具集
mp-creator转公众号HTML+上传glm-4.74个微信skill

类比：像一个编辑部——

  • ◆ Writer是记者，负责采访写稿
  • ◆ Reviewer是编辑，负责审稿把关
  • ◆ Creator是排版员，负责报纸和网站两个渠道的排版

注意模型选择：写作和审核用强模型(glm-5.1)，格式转换用弱模型(glm-4.7)。

为什么？格式转换是机械活，不需要创造力。省下来的Token是真金白银。

2. Pipeline全景：10步流水线

 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

  ① blog-writer           ② reviewer              Fan-out
  ┌──────────────┐       ┌──────────────┐      ┌─────────────────┐
  │ 写原始文章    │──────▶│ 内容审核      │──PASS│ 并行分发          │
  │ (glm-5.1)    │ 7min  │ PII/事实/AI味 │12min └──────┬──────────┘
  └──────────────┘       └──────────────┘             │
                                          ┌───────────┴───────────┐
                                          ▼                       ▼
                               ③ blog-creator          ④ mp-creator
                               ┌──────────────┐       ┌──────────────┐
                               │ Markdown+部署 │       │ HTML+封面+上传│
                               │ (glm-4.7)    │       │ (glm-4.7)    │
                               └──────┬───────┘       └──────┬───────┘
                                      │                      │
                                      ▼                      ▼
                               ⑤ reviewer              ⑥ reviewer
                               ┌──────────────┐       ┌──────────────┐
                               │ Blog格式审核   │       │ 公众号格式审核 │
                               └──────┬───────┘       └──────┬───────┘
                                  PASS ✅                   FAIL ❌
                                      │                      │
                                      ▼                      ▼
                                 博客上线          ┌──────────────────┐
                                                  │ ⟳ 审核修复循环×3轮 │
                                                  │ ⑦修复→⑧审核→⑨修复 │
                                                  │ →⑩审核 PASS ✅    │
                                                  └──────────────────┘

解释一下关键节点：

  • ◆ Step ①②：Writer写完文章，交给Reviewer审核内容
  • ◆ Fan-out：审核通过后，同时派给Blog和公众号两个渠道
  • ◆ Step ③④：两个Creator并行工作，互不等待
  • ◆ Step ⑤⑥：各自的Reviewer再审一遍格式
  • ◆ Step ⑦-⑩：公众号没过，进入修复循环

Blog那边一次通过，公众号那边经历了3轮修复。为什么？

因为公众号对段落长度有严格限制（每段≤100字），模型对"手机屏幕3行"的物理感知不够精确。

3. 依赖链：怎么让Agent自动接力

核心机制是Kanban的parents依赖。

创建任务时指定parents，意思是：“等这些父任务完成后，我才启动”。

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

# 创建Writer任务
kanban_create(title="写对比文章", assignee="blog-writer")

# 创建Reviewer任务，依赖Writer
kanban_create(title="审核内容", assignee="reviewer",
    parents=["t_writer_xxx"])

# 创建两个Creator任务，依赖Reviewer
kanban_create(title="部署博客", assignee="blog-creator",
    parents=["t_reviewer_xxx"])
kanban_create(title="公众号推文", assignee="mp-creator",
    parents=["t_reviewer_xxx"])

注意看最后两行——它们的parents是同一个Reviewer任务。

这意味着Reviewer通过后，Blog和公众号同时启动。

这就是Fan-out（扇出）：一个任务完成，触发多个下游并行执行。

4. 质量门禁：FAIL就卡住

Reviewer不是走过场。它有5级审核维度，每级有明确的通过标准：

优先级检查项判定标准
🔴 必须通过PII信息脱敏手机号/邮箱/IP必须处理
🔴 必须通过事实准确性数据有来源，技术描述正确
🟡 3处FAILAI味检测废话铺垫/过度道歉/套话
🟢 仅建议品牌名不强制，给出建议
🔵 格式规范平台适配Blog/公众号各有专项检查

关键机制：Reviewer判定FAIL时，在kanban_complete的metadata里写入问题列表。

下游任务的parents依赖没满足，不会自动启动。

必须创建修复任务，修好后再提交审核。这就是"门禁"——

不是标记一下就过了，是真的挡住，修好才放行。

5. 实战：3轮修复循环

说说真实发生的事。

第一轮公众号HTML生成后，Reviewer发现11个段落超标（限制100字/段）。

其中3个段落超过150字，在手机上会显示成一大坨。

mp-creator收到问题列表，拆分段落。

Reviewer二轮审核——还有5段超标。继续修。

第三轮审核——91个段落全部≤100字，PASS。

整个过程零人工介入。Reviewer自动FAIL，mp-creator自动读问题列表修复。

从第一次FAIL到最终PASS，修复循环自动跑了3轮。

教训：模型对"手机屏幕3行=100字"这种物理约束，理解不够精确。需要多轮迭代。

6. 模型分级：省钱的关键

4个Agent不是都用最贵的模型。按职责复杂度分级：

职责模型为什么
原创写作glm-5.1（强）需要创造力和上下文
内容审核glm-5.1（强）找错需要精确理解
格式转换glm-4.7（省）机械任务，够用即可
辅助工具glm-4.5-air（最省）压缩/搜索等轻量任务

实际效果：写作和审核两个最关键的环节用强模型保证质量。

格式转换这种"体力活"用弱模型，成本直接砍半。

而且reviewer在下游兜底，弱模型出了问题也能被拦截。

7. 搭建要点回顾

如果你也想搭这样的Pipeline，关键步骤：

  • ◆ Step 1：为每个角色创建独立Profile
  • ◆ Step 2：写SOUL.md定义行为规范
  • ◆ Step 3：配置review skill的审核checklist
  • ◆ Step 4：用kanban的parents参数搭建依赖链
  • ◆ Step 5：按职责复杂度分配模型

最关键的设计决策是质量门禁。

没有它，Agent就是各干各的，错误会一路传到最终发布。

有了它，每个环节都有人把关，问题在传播之前就被拦截。

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

多Agent协作系列第3篇 · 第4篇将分享踩坑最佳实践