§22八种协作模式与按卡片控成本

Eight Collaboration Patterns and Per-Card Cost Control

上一节我们看清了 Kanban 那个「笨内核」。这一节落到地上：同样一套 tasks + links + comments，能拼出八种完全不同的多Agent协作形态。更有意思的是，每张卡片可以单独钉一个模型，多Agent的成本控制，最后落到了一张张卡片上。

没有新原语，只有新组合

读到这里你可能会有个预期：要讲八种协作模式，那底层是不是得有八套机制？

恰恰相反。Hermes 的设计文档里把这八种模式叫 P1 到 P8，每一种都是从同一套零件里拼出来的：任务、任务之间的依赖链接、任务上的评论、谁负责（assignee）、在哪个工作区跑。没有为「投票」造一个投票引擎，也没有为「流水线」造一个流水线引擎。

我觉得这才是这套设计最值得学的地方。很多人设计多Agent系统，习惯一个场景配一个新功能，最后系统臃肿到没人能维护。Hermes 反过来，先把原语压到最少，再用组合去覆盖场景。

先把八种模式摆出来，你扫一眼就能找到自己想要的那种。

八种里我特别想拎出来讲的是 P1、P3 和 P8，因为它们最容易暴露一个新手陷阱。

P1 扇出：并发不等于「进程内分身」

Fan-out 听起来最简单：把一个大活儿切成 N 块，同时开干。但这里藏着 Hermes 和很多同类系统的根本分歧，也就是上一节（§21）那个「进程内分身 vs 独立 OS 进程」的老问题。进程内分身的命挂在主 Agent 身上，主 Agent 一结束就被静默杀掉，活干到一半也照样蒸发。

Hermes 的 P1 不这么干。它扇出的每一个任务，都是一个独立的操作系统进程。调度器原子地认领全部 N 个任务，spawn 出 N 个真正的进程。它们谁也不依赖谁，谁崩了不影响别人，崩了的那个还能被重新认领跑一遍。

要点：「并发」有两种长法。一种是进程内分身（脆弱，依赖上游 SDK 的生命周期），一种是各自独立的 OS 进程（崩了能恢复，结束能审计）。Hermes 全程选后者，这是上一节「笨内核」哲学在协作层的延续。

P3 投票：让几个 Agent 吵一架，再请一个来裁决

P3 的形状很优雅：N 个 Agent 拿到同一个任务描述，但负责人不同（可以是不同模型、不同 profile），各自独立产出一份答案。然后有一个聚合器任务，从这 N 个任务链接过来，把几份答案放一起，挑一个或者合一个。

这招对付那种「一次不一定对」的任务特别管用。比如让三个 Agent 各写一版方案，再让第四个当评审。比单个 Agent 闷头写一版要稳得多。

这里顺带提一个 Hermes 内置的高层封装，叫 swarm。上一节说过，hermes kanban swarm底下没有第二个调度器，它就是 P1 扇出加 pipeline 加一个共享黑板拼出来的「组合糖」。一条命令就能拉出「并行专家 + 一个把关的验证者 + 一个收尾的综合者」这套阵型。验证者只在证据足够时才放行，否则把卡片打回去并列清楚还差什么。

P8 舰队耕作：一个 Agent 管 50 个账号

P8 是设计文档里的旗舰例子，也是最能说明「不要为这事造专门工具」的一个。

设想你要管 50 个社交账号，每隔几小时各自跑一轮维护。换成传统思路，你大概会去找一个 RPA 工具，配一堆流程。Hermes 的做法是：一个专家 profile，N 个并行任务，每个账号一个独立的工作区目录，靠定时任务每隔一段时间为每个账号生成一张卡片。

一个 insta-manager profile

cron 每轮为每账号建卡每账号一个独立工作区失败靠认领锁过期自动回收哪个账号那一轮挂了，它的认领锁到点过期，下一轮自动重新认领重跑。每个账号的历史都留在任务事件日志里，可审计。设计文档里有句话我很喜欢：这是 RPA 形状的工作流，但不用 RPA 工具，没有专用基础设施正是它的特性，不是缺陷。

