我把多 Agent 协作搬进 Hermes Kanban，才发现群聊派活真的不够用了

# 多 Agent 协作的真正门槛，不在智能，在任务管理 这几天在跑一条做站流水线——从市场调研、关键词规划、PRD、定价、合规、文案、设计、前后端开发、QA，一直到上线冷启动。中间需要一串 Agent 接力完成。实践中最大的感受是：多 Agent 协作真正难的，不是让它们动起来，是让任务别丢。 一开始，最朴素的方式自然是：在聊天窗口里派活，在群里 @ 人，让一个 Agent 做完后喊下一个 Agent。很快就会发现扛不住了。聊天窗口适合沟通，但不适合做任务系统。上下文一长，谁做了什么、产物在哪、哪里卡住、下一步谁接，经常需要重新翻。 后来把这条流程搬进 Hermes Kanban，才觉得多 Agent 协作终于像一套工程系统了。Agent 可以忘，聊天可以断，但任务卡不能丢。 ## 01 delegate_task 解决不了长链路 delegate_task 很好用。你把一个任务丢给子 Agent，父 Agent 等它执行完，再拿结果继续。它更像一次 RPC 调用。短任务很适合：查资料、跑测试、写一个小模块、做一次独立 code review。 问题出在长链路任务。比如做站。设计 Agent 做完一版，产品 Agent 要验收。验收通过，前端 Agent 再实现。实现后，QA Agent 要回归。QA 发现问题，又要开修复任务。中间还可能插入人工确认、外部发布、凭据补充、合规判断。 这类任务不是一个“问答回合”。它有状态，有依赖，有产物，有阻塞，有恢复。如果还靠聊天接力，就会出现几个典型问题： - 父进程要等。任务时间一长，整个链路被挂住。 - 状态不可见。你不知道它是真在跑、卡住了，还是已经崩了。 - 恢复成本高。某个 Agent 中途断掉，下一次接起来要重新拼上下文。 - 人工节点很别扭。比如“这个设计要不要过”“这个站能不能发外部渠道”，这些都不能让 Agent 自己越权处理。 Hermes Kanban 的思路，则是另一条路。任务不是一次函数调用，任务是看板里一张持久化的卡片。卡片里有任务描述、owner、lane、状态、评论、metadata、产物路径、阻塞原因。Agent 接任务、执行、写结果、创建下一张卡。整个过程不依赖某个聊天窗口活着。多 Agent 协作要跑起来，先得把任务从对话里拿出来。 ## 02 做站流水线搬进 Kanban 的具体做法 做法其实很简单：Kanban 做事实源，Telegram 只做可见性。看板里有不同 lane。每个 Agent 只看自己 lane 里的 ready 任务——调研 Agent 看 research，PRD Agent 看 product，设计 Agent 看 design，前端 Agent 看 frontend，QA Agent 看 qa。 任务开始执行后，状态变成 running。做完以后，必须 complete，并写清楚：交付物在哪里、关键结论是什么、下一棒是谁、有没有风险、有没有需要人工确认的点。如果做不下去，就 block。block 不是失败，block 的意思是：已经做到当前边界，继续往下需要外部条件——比如缺凭据、缺确认、缺上游产物，或者发现需求冲突。这比一直 running 强太多。一直 running 你不知道它是在工作还是已经死了，blocked 至少把问题暴露出来。 Hermes 的 worker lane 机制也很关键。Agent 启动后，会拿到当前任务、看板 slug、工作目录等上下文。它知道自己接的是哪张卡，属于哪块板，产物应该写到哪里。这里有个细节：看板名是 board slug，不是某个本机数据库路径。这个设计很重要，因为多 Agent 协作最怕“靠嘴传上下文”。一旦要靠聊天告诉它“你去读哪个文件”“你接哪个任务”“你现在是什么身份”，链路就会变脆。 现在的要求是：所有 Agent 完成任务时，都必须把产物路径写回卡片。不要说“完成了”就完事。下一棒 Agent 不需要猜，它打开任务卡，看到上游文件，直接读取，继续执行。状态消息会过期，产物路径不会。 ## 03 一条真实任务链：地图类工具站的视觉返工 这次写文章前，特意翻了几个小墨系列 Agent 的历史 session。最有代表性的是一次地图类工具站的视觉返工。起点是用户反馈：实站效果和设计预期差距很大。以前这种事很容易变成一句模糊指令：“设计再优化一下。”这次没有这么做。 在看板里建了一张设计返工卡，要求设计 Agent 先做四件事：看实站效果、对照原设计真源、列出 fidelity gap、交付可执行的前端 patch 清单。设计 Agent 执行过程中遇到一个外部工具失败，它没有把失败吞掉，而是在任务评论里写清楚：工具尝试失败，改用 fallback 方案继续。这个细节很重要，后面接手的人不需要猜“为什么交付格式和预期不一样”，原因已经写在卡片里。 设计完成后，产品验收 Agent 接棒。它不是凭感觉说“可以”，而是读取设计包、核对验收标准，然后给出明确结论：是否允许进入前端实现。通过后，它创建下一张前端任务卡。前端 Agent 拿到的不是一句“你实现一下”，而是设计交付物、验收结论、实现边界、不得额外发挥的要求。这句话非常关键。很多多 Agent 协作会失控，就是因为每个 Agent 都想“顺手优化”——设计想改产品，前端想改设计，QA 想改需求。最后看起来大家都很主动，实际产物越来越偏。 规则很明确：当前 Agent 只执行当前合同。发现问题可以开卡，不能偷偷改方向。 前端实现后，QA Agent 接棒。QA 没有只回一句“有问题”，而是把问题按严重程度写成报告，并创建修复卡。修复卡再回到前端 lane。修完后，QA 再回归。这一整条链路里，人类只在关键节点介入：确认方向、解锁外部动作、判断是否发布。其他动作都在 Kanban 上流转。 这就是现在觉得 Kanban 必须存在的原因。如果只看聊天记录，你会看到一堆“完成了”“已修复”“继续”。如果看 Kanban，你能看到任务链本身：谁创建了卡，谁接手，谁阻塞，谁产出，谁验收，谁把下一张卡推出来。真正的协作痕迹，不在热闹的聊天里，在冷静的状态机里。 ## 04 worker lanes 解决的是“谁来执行” Hermes 官方文档里有一个页面专门讲 worker lanes。以前对这个概念没那么敏感，真正跑起做站流水线后，才发现它是多 Agent 协作的关键抽象。lane 不是简单的列名，它代表一类可执行任务的角色、启动方式、生命周期边界和完成约定。比如设计 lane 里的任务，就应该由设计 Agent 接；QA lane 里的任务，就应该由 QA Agent 接；前端 lane 的任务，不能因为某个 Agent“看到了”就随手做。这让协作从“谁在线谁接”变成“谁适合谁接”。 这也是为什么现在不喜欢纯群聊派活。群聊派活靠人记，Kanban lane 靠系统路由。前者看起来灵活，后者更适合长期运行。 ## 05 从历史 session 里总结的四条协作规则 复盘几个 Agent 的历史 session，更确定了四条规则。 **第一，看板是事实源。** 任务上下文、中间决策、产物路径，必须写在卡片里。聊天可以同步进展，但不能承担事实源。这点非常反直觉。人类习惯在群里看进度，觉得群消息就是记录，但 Agent 不一定读群。下一棒真正会读的是任务卡、metadata、handoff 文件。所以现在的规则是：群里可以发 START / DONE / BLOCKED，但最终状态必须回写 Kanban。 **第二，block 是安全阀。** 很多人会把 blocked 当成坏状态，现在反而希望 Agent 该 block 就 block。缺权限、缺确认、缺输入、外部发布有风险，就停下来，把原因写清楚。最危险的不是 block，最危险的是 Agent 为了显得能干，绕过确认，自己往下做。 **第三，产物路径比自然语言总结重要。** “我已经完成设计优化”没有意义。有意义的是：设计包在哪、验收报告在哪、patch 清单在哪、截图在哪、测试报告在哪。Agent 的自然语言总结经常会变形，文件不会。 **第四，下一棒必须由上游产物驱动。** 不是让前端 Agent 重新理解一遍需求，也不是让 QA Agent 重新猜业务目标。上游交付什么，下游就基于什么执行。如果下游发现上游有问题，开新卡，回到对应 lane。这样链路才不会变成一团麻。 ## 06 对多 Agent 协作的核心判断 别急着同时启动 20 个 Agent。先把任务系统搭好。 多 Agent 协作的核心，不是“更多模型同时干活”。核心是：任务能不能持久化，状态能不能恢复，上下文能不能无损交接，阻塞能不能暴露，人工确认能不能留下记录，产物能不能被下一棒直接使用。 Hermes Kanban 的价值，就是把这些东西变成了工程约束。Agent 可以独立跑，任务可以被追踪，中间状态可以被审计。某个 Agent 崩了，卡片还在；某段聊天断了，流程还能继续。这才是多 Agent 协作真正需要的底座。 多 Agent 协作的上限，不取决于 Agent 数量，取决于任务管理精度。工具就在那儿，用不用，取决于你。