Hermes多Agent协同研发实践

背景

该用户在 LINUX DO 论坛发帖，探讨多 agent 协同进行端到端研发的实践经验。用户所在团队此前已使用 Codex、Cursor（CC）等工具进行人机协同开发，但领导层对此不再满足。领导的理想目标是：实现全自动化开发流程——开发者只需在下班前将一个需求提交给系统，第二天早上系统就能完成开发并交付可用代码。此外，领导对代码的可控性和“代码熵”的管控有更高要求，期望每个开发阶段的产物都能被沉淀下来，便于追踪、复用和推广。

当前市场上，OpenClaw 和 Hermes 两个产品均支持对接飞书（Feishu）进行任务调度与协作，被认为最贴合团队需求。因此，该用户专门针对 Hermes 的多 agent 协同机制进行了深入研究和实际跑验。

核心内容

整体架构

用户基于 Hermes 的 Kanban（看板） 多 profile 协同模式，自定义编写了 Workflow（工作流） 和 Router（路由），没有使用任何第三方 skill（如 Superpower、OpenSpec 等）。整个系统按角色拆分为 5 个 agent：

| Agent 名称 | 职责 | |------------|------| | prod-main | 生产入口，负责 PRD 任务创建，以及在用户主动请求时进行手动路由 | | prod-prd | 生产 PRD，创建 prod-architect 子任务 | | prod-architect | 制定技术方案、详细设计，并创建 prod-coder 子任务 | | prod-coder | 生产和自测代码，完成后执行 review-required 的 handoff，等待 tester 审批 | | prod-tester | 实现验收：若通过则 unblock coder（允许继续），若失败则生成缺陷报告 |

每个 agent 具有自定义的轻量级 Manual SDD（软件设计文档）、handoffs（交接） 和 skill（技能），并明确规定了产物的格式和内容，供下游 agent 使用。

飞书对接与自动化流程

将上述 5 个 agent 拉入一个飞书群组后，用户配置了一条自动化链路：

prod-main → prod-prd → prod-architect → prod-coder → prod-tester

这样，需求文档进入后，各 agent 依次执行，全程无需人工干预。

实际跑验结果

该用户已跑了两个真实需求：

1. 第一个需求（全新系统反向拆解）
   同事此前使用 Codex 耗费两周时间 vibe coding 开发完成了一个全新系统。用户将该系统反向拆解为需求文档，投入 Hermes 自动化流程运行。对比效果：

   • 细节差距明显：原人工开发经过反复调优，而自动化跑完所有阶段只需几个小时。第一版产出仅达到 50% 的相似度，“只有形似，经不起推敲”。
   • 高保真还原度不高：即便使用了 Stitch 的 MCP（带原型组件代码），也只能还原约 80% 的 UI。此外存在大量功能性粗糙问题。

2. 第二个需求（存量简单需求增量开发）
   运行总耗时约 6 小时，其中文档输出了 1.5 小时。最终完成率达到 80% 的要求，剩余细节问题需要人工修复。

   • 文档内容非常详细，但核对内容本身成为新的成本瓶颈——即便用户让 AI 自行核对，最终依旧需要人工重新核对一遍。因为 PRD 和设计一旦有偏差，下游 coder 开发的代码就会跟着偏离。

关键要点

• Codex / Cursor 与多 agent 协同的对比：用户认为 single-agent 模式的工具（如 Codex、Cursor）开发效率最高（质量和速度均优），但无法沉淀稳定工作流，本质上是“纯 vibe，一次性开发”；而多 agent 协同（Hermes / OpenClaw）虽定义合理，能沉淀各个阶段的产物，并让 agent 像实习生一样积累经验，但整体开发过程更加“黑盒”，且核对环节仍高度依赖人工。
• 企业对代码熵管控的诉求：领导不希望每次开发后项目就“完结”，而是要求有可持续的提效经验沉淀、可复用的工作流程。用户此前在 Cursor 中通过制定大量 rule 和 skill （如禁止重复生成已有的工具类）来管控代码一致性和规范，但在多 agent 体系下依然存在类似管理成本。
• 自动化产出的质量瓶颈：自动生成的代码在细节、高保真、功能完整性上均难以达到人工反复调优的水平。当前第一版效果约 50-80%，且存在“文档正确性→代码正确性”的传递风险，需要人工二次核对。
• 实践耗时与收益的权衡：第一个需求自动化耗时数小时（对比人工两周），第二个需求耗时 6 小时（其中文档核对占 1.5 小时）。整体提效显著，但质量保证环节（文档校验、设计校验）尚未完全自动化，成为新的瓶颈。

意义与影响

该用户的实践反映了当前企业级 AI 研发从“单人辅助 coding”向“多 agent 自动化流水线”转型的真实探索。其意义体现在以下几个方面：

1. 工作流可沉淀与复用：多 agent 协同将研发过程结构化，每个 step 的产出物可追踪、可积累，符合企业需要“提效经验可推广”的管理诉求。这与纯 vibe coding 的“用完即弃”模式形成鲜明对比。
2. 代码熵管控的新路径：通过 agent 的角色划分和 handoff 机制，可以在流程中嵌入规范检查（如禁止重复生成已有工具类），但同时也增加了“黑盒”风险：当 PRD 或设计出现偏差时，整个下游会连锁偏离且不易早期察觉。
3. 效率与质量的矛盾尚未完全解决：自动化能大幅缩短从需求到代码的耗时，但“核对”环节仍须人工介入，且自动生成的代码在复杂业务逻辑和高保真还原上仍有明显差距。这提示企业需要在“全自动”和“人机协同”之间找到平衡点。
4. 对未来工具演进的参考：市场上已有多款多 agent 协同产品（Hermes、OpenClaw 等），但用户实测显示它们距离领导“下班扔需求、上班收代码”的理想还有距离。未来需要进一步优化 agent 对复杂需求的理解、跨阶段校验能力以及自动纠偏机制，才能真正成为企业级可信赖的研发流水线。