用三省六部做 AI Agent 协作：Edict 架构拆解

通信权限不是随便开的

Edict 里，Agent 之间不是想发消息就能发。权限矩阵把路由限制得很死：

对应关系基本就是：

• 太子只转发到中书、门下
• 中书可以送审到门下，也可以交给尚书和户部
• 门下只回到尚书
• 尚书可以调度所有六部和吏部
• 六部之间、以及六部直连其他部门，默认都不允许

这套限制看起来麻烦，但它把消息流压平了，审计也就顺手了。对需要长期运行的系统来说，这比'大家都能聊'更实在。

任务状态机

待处理 → 中书规划中 → 门下审议中 → 已派发 → 执行中 → 待审查 → 已完成
↑ ↓
└── 封驳（打回重做）
└── 阻塞 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 会自动写入这些配置。

和主流框架比起来

差异其实很简单：别家更偏向自由协作，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. 部署文档

然后看任务流转

流程会自动走下去：

1. 中书省 接旨，拆解任务并给出分配方案
2. 门下省 审议方案，通过或封驳
3. 尚书省 准奏，派发给兵部、工部、礼部等部门
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

文档资源

项目文档写得比较细，下面几篇值得先看：

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

真实案例

examples/ 目录里有几组完整记录：

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

每个案例都能看到完整链路：旨意、中书规划、门下审核、各部执行、最后回奏。

优缺点

优点

• 分权制衡明确，输出更可控
• 流转链完整，便于审计
• 支持实时干预
• Agent 职责和权限边界清楚
• Docker 一键启动，部署成本低
• 还有模板库、技能管理、新闻推送、看板这些配套能力

注意点

• 依赖 OpenClaw，必须先把 Gateway 跑起来
• 官方主要支持 macOS 和 Linux，Windows 要靠 WSL2
• 需要理解三省六部和权限规则，上手门槛不是没有
• 通信限制比较严格，不适合那种需要自由讨论的场景
• 项目文档和界面以中文为主，国际化还有限

适用场景

适合：

• 需要高质量、可审计输出的任务，比如技术方案、代码审查、安全评估
• 企业环境里需要流程化管理、权限控制、任务追踪的场景
• 要长期运行，作为团队工作流的一部分持续使用
• 不同部门需要切换不同 LLM 的情况

不太适合：

• 创意型任务，尤其是需要 Agent 自由讨论的时候
• 想快速试个原型，但又不想先配权限矩阵的场景
• 一次性的小任务，流程开得有点重

结语

三省六部在中国古代能长期运转，靠的不是'大家一起自由发挥'，而是一套稳定的制度。Edict 做的事情很直接：把这种制度感搬到 AI Agent 协作里。

它的价值不在于新奇，而在于把协作这件事变得更可控。对于那些受够了 Agent 聊完就散、结果不好追、出了问题没法插手的场景，这套设计确实更顺手。