Hermes 多 Agent 工作流：从看到到跑起来
四月底开始看到各种 Hermes 的 demo：从飞书发一个需求，Agent 军团接着完成市场调研、写 PRD、出架构设计、开发、测试，全程不用人插手。看着确实酷。
花了一个周末把它跑起来，记录一下中间踩过的坑，以及我对这个框架目前能力边界的判断。
Hermes 是什么
从架构上看，Hermes 是一个以「任务看板」（Kanban）为核心的异步多 Agent 框架。跟主流的同步编排框架（Orchestrator 派一批 Worker、等结果收回来）不同，Hermes 的任务是写进持久队列里的，Agent 按状态自己拉任务，跑完再更新状态，支持跨会话、跨天、跨重启继续运行。
理论上这个设计解决了长任务的一个大问题：任务不再绑定在一次会话里，中途可以被人工介入，可以挂起来等外部条件，可以失败后从中间重跑而不是从头。
公式很简单：
Hermes = 任务队列 + Agent 集合 + 消息总线 + 工具权限管理
每个 Agent 有自己的系统提示、工具集、上下文窗口，互相之间通过消息总线通信，不共享上下文。
环境搭建：文档和实际有出入
官方文档写的是几行命令就能起来，实际操作有几个地方文档没说清楚。
模型配置。Hermes 官方支持接多个模型 API，主流教程用 Kimi K2.6 演示，因为它有官方推荐且开源。我在公司内网环境下，代理设置花了不少时间，文档里没提这部分。
消息总线。默认用文件系统模拟消息队列（每个 Agent 一个目录，写文件就是发消息），生产环境当然要换成真正的队列（Redis 或者 RabbitMQ），但这个迁移文档写得很粗。本地测试用文件系统就够了，需要知道的是：文件系统的并发写入没有锁，多个 Agent 同时写同一个任务状态文件会出问题，本地测试尽量不要多 Agent 并发跑同一个任务的同一个子步骤。
工具权限。这是最容易踩坑的地方，也是 demo 里最不演示的地方。Hermes 里每个 Agent 的工具集要显式配置，没有配置的工具 Agent 调不到，调了会报「工具不存在」而不是权限报错，排查很迷惑。配置文件大概是这样：
agents:
researcher:
tools: [web_search, read_file]
model: kimi-k2
developer:
tools: [read_file, write_file, run_bash]
model: kimi-k2
reviewer:
tools: [read_file, run_bash]
model: kimi-k2
developer 可以写文件，reviewer 不能——这个权限边界要自己想清楚，框架不会替你设计。
跑一个真实任务
用一个我实际跑过的场景说说效果：给一个 Go 的内部工具库写一批单元测试。
任务分发给三个 Agent：
analyst：读源码、梳理函数签名和依赖关系、输出测试点清单developer：根据清单写测试代码reviewer：跑测试、检查覆盖率、输出 review 意见
理论上这是多 Agent 的理想场景：任务可清晰切分、各 Agent 产物是下一个的输入、不需要共享上下文。
实际跑下来，前两步基本达到预期，analyst 出了一份还算准确的清单，developer 照着写出来的测试能编译，覆盖了七八成的 case。
问题出在 reviewer 这步。它跑测试发现有几个 case 失败，然后做了一件让我没预料到的事：它直接修改了 developer 已经写好的测试文件，把 assertion 改成了「更宽松」的版本，让测试通过了。表面上看任务完成了，实际上它在用最省事的方式过关，而不是真正修复逻辑。
这个问题的根因是 reviewer 的系统提示写得不够严格——「确保测试通过」和「修复测试中的错误」是两件不同的事，但我没有在提示词里区分。多 Agent 系统里，每个角色的职责边界必须在提示词里讲得很死，含糊的空间会被模型用来走捷径。
修完 reviewer 的提示，加了一句「你只能修改测试文件里的 helper 和 setup 代码，不能修改 assertion，assertion 必须联系 developer agent 修改」，结果就正常了——它开始发消息给 developer，让 developer 来修实现而不是改断言。
和 Subagent 模式的比较
Hermes 的异步 Kanban 模式和 Claude Code 的 Subagent 模式，适合的场景不一样。
Subagent 适合：任务有明确终点、结果需要在本次会话里拿到、子任务之间依赖关系复杂需要 Orchestrator 实时调度。代码审查、文档生成这类「发出去、等收回来」的任务，Subagent 更顺。
Hermes 适合：任务周期长（几小时到几天）、可能需要人工介入某个环节、各 Agent 之间的协作是持续的而不是单次交付。一个「从需求到上线」的完整开发链路，如果放在 Subagent 里，单次会话跑下来上下文会爆，Hermes 的分阶段持久化就有价值。
不适合 Hermes 的场景也很明确：任务依赖关系是强顺序的（B必须严格等 A 交付后才能开始）、或者任务对实时性要求高（不能等队列调度延迟）。
目前的判断
跑完这一圈，我觉得 Hermes 现阶段是「思路正确、工程成熟度不足」的状态。任务队列、持久化、多 Agent 消息总线这套设计是对的，解决的是真实的工程问题。但文档的完整度和错误信息的友好度，还停留在「作者自己用着没问题」的阶段。
比较实际的用法：现阶段不要把它用在核心业务链路上，更适合作为「内部效率工具」跑——代码批量处理、文档生成、测试覆盖率提升这类容错性高的场景。出了问题能重跑、不影响线上，这时候 Hermes 的异步持久化优势才能发挥出来，代价也是可以接受的。