1. 为什么单对话框模式撑不住多智能体协作如果你现在用 AI 写代码还是「一个对话框来回折腾」——提需求、等回复、看不懂再追问——那你其实是在用电话客服的方式指挥一支本该并行开工的团队。Hermes Agent v0.12.0 带来的 Kanban 机制把这件事从「串行问答」改成了「任务板 多智能体认领」你往看板上贴任务卡片researcher、coder、reviewer 各自领活、并行执行、把结果写回 SQLite你只需要在真正需要人类拍板的地方出手。这篇文章聚焦一个具体问题怎么用 Hermes Agent v0.12.0 的 Kanban SQLite delegate_task让一群 AI 真正替你干活而不是卡在一个对话框里。适合已经跑通过 Hermes 基础对话、想往多智能体流水线进阶的开发者也适合被「一个 Agent 干到一半崩了就全崩」折磨过的同学。下面我会给出可复制的config.toml骨架、TaoToken 统一 Key 配置、任务分派与状态落库的完整验证动作以及我踩过的几个坑。核心检索词先摆出来Hermes Agent、Kanban、多智能体、SQLite、delegate_task。这五个词贯穿全文你跟着做就能跑起来。2. TaoToken 前置统一 Key 与模型接入Hermes Agent 的多智能体架构里每个 profileresearcher、coder、reviewer都要调用模型。如果每个 profile 各配一套 Key管理成本会爆炸。我的做法是用 TaoToken 做统一入口一个 Key 覆盖多个模型profile 之间只改模型名不改鉴权。TaoToken 在这里的角色是「模型调用的统一网关」你拿到一个 API Key配好 base_urlHermes 的各个 profile 就能通过它调用不同模型。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不加 UTM 参数。操作顺序建议这样先注册账号进控制台创建 API Key把 Key 存到环境变量里再写进 Hermes 的config.toml。控制台地址 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。注意Key 不要硬编码进config.toml提交到 git。用环境变量TAOTOKEN_API_KEY注入配置文件里写api_key_env TAOTOKEN_API_KEY。如果你还没决定用哪个模型可以先去模型对话页试一下手感https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。长期跑编码和 Agent 任务的话Coding Plan 更划算https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。3. 可复制配置config.toml 骨架与 Kanban 参数Hermes Agent v0.12.0 的配置文件默认在~/.hermes/config.toml。下面这份骨架是我实测能跑通多智能体协作的最小配置你可以直接复制后改模型名。# ~/.hermes/config.toml [provider] name taotoken base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY timeout_seconds 120 [kanban] enabled true db_path ~/.hermes/kanban.db max_parallel_tasks 5 claim_lock_ttl 300 # 防重复认领的锁超时秒 auto_retry_failed true retry_backoff_seconds 15 [kanban.dashboard] enabled true host 127.0.0.1 port 8787 # 多智能体 profile 定义 [[profiles]] name researcher model claude-sonnet-4-5 skills [kanban-worker, web-research] system_prompt 你负责调研与资料汇总输出结构化要点。 [[profiles]] name coder model claude-sonnet-4-5 skills [kanban-worker, code-edit] system_prompt 你负责按任务描述写代码产出可运行文件。 [[profiles]] name reviewer model gpt-5 skills [kanban-worker, code-review] system_prompt 你负责审核代码指出问题并给出修改建议。 [[profiles]] name orchestrator model claude-sonnet-4-5 skills [kanban-orchestrator] system_prompt 你负责把大任务拆成子任务并分派给合适的 profile。几个参数值得单独说。max_parallel_tasks 5控制同时开工的智能体数量设太大容易触发上游限流设太小又失去并行意义5 是个稳妥起点。claim_lock_ttl 300是防重复认领的关键多个 worker 同时抢一个任务时只有拿到锁的那个能执行锁 300 秒后自动释放避免某个 worker 崩了任务永远锁死。auto_retry_failed true配合retry_backoff_seconds让失败任务自动重试这是 Kanban 相比 delegate_task 最实用的差异之一。配置写完后用环境变量注入 Keyexport TAOTOKEN_API_KEY你的Key hermes config validatehermes config validate会检查 TOML 语法、profile 引用、数据库路径是否可写。看到config OK再往下走。4. 任务分派、状态落库与结果校验配置就绪后进入实战环节。这一节分三步创建任务、观察分派、校验结果。4.1 用 delegate_task 创建任务并分派Hermes 的 CLI 里delegate_task负责把任务写进 Kanban 并指定执行者。先创建一个父任务再挂子任务# 创建父任务调研 实现 审核 一条流水线 hermes kanban create \ --title 实现一个 URL 短链服务 \ --profile orchestrator \ --id parent-001 # 子任务1调研无依赖立即可跑 hermes kanban create \ --title 调研短链服务的存储方案 \ --profile researcher \ --parent parent-001 \ --id task-research # 子任务2写代码依赖调研完成 hermes kanban create \ --title 实现短链生成与跳转 API \ --profile coder \ --parent parent-001 \ --depends-on task-research \ --id task-code # 子任务3审核依赖代码完成 hermes kanban create \ --title 审核短链服务代码 \ --profile reviewer \ --parent parent-001 \ --depends-on task-code \ --id task-review--depends-on是 Kanban 依赖引擎的核心。task-code 不会在 task-research 完成前被认领task-review 同理。这样你不需要手动协调顺序依赖满足后任务自动进入 ready 状态。4.2 观察状态落库任务写进去后状态全部落在 SQLite 里。你可以直接查库确认sqlite3 ~/.hermes/kanban.db \ SELECT id, title, profile, status, depends_on FROM tasks ORDER BY created_at;预期输出类似parent-001|实现一个 URL 短链服务|orchestrator|running| task-research|调研短链服务的存储方案|researcher|done| task-code|实现短链生成与跳转 API|coder|running|task-research task-review|审核短链服务代码|reviewer|ready|task-code看到task-research变成done、task-code变成running、task-review还是ready说明依赖引擎在正常工作。如果 task-code 在 task-research 没完成时就 running那说明--depends-on没生效检查一下任务 ID 是否拼错。4.3 校验结果与评论机制任务完成后结果写回 SQLite 的task_results表同时可以在看板上看到。校验动作# 查看某个任务的产出 hermes kanban result task-code # 查看任务下的全部评论人类和 AI 的对话 hermes kanban comments task-review如果 reviewer 在审核时遇到不确定的技术决策它会在任务下留言而不是卡死。你看到留言后回复hermes kanban comment task-review \ --author human \ --body 这个决策按方案 B 走继续。reviewer 下次被唤醒时会读完全部评论再继续。这就是「人类在回路」的落地方式——不是打断流程而是插入一条消息。5. 本篇常见错排查跑多智能体协作时下面几个错我基本都踩过列出来帮你省时间。错误一claim_lock_ttl设太小导致任务被重复执行。如果你把claim_lock_ttl设成 30 秒而某个任务实际要跑 2 分钟锁会在任务没完成时释放另一个 worker 抢到同一个任务结果就是重复执行。建议 TTL 至少是单任务平均耗时的 2 倍默认 300 秒对多数任务够用。错误二SQLite 数据库被多进程同时写导致database is locked。Hermes 内部用了 WAL 模式缓解这个问题但如果你自己写脚本直接连kanban.db做批量写可能撞锁。解决办法是只读查询用sqlite3 -readonly写操作走 Hermes CLI不要绕过它。错误三profile 的 model 名写错任务一直 pending。如果config.toml里某个 profile 的model字段拼错任务创建成功但永远不被认领状态卡在ready。用hermes config validate能提前发现跑起来后也可以用hermes kanban list --status ready看有没有长期滞留的任务。错误四delegate_task和 Kanban 混用导致状态不一致。delegate_task 是函数调用模型执行完就结束不写 Kanban。如果你既用 delegate_task 又用 Kanban两套状态各管各的容易混乱。建议需要持久化、可恢复、可并行的任务走 Kanban一次性的、不需要留痕的子调用才用 delegate_task。错误五看板端口被占用。[kanban.dashboard]默认 8787如果被占改成 8788 或别的端口重启 Hermes 即可。看板只是可视化不影响任务执行端口冲突不会导致任务失败。6. 从单对话框到多智能体流水线的下一步把上面这套跑通后你手里就有了一条可复用的多智能体流水线orchestrator 拆任务researcher 调研coder 实现reviewer 审核状态全在 SQLite崩溃可恢复人类可随时插入评论。这比在一个对话框里来回追问的效率高一个量级。下一步可以做的把max_parallel_tasks逐步调大观察上游限流情况给不同 profile 配不同模型比如调研用便宜模型、审核用强模型控制成本把 Kanban 看板接到你的通知系统任务完成时推消息。如果你还没配好 Key先去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建一个再回来看接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 确认 base_url 和鉴权头格式。长期跑编码和 Agent 任务的话Coding Plan 的额度模型更适合这种多任务并行场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。Claude Code 相关的接入细节在 https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个我实测有效的技巧先跑两个 profile 的最小流水线确认依赖引擎和状态落库都正常再往上加 profile。一上来就配五个 profile 并行出问题时你分不清是配置错、依赖错还是模型错。从 researcher coder 两条开始跑通再加 reviewer稳得多。