🏛️ 三省六部架构实施方案
基于 cft0808/edict 项目的多智能体协作架构，为我们的团队设计实施方案。
一、现有架构分析
当前团队组成
| Agent | 角色 | 端口 | 主要职能 |
|---|---|---|---|
| 小蓝 | 队长 | 18789 | 统筹协调 |
| 虾2号 | 研究 | 28789 | 文献调研 |
| 虾3号 | 替补 | 38789 | 协助执行 |
| 程序虾 | 代码 | 48789 | 代码实现 |
当前问题
- 任务分配不透明
- 缺乏质量审核机制
- 流程不可观测
- 无法实时干预
二、目标架构设计
2.1 五阶段审批流
深蓝 → 小蓝(太子) → 虾2号(中书省) → 小蓝(门下省) → 执行Agent → 汇总回复
2.2 Agent角色映射
| 新角色 | 对应Agent | 职能 |
|---|---|---|
| 🐢 太子 | 小蓝 | 消息分拣、判断任务类型 |
| 📋 中书省 | 虾2号 | 规划方案、任务拆解 |
| 🚫 门下省 | 小蓝 | 审核方案、可封驳 |
| 📦 尚书省 | 小蓝 | 派发任务、汇总结果 |
| ⚔️ 兵部 | 程序虾 | 代码实现 |
| 📚 吏部 | 虾3号 | 文档整理、知识库 |
三、核心流程设计
3.1 消息分拣规则
小蓝直接回复（不建任务）：
- 简短回复：「好」「否」「了解」
- 闲聊/问答：「token消耗多少？」
- 信息查询：「xx是什么」
- 内容不足10个字
创建任务（转中书省）：
- 明确工作指令：「帮我做XX」「调研XX」
- 包含具体目标或交付物
- 有实质内容（≥10字）+ 动作词
3.2 任务流转状态
Pending → Taizi → Zhongshu → Menxia → Assigned → Doing → Review → Done
3.3 审核机制
- 中书省规划完成后，必须提交门下省审核
- 门下省可以：准奏 → 执行 / 封驳 → 返回修改
- 最多3轮封驳循环
四、看板系统
4.1 任务数据结构
{
"id": "JJC-20260307-001",
"title": "任务标题",
"state": "Zhongshu",
"org": "中书省",
"created_at": "2026-03-07T17:00:00Z",
"flow": [...]
}
4.2 关键脚本
- kanban_create.py – 创建任务
- kanban_state.py – 更新状态
- kanban_flow.py – 记录流转
- kanban_done.py – 完成任务
五、实施计划
Phase 1：基础架构（1周）
- 建立任务管理系统（JSON文件存储）
- 定义Agent角色和权限
- 实现消息分拣逻辑
Phase 2：审核机制（1周）
- 实现中书省→门下省审核流程
- 添加封驳/重做逻辑
- 完善任务状态机
Phase 3：可视化（2周）
- 开发简易看板（Web界面）
- 实现任务监控
- 添加实时状态推送
Phase 4：飞书集成（1周）
- 飞书消息接入
- 任务状态同步
- 推送通知
六、权限矩阵
| Agent | 可调用 |
|---|---|
| 小蓝(太子) | 中书省 |
| 虾2号(中书省) | 门下省、尚书省 |
| 小蓝(门下省) | 尚书省、回调中书 |
| 小蓝(尚书省) | 六部(程序虾、虾3号) |
| 程序虾(兵部) | – |
| 虾3号(吏部) | – |
七、风险与对策
| 风险 | 对策 |
|---|---|
| 流程复杂影响效率 | 简化场景，复杂任务才走全流程 |
| 审核循环过长 | 最多3轮封驳 |
| 实现难度大 | 分阶段，先实现核心功能 |
方案制定：2026-03-07
参考：cft0808/edict 项目