📚 系列导航：上一篇 Hermes Agent Swarm 调度指南 已经讲清“Swarm 与子 Agent 调度原理”；本篇聚焦 Hermes Agent 多 Agent 协作模式；下一篇 Hermes Agent 安装与部署教程 继续学习“安装与部署教程（Windows、macOS、Linux）”。
先给结论：先选协作形状，再给每张卡片选模型。 tasks + links + comments 这组基础原语可以拼出扇出、流水线、投票、人在环等模式；模型成本则通过卡片级覆盖控制，不必全员使用最贵模型。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
Hermes 多 Agent 的八种协作模式
读到这里你可能会有个预期：要讲八种协作模式，那底层是不是得有八套机制？
恰恰相反。Hermes 的设计文档里把这八种模式叫 P1 到 P8，每一种都是从同一套零件里拼出来的：任务、任务之间的依赖链接、任务上的评论、谁负责（assignee）、在哪个工作区跑。没有为「投票」造一个投票引擎，也没有为「流水线」造一个流水线引擎。
我觉得这才是这套设计最值得学的地方。很多人设计多 Agent 系统，习惯一个场景配一个新功能，最后系统臃肿到没人能维护。Hermes 反过来，先把原语压到最少，再用组合去覆盖场景。
先把八种模式摆出来，你扫一眼就能找到自己想要的那种。
| 编号 | 模式 | 形状 | 典型用途 |
|---|---|---|---|
| P1 | Fan-out 扇出 | 同一负责人,N 个无依赖的兄弟任务,并发跑 | 批量处理:一次审 50 个文件 |
| P2 | Pipeline 流水线 | 角色专精链,按序链接 | 调研→编辑→撰写,各司其职 |
| P3 | Voting 投票/法定多数 | N 个同题不同人,外加一个聚合器 | 多方案产出后择优合并 |
| P4 | Long-running journal 长期日志 | 同一负责人 + 同一共享目录 + 循环任务 | 日报周报,跨天累积进同一个库 |
| P5 | Human-in-the-loop 人在环 | 阻塞→提问→人回答→解除→重跑 | 拿不准的地方停下来等你拍板 |
| P6 | @mention 委派 | 消息里 @某个 profile,自动建卡指派 | 对话中随手把活儿丢给某个 Agent |
| P7 | Thread-scoped 线程工作区 | 把工作区钉到当前对话所在目录 | 这个项目的活儿就在这个项目里干 |
| P8 | Fleet farming 舰队耕作 | 一个专家 profile + N 个并行任务 + 每个对象一个目录 | 一个 Agent 管 50 个账号 |
八种里我特别想拎出来讲的是 P1、P3 和 P8，因为它们最容易暴露一个新手陷阱。
P1 Fan-out：独立进程并行任务
Fan-out 听起来最简单：把一个大活儿切成 N 块，同时开干。但这里藏着 Hermes 和很多同类系统的根本分歧，也就是上一节（§16）那个「进程内分身 vs 独立 OS 进程」的老问题。进程内分身的命挂在主 Agent 身上，主 Agent 一结束就被静默杀掉，活干到一半也照样蒸发。
Hermes 的 P1 不这么干。它扇出的每一个任务，都是一个独立的操作系统进程。调度器原子地认领全部 N 个任务，spawn 出 N 个真正的进程。它们谁也不依赖谁，谁崩了不影响别人，崩了的那个还能被重新认领跑一遍。
要点：「并发」有两种长法。一种是进程内分身（脆弱，依赖上游 SDK 的生命周期），一种是各自独立的 OS 进程（崩了能恢复，结束能审计）。Hermes 全程选后者，这是上一节「笨内核」哲学在协作层的延续。
P3 Voting：多方案生成与聚合评审
P3 的形状很优雅：N 个 Agent 拿到同一个任务描述，但负责人不同（可以是不同模型、不同 profile），各自独立产出一份答案。然后有一个聚合器任务，从这 N 个任务链接过来，把几份答案放一起，挑一个或者合一个。
这招对付那种「一次不一定对」的任务特别管用。比如让三个 Agent 各写一版方案，再让第四个当评审。比单个 Agent 闷头写一版要稳得多。
这里顺带提一个 Hermes 内置的高层封装，叫 swarm。上一节说过， hermes kanban swarm 底下没有第二个调度器，它就是 P1 扇出加 pipeline 加一个共享黑板拼出来的「组合糖」。一条命令就能拉出「并行专家+一个把关的验证者+一个收尾的综合者」这套阵型。验证者只在证据足够时才放行，否则把卡片打回去并列清楚还差什么。
P8 Fleet Farming：批量对象长期维护
P8 是设计文档里的旗舰例子，也是最能说明「不要为这事造专门工具」的一个。
设想你要管 50 个社交账号，每隔几小时各自跑一轮维护。换成传统思路，你大概会去找一个 RPA 工具，配一堆流程。Hermes 的做法是：一个专家 profile，N 个并行任务，每个账号一个独立的工作区目录，靠定时任务每隔一段时间为每个账号生成一张卡片。
哪个账号那一轮挂了，它的认领锁到点过期，下一轮自动重新认领重跑。每个账号的历史都留在任务事件日志里，可审计。设计文档里有句话我很喜欢：这是 RPA 形状的工作流，但不用 RPA 工具，没有专用基础设施正是它的特性，不是缺陷。
Hermes Kanban 卡片级模型成本控制
讲完协作形状，来讲钱。多 Agent 一跑起来，token 消耗是单 Agent 的好几倍，这是真实痛点。
两个月前的 Hermes 已经能「不同子 Agent 用不同模型」，但那是父 Agent 在委派时一锤子定的。现在升级成了更细的颗粒度：每一张卡片，都可以独立指定自己跑哪个模型。
对应到任务表上就是一个 model_override 字段。调度器 spawn 这个任务的 worker 进程时，如果卡片上钉了模型，就在命令行里加上 -m 把它带进去。
💡 推荐
写样板代码、跑格式化、做简单分类→钉便宜快模型，省钱省时间
⚠️ 不推荐
啃硬骨头、做关键推理、写核心方案→钉贵的强模型，该花的钱花
官方的原话是「便宜模型干样板活，贵模型干难的子任务」。这句话背后是一笔很实在的账：一个十几张卡片的工作流，可能只有两三张真正需要顶配模型，剩下的用便宜模型跑完全够。多 Agent 的经济学，最后落到了你愿不愿意一张张卡去调模型上。
💡 核心建议
设计自己的 Agent 团队时，先别急着所有卡片都上最强模型。把任务按「难度」分一遍，样板活和检索活交给便宜模型，留下顶配额度给真正吃推理的环节。一个跑得勤的工作流，这笔差价积累起来很可观。
Hermes Goal Mode 的持续执行机制
还有一个我觉得很妙的能力，叫 goal_mode。
玩过 Agent 的人可能听过 Ralph 这个技巧：让 Agent 反复跑同一个目标，每跑一轮检查一下到没到位，没到就接着跑，直到搞定。以前这得你自己在外面搭个循环。
Hermes 把它做成了卡片上的一个开关。一张卡片开了 goal_mode，每跑完一轮，会有一个辅助裁判去比对这轮的产出和卡片的标题、正文，没完成就把续写提示喂回同一个会话，接着跑。直到裁判点头，或者耗尽轮数预算（默认 20 轮）。
这就是上一节那个思路的又一个例子：Ralph 不是被做成一个独立的运行时，而是被收进卡片，变成一个字段。你要用就打开它，不用就当它不存在。
Hermes 多看板、Tenant 与 Gateway 隔离
最后说说规模。当你的 Agent 团队从「几张卡」长到「几条业务线」，Hermes 给了三层隔离手段，颗粒度从粗到细。
| 层级 | 隔离强度 | 怎么用 | 什么时候用 |
|---|---|---|---|
| 多看板 Boards | 硬边界 | 每个看板独立的数据库 + 工作区目录 + 调度视角 | 业务彻底分家,互不可见 |
| 多租户 Tenant | 软命名空间 | 看板内一个 tenant 标签做软过滤 | 一个专家团队服务多个业务 |
| 多 gateway | 进程级 | 多个 gateway 并发,但只有一个持有调度器 | 不同 profile 各跑各的,分散负载 |
官方一句话把前两层的关系说清了：租户是软过滤，看板才是硬隔离边界。同一个专家 fleet，用不同的 tenant 标签服务多个业务，靠工作区路径和记忆前缀把数据隔开；真要彻底分家、谁也别看见谁，就开两个看板。
多 gateway 这层有个容易踩的坑：可以同时跑多个 gateway 进程，但调度器只能有一个持有，其余都得关掉自己的调度。原因不复杂：多个进程同时去抢同一个 SQLite 连接，会放大读写争用。这种「内核保持笨、扩展性
靠组合」的取舍，到这一层还是一以贯之。
Hermes 多 Agent 团队设计清单
把这一节串起来，其实是一张可以照着填的设计清单。
先问形状：你的活儿是批量并行（P1），还是有先后顺序的流水线（P2），还是需要多方案投票（P3），还是要长期跨天累积（P4）？再问人机边界：哪些步骤要停下来等你拍板（P5）？然后问成本：哪些卡片用便宜模型，哪些卡片值得上顶配？最后问规模：要不要开多个看板把业务分家？
这套东西最让我服气的地方，是它没逼你学一堆新概念。八种模式、按卡片控成本、横向扩展，底下还是上一节那个笨内核：任务、链接、评论、负责人、工作区。你设计团队，本质上只是在这几个零件上做排列组合。下一节我们离开协作层，去看 Hermes 怎么把自己扔进操作系统的沙箱里—因为放出这么多并行进程之后，边界在哪，就成了一个绕不开的问题。
常见问题
Hermes Agent 多 Agent 适合哪些任务？
适合可以拆成并行批处理、顺序流水线、多方案评审、跨天日志或需要人工确认的任务。无法独立验收的小步骤不一定值得拆成多个 Agent。
Hermes 多 Agent 怎么节省模型成本？
先按卡片难度选模型，把格式化、分类和简单检索交给便宜模型，把强模型留给关键推理、评审和综合环节。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。