# 从 Hermes Kanban 看多 Agent 协作：真正的协作必须回到任务系统

`2026-06-05`

上一篇《为什么 Hermes 会超越 OpenClaw》里我谈过，Hermes 反超的关键是它选对了人群，又选对了云端常驻的部署形态。但 Hermes 0.13 还做了一件值得单独写一篇的事：把 Kanban 放进了核心特性里。这件事看起来只是多了一块任务面板，实际上是对"多 Agent 协作应该长什么样"这个问题的一次正面回答。

过去一年多，AI 圈对多 Agent 协作的想象非常热烈。一个 Agent 当产品经理，一个当架构师，一个当程序员，一个当 Reviewer，几个 AI 围坐一桌发表意见，最后综合出一个更好的方案。这个画面很诱人，因为它借用了人类组织里的协作隐喻。但实践中它很容易变成"几个同源模型换着人设说话"，热闹得轰轰烈烈，工程增益却薄得像层窗户纸。

Hermes Kanban 把这件事从聊天层拉回了任务系统层。这才是它的意义。

## 一、Kanban 解决的不是"Agent 不够多"，是"长任务不稳定"

Hermes Kanban 是一个所有 profile 共享的 durable task board。每个任务都是 `~/.hermes/kanban.db` 里的一行，可读可写；每个 worker 都是一个有自己身份的完整 OS 进程。0.13 release 把这套东西叫做 "Hermes Agent now finishes what it starts"，配套机制处理的全是脏活：Agent 跑着跑着死了得有 heartbeat 探活，僵尸进程要能被 reclaim 回收，worker 出现幻觉式 finish 还得能回滚重试。

这些词描述的就是分布式任务系统的老问题：进程会失败，状态需要持久化，交接得有协议。跟"专家团"或"多 Agent 智慧"那套叙事是两件事。Kanban 应当被当成 Agent 工作流的任务底座，不是多 Agent 的表演舞台。

理解这一点是理解 Hermes Kanban 的起点。专家团式多 Agent 把重心放在角色 prompt 上，"你是战略专家""你是安全专家"。Kanban 把重心放在任务怎么持久化、worker 怎么标识、状态机怎么推进。前者是语言层的协作想象，后者是运行时层的协作约束。

## 二、多 Agent 协作其实是一种 harness 工程

我之前写过一组关于 harness engineering 的文章，里面反复在讲一件事：让 AI Agent 好用，关键不在模型，在围绕模型搭起来的运行环境。Context 要被治理，约束要用机械方式落实，验证要落到外部 artifact 上（光靠另一个 Agent 点头不算），人机协作得发生在正确的层次。

把这一组原则搬到多 Agent 场景，它们一个都没变，只是从"一个 Agent 怎么不跑偏"升级成了"几个 Agent 怎么互相不带偏对方"。

Context 治理在单 Agent 场景是清空 scrollback、压缩历史；在多 Agent 场景是给每个 worker 自己的 SOUL.md 和工作目录，让上游的失败上下文不会污染下游。约束在单 Agent 场景是 sandbox 和 Linter；在多 Agent 场景是 worker identity 和 approval token，谁能改什么、要不要等审批，全在这里画死。验证在单 Agent 场景是 build-and-self-verify loop；在多 Agent 场景就是 Trellis 那种 implement.jsonl 和 check.jsonl 物理隔离的 spec：写代码的 agent 拿到的是"怎么写"的规范，审代码的 agent 拿到的是"怎么查"的标准，两者看不到对方的上下文，对抗才成立。人机协作在单 Agent 场景是请求权限确认；在多 Agent 场景就是 Kanban 上的 blocked / review-required 状态。人不全程监工，他在 inbox 里等任务停住的那一刻才出场。

把这条线想清楚之后再看 Hermes Kanban 和 Trellis，就特别顺。它们没有在多 Agent 上发明新东西，做的是把已经被验证过的 harness 原则从单 Agent 工程铺到多 Agent 工程上。这条路看起来不性感，但它是目前唯一被独立项目反复跑通的多 Agent 路径。

## 三、Trellis：另一种朴实而有效的样本

工程领域里其实已经有人沿着同一条路走过了。Trellis 是一个开源 harness 项目，我之前在《通过 Trellis 来看 harness 工程的实现》里写过它。它的多 Agent 路径甚至比 Hermes Kanban 更克制，但同样能跑得起来。

