三省六部制 AI:OpenClaw 的帝国级进化

🏛️ 三省六部制 AI：OpenClaw 的帝国级进化

朕让 AI 上朝，结果 AI 比朕还卷。

一、引言：AI 协作的"战国时代"

1.1 一个来自 2026 年的困境

想象一下这个场景：

你是一家 tech 公司的 CTO，团队刚刚接到了一个紧急项目——在两周内完成一个全新的用户管理系统，包含 RESTful API、数据库设计、前端界面、测试用例和部署文档。

你手上有 5 个 AI 助手：

一个擅长写代码
一个擅长写文档
一个擅长做测试
一个擅长设计数据库
一个擅长写部署脚本

问题来了：你怎么让他们协作？

你尝试过让他们"自己聊"——建个群，把需求丢进去，然后说"你们商量着办"。

结果呢？

写代码的 AI 不知道数据库已经设计好了，自己又设计了一套
写文档的 AI 对着旧版本的 API 写了一堆废纸
测试的 AI 根本不知道系统应该有什么功能
最后交上来的东西，拼都拼不起来

这就是当前 Multi-Agent 协作的真实写照——战国时代，各自为政。

1.2 历史的回响

公元 627 年，唐太宗李世民登基。

面对庞大的帝国，他面临着一个类似的问题：如何让成千上万的官员高效协作，同时防止权力滥用？

他的答案是：三省六部制。

这个制度在中国延续了 1400 年，历经隋唐五代宋元，成为人类历史上最成功的官僚制度设计之一。

核心思想只有八个字：分权制衡，层层审核。

中书省负责规划——但不能执行
门下省负责审核——可以封驳皇帝的旨意
尚书省负责派发——但不能自己决定做什么
六部负责执行——但必须按审核通过的方案来

1300 年后，我们用这个制度重新设计了 AI 多 Agent 协作架构。

1.3 OpenClaw + edict：帝国级进化

OpenClaw 本身已经是一个强大的 AI 助手框架。

但当它集成了 edict 三省六部制多 Agent 协作系统后，发生了一次质的飞跃：

从一个"聪明的助手"，进化为一个"有制度的帝国机器"。

这不是简单的功能叠加，而是架构层面的根本性变革：

【表 1-1】OpenClaw 集成 edict 前后对比

维度	之前的 OpenClaw	集成 edict 后
协作模式	单 Agent 或松散协作	制度化分层协作
质量控制	依赖单个 Agent 水平	门下省强制审核
过程透明	黑箱操作	全流程可视化
可干预性	难以中途介入	随时叫停/恢复
审计能力	有限的日志记录	完整奏折存档
扩展能力	手动添加技能	Skills 生态一键导入

这就像从一个"草台班子"，升级成了"帝国机器"。

二、痛点深度剖析：为什么现有框架不够用

2.1 CrewAI：没有 QA 的工厂

CrewAI 是目前最流行的 Multi-Agent 框架之一。

它的核心理念是：定义几个 Agent，给每个 Agent 分配角色和任务，然后让他们自己协作完成。

听起来很美好，对吧？

但实际使用中，你会发现几个致命问题：

【表 2-1】CrewAI 三大问题

问题	表现	后果
没有质量审核	Agent"做完就交"	产出质量波动极大
过程不可观测	协作过程是黑箱	无法复盘优化
无法中途干预	任务开始后失控	错误无法及时纠正

就像一个软件公司没有 QA 部门——工程师写完代码直接上线，没有人检查代码质量、没有人做 Code Review、没有人测试边界情况。

2.2 AutoGen：Human-in-loop 的局限

AutoGen 是微软推出的 Multi-Agent 框架。

它引入了"Human-in-loop"的概念——允许人类在协作过程中介入。

听起来解决了干预问题，对吧？

但实际上有几个局限：

【表 2-2】AutoGen 三大局限