按卡片钉模型：成本控制落到最细的颗粒度

讲完协作形状，来讲钱。多Agent一跑起来，token 消耗是单Agent的好几倍，这是真实痛点。

4月的 Hermes 已经能「不同子 Agent 用不同模型」，但那是父 Agent 在委派时一锤子定的。现在升级成了更细的颗粒度：每一张卡片，都可以独立指定自己跑哪个模型。

对应到任务表上就是一个model_override字段。调度器 spawn 这个任务的 worker 进程时，如果卡片上钉了模型，就在命令行里加上-m把它带进去。后来卡片上又多了provider_override和reasoning_effort两个字段，连用哪家服务商、推理开多深都能一张卡一张卡地定。

官方的原话是「便宜模型干样板活，贵模型干难的子任务」。这句话背后是一笔很实在的账：一个十几张卡片的工作流，可能只有两三张真正需要顶配模型，剩下的用便宜模型跑完全够。多Agent的经济学，最后落到了你愿不愿意一张张卡去调模型上。

核心建议

设计自己的 Agent 团队时，先别急着所有卡片都上最强模型。把任务按「难度」分一遍，样板活和检索活交给便宜模型，留下顶配额度给真正吃推理的环节。一个跑得勤的工作流，这笔差价积累起来很可观。

goal_mode：把 Ralph 循环收进了内核

还有一个我觉得很妙的能力，叫 goal_mode。

玩过 Agent 的人可能听过 Ralph 这个技巧：让 Agent 反复跑同一个目标，每跑一轮检查一下到没到位，没到就接着跑，直到搞定。以前这得你自己在外面搭个循环。

Hermes 把它做成了卡片上的一个开关。一张卡片开了 goal_mode，每跑完一轮，会有一个辅助裁判去比对这轮的产出和卡片的标题、正文，没完成就把续写提示喂回同一个会话，接着跑。直到裁判点头，或者耗尽轮数预算（默认 20 轮）。

这就是上一节那个思路的又一个例子：Ralph 不是被做成一个独立的运行时，而是被收进卡片，变成一个字段。你要用就打开它，不用就当它不存在。

横向扩展：多看板、多租户、多 gateway

最后说说规模。当你的Agent团队从「几张卡」长到「几条业务线」，Hermes 给了三层隔离手段，颗粒度从粗到细。

官方一句话把前两层的关系说清了：租户是软过滤，看板才是硬隔离边界。同一个专家 fleet，用不同的 tenant标签服务多个业务，靠工作区路径和记忆前缀把数据隔开；真要彻底分家、谁也别看见谁，就开两个看板。

多 gateway 这层有个容易踩的坑：可以同时跑多个 gateway 进程，但调度器只能有一个持有，其余都得关掉自己的调度。原因不复杂：多个进程同时去抢同一个 SQLite 连接，会放大读写争用。这种「内核保持笨、扩展性靠组合」的取舍，到这一层还是一以贯之。

到v0.22这层又简化了一步：默认一台机器只跑一个 gateway，所有 profile 都挂在它上面（老用户用hermes gateway migrate --multiplex迁过来），「谁持有调度器」的问题在大多数场景里自然就没了。真要跨多台机器跑，官方单独写了一份多 gateway 的文档。

回到一个问题：你该怎么设计自己的团队

把这一节串起来，其实是一张可以照着填的设计清单。

先问形状：你的活儿是批量并行（P1），还是有先后顺序的流水线（P2），还是需要多方案投票（P3），还是要长期跨天累积（P4）？再问人机边界：哪些步骤要停下来等你拍板（P5）？然后问成本：哪些卡片用便宜模型，哪些卡片值得上顶配？最后问规模：要不要开多个看板把业务分家？

这套东西最让我服气的地方，是它没逼你学一堆新概念。八种模式、按卡片控成本、横向扩展，底下还是上一节那个笨内核：任务、链接、评论、负责人、工作区。你设计团队，本质上只是在这几个零件上做排列组合。

下一节我们离开协作层，去看 Hermes 本身装在哪、这些进程的命令又落在哪台机器上。放出这么多并行进程之后，这件事就绕不开了。