AI Agent 不是聊天框：用 Hermes Kanban 搭一条内容生产流水线

全文约 5200 字，阅读约需 12 分钟。适合已经装好 Hermes Agent，想让多个 AI 分工干活的新手。

本文写于 2026 年 5 月 20 日，主要参考 Hermes Agent 官方文档：Kanban tutorial、Kanban Multi-Agent Board、Kanban worker lanes。后续如果命令更新，请以官方文档为准。

Hello 大家好，我是老麦克。

今天我们继续聊 Hermes。

上一篇我们聊的是怎么把 Hermes 装进自己的电脑。

装完以后，很多人的第一反应是：

“不错，可以在终端里和 AI 聊天了。”

但说实话，如果你只是把 Hermes 当成另一个聊天框，那就有点浪费了。

这就像你买了一艘船，结果只拿它在浴缸里划。

能划。

但属实有点委屈它。

Hermes 真正有意思的地方，不是“你问一句，它答一句”。

而是你可以开始管理 AI 做事。

今天要讲的 Hermes Kanban，就是这个能力里特别关键的一块。

你可以把它理解成：

给一群 AI 员工准备的一块任务看板。

你把任务扔上去。

谁负责需求，谁负责开发，谁负责测试，谁负责审核。

每个人干到哪一步，卡住了没有，重试过几次，改了哪些文件，跑了哪些测试。

全都留在看板里。

不是靠你脑子记。

不是靠聊天记录翻。

更不是靠“我感觉它刚才好像做完了”。

而是落到一张 SQLite 数据表里。

对，就是这么朴素。

但很多真正能用的工具，底层都很朴素。

关键不在于它炫不炫。

关键在于它能不能帮你把活干完。

[封面图建议：AI 员工围着一块 Kanban 看板分工干活，标题后期叠加“别再让 AI 排队干活”。详见 media-plan.md]

01 先说结论：Kanban 不是普通待办清单

很多人听到 Kanban，会想起 Trello、飞书多维表格、Notion 看板。

一列待办。

一列进行中。

一列完成。

拖来拖去。

看起来很有生产力。

结果月底一看，全是“待整理”“待复盘”“待开始”。

收藏夹换了个皮而已。

Hermes Kanban 不一样。

它不是给你一个漂亮的任务清单，让你假装很忙。

它是给 AI Agent 用的协作底座。

说人话：

普通 Kanban 是人看的。

Hermes Kanban 是人和 AI 一起用的。

这里面有几个关键角色。

第一，Board。

就是看板本身。默认看板的数据放在：

~/.hermes/kanban.db

如果你创建多个项目看板，每个看板会有自己的数据库、工作目录和日志目录。

这意味着不同项目可以隔离，不会全都搅成一锅粥。

第二，Task。

就是一张任务卡片。

它有标题、描述、负责人、状态、优先级、父子依赖、评论、运行记录。

状态大概是这些：

triage -> todo -> ready -> running -> blocked / done / archived

不用一上来背。

先理解成一条流水线就行。

第三，Profile。

在 Hermes 里，一个 profile 就像一个 AI 员工身份。

你可以有一个 backend profile，专门干后端。

也可以有一个 qa profile，专门写测试。

还可以有一个 reviewer profile，专门审代码。

它们不是抽象概念。

它们是真正会被 Hermes dispatcher 启动起来的独立工作进程。

第四，Dispatcher。

这是最像“工头”的东西。

它会定期扫描看板，发现 ready 状态的任务，就把对应的 profile 拉起来干活。

官方默认是每 60 秒扫一次。

如果你打开 Dashboard，也可以点一下 Nudge dispatcher，让它立刻调度一轮。

第五，Run。

这点很重要。

一个任务不是只有“做没做完”。

它可能第一次做失败了。

第二次被人补充信息后重试。

第三次才通过。

每一次尝试，Hermes 都会记录成一条 run。

这就比普通聊天强太多了。

普通聊天里，AI 第一次失败，第二次你让它改，它经常忘了自己为什么失败。

Hermes Kanban 里，失败原因、阻塞原因、上一次尝试的结果，会留在任务上下文里。

下一次 worker 打开任务时能看到。

这就是“别重复踩坑”的基础。

02 它到底解决什么痛点？

我们先别急着敲命令。

先说为什么需要它。

很多人用 AI Agent 做开发，会遇到一个特别尴尬的问题：

AI 能做事。

但它通常是单线程做事。

你让它改一个功能。

它开始看代码、写代码、跑测试、修 bug。

