Hermes 多 Agent 方案实战：用 Kanban 编排 Swarm 协作流

1. 为什么单 Agent 干不完的活Hermes 要用 Kanban 编排如果你已经在用 Hermes 跑单 Agent 任务大概率遇到过这种局面一个需求里既有调研、又有编码、还要评审全塞给一个会话上下文越滚越长跑到一半工具调用次数打满结果还得从头再来。Hermes 的多 Agent 方案本质上是把「一个全能助手」拆成「一组有明确分工的 profile」再用 Kanban 看板把任务串成可追踪的流水线。它适合谁适合那些需要把多个 Agent 串成可追踪流水线的开发者尤其是任务之间有先后依赖、需要并行扇出、还想要审计轨迹和自动重试的场景。我实测下来Hermes 的多 Agent 协作有两种分发方式轻量的hermes -p chat直接分发和持久化的 Kanban 看板分发。前者适合一次性、串行的临时任务后者是 Hermes 自带的 SQLite 持久任务板跨 profile 共享任务被原子领取、可声明依赖、由指定 profile 在隔离工作区执行。本文就围绕 Kanban 编排 Swarm 协作流这条落地路径给出可复制的配置骨架和hermes -p chat启动命令并演示一轮多 Agent 任务分发与结果回收的验证动作。先明确环境基线Hermes Agent v0.15.1模型 mimo-v2-pro安装路径在C:\Users\Administrator\AppData\Local\hermes\hermes-agent。调度铁律只有一条只用hermes -p profile chat -q或 Kanban 看板分发禁止使用delegate_task。这条规则后面还会反复提到因为它直接决定了你的卡片会不会永远卡在 ready。2. TaoToken 前置给多 Agent 流水线备好模型入口多 Agent 协作最容易被忽略的成本是每个 profile 都要独立调用模型。调研、编码、评审、汇总四五个 Agent 并行跑起来请求量和 token 消耗是单 Agent 的好几倍。所以在正式编排之前我建议先把模型接入层统一好避免每个 profile 各配一套 Key后面排障时找不到是哪一路出的问题。TaoToken 在这里的角色是统一的模型接入入口。你可以先到官网了解整体能力再进控制台创建 API Key把 Key 配到 Hermes 的模型配置里。这样无论你后面是走hermes -p chat还是 Kanban 看板分发底层调用的都是同一套凭证切换 profile 时不用重复改配置。具体操作路径是这样的先访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解平台定位然后进控制台 https://taotoken.net/console 创建 API Key。API 端点统一用 https://taotoken.net/api注意这个地址不加 UTM 参数配置时直接填就行。如果你后面要跑长期编码或 Agent 任务可以顺带看下 Coding Plan 页面评估一下额度是否够多 Agent 并行消耗。注意多 Agent 场景下每个 profile 都会独立发起请求建议在控制台里给不同用途的 Key 做区分比如一个专门给 coder、一个给 searcher出问题时能快速定位是哪条流水线在异常消耗。拿到 Key 之后把它写进 Hermes 的模型配置。如果你用的是 Anthropic 兼容协议接入 Claude Code 那套可以参考接入文档里的字段说明把 base_url 指向https://taotoken.net/api模型名按你实际选用的填。这一步做完后面所有 profile 的调用都会走这个入口。3. 可复制配置Kanban 初始化与 Profile 骨架配置阶段的核心是把「角色」和「看板」两件事定下来。先看角色。本机实际可用的 profile 来自hermes profile list我把它整理成一张对照表分发时 profile 名必须与下表完全一致分配给不存在的 profileKanban 卡片会永远停在 ready 不被领取。Profile角色定位典型任务default默认会话临时问答、不归类的杂活planner规划者需求拆解、任务编排、生成执行计划coder编码者写代码、改 bug、跑测试reviewer评审者代码审查、质量把关、找缺陷searcher调研者资料调研、竞品分析、信息检索主控orchestrator默认由当前会话担任接收你的任务拆解后分发给上面对应的 profile再汇总结果。接下来初始化 Kanbanhermes kanban init # 幂等创建 kanban.db hermes kanban boards list # 查看现有看板 hermes kanban assignees # 查看可分配的 profile 各自任务数hermes kanban init是幂等的重复执行不会破坏已有数据。assignees这条命令特别重要分发前先跑一遍确认你要分配的 profile 名真实存在这是避免卡片卡死的第一道防线。然后是创建卡片。基础用法是把一张卡分配给 coderhermes kanban create 实现用户认证模块 --assignee coder --body 包含注册/登录/JWT 刷新写好单测带技能与运行时上限的写法hermes kanban create 翻译产品页文案 --assignee searcher --skill translation --max-runtime 30mhermes kanban create的关键参数我整理成下表配置骨架基本就靠这几个参数作用title位置参数卡片标题--assignee分配给哪个 profile--body任务正文 / 详细要求--parent父任务 id可重复用于建依赖--skill强制为 worker 加载的技能可重复--workspacescratch / worktree / worktree:/ dir:--goal目标循环模式每轮由 judge 判断是否完成没完成就继续--max-runtime单任务运行时上限如 90s / 30m / 2h--max-retries N连续失败熔断阈值--triage先丢进 triage由 specifier 细化后再进 todo依赖是 Kanban 编排的灵魂。父任务完成后子任务才会变 ready子任务能读到父任务的结果。你可以用--parent在创建时直接建依赖也可以用link事后串联hermes kanban link parent_id child_id当目标可以拆成多个并行子任务、最后统一验证汇总时用 swarm 一条命令建好整张图hermes kanban swarm 产出航司促销竞品分析报告 \ --worker searcher:调研A航司促销 \ --worker searcher:调研B航司促销 \ --worker planner:对比定价策略 \ --verifier reviewer \ --synthesizer planner结构很清晰多个--worker并行跑--verifier验证--synthesizer汇总成最终产物。这就是 Swarm 协作流的最小骨架。4. 验证请求hermes -p chat 启动与一轮分发回收配置搭好后先用最轻的方式验证链路通不通再上 Kanban。hermes -p chat是最直接的调用方式主控把子任务作为单次查询交给指定 profilehermes -p coder chat -q 实现用户认证模块包含注册/登录/JWT 刷新 hermes -p searcher chat -q 调研航司促销数据给出近 30 天主要航线降价情况 hermes -p reviewer chat -q 审查 src/auth 目录的代码质量列出风险点常用 flag 来自hermes chat --help我挑几个分发时最常用的Flag作用-q, --query单次非交互查询分发的核心-Q, --quiet安静模式只输出最终结果适合程序化采集-t, --toolsets限定本次可用工具集如 terminal,file-s, --skills预加载技能-w, --worktree在隔离的 git worktree 里跑多 agent 并行同一仓库时用--max-turns N限制单轮工具调用次数默认 90-c, --continue续上一次会话保留上下文并行采集结果时推荐加-Q方便把输出直接喂回主控做汇总hermes -p searcher chat -q 调研竞品定价 -Q现在演示一轮完整的 Kanban 分发与结果回收。假设需求是「做一份航司促销竞品分析并据此实现一个定价建议模块」主控拆解后这样建图# 初始化 hermes kanban init # 调研并行两路 $a hermes kanban create 调研A航司近30天促销 --assignee searcher --json $b hermes kanban create 调研B航司近30天促销 --assignee searcher --json # 分析依赖两路调研 $p hermes kanban create 汇总两家促销并提炼定价策略 --assignee planner --json hermes kanban link a_id p_id hermes kanban link b_id p_id # 编码依赖分析 $c hermes kanban create 实现定价建议模块 单测 --assignee coder --workspace worktree --json hermes kanban link p_id c_id # 评审依赖编码 $r hermes kanban create 评审定价模块代码与测试覆盖 --assignee reviewer --json hermes kanban link c_id r_id # 推进调度并观察 hermes kanban dispatch hermes kanban watch执行顺序是两路调研并行planner 汇总分析coder 在隔离 worktree 编码reviewer 评审。主控最后用hermes kanban show和hermes kanban log收集各环节产物汇总回报给你。成功的结果长这样hermes kanban stats里能看到各状态任务数归位hermes kanban show id能看到卡片详情、评论和事件流hermes kanban runs id每次尝试一行hermes kanban log id打印 worker 日志。监控与恢复的命令也一并给你hermes kanban list # 列出所有任务 hermes kanban show id # 看某张卡的详情 评论 事件 hermes kanban stats # 按状态/按 assignee 统计 最老 ready 时长 hermes kanban watch # 实时流式查看 task_events hermes kanban tail id # 跟踪单张卡的事件流 hermes kanban runs id # 查看任务的尝试历史 hermes kanban log id # 打印 worker 日志 hermes kanban dispatch # 手动跑一轮调度注意旧的hermes kanban daemon已废弃调度器现在跑在 gateway 里。常驻调度用hermes gateway start临时推进一轮用hermes kanban dispatch。5. 本篇常见错排查卡片卡死与 worker 不启动多 Agent 编排最容易踩的坑基本都集中在「任务不动」和「profile 对不上」这两类。我把排错清单整理成表遇到问题直接对号入座。症状排查方向卡片永远停在 readyprofile 名拼错或不存在用hermes kanban assignees核对worker 不启动调度器没跑hermes gateway start或hermes kanban dispatch任务卡死不动hermes kanban reclaim id释放占用后unblock想看子 agent 做了什么hermes kanban log id/hermes kanban runs idprofile 名对不上hermes profile list看真实 profile多 agent 改同一仓库冲突chat 用-wKanban 用--workspace worktree状态恢复与异常处理的命令单独列一下这几个是救火用的hermes kanban block id # 标记阻塞 hermes kanban unblock id # 阻塞/计划中 - 重新 ready hermes kanban promote id # 手动把 todo/blocked 推到 ready hermes kanban reclaim id # 释放卡死的 worker 占用 hermes kanban reassign id --assignee profile # 改派给其他 profile hermes kanban complete id # 标记完成 hermes kanban archive id # 归档我踩过的一个坑是卡片一直 ready查了半天以为是调度器问题最后发现是--assignee写成了coders多了一个 s。所以分发前先跑hermes kanban assignees这个习惯能省掉大量排查时间。另一个高频问题是多 Agent 同时改同一个仓库导致冲突解决办法是 chat 分发时加-w走隔离 worktreeKanban 分发时用--workspace worktree两者都是把每个 Agent 的工作区隔离开。6. 两种分发方式怎么选以及后续接入把两种方式放一起对比选择逻辑就清楚了维度hermes -p chat -qKanban 看板适合场景一次性、串行、临时并行扇出、有依赖、长流程持久化无会话级有SQLite 持久任务依赖手动串原生支持 link / --parent自动重试无有熔断 重试审计轨迹弱强events / runs / log隔离工作区--worktree--workspace 多模式上手成本极低中经验法则很简单单个子任务直接 chat多个子任务、有先后依赖或要并行就上 Kanban。调度铁律再强调一遍分发只走hermes -p profile chat -q ...或 Kanban 看板不使用delegate_task派遣其他 agent。标准流程是用户给任务主控拆解创建看板卡片或hermes -p分发最后汇总结果回报。分发前先用hermes profile list或hermes kanban assignees核对 profile 名避免卡片卡死。如果你准备把这套流水线跑起来建议按这个顺序推进先去控制台创建 API Keyhttps://taotoken.net/console 把模型入口配好然后对照接入文档https://taotoken.net/doc 确认 base_url 和模型名字段想先验证模型对话是否正常可以用模型对话页面https://taotoken.net/models 跑一轮如果是要长期跑编码或 Agent 任务再评估 Coding Planhttps://taotoken.net/coding-plan 的额度是否够多 Agent 并行消耗。API Key 管理入口在 https://taotoken.net/api-keys Claude Code 那套 Anthropic 兼容接入参考 https://taotoken.net/claudecode-anthropic 。把这些前置做好后面 Kanban 编排 Swarm 协作流时你只需要专注在任务拆解和依赖设计上模型接入层不用再操心。