AI Agent 协作架构：基于三省六部官制的 Edict 开源框架

概述

三省六部·Edict 是一个基于中国古代官制设计的 AI 多 Agent 协作架构。它把唐朝以来运行了一千多年的三省六部制搬到了 AI 世界，创建了一套具有分权制衡、专职审核、完全可观测特性的 Agent 协作系统。

核心设计思想

问题：为什么大多数 Multi-Agent 框架不好用？

当前主流的多 Agent 框架（CrewAI、AutoGen、LangGraph）通常采用「自由对话」模式：

Agent A → "Hey, 你来处理这个"
Agent B → "好，我算一下"
Agent A → "结果是这样"

问题在于：

不可控：Agent 之间聊什么你不知道
不可复现：同样的输入，每次结果可能不同
无法审计：不知道中间经历了什么
难以干预：发现问题时已经晚了

解法：制度化协作

Edict 的思路是：不要让他们自由发挥，而是要设计一套制度。

三省六部制的核心是分权制衡：

皇上（用户） ↓ 下旨
太子（分拣） ↓ 传旨
中书省（规划） ↓ 提交审核
门下省（审议）← 可以封驳
尚书省（派发） ↓ 分配
六部（执行） ↓ 汇总
尚书省（回奏） ↓ 皇上（用户）

这条路线上，每一个环节都有明确的职责，不能越级沟通，必须经过审核。这就是制度。

架构详解

12 个 Agent 及其职责

部门	Agent ID	职责	说明
太子	taizi	消息分拣	判断是闲聊还是任务，闲聊直接回复，任务递交给中书省
中书省	zhongshu	规划中枢	接旨后拆解为子任务，分配方案
门下省	menxia	审议把关	审核中书省的方案，可以准奏或封驳（打回重做）
尚书省	shangshu	调度大脑	派发任务，协调六部，汇总结果
户部	hubu	数据资源	数据处理、报表、成本分析
礼部	libu	文档规范	技术文档、API 文档
兵部	bingbu	工程实现	代码开发、Bug 修复、代码审查
刑部	xingbu	安全合规	安全扫描、合规检查
工部	gongbu	基础设施	CI/CD、Docker、部署
吏部	libu_hr	人事管理	Agent 注册、权限维护
早朝官	zaochao	情报枢纽	每日新闻聚合、数据汇总

关键点：每个 Agent 有独立的 Workspace、独立的 Skills、可以独立配置 LLM 模型。

权限矩阵：严格的通信规则

不是谁想给谁发消息都可以。这张表定义了完整的权限：

From ↓ \ To → 太子 中书 门下 尚书 户 礼 兵 刑 工 吏
太子 — ✅
中书省 ✅ — ✅ ✅ ✅
门下省 ✅ ✅ ✅
尚书省 ✅ ✅ ✅ — ✅ ✅ ✅ ✅ ✅ ✅
六部 + 吏部 ✅

太子只能->中书、门下
中书->门下（必须审核）、尚书、户部
门下只能->尚书
尚书->所有六部 + 吏部
六部之间、六部->其他部门（除尚书）均不可直接通信

这种设计避免了混乱的消息流，确保所有任务都经过审核。

任务状态机

待处理 → 中书规划中 → 门下审议中 → 已派发 → 执行中 → 待审查 → 已完成
↑ ↓
└── 封驳（打回重做）
└── 阻塞 Blocked

9 种状态，每个状态转换都记录在案，形成完整的流转审计。

军机处看板：10 个功能面板

Edict 提供了一个名为「军机处」的 Web 看板（端口 7891），包含：

1. 旨意看板（Kanban）

任务按状态列展示，支持：

省部过滤
全文搜索
心跳徽章（🟢活跃/🟡停滞/🔴告警）
查看任务详情和完整流转链
叫停 / 取消 / 恢复操作

2. 省部调度（Monitor）

各状态任务数量可视化
部门分布条形图
Agent 健康状态实时卡片