你在旁边等。

等它搞完，你再让它写文档。

再等。

再让它 review。

继续等。

这不叫团队协作。

这叫你雇了一个全能实习生，然后让它从早到晚一个人排队干活。

更麻烦的是，一旦任务复杂起来，你会发现聊天窗口不是一个好项目管理工具。

比如一个功能开发，真实流程可能是：

产品先写需求。

后端设计接口。

前端接页面。

测试补用例。

Reviewer 看安全风险。

中间有人卡住了，还要问你一句：

“这个登录 token 是 15 分钟过期，还是 7 天过期？”

如果全放在一个聊天窗口里，最后就是一坨麻线。

Hermes Kanban 的价值就在这里。

它把“聊天”变成了“流程”。

你不是一直追着 AI 问：

“你做完了吗？”

“你刚才改了啥？”

“你怎么又忘了？”

你是把任务拆成卡片。

让不同 profile 去接。

让依赖关系自动推进。

让失败和阻塞都留下记录。

一句话：

delegate_task 像临时叫同事帮你看一眼。

Kanban 像给一个项目搭了工作流。

短任务、临时研究、父 Agent 需要等子 Agent 答案再继续，用 delegate_task 就很好。

但如果任务要跨角色、跨时间、要重试、要人类介入、要留下审计记录，那就该用 Kanban。

别拿菜刀开椰子。

工具要按场景用。

03 新手先准备什么？

这篇文章默认你已经装好了 Hermes。

如果你还没装，先去看前一篇 Hermes 安装教程。

这里不重复安装全流程。

但有几个前提要确认。

macOS 用户

在终端里确认 Hermes 能跑：

hermes --version
hermes doctor

如果能看到版本号，并且 doctor 没有严重错误，就可以继续。

你的项目目录建议放在类似这里：

/Users/你的用户名/dev/myapp

后面所有 dir: 工作区路径都要用绝对路径。

不要写相对路径。

不要写 ../myapp。

这点官方文档强调过，因为 dispatcher 启动 worker 时，当前目录不一定是你以为的那个目录。

相对路径容易出幺蛾子。

Windows 用户

Windows 用户请在 WSL2 的 Ubuntu 里操作。

不要在原生 PowerShell 里硬跑这套命令。

你的项目目录建议放在 WSL 里面，比如：

/home/你的用户名/dev/myapp

不要一会儿 Windows 路径，一会儿 Linux 路径。

命令行不是鸳鸯锅。

别混。

准备几个 profile

Kanban 要好用，最好先准备几个角色。

比如我们后面的开发案例，会用到四个：

pm：负责把需求写清楚。

backend：负责后端开发。

qa：负责测试。

reviewer：负责审查。

第一次可以这样创建：

hermes profile create pm --clone --description "负责把模糊需求拆成清晰规格、验收标准和边界条件。"
hermes profile create backend --clone --description "负责后端代码、接口实现、数据库迁移和自动化测试。"
hermes profile create qa --clone --description "负责测试计划、边界用例、回归测试和质量检查。"
hermes profile create reviewer --clone --description "负责代码审查、安全风险、可维护性和合并前检查。"

如果你已经有这些 profile，就不用重复创建。

想改描述，可以用：

hermes profile describe backend --text "负责后端代码、接口实现、数据库迁移和自动化测试。"

为什么 description 重要？

因为 Kanban 的自动拆解器会看 profile 描述，再决定任务该派给谁。

你不给描述，它也不是不能用。

但就像公司里新来了几个同事，名片上只写“张三”“李四”。

谁会写代码，谁会做测试，谁会写文档？

不知道。

那派活就容易乱。

04 先把看板跑起来

最小启动流程很简单。

先初始化 Kanban：

hermes kanban init

然后打开 Dashboard：

hermes dashboard

浏览器里打开后，左侧会有 Kanban 标签。

你可以在里面看到任务列、负责人、状态、评论、运行记录。

如果你希望任务真的被 worker 自动捡起来干活，还要启动 gateway：

hermes gateway start

这里新手最容易搞混。

Dashboard 是给你看的。

Gateway 里带着默认 dispatcher，负责调度任务。

也就是说：

只开 Dashboard，你能看任务。

开了 Gateway，任务才会按规则被 worker 接走。

官方现在推荐用 gateway 内置 dispatcher。

老的 hermes kanban daemon 已经不推荐了。

别两个一起跑。

两个工头抢一张派工单，最后不是提高效率，是制造灵异事件。

你也可以用 CLI 看看当前任务：

