AI朝廷三省六部

AI朝廷三省六部协作系统。将中国唐代三省六部制映射到多Agent协作框架，实现"起草-审核-执行"的分权制衡流程。 触发场景： - 用户要求多Agent协作完成任务 - 需要评审、质检、审核流程 - 复杂任务需要分解与协调 - 提及"朝廷"、"三省"、"六部"、"封驳"、"协作"等关键词 - 需要角色扮演式任务处理

将唐代三省六部制转化为多Agent协作框架，实现分权制衡与专业化分工。

核心理念

text

┌─────────────────────────────────────────────────────────────┐
│                         用  户 (皇帝)                        │
└─────────────────────────────────────────────────────────────┘
          │                              │
          ▼                              ▼
┌─────────────────┐              ┌─────────────────┐
│    中书省       │              │    门下省       │
│  (规划起草)     │───────────▶  │  (审核封驳)     │
│  规划Agent      │   草案       │  评审Agent      │
└─────────────────┘              └─────────────────┘
          │                              │
          │         通过                 │
          └──────────────────────────────┘
                         │
                         ▼
              ┌─────────────────┐
              │    尚书省       │
              │  (执行调度)     │
              │  执行调度器     │
              └─────────────────┘
                         │
          ┌──────┬──────┼──────┬──────┬──────┐
          ▼      ▼      ▼      ▼      ▼      ▼
        吏部   户部   礼部   兵部   刑部   工部
       人事   财务   文档   策略   合规   工程

三省职责

中书省 — 规划起草

触发时机： 接收用户任务后第一步

核心职责：

1. 分析任务需求
2. 制定执行计划
3. 起草方案草案
4. 分配六部职责

输出格式：

markdown

## 诏令草案 [任务ID]

### 任务分析
- 背景：
- 目标：
- 约束：

### 执行计划
1. [步骤1] - 负责部门：工部
2. [步骤2] - 负责部门：吏部
3. ...

### 资源分配
- 吏部：[人力需求]
- 户部：[预算需求]
- 工部：[技术需求]

### 预期产出
- [产出物1]
- [产出物2]

---
起草：中书省
时间：[ISO时间]

---

门下省 — 审核封驳

触发时机： 收到中书省草案后

核心职责：

1. 审核方案可行性
2. 检查遗漏与风险
3. 提出修改建议
4. 决定通过/封驳

审核清单：

markdown

## 门下省审核表

### 可行性检查
- [ ] 技术可行性
- [ ] 资源充足性
- [ ] 时间合理性
- [ ] 依赖完整性

### 风险检查
- [ ] 安全风险
- [ ] 合规风险
- [ ] 依赖风险

### 遗漏检查
- [ ] 边界情况
- [ ] 异常处理
- [ ] 回滚方案

### 决定
- [ ] 通过 - 可交付尚书省执行
- [ ] 封驳 - 需中书省重拟，原因：[具体原因]

---
审核：门下省
时间：[ISO时间]

封驳权： 门下省有权直接驳回不合规方案，中书省必须修改后重新提交

---

尚书省 — 执行调度

触发时机： 门下省审核通过后

核心职责：

1. 接收通过诏令
2. 调度六部执行
3. 监控执行进度
4. 汇报执行结果

执行报告格式：

markdown

## 执行报告 [任务ID]

### 执行状态
| 部门 | 任务 | 状态 | 产出 |
|------|------|------|------|
| 工部 | [任务] | ✅ 完成 | [链接/文件] |
| 吏部 | [任务] | 🔄 进行中 | - |

### 问题与决策
- [问题1] → 决策：[处理方式]
- [问题2] → 决策：[处理方式]

### 最终产出
- [产出物1]：[链接/内容]
- [产出物2]：[链接/内容]

---
执行：尚书省
时间：[ISO时间]

---

六部专长

部门	职责	适用场景
吏部	人事管理、Agent调度、角色分配	团队组建、角色定义、权限管理
户部	预算管理、资源规划、成本估算	预算评估、资源分配、ROI分析
礼部	文档撰写、沟通协调、对外交互	文档生成、报告撰写、用户沟通
兵部	策略制定、竞争分析、方案对比	技术选型、方案PK、竞争策略
刑部	合规检查、安全审计、风险识别	代码审计、安全检查、合规验证
工部	工程实施、代码构建、技术实现	编码、部署、测试、运维

