⚔️ 三省六部 · Edict

我用 1300 年前的帝国制度，重新设计了 AI 多 Agent 协作架构。
结果发现，古人比现代 AI 框架更懂分权制衡。

_{12 个 AI Agent（11 个业务角色 + 1 个兼容角色）组成三省六部：太子分拣、中书省规划、门下省审核封驳、尚书省派发、六部+吏部并行执行。
比 CrewAI 多一层制度性审核，比 AutoGen 多一个实时看板。}

🎬 看 Demo · 🚀 30 秒体验 · 🏛️ 架构 · 📋 看板功能 · 📚 架构文档 · English · 日本語 · 参与贡献

---

🎬 Demo

您的浏览器不支持视频播放，请查看下方 GIF 或 下载视频。
_{🎥 三省六部 AI 多 Agent 协作全流程演示}

📸 GIF 预览（加载更快）

_{飞书下旨 → 太子分拣 → 中书省规划 → 门下省审议 → 六部并行执行 → 奏折回报（30 秒）}

🐳 没有 OpenClaw？ 跑一行 docker run -p 7891:7891 cft0808/edict 即可体验完整看板 Demo（预置模拟数据）。

---

🤔 为什么是三省六部？

大多数 Multi-Agent 框架的套路是：

"来，你们几个 AI 自己聊，聊完把结果给我。"

然后你拿到一坨不知道经过了什么处理的结果，无法复现，无法审计，无法干预。

三省六部的思路完全不同 —— 我们用了一个在中国存在 1400 年的制度架构：

你 (皇上) → 太子 (分拣) → 中书省 (规划) → 门下省 (审议) → 尚书省 (派发) → 六部 (执行) → 回奏

这不是花哨的 metaphor，这是真正的分权制衡：

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

核心差异：制度性审核 + 完全可观测 + 实时可干预

🔍 为什么「门下省审核」是杀手锏？（点击展开）

CrewAI 和 AutoGen 的 Agent 协作模式是 "做完就交"——没有人检查产出质量。就像一个公司没有 QA 部门，工程师写完代码直接上线。

三省六部的 门下省 专门干这件事：

• 📋 审查方案质量 —— 中书省的规划是否完备？子任务拆解是否合理？
• 🚫 封驳不合格的产出 —— 不是 warning，是直接打回重做
• 🔄 强制返工循环 —— 直到方案达标才放行

这不是可选的插件——它是架构的一部分。每一个旨意都必须经过门下省，没有例外。

这就是为什么三省六部能处理复杂任务而结果可靠：因为在送到执行层之前，有一个强制的质量关卡。1300 年前唐太宗就想明白了——不受制约的权力必然会出错。

---

✨ 功能全景

🏛️ 十二部制 Agent 架构

• 太子 消息分拣 —— 闲聊自动回复，旨意才建任务
• 三省（中书·门下·尚书）负责规划、审议、派发
• 七部（户·礼·兵·刑·工·吏 + 早朝官）负责专项执行
• 严格的权限矩阵 —— 谁能给谁发消息，白纸黑字
• 状态流转校验 —— kanban_update.py 强制合法转换路径，非法状态跳转被拒绝
• 每个 Agent 独立 Workspace · 独立 Skills · 独立模型
• 旨意数据清洗 —— 标题/备注自动剥离文件路径、元数据、无效前缀

📋 军机处看板（10 个功能面板）

📋 旨意看板 · Kanban 按状态列展示全部任务 省部过滤 + 全文搜索 心跳徽章（🟢活跃 🟡停滞 🔴告警） 任务详情 + 完整流转链 叫停 / 取消 / 恢复操作	🔭 省部调度 · Monitor 可视化各状态任务数量 部门分布横向条形图 Agent 健康状态实时卡片
**