局限	说明	影响
介入成本高	需要配置复杂的回调函数	普通用户门槛太高
没有制度化审核	人类介入是"救火式"的	问题发生后才介入
审计能力弱	日志记录是分散的	难以追溯责任

就像消防队很厉害，但不如有一个防火检查部门。

2.3 MetaGPT：可选审核的尴尬

MetaGPT 尝试引入审核机制。

但它的问题是：审核是可选的。

就像一个公司的 QA 部门——项目紧急时可以"特事特办"，跳过 QA 直接上线。

短期看是效率，长期看是隐患。

2.4 核心问题总结

现有框架的共同问题：

【表 2-3】现有框架问题汇总

问题	表现	后果
无制度化审核	质量依赖单个 Agent	产出波动大
过程不透明	黑箱操作	无法复盘优化
无法实时干预	任务开始后失控	错误无法及时纠正
审计能力弱	日志分散	难以追溯责任
扩展性差	手动添加技能	生态建设困难

这些问题的根源在于：没有制度。

几个 AI 漫无目的地聊天，就像一个没有规章制度的公司——短期可能靠能人撑起局面，长期必然混乱。

三、三省六部制的历史智慧

3.1 制度起源：从汉到唐的演进

三省六部制不是凭空出现的。

它的雏形可以追溯到汉朝的尚书台，经过魏晋南北朝的演变，最终在隋朝定型，唐朝完善。

核心设计思想：

【表 3-1】三省六部制核心设计思想

思想	说明	作用
决策权、审核权、执行权分离	防止权力集中	避免独裁
层层审核	减少决策失误	提高质量
职责明确	每个部门知道该做什么	提高效率
相互制衡	没有一个部门可以为所欲为	防止滥用

3.2 三省：决策的中枢

【表 3-2】三省职责详解

部门	职责	权限	限制
中书省	接旨和规划	理解需求、拆解任务、制定方案	不能执行
门下省	审议和封驳	审核方案、打回重做	不能自己提方案
尚书省	派发和协调	派发任务、协调进度、汇总结果	不能决定做什么

3.3 六部：执行的力量

【表 3-3】六部职责与现代对应

部门	古代职责	现代对应	擅长领域
吏部	人事管理	HR、Agent 管理	Agent 注册、权限维护
户部	财政、数据	数据处理、报表	数据处理、报表生成
礼部	礼仪、文档	技术文档、规范	技术文档、API 文档
兵部	军事、工程	代码开发、算法	功能开发、Bug 修复
刑部	司法、审计	安全、合规	安全扫描、合规检查
工部	工程、制造	CI/CD、部署	Docker 配置、流水线

3.4 制度优势：为什么能延续 1400 年

三省六部制能延续 1400 年，不是偶然的。

【表 3-4】三省六部制四大优势

优势	说明	效果
分权制衡	没有一个部门可以独揽大权	权力被关进制度的笼子
强制审核	每一个决策都必须经过门下省	制度面前人人平等
职责明确	每个部门知道自己的职责	边界清晰，效率更高
可追溯	每一个决策都有记录	出问题可追溯责任

3.5 对 AI 协作的启示

1300 年前的制度设计，对今天的 AI 协作有什么启示？

答案：制度比能人更重要。

几个再聪明的 AI，如果没有制度约束，也会混乱。

一个有制度的系统，即使单个 Agent 水平一般，也能产出稳定的高质量结果。

这就是为什么我们把三省六部制引入 OpenClaw。

四、架构详解：12 个 AI 官员如何协作

4.1 整体协作流程

【表 4-1】旨意流转完整流程

步骤	部门	动作	输出
1	皇上（用户）	下旨	原始需求
2	太子	分拣传旨	提炼后的旨意
3	中书省	规划方案	子任务拆解
4	门下省	审议	准奏或封驳
5	尚书省	派发	任务分配
6	六部	执行	具体成果
7	尚书省	汇总回奏	最终报告
8	系统	归档	奏折存档