3. 奏折阁（Memorials）

已完成任务自动归档
五阶段时间线（圣旨→中书→门下→六部→回奏）
一键复制为 Markdown

4. 旨库（Template Library）

9 个预设模板：

周报生成
代码审查
API 设计
竞品分析
数据报告
博客文章
部署方案
邮件文案
站会摘要

5. 官员总览（Officials）

Token 消耗排行榜
活跃度、完成数、会话统计

6. 天下要闻（News）

每日科技/财经资讯采集
分类订阅 + 飞书推送

7-10. 模型配置、技能配置、小任务监控、上朝仪式

技术实现

后端：纯 Python 标准库

dashboard/server.py 基于 http.server，零依赖，同时提供 API 和静态文件服务。约 1200 行代码。

前端：React 18 + TypeScript + Vite + Zustand

13 个功能组件，完整的状态管理。Docker 镜像包含预构建版本。

数据同步

scripts/run_loop.sh 每 15 秒自动同步 Agent 运行时数据到看板，显示倒计时。

Agent 配置

所有 Agent 的人格和工作流定义在 agents/<id>/SOUL.md，遵循 Agent 平台的 SOUL.md 规范。

权限和路由

通过 openclaw.json 配置 Agent 之间的通信权限矩阵。Edict 的 install.sh 会自动写入这些配置。

与主流框架对比

特性	CrewAI	MetaGPT	AutoGen	三省六部
审核机制	❌ 无	⚠️ 可选	⚠️ Human-in-loop	✅ 专职门下省 · 可封驳
实时看板	❌	❌	❌	✅ Kanban + 时间线
任务干预	❌	❌	❌	✅ 叫停/取消/恢复
流转审计	⚠️	⚠️	❌	✅ 完整奏折存档
Agent 健康监控	❌	❌	❌	✅ 心跳 + 活跃度
热切换模型	❌	❌	❌	✅ 看板内一键切换
技能管理	❌	❌	❌	✅ 查看/添加 Skills
部署难度	中	高	中	低（Docker 一键）

核心差异：制度化 vs 自由协作。Edict 强调可观测、可干预、可审计。

快速体验

Docker（最快）

docker run -p 7891:7891 cft0808/edict

访问 http://localhost:7891。Docker 镜像包含预填充的演示数据。

注意：Windows 用户需要 WSL2 后端或 Docker Desktop with WSL2。

完整安装（需要 Agent 平台）

前置条件
- Agent 平台已安装并运行
- Python 3.9+
- Node.js 18+（可选，用于构建前端）
- macOS 或 Linux（Windows 推荐 WSL2）
克隆并安装

git clone https://github.com/cft0808/edict.git
cd edict
chmod +x install.sh && ./install.sh

install.sh 会自动：

创建 12 个 Agent 的 Workspace
写入 SOUL.md（人格、工作流、数据清洗规则）
注册 Agent 和权限矩阵到 openclaw.json
构建 React 前端（如果有 Node.js）
初始化数据目录
重启 Agent Gateway

启动服务

# 终端 1：数据刷新
bash scripts/run_loop.sh
# 终端 2：看板服务器
python3 dashboard/server.py

访问 http://localhost:7891

使用流程

1. 向 AI 下旨

通过 Feishu/Telegram/Signal 给中书省发送任务，例如：

帮我设计一个用户注册系统，要求：
1. RESTful API（FastAPI）
2. PostgreSQL 数据库
3. JWT 鉴权
4. 完整测试用例
5. 部署文档

2. 坐好，看戏

过程自动流转：

中书省：接旨，规划子任务分配方案
门下省：审议方案，通过或封驳（打回）
尚书省：准奏，派发给兵部 + 工部 + 礼部等
六部：并行执行，进度实时更新
尚书省：汇总结果，回奏给你

全程在军机处看板可视，随时可以叫停或调整。

3. 使用圣旨模板

