三省六部制 Edict：用唐代官僚制度约束 AI 多 Agent 协作
三省六部制 · OpenClaw 多代理编排系统，9 个专门的 AI 代理，具有实时仪表板、模型配置和完整的审计跟踪。
秒懂
- 它是什么？
- Edict 是一个基于 OpenClaw 的多 Agent 编排系统，用唐代三省六部的分权制衡来约束 AI 协作流程。它提供专职审核、实时看板和完整审计轨迹，但依赖 OpenClaw 生态，且部署步骤中有不少手工环节。
- 适合谁用？
- Edict 适合已经使用 OpenClaw、且对多 Agent 协作的可审计性和可干预性有硬性要求的团队，尤其是需要向客户或监管展示任务流转过程的场景。它不适合没有 OpenClaw 基础、或者只想要一个轻量编排库的开发者，因为整个系统深度绑定 OpenClaw 的 agent 管理、消息可见性和 Gateway 机制。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 9 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
用唐代制度解决现代 AI 协作的黑盒问题
大多数多 Agent 框架的做法是让几个 AI 互相聊天，聊完把结果丢给你。你拿到一坨输出，不知道中间经历了什么，无法复现，无法审计，也无法干预。Edict 的作者用唐代三省六部的制度架构来重新设计这套流程。核心链条是：皇上（你）下旨，太子分拣，中书省规划，门下省审议，尚书省派发，六部执行，最后回奏。这不是装饰性的比喻，而是真正的分权制衡。门下省专职审核，可以封驳不合格的方案，直接打回重做。这个审核环节是架构的一部分，不是可选插件，每一道旨意都必须经过门下省。对需要可靠输出的团队来说，这比让 Agent 自由发挥要可控得多。
十二个 Agent 的职责与权限矩阵
Edict 定义了 12 个 Agent，其中 11 个业务角色加 1 个兼容角色。太子负责消息分拣，闲聊自动回复，只有真正的旨意才建任务。中书省负责规划，门下省负责审议封驳，尚书省负责派发协调。执行层是七部：户部处理数据，礼部写文档，兵部写代码，刑部做安全合规，工部做工程，吏部管人事，早朝官做兼容。每个 Agent 有独立的 Workspace、独立的 Skills 和独立的模型配置。权限矩阵白纸黑字规定谁能给谁发消息，状态流转校验由 kanban_update.py 强制合法转换路径，非法状态跳转会被拒绝。这种严格的角色划分和权限控制，在多 Agent 系统里并不常见，多数框架只是让 Agent 自由调用工具。
军机处看板：实时监控与干预
Edict 提供了一个叫军机处的实时看板，包含 10 个功能面板。旨意看板是 Kanban，按状态列展示全部任务，支持省部过滤和全文搜索，每个任务有心跳徽章，绿色活跃，黄色停滞，红色告警。你可以直接叫停、取消或恢复任务，这是其他框架少有的干预能力。省部调度面板可视化各状态任务数量和部门分布，Agent 健康状态实时卡片。奏折阁自动归档已完成的任务，显示五阶段时间线，从圣旨到回奏，一键复制为 Markdown。官员总览展示 Token 消耗排行榜、活跃度和完成数。模型配置面板允许每个 Agent 独立切换 LLM，应用后自动重启 Gateway，大约 5 秒生效。这些功能合在一起，让整个任务流转过程完全可观测，不再是黑盒。
快速体验：Docker 与完整安装
最快的体验方式是 Docker：docker run -p 7891:7891 cft0808/sansheng-demo，打开 http://localhost:7891 即可看到预置模拟数据的看板。但要注意，如果你在 x86/amd64 机器上遇到 exec format error，是因为镜像架构不匹配，需要加 --platform linux/amd64 参数，或者用 docker-compose，它已内置 platform 配置。完整安装需要先装 OpenClaw，Python 3.10+，macOS 或 Linux。然后 git clone，运行 install.sh。这个脚本会创建全量 Agent Workspace，写入各省部的 SOUL.md，注册 Agent 和权限矩阵到 openclaw.json，用符号链接统一数据目录，设置 Agent 间通信可见性为 sessions.visibility all，同步 API Key 到所有 Agent，构建 React 前端，初始化数据目录，最后重启 Gateway。首次安装需要先配置 API Key：openclaw agents add taizi，然后重新运行 install.sh。启动方式有两种，推荐用 start.sh 一键启动，或者分别运行 scripts/run_loop.sh 和 python3 dashboard/server.py。生产环境可以用 edict.service 或 edict.sh 管理脚本。
制度性审核的代价：依赖 OpenClaw 生态
Edict 的审核机制是亮点，但也带来一个明显约束：它完全依赖 OpenClaw。没有 OpenClaw 就无法运行，所有 Agent 的注册、消息可见性、Gateway 重启都基于 OpenClaw 的机制。这意味着如果你想用 Edict，必须先接受 OpenClaw 作为基础平台。另一个问题是安装步骤中有不少手工环节，比如首次安装需要先手动添加 taizi Agent 并配置 API Key，然后重新运行 install.sh。install.sh 会尝试自动同步 API Key，但前提是你已经配置好一个 Agent。Docker 镜像的架构问题也需要留意，非 amd64 机器上可能无法直接运行。这些都不是致命缺陷，但说明 Edict 不是开箱即用的产品，更像是一个需要按手册配置的系统。
与 CrewAI 和 AutoGen 的差异
README 中直接对比了 CrewAI、MetaGPT 和 AutoGen。CrewAI 没有审核机制，Agent 做完就交，没有质量检查。AutoGen 只有可选的 Human-in-loop，不是强制审核。Edict 的审核是制度性的，门下省专职负责，可以封驳。AutoGen 也没有实时看板，CrewAI 和 MetaGPT 都没有。Edict 的看板能显示任务流转链、心跳状态和 Token 消耗，还能在运行中切换模型。但要注意，CrewAI 和 AutoGen 是通用编排框架，不绑定特定平台，而 Edict 绑定 OpenClaw。如果你已经在用 OpenClaw，Edict 是增强层；如果你还没选型，CrewAI 的轻量编排或 AutoGen 的对话驱动模式可能更容易上手。Edict 的看板功能在 README 中对比表里全部打勾，但部署难度标为低，实际安装步骤并不少，尤其是生产环境。
维护与升级成本
Edict 的维护成本主要来自两部分：OpenClaw 的版本兼容性和前端构建。install.sh 会写入 openclaw.json，如果 OpenClaw 更新了配置格式，install.sh 可能需要调整。前端是 React 构建，需要 Node.js 18+，如果本机没有 Node.js，安装脚本会跳过构建，但看板就无法使用。数据同步依赖符号链接，各 Workspace 的 data/scripts 指向项目目录，如果你手动修改了某个 Agent 的 Workspace，可能会破坏链接。许可证是 MIT，这意味着你可以自由修改和商用，但需要保留版权声明。由于没有 release 记录，版本升级路径不明确，你可能需要直接从 main 分支拉取最新代码，这增加了不确定性。
编辑结论
Edict 适合已经使用 OpenClaw、且对多 Agent 协作的可审计性和可干预性有硬性要求的团队，尤其是需要向客户或监管展示任务流转过程的场景。它不适合没有 OpenClaw 基础、或者只想要一个轻量编排库的开发者，因为整个系统深度绑定 OpenClaw 的 agent 管理、消息可见性和 Gateway 机制。在采用之前，需要先验证三件事：你的 OpenClaw 版本是否兼容 install.sh 中的权限矩阵写入逻辑；你的 API Key 是否能在所有 Agent 间同步；以及 Docker 镜像在非 amd64 架构上是否能正常启动。如果这三关都能过，Edict 的制度性审核和看板监控能显著减少黑盒输出，但如果你只是需要快速完成任务编排，CrewAI 或 AutoGen 的轻量模式可能更省事。
社区笔记