别再手动写博客了：4 张卡片搞定素材到发布

凌晨 2 点，4 个 Agent 自动跑完了我一篇博客从素材收集到网站部署的全部流程。没有人工介入，也没有手动触发。

这不是 demo，是我跑了两周的真实流水线。

单 Agent 的天花板

用 Hermes Agent 写东西，最初就是一个人干所有活：选题、搜集素材、写稿、检查、发布。任务一多就暴露问题——上下文窗口塞不下，长文写到一半模型开始车轱辘话，或者干脆超时。

试过 delegate_task，它能在当前 session 里 fork 一个子 Agent 跑任务，跑完再 join 回来。短任务好用，一旦子任务需要几分钟甚至十几分钟，父 Agent 就卡在那等，超时了还得手动重跑。更麻烦的是，子 Agent 的记忆不持久，crash 了就彻底丢了。

我需要的是一套任务队列：把大任务拆成小卡片，每张卡片独立执行、独立留档。Kanban 就是干这个的。

Kanban 是什么

一句话说完：Hermes Kanban 是一个持久化的任务看板，存在 SQLite 里，让多个命名 Agent 协作完成任务。

跟 delegate_task 的核心区别：

底层是一张 SQLite 表，所有 Hermes profile 共享。每条任务有标题、分配人、状态（triage→todo→ready→running→blocked→done→archived）、依赖关系、评论线程。Dispatcher 长驻循环，自动回收超时任务、提升就绪任务、spawn 对应的 worker。

4 张卡片的博客流水线

我的流水线是 4 个任务串行的 pipeline：

T1: 素材收集    → T2: 撰写文章    → T3: 安全检查    → T4: 发布

每张卡片加载不同的 skill 组合：

• T1 加载 blog-topic-picker 和 dbs-content，做选题诊断和素材整理
• T2 加载 ruite-blog、humanizer-zh、dbs-ai-check、ian-xiaohei-illustrations，写稿 + AI 痕迹检测 + 配图
• T3 加载 blog-topic-picker，做敏感信息扫描
• T4 加载 ruite-blog、dbs-xhs-title、guizang-social-card-skill，做标题优化、封面设计、发布

创建方式是写一个 Python 脚本，用 CLI 命令逐个创建卡片并建立依赖链。核心逻辑大概是这样：

import subprocess, json

def kanban_create(title, assignee, body, skills, parent=None, workspace="scratch"):
    cmd = [
        "hermes", "kanban", "create", title,
        "--assignee", assignee,
        "--body", body,
        "--skill", ",".join(skills),
        "--workspace", workspace,
        "--json"
    ]
    if parent:
        cmd += ["--parent", parent]
    result = subprocess.run(cmd, capture_output=True, text=True)
    return json.loads(result.stdout)["task_id"]

# T1: 素材收集
t1 = kanban_create(
    "素材收集与选题诊断",
    assignee="writer-agent",
    body="收集素材，做五维选题诊断",
    skills=["blog-topic-picker", "dbs-content"],
    workspace="dir:~/articles/current"
)

# T2: 撰写（依赖 T1）
t2 = kanban_create(
    "撰写文章并自检",
    assignee="writer-agent",
    body="基于 T1 素材撰写，做 AI 痕迹检测和配图",
    skills=["ruite-blog", "humanizer-zh", "dbs-ai-check", "ian-xiaohei-illustrations"],
    parent=t1,
    workspace="dir:~/articles/current"
)

# T3: 安全检查（依赖 T2）
t3 = kanban_create(
    "安全检查",
    assignee="writer-agent",
    body="扫描敏感信息",
    skills=["blog-topic-picker"],
    parent=t2,
    workspace="dir:~/articles/current"
)

# T4: 发布（依赖 T3）
t4 = kanban_create(
    "标题优化与发布",
    assignee="writer-agent",
    body="优化标题，设计封面，部署网站，推送草稿箱",
    skills=["ruite-blog", "dbs-xhs-title", "guizang-social-card-skill"],
    parent=t3,
    workspace="dir:~/articles/current"
)

T1 完成后 dispatcher 自动把 T2 从 todo 提升到 ready，spawn worker 开始写稿。T2 完成后 T3 接上，以此类推。整个链路跑完，一篇文章就从零到部署好了。

workspace 参数决定 worker 能访问的目录。scratch 是临时目录，用完删；dir: 是共享持久目录，适合多张卡片需要读写同一份文件的场景。我这里用 dir:~/articles/current，因为 T2 需要读 T1 收集的素材，T4 需要读 T2 写好的文章。

不只是串行流水线

4 张卡片串行是最简单的模式。Kanban 支持更灵活的编排：