4.2 12 个 AI 官员详解

【表 4-2】12 个 AI 官员职责总览

部门	Agent ID	职责	擅长领域
太子	taizi	消息分拣、需求整理	闲聊识别、旨意提炼、标题概括
中书省	zhongshu	接旨、规划、拆解	需求理解、任务分解、方案设计
门下省	menxia	审议、把关、封驳	质量评审、风险识别、标准把控
尚书省	shangshu	派发、协调、汇总	任务调度、进度跟踪、结果整合
户部	hubu	数据、资源、核算	数据处理、报表生成、成本分析
礼部	libu	文档、规范、报告	技术文档、API 文档、规范制定
兵部	bingbu	代码、算法、巡检	功能开发、Bug 修复、代码审查
刑部	xingbu	安全、合规、审计	安全扫描、合规检查、红线管控
工部	gongbu	CI/CD、部署、工具	Docker 配置、流水线、自动化
吏部	libu_hr	人事、Agent 管理	Agent 注册、权限维护、培训
早朝官	zaochao	每日早朝、新闻聚合	定时播报、数据汇总

4.3 权限矩阵：谁能给谁发消息

不是想发就能发——真正的分权制衡。

【表 4-3】Agent 间通信权限矩阵

发送方 \ 接收方	太子	中书省	门下省	尚书省	户部	礼部	兵部	刑部	工部	吏部
太子	-	✅	❌	❌	❌	❌	❌	❌	❌	❌
中书省	❌	-	✅	✅	❌	❌	❌	❌	❌	❌
门下省	❌	✅	-	✅	❌	❌	❌	❌	❌	❌
尚书省	❌	✅	✅	-	✅	✅	✅	✅	✅	✅
六部 + 吏部	❌	❌	❌	✅	❌	❌	❌	❌	❌	❌

这个权限矩阵确保：

太子只能传旨给中书省
中书省只能提交给门下省和尚书省
门下省可以封驳给中书省，或准奏给尚书省
尚书省可以派发给六部
六部只能回报给尚书省

越权发消息？系统直接拒绝。

4.4 状态流转：旨意的一生

【表 4-4】任务状态流转规则

当前状态	可转换到的状态	说明
太子分拣	中书规划、已取消	太子分拣后传给中书省
中书规划	门下审议、已取消	中书省规划后提交审核
门下审议	已派发、中书规划、已取消	准奏则派发，封驳则返回中书省
已派发	执行中、已取消	尚书省派发后开始执行
执行中	待审查、阻塞、已取消	执行完成后进入审查
待审查	已完成、执行中、已取消	审查通过后完成
已完成	无	已完成不能转换
阻塞	执行中、已取消	解除阻塞后继续执行
已取消	无	已取消不能转换

状态转换受保护：系统内置状态机校验，非法跳转会被拒绝并记录日志。

五、核心功能全景解析

5.1 旨意看板 · Kanban

按状态列展示全部任务。

【表 5-1】旨意看板核心功能

功能	说明	用途
状态列展示	按任务状态分列	一眼看清各阶段任务
省部过滤	按部门筛选任务	查看特定部门工作
全文搜索	搜索任务标题、描述	快速定位任务
心跳徽章	活跃/停滞/告警状态	识别异常任务
任务详情	查看完整流转链	了解任务历史
实时干预	叫停/取消/恢复任务	掌控全局

5.2 省部调度 · Monitor

可视化各状态任务数量。

【表 5-2】省部调度核心功能

功能	说明	用途
状态分布	饼图展示各状态任务占比	了解整体进度
部门分布	横向条形图展示各部门任务数量	识别工作负载
Agent 健康	实时卡片展示 Agent 状态	监控 Agent 活性
Token 消耗	今日/本周 Token 使用统计	成本控制

5.3 奏折阁 · Memorials

已完成旨意自动归档。

【表 5-3】奏折阁核心功能

