🧠 个人知识库

三位一体AI协作研发团队架构设计与SOP

Properties1
tags架构, ai-agent, 自动化研发, 飞书

21 min read

三位一体 AI 协作研发团队架构设计与 SOP

本文档记录基于 Hermes Agent 构建的 “Hermes (总管决策) + A Bot (首席架构/独立审核) + B Bot (核心研发/测试实现)” 三位一体自动化敏捷研发团队的完整架构设计、20 条核心协作规则、潜在故障清单 (Pre-Mortem) 与飞书专属研发群落地指南。

一、 团队角色定位与职责矩阵

【用户 (最高指挥官 / 业务需求提出)】
              │
              ▼
┌────────────────────────────────────────────────────────┐
│               Hermes (总管决策者 / Tech Lead)           │
│  - 需求拆解与目标量化                                    │
│  - 状态机推进与工作流调度                                 │
│  - 争议仲裁 (基于证据与事实，绝非投票)                     │
│  - 物理终端验证、Git 版本控制与最终上线发布                │
└───────────────┬────────────────────────┬───────────────┘
                │                        │
        【派发架构与审计】               【派发编码与测试】
                │                        │
                ▼                        ▼
 ┌─────────────────────────────┐  反驳/技术证据  ┌─────────────────────────────┐
 │  A Bot (首席架构师 / 审核者)  │ ◄───────────── │  B Bot (核心程序员 / 实现者) │
 │  - 全局系统设计与模块解耦    │ ─────────────► │  - 功能编码与单元测试编写   │
 │  - P0~P4 问题分级审查       │   审查/证伪攻击  │  - 拒绝临时 if 补丁解决根因 │
 │  - 强制反向推导与最坏情况证伪│                │  - 提供真实测试运行证据     │
 └─────────────────────────────┘                └─────────────────────────────┘
                │                                              │
                └──────────────────────┬───────────────────────┘
                                       │ 提交完整审查证据链
                                       ▼
                         ┌───────────────────────────┐
                         │   Hermes 物理最终验收闸口  │
                         │   ✓ 终端真实测试 exit_code=0  │
                         │   ✓ 零 P0/P1 残留         │
                         │   ✓ 代码与配置生产交付    │
                         └───────────────────────────┘

1. Hermes (总管 / 架构裁决者)

  • 核心定位：项目最高技术管理者与质量守门人，负责调度全流程，拒绝沦为单纯的“任务转发器”。
  • 核心职责：
    1. 理解业务目标并拆解为可执行的原子子任务；
    2. 决定任务何时进入设计、编码、审核与测试阶段；
    3. 负责最终代码质量把控，必要时直接介入修改代码、配置或任务定义；
    4. 当 A 与 B 产生分歧时，基于终端真实运行证据、测试结果与第一性原理做最终技术裁决；
    5. 严禁为了“赶进度”而牺牲系统的稳定性、安全性与可维护性。

2. A Bot (首席架构师 + 全方位独立审核者)

  • 核心定位：批判性思考者、系统设计者与红队证伪专家，重点关注全局正确性而非局部函数能否运行。
  • 底座与算力引擎：
    • 飞书网关交互层：Profile a_architect（Hermes Agent 独立会话进程）；
    • 底层架构攻坚引擎：Factory Droid CLI (gpt-5.5)，负责多模块代码 AST 语法树解析、系统边界推演与自动化反向证伪攻击构造。
  • 核心职责：
    1. 框架构建：项目整体架构、模块划分、数据流、异常捕获体系、数据库与日志规范设计；
    2. 指导 B Bot：说明做什么、为什么做、如何做、严禁怎么做，但避免无意义地替 B 编写大量具体业务代码；
    3. 独立多维审核：涵盖功能正确性、边界条件、并发竞态、资源/句柄泄漏、隐式耦合、配置与回归风险；
    4. 强制反向推导 (Inversion Thinking)：先假设代码存在致命漏洞，主动构造极端异常、断网、超时、重启与数据污染场景进行证伪攻击；
    5. 审核三问：每次签字前必须回答：
      • ① 正常情况下，代码是否正确？
      • ② 异常情况下，系统是否安全？
      • ③ 极端情况下，状态是否可控？