Fan-out + Fan-in（并行研究再综合）：

T1: 研究成本 (agent-A)  ──┐
                           ├── T3: 综合建议 (agent-B)
T2: 研究性能 (agent-A)  ──┘

T1 和 T2 同时跑，两者都完成后 T3 自动启动。设置方式就是把 T3 的 parents 设成 [T1, T2]。

Human-in-the-loop（人工审查卡点）：

T1: 实现功能 (engineer) → T2: 代码审查 (reviewer)

reviewer 发现需要人工判断时，调用 kanban_block(reason="需要确认 API 设计") 阻塞。人在 CLI 或 Dashboard 上看完后执行 hermes kanban unblock <task_id>，worker 继续执行。

Goal Mode（目标驱动的长任务）：

kanban_create(
    title="翻译整个文档站为法语",
    body="验收标准：每页翻译完成，无英文残留，链接完整",
    assignee="translator-agent",
    goal_mode=True,
    goal_max_turns=15
)

worker 在目标循环里反复执行，每轮由 judge 评估是否达标，没达标且还有预算就继续，预算耗尽就 block 等人看。

踩坑记录

跑了两周，踩过几个比较有代表性的坑：

1. Profile 名写错，卡片永远停在 ready

dispatcher 不会纠正不存在的 assignee 名。卡片创建了，状态永远是 ready，不会有人来领。创建卡片前先跑一遍 hermes profile list 确认目标 profile 存在。

2. 下游 Worker 看不到上游的上下文

这是最容易犯的错误。Kanban worker 是独立 session，T2 的撰写者不知道 T1 收集者具体做了什么、输出了什么。上下文传递靠两样东西：

• 磁盘文件（主要通道，可靠）
• 卡片的 body 和 comments（补充，放简要 metadata）

所以 workspace 要用 dir: 共享目录，让前一张卡片把产出写到固定位置。不要假设下一个 worker “看到”了上一个的 kanban_summary。

3. 在 body 里用散文写依赖关系

如果 T2 依赖 T1，必须用 parents=[T1] 建立链接。光在 body 里写”等 T1 完成后再做”没用，dispatcher 不会解析自然语言里的依赖。

4. Worker 不是交互式 session

Worker 无人值守。它不能弹出问题问你。需要人工判断时，worker 应该用 kanban_comment 写清楚情况，然后 kanban_block(reason="...") 阻塞等人介入。

还能更猛

我自己的 4 卡片流水线是比较保守的用法。YouTube 频道 Tonbi’s AI Garage 展示了一个 18 Agent 并行的工作流：scout Agent 搜痛点，orchestrator 评分筛选，3 个 researcher 并行验证，builder 出工具，tester 做测试，最后 Telegram 通知人工审批。一次运行完成 97 个任务，系统自己修好了一个坏掉的交付物。模板开源于 GitHub。

对比来看，Kanban 适合的任务规模可以从 2-3 张卡片的简单流水线，扩展到几十个 Agent 的复杂编排。核心都是同一套：拆任务、建依赖、自动调度、持久记录。

几个实用的 CLI 命令

日常操作用这几个就够了：

# 查看当前看板所有任务
hermes kanban list

# 实时跟踪某个任务的日志
hermes kanban tail <task_id>

# 手动回收卡住的任务
hermes kanban reclaim <task_id>

# 给任务加备注
hermes kanban comment <task_id> "这里需要检查一下"

# 诊断看板状态
hermes kanban diagnostics

也可以不写代码，直接在 CLI 里创建完整流水线：

hermes kanban create "素材收集" --assignee writer --skill blog-topic-picker,dbs-content --json
hermes kanban create "撰写文章" --assignee writer --parent <t1_id> --skill ruite-blog,humanizer-zh --json

如果你的环境支持 Docker Compose，可以把 dispatcher 作为常驻服务编排，避免手动启动。我的环境比较老，用的是单容器 docker run 方式跑 gateway，效果一样，只是管理上不如 compose 优雅。

写在最后

Kanban 不是什么新发明，就是把项目管理里的看板搬到了 AI Agent 协作场景里。但它解决了一个真实问题：当单个 Agent 的上下文和算力不够用时，怎么把任务拆开、分出去、收回来。

我现在写博客的流程已经基本自动化了。人工做的只剩选题决策和最终审稿。如果你也在用 Hermes Agent，建议从最简单的 2 卡片 pipeline 试起：一个收集素材，一个写稿。跑通了再加检查、发布这些环节。

参考链接：
- Hermes Agent 官方文档 - Kanban
- Tonbi 的 18 Agent 工作流（YouTube）
- Tonbi 开源模板（GitHub）