Kanban on Kalend's Blog

Hermes Agent v0.15：速度翻倍，从单兵到军团

Fri, 29 May 2026 18:30:00 +0800

先说结论

Hermes Agent v0.15.0（5月28日）是迄今最大的单版本更新。 1,302个提交、747个合并PR、1,746个文件变更、321位社区贡献者。隔天（5月29日）发布的 v0.15.1 修复了影响所有 Dashboard 用户的 P0 bug。

这个版本的三个关键词：快、拆、稳。

速度：从各个维度变快

冷启动再砍1秒

v0.15.0 延续了冷启动性能优化的浪潮，三轮优化叠加：

openai._base_client 导入延迟加载：-240ms / -17MB 内存
热路径函数调用削减 47%（399k → 213k，31轮对话）
压缩可行性检查延迟：-170 到 -290ms
自适应子进程轮询：-195ms/工具调用

实际效果：Termux 冷启动从 2.9s → 0.8s。 hermes --version 冷启动 701ms → 258ms（降63%），首次超越 Codex CLI。

session_search 快了4500倍

旧版 session_search 是辅助 LLM 驱动的工具，每次搜索花 90 秒、花费 $0.30，偶尔还会编造结果。新版完全重写：

零 LLM 调用，纯 FTS5 搜索引擎
三种模式（发现/滚动/浏览），自动推断无需切换
搜索延迟：~20ms（旧版 ~90s）
滚动延迟：~1ms

搜索历史对话现在免费且即时。

拆：核心代码大瘦身

run_agent.py 从16,000行拆成3,800行

