AI朝廷三省六部

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

Security Scan

The skill's files, instructions, and runtime behavior align with its stated purpose (a multi‑agent, draft-review-execute workflow); it contains a small local Node script that only creates markdown records and does not access network, credentials, or unrelated system resources.

Purpose & Capability

The name/description promise (map the Tang 三省六部 to a multi‑agent draft→review→execute workflow) matches the provided assets: SKILL.md documents the process and examples, references explain roles, and bin/court-start.js generates the expected draft/review/exec markdown files. There are no extraneous environment variables, binaries, or requirements that don't fit the described purpose.

Instruction Scope

SKILL.md instructs the agent and the user about running the local Node script and outlines agent role behavior and templates. The runtime instructions do not prompt reading arbitrary system files, accessing environment variables, or contacting external endpoints. The guidance is broad (describes agents '调度', '角色分配') but stays within the domain of coordinating agents and producing documentation rather than performing hidden I/O.

Install Mechanism

There is no install spec (instruction-only style). The included Node script and package.json are small and local; no downloads, external installers, or archive extraction are used. Risk from install mechanism is low.

Credentials

The skill requests no environment variables, no credentials, and no config paths. The Node script uses only the filesystem under the package (creates a records/ directory) and standard Node APIs. Requested access is proportional to its function of generating local workflow documents.

Persistence & Privilege

The skill is not always-enabled, it's user-invocable, and allows normal autonomous invocation by the agent (the platform default). It only writes files under records/ inside the package tree; it does not modify other skills, system-wide configs, or persist credentials. No elevated persistence or cross-skill configuration changes are requested.

Assessment

This skill appears coherent and low-risk: it documents a multi-agent review workflow and ships a small Node script that only writes three markdown templates into a local records/ directory. Before installing, consider: 1) If you grant the agent broader execution rights (shell access, network access, or permission to call other services), review how you restrict those abilities — the SKILL itself does not require them but agent orchestration might. 2) Generated records are stored on disk under the package path; avoid putting sensitive secrets into the autogenerated files. 3) If you plan to run the included script, ensure Node.js >=14 is acceptable and run it in an environment where writing records/ is safe. Otherwise, no credentials, network calls, or suspicious behavior were found.

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

核心理念

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

三省职责

中书省 — 规划起草

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

核心职责：

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

输出格式：

## 诏令草案 [任务ID]

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

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

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

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

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

---

门下省 — 审核封驳

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

核心职责：

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

审核清单：

## 门下省审核表

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

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

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

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

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

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

---

尚书省 — 执行调度

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

核心职责：

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

执行报告格式：

## 执行报告 [任务ID]

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

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

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

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

---

六部专长

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

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

---

工作流程

标准流程

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

快速流程（简单任务）

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

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

简单任务判定标准：

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

---

使用示例

示例1：代码项目开发

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

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

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

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

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

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

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

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

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

---

历史典故参考

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

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

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

---

🚀 快速启动

一键生成工作流文档

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协作。让每项任务都经过规划、审核、执行的完整流程，确保质量与安全。