# edict 适配 sanguo_quant 多agent组织架构方案

## 当前现状对比

### 我们 sanguo_quant 现有架构

```
你 (丞相/总军师) → 诸葛亮 (总军师) → 拆解任务 → 分配给 庞统/司马懿/张飞/关羽/赵云/姜维 → 各将军执行 → 回报丞相 → 汇总交付
```

| 角色 | 职责 | 对应三省六部 |
|------|------|--------------|
| 你 | 皇帝/最高决策者 | 皇上 |
| 诸葛亮 | 总军师 | 太子 + 中书省 |
| 庞统 | 副军师/策略设计 | 中书省 + 协助规划 |
| 司马懿 | 质量总监 | 门下省 (审核) |
| 各将军 (张飞/关羽/赵云/姜维) | 六部 (执行) | 六部 |
| 姜维 | 基础设施/运维 | 工部 |

### edict 原有架构

```
皇上 → 太子 (分拣) → 中书省 (规划) → 门下省 (审核) → 尚书省 (派发) → 六部 (执行) → 回奏
```

---

## 适配方案：保持我们现有接口不变，集成edict仪表盘

### 目标
- ✅ **不改变我们现有的组织分工和工作流**
- ✅ **获得edict的实时仪表盘**好处：
  - 可视化任务进度看板
  - 完整审计追踪（每一步谁做了什么都记录）
  - 状态流转清晰
  - 可以随时干预（叫停/恢复）

### 架构设计

```
sanguo_quant                edict
─────────────────┐       ┌──────────────────
 你的需求        │       │
    ↓            │       │
  诸葛亮         │       │
    ↓ 拆解分配   │       │
  创建任务       ┼───────▶│  edict 记录任务状态
    ↓            │       │
  各将军执行     │       │
    ↓ 更新进度   ┼───────▶│  更新状态流转
    ↓            │       │
  司马懿审核     │       │
    ↓ 更新       ┼───────▶│ 更新审核状态
    ↓            │       │
  交付汇总       ┼───────▶│ 标记完成
    ↓            │       │
  你             │◀───────┤  通过看板查看进度
```

### 数据映射

| sanguo_quant 状态 | edict 状态 | 说明 |
|------------------|-----------|------|
| assigned | Assigned/Doing | 已分配给将军执行 |
| in_progress | Doing | 执行中 |
| review | Review | 司马懿审核中 |
| approved | Done | 审核通过，完成 |
| rejected | Blocked | 审核驳回，阻塞 |
| cancelled | Cancelled | 已取消 |

| sanguo_quant 角色 | edict 部门 |
|------------------|------------|
| 诸葛亮 | 中书省 |
| 庞统 | 中书省 |
| 司马懿 | 门下省 |
| 张飞 | 工部 |
| 关羽 | 兵部 |
| 赵云 | 户部 |
| 姜维 | 工部 |

---

## 改造方案：轻量化适配，不侵入原有代码

### 方案A：独立服务 + API同步（推荐，最简改造）

**原理**：edict容器独立运行，我们通过HTTP API同步任务状态到edict

步骤：
1. edict容器保持现在这样运行（端口7891）
2. 在我们现有任务管理脚本中，添加几行HTTP API调用：
   - 创建任务 → `POST /api/create`
   - 更新状态 → `POST /api/update`
3. 我们原有工作流完全不变，只是多了一步同步状态到edict
4. 你可以随时打开 `http://your-host:7891` 查看可视化看板

**优点**：
- ✅ 完全不改动我们现有代码架构
- ✅ 零侵入，只是添加API调用
- ✅ 风险极低，即使edict挂了不影响我们工作
- ✅ 可以随时停用

### 需要做的改造

1. **在edict中添加我们的角色映射**（不改核心，只加配置）
   - 修改 `data/departments.json` 映射我们的角色
   - 修改 `data/states.json` 匹配我们的状态流转

2. **在我们的任务创建脚本中添加同步**
   - `management/workflow/scripts/create_task*.sh` 添加几行curl调用

3. **在我们的任务状态更新脚本中添加同步**
   - `assign_task*.sh` 等脚本添加状态更新调用

### 方案B：深度集成，让edict接管流转控制（不推荐，改变原有接口）

如果让edict原生接管整个流转，会改变我们现有的分工接口，不符合你"不想改变组织接口"的要求，所以不推荐。

---

## 具体实施步骤（方案A）

### 第一步：在edict数据目录添加我们的配置

```
# 进入容器
docker exec -it edict-new bash

# 修改部门配置
cp /app/data/departments.json /app/data/departments.json.backup
# 替换为sanguo_quant的部门配置
```

### 第二步：添加API调用封装

在我们的项目中添加一个小脚本：
`jiangwei-platform/deploy/edict/sync-status.sh`

```bash
#!/bin/bash
# 同步任务状态到edict看板

EDICT_URL="http://localhost:7891"

# 创建任务
# Usage: create-edict-task <task-id> <title> <assignee>
create-edict-task() { ... }

# 更新任务状态
# Usage: update-edict-status <task-id> <state>
update-edict-status() { ... }
```

### 第三步：改造现有脚本

在现有这些脚本中添加一行调用：
- `create_task*.sh` → 创建任务后调用 create-edict-task
- `assign_task*.sh` → 分配后更新状态 to Assigned
- 任务完成后 → 更新状态 to Review
- 司马懿审核通过 → 更新状态 to Done
- 司马懿驳回 → 更新状态 to Blocked

### 第四步：测试验证

1. 创建一个测试任务
2. 检查edict看板是否正确显示
3. 检查状态流转是否正确

---

## 优势总结

| 要点 | 说明 |
|------|------|
| **不改变原有组织接口** | 我们的分工、工作流、角色职责完全不变 |
| **零侵入改造** | 只添加API调用，不修改原有逻辑 |
| **获得可视化收益** | 有了实时看板，任务进度一目了然 |
| **完整审计追踪** | 所有任务状态变化都记录在edict |
| **回滚方便** | 如果不用了，直接停掉docker容器就行，不影响我们系统 |
| **风险极低** | 即使edict出问题，我们原有工作流不受影响 |

---

## 产出物结构（在我们项目中）

```
sanguo_vnpy/
└── jiangwei-platform/
    └── deploy/
        └── edict/
            ├── README.md               # 部署使用说明
            ├── sync-status.sh          # API封装脚本
            └── sanguo-departments.json # 我们的部门配置
```

---

*结论：方案A推荐采用，最快半天就能完成改造，完全满足你的需求"不改变组织接口，获得edict仪表盘能力"。*