hermes kanban list
hermes kanban stats
hermes kanban watch

watch 很适合观察现场。

它会持续显示任务事件，比如 created、claimed、completed、blocked、gave_up。

如果你只关心失败和完成，可以这样看：

hermes kanban watch --kinds completed,gave_up,timed_out,blocked

05 小白版流程：一张卡片是怎么被 AI 做完的？

我们用最简单的任务来理解。

你创建一张卡：

hermes kanban create "整理项目 README 的安装步骤" \
  --assignee reviewer \
  --body "检查 README 的安装步骤是否完整，补充缺失的命令和常见报错。"

这时任务进入看板。

如果它有 assignee，而且没有未完成的父任务，它会进入 ready。

dispatcher 下一轮扫描到它，就会启动 reviewer 这个 profile。

注意，这里 worker 不是在终端里运行 hermes kanban show。

官方文档明确说了：

人类用 CLI、Dashboard、slash command 操作看板。

worker 用 kanban_* 工具操作看板。

worker 的典型动作大概是这样：

# 这是 worker 的工具调用，不是你要复制的命令
kanban_show()
# 读取任务标题、描述、父任务结果、历史尝试、评论线程

# worker 使用 terminal/file/search 等工具做真实工作

kanban_heartbeat(note="已检查 README，正在补充常见报错")

kanban_complete(
    summary="补充了安装步骤、环境要求和两个常见报错处理方法",
    metadata={
        "changed_files": ["README.md"],
        "verification": ["手动检查 Markdown 渲染"],
        "residual_risk": ["未在 Windows WSL2 上实测"]
    }
)

这段你不用背。

你只要理解一件事：

Kanban 不是让 AI 假装点了个“完成”。

它要求 worker 最后必须明确终结任务。

要么 complete。

要么 block。

如果 worker 什么都不调用，直接退出，Hermes 会认为这是协议违规或失败。

这很好。

因为真实工作里，最烦的就是那种“我好像干完了但没交接”的同事。

Kanban 不吃这一套。

06 开发案例：用 Kanban 管老麦的公众号文章生产流水线

下面我们不拿那种通用功能做案例。

太通用了。

看着像教程，落到自己身上没感觉。

这次直接拿老麦自己的真实场景举例：

公众号文章生产。

更具体一点，是这条流水线：

选题确认 -> 资料抓取 -> 初稿改写 -> 三轮审校 -> 媒体计划 -> 最终交付

你可能会说：

“这不是写文章吗？怎么变成开发案例了？”

我告诉你，这恰恰是最适合普通人理解 AI Agent 的开发案例。

因为它不是单纯写一篇文章。

它背后有文件目录。

有 Skill。

有素材库。

有风格档案。

有审核清单。

有输出文件。

有版本迭代。

这就是一个轻量级内容生产系统。

不比写一个登录按钮低级。

甚至更贴近很多普通人的真实需求。

这次我们假设项目目录就是老麦正在用的公众号写作助手：

PROJECT="/Users/mike/.hermes/skills/chenchen913~wechat-article-writer-cc"

目标也很明确：

给这个写作助手增加一条“Kanban 教程文章生产流水线”。

最后要交付三个东西：

1. 公众号排版版完整稿
2. 媒体资源计划 media-plan.md
3. 文章概要卡 summary-card.md

这不就是今天我们正在干的事吗？

对。

直接拿真活举例。

别老拿教程界的五花肉来糊弄自己。

第一步：准备几个 profile

我们先准备几个角色。

这次不叫 backend、qa、reviewer 了。

换成内容生产更贴近的名字：

hermes profile create researcher --clone --description "负责资料抓取、官方文档核验、外部案例搜索和事实来源整理。"
hermes profile create writer --clone --description "负责按老麦克风格写公众号文章，擅长口语化表达和技术人话翻译。"
hermes profile create editor --clone --description "负责三轮审校：事实、风格、格式，重点去 AI 味和移动端阅读体验。"
hermes profile create media --clone --description "负责封面图、正文配图、视频脚本和媒体资源清单。"

如果你已经有这些 profile，不用重复创建。

可以只更新描述：

hermes profile describe writer --text "负责按老麦克风格写公众号文章，擅长口语化表达和技术人话翻译。"

这里的重点不是名字有多高级。

重点是角色边界要清楚。

researcher 不写全文。

writer 不负责核所有事实。

editor 不重新发明选题。

media 不乱改正文观点。

这就叫分工。

第二步：创建专属看板

