## 从 Hermes Kanban 看多 Agent 协作：真正的协作必须回到任务系统 --- ### 一、Hermes Kanban 的出现：不是为了让 Agent 更多，而是为了让任务更稳定 **Hermes Kanban 这个东西有意思，不是因为它又发明了一个“多 Agent 专家团”，而是因为它把多 Agent 问题从聊天层拉回了任务系统层。** 过去一年多，AI 圈里对多 Agent 协作的想象非常热烈：一个 Agent 当产品经理，一个 Agent 当架构师，一个 Agent 当程序员，一个 Agent 当 Reviewer，大家围坐一桌，各自发表意见，最后综合出一个更好的方案。这个画面很诱人，因为它借用了人类组织里的协作隐喻；然而在实践中，它也很容易变成“几个同源模型换着人设说话”，热闹有余，工程增益不足。 Hermes Kanban 的历史缘由，正是在这种背景下出现的。Hermes 本身是 Nous Research 做的本地化 Agent 框架，它原本就有 profile、skill、gateway、记忆、工具调用等能力；而 Kanban 的加入，说明 Hermes 团队意识到一个关键问题：**真正难的不是让一个 Agent 再启动几个 subagent，而是让长期任务在多个 Agent、多个 profile、多个进程、多个上下文之间可靠流转。** 官方文档对 Hermes Kanban 的定义很直接：它是一个所有 Hermes profiles 共享的 durable task board，每个任务是 `~/.hermes/kanban.db` 里的一行，每次交接都可读写，每个 worker 是一个有自己身份的完整 OS process。这个定义非常工程化，它强调的是持久化、身份、交接、任务行，而不是“智能体人格”。([Hermes Agent](https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban?utm_source=chatgpt.com "Kanban (Multi-Agent Board) - Hermes Agent")) 到了 Hermes v0.13.0，Kanban 被放进 “Tenacity Release” 的核心特性里。这个 release 的措辞很值得玩味：Hermes Agent now finishes what it starts。它说 Kanban 作为 durable multi-agent board，提供 heartbeat、reclaim、zombie detection、auto-block、per-task retries、hallucination recovery 等机制。**这说明 Hermes Kanban 的设计目标不是“让 Agent 讨论得更精彩”，而是解决 Agent 做长期任务时最现实的问题：跑着跑着死了怎么办，任务半截退出怎么办，worker 幻觉完成怎么办，多个 Agent 怎么接手，状态怎么恢复。**([GitHub](https://github.com/NousResearch/hermes-agent/blob/main/RELEASE_v0.13.0.md?utm_source=chatgpt.com "hermes-agent/RELEASE_v0.13.0.md at main")) 所以，理解 Hermes Kanban 的第一原则是：**它不是多 Agent 的表演舞台，而是 Agent 工作流的任务底座。** 这和传统“专家团式”多 Agent 有根本区别。专家团式多 Agent 通常把重点放在角色 prompt 上，比如“你是战略专家”“你是安全专家”“你是增长专家”；Hermes Kanban 则把重点放在任务对象、状态机、worker 身份、持久化数据库、heartbeat、blocked/done/retry 这些东西上。前者是语言层的协作想象，后者是运行时层的协作约束。 --- ### 二、Hermes Kanban 的设计准则：任务外化、角色边界、状态持久、人工介入 **Hermes Kanban 背后的核心理念，可以概括为四个词：任务外化、角色边界、状态持久、人工介入。** 这四点也正是多 Agent 如果想从概念走向工程，必须补上的东西。 第一，**任务外化**。在 Codex 或 Claude Code 这样的交互式 coding agent 中，任务经常隐含在对话上下文里。用户说了一段需求，Agent 读代码、改文件、跑测试、继续修复；整个过程很流畅，但任务本身没有被抽象成一个稳定对象。任务目标、约束、验收标准、当前状态、阻塞原因、产物位置，都散落在聊天记录、terminal scrollback、git diff 和用户脑子里。一个 session 如果很短，这没问题；但当任务跨越几个小时、几天，或者涉及多个项目、多个执行器、多个审批点，这种隐式状态就会变得脆弱。Hermes Kanban 的第一步，就是把任务变成数据库里的 card：任务有 id，有 assignee，有状态，有 comment，有 run，有依赖，有 workspace。**这意味着任务不再依赖某个模型上下文是否还活着，而成为可以被多个执行者读取、接手、恢复和审查的外部对象。** 第二，**角色边界**。Hermes 里的不同 profile 可以有不同的 SOUL.md、不同技能、不同工具权限和不同工作目录。真正有意义的角色差异，不是“你说话像架构师，我说话像测试工程师”，而是“你能看什么、能改什么、能调用什么工具、能不能完成任务、何时必须 block 等待审核”。一个 researcher 如果只能读资料不能改代码，一个 engineer 可以改 worktree 但不能发布，一个 reviewer 可以看 diff 但不能直接修改，一个 publisher 必须等待 approval token 才能发出结果，这些角色才开始有真实边界。**角色不是人格，而是权限、输入、输出和责任的组合。** 第三，**状态持久**。多 Agent 最大的问题之一是状态漂移。一个子 Agent 说自己完成了，但它到底完成了什么？另一个 Agent 接手时，能不能知道上游产物在哪里？如果 worker 掉线，任务是重试、阻塞、还是转派？如果模型以为自己完成了，但实际上测试没跑，系统怎么发现？Hermes v0.13.0 强调 heartbeat、reclaim、zombie detection、auto-block、retry budgets，正是因为实际运行中的 Agent 系统不是一个“聪明回答问题”的模型，而是一组会失败、会断线、会误判、会跑偏的进程。([GitHub](https://github.com/NousResearch/hermes-agent/blob/main/RELEASE_v0.13.0.md?utm_source=chatgpt.com "hermes-agent/RELEASE_v0.13.0.md at main")) **多 Agent 的工程难点，首先是分布式任务系统的难点，其次才是 prompt 设计的难点。** 第四，**人工介入**。Hermes Kanban 的价值不是全自动，而是让人类能在正确的抽象层介入。人类不应该时时盯着某个 terminal，等待 Codex 问“是否继续”；更理想的交互是看到一个 blocked/review-required inbox：哪个任务需要确认，为什么停住，产物在哪里，风险是什么，下游任务是否能开始。**Kanban 的强点不是“替人做决定”，而是把人类审批点变成清晰、可追踪、可恢复的状态节点。** --- ### 三、多 Agent 的历史发展：从角色扮演，到任务编排，再到运行时系统 **多 Agent 概念的流行，很大程度上来自一个朴素直觉：既然一个 AI 会犯错，那多个 AI 互相讨论、互相审查，应该更可靠。** 这个直觉并非完全错误。人类组织确实通过分工、审查、对抗和复核来降低错误；工程团队也确实有 architect、developer、reviewer、QA、SRE、安全审计等角色。把这种结构迁移到 AI 系统里，是非常自然的想法。 早期多 Agent 实践里，最常见的是“角色扮演式协作”。一个 Agent 被设定为 CEO，一个是 CTO，一个是产品经理，一个是程序员，一个是测试员；或者一个是批判者，一个是乐观者，一个是专家，一个是反方。它的演示效果往往很好，因为多个角色轮流发言，很像一个小型组织在工作。然而问题也很快暴露：**这些角色通常共享同一个底座模型、同一份上下文、同一套知识分布，差异主要来自 prompt 的风格，而不是来自真实的信息源、工具能力、权限边界和验证机制。** 于是第二阶段开始强调 subagent 和 harness。也就是不再让几个 Agent 自由开会，而是把任务拆成几个明确子任务，每个子任务有独立上下文、明确输入、明确输出，最后由 orchestrator 汇总。这比“专家团开会”靠谱很多，因为它至少引入了上下文隔离和任务分解。比如调研一个技术方案，可以让一个 subagent 读官方文档，一个读 GitHub issue，一个读社区评价，一个读源码结构；或者 debug 一个问题，让一个 Agent 看 recent diff，一个 Agent 看测试日志，一个 Agent 看依赖变更。**这里的收益来自并行探索和上下文隔离，而不是来自“人格多样性”。** 第三阶段，也就是 Hermes Kanban、Vibe Kanban、operator 这类工具所代表的方向，则进一步把多 Agent 推向运行时系统。Vibe Kanban 明确把自己定位为 orchestrate AI coding agents，强调 issue tracking、coding agent 在后台解决 issue、状态自动更新、PR review 等能力。其 GitHub 项目也强调 plan with kanban issues、run coding agents in workspaces、review diffs and leave inline comments。([Vibe Kanban](https://vibekanban.com/?utm_source=chatgpt.com "Vibe Kanban - Orchestrate AI Coding Agents")) 这说明行业正在从“让 Agent 聊天协作”转向“让 Agent 围绕 issue、workspace、diff、PR、review 状态协作”。**这个转变非常关键：多 Agent 的中心不再是对话，而是 artifact 和 workflow。** --- ### 四、为什么多 Agent 落地经常变成绣花枕头？ **多 Agent 之所以容易变成绣花枕头，根本原因是它经常借用了组织协作的外壳，却没有实现组织协作的机制。** 人类团队之所以能协作，不是因为每个人有不同 title，而是因为每个人有不同经验、不同信息来源、不同工具、不同责任、不同激励、不同审核权，并且最终要对可观察产物负责。如果 AI 多 Agent 只复制 title，不复制这些机制，那它当然会变成 cosplay。 第一个问题是，**角色名不能创造能力**。告诉模型“你是世界级安全专家”，确实可能让它更关注权限、边界、攻击面，但这不会让它真的拥有独立安全团队的经验、工具和长期案例库。它只是把同一个模型的注意力调到某个方向。这个技巧不是没用，但远不足以支撑“专家团”这个隐喻。真正的安全 reviewer，应该有权限检查规则、攻击用例、静态分析、危险操作列表、历史事故样本，以及强制阻断能力。否则它只是用安全专家的语气说话。 第二个问题是，**同源模型容易共振，而不是互补**。如果几个 Agent 都来自同一个模型、同一个提示体系、同一份资料，它们的错误模式高度相关。一个 Agent 产生了似是而非的解释，另一个 Agent 在协作语境下可能礼貌地接受并补充，第三个 Agent 再综合成一个更自信的结论。表面上看是多方验证，实际上可能是共识幻觉。多 Agent 并不天然降低幻觉；如果设计不好，它会把幻觉包装得更像组织共识。 第三个问题是，**讨论不是验证**。几个 Agent 都说“这个方案合理”，不等于它合理；一个 Reviewer Agent 说“没有发现问题”，不等于没有问题。验证必须落到外部世界：测试有没有通过，事实有没有来源，diff 是否符合约束，命令是否真的执行，权限是否真的隔离，反例是否真的覆盖，用户是否真的批准。学术研究也已经开始系统性指出这个问题。一篇 2025 年的多 Agent 系统失败研究分析了 5 个流行 MAS 框架和 150 多个任务，发现多 Agent 相比单 Agent 的 benchmark 性能提升并不总是显著，并把失败模式归为 specification/system design failures、inter-agent misalignment、task verification and termination 三大类。**这说明多 Agent 的瓶颈不是“角色 prompt 写得不够好”，而是规格、协调、验证和终止条件这些系统问题。**([arXiv](https://arxiv.org/abs/2503.13657?utm_source=chatgpt.com "Why Do Multi-Agent LLM Systems Fail?")) 第四个问题是，**协作成本可能高于收益**。多 Agent 会引入通信成本、合成成本、状态管理成本、失败归因成本。一个单 Agent 出错，你可以沿着一个上下文排查；多个 Agent 出错，你要判断到底是上游任务规格错了、某个 Agent 理解错了、产物交接错了、synthesizer 合成错了，还是 verifier 没有验证出来。关于多 Agent 失败归因的研究显示，即使识别哪个 Agent 导致失败、在哪一步导致失败，本身也是困难任务；相关研究中最佳方法识别失败责任 Agent 的准确率只有 53.5%，定位失败步骤更低到 14.2%。([arXiv](https://arxiv.org/abs/2505.00212?utm_source=chatgpt.com "Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems")) **当系统复杂度上升得比可靠性更快，多 Agent 就会从增强工具变成故障放大器。** --- ### 五、多 Agent 的本质问题：不是“几个人合作”，而是“如何制造有效差异” **真正的多 Agent 协作，核心不是多个 Agent，而是多个有效差异。** 如果没有有效差异，一个 Agent 拆成五个 Agent，只是多花 token、多制造噪声。有效差异至少包括五类。 第一是**信息差异**。不同 Agent 应该接触不同输入：一个看官方文档，一个看源码，一个看 issue，一个看 benchmark，一个看用户反馈。这样它们的分歧才来自信息源，而不是来自人格设定。第二是**工具差异**。一个 QA Agent 如果不能跑测试，它就不是 QA，只是发表 QA 意见的人；一个 SRE Agent 如果不能读日志和指标，它也不是 SRE，只是从 SRE 角度说话。第三是**权限差异**。能读不能写、能写不能发布、能生成不能发送、能建议不能执行，这些边界比“你是什么专家”更重要。第四是**目标差异**。builder 要完成，breaker 要破坏，verifier 要证明，reviewer 要阻断风险；这些目标天然有张力，因此能产生真实审查。第五是**验证差异**。每个 Agent 的产出必须能被外部 artifact 检查，而不是只被另一个 Agent 语言评价。 所以，多 Agent 的本质不是模拟公司，而是构造一个更可靠的认知系统：**通过上下文隔离避免路径污染，通过目标冲突制造审查张力，通过工具权限限制错误半径，通过外部验证约束语言幻觉，通过持久状态支持长期任务。** 这才是它可能超过单 Agent 的地方。 --- ### 六、应该怎样做任务拆解？ **好的任务拆解，不是把一个任务切成很多碎片，而是沿着“认知边界”和“责任边界”切开。** 很多多 Agent 系统拆解失败，是因为它只按步骤拆，比如第一步调研、第二步写作、第三步审查；这当然有用，但还不够。更好的拆解要问：这个任务里有哪些不同评价标准？哪些环节需要独立证据？哪些地方风险最高？哪些产物必须被验证？哪些操作需要权限隔离？ 对于工程任务，一个比较稳的拆法是 planner / builder / breaker / verifier / integrator。Planner 不写代码，只定义目标、边界和验收标准；Builder 只负责最小实现；Breaker 专门找失败路径、边界条件和安全绕过；Verifier 用测试、静态检查、运行结果验证；Integrator 负责综合、取舍、最终交付。**这里最关键的是 Builder 和 Breaker 的对抗关系。** 如果同一个 Agent 写完代码再审代码，它很容易为自己的实现辩护；但如果另一个 Agent 被明确要求“只找它如何失败”，它就更可能产生有效分歧。 对于研究和写作任务，拆法应该是 researcher / analyst / critic / writer / editor。Researcher 不写文章，只产事实、来源、反例、不确定性；Analyst 不扩写，只抽象结构和矛盾；Critic 不追求完整方案，只找 unsupported claims 和反例；Writer 只能使用已有材料写成文章；Editor 只处理结构、语言、表达和读者路径。**这能避免一种常见问题：模型一边调研一边写作，最后文章很顺，但事实支撑松散。** 对于自动化和个人助理任务，拆法应该围绕权限，而不是围绕人设。比如 Butler 这种本地助理，可以有 intent parser、policy checker、executor、logger、approver、reviewer。Intent parser 只理解需求，policy checker 判断风险，executor 执行低风险动作，approver 处理高风险确认，logger 留痕，reviewer 定期审查误操作。**这类多 Agent 不一定更聪明，但更安全，因为它把危险动作的路径拆开了。** --- ### 七、什么才是真正的多 Agent 协作？ **真正的多 Agent 协作有一个非常朴素的标准：如果去掉多个 Agent，系统是否会失去某种真实机制，而不只是少几个发言者。** 如果去掉“安全 reviewer”以后，只是少了一段安全角度的评论，那它可能是装饰；如果去掉它以后，危险命令无法被拦截、权限策略无人检查、发布流程不能通过，那它就是系统角色。区别就在这里。 我会给真正的多 Agent 协作下一个工程定义：**多个具有独立上下文、不同输入/工具/权限/目标的执行单元，围绕可检查 artifact，通过明确状态机和验证机制完成任务交接，并允许人类在关键节点介入。** 这个定义里没有“专家团”“智慧涌现”“群体智能”这些漂亮词，因为它们太容易误导。真正要紧的是 context、tool、permission、objective、artifact、state、verification、human-in-the-loop。 从这个标准看，subagent 是有效但短生命周期的多 Agent；harness pipeline 是更可控的多 Agent；Kanban 是更持久、更可恢复的多 Agent；而“大佬开会”式专家团，除非它有真实工具、真实产物和真实验证，否则更多是启发式 brainstorming，而不是可靠工作流。 --- ### 八、回到 Hermes Kanban：它的真正价值和边界 **Hermes Kanban 的价值，不是证明多 Agent 一定比单 Agent 强，而是提供了一种更工程化的多 Agent 落地路线。** 它承认 Agent 会失败，所以有 heartbeat 和 reclaim；它承认任务会长期存在，所以有 SQLite-backed durable board；它承认角色需要边界，所以有 profile 和 worker identity；它承认人类仍然重要，所以支持 blocked、comment、review-required 这样的状态；它承认工作流不是聊天，所以把任务变成 board 上的 card。 但它也有边界。对于一个人和 Codex 高密度结对编程，Kanban 未必更好；对于一次性小任务，Kanban 只会增加流程成本；对于只需要手机按确认键的场景，tmux send-keys 可能更简单；对于没有明确产物和验收标准的“开放式专家讨论”，Kanban 也不能凭空制造质量。**Kanban 只有在任务天然包含多角色、多阶段、多产物、多审批、多恢复需求时，才值得引入。** 这也是我对多 Agent 的最终判断：**默认单 Agent，必要时 subagent，流程稳定时 harness，多任务长期化时 Kanban。** 不要从“我想用多 Agent”出发，而要从“我的任务里有没有真实的认知边界、权限边界、验证边界和状态边界”出发。只有这些边界存在，多 Agent 才不是绣花枕头。 --- ## 结语：多 Agent 的未来不是 AI 公司开会，而是任务系统工程 **多 Agent 真正值得期待的方向，不是让一群 AI 角色像公司高管一样开会，而是把 AI 工作流变成可拆解、可验证、可恢复、可审计的任务系统。** 人类组织协作的精髓也不是 title，而是分工、责任、反馈、审核、产物和制度。AI 多 Agent 如果只学 title，就会浮夸；如果学制度，就可能有用。 Hermes Kanban 的意义就在这里：它把多 Agent 从“角色扮演”往“任务操作系统”方向推了一步。它不一定是最终答案，也不一定现在就成熟到适合所有人使用，但它提出了一个很正确的问题：**当 AI 不再只是回答问题，而是开始长期执行任务时，我们到底应该如何管理任务、角色、状态、失败和人类审批？** 这个问题比“几个 Agent 谁更像专家”重要得多。真正的多 Agent 协作，不是让 AI 变成一个热闹的会议室，而是让 AI 进入一套严肃的工程流程：有人规划，有人执行，有人破坏，有人验证，有人审批；每一步都有产物，每个产物可检查，每次失败可追踪，每个高风险动作可阻断。**只有到了这个层面，多 Agent 才从概念秀变成生产力。**