这是整个版本最激进的重构。 run_agent.py 从 16,083 行缩减到 3,821 行（-76%），拆分到 14 个内聚的 agent/* 模块。

关键保证：行为零变化。每个拆分都在 AIAgent 上保留薄转发器，所有测试补丁路径不受影响，外部调用者完全兼容。

为什么你应该关注？以前这个文件在你的编辑器里要 90 秒才能打开，现在眨眼即开。未来开发迭代速度会显著加快。

稳：Kanban长成真正的多Agent平台

v0.15.0 用 104个PR 把 Kanban 从任务队列升级为多 Agent 协作平台。

新能力一览

能力	说明
自动分解	Triage 自动将一个任务分解为子任务树
Swarm 拓扑	`hermes kanban swarm` 一键创建完整 Swarm v1 图
每任务模型覆盖	便宜模型做杂活，贵模型啃硬骨头
工作树隔离	每个任务独立 git worktree，互不干扰
定时启动	任务支持指定开始时间
陈旧任务检测	自动发现并回收卡住的任务
Worker 可视化	`/workers/active`、`/runs/{id}`、`/inspect` 端点

Swarm 是什么

一条命令创建一个完整的多 Agent 工作流：

1

hermes kanban swarm

自动生成：根节点 → 并行 Worker → 门控验证者 → 门控综合者 → 共享黑板。适合代码审查、批量研究、多文件重构等场景。

安全：三道防线对抗提示注入

受 Brainworm/Promptware Kill Chain 研究（arxiv 2601.09625）启发，v0.15.0 在三个关键位置部署了防御：

威胁模式库（tools/threat_patterns.py）：~15个新的 Brainworm/C2 模式
记忆加载扫描：召回的记忆在注入上下文前先过安全检查
工具结果分隔符：恶意文件或远程服务无法伪装成 Hermes 自身的系统内容

配合新增的 security-guidance 插件，对危险代码写入进行模式匹配。

其他值得关注的更新

Bitwarden Secrets Manager 集成

一个引导令牌（BWS_ACCESS_TOKEN）替代所有明文 API Key。在 Bitwarden Web 端轮换密钥，重启即生效。

ntfy：第23个消息平台

无需注册、无需 API Key，只要一个 topic URL。Agent 完成任务、cron 到点，推送通知直达手机/桌面/智能家居。

Skill Bundle：一条命令加载多个 Skill

设置你的"写作日"组合（humanizer + ideation + obsidian + youtube-content）。 /writing-day 一次性激活全部。

TUI 会话管理器

Ink TUI 新增多会话切换器：在同一个终端窗口里列出、切换、刷新、关闭多个会话，不用退出。

Docker s6-overlay 容器管理

容器内网关自动监督、重启对账、docker logs 集成。Node 升级到 22 LTS。

v0.15.1 热修复（5月29日）

v0.15.0 发布隔天，一个 P0 bug 浮出水面：Dashboard 在 loopback 模式下无限重载。

根因

Dashboard 的身份探针（/api/auth/me）在 loopback 模式下返回 401（设计如此）。但 v0.15.0 的过期令牌重载守卫把每个 401 都当成了需要刷新的会话令牌，触发整页重载。重载后其他请求清除了单次重载守卫，于是又触发下一轮。 Firefox 表现为 “Navigated to /sessions” 暴风，Chrome 表现为 React 重渲染风暴。

修复

fetchJSON 新增 allowUnauthorized 选项，跳过 loopback 下的过期令牌重载逻辑。 401 仍然抛异常让 AuthWidget 处理，但不再触发整页刷新。

其他修复

Docker --insecure 改为显式环境变量（HERMES_DASHBOARD_INSECURE=1），不再从绑定主机推断
MCP bare 命令（npx/npm/node）在 Docker 容器内正确解析到 /usr/local/bin
Kanban Worker 的 SIGTERM 终于能正常终止进程
Skills 页面源标签和分类侧边栏恢复
/yolo 中途启用变为 per-session 级别
/model 和 hermes model 显示统一列表
.md 文件媒体投递恢复
Web URL 不再被误删查询参数
Skills Hub 全目录：858 → 19,932，所有 skills.sh 条目可搜索

升级建议

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 源码安装
cd /opt/hermes-agent
git pull
pip install -e .

# 或 Docker
docker pull nousresearch/hermes-agent:latest

# 检查版本
hermes --version

直接跳到 v0.15.1，不要停在 v0.15.0。 Dashboard 无限重载 bug 只影响 v0.15.0。

数据总结

指标	v0.15.0	v0.15.1
提交数	1,302	28
合并PR	747	21
文件变更	1,746	-
贡献者	321	9
P0 修复	15	1
P1 修复	65	-
安全修复	19	-

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

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

Tue, 19 May 2026 07:00:00 +0800

一篇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.1	204K上下文，有记忆
reviewer	审核内容质量	glm-5.1	只审不改，无记忆
blog-creator	转Markdown+部署	glm-4.7	最精简工具集
mp-creator	转公众号HTML+上传	glm-4.7	4个微信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处FAIL	AI味检测	废话铺垫/过度道歉/套话
🟢 仅建议	品牌名	不强制，给出建议
🔵 格式规范	平台适配	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篇将分享踩坑最佳实践

从零搭建 Blog Writer Agent：让 AI 自己写文章、自己部署

Fri, 15 May 2026 17:30:00 +0800

这是「多 Agent 协作」系列第 2 篇。第 1 篇讲了概念：Kanban + Profile：让你的 AI Agent 自己管博客。这篇是纯实操——每一步都是我刚跑过的真实命令。

先说结论

搭一个会自己写博客的 AI Agent，7 步，2.5 分钟。不是 demo，是真的能写文章、构建验证、部署上线的 Agent。

1
2


你：hermes kanban create "写一篇 Kanban 入门" --assignee blog-writer
AI：自动写文章 → 构建验证 → 完成汇报

整个过程你只需要发一条命令。

前置条件

已安装 Hermes Agent（v0.13.0+）
有一个 Hugo/Hexo 等静态博客项目
Gateway 正在运行

第 1 步：启用 Kanban Toolset

Kanban 是隐藏 toolset——hermes tools list 里看不到它。需要手动在 config.yaml 里添加：

1
2
3
4


# ~/.hermes/config.yaml
toolsets:
- hermes-cli
- kanban  # ← 加这一行

同时在 config.yaml 底部确认 dispatcher 配置（通常已有）：

1
2
3
4


kanban:
 dispatch_in_gateway: true
 dispatch_interval_seconds: 60
 failure_limit: 2

改完重启 gateway：

1

systemctl restart hermes-gateway.service

第 2 步：创建 blog-writer Profile

Profile 就是一个独立的 AI 身份——有自己的配置、人格、工作目录。

1

hermes profile create blog-writer --clone

输出：

1
2
3


Profile 'blog-writer' created at ~/.hermes/profiles/blog-writer
Cloned config, .env, SOUL.md, and skills from default.
Wrapper created: ~/.local/bin/blog-writer

--clone 会复制当前 profile 的 API 密钥、配置、记忆文件，省得重新配置。

第 3 步：写 SOUL.md（定义人格）

SOUL.md 决定了这个 Agent 的行为模式。给 blog-writer 写一个专门的人格：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


cat > ~/.hermes/profiles/blog-writer/SOUL.md << 'EOF'
# Blog Writer Agent

你是博客写作和部署专家。

## 职责
1. 撰写技术博客文章（Markdown + Hugo front matter）
2. 构建验证（hugo --minify）
3. 部署到云存储

## 严格规则
- 日期必须是 RFC3339 格式：2026-05-15T10:00:00+08:00
- categories 和 tags 都要包含主题关键词
- description 必须填写
- **永远不要用 read_file → write_file 修改 Markdown**
- 构建后必须检查页面数
EOF

第 4 步：配置工作目录

让 blog-writer 的默认工作目录指向博客项目：

1
2
3
4
5
6
7


# 编辑 blog-writer 的 config.yaml
# 在 terminal 段添加：
terminal:
 cwd: /root/blog
toolsets:
- hermes-cli
- kanban

这样 worker 被调度时，会自动 cd 到博客目录。

第 5 步：初始化 Kanban 看板

1

hermes kanban init

输出：

1
2
3
4
5
6


Kanban DB initialized at ~/.hermes/kanban.db

Discovered 3 profile(s) on disk:
 blog-writer
 default
 yuan

看板是一张 SQLite 表，所有 profile 共享。验证一下：

1
2


hermes kanban stats # 0 tasks (空看板)
hermes kanban assignees # blog-writer (idle)

第 6 步：创建第一个写作任务

1
2
3
4
5
6


hermes kanban create \
 --assignee blog-writer \
 --skill hugo-blog \
 --workspace 'dir:/root/blog' \
 --body '写一篇 Kanban 入门文章。要求：RFC3339日期、categories含hermes、构建验证' \
 '测试任务：写一篇 Kanban 入门文章'

输出：

1

Created t_9dd47956 (ready, assignee=blog-writer)

关键参数解释：

参数	作用
`--assignee blog-writer`	指定谁来做
`--skill hugo-blog`	给 worker 注入博客相关知识
`--workspace dir:/root/blog`	工作目录（不是临时 scratch）
`--body '...'`	任务的详细要求

第 7 步：等 2 分钟，验收

Dispatcher 每 60 秒轮询一次 ready 任务。大约 70 秒后：

1
2


hermes kanban stats
# blog-writer running=1 ← 正在执行

再等 82 秒：

1
2
3
4


hermes kanban show t_9dd47956
# status: done
# summary: 完成测试文章「Hermes Kanban 快速入门」，186页构建通过
# Run #1: completed @blog-writer 82s

文章已经写好了。 看看产出：

1
2
3
4
5
6
7
8


---
title: "Hermes Kanban 快速入门"
date: 2026-05-15T17:00:00+08:00
categories: ["hermes"]
tags: ["hermes", "kanban", "agent"]
---
## 什么是 Kanban？
Hermes Kanban 是内置的任务调度系统...

front matter 格式正确，日期 RFC3339，构建验证通过。全流程从创建到完成 2 分 22 秒。

背后发生了什么

整个调度流程：

1
2
3
4
5
6
7
8
9


你发命令 → kanban create（SQLite 写入一条 ready 任务）
 ↓ 60s
Gateway dispatcher 轮询 → 发现 ready 任务 → claim
 ↓
spawn 子进程：hermes -p blog-writer --skills kanban-worker --skills hugo-blog chat -q "work kanban task t_9dd47956"
 ↓ 82s
blog-writer 读任务 → 写文章 → hugo 构建 → kanban_complete
 ↓
任务状态 → done，你收到通知

几个关键设计：

Dispatcher 嵌在 Gateway 里，不需要给 blog-writer 单独跑 gateway
Worker 是独立子进程，hermes -p blog-writer 启动，完成后自行退出
--skills 自动注入，每个 worker 都会加载 kanban-worker skill（行为规范）
Claim TTL = 15 分钟，超时自动 reclaim，不会永远卡住

我踩过的 4 个坑

坑 1：hermes 不在 PATH 中

Dispatcher spawn worker 时执行 hermes -p blog-writer ...，如果 hermes 不在 PATH 里，直接失败。

1
2
3
4
5


# 检查
which hermes # 如果为空，需要手动链接

# 修复
ln -sf ~/.hermes/hermes-agent/venv/bin/hermes /usr/local/bin/hermes

坑 2：blog-writer 不需要独立 gateway

一开始我以为每个 profile 都得跑自己的 gateway。错了。Dispatcher 运行在主 gateway 里，通过 hermes -p blog-writer spawn 子进程。子进程不需要消息平台，不需要 gateway。

如果你给 blog-writer 启动了 gateway，会和主 gateway 冲突（weixin token 被占）。

坑 3：kanban toolset 是隐藏的

hermes tools list 不显示 kanban。它是条件注册的——只有 config.yaml 的 toolsets 列表里有 kanban 才会激活。很多教程会遗漏这一步。

坑 4：workspace 默认是 scratch

如果不指定 --workspace，默认用 scratch（临时目录，任务完成后会被清理）。博客项目要用 dir:/root/blog，否则写完文章就被删了。

时间线回顾

时刻	事件
17:07:00	`kanban create` → 任务 ready
17:07:10	Dispatcher claim + spawn worker
17:08:32	Worker 完成，kanban_complete
总耗时	1 分 32 秒（从创建到完成）

下一步

这是系列第 2 篇。接下来的内容：

第 3 篇：多任务编排——让多个 Agent 同时写多篇文章，Pipeline + Fan-out 实战
第 4 篇：踩坑全记录——格式陷阱、模型选择、成本控制、调试技巧

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

Kanban + Profile：让你的 AI Agent 自己管博客

Thu, 14 May 2026 23:00:00 +0800

你跟 AI 说"帮我写篇博客"，它写完就走了。下次再说，它又是从零开始。

这篇文章教你用 Hermes 的 Kanban + Profile，给 AI Agent 一个专职身份，让它自己管博客。

先说结论

delegate_task 是临时工，Kanban + Profile 是全职员工。

如果你想：

让一个 AI 专门负责博客（写文章、同步、部署）
任务不丢失（主 Agent 崩了也不影响）
随时查看进度（微信直接看）
出了问题自动通知你

那就用 Kanban + Profile。下面是完整方案。

我的踩坑故事

我有一个 Hugo 静态博客。之前让主 Agent 兼顾博客写作——一边排查路由器 DNS 问题，一边写博客文章。结果：

read_file 带行号前缀写回文件，Hugo front matter 全毁，页面数从 168 暴跌到 102
日期格式不对，date: 2026-05-14 被解析成 0001-01-01
中文 URL 编码错误，又拍云上传 45 个文件失败

根本原因：上下文切换太频繁，主 Agent 在路由器、DNS、博客之间反复横跳，每次切换都丢细节。

两种方案对比

很多人第一反应是 delegate_task（子代理），我也是。但调研完官方文档后发现，这俩根本不是一个量级：

维度	delegate_task	Kanban + Profile
形状	函数调用（fork→join）	持久工作队列 + 状态机
生命周期	分钟级，调用者阻塞等待	小时/天级，fire-and-forget
身份	匿名子代理，干完就走	命名 Profile，有自己的记忆和人格
抗中断	父 Agent 断了，子代理也死	独立进程，互不影响
可恢复	失败即失败	阻塞→解除→重跑；崩溃→回收
人工介入	不支持	任何节点都能 comment/unblock
审计追踪	上下文压缩后丢失	SQLite 永久保存

一句话：delegate_task 是你叫一次临时工；Kanban 是你雇了个全职员工。

架构设计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


你（微信/Telegram/CLI）
 ↓ "写一篇关于 XX 的博客"
主 Agent（orchestrator）
 ↓ kanban_create 创建任务
kanban.db（SQLite 持久化看板）
 ↓ dispatcher 自动调度（gateway 内嵌，60s 轮询）
blog-writer（独立 Profile，独立进程）
 ↓ kanban_complete / kanban_block 汇报
kanban.db
 ↓ gateway 自动通知
你（微信收到完成/阻塞通知）

关键点：

dispatcher 内嵌在 gateway 里，不需要额外的守护进程
blog-writer 是独立 Profile，有自己的 config、记忆、skills、SOUL.md
gateway 自动推送通知，任务完成或卡住都会通知你
你随时可以用 /kanban 命令查看进度、添加评论、解除阻塞

5 步搭建

第 1 步：创建独立 Profile

1

hermes profile create blog-writer --clone

--clone 会复制当前 Profile 的 config.yaml、.env、SOUL.md，省得重新配 API Key。

第 2 步：配置独立人格和工作目录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 配置工作目录指向博客项目
blog-writer config set terminal.cwd /root/blog

# 写专属 SOUL.md
cat > ~/.hermes/profiles/blog-writer/SOUL.md << 'EOF'
你是 blog.kalend.top 的博客写作专家。
职责：撰写高质量技术博客、同步公众号文章、构建和部署。
风格：简洁直接、先结论后细节、代码示例丰富。
严格遵守 hugo-blog skill 中的所有陷阱清单。
EOF

第 3 步：确认 skill 可用

1
2
3
4
5
6
7
8


# kanban-worker 是 bundled skill，自动同步
blog-writer skills list | grep kanban-worker

# 如果缺失，恢复
blog-writer skills reset kanban-worker --restore

# 验证 hugo-blog skill（需要手动确保已安装）
blog-writer skills list | grep hugo-blog

第 4 步：初始化 Kanban

1
2
3
4
5


# 创建看板数据库（幂等操作）
hermes kanban init

# 确保 gateway 运行（内嵌 dispatcher）
hermes gateway start

第 5 步：创建第一个任务

1
2
3
4


hermes kanban create "写一篇关于 Hermes Kanban 的博客" \
 --assignee blog-writer \
 --skill hugo-blog \
 --workspace dir:/root/blog

从这一刻起，dispatcher 会自动发现 ready 状态的任务，spawn blog-writer Profile 作为独立进程执行。

Worker 的工作流程

当 dispatcher 启动 blog-writer 后，它会：

1
2
3
4
5
6


1. kanban_show() → 读取任务详情（标题、正文、父任务结果、评论历史）
2. cd $WORKSPACE → 进入工作目录
3. 执行任务 → 搜索素材 → 撰写文章 → Hugo build → 部署
4. kanban_heartbeat() → 长任务中间汇报（可选）
5. kanban_complete() → 完成（附带 summary + metadata）
 或 kanban_block() → 阻塞（需要你确认标题/内容等）

阻塞时，你微信会收到通知。你直接在微信里回复：

1
2


/kanban comment t_xxx "标题用「Kanban实战：让AI自己管博客」"
/kanban unblock t_xxx

dispatcher 下一次轮询时会重新 spawn worker，worker 读取你的评论后继续。

任务依赖：Pipeline 模式

如果你的写作流程是：调研 → 写作 → 审校 → 部署，可以用 parents 串起来：

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


# 1. 调研任务（立即开始）
hermes kanban create "调研 Hermes Kanban 架构" \
 --assignee researcher

# 2. 写作任务（等调研完成）
hermes kanban create "写博客文章" \
 --assignee blog-writer \
 --parent t_research

# 3. 部署任务（等写作完成）
hermes kanban create "部署博客" \
 --assignee blog-writer \
 --parent t_writing

子任务会停留在 todo 状态，直到所有 parent 达到 done，然后自动 promote 到 ready。不需要手动协调。

9 种协作模式

官方文档列出了 9 种 Kanban 协作模式。博客场景常用的：

模式	用法
P1 Fan-out	同时写 5 篇不同主题的文章
P2 Pipeline	调研 → 写作 → 审校 → 部署
P5 Human-in-the-loop	写完后阻塞等你确认再部署
P8 Fleet farming	一个 writer 处理 N 篇文章队列
P9 Triage specifier	粗略想法 → triage → 自动展开为完整任务

我遇到的真实问题

问题 1：写作质量不可控

解法：GLM-5.1 做格式转换和同步任务完全够用。原创写作需要更强的模型——Profile 可以独立配置模型：

1

blog-writer config set model.default anthropic/claude-sonnet-4

问题 2：格式错误反复出现

解法：把所有踩过的坑写进 skill，每次 worker 启动时自动加载。我的 hugo-blog skill 现在有 12 条陷阱清单，覆盖了行号前缀、日期格式、URL 编码等所有已知问题。

问题 3：上下文丢失

解法：每篇独立跑，skill 固定注入。不依赖主 Agent 的上下文。kanban.db 里的 comment 线程就是完整的任务上下文。

和 delegate_task 什么时候用哪个

场景	选择
快速并行子任务（搜索3个话题）	`delegate_task`
长时间独立工作（写博客文章）	Kanban + Profile
需要人工确认	Kanban（阻塞/解除）
一次性的简单问答	直接回答
需要跨 session 保持状态	Kanban（SQLite 持久化）

它们可以共存：Kanban worker 内部可以调用 delegate_task 处理短子任务。

官方文档

Kanban 文档：https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban
Kanban 教程：https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban-tutorial
Profile 文档：https://hermes-agent.nousresearch.com/docs/user-guide/profiles

这是「Hermes 多 Agent 协作」系列的第一篇。下一篇会实际搭建 blog-writer Profile，跑通第一个完整的写作→部署流程。

如果你也在用 Hermes Agent 或者对 AI Agent 协作感兴趣，关注我，后面会持续分享实战经验。

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

多 Agent 协作实战