3. B Bot (核心程序员 + 测试实现者)

  • 核心定位：高标准工程实现者与自动化测试执行者。
  • 底座与算力引擎：
    • 飞书网关交互层：Profile b_coder（Hermes Agent 独立会话进程）；
    • 底层工程落地引擎：Factory Droid CLI (claude-opus-5，即 Opus 5)，负责高精度代码生成、跨文件 Patch 重构与自动化测试用例编写，严禁私自降级模型。
  • 核心职责：
    1. 根据 A 的架构契约编写代码并完成功能开发与重构；
    2. 编写配套单元测试，真实运行测试并收集执行日志与证据；
    3. 逐条处理 A 提出的审核意见，修复发现的缺陷；
    4. 有理据的技术反驳：若认为 A 的方案存在技术错误或不必要的复杂度，必须提供明确的问题、技术依据、风险及替代方案（代码/测试证据）。

二、 核心协作 20 条铁律 (最高优先级原则)

  1. 角色绝对分离：A 不追求代码产出量，B 不自判代码最终正确，Hermes 不盲目轻信口头申报。
  2. B 写完 ≠ 任务完成：B 提交仅代表实现结束，必须经 A 审查 ➔ B 修复 ➔ A 复审 ➔ Hermes 物理验收。
  3. A 必须主动找问题：A 必须尝试证明“代码在什么情况下会失败”，而非仅验证“正常情况能跑”。
  4. 强制反向推导：核心功能必须构造极端输入、并发冲突与中断场景进行破坏性测试。
  5. A 必须挑战 B：不得因代码能跑、测试通过就轻易批准，必须评估是否埋下技术债或性能瓶颈。
  6. B 可以反驳 A：反对必须携带技术依据、风险分析与测试代码证据，禁止空对空推测。
  7. 禁止为了通过审核打补丁：严禁添加临时 if、隐藏异常、删除错误日志、硬编码或吞掉错误。
  8. 禁止修改测试掩盖代码问题：测试失败首先假设代码有错，严禁通过降低测试标准制造虚假通过。
  9. 禁止无关修改：不得借“顺手优化”大范围改动无关模块，发现新问题需独立建任务。
  10. 重大修改必须先设计：核心架构、数据库结构、权限认证、交易逻辑改动必须先由 A 出方案。
  11. 所有问题必须闭环：A 提出的问题必须经历“发现 ➔ 分类 ➔ 修复 ➔ 复审 ➔ 关闭”，不留悬空隐患。
  12. 优先修复根因：区分表象与底层逻辑，优先重构状态机或数据模型从根源解决 Bug。
  13. 风险优先于速度：快速实现与可靠实现冲突时，核心功能绝对选择可靠实现。
  14. 证据优先 (Evidence-Based)：事实 > 推测，终端输出 > 口头描述，真实 exit_code > 理论假设。
  15. 重要决策必须留下记录：架构选型、重大代码变更、争议裁决必须留存完整上下文档案。
  16. 禁止互相迎合：三方保持独立技术质疑与独立思考，目标是方案正确而非所有人意见一致。
  17. 技术辩论模式：出现分歧时，A 和 B 分别提交方案依据与风险分析，由 Hermes 最终定夺。
  18. 高风险代码双重验证：涉及资金、交易、认证、核心数据清理的操作必须经过双重推演与隔离测试。
  19. 每次审核回答三问：正常是否正确？异常是否安全？极端是否可控？
  20. Hermes 最终验收标准：必须满足无 P0/P1 缺陷、边界验证通过、测试真实执行成功方可标记 DONE。

三、 潜在问题、系统风险与防御规程 (Pre-Mortem)