功能	说明	用途
自动归档	已完成任务自动转为奏折	知识沉淀
五阶段时间线	圣旨→中书→门下→六部→回奏	追溯全过程
Markdown 导出	一键复制为 Markdown	方便分享
状态筛选	按时间、部门、状态筛选	快速查找

5.4 旨库 · Template Library

9 个预设圣旨模板。

【表 5-4】9 个预设模板

模板	用途	涉及部门
周报生成	生成本周工作总结	户部 + 礼部
代码审查	审查代码质量和安全	兵部 + 刑部
API 设计	设计 RESTful API	礼部 + 兵部
竞品分析	分析竞争对手产品	户部 + 兵部 + 礼部
数据报告	生成数据分析报告	户部 + 礼部
博客文章	撰写技术博客	礼部
部署方案	设计部署架构	工部 + 兵部
邮件文案	撰写商务邮件	礼部
站会摘要	生成站会纪要	户部 + 礼部

5.5 官员总览 · Officials

Agent 绩效统计。

【表 5-5】官员总览核心功能

功能	说明	用途
Token 排行榜	按 Token 消耗排序	识别高消耗 Agent
活跃度	近 7 天活跃情况	监控 Agent 使用
完成数	完成任务数量	评估工作效率
会话统计	会话时长、消息数	了解交互情况

5.6 天下要闻 · News

每日自动采集科技/财经资讯。

【表 5-6】天下要闻核心功能

功能	说明	用途
自动采集	每日定时抓取新闻	获取最新资讯
分类订阅	科技/财经/AI/开源	按需订阅
飞书推送	重要新闻推送到飞书	及时通知
订阅管理	自定义订阅源	个性化配置

5.7 模型配置 · Models

每个 Agent 独立切换 LLM。

【表 5-7】模型配置核心功能

功能	说明	用途
独立配置	每个 Agent 可配置不同模型	按需分配
一键切换	看板内直接切换	快速调整
自动生效	应用后自动重启 Gateway	无需手动操作
成本优化	简单任务用便宜模型	节省成本

推荐配置：

【表 5-8】Agent 模型推荐配置

Agent	推荐模型	理由
太子	经济型	消息分拣不需要太强模型
中书省	高端型	规划需要强推理能力
门下省	高端型	审核需要精准判断
兵部	代码专用	代码生成优化模型
刑部	安全专用	安全审查优化模型

5.8 技能配置 · Skills

查看/添加 Skills。

【表 5-9】技能配置核心功能

功能	说明	用途
已安装技能	查看各省部已安装 Skills	了解现有能力
远程添加	从 GitHub/URL 一键导入	扩展能力
版本管理	支持技能版本更新	保持最新
技能详情	查看技能说明和使用方法	学习使用

5.9 小任务 · Sessions

OC-* 会话实时监控。

【表 5-10】小任务核心功能

功能	说明	用途
会话列表	所有活跃会话一览	全局监控
来源渠道	显示会话来源	了解来源分布
心跳状态	会话活跃度	识别异常
消息预览	最近消息预览	快速了解内容

5.10 上朝仪式 · Ceremony

每日首次打开播放开场动画。

【表 5-11】上朝仪式核心功能

功能	说明	用途
开场动画	帝国风格开场	增强仪式感
今日统计	昨日任务完成情况	了解进度
自动消失	3.5 秒后自动关闭	不干扰操作

让 AI 协作，有了帝国的仪式感。

5.11 朝堂议政 · Court Discussion

多官员围绕议题展开部门视角讨论。

【表 5-12】朝堂议政核心功能

功能	说明	用途
多角色辩论	各部依职责发表专业意见	多角度分析
多轮推进	支持多轮讨论	深入探讨
结论总结	自动总结讨论结论	形成决策
记录保留	完整讨论记录存档	追溯决策过程

六、门下省封驳权：杀手锏深度解析

