# 三个主流多Agent项目协作模式分析报告 **日期**:2026-04-11 **分析人**:庞统 (pangtong-fujunshi) **项目**:Hermes Agent / oh-my-codex / oh-my-claudecode --- ## 目录 1. [项目概览](#一项目概览) 2. [多Agent协作模式对比](#二多agent协作模式对比) 3. [任务依赖控制实现](#三任务依赖控制实现) 4. [通信共享信息实现](#四通信共享信息实现) 5. [提示词设计总结](#五提示词设计总结) 6. [对三国量化项目的借鉴](#六对三国量化项目的借鉴) --- ## 一、项目概览 | 项目 | 开发者 | 定位 | 目标 | |------|--------|------|------| | **Hermes Agent** | NousResearch | 自进化自治Agent框架 | 打造能随用户一起成长的自主Agent,从经验创建技能 | | **oh-my-codex** | Yeachan-Heo | OpenAI Codex CLI 工作流层 | 为 Codex CLI 预置标准工作流和专家技能 | | **oh-my-claudecode** | Yeachan-Heo | Claude Code 多Agent编排插件 | 为 Claude Code 提供阶段化流水线多Agent协作 | --- ## 二、多Agent协作模式对比 ### 1. Hermes Agent (NousResearch) **协作模式**:原生内置 **主Agent ↔ 隔离子Agent** 层次结构 - 主Agent:理解需求 → 分解任务 → 生成子Agent提示词 → 等待结果 → 整合输出 - 子Agent:执行分配的具体任务 → 写结果到共享内存 → 汇报完成 - **特点**:原生支持动态生成子Agent,主Agent全权调度 ### 2. oh-my-codex / oh-my-claudecode **协作模式**:**阶段化流水线 + 同阶段并行** 固定流程: ``` 深度访谈澄清需求 → 制定方案计划 → 拆解任务 → 多worker并行执行 → 验证评审 → 修复循环 → 汇总交付 ``` - **阶段之间**:顺序执行,必须等前一阶段完成才进入下一阶段 - **同一阶段**:多个worker完全并行,无依赖 - **特点**:开箱即用,适合大多数软件开发任务,用户不用自己设计流程 --- ## 三、任务依赖控制实现 ### 1. Hermes Agent - **实现**:主Agent负责依赖调度,动态生成子Agent时声明依赖 - 支持Python脚本RPC编排,可以显式定义依赖顺序 - 优点:灵活;缺点:需要编写编排代码 ### 2. oh-my-codex / oh-my-claudecode #### 固定阶段流水线(默认推荐) ``` 澄清 → 计划 → 执行 → 验证 → 修复 ``` - 天然满足依赖:前面阶段输出就是后面阶段输入 - 同一阶段内并行任务无依赖,直接同时跑 - **简单够用**,绝大多数软件开发任务都能套这个流程 #### 复杂依赖(支持) 如果任务需要自定义依赖: - 每个任务JSON声明 `depends_on: [task-id...]` - 系统轮询检查所有依赖任务状态,全部 `completed` 才解锁当前任务 - 状态存在文件系统:`.omx/state/team/{name}/tasks/task-{id}.json` #### 轮询收敛机制(核心实现) ```typescript // 每次查询状态都重新从文件读取 while (!timeout) { for (all tasks) { // 从结果工件文件读取状态 const artifact = readResultArtifact(jobId); // 如果结果文件标记完成,更新任务状态 convergeJobWithResultArtifact(job, jobId); } // 检查是否全部terminal if (allTasksTerminal()) break; // 指数退避等待 await sleep(pollDelay); pollDelay = min(pollDelay * 1.5, 2000); } ``` **没有用任何开源第三方调度库**,完全手写文件轮询,简单可靠。 --- ## 四、通信共享信息实现 ### 1. Hermes Agent - **通信方式**:共享持久化内存 + 主Agent中转 - 所有Agent都能读写共享记忆库 - 支持全文搜索,跨会话回忆 ### 2. oh-my-codex / oh-my-claudecode **核心设计思想:文件系统就是共享总线** #### 目录结构 ``` project-root/ └── .omx/ └── state/ └── team/{team-name}/ ├── manifest.v2.json # 团队信息 ├── mailbox/ │ ├── worker1.json # 每个worker一个邮箱,存消息 │ └── worker2.json ├── tasks/ │ ├── task-0.json # 每个任务一个文件,包含状态/依赖/结果 │ └── task-1.json └── events/ └── events.ndjson # 事件日志,append-only ``` #### 通信机制 - **发消息**:写到接收方mailbox JSON文件 - **收消息**:从自己mailbox JSON文件读取 - **任务输入输出**:每个任务从指定文件读输入,写完结果到指定文件 - **总结**:**文件就是通信**,没有IPC,没有复杂机制,简单到不会丢消息 #### 和三国Sanguo Mail对比 | 点 | oh-my-claudecode | 三国Sanguo Mail | |----|-----------------|-----------------| | 状态存储 | `.omx/state/` JSON文件 | 项目git目录 + 各将军工作目录 | | 消息通信 | 文件mailbox | Sanguo Mail + 文件 | | 依赖检查 | 轮询文件状态 | 邮件通知 + 主军师调度 | | 并行 | tmux多CLI真并行 | 多Agent独立会话真并行 | | 优点 | 单机全自动 | 分布式跨机器,支持团队协作 | **核心思想一致**:都是**文件系统做共享总线**,状态存在文件,靠文件变化推进流程。 --- ## 五、提示词设计总结 ### 1. Hermes Agent **设计思路**:自主技能进化,提示词随使用自动改进 - **系统提示**:定义自主学习身份能力 - **技能创建提示**:从对话提取新技能,生成格式完整的技能文档 - **技能改进提示**:基于使用反馈优化提示词 - **用户建模提示**:持续学习用户偏好 - **记忆压缩提示**:压缩长期记忆,保留关键信息 ### 2. oh-my-codex / oh-my-claudecode **设计思路**:预置专家角色+阶段化提示词,开箱即用 #### 核心预置命令/提示词 | 命令 | 作用 | |------|------| | `/deep-interview` | 苏格拉底式提问澄清需求,揭示隐藏假设 | | `/team N:role "task"` | 启动Team阶段流水线 | | `/omc-teams N:model "task"` | 启动tmux多CLI混合模型 | | `/plan` | 只执行计划阶段,输出plan.md | | `/exec` | 只执行阶段 | #### 阶段分工提示词 每个阶段独立提示词模板,**只干一件事**: | 阶段 | 职责 | 输出 | |------|------|------| | 深度访谈 | 澄清需求,确认验收标准 | `requirements.md` | | 团队计划 | 拆分任务,识别依赖 | `plan.md` + `tasks/` | | 团队执行 | 并行执行任务 | `results/` | | 团队验证 | 代码评审,质量检查 | `issues.md` | | 团队修复 | 根据问题修复 | 更新结果 | #### 混合模型提示词优化 当使用多模型混合时,提示词会**强化模型优势**: - Codex:你擅长代码分析和审查,请重点关注架构和安全 - Gemini:你擅长设计和文档,请产出清晰的设计方案 - Claude:你擅长编码实现,请根据设计写出完整代码 让每个模型干它擅长的,提示词配合模型能力定制优化。 --- ## 六、对三国量化项目的借鉴 ### 1. 我们已有基础 - ✅ Sanguo Mail 异步消息通信已经搞定 - ✅ 各将军分工已经明确 - ✅ Git + 文件系统共享已经在用 - ✅ 多Agent跨机器并行已经支持 ### 2. 可以直接借鉴的点 #### (1) 阶段流水线工作流模板 针对代码输出型项目(sanguo_vnpy / sanguo_quant_live),可以照搬这个阶段化流水线: ``` 需求澄清 → 方案计划 → 拆解任务 → 并行执行 → 验证评审 → 修复循环 → 汇总交付 ``` 每个阶段对应发邮件给相应将军: - 需求澄清 → 庞统/诸葛亮 - 方案计划 → 庞统/诸葛亮 - 执行 → 张飞/关羽/赵云 按分工 - 验证 → 司马懿 - 修复 → 返还给对应将军 - 汇总 → 诸葛亮/庞统 **这就是标准流程,新项目直接套用,不用每次重新商量怎么走**。 #### (2) 状态文件约定 可以在项目根目录约定: ``` / └── .sanguo/ └── state/ └── team/{team-name}/ ├── config.json ├── tasks/ ├── mailbox/ └── events/ ``` 和 oh-my-claudecode 一样,靠文件状态推进流程,不用改造Sanguo Mail。 #### (3) 依赖处理简单化 - 大部分项目用固定阶段流水线就够了,不用复杂DAG调度 - 需要自定义依赖的任务,走**文件状态检查**:每个任务声明依赖,轮询检查依赖完成解锁 - 我们有Sanguo Mail,依赖完成可以发邮件通知,比纯轮询更高效 #### (4) 提示词模块化预置 按角色/阶段预置提示词模板: ``` prompts/ ├── deep-interview.md # 需求澄清 ├── team-plan.md # 计划拆解 ├── team-exec.md # 任务执行 ├── team-verify.md # 验证评审 └── team-fix.md # 修复问题 ``` 每个将军接过任务,直接用对应模板,保证输出格式一致。 #### (5) 支持混合模型(未来扩展) 我们也可以支持"**不同将军用不同模型**",提示词按模型优势定制: - 比如:赵云(数据)用某个模型,张飞(编码)用另一个模型,司马懿(评审)用第三个模型 - 因为我们本来就是独立进程,天然支持混合模型,和 oh-my-claudecode 的 tmux 混合思路一致 ### 3. 总结落地方案 | 层 | 已有 | 需要新增 | |-----|------|----------| | 通信层 | Sanguo Mail | - | | 状态层 | 文件系统 | 新增 `.sanguo/state/` 目录约定 | | 流程层 | - | 新增 阶段流水线脚本 + 预置提示词模板 | | 依赖层 | - | 新增简单依赖检查工具 | **工程量很小**,就是在现有Sanguo Mail上层加一层流程编排,不用改底层。 --- ## 附录:源码关键文件位置(oh-my-claudecode) - 状态类型定义:`src/interop/omx-team-state.ts` - 任务收敛:`src/mcp/team-job-convergence.ts` - tmux进程管理:`src/team/tmux-session.ts` - MCP服务器:`src/mcp/team-server.ts` --- **报告完**。