潜在问题 / 风险故障表现根本原因物理防御与硬性解决方案
1. 审核无限死锁循环 (Infinite Review Loop)A 与 B 在微小格式或 P3/P4 优化上反复拉锯，消耗海量 Token 与时间。缺乏审查轮次上限与问题分级管控。硬性熔断器 (Max 3 Loops)：单任务审查最多进行 3 轮。第 3 轮未收敛强制上移 Hermes 裁决；P0/P1 必须当场修复，P3/P4 自动沉淀为后续优化清单，不阻断本次合并。
2. 审查惰性 / 形式主义迎合 (Sycophancy)运行多轮后，A Bot 趋于敷衍，看到代码能跑就直接通过审核。上下文疲劳导致角色漂移。负面用例强制清单 (Fuzzing Checklist)：A 签字前必须提交至少 2 组反向证伪用例（包含 None/并发/超时场景），证明已执行破坏性验证。
3. 跨任务上下文爆炸派生子任务时携带过多历史无用聊天记录，导致 Token 膨胀与指令漂移。子 Agent 上下文未做信息提纯。契约化上下文传递：A 只向 B 交付精准的《架构设计与接口契约》；B 只向 A 交付《修改 Diff 与测试执行证据》。
4. 生产环境代码误伤B 在实现功能时意外破坏现有未覆盖测试的隐式功能。修改缺乏基线回归测试。Git Worktree 隔离沙盒：B 只能在隔离的分支/临时工作区中编码与测试，只有 Hermes 在通过验收后执行向生产主干的物理 Merge。
5. 假性测试通过 (False Positive)B 声称“测试已全部通过”，实际未运行测试或测试被 mock 掉。单一依赖模型自我申报。真实终端验证：Hermes 必须在宿主机/测试容器终端真实执行测试脚本，校验 exit_code == 0 及实际覆盖率日志。

五、 原生 Bot Mode (专才 Bot 舰队与多 Agent 协同) 体系融合

Hermes Agent 官方生态（Desktop 与 Gateway）内置了原生的 Bot Mode。其设计哲学是：“把 Hermes 的 Profile 变成一排有名有姓的专才 Bot”。这与我们构建的 A Bot 与 B Bot 架构是100% 同构原生对齐的，无需从零造轮子，可直接复用以下官方底层机制：

                              ┌───────────────────────────────────┐
                              │     Bot Mode (Profile 舰队体系)    │
                              └─────────────────┬─────────────────┘
                                                │
         ┌──────────────────────────────────────┼──────────────────────────────────────┐
         ▼                                      ▼                                      ▼
┌───────────────────────────────┐ ┌───────────────────────────────┐ ┌───────────────────────────────┐
│     多 Bot 房间群聊机制       │ │   点对点派活: message_agent    │ │    独立定时 Routines 机制     │
│ - 2~6 个 Bot 同房间协同会话   │ │ - 动态解析 @mention 调派       │ │ - 命名空间: [bot:名字]        │
│ - 单次输入最多 3 轮串行发言   │ │ - 自动注入队友花名册及分工     │ │ - 普通 cron 挂载到专属 Bot   │
│ - 单次封顶 10 条消息防死循环  │ │ - Fire-and-Forget 异步通知     │ │ - 产物直接落入对应 Bot 专属聊 │
│ - 独立 Group:xxx 上下文隔离   │ │ - 杜绝口头原样传话，自主组织   │ │   天记录，随时等待验收        │
└───────────────────────────────┘ └───────────────────────────────┘ └───────────────────────────────┘

1. Profile 即 Bot (专才 Bot 的原生隔离性)

  • 本质定义：一个 Bot 就是一个独立的 Hermes Profile（存储于 ~/.hermes/profiles/<name>/）。
  • 四大原生独立资产：
    • 独立模型：A Bot 绑定大推理/架构模型，B Bot 绑定代码主力模型；
    • 独立记忆与人设：A 的 SOUL.md 注入架构审查哲学与质疑铁律，B 的 SOUL.md 注入严密编码与测试铁律；
    • 独立技能与工具集：A 开启架构、审查与静态分析工具，B 开启完整 terminal、代码编译与测试运行工具；
    • 独立凭据与环境：每个 Bot 维护独立的上下文与历史记录，避免多角色共处一室时的角色退化或认知污染。

2. 拉群开会 (Group Rooms)：2~6 个 Bot 独立房间协同

  • 会议触发机制：
    • 用户或 Hermes 在群房间发言，最多触发 3 轮串行发言；
    • @定向唤醒：被 @ 的 Bot 必须应答；未 @ 任何 Bot 时，有意见的 Bot 自主发言，无新观点则静默 Pass；
    • 自动安静收敛：若整整一轮没有 Bot 接话，房间自动平息，等待下一次指令。
  • 物理防刷屏熔断：单次输入最多 3 轮、总共 10 条消息硬性封顶，物理杜绝 A 和 B 互相辩论刷屏导致 Token 击穿。
  • 上下文隔离：每个 Bot 内部维护独立的 Group:<room_name> 会话，群聊记忆与个人独立工作流互不串味。