6.1 为什么"封驳权"是杀手锏？

因为它是质量控制的最后一道防线。

CrewAI 和 AutoGen 的 Agent 协作模式是"做完就交"——没有人检查产出质量。

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

【表 6-1】门下省三大职责

职责	说明	效果
审查方案质量	中书省的规划是否完备	确保方案可行
封驳不合格的产出	不是 warning，是直接打回重做	强制返工
强制返工循环	直到方案达标才放行	保证最终质量

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

6.2 封驳的真实案例

【表 6-2】封驳案例一：缺少异常处理

阶段	内容
中书省原方案	1.编写 HTTP 请求模块 2.编写数据解析模块 3.编写数据库存储模块
门下省封驳意见	1.缺少 HTTP 请求失败的重试机制 2.缺少 API 返回数据格式异常的异常处理 3.缺少数据库连接失败的降级方案
中书省修订后	1.编写 HTTP 请求模块（含 3 次重试机制）2.编写数据解析模块（含格式校验和异常处理）3.编写数据库存储模块（含连接池和降级方案）4.编写全局异常处理器 5.编写日志记录模块
门下省最终决定	准奏

【表 6-3】封驳案例二：安全漏洞

阶段	内容
中书省原方案	1.编写用户注册 API 2.编写数据库表结构 3.编写前端界面
门下省封驳意见	1.密码未提及加密存储方案 2.未提及 SQL 注入防护 3.未提及 API 限流方案 4.未提及敏感信息日志脱敏
中书省修订后	1.编写用户注册 API（含 JWT 鉴权）2.编写数据库表结构（含索引优化）3.编写前端界面（含表单验证）4.密码 bcrypt 加密存储 5.SQL 参数化查询防护 6.API 限流（100 次/分钟）7.日志敏感信息脱敏 8.刑部安全审查
门下省最终决定	准奏

6.3 封驳统计数据

根据 edict 项目的实际运行数据：

【表 6-4】封驳统计数据

指标	数值
平均封驳率	23%
封驳后一次通过率	89%
封驳原因 TOP1	缺少异常处理（35%）
封驳原因 TOP2	安全问题（28%）
封驳原因 TOP3	方案不完备（22%）
封驳原因 TOP4	其他（15%）

封驳不是刁难，是质量保障。

6.4 封驳的边界

门下省虽然有权封驳，但也不是为所欲为。

封驳必须有理有据：

必须明确指出问题所在
必须给出修改建议
不能无故封驳
不能反复封驳同一问题

如果门下省滥用封驳权，怎么办？

系统有升级机制：

同一任务封驳超过 3 次，自动上报尚书省协调
尚书省可以裁定是否继续封驳
极端情况下，可以绕过门下省（需要记录原因）

制度内有救济渠道。

七、军机处看板：可视化治理的艺术

7.1 看板设计理念

"一眼看清全局"

【表 7-1】看板设计三大原则

原则	说明	效果
信息密度高	一个屏幕展示所有关键信息	不需要点来点去
实时刷新	数据每 15 秒自动刷新	信息自动推送
操作便捷	常用操作一键完成	点击即可完成

7.2 看板技术实现

【表 7-2】前端技术栈

技术	用途
React 18	UI 框架
TypeScript	类型安全
Vite	构建工具
Zustand	状态管理

【表 7-3】后端技术栈

模块	说明
server.py	API 服务器（纯 Python 标准库）
dashboard.html	内嵌前端（零依赖）
court_discuss.py	朝堂议政引擎
data/	数据存储目录

特点：零依赖，纯标准库，部署简单。

7.3 数据同步机制

【表 7-4】数据刷新脚本

脚本	功能
refresh_live_data.py	刷新实时数据
sync_officials_stats.py	同步官员统计
fetch_morning_news.py	抓取早间新闻
apply_model_changes.py	应用模型配置变更

15 秒刷新循环确保数据实时性。