我们给这条文章生产线单独建一个 board：

hermes kanban boards create laomai-content \
  --name "老麦内容生产线" \
  --description "公众号文章从资料抓取到最终交付的 Kanban 工作流" \
  --switch

确认当前 board：

hermes kanban boards show

这样做的好处是，内容生产任务不会和其他开发任务混在一起。

你不会在一个看板里同时看到：

“修复 API 鉴权 bug”。

“生成 Hermes Kanban 封面图”。

“整理红酒选题”。

放一起当然也能看。

但看多了脑子会串台。

第三步：创建资料核验任务

第一张卡先交给 researcher。

任务目标：把官方资料和外部案例摸清楚。

RESEARCH=$(hermes kanban create "Research: Hermes Kanban 官方资料与案例核验" \
  --assignee researcher \
  --tenant laomai-content \
  --workspace "dir:$PROJECT" \
  --priority 1 \
  --body "围绕 Hermes Kanban 写一篇新手教程。请核验官方 Kanban tutorial、Kanban overview、worker lanes 文档，整理核心概念、关键命令、适合新手的案例和注意事项。输出来源清单、事实要点和写作建议。" \
  --json | jq -r .id)

上面这个写法用了 jq 自动提取任务 id。

如果你电脑里没有 jq，也没关系。

就先去掉最后这一段：

| jq -r .id

然后从命令输出里手动复制 id，再写成：

RESEARCH=t_xxx

小白别卡在工具上。

先把流程跑通。

这张卡完成时，researcher 应该留下结构化交接。

比如：

{
  "sources": [
    "Kanban tutorial",
    "Kanban Multi-Agent Board",
    "Kanban worker lanes"
  ],
  "key_points": [
    "Kanban 是持久化任务队列，不是普通待办清单",
    "worker 用 kanban_* 工具，不是 CLI",
    "gateway 内置 dispatcher，默认 60 秒调度一次"
  ],
  "risks": [
    "不要把 dashboard 暴露到公网",
    "dir workspace 必须使用绝对路径"
  ]
}

这一步非常关键。

写技术教程最怕什么？

不是写得不够热闹。

是命令写错。

读者复制以后直接报错。

那就不是教程了。

那叫赛博绊马索。

第四步：创建初稿任务

第二张卡交给 writer。

它依赖 researcher 的资料核验。

DRAFT=$(hermes kanban create "Write: Hermes Kanban 新手教程初稿" \
  --assignee writer \
  --tenant laomai-content \
  --workspace "dir:$PROJECT" \
  --parent "$RESEARCH" \
  --priority 1 \
  --skill wechat-article-writer \
  --body "根据父任务资料，按老麦克公众号风格写一篇新手教程。要求：开头像聊天，不要宏大叙事；正文解释 Kanban 核心概念；开发案例使用老麦公众号内容生产流水线；正文不使用 emoji；输出完整 Markdown 草稿。" \
  --json | jq -r .id)

注意这里的 --skill wechat-article-writer。

这不是装饰。

它相当于给 writer 临时发了一本“老麦公众号写作操作手册”。

AI 不是靠玄学变像你的。

它要读你的风格档案。

要知道你的禁忌表达。

要知道你喜欢短段落、反问、口语化、少 emoji。

这就是 Skill 的价值。

第五步：创建审校任务

第三张卡交给 editor。

它依赖初稿。

EDIT=$(hermes kanban create "Edit: Kanban 教程三轮审校" \
  --assignee editor \
  --tenant laomai-content \
  --workspace "dir:$PROJECT" \
  --parent "$DRAFT" \
  --priority 1 \
  --body "对父任务初稿做三轮审校：第一轮核事实和命令；第二轮去 AI 味，改成老麦口语风格；第三轮检查移动端段落、Markdown、引用、emoji、标题摘要。输出最终稿和修改摘要。" \
  --json | jq -r .id)

这一步就像公众号文章里的“质检工位”。

很多 AI 文章最大的问题，不是没有内容。

而是太顺了。

顺到像刚从模板厂出来。

每一段都正确。

每一句都礼貌。

每一个转折都像“此外”“另外”“值得注意的是”。

读者一看就知道：

这不是人在说话。

这是 AI 在上班。

所以 editor 的任务不是把文章改得更正式。

恰恰相反。

是把它改得更像人。

更像老麦。

第六步：创建媒体计划任务

第四张卡交给 media。

它依赖最终稿。

