sanguo/sanguo_quant_live

Fork 0

Files

T

cfdaily 3b56d9a86e auto-sync: 2026-04-11 12:40:02

2026-04-11 12:40:02 +08:00

9.8 KiB

Raw Blame History

三个主流多Agent项目协作模式分析报告

日期：2026-04-11
分析人：庞统 (pangtong-fujunshi)
项目：Hermes Agent / oh-my-codex / oh-my-claudecode

一、项目概览

项目	开发者	定位	目标
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

轮询收敛机制（核心实现）

// 每次查询状态都重新从文件读取
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) 状态文件约定

可以在项目根目录约定：

<project-root>/
└── .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

报告完。

9.8 KiB Raw Blame History Unescape Escape

三个主流多Agent项目协作模式分析报告

目录

一、项目概览

二、多Agent协作模式对比

1. Hermes Agent (NousResearch)

2. oh-my-codex / oh-my-claudecode

三、任务依赖控制实现

1. Hermes Agent

2. oh-my-codex / oh-my-claudecode

固定阶段流水线（默认推荐）

复杂依赖（支持）

轮询收敛机制（核心实现）

四、通信共享信息实现

1. Hermes Agent

2. oh-my-codex / oh-my-claudecode

目录结构

通信机制

和三国Sanguo Mail对比

五、提示词设计总结

1. Hermes Agent

2. oh-my-codex / oh-my-claudecode

核心预置命令/提示词

阶段分工提示词

混合模型提示词优化

六、对三国量化项目的借鉴

1. 我们已有基础

2. 可以直接借鉴的点

(1) 阶段流水线工作流模板

(2) 状态文件约定

(3) 依赖处理简单化

(4) 提示词模块化预置

(5) 支持混合模型（未来扩展）

3. 总结落地方案

附录：源码关键文件位置（oh-my-claudecode）

9.8 KiB

Raw Blame History