八、实战案例：从旨意到奏折的完整旅程

8.1 案例背景

公司需求：搭建一个内部使用的文档管理系统

要求：

支持文档上传下载
支持版本管理
支持权限控制
支持全文搜索
支持在线预览
部署到公司内部服务器

8.2 完整流程

【表 8-1】完整流程时间线

时间	部门	动作	输出
09:00	皇上	下旨	原始需求
09:02	太子	分拣传旨	提炼后的旨意
09:05	中书省	规划方案	子任务拆解
09:10	门下省	封驳	问题清单
09:18	中书省	修订方案	补充后的方案
09:22	门下省	准奏	准予执行
09:24	尚书省	派发	任务分配
09:25	六部	执行	具体成果
14:30	尚书省	回奏	最终报告
14:35	系统	归档	奏折存档

总耗时：5 小时 35 分钟

8.3 案例总结

【表 8-2】三省六部制的核心价值

价值	说明	效果
门下省封驳	发现方案缺陷	避免返工
六部并行	多部门同时执行	提高效率
全程可视	看板实时展示进度	掌控全局
完整归档	奏折可追溯复盘	知识沉淀

如果没有三省六部制，可能会发生：

缺少数据库选型，开发到一半发现不兼容
缺少文件存储方案，上线后容量不足
缺少备份方案，数据丢失无法恢复
缺少监控方案，故障无法及时发现

门下省的一次封驳，避免了上线后的 N 次救火。

九、技术实现：背后的工程奇迹

9.1 Agent 间通信机制

【表 9-1】Session JSONL 数据融合

组件	说明
数据结构	JSONL 日志文件
同步机制	文件锁防止并发写入
存储位置	data/sessions/<agent_id>/session.jsonl
合并方式	定期合并到看板数据

9.2 权限矩阵实现

【表 9-2】权限矩阵配置示例

发送方	可接收方列表
太子	中书省
中书省	门下省、尚书省
门下省	中书省、尚书省
尚书省	中书省、门下省、六部、吏部
六部	尚书省

每次发消息前检查权限，越权直接拒绝。

9.3 状态机实现

【表 9-3】状态转换规则

当前状态	可转换状态
太子分拣	中书规划、已取消
中书规划	门下审议、已取消
门下审议	已派发、中书规划、已取消
已派发	执行中、已取消
执行中	待审查、阻塞、已取消
待审查	已完成、执行中、已取消
已完成	无
阻塞	执行中、已取消
已取消	无

非法状态转换会被拒绝并记录日志。

9.4 数据清洗规范

【表 9-4】旨意标题清洗规则

规则	说明	示例
移除文件路径	删除路径信息	"/path/to/file" → ""
移除元数据	删除方括号内容	"[重要]" → ""
移除无效前缀	删除"请/帮我/需要"等	"请帮我" → ""
限制长度	超过 50 字截断	50 字以上 → 47 字 + "..."

确保标题清晰、简洁、规范。

9.5 重复任务防护

【表 9-5】重复任务检测

检测项	说明
相似度阈值	85% 以上视为重复
检测范围	未完成的任务
处理方式	提示用户已有类似任务

9.6 已完成任务保护

【表 9-6】已完成任务保护

保护机制	说明
状态锁定	已完成任务不能修改状态
操作拦截	尝试修改时返回错误
日志记录	记录尝试修改的操作

防止误操作修改已完成任务。

十、性能对比：数据说话

10.1 任务完成质量对比

【表 10-1】任务完成质量对比

框架	一次通过率	返工率	用户满意度
CrewAI	62%	38%	7.2/10
AutoGen	68%	32%	7.5/10
MetaGPT	74%	26%	7.8/10
三省六部	89%	11%	9.1/10

数据来源：edict 项目实际运行统计（1000+ 任务）

10.2 任务耗时对比

【表 10-2】任务耗时对比（单位：小时）

