cfdaily
305 lines
9.8 KiB
Markdown
305 lines
9.8 KiB
Markdown
# 三个主流多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) 状态文件约定
|
||
|
||
可以在项目根目录约定：
|
||
|
||
```
|
||
<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`
|
||
|
||
---
|
||
|
||
**报告完**。
|