6.3 节深度拆解：Hermes Agent 多 Agent 协同执行链路的 4 层设计逻辑

1. 多 Agent 协同不是“堆人”，而是建流水线：Hermes 的 4 层链路设计，本质是工程化任务分解

我第一次把三个 Hermes Agent 拉进同一个 workflow 时，以为只要给它们起好名字、连上模型、丢个需求进去，就能自动跑出结果。结果跑了三轮：第一轮，Code Agent 写完函数，Test Agent 直接报错说“找不到被测模块”——它压根没看到前一步生成的文件；第二轮，我把所有代码 dump 进 system prompt，Test Agent 是跑通了，但 Review Agent 看着满屏日志直接返回“上下文超限，建议人工介入”；第三轮，我加了中间缓存目录、手动 copy 文件、再用 shell 脚本触发下一步……流程是通了，但整个链路像用胶带缠起来的电路板，改一行配置就得重测五步。

这不是 Agent 不够聪明，是协同逻辑没对齐工程现实。Hermes Agent 的多 Agent 协同，从来就不是让几个 AI 坐在一起开会，而是像汽车工厂的装配线：每个工位（Agent）只做一件确定的事，物料（数据/代码/状态）必须按标准托盘（Schema）流转，传送带（Message Bus）速度可控，质检点（Guardrail）嵌在固定位置。它的 4 层设计——协议层 → 编排层 → 执行层 → 适配层——每一层都在解决一个具体的工程问题：协议层管“说什么”，编排层管“谁先说”，执行层管“怎么说清楚”，适配层管“和谁说”。这四层叠在一起，才让“AI 编程”从玩具级 demo 变成可上线、可审计、可扩缩的生产级能力。

你不需要记住这四个词，但必须理解：当你在hermes-agent.yaml里写router: code_re