框架	平均耗时	P90 耗时	P99 耗时
CrewAI	2.1	4.5	8.2
AutoGen	1.9	4.2	7.8
MetaGPT	2.3	4.8	9.1
三省六部	2.5	3.8	5.2

三省六部平均耗时略高（因为审核环节），但 P90/P99 耗时更低（返工少）。

10.3 Token 消耗对比

【表 10-3】Token 消耗对比（单位：个）

框架	平均 Token	P90 Token	P99 Token
CrewAI	45,000	120,000	280,000
AutoGen	42,000	115,000	260,000
MetaGPT	48,000	125,000	290,000
三省六部	52,000	95,000	150,000

三省六部平均 Token 略高（审核环节消耗），但 P90/P99 Token 更低（返工少）。

10.4 可干预性对比

【表 10-4】可干预性对比

框架	可叫停	可取消	可恢复	可修改
CrewAI	❌	❌	❌	❌
AutoGen	⚠️	⚠️	❌	❌
MetaGPT	⚠️	⚠️	❌	❌
三省六部	✅	✅	✅	✅

10.5 审计能力对比

【表 10-5】审计能力对比

框架	完整日志	时间线	决策记录	可导出
CrewAI	⚠️	❌	❌	❌
AutoGen	⚠️	⚠️	❌	⚠️
MetaGPT	⚠️	⚠️	❌	⚠️
三省六部	✅	✅	✅	✅

十一、适用场景与最佳实践

11.1 最佳适用场景

【表 11-1】最佳适用场景

场景	特征	示例
复杂项目规划	需要多部门协作、任务周期长、质量要求高	搭建完整系统、开发新功能模块
代码审查	需要安全审查、需要代码质量检查	上线前代码审查、安全漏洞扫描
API 设计	需要文档、需要实现、需要审核	RESTful API 设计、接口规范制定
数据分析	需要数据处理、需要报告生成	业务数据分析、财务报表生成
安全合规	需要安全扫描、需要合规检查	安全审计、合规检查
CI/CD 部署	需要部署脚本、需要流水线配置	Docker 配置、CI/CD 流水线
周报/报告生成	需要数据汇总、需要文案撰写	周报生成、项目报告

11.2 不适用场景

【表 11-2】不适用场景

场景	特征	建议
简单问答	只需要一个答案、不需要多部门协作	直接用单 Agent 回复
紧急任务	需要立即执行、没有时间审核	使用"急奏"模式
创意类任务	需要发散思维、没有标准答案	用"朝堂议政"模式

11.3 最佳实践

【表 11-3】最佳实践建议

实践	好的示例	不好的示例
旨意要清晰	"搭建一个内部文档管理系统，要求：支持文档上传下载、版本管理、权限控制、全文搜索、在线预览，部署到公司内部服务器"	"帮我弄个文档系统"
明确验收标准	"API 响应时间<200ms，支持 1000 并发"	"越快越好"
指定负责部门	"兵部负责开发，工部负责部署"	"你们看着办"
设置合理预期	"预计 5 小时完成"	"马上要"

十二、快速开始指南

12.1 方式一：Docker 一键体验（推荐）

【表 12-1】Docker 快速启动

步骤	命令	说明
1	docker run -p 7891:7891 cft0808/edict	启动容器
2	打开浏览器访问 http://localhost:7891	查看看板

12.2 方式二：本地安装

【表 12-2】本地安装步骤

步骤	命令	说明
1	git clone https://github.com/cft0808/edict.git	克隆仓库
2	cd edict	进入目录
3	chmod +x install.sh && ./install.sh	运行安装脚本

安装脚本自动完成：

创建全量 Agent Workspace
写入各省部 SOUL.md
注册 Agent 及权限矩阵
同步 API Key 到所有 Agent
构建 React 前端
重启 Gateway 使配置生效

12.3 配置 API Key

【表 12-3】API Key 配置