Trellis 把编码工作拆成三种 sub-agent：trellis-implement 写代码，trellis-check 审查代码，trellis-research 调研。三者运行在独立 context 里，接收不同的 spec 文件。implement.jsonl 列出"怎么写"的规范，check.jsonl 列出"怎么查"的标准，两个 agent 互不可见对方的上下文。它的工作流是 no_task → planning → in_progress 三态状态机，每个状态注入不同的 breadcrumb 块。会话恢复靠的是文件系统里的 session pointer，跟 AI 的记忆没关系。

这套机制朴实得几乎平淡。没有任何一个 agent 被设定成"高级架构师"或"安全专家"，但它已经是一个真能跑的多 Agent 系统。原因正是它把最难的几件事做对了：context 隔离对应 harness 的 context 治理，spec 按任务精挑对应约束机制，状态机硬性分阶段对应验证逻辑前置，session pointer 放进文件系统对应人机协作的清晰交接点。Trellis 没有大佬开会，它只有任务、规范和带着不同视角的子 agent，但它的可靠性比任何 "CEO + CTO + 程序员" 式 demo 都高一个量级。

Hermes Kanban 和 Trellis 走的是同一条路。前者用 SQLite-backed 任务板把任务状态外化，后者用 JSONL curation 把规范选择外化。前者关心多 profile 之间的任务交接，后者关心多 sub-agent 之间的视角分离。两者都把多 Agent 设计成了一条任务流水线。没人把它当会议室来用。

## 四、为什么"专家团"式多 Agent 容易变成绣花枕头

去年我自己也跑过一个三 Agent 的小流水线。用 Claude Code 拉了一个 architect、一个 coder、一个 reviewer，让它们配合写一个数据迁移脚本。跑了大概两个小时，最后 reviewer 礼貌地批准了 coder 提交的方案，我兴冲冲拿去本地一跑，根本运行不了。回头看 reviewer 当时的发言，它认认真真分析了 coder 的"设计意图"，把 coder 自己的辩护当成了规范本身。三个 Agent 共享一个底座模型，吵了半天，吵的其实是同一个模型对自己输出的合理化解释。

这种翻车不是个案。多 Agent 之所以容易变成绣花枕头，根本原因是它经常借用了组织协作的外壳，却没有实现组织协作的机制。人类团队能协作，靠的是每个人手上的经验、信息源、工具和责任都不一样，最终都要对可观察产物负责。靠 title 协作的团队从来活不久。AI 多 Agent 如果只复制 title 不复制这些机制，就只能 cosplay。

具体说，"专家团"模式有四个常见的塌方点。

**角色名不能创造能力**。告诉模型"你是世界级安全专家"可能让它更关注权限和攻击面，但这不会让它真的拥有独立安全团队的经验、工具和案例库。它只是把同一个模型的注意力调到某个方向。这个技巧不是没用，但远不足以撑起"专家团"这个隐喻。一个能用的安全 reviewer 该握有权限规则、攻击用例、静态分析工具，再加上强制阻断能力。否则它只是用安全专家的语气说话。

**同源模型容易共振**。我那个 architect/coder/reviewer 三件套就吃了这个亏。几个 Agent 来自同一个模型、同一份提示体系，错误模式高度相关。一个产生了似是而非的解释，另一个在协作语境下会礼貌地接受并补充，第三个再综合成一个更自信的结论。表面是多方验证，实际上是共识幻觉被层层加固。多 Agent 不天然降低幻觉，设计不好反而会把幻觉包装得更像组织共识。

**讨论不是验证**。几个 Agent 都说"这个方案合理"，不等于它合理。验证必须落到外部世界，能不能跑通测试、diff 是不是符合规范、命令是不是真的被执行了。一篇 2025 年关于多 Agent 系统失败的研究分析了 5 个流行框架和 150 多个任务，发现多 Agent 相对单 Agent 的性能提升并不总是显著，失败原因主要集中在规格设计、协调失配和验证缺失这三类系统问题上。瓶颈不在 prompt 写得够不够漂亮。

**协作成本可能高于收益**。多 Agent 引入通信、合成、状态管理和失败归因这一连串成本。单 Agent 出错，你能沿着一个上下文排查；多个 Agent 出错，你得先猜是谁出的错，再猜是哪一步出的错。一项相关研究里，最佳方法识别失败责任 Agent 的准确率只有 53.5%，定位失败步骤更低到 14.2%。这是把 AI 当 debugger 来用都未必稳的事，你却指望 AI 自己去做这种归因。系统复杂度涨得越快，可靠性追不上的部分越大，多 Agent 就越容易从增强工具变成故障放大器。