看板 → 旨库 → 选择模板 → 填写参数 → 下旨。

适合标准化任务（周报、代码审查、API 设计等）。

4. 自定义 Agent

编辑 agents/<agent_id>/SOUL.md 即可修改人格、职责、输出规范。

5. 添加 Skills

方式一：看板 UI 看板 → 技能配置 → 添加远程 Skill → 输入 Agent、Skill 名称、GitHub URL → 确认

方式二：CLI

python3 scripts/skill_manager.py add-remote \
--agent zhongshu \
--name code_review \
--source https://raw.githubusercontent.com/openclaw-ai/skills-hub/main/code_review/Skill.md \
--description"代码审查技能"

方式三：API

curl -X POST http://localhost:7891/api/add-remote-skill \
-H"Content-Type: application/json" \
-d'{"agentId":"zhongshu","skillName":"code_review","sourceUrl":"...","description":"..."}'

项目结构

edict/
├── agents/ # 12 个 Agent 的人格模板
├── dashboard/ # 看板前端 + 后端服务器
├── scripts/ # 各种工具脚本（数据同步、技能管理、新闻采集等）
├── data/ # 运行时数据（gitignored）
├── docs/ # 详细文档
├── tests/ # 端到端测试（17 个断言）
├── install.sh # 一键安装脚本
├── docker-compose.yml # Docker Compose 配置
└── README.md

文档资源

项目文档非常详细，建议阅读：

任务分发流转完整架构
- 详细讲解业务设计和技术实现
- 9 大状态机、权限矩阵、4 阶段调度、Session JSONL 数据融合
- 故障场景与恢复机制
远程 Skills 资源管理指南
- 如何从 GitHub 添加 Skills
- Skills 文件规范
- 版本管理
快速上手指南
ROADMAP.md
- Phase 1 已完成（核心架构）
- Phase 2 进行中（御批模式、功过簿、急递铺、国史馆）
- Phase 3 规划（Docker Compose、移动端、上架）

真实案例

examples/ 目录包含完整的使用记录：

竞品分析：分析 CrewAI vs AutoGen vs LangGraph
代码审查：审查 FastAPI 安全性
周报生成：工程团队周报

每个案例都包含：完整旨意 → 中书规划 → 门下审核 → 各部执行 → 最终奏折。

优缺点分析

✅ 优点

制度可靠：分权制衡 + 专职审核，输出质量可控
完全可观测：流转链完整记录，随时查看
实时干预：可以叫停、取消、恢复任务
架构清晰：Agent 职责明确，权限矩阵严格
部署简单：Docker 一键启动
生态完善：技能管理、新闻推送、模板库、看板一应俱全

⚠️ 注意点

依赖底层框架：必须安装并运行 Agent Gateway
平台限制：官方只支持 macOS/Linux，Windows 需 WSL2
学习成本：需要理解三省六部的概念和权限规则
灵活性较低：严格的通信限制可能不适合需要自由对话的场景
中文项目：文档和界面主要是中文，国际化有限

适用场景

Edict 适合：

需要高质量、可审计输出的任务：技术方案设计、代码审查、安全评估
企业环境：需要制度化管理、权限控制、流程追踪
长期运行：作为团队工作流的一部分持续使用
模型切换频繁：不同部门用不同 LLM（看板内一键切换）

不适合：

创意型任务：需要 Agent 自由讨论、头脑风暴的场景
快速原型：设置权限矩阵可能太重
单次性任务：杀鸡用牛刀

结语

三省六部制在中国运行了 1400 年，从隋唐到清末，历经无数王朝更迭，证明了一套好的制度设计比自由发挥更稳定。

Edict 把这个思想移植到了 AI Agent 世界。它的价值不在于技术有多新颖，而在于用制度解决问题。

如果你受够了 Agent「聊完就忘、结果不可控」的状态，想体验一下有审核、有流程、可干预的多 Agent 协作，可以试试 Edict。