步骤	命令	说明
1	openclaw agents add taizi	添加太子 Agent
2	按提示配置 API Key	配置模型密钥
3	./install.sh	同步到所有 Agent

十三、常见问题解答

13.1 任务总超时

【表 13-1】任务超时问题排查

症状	可能原因	解决方案
六部完成了但无法传回太子	Agent ID 不匹配	检查 Agent 注册状态
Gateway 报错	LLM provider 超时	增加自动重试
僵尸 Agent 进程	进程卡住	运行 ps aux 检查并重启

13.2 Docker 架构错误

【表 13-2】Docker 架构错误解决

症状	错误信息	解决方案
架构不匹配	exec format error	docker run --platform linux/amd64

13.3 Skill 下载失败

【表 13-3】Skill 下载失败解决

症状	可能原因	解决方案
网络超时	访问 GitHub raw 超时	使用代理
仓库维护	官方 Skills Hub 维护	稍后重试

十四、生态与扩展：Skills 系统

14.1 官方 Skills Hub

【表 14-1】官方预设 Skills

Skill	用途	适用部门
code_review	代码审查	兵部、刑部
api_design	API 设计审查	礼部、兵部
security_audit	安全审计	刑部
data_analysis	数据分析	户部
doc_generation	文档生成	礼部
test_framework	测试框架设计	兵部

14.2 添加 Skills 的三种方式

【表 14-2】添加 Skills 方式对比

方式	适用场景	操作步骤
看板 UI	普通用户	看板→技能配置→添加远程 Skill
CLI 工具	开发者	python3 scripts/skill_manager.py add-remote
API	自动化	curl POST /api/add-remote-skill

14.3 创建自己的 Skills 库

【表 14-3】Skills 文件规范

要素	说明
SKILL.md	技能说明文件
函数定义	可被调用的函数
触发条件	什么情况下使用
输入输出	参数和返回值规范

十五、未来路线图

15.1 短期计划（3 个月）

【表 15-1】短期计划

功能	说明	优先级
深色/浅色主题	UI 主题切换	高
移动端适配	响应式设计	高
Notion 适配器	集成 Notion	中
Linear 适配器	集成 Linear	中

15.2 中期计划（6 个月）

【表 15-2】中期计划

功能	说明	优先级
功过簿	Agent 绩效评分体系	高
急递铺	Agent 间实时消息流可视化	中
国史馆	知识库检索 + 引用溯源	中
年度大考	Agent 年度绩效报告	低

15.3 长期计划（12 个月）

【表 15-3】长期计划

功能	说明	优先级
十二部制扩展	新增专职 Agent 角色	中
PWA 支持	离线使用	中
ClawHub 上架	正式发布	高
多语言支持	日文、韩文、西班牙文	低

十六、结语：以古制御新技

16.1 核心回顾

【表 16-1】三省六部制六大核心优势

优势	说明
制度性审核	门下省专职审核，不合格直接封驳打回
完全可观测	军机处看板实时展示所有 Agent 的思考过程
实时可干预	随时叫停、取消、恢复任务
完整审计链	每个旨意的 5 阶段流转完整存档
分权制衡	严格的权限矩阵，防止失控
生态扩展	远程 Skills 一键导入，能力无限扩展

16.2 最终对比

【表 16-2】最终对比总结

维度	传统框架	三省六部
质量	依赖单个 Agent	制度化审核保障
透明	黑箱操作	全流程可视化
控制	无法干预	实时掌控
审计	有限日志	完整奏折
扩展	手动添加	生态一键导入

16.3 最后的思考

古有邸报传天下政令，今有看板治 AI 万机。

OpenClaw 集成 edict 三省六部制后，不再是几个 AI 漫无目的地聊天。

它是一个有制度、有审核、有审计、可干预的帝国机器。

12 个 AI 官员各司其职，门下省把关质量，军机处实时看板，奏折完整归档。

以古制御新技，以智慧驾驭 AI。