最近在体验各类 Multi-Agent 框架时，我发现了一个共同的痛点：大多数系统让几个 AI 自己聊完就完事，你拿到的是一个黑盒结果——无法复现、无法审计、无法中途干预。直到接触到这个项目，我才意识到这个问题的解法竟然来自 1400 年前的唐朝制度设计。
项目核心定位
Edict 是一个基于 OpenClaw 的多 Agent 协作系统，采用唐朝三省六部制度作为架构模型。与其他 Multi-Agent 框架不同，它的核心不在于让 Agent 自由对话，而在于通过制度化的权力制衡机制，确保任务流转的可控性和可审计性。
项目地址：https://github.com/cft0808/edict
技术栈：Python + React | License：MIT | 作者：cft0808
架构设计：12 个 Agent 的分工体系
系统将任务流转设计为一条完整的行政链路：
皇上（用户）→ 太子（分拣）→ 中书省（规划）→ 门下省（审议）→ 尚书省（派发）→ 六部（执行）→ 回奏
| Agent | 职责定义 |
| 太子（taizi） | 消息分拣、闲聊回复、将用户指令转化为正式旨意 |
| 中书省（zhongshu） | 接收旨意、制定执行方案、拆解为子任务 |
| 门下省（menxia） | 审议方案质量、可以封驳返工、把关制度执行 |
| 尚书省（shangshu） | 任务派发、六部协调、汇总回奏结果 |
| 户部（hubu） | 数据处理、报表生成、成本分析 |
| 礼部（libu） | 文档撰写、规范制定、内容组织 |
| 兵部（bingbu） | 代码开发、Bug 修复、技术方案实现 |
| 刑部（xingbu） | 安全审计、合规检查、风险评估 |
| 工部（gongbu） | CI/CD 流程、部署、工具链管理 |
| 吏部（libu_hr） | Agent 管理、权限维护、系统配置 |
| 早朝官（zaochao） | 每日播报、新闻聚合、信息同步 |
核心差异化设计
与 CrewAI、AutoGen 等框架的对比维度：
| 特性维度 | CrewAI | AutoGen | Edict（三省六部） |
| 审核机制 | ❌ 无 | ⚠️ 可选 | ✅ 门下省专职审核 |
| 实时看板 | ❌ | ❌ | ✅ 军机处 Kanban |
| 任务干预 | ❌ | ❌ | ✅ 叫停/取消/恢复 |
| 完整审计 | ⚠️ | ⚠️ | ✅ 奏折存档 |
| Agent 监控 | ❌ | ❌ | ✅ 心跳+活跃度 |
| 模型热切换 | ❌ | ❌ | ✅ 看板内切换 |
| 技能管理 | ❌ | ❌ | ✅ 查看/添加 |
| 部署难度 | 中 | 中 | 低 |
1. 门下省审核机制（最大差异点）
这是三省六部对标其他框架的杀手锏。其他系统的 Agent 协作模式是"完成即交付"——没有质量把关环节。Edict 的门下省专门干这件事：
- 审查方案质量：中书省的规划是否完备？子任务拆解是否合理？
- 封驳不合格产出：不是警告，而是直接打回重做
- 强制返工循环：直到方案达标才放行执行
这不是可选的插件，而是架构的内核。每个旨意都必须经过门下省的审议。
2. 实时看板（军机处）— 10 个功能面板
- 旨意看板 Kanban — 按状态列展示任务，支持省部过滤和搜索
- 省部调度 Monitor — 可视化任务分布，Agent 健康状态一览
- 奏折阁 Memorials — 已完成任务归档，完整时间线回溯
- 旨库 Templates — 9 个预设模板，快速参数化下旨
- 官员总览 Officials — Token 消耗排行，活跃度统计
- 天下要闻 News — 自动采集科技/财经资讯
- 模型配置 Models — 每个 Agent 独立切换 LLM
- 技能配置 Skills — 查看和添加技能库
- 小任务 Sessions — 会话实时监控和调试
- 上朝仪式 Ceremony — 每日首次打开的动画演示
3. 任务状态流转与权限矩阵
9 个任务状态：
新圣旨 → 太子分拣中 → 中书省规划中 → 门下省审议中 → （封驳返回）→ 尚书省派发中 → 六部执行中 → 待回奏审查 → 已完成（奏折）
权限矩阵（From → To）：
| 太子 | 中书 | 门下 | 尚书 | 六部 | |
| 太子 | — | ✅ | |||
| 中书省 | ✅ | — | ✅ | ✅ | |
| 门下省 | ✅ | — | ✅ | ||
| 尚书省 | ✅ | ✅ | — | ✅ | |
| 六部 | ✅ | — |
安装与部署
前置条件
- OpenClaw 已安装
- Python 3.9+
- macOS / Linux 环境
- Node.js 18+（前端构建，可选）
一键安装
git clone https://github.com/cft0808/edict.git
cd edict
chmod +x install.sh && ./install.sh安装脚本自动完成：
- 创建全量 Agent Workspace
- 写入各省部 SOUL.md 人格定义
- 注册 Agent 及权限矩阵
- 构建前端（可选）
- 初始化数据目录
- 重启 OpenClaw Gateway
Docker 快速体验
没有 OpenClaw 环境？一行命令体验完整 Demo：
docker run -p 7891:7891 cft0808/edict然后打开 http://localhost:7891 即可看到完整看板。
x86/amd64 机器需要指定平台：
docker run --platform linux/amd64 -p 7891:7891 cft0808/edict本地启动三个进程
# 终端 1：数据刷新循环
bash scripts/run_loop.sh
# 终端 2：看板服务器
python3 dashboard/server.py
# 打开浏览器
open http://127.0.0.1:7891核心使用场景
场景 1：竞品分析
旨意示例：分析 CrewAI vs AutoGen vs LangGraph 的优缺点
流转路径：中书省规划 → 门下省审核 → 户部+兵部+礼部并行执行 → 回奏汇总
输出物：
- 功能对比表
- 性能测试数据
- 选型建议和风险评估
场景 2：代码审查
旨意示例：审查这段 FastAPI 代码的安全性和性能瓶颈
流转路径：中书省规划 → 门下省审核 → 兵部+刑部执行 → 回奏
输出物：
- 安全漏洞列表（CVSS 评级）
- 修复建议
- 性能优化方案
场景 3：API 设计
旨意示例：设计用户管理 API，包含 CRUD + 权限控制
流转路径：中书省规划 → 门下省审核 → 兵部+礼部执行 → 回奏
输出物：
- OpenAPI 3.0 规格文档
- 数据模型设计（ER 图）
- 示例请求/响应
场景 4：周报生成
旨意示例：生成本周工程团队周报
流转路径：中书省规划 → 门下省审核 → 户部+礼部执行 → 回奏
输出物：
- 本周完成事项
- 遇到的问题和解决方案
- 下周计划和资源需求
高级配置
修改 Agent 人格
编辑 agents//SOUL.md 来自定义 Agent 的思考方式和行为准则：
# 中书省 SOUL.md
你是中书省，负责接旨、规划、拆解任务。
## 职责
- 理解用户需求，深度分析
- 制定完整解决方案
- 拆解为可执行子任务
## 输出规范
- 必须包含任务列表
- 每个任务指定执行部门
- 预估完成时间添加远程技能（三种方式）
方式一：看板 UI
看板 → 技能配置 → 添加远程 Skill → 输入信息
方式二：命令行
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": "https://raw.githubusercontent.com/.../SKILL.md",
"description": "代码审查"
}'官方预设技能库：
python3 scripts/skill_manager.py import-official-hub \
--agents zhongshu,menxia,shangshu,bingbu,xingbu包含：code_review、api_design、security_audit、data_analysis、doc_generation、test_framework
模型热切换
看板 → 模型配置 → 选择 Agent → 切换 LLM → 应用（5 秒内生效）
适用场景：为不同部门配置差异化模型
- 中书省/门下省：使用强模型（GPT-4/Claude）
- 兵部：使用强模型（代码生成）
- 礼部：使用经济模型（文档生成）
- 户部：使用专用模型（数据分析）
自定义模板
在 data/templates/ 添加 JSON 模板：
{
"name": "技术方案",
"description": "生成技术方案文档",
"params": ["项目名称", "技术栈", "预期目标"],
"estimatedTime": "30min",
"estimatedCost": "5000 tokens"
}技术架构详解
目录结构
edict/
├── agents/ # 12 个 Agent 的人格模板
│ ├── taizi/SOUL.md
│ ├── zhongshu/SOUL.md
│ └── ...
├── dashboard/
│ ├── dashboard.html # 单文件看板（~2500 行）
│ ├── dist/ # React 前端
│ └── server.py # API 服务器（~1200 行）
├── scripts/
│ ├── run_loop.sh # 数据刷新循环
│ ├── kanban_update.py
│ ├── skill_manager.py
│ └── ...
├── tests/
│ └── test_e2e_kanban.py # 端到端测试
├── data/ # 运行时数据
└── docs/ # 文档资源技术栈与性能指标
| 层级 | 技术选型 |
| 前端 | React 18 + TypeScript + Vite + Zustand |
| 后端 | Python 标准库（零外部依赖） |
| 运行时 | OpenClaw Gateway |
| 数据存储 | JSON 文件 + JSONL 会话日志 |
任务流转性能指标
| 环节 | 响应时间 |
| 旨意分拣（太子） | 3-5 秒 |
| 中书省规划 | 10-30 秒 |
| 门下省审核 | 5-15 秒 |
| 任务派发（尚书省） | 2-5 秒 |
| 六部执行 | 取决于任务复杂度 |
Token 成本估算
| 任务类型 | 预估 Token |
| 简单问答 | 500-1000 |
| 代码审查 | 2000-5000 |
| 方案设计 | 3000-8000 |
| 复杂分析 | 5000-15000 |
成本优化建议
- 让门下省严格把关，避免返工导致的成本倍增
- 合理拆分子任务，充分利用各部并行执行能力
- 为不同部门配置差异化模型（强弱搭配）
- 使用预设模板减少中书省规划的 token 消耗
故障排查
任务超时或无法回奏
症状：六部完成任务，但太子收不到回报
排查步骤：
# 检查 Agent 状态
curl -s http://127.0.0.1:7891/api/agents-status | python3 -m json.tool
# 检查 OpenClaw Gateway 日志
grep -i "error\|fail" /tmp/openclaw/openclaw-*.log | tail -20
# 手动触发巡检
curl -X POST http://127.0.0.1:7891/api/scheduler-scan \
-H 'Content-Type: application/json' \
-d '{"thresholdSec":60}'Docker 架构不匹配
错误信息：exec format error
解决方案：
docker run --platform linux/amd64 -p 7891:7891 cft0808/edict技能下载失败
原因：网络问题（中国大陆访问 GitHub）
解决方案：
export https_proxy=http://your-proxy:port
python3 scripts/skill_manager.py import-official-hub --agents zhongshu看板数据不更新
排查步骤：
# 检查 run_loop 是否运行
ps aux | grep run_loop
# 检查数据文件权限
ls -la data/
# 手动刷新数据
python3 scripts/kanban_update.py常见问题
Q: 与 CrewAI 的核心区别是什么？
A: CrewAI 让 Agent 自由协作，三省六部引入了制度化的审核权。门下省可以封驳不合格方案，强制返工，这是其他框架所没有的。
Q: 需要自己开发 12 个 Agent 吗？
A: 不需要。12 个 Agent 已完整预设，开箱即用。你可以通过编辑 SOUL.md 调整人格，但架构无需改动。
Q: 支持哪些消息渠道？
A: 飞书、Telegram、Signal、Discord、WhatsApp 等 OpenClaw 支持的渠道都可以。
Q: 能处理多复杂的任务？
A: 复杂度取决于模型能力。系统会自动拆解为子任务，各部并行执行。门下省审核环节确保质量。
Q: 如何调试 Agent 的思考过程？
A: 看板的"官员总览"和"小任务"面板可以看到 Agent 的完整思考链、工具调用和返回结果。
Q: 数据存在哪里？能导出吗？
A: JSON 文件存在 data/ 目录，会话日志是 JSONL 格式。完全可导出和迁移。
Q: 可以自定义新的部门吗？
A: 可以。添加新的 Agent 目录和 SOUL.md，然后更新权限矩阵即可。
与其他项目的对比推荐
如果你在不同场景下有其他需求，可参考：
- CrewAI：适合简单的 Agent 编排，快速上手，但缺乏审计和干预能力
- AutoGen：适合对话驱动的多 Agent 系统，易于扩展，但同样缺乏质量把关
- LangGraph：更底层的工作流框架，灵活性高，但需要自己实现审核逻辑
- Edict（三省六部）：适合需要完整可审计、可干预的生产级多 Agent 系统
总结与反思
在评测这个项目的过程中，我意识到一个深刻的设计哲学：最好的系统架构往往不来自最新的技术，而是来自历史中的成熟制度。
唐朝的三省六部制存在了 1400 年，核心原因是它解决了一个永恒问题：如何在复杂的协作系统中确保权力受制约、流程可追溯、质量有保障。
Edict 将这套思想应用到 AI Agent 协作，核心贡献有四：
- 制度性审核 — 门下省不是装饰，而是架构的一部分
- 完全可观测 — 10 个看板面板，每个环节都能看到
- 实时可干预 — 随时叫停、取消、恢复，不是黑盒
- 完整审计 — 所有流转记录在奏折里，支持回溯和合规检查
这对需要在生产环境中部署多 Agent 系统的团队特别有价值——尤其是当任务涉及关键决策、成本控制或合规要求时。
如果你正在评估 Multi-Agent 框架，我建议把 Edict 加入候选名单。它不一定是"最强的"，但它解决了其他框架忽视的问题。