sanguo/sanguo_vnpy

Fork 0

Files

T

cfdaily 5e6b2d73eb initial-import: 2026-04-11 21:18:55

2026-04-11 21:18:55 +08:00

6.3 KiB

Raw Blame History

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

步骤：

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

优点：

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

需要做的改造

在edict中添加我们的角色映射（不改核心，只加配置）
- 修改 data/departments.json 映射我们的角色
- 修改 data/states.json 匹配我们的状态流转
在我们的任务创建脚本中添加同步
- management/workflow/scripts/create_task*.sh 添加几行curl调用
在我们的任务状态更新脚本中添加同步
- 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

#!/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

第四步：测试验证

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

优势总结

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

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

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

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

6.3 KiB Raw Blame History Unescape Escape