## 五、多 Agent 的本质：制造有效差异

多 Agent 协作的核心不在多个 Agent，在多个有效差异。没有有效差异，把一个 Agent 拆成五个，只是多花 token 多制造噪声。有效差异至少有五种，它们也是检查任何"多 Agent"方案能否成立的清单。

**信息差异**：不同 Agent 应该接触不同输入。让一个看官方文档，让另一个看源码，再让一个看用户反馈，它们的分歧才来自信息源，而不是来自人格设定。

**工具差异**：一个 QA Agent 不能跑测试，它就只是一个发表 QA 意见的人。一个 SRE Agent 不能读日志和指标，它也不是 SRE，只是站在 SRE 角度说话。Trellis 的 implement agent 和 check agent 能形成对抗，靠的就是它们手上的 spec 文件物理上不同。

**权限差异**：能读不能写、能写不能发布、能建议不能执行。这些边界比"你是什么专家"重要得多。Hermes Kanban 强调 worker identity 和 approval token，理由就在这里。

**目标差异**：builder 要完成，breaker 要破坏，verifier 要证明。这些目标天然互相牵制，所以才能产生真实审查。仅靠提示给 Agent 一个"反方"角色而没有目标差异，反方很容易被讨论氛围说服。

**验证差异**：每个 Agent 的产出必须能被外部 artifact 检查。能跑的测试、能 diff 的代码，这些才算验证；另一个 Agent 用语言点头不算。

把这五条当成清单去对照任何"多 Agent"方案，会立刻发现大量"专家团"在五条上一条都不满足。多 Agent 在做的事其实是构造一个更可靠的认知系统：用上下文隔离避免路径污染，用目标冲突制造审查压力，用工具权限限制错误半径，用外部验证约束语言幻觉，用持久状态支持长期任务。这是它可能超过单 Agent 的地方，前提是五条里至少满足三条；满足不了，就老老实实回去用单 Agent。

## 六、怎么执行：拿一个具体场景走一遍

假设我现在要让多 Agent 帮我把一个 Python 项目从 3.10 升到 3.12，涉及几十个依赖、上千行代码，还有一套不太完整的测试。这种规模就值得动用多 Agent 了。

如果按"角色名"拆，很容易拆成一个"Python 升级专家 Agent"加一个"测试专家 Agent"。两个 Agent 共享同一个仓库，共享同一份对话上下文。结果会跟我前面那个 architect/coder/reviewer 翻车故事一模一样。

按 harness 的思路拆就完全不一样了。先有一个 planner 跑过整个仓库，产出一份变更清单和一份新版本不兼容点的文档。它不写代码，它的产物就是这两份文件。接着进入 builder，它的输入只有 planner 给的那两份文件加上当前文件 diff，看不到 planner 的中间思考；它只做一件事，按清单一项项改。每改完一个模块，breaker 启动。breaker 的 spec 不是"怎么改"，是"找出这次改动可能引入的回归"，它能跑测试、能查 deprecated API 列表、能比对依赖更新日志，但它不能改代码。verifier 是最后一道，跑完整 test suite 加上 mypy 严格模式，输出一个二进制结论：能合还是不能合。

这套拆法里，五条差异都自然到位。每个 Agent 的输入物理上不同（信息差异），每个能调的工具集物理上不同（工具差异），改代码的不能验证、验证的不能改代码（权限差异），builder 想"完成"和 breaker 想"挑刺"是相反的目标（目标差异），最后所有结论都落在能跑的测试和 mypy 报告上（验证差异）。这一条流水线没有任何一个 agent 的 prompt 里写"你是 XX 专家"，但它已经是一个能用的多 Agent 系统。

不是所有任务都得这么拆。研究和写作任务的边界不一样，researcher 只产事实和反例，writer 只能用 researcher 给的材料。自动化和个人助理任务的边界更多围绕权限切，intent parser 理解需求，policy checker 判风险，executor 干低风险动作，approver 把守高风险关口。但骨架都是同一个：先想清楚认知边界和责任边界在哪里，再决定要不要多 Agent。

总结来看，就是以下三个点：

**先选载体**。短任务和小修改不需要 Kanban，对 Codex 或 Claude Code 一来一回就够。流程稳定的中型任务用 harness（Trellis 已经是成熟样本）。多任务长期化、跨多人多机的才上 Kanban。

**先做差异**。在写任何 agent 角色 prompt 之前，先确认每个 agent 的信息源、工具和权限是不是真的不同。如果不是，把它合并回单 Agent。