MEDIA=$(hermes kanban create "Media: Kanban 教程封面图与配图方案" \
  --assignee media \
  --tenant laomai-content \
  --workspace "dir:$PROJECT" \
  --parent "$EDIT" \
  --priority 1 \
  --body "根据最终稿生成媒体资源方案。包括：公众号封面图方案、正文配图位置、每张图的提示词、是否需要用户截图、是否建议视频演示。输出 media-plan.md。" \
  --json | jq -r .id)

这张卡不是为了“凑图”。

而是为了降低读者理解成本。

比如：

Kanban 和普通待办清单的区别，适合用一张对比图。

Profile 分工，适合用角色泳道图。

Blocked -> Comment -> Unblock，适合用流程图。

如果只是随便生成几张赛博蓝光背景，那还不如不配。

图不是装饰。

图是解释工具。

第七步：创建最终交付任务

最后来一张总装卡。

它依赖 editor 和 media。

hermes kanban create "Deliver: Kanban 教程最终交付包" \
  --assignee editor \
  --tenant laomai-content \
  --workspace "dir:$PROJECT" \
  --parent "$EDIT" \
  --parent "$MEDIA" \
  --priority 1 \
  --body "整合最终公众号排版稿、media-plan.md、summary-card.md。检查文件路径、标题摘要、字数、引用来源和正文 emoji。输出最终交付说明。"

到这里，一条完整内容生产流水线就搭好了。

researcher 核资料
        ↓
writer 写初稿
        ↓
editor 三轮审校
        ↓
media 做媒体计划
        ↓
editor 整合交付

这就是我说的“真实项目案例”。

不是为了演示而演示。

而是你以后真的可以这么用。

写文章可以。

做课程可以。

做产品需求文档也可以。

甚至你要做一个小工具，也可以把它换成：

PM 写规格 -> 工程师实现 -> QA 测试 -> Reviewer 审查 -> 文档员补说明

底层逻辑都一样。

把一句话任务，变成一条可追踪的协作流水线。

第八步：启动调度并观察

确认 gateway 在跑：

hermes gateway start

然后观察这个内容生产看板：

hermes kanban watch --tenant laomai-content

或者打开 Dashboard：

hermes dashboard

你会看到任务不是一窝蜂同时乱跑。

researcher 先跑。

它完成以后，writer 才拿到资料。

writer 完成以后，editor 才审稿。

editor 完成以后，media 才知道该配什么图。

最后交付任务等 editor 和 media 都完成，才开始整合。

这就是依赖推进。

不是 AI 比你聪明了。

是流程终于不靠你脑子硬记了。

07 如果 worker 卡住了，怎么办？

真实开发一定会卡。

比如 writer 发现：

“这篇文章到底接上一篇安装教程，还是单独成篇？”

或者 media 发现：

“封面图要走硬核开发风，还是老麦式接地气风？”

这时 worker 可以把任务 block。

你可以查看：

hermes kanban list --status blocked
hermes kanban show t_xxx
hermes kanban runs t_xxx

如果你知道怎么处理，可以加评论：

hermes kanban comment t_xxx "这篇文章接上一篇 Hermes 安装教程，但要保证单独阅读也能看懂。封面走硬核但不装的风格，少赛博蓝光，多任务看板和 AI 员工分工感。" --author 老麦

然后解锁：

hermes kanban unblock t_xxx

下一轮 dispatcher 会重新拉起 worker。

重点来了。

重新拉起不是完全失忆。

它会看到之前为什么 block。

也会看到你后来补充的评论。

这就是 Kanban 比单纯聊天更适合工程任务的地方。

它不是一次性问答。

它是可恢复、可追踪、可重试的工作流。

08 新手最容易踩的几个坑

坑一：assignee 写错了

你创建任务时写了：

--assignee backned

结果你真正的 profile 叫 backend。

少打一个字母。

任务可能一直在 ready 里没人接。

这种问题可以用：

hermes kanban assignees
hermes kanban diagnostics

看看 profile 和任务分配是否正常。

坑二：以为开 Dashboard 就会自动干活

Dashboard 是观察界面。

真正调度靠 gateway 里的 dispatcher。

所以要确认：

hermes gateway start

或者在 Dashboard 里点 Nudge dispatcher 看看有没有任务被捡起来。

坑三：workspace 用了相对路径

不要这样：

--workspace dir:../myapp

用绝对路径：

--workspace dir:/Users/你的用户名/dev/myapp

或者在 WSL2 里：

--workspace dir:/home/你的用户名/dev/myapp

官方文档明确说了，dir:<path> 必须是绝对路径。