详细说明： 见 references/six-ministries.md

---

工作流程

标准流程

text

用户请求 → 中书省起草 → 门下省审核 → [通过?]
                                          ↓
                     ┌─────── 否 ────────┤
                     ↓                    ↓
              中书省重拟              尚书省执行
                                          ↓
                                    六部协作
                                          ↓
                                    执行报告 → 用户

快速流程（简单任务）

对于简单任务（单步骤、无依赖），可跳过门下省审核：

text

用户请求 → 中书省起草（简化版）→ 尚书省执行 → 结果返回

简单任务判定标准：

• 单一步骤
• 无外部依赖
• 无安全风险
• 无合规要求

---

使用示例

示例1：代码项目开发

text

用户：帮我开发一个命令行TODO工具

中书省起草：
├── 分析：CLI工具，需文件存储，Python实现
├── 计划：工部负责开发，刑部负责安全检查，礼部负责文档
└── 预期：可执行CLI + README

门下省审核：
├── 检查：技术可行 ✅，资源充足 ✅，时间合理 ✅
├── 风险：无安全风险 ✅
└── 决定：通过

尚书省执行：
├── 工部：开发 todo.py
├── 刑部：检查文件操作安全性
├── 礼部：编写 README.md
└── 交付：可执行工具 + 文档

示例2：复杂决策（封驳场景）

text

用户：帮我设计一个支付系统

中书省起草：
├── 分析：支付网关，对接支付宝/微信
├── 计划：工部开发，户部预算...
└── [遗漏：安全审计、合规检查]

门下省审核：
├── 检查：技术可行 ✅
├── 风险：支付安全风险 ❌（未提及）
├── 合规：PCI-DSS ❌（未考虑）
└── 决定：封驳
    └── 原因：缺少安全审计方案，需补充刑部安全检查、合规评估

中书省重拟：
├── 补充：刑部安全审计，合规检查
├── 新增：沙箱测试阶段
└── 重新提交 → 门下省 → 通过

---

历史典故参考

三省制起源于隋唐，核心是分权制衡：

• 唐太宗贞观之治：魏征（门下省给事中）多次封驳诏令，太宗虚心接受
• 斜封官事件：唐中宗绕过三省直接任命，被朝野耻笑
• 王安石变法：门下省封驳青苗法，朝堂博弈

核心价值： 即使是"皇帝"（用户）的命令，也要经过审核才能执行。这不是效率问题，是质量与安全的问题。

---

🚀 快速启动

一键生成工作流文档

bash

node bin/court-start.js "任务名称"

将生成三个文档：

• records/{id}-draft.md — 诏令草案
• records/{id}-review.md — 审核表格
• records/{id}-exec.md — 执行报告

常用命令

命令	说明
启动朝廷 [任务]	启动完整工作流
中书省起草 [任务]	仅起草阶段
门下省审核	审核当前方案
尚书省执行	执行通过方案
六部汇报	各部门状态汇报

---

📚 参考文档

• 六部详解 — 六部职责与输出格式
• 执行示例 — 常见场景示例

---

注意事项

1. 封驳不是拒绝：是要求改进，最终目标是把事情做好
2. 三省协作而非对抗：共同为用户负责，而非互相刁难
3. 灵活运用：简单任务简化流程，复杂任务严格流程
4. 保留记录：所有诏令、审核、执行报告应记录存档

---

更新日志

v1.1.0 (2026-03-21)

• ✨ 新增快速启动脚本 bin/court-start.js
• 📚 新增执行示例文档 references/examples.md
• 📝 完善命令参考表

v1.0.0 (2026-03-18)

• 🎉 初始发布
• ✨ 三省六部协作框架
• ✨ 分权制衡工作流

---

此技能借鉴唐代三省六部制的智慧，应用于AI Agent协作。让每项任务都经过规划、审核、执行的完整流程，确保质量与安全。