**先把状态外化**。任务对象、产物、状态机和审批点放进文件或数据库，不要放进对话。这一步做好了，多 Agent 之间的交接才有依据。

## 七、什么才算真正的多 Agent 协作

判断一个多 Agent 方案是不是真的，有一个朴素的标准：把"多个 Agent"这层去掉之后，系统会失去某种真实机制，而不只是少几个发言者。去掉"安全 reviewer"以后只是少了一段安全角度的评论，那它可能就是装饰；去掉它以后危险命令拦不住、权限策略没人查、发布流程过不去，那它就是系统角色。区别只在这里。

工程上可以下一个更紧的定义：多 Agent 协作是多个执行单元的协作，每个单元有自己的上下文、输入、工具、权限和目标，它们围绕可检查的 artifact 运转，靠明确的状态机和验证机制完成交接，并在关键节点把人类拉进来。这个定义里没有"专家团""智慧涌现""群体智能"这些漂亮词，因为它们太容易误导。要紧的是 context、tool、permission、objective、artifact、state、verification 和 human-in-the-loop。这刚好就是 harness 工程那张老清单。

按这个标准看，subagent 是有效但短生命周期的多 Agent；harness pipeline（Trellis 是典型）是更可控的多 Agent；Kanban 是更持久、更可恢复的多 Agent。"大佬开会"式专家团除非配上能用的工具、产物和验证，否则更多是启发式 brainstorming，称不上可靠工作流。

## 八、Hermes Kanban 的价值和边界

Hermes Kanban 的价值在于提供了一种更工程化的多 Agent 落地路线。它承认 Agent 会失败，所以有 heartbeat 和 reclaim；承认任务会长期存在，所以有 SQLite-backed durable board；承认角色需要边界，所以有 profile 和 worker identity；承认人类仍然重要，所以支持 blocked 和 review-required 这样的状态；承认工作流不是聊天，所以把任务变成 board 上的 card。

它也有边界。一个人和 Codex 高密度结对编程，Kanban 未必更好；一次性小任务，Kanban 只会增加流程成本；只需要在手机上按确认键的场景，tmux send-keys 可能更简单；没有明确产物和验收标准的"开放式专家讨论"，Kanban 也变不出质量来。Kanban 只在任务天然包含多角色、多阶段、多产物和多审批的恢复需求时才值得引入。

这也是我对多 Agent 的最终判断：默认单 Agent，必要时 subagent，流程稳定时上 harness（Trellis 那种），多任务长期化时上 Kanban。不要从"我想用多 Agent"出发，要从"我的任务里有没有真实的认知边界、权限边界、验证边界和状态边界"出发。这些边界存在，多 Agent 才不至于沦为绣花枕头。

## 结语

多 Agent 真正值得期待的方向是把 AI 工作流变成可拆解、可验证、可恢复、可审计的任务系统，而不是让一群 AI 角色像公司高管一样开会。人类组织协作的精髓也不在 title，在分工和责任、反馈和审核、产物和制度上。AI 多 Agent 学 title 就会浮夸，学 harness 才可能有用。

Hermes Kanban 和 Trellis 各自从一端出发，朝同一个方向收敛。一个从"长任务怎么活下去"出发，做出了 SQLite 任务板加 worker identity；一个从"代码任务怎么不互相辩护"出发，做出了 JSONL curation 加 sub-agent 隔离。两者都没有大佬开会，也没让 AI 扮演任何 title，但都已经是可以工作的多 Agent 系统。它们不是答案的全部，但提示了正确的问题：当 AI 不再只是回答问题，而是开始长期执行任务时，到底应该怎么管理任务、角色、状态、失败和人类审批？

这个问题比"几个 Agent 谁更像专家"重要得多。

## 引用

- Hermes Agent 官方文档 — Kanban (Multi-Agent Board)：[hermes-agent.nousresearch.com](https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban)
- Hermes Agent v0.13.0 Release Notes (Tenacity Release)：[github.com/NousResearch/hermes-agent](https://github.com/NousResearch/hermes-agent/blob/main/RELEASE_v0.13.0.md)
- Vibe Kanban — Orchestrate AI Coding Agents：[vibekanban.com](https://vibekanban.com/)
- Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657)：[arxiv.org/abs/2503.13657](https://arxiv.org/abs/2503.13657)
- Which Agent Causes Task Failures and When? (arXiv 2505.00212)：[arxiv.org/abs/2505.00212](https://arxiv.org/abs/2505.00212)