3. 点对点派活：message_agent 原生工具链

  • 不是简单转发，而是自主重组：在会话中输入 @researcher 帮我看下这个，发送端 Bot 不会死板复读，而是结合当前上下文用自己的语言调用底层的 message_agent 工具： 
    message_agent(target="coder", message="架构方案已确定，请基于以下契约实现模块...")
  • 自动身份署名：接收方 Bot 收到消息会自动带有官方署名前缀 Message from 🤖 <sender> (@<sender>):，明确任务来源与责任链。
  • Fire-and-Forget 异步通知：发送方发出后立刻完成当前轮次（避免同步阻塞死等）；接收方在自己的 Canonical Bot Chat 中跑完后，以后台通知（Background Completion Notification）形式送回。
  • 天生熟知队友名单 (Teammate Roster)：每个 Bot 启动时，系统 Prompt 自动注入全局活跃队友名单及其职能描述，Bot 自主知晓该把什么专业领域的任务派给谁。

4. 挂载 Routines：定时任务专属归属

  • 架构映射：Bot 的 Routine 本质上就是 Hermes 底层的 Cron 定时任务，采用统一命名空间 [bot:名字] <任务名>（例如 [bot:A_Architect] 每周架构巡检）。
  • 就地交付免搬运：任务执行产物直接写入该 Bot 自己的 Canonical Bot Chat 中，打开该 Bot 即可审查交付成果，与全局杂乱日志物理隔离。

六、 飞书专属研发群协作落地方案

将三方协作过程完全透明化推送到一个专属飞书群，用户可随时以“指挥官”视角旁观、介入或叫停。

方案 A：三独立应用同群直聊（🌟 视觉与沉浸感最佳）

  • 架构设计：
    • 在飞书开放平台创建 3 个独立自建应用：
      1. Hermes（总管决策者）
      2. A Bot (架构审计)
      3. B Bot (核心研发)
    • 将 3 个 Bot 拉入同一个飞书私有群（如【Titan-Q 核心量化研发指挥部】）；
    • 主控 Hermes 获取三者的 App 凭据，在不同工作阶段调用对应 Bot 的身份在群内发送消息。
  • 群聊效果示例：
    • 👤 老大：“重构 clbot 的长连接重连模块”
    • 🤖 Hermes：“已立项（任务 #201），启动三方协作流程，分发 A Bot 进行架构设计。”
    • 📐 A Bot：“【架构方案】提出子线程沙盒重定向 ws.client.loop 方案。⚠️ 极端推演：需防止 GC 析构崩溃。”
    • 💻 B Bot：“【代码实现】完成编码并注入 finally 清理，本地执行 3 轮并发测试通过（exit_code=0）。”
    • 📐 A Bot：“【代码复审】P1 问题：退出前未主动 cancel 缓存定时器！请补充修复。”
    • 💻 B Bot：“【缺陷修复】已在 finally 补充 _cache._cron.cancel()。”
    • 🤖 Hermes：“【终审验收】实测通过，无 P0/P1 遗留，代码合并并推送到生产 VPS ✅。”

方案 B：单应用多色卡片路由（零额外凭据，轻量极速）

  • 架构设计：
    • 使用现有的单个 Hermes 飞书应用；
    • 在发送群消息时，通过飞书高级互动卡片（Interactive Cards）的专属颜色页眉与前缀区分主体：
      • 🟣 [🤖 Hermes 决策总管]（紫色页眉）
      • 🔵 [📐 A Bot 首席架构]（蓝色页眉）
      • 🟢 [💻 B Bot 核心程序员]（绿色页眉）

七、 后续部署实施 Checklist

  • 步骤 1：在 Hermes 中创建专属 Profile：hermes profile create A_Architect 与 hermes profile create B_Coder，分别配置专属的 SOUL.md、模型及工具集；
  • 步骤 2：在 ~/.hermes/skills/ 下固化创建 multi-bot-dev-team 技能，封装 20 条铁律与工作流调度 Prompt；
  • 步骤 3：在飞书开放平台创建 A Bot 与 B Bot 应用，获取凭据并拉入同一个【研发指挥群】（或配置多色卡片路由）；
  • 步骤 4：挂载日常代码巡检与架构自检 Routine（如 [bot:A_Architect] 代码质量巡检）；
  • 步骤 5：挑选一个量化辅助模块进行端到端闭环沙盒压力演练（验证 A 质疑 ➔ B 实现 ➔ A 复审 ➔ Hermes 终审）。

相关链接

Graph View

Backlinks