坑四：让 worker 自己跑 CLI 操作 Kanban

人类用：

hermes kanban show t_xxx

worker 用：

kanban_show()

这两个不是一回事。

别在任务 body 里写“请你运行 hermes kanban complete”。

worker 应该通过 kanban_* 工具完成任务。

这是官方设计，原因也很现实：

worker 的 terminal 可能在 Docker、SSH、Modal 或别的环境里。

那里不一定有本机的 ~/.hermes/kanban.db。

用工具调用，才不会因为 shell 路径和环境乱套。

坑五：完成任务不写交接信息

不要只写：

“done”。

这和同事下班前在群里发个“搞定了”一样。

听起来很好。

但你完全不知道他搞定了什么。

建议每个工程任务完成时都留下这些信息：

{
  "changed_files": ["修改过的文件"],
  "verification": ["跑过的测试命令"],
  "residual_risk": ["还没覆盖的风险"],
  "blocked_reason": null
}

这不是仪式感。

这是下游 worker、reviewer 和未来的你能不能看懂现场的关键。

坑六：把 dashboard 暴露到公网

Hermes Dashboard 默认绑定本机。

别随便用：

hermes dashboard --host 0.0.0.0

尤其是在共享服务器上。

Kanban 里有任务描述、评论、路径、项目上下文。

你把它暴露出去，相当于把项目作战室门打开了。

别给自己加戏。

09 老麦的灵魂总结

Hermes Kanban 最值得学的，不是那几条命令。

命令只是表面。

真正值得学的是一种新的 AI 使用方式。

以前我们用 AI，是一个人对一个聊天框。

你问。

它答。

你催。

它改。

它忘。

你骂。

然后你们俩继续在聊天窗口里互相折磨。

Kanban 代表的是另一种思路：

把 AI 当成可以分工的数字员工。

把任务拆成卡片。

把角色拆成 profile。

把过程留在数据库。

把结果写成结构化交接。

把失败变成下一次尝试的上下文。

这就开始有点像“管理 AI 团队”了。

当然，别过度神化。

它不会让你一夜之间拥有一个硅谷研发团队。

它也不会自动判断你的商业方向对不对。

更不会替你承担产品决策。

但它能解决一个很实际的问题：

当任务不再是一句 prompt 能讲清楚时，你需要一个工作流。

Hermes Kanban 就是这个工作流。

对开发者来说，最推荐的起步方式就是今天这个案例：

先别搞宏大的“全自动创业公司”。

先拿一个小功能练手。

比如今天这篇 Kanban 教程。

比如一条公众号文章生产线。

比如一个数据导入脚本。

拆成资料、初稿、审校、媒体、交付几张卡。

跑一遍。

看它怎么卡住。

看它怎么重试。

看它怎么交接。

你跑通这一遍，才会真正理解：

AI Agent 的关键，不是“更聪明的聊天”。

而是“更可控的协作”。

这就是 Hermes Kanban 的意义。

好了，以上就是本期的全部内容。

如果你已经装好了 Hermes，建议别光收藏。

找一个不那么重要的小项目，或者一篇准备写的文章，照着这篇文章跑一条协作流水线。

然后你会发现：

AI 真正开始有用，往往不是它突然变成了天才。

而是你终于开始像管理项目一样管理它。

我是老麦克，我们下期见。

文章引用与备注

1. Hermes Agent 官方文档：Kanban tutorial，访问与核验时间：2026-05-20。

2. Hermes Agent 官方文档：Kanban Multi-Agent Board，访问与核验时间：2026-05-20。

3. Hermes Agent 官方文档：Kanban worker lanes，访问与核验时间：2026-05-20。

4. 本文中的真实项目案例基于老麦克正在使用的公众号文章写作助手目录和内容生产流程改写，同时参考官方 tutorial 的 solo dev、role pipeline、retry、structured handoff 思路，不代表官方固定模板。

文末资源

本文提到的官方资料：

• Hermes Kanban tutorial：https://hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/features/kanban-tutorial

• Hermes Kanban overview：https://hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/features/kanban

• Hermes Kanban worker lanes：https://hermes-agent.nousresearch.com/docs/zh-Hans/user-guide/features/kanban-worker-lanes

如果你要照着练，老麦建议先别动生产目录。

先拿一个小项目。

或者拿一篇准备写的文章。

跑一遍完整流程。

把卡片怎么推进、怎么 block、怎么补评论、怎么 unblock 都看一遍。

收藏等于会了？

不是。

跑通才算。