你是否有这样的经历：让AI写篇文章，它思考了三分钟后告诉你"好的我开始写了"，然后——就没有然后了。你等了一小时，它已经显示"完成"，但文章连个影子都没有。或者更气人的是，它确实写了，写了一半，丢在某个你永远找不到的地方。

这不是你的问题。这是AI agent架构的原生缺陷。

传统AI调度的三大死穴

第一个：串行等待陷阱。 你让Agent去做A，然后等它做完再告诉它做B。但AI的"思考"时间是不可预测的——有时候10秒，有时候10分钟。你要么干等，要么错过最佳干预时机。

第二个：任务丢失综合症。 Agent接了一个复杂任务，开始做，中途遇到问题，默默失败了。你完全不知道它做了多少，也不知道它卡在哪。最后只能重头来过。

第三个：上下文悬崖。 一个任务做了很久，上下文窗口已经堆积了几万token。Agent开始遗忘最初的指令，做出和目标完全无关的东西。你说"继续"，它一头雾水。

这三个问题，几乎困扰着每一个试图用AI实现复杂工作流的人。

Hermes Kanban是什么

Hermes Kanban是Hermes Agent框架内置的任务调度系统。它的核心理念来自实体世界的看板管理——每一项工作变成一张卡片，有明确的状态、归属和依赖关系。

但它不是给人类用的，是给AI用的。

在Hermes Kanban里，每个任务是一张卡片，包含：

• 标题和描述：告诉Agent要做什么

• 状态：todo（待处理）、running（执行中）、done（完成）、blocked（阻塞）

• 工作空间：隔离的临时目录，用来读写文件

• 依赖关系：哪些任务必须先完成才能开始

• Assignee：具体哪个Agent profile来处理这张卡

你作为Orchestrator（编排者），不再是直接命令一个Agent埋头干活然后干等。你创建任务卡片，把它们分发给不同的Agent，监控它们的状态，在关键节点插入人类审批。

核心工作流程

一个典型的Kanban任务生命周期是这样的：

第一步：分解任务。 你接到一个复杂请求——比如"写一篇公众号文章，附三张配图"。在Hermes Kanban里，这不是一个任务，是四个：

• 写文章内容（researcher profile）

• 生成封面图（image-prompt-engineer profile）

• 生成配图A（image-prompt-engineer profile）

• 生成配图B（image-prompt-engineer profile）

第二步：建立依赖。 封面图和配图必须等文章写完才能开始——你用parent关系把它们链接起来。配图A和配图B是独立的，可以并行执行。

第三步：派发执行。 Hermes的dispatcher自动把ready状态的任务分配给对应的Agent profile。Agent开始工作，你实时看到状态变化。

第四步：人类审批。 文章初稿完成后，系统会停在一个"blocked"状态，等待你确认。你可以回复"通过"让它继续，或者指出需要修改的地方。

第五步：完成汇总。 所有任务都done之后，你得到最终产物——文章、配图、一切就绪。

任务状态详解

todo → running → done         ↓      blocked (等待人工审批)

• todo：任务已创建，等待执行。依赖未完成时自动保持todo。

• running：Agent正在处理中。

• done：任务完成，产物已就位。

• blocked：需要人工介入或审批，不能自动继续。

blocked状态是Hermes Kanban最重要的设计。它让AI在关键决策点停下来等人类确认，而不是按自己的想法一路狂奔到最后才发现跑偏了。

工作空间隔离

每个Kanban任务都有自己独立的工作目录：~/.hermes/kanban/workspaces/<task_id>/。

这解决了AI agent的另一个经典问题：不同任务之间的相互污染。Agent A在workspace里写了一堆中间文件，不会影响Agent B的工作环境。任务完成后，workspace可以保留（用于调试）或自动清理（用于一次性任务）。

你也可以指定共享工作空间（--workspace dir:~/shared/），让多个任务读写同一个目录。这在你需要任务之间传递产物时很有用——但要小心同时写入的冲突。

依赖链：让任务按正确顺序执行

Kanban的依赖系统通过parents参数实现。子任务会一直卡在todo状态，直到所有父任务都标记为done。

Step1-素材搜索 (done)Step2-文章撰写 (running) ← parents=[Step1]Step3-配图生成 (todo) ← parents=[Step2]Step4-发布 (blocked) ← parents=[Step3] + 人工审批节点

这个机制确保了数据流的正确性：文章没写完，AI不会开始生成配图；配图没到位，发布任务不会启动。

对于并行的独立任务，不设置parents关系，它们会同时被dispatcher派发出去，节省总执行时间。

监控与恢复

任务执行中如果Agent崩溃了怎么办？Hermes Kanban会自动检测并标记。Dispatcher每60秒检查一次所有running的任务——如果一个任务超过15分钟没有心跳（heartbeat），它会标记为超时。

你可以通过hermes kanban show <task_id>查看某个任务的具体状态和诊断信息。如果Agent写完了产物但忘记调用kanban_complete，你也可以手动标记完成。

对于持续失败的任务，有三个选项：

• Reclaim：终止当前运行，重置为ready状态重新派发

• Reassign：把任务转给另一个Agent profile处理

• 修改配置：如果失败是因为模型能力不足，更换更强模型后重试

与delegate_task的对比

很多人会问：Kanban和delegate_task有什么区别？

delegate_task适合短平快的任务。你让一个Agent做一件独立的事，它做完直接返回结果，你在当前对话里拿到输出。全程在同一个上下文里，没有状态持久化。

Kanban适合复杂、长时、多步骤的工作流。你需要任务分阶段执行、需要人工审批节点、需要并行处理多个独立任务、需要任务状态持久化（不怕对话中断）。

简单判断：如果一个任务你预计要超过3分钟，或者中间需要人类确认，就用Kanban。否则，delegate_task更轻量。

实际配置

在~/.hermes/config.yaml里可以配置Kanban行为：

kanban:  threshold_minutes: 3  # 超过3分钟的任务建议用Kanban

每个Agent profile可以有独立的config.yaml（~/.hermes/profiles/<name>/config.yaml）。这允许你为不同类型的任务配置不同的模型——比如researcher用GPT-4，code-agent用Claude Sonnet，image-engineer用MiniMax。

什么时候用Hermes Kanban

✅ 推荐场景：

• 公众号文章创作（写作→配图→排版→审批）

• 视频制作流水线（素材搜索→剪辑→配音→合成）

• 多维度研究（并行搜索不同来源→综合分析→报告撰写）

• 任何需要多Agent协作、有人类干预点的复杂工作流

❌ 不建议场景：

• 单步查询或简单操作（直接问，直接答）

• 纯文案写作且不需要审批（一气呵成，不需要分阶段）

• 实时对话式交互（Kanban是异步的，不适合需要即时反馈的场景）

写在最后

Hermes Kanban解决的不是"AI不够聪明"的问题。它解决的是"AI不可靠"的问题。

当你的AI助手可以在关键时刻停下来问你，可以在失败后不丢失进度，可以让多个专业Agent协同完成一个复杂任务——你就拥有了一个真正可用的AI工作流，而不只是一个人工智障。

你用Kanban做过什么复杂任务？有什么坑或经验？欢迎来聊。

---

「智元记」