概述
三省六部·Edict 是一套按中国古代官制来组织的 AI 多 Agent 协作架构。它把'自由聊天式'的 Agent 协作，改成了有分工、有审核、有回路的流程，重点不是让 Agent 更会聊，而是让它们更可控、可查、可干预。
核心设计
为什么很多 Multi-Agent 框架不好用
像 CrewAI、AutoGen、LangGraph 这类框架，常见做法还是让 Agent 自由对话：
Agent A → "Hey, 你来处理这个"
Agent B → "好，我算一下"
Agent A → "结果是这样"
问题不在于它们不能工作，而在于工作过程太散：
- 你很难提前知道它们会聊到哪一步
- 同样的输入，输出可能不一样
- 中间发生了什么，很难完整追踪
- 发现方向跑偏时，往往已经晚了
Edict 的做法：先定制度，再谈协作
Edict 走的是另一条路：不要让 Agent 自由发挥，而是给它们一套固定流程。
三省六部的思路本来就是分权制衡，放到 AI 系统里也差不多：
皇上（用户） ↓ 下旨
太子（分拣） ↓ 传旨
中书省（规划） ↓ 提交审核
门下省（审议）← 可以封驳
尚书省（派发） ↓ 分配
六部（执行） ↓ 汇总
尚书省（回奏） ↓ 皇上（用户）
路径是收敛的，职责是固定的。谁负责规划，谁负责审核，谁负责执行，都写死了。这样做不够'自由'，但线上用起来省心，尤其是在需要留痕和回滚的时候。
架构细节
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。这个设计的好处很直接：职责边界清楚，出问题时更容易定位，不会把所有东西都塞进一个大而全的提示词里。
通信权限不是随便开的
Edict 里，Agent 之间不是想发消息就能发。权限矩阵把路由限制得很死：
| From \ To | 太子 | 中书 | 门下 | 尚书 | 户 | 礼 | 兵 | 刑 | 工 | 吏 |
|---|---|---|---|---|---|---|---|---|---|---|
| 太子 | — | ✅ | ||||||||
| 中书省 | ✅ | — | ✅ | ✅ | ✅ | |||||
| 门下省 | ✅ | ✅ | — | |||||||
| 尚书省 | ✅ | ✅ | ✅ | — | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 六部 + 吏部 | ✅ |
对应关系基本就是：
- 太子只转发到中书、门下
- 中书可以送审到门下，也可以交给尚书和户部
- 门下只回到尚书
- 尚书可以调度所有六部和吏部
- 六部之间、以及六部直连其他部门，默认都不允许
这套限制看起来麻烦，但它把消息流压平了，审计也就顺手了。对需要长期运行的系统来说，这比'大家都能聊'更实在。
任务状态机
待处理 → 中书规划中 → 门下审议中 → 已派发 → 执行中 → 待审查 → 已完成
↑ ↓
└── 封驳（打回重做）
└── 阻塞 Blocked
一共 9 种状态，所有转换都会记录下来。实际排障时，这种状态链比'任务应该差不多跑完了'靠谱得多。
军机处看板
Edict 提供了一个叫'军机处'的 Web 看板，默认端口是 7891。它不是装饰品，主要作用是把整个流转过程摊在桌面上看。
旨意看板（Kanban）
任务会按状态展示，支持：
- 省部过滤
- 全文搜索
- 心跳徽章（🟢活跃 / 🟡停滞 / 🔴告警）
- 查看任务详情和完整流转链
- 叫停 / 取消 / 恢复
省部调度（Monitor）
这里能看到：
- 各状态任务数量
- 部门分布条形图
- Agent 健康状态卡片
奏折阁（Memorials）
- 已完成任务自动归档
- 五阶段时间线：圣旨 → 中书 → 门下 → 六部 → 回奏
- 一键复制为 Markdown
旨库（Template Library）
预设了 9 个模板，包括周报生成、代码审查、API 设计、竞品分析、数据报告、博客文章、部署方案、邮件文案、站会摘要。
官员总览（Officials）
这里看的是：
- Token 消耗排行榜
- 活跃度
- 完成数
- 会话统计
天下要闻（News）
- 每日科技/财经资讯采集
- 分类订阅
- 飞书推送
其他配置
还包括模型配置、技能配置、小任务监控、上朝仪式等。
技术实现
后端
dashboard/server.py 基于 http.server，走的是纯 Python 标准库，零依赖，同时提供 API 和静态文件服务。代码量大约 1200 行。
前端
前端使用 React 18 + TypeScript + Vite + Zustand，包含 13 个功能组件。Docker 镜像里已经带了预构建版本，起步会轻一些。
数据同步
scripts/run_loop.sh 会每 15 秒同步一次 OpenClaw 运行时数据到看板，并显示倒计时。
Agent 配置
每个 Agent 的人格和工作流定义在 agents/<id>/SOUL.md，遵循 OpenClaw 的 SOUL.md 规范。
权限和路由
openclaw.json 负责配置 Agent 之间的通信权限矩阵。Edict 的 install.sh 会自动写入这些配置。
和主流框架比起来
| 特性 | CrewAI | MetaGPT | AutoGen | 三省六部 |
|---|---|---|---|---|
| 审核机制 | ❌ 无 | ⚠️ 可选 | ⚠️ Human-in-loop | ✅ 专职门下省 · 可封驳 |
| 实时看板 | ❌ | ❌ | ❌ | ✅ Kanban + 时间线 |
| 任务干预 | ❌ | ❌ | ❌ | ✅ 叫停/取消/恢复 |
| 流转审计 | ⚠️ | ⚠️ | ❌ | ✅ 完整奏折存档 |
| Agent 健康监控 | ❌ | ❌ | ❌ | ✅ 心跳 + 活跃度 |
| 热切换模型 | ❌ | ❌ | ❌ | ✅ 看板内一键切换 |
| 技能管理 | ❌ | ❌ | ❌ | ✅ 查看/添加 Skills |
| 部署难度 | 中 | 高 | 中 | 低（Docker 一键） |
差异其实很简单：别家更偏向自由协作，Edict 更像流程系统。它强调的是可观测、可干预、可审计。
快速体验
Docker 启动
docker run -p 7891:7891 cft0808/edict
打开 http://localhost:7891 就能看到看板。Docker 镜像里已经放了演示数据。
Windows 用户需要 WSL2 后端，或者直接用 Docker Desktop with WSL2。
完整安装
前置条件
- OpenClaw 已安装并运行
- 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）
- 初始化数据目录
- 重启 OpenClaw Gateway
启动服务
# 终端 1：数据刷新
bash scripts/run_loop.sh
# 终端 2：看板服务器
python3 dashboard/server.py
访问
http://localhost:7891
使用方式
先向 AI 下旨
可以通过 Feishu、Telegram 或 Signal 给 中书省 发送任务，例如：
帮我设计一个用户注册系统，要求：
1. RESTful API（FastAPI）
2. PostgreSQL 数据库
3. JWT 鉴权
4. 完整测试用例
5. 部署文档
然后看任务流转
流程会自动走下去：
- 中书省 接旨，拆解任务并给出分配方案
- 门下省 审议方案，通过或封驳
- 尚书省 准奏，派发给兵部、工部、礼部等部门
- 六部 并行执行，进度实时更新
- 尚书省 汇总结果，回奏给你
整个过程都能在军机处看板里看到，想叫停或者调整，也不用等它跑完。
用圣旨模板
看板 → 旨库 → 选择模板 → 填写参数 → 下旨。
这套更适合周报、代码审查、API 设计这类重复性任务。
自定义 Agent
编辑 agents/<agent_id>/SOUL.md 就能改人格、职责和输出规范。
添加 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":"..."}'
官方 Skills Hub：https://github.com/openclaw-ai/skills-hub
项目结构
edict/
├── agents/ # 12 个 Agent 的人格模板
├── dashboard/ # 看板前端 + 后端服务器
├── scripts/ # 各种工具脚本（数据同步、技能管理、新闻采集等）
├── data/ # 运行时数据（gitignored）
├── docs/ # 详细文档
├── tests/ # 端到端测试（17 个断言）
├── install.sh # 一键安装脚本
├── docker-compose.yml # Docker Compose 配置
└── README.md
文档资源
项目文档写得比较细，下面几篇值得先看：
- 任务分发流转完整架构
- 9500+ 字
- 业务设计和技术实现都讲得比较完整
- 9 大状态机、权限矩阵、4 阶段调度、Session JSONL 数据融合
- 还有故障场景和恢复机制
- 远程 Skills 资源管理指南
- 如何从 GitHub 添加 Skills
- Skills 文件规范
- 版本管理
- 快速上手指南
- ROADMAP.md
- Phase 1 已完成（核心架构）
- Phase 2 进行中（御批模式、功过簿、急递铺、国史馆）
- Phase 3 规划（Docker Compose、移动端、ClawHub 上架）
真实案例
examples/ 目录里有几组完整记录：
每个案例都能看到完整链路：旨意、中书规划、门下审核、各部执行、最后回奏。
优缺点
优点
- 分权制衡明确，输出更可控
- 流转链完整，便于审计
- 支持实时干预
- Agent 职责和权限边界清楚
- Docker 一键启动，部署成本低
- 还有模板库、技能管理、新闻推送、看板这些配套能力
注意点
- 依赖 OpenClaw，必须先把 Gateway 跑起来
- 官方主要支持 macOS 和 Linux，Windows 要靠 WSL2
- 需要理解三省六部和权限规则，上手门槛不是没有
- 通信限制比较严格，不适合那种需要自由讨论的场景
- 项目文档和界面以中文为主，国际化还有限
适用场景
适合：
- 需要高质量、可审计输出的任务，比如技术方案、代码审查、安全评估
- 企业环境里需要流程化管理、权限控制、任务追踪的场景
- 要长期运行，作为团队工作流的一部分持续使用
- 不同部门需要切换不同 LLM 的情况
不太适合：
- 创意型任务，尤其是需要 Agent 自由讨论的时候
- 想快速试个原型，但又不想先配权限矩阵的场景
- 一次性的小任务，流程开得有点重
结语
三省六部在中国古代能长期运转，靠的不是'大家一起自由发挥'，而是一套稳定的制度。Edict 做的事情很直接：把这种制度感搬到 AI Agent 协作里。
它的价值不在于新奇，而在于把协作这件事变得更可控。对于那些受够了 Agent 聊完就散、结果不好追、出了问题没法插手的场景，这套设计确实更顺手。
