Hermes多Agent协同研发实践：从Vibe Coding到流程化管控

背景

随着企业级 AI 辅助开发工具的普及，单纯依赖 Codex、Cursor 或 Claude Code (CC) 等工具进行“人机协同”研发的模式正面临瓶颈。尽管这些工具在单点任务上表现优异，但企业管理层对研发流程提出了更严苛的要求：

1. 全自动化与即时响应：期望实现“随时随地”的开发能力，即下班前提交需求，次日即可获得完整开发成果。
2. 代码熵管控与产物沉淀：领导层不再满足于一次性、黑盒式的“Vibe Coding”（灵感式编码），而是要求对代码质量进行严格控制，确保每个阶段的产物（如 PRD、架构设计、代码）都能被标准化沉淀，以便后续复用和经验积累。

在此背景下，作者深入研究了 Hermes 和 OpenClaw 等多 Agent 协同框架，并重点探索了 Hermes 结合飞书（Feishu）的工作流实现，旨在构建一套既具备自动化能力，又能满足企业级规范管控的研发闭环。

核心内容

作者通过一周多的研究，实际运行了两个需求案例，详细阐述了基于 Hermes 的多 Agent 协同架构及其落地效果。

1. 架构设计与工作流

作者未使用 Superpower、OpenSpec 等第三方 Skill，而是基于 Hermes 的 Kanban 多 Profile 协同机制，自定义了轻量级的 Manual SDD（软件设计文档）、Handoffs（交接机制）和 Skill。整个流程通过飞书群组对接，实现了从需求到测试的自动化链路。

Agent 角色分工如下：

• prod-main：生产入口。负责 PRD 任务创建，并在用户主动请求时进行手动路由。
• prod-prd：负责生成生产级 PRD，并创建 prod-architect 子 Agent。
• prod-architect：负责技术方案设计与详细设计，并创建 prod-coder 子 Agent。
• prod-coder：负责生产开发、自测。当代码完成且需人工审核时，触发 review-required 交接；等待 prod-tester 批准。
• prod-tester：负责实现验收。通过后 Unblock coder；若失败，则生成缺陷报告。

每个 Agent 都有明确的产物规定，作为下一个 Agent 的输入，形成严密的协作链条。

2. 实战案例与效果评估

案例一：全新系统反向拆解

• 背景：同事使用 Codex 耗时两周，通过 Vibe Coding 开发完成的全新系统。作者将其反向拆解为需求文档，输入 Hermes 自动化流程。
• 耗时：约几个小时。
• 效果：完成度约 50%。
• 问题分析：
  • 细节缺失：Codex 的开发过程包含大量人工微调，自动化流程难以还原这种“调优”过程，导致结果仅形似，经不起推敲。
  • 高保真难题：即使使用 Stitch 的 MCP 获取原型组件代码，还原度也仅达 80%，存在大量功能性粗糙问题。

案例二：存量简单需求

• 背景：近期运行的一个简单存量需求。
• 耗时：总耗时 6 小时，其中文档输出耗时 1.5 小时。
• 效果：完成度约 80%，细节问题需人工修复。
• 问题分析：
  • 文档质量与核对成本：虽然文档内容详细，但核对文档本身成为新的成本瓶颈。
  • 错误传导风险：即使让 AI 自行核对，仍需人工二次确认。若 PRD 或设计阶段出现偏差，Coder 的开发将随之偏离，导致整体返工。

3. 核心思考：Vibe Coding 与 工作流协同的博弈

• 效率 vs. 沉淀：Codex 或 CC 在速度和单点质量上依然最高，但其本质是“纯 Vibe”，是一次性开发，无法沉淀稳定的工作流和经验。
• 多 Agent 的优势：Hermes/OpenClaw 的多 Agent 协同允许定义合理的分工。每个 Agent 像实习生一样工作，随着任务积累，系统可沉淀出类似“资深 PRD 专家”或“资深代码专家”的经验。这符合领导层对于“提效经验可复用、可推广”的期待，而非仅服务于单个项目。
• 企业级熵管控：企业项目必须管控代码熵。例如，若系统中已存在日期工具类，AI 不应再生成重复方法。去年的 Cursor 实践表明，制定严格的 Rule 和 Skill 是必要的，但纯 Vibe 模式难以稳定执行这些规范。
• 黑盒化风险：多 Agent 协同虽然规范，但也使代码研发过程更加黑盒化，增加了理解和调试的难度。

关键要点

• 架构解耦：Hermes 多 Agent 协同通过 prod-main -> prod-prd -> prod-architect -> prod-coder -> prod-tester 的线性链路，实现了研发全流程的自动化流转。
• 产物驱动：每个 Agent 必须输出标准化的产物（如 PRD、设计文档、代码），作为下游 Agent 的输入，确保上下文的一致性。
• 效果局限：
  • 对于复杂的新系统开发，自动化还原度低（约 50%），难以替代人工微调的高质量开发。
  • 对于简单需求，自动化效率较高（完成度 80%），但文档核对和错误修正仍占大量人工成本。
• 核心价值在于“沉淀”：多 Agent 协同的核心优势不在于单次开发的极致效率，而在于将开发过程标准化、可复用化，形成企业级的经验资产。
• 熵管控必要性：企业级开发必须通过 Rule 和 Skill 限制 AI 的行为（如禁止重复造轮子），以控制代码熵，这是纯 Vibe Coding 难以做到的。
• 人机协作新范式：未来的企业研发可能是“AI 执行标准化流程 + 人工审核关键节点 + 人工处理异常与细节”的模式。

意义与影响

这篇分享揭示了 AI 辅助开发从“个人提效工具”向“企业级工程化平台”转型的关键痛点与探索方向。

1. 重新定义 AI 在研发中的角色：AI 不再仅仅是“代码生成器”，而是被定位为遵循严格工作流的“执行单元”。这种转变要求开发者从“写代码”转向“设计工作流”和“定义规范”。
2. 平衡效率与质量：当前技术阶段，全自动化的多 Agent 协同在复杂场景下尚无法完全替代资深工程师的直觉和微调能力。企业需要在“快速交付”与“代码质量/可维护性”之间寻找平衡点。
3. 知识资产化：通过多 Agent 协同，企业的研发过程被结构化、数据化。这意味着企业的技术债务、最佳实践、常见错误都可以被系统化地记录和复用，从而降低对个别资深员工的依赖。
4. 对开发者的挑战：开发者需要掌握新的技能树，包括 Workflow 设计、Agent 编排、Prompt 工程以及更严格的代码规范制定能力。同时，人工审核的成本（如文档核对）成为新的瓶颈，提示我们需要进一步优化 AI 的自检和验证能力。

总体而言，Hermes 等多 Agent 框架为企业级 AI 研发提供了一条可行的路径，但其成熟度仍需在实际复杂场景中不断迭代，特别是在降低人工核对成本和提升复杂逻辑还原度方面仍有巨大提升空间。