edict Documentation

️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails

17,013 stars Python Python 13 files · ~18,820 tokens #ai-agents#ai-orchestration#autonomous-agents#claude#dashboard#kanban#llm#multi-agent
RAW Doc

Docker & Self-Hosted Deployment Verified OCI

Deploy edict on any server, homelab, or cloud container platform.

1-Click Terminal Command
bash (docker run) 
docker run -d --name edict -p 5432:5432 --restart always postgres:16-alpine
Configured Services & Ports
⚙️ postgres
image: postgres:16-alpine
🔌 Ports: 5432:5432
⚙️ redis
image: redis:7-alpine
🔌 Ports: 6379:6379
⚙️ backend
image: build locally
🔌 Ports: 8000:8000
⚙️ orchestrator
image: build locally
⚙️ dispatcher
image: build locally
⚙️ frontend
image: build locally
🔌 Ports: 3000:3000
docker-compose.yml
yaml (docker-compose.yml) 
# ══════════════════════════════════════════════════════
# Edict 三省六部 — 事件驱动架构 Docker Compose
# ══════════════════════════════════════════════════════

services:
  # ── 基础设施 ──

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: edict
      POSTGRES_USER: edict
      POSTGRES_PASSWORD: edict_dev_2024
    ports:
      - "5432:5432"
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U edict"]
      interval: 5s
      timeout: 3s
      retries: 5
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5
    restart: unless-stopped

  # ── 后端服务 ──

  backend:
    build:
      context: ..
      dockerfile: edict/Dockerfile
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql+asyncpg://edict:edict_dev_2024@postgres:5432/edict
      REDIS_URL: redis://redis:6379/0
      PORT: 8000
      DEBUG: "true"
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - ../agents:/app/agents:ro
      - ../data:/app/data
    command: >
      sh -c "
        python -m alembic upgrade head &&
        uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload
      "
    restart: unless-stopped

  # ── Worker 进程 ──

  orchestrator:
    build:
      context: ..
      dockerfile: edict/Dockerfile
    environment:
      DATABASE_URL: postgresql+asyncpg://edict:edict_dev_2024@postgres:5432/edict
      REDIS_URL: redis://redis:6379/0
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    command: python -m app.workers.orchestrator_worker
    restart: unless-stopped

  dispatcher:
    build:
      context: ..
      dockerfile: edict/Dockerfile
    environment:
      DATABASE_URL: postgresql+asyncpg://edict:edict_dev_2024@postgres:5432/edict
      REDIS_URL: redis://redis:6379/0
      OPENCLAW_PROJECT_DIR: /app
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - ../agents:/app/agents:ro
      - ../scripts:/app/scripts
      - ../data:/app/data
    command: python -m app.workers.dispatch_worker
    restart: unless-stopped

  # ── 前端 ──

  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    environment:
      VITE_API_URL: http://localhost:8000
      VITE_WS_URL: ws://localhost:8000/ws
    depends_on:
      - backend
    restart: unless-stopped

volumes:
  pg_data:
  redis_data:

Technical Documentation: cft0808/edict

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (README.md)

⚔️ 三省六部 · Edict

🎬 Demo

📸 GIF 预览（加载更快）

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

🤔 为什么是三省六部？

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

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

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

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

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

这不是花哨的 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 健康状态实时卡片 |
    | --- | --- |
    | 📜 奏折阁 · Memorials
  • 已完成旨意自动归档为奏折
  • 五阶段时间线：圣旨→中书→门下→六部→回奏
  • 一键复制为 Markdown
  • 按状态筛选 | 📜 旨库 · Template Library
  • 9 个预设圣旨模板
  • 分类筛选 · 参数表单 · 预估时间和费用
  • 预览旨意 → 一键下旨 |
    | 👥 官员总览 · Officials
  • Token 消耗排行榜
  • 活跃度 · 完成数 · 会话统计 | 📰 天下要闻 · News
  • 每日自动采集科技/财经资讯
  • 分类订阅管理 + 飞书推送 |
    | ⚙️ 模型配置 · Models
  • 每个 Agent 独立切换 LLM
  • 应用后自动重启 Gateway（~5秒生效） | 🛠️ 技能配置 · Skills
  • 各省部已安装 Skills 一览
  • 查看详情 + 添加新技能 |
    | 💬 小任务 · Sessions
  • OC-* 会话实时监控
  • 来源渠道 · 心跳 · 消息预览 | 🎬 上朝仪式 · Ceremony
  • 每日首次打开播放开场动画
  • 今日统计 · 3.5秒自动消失 |
    | 🏛️ 朝堂议政 · Court Discussion
  • 多官员围绕议题展开部门视角讨论
  • LLM 驱动的多角色辩论（各部依职责发表专业意见）
  • 支持多轮推进 · 总结结论 · 保留讨论记录 | |

🖼️ 截图

旨意看板

📸 展开查看更多截图

省部调度

任务流转详情

模型配置

技能配置

官员总览

会话记录

奏折归档

圣旨模板

天下要闻

上朝仪式

🚀 30 秒快速体验

Docker 一键启动

bash
docker run -p 7891:7891 cft0808/sansheng-demo

打开 http://localhost:7891 即可体验军机处看板。

⚠️ 遇到 exec format error？（点击展开）

如果你在 x86/amd64 机器（如 Ubuntu、WSL2）上看到：

text
exec /usr/local/bin/python3: exec format error

这是因为镜像架构不匹配。请使用 --platform 参数：

bash
docker run --platform linux/amd64 -p 7891:7891 cft0808/sansheng-demo

或使用 docker-compose（已内置 platform: linux/amd64）：

bash
docker compose up

完整安装

前置条件

  • OpenClaw 已安装
  • Python 3.10+
  • macOS / Linux

安装

bash
git clone https://github.com/cft0808/edict.git
cd edict
chmod +x install.sh && ./install.sh

安装脚本自动完成：

  • ✅ 创建全量 Agent Workspace（含太子/吏部/早朝，兼容历史 main）
  • ✅ 写入各省部 SOUL.md（角色人格 + 工作流规则 + 数据清洗规范）
  • ✅ 注册 Agent 及权限矩阵到 openclaw.json
  • ✅ 符号链接统一数据（各 Workspace 的 data/scripts → 项目目录，确保数据一致）
  • ✅ 设置 Agent 间通信可见性（sessions.visibility all，解决消息不可达问题）
  • ✅ 同步 API Key 到所有 Agent（自动从已配置的 Agent 复制）
  • ✅ 构建 React 前端（需 Node.js 18+，如未安装则跳过）
  • ✅ 初始化数据目录 + 首次数据同步（含官员统计）
  • ✅ 重启 Gateway 使配置生效

⚠️ 首次安装：需先配置 API Key：openclaw agents add taizi，然后重新运行 ./install.sh 同步到所有 Agent。

启动

bash
# 方式 1：一键启动（推荐）
chmod +x start.sh && ./start.sh

# 方式 2：分别启动
bash scripts/run_loop.sh &      # 数据刷新循环
python3 dashboard/server.py     # 看板服务器

# 打开浏览器
open http://127.0.0.1:7891

🖥️ 生产环境部署（systemd）

bash
# 安装 systemd 服务
sudo cp edict.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable edict
sudo systemctl start edict

# 或使用管理脚本
bash edict.sh start    # 启动
bash edict.sh status   # 查看状态
bash edict.sh restart  # 重启
bash edict.sh stop     # 停止

💡 看板即开即用：server.py 内嵌 dashboard/dashboard.html，Docker 镜像包含预构建的 React 前端

💡 详细教程请看 Getting Started 指南

🏛️ 架构

text
/* Detailed source-code truncated for AI context efficiency. */

各省部职责

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

权限矩阵

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

From ↓ \ To → 太子 中书 门下 尚书 户 礼 兵 刑 工 吏
太子 — ✅
中书省 ✅ — ✅ ✅
门下省 ✅ — ✅
尚书省 ✅ ✅ — ✅ ✅ ✅ ✅ ✅ ✅
六部+吏部 ✅

任务状态流转

text
皇上 → 太子分拣 → 中书规划 → 门下审议 → 已派发 → 执行中 → 待审查 → ✅ 已完成
                      ↑          │                              │
                      └──── 封驳 ─┘                    阻塞 Blocked

⚡ 状态转换受保护：kanban_update.py 内置 _VALID_TRANSITIONS 状态机校验，
非法跳转（如 Doing→Taizi）会被拒绝并记录日志，确保流程不可绕过。

🔄 异步事件驱动：服务间通过 Redis Streams EventBus 解耦通信，Outbox Relay 保障事件可靠投递。
所有状态变更自动写入审计日志（audit.py），支持完整追溯。

📁 项目结构

text
/* Detailed source-code truncated for AI context efficiency. */

🎯 使用方法

向 AI 下旨

通过 Feishu / Telegram / Signal 给中书省发消息：

text
给我设计一个用户注册系统，要求：
1. RESTful API（FastAPI）
2. PostgreSQL 数据库
3. JWT 鉴权
4. 完整测试用例
5. 部署文档

然后坐好，看戏：

  1. 📜 中书省接旨，规划子任务分配方案
  2. 🔍 门下省审议，通过 / 封驳打回重规划
  3. 📮 尚书省准奏，派发给兵部 + 工部 + 礼部
  4. ⚔️ 各部并行执行，进度实时可见
  5. 📮 尚书省汇总结果，回奏给你

全程可在军机处看板实时监控，随时可以叫停、取消、恢复。

使用圣旨模板

看板 → 📜 旨库 → 选模板 → 填参数 → 下旨

9 个预设模板：周报生成 · 代码审查 · API 设计 · 竞品分析 · 数据报告 · 博客文章 · 部署方案 · 邮件文案 · 站会摘要

自定义 Agent

编辑 agents//SOUL.md 即可修改 Agent 的人格、职责和输出规范。

增补 Skills（从网上连接）

三种方式添加 Skills：

1️⃣ 看板 UI（最简单）

text
看板 → 🔧 技能配置 → ➕ 添加远程 Skill
→ 输入 Agent + Skill 名称 + GitHub URL
→ 确认 → ✅ 完成

2️⃣ CLI 命令（最灵活）

bash
# 从 GitHub 添加 mmx_cli skill 到门下省
python3 scripts/skill_manager.py add-remote \
  --agent menxia \
  --name mmx_cli \
  --source https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md \
  --description "MiniMax 多模态 CLI 技能"

# 一键导入默认 skills 到指定 agents
python3 scripts/skill_manager.py import-official-hub \
  --agents menxia,shangshu

# 列出所有已添加的远程 skills
python3 scripts/skill_manager.py list-remote

# 更新某个 skill 到最新版本
python3 scripts/skill_manager.py update-remote \
  --agent menxia \
  --name mmx_cli

3️⃣ API 请求（自动化集成）

bash
# 添加远程 skill
curl -X POST http://localhost:7891/api/add-remote-skill \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "menxia",
    "skillName": "mmx_cli",
    "sourceUrl": "https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md",
    "description": "MiniMax 多模态 CLI 技能"
  }'

# 查看所有远程 skills
curl http://localhost:7891/api/remote-skills-list

默认可导入 Skill：

支持的 Skills：

  • mmx_cli — MiniMax 多模态 CLI 技能（文本、图像、视频、语音、音乐、搜索）

如果你有自己的 Skills Hub，可以通过 OPENCLAW_SKILLS_HUB_BASE 或 ~/.openclaw/skills-hub-url 配置自定义源。

详见 🎓 远程 Skills 资源管理指南

🔧 技术亮点

特点 说明
React 18 前端 TypeScript + Vite + Zustand 状态管理，13 个功能组件
纯 stdlib 后端 server.py 基于 http.server，零依赖，同时提供 API + 静态文件服务
EventBus 事件总线 Redis Streams 发布/订阅，服务间解耦通信
Outbox Relay 事务性 Outbox 模式，保障事件可靠投递（至少一次语义）
状态机审计 严格生命周期状态转换 + 完整审计日志（audit.py）
并行调度引擎 Dispatch Worker 支持并行执行、指数退避重试、资源锁
DAG 编排器 Orchestrator 基于 DAG 的任务分解与依赖解析
Agent 思考可视 实时展示 Agent 的 thinking 过程、工具调用、返回结果
一键安装 / 一键启动 install.sh 自动配置，start.sh 一条命令启动全部服务
systemd 生产部署 edict.service 支持 systemd 守护进程，开机自启
15 秒同步 数据自动刷新，看板倒计时显示
Dashboard 鉴权 auth.py 提供看板登录认证
每日仪式 首次打开播放上朝开场动画
远程 Skills 生态 从 GitHub/URL 一键导入能力，支持版本管理 + CLI + API + UI

� 深入了解

核心文档

  • 📖 任务分发流转完整架构 — 必读文档

    • 详细讲解三省六部如何处理复杂任务的业务设计和技术实现
    • 涵盖：9大任务状态机 / 权限矩阵 / 4阶段调度（重试→升级→回滚）/ Session JSONL数据融合
    • 包含完整的使用案例、API端点说明、CLI工具文档
    • 对标 CrewAI/AutoGen：为什么制度化>自由协作
    • 故障场景与恢复机制
    • 读这个文档会理解为什么三省六部这么强大（9500+ 字，30 分钟完整理解）

  • 🎓 远程 Skills 资源管理指南 — Skills 生态

    • 从网上连接和增补 skills，支持 GitHub/Gitee/任意 HTTPS URL
    • 默认 Skills 源和自定义 Hub 支持
    • CLI 工具 + 看板 UI + Restful API
    • Skills 文件规范与安全防护
    • 支持版本管理和一键更新

  • ⚡ Remote Skills 快速入门 — 5 分钟上手

    • 快速体验、CLI 命令、看板操作示例
    • 创建自己的 Skills 库
    • API 完整参考 + 常见问题

  • 🚀 快速上手指南 — 新手入门

  • 🤝 贡献指南 — 想参与贡献？从这里开始

🔧 常见问题排查

❌ 任务总超时 / 下属完成了但无法传回太子

症状：六部或尚书省已完成任务，但太子收不到回报，最终超时。

排查步骤：

  1. 检查 Agent 注册状态：
bash
curl -s http://127.0.0.1:7891/api/agents-status | python3 -m json.tool

确认 taizi agent 的 statusLabel 是 alive。

  1. 检查 Gateway 日志：
bash
ls /tmp/openclaw/ | tail -5          # 找到最新日志
grep -i "error\|fail\|unknown" /tmp/openclaw/openclaw-*.log | tail -20

  1. 常见原因：

    • Agent ID 不匹配（已在 v1.2 修复：main → taizi）
    • LLM provider 超时（增加了自动重试）
    • 僵尸 Agent 进程（运行 ps aux | grep openclaw 检查）

  2. 强制重试：

bash
# 手动触发巡检扫描（自动重试卡住的任务）
curl -X POST http://127.0.0.1:7891/api/scheduler-scan \
  -H 'Content-Type: application/json' -d '{"thresholdSec":60}'

❌ Docker: exec format error

症状：exec /usr/local/bin/python3: exec format error

原因：镜像架构（arm64）与主机架构（amd64）不匹配。

解决：

bash
# 方法 1：指定平台
docker run --platform linux/amd64 -p 7891:7891 cft0808/sansheng-demo

# 方法 2：使用 docker-compose（已内置 platform）
docker compose up

❌ Skill 下载失败

症状：python3 scripts/skill_manager.py import-official-hub 报错。

排查：

bash
# 测试网络连通性
curl -I https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md

# 如果超时，使用代理
export https_proxy=http://your-proxy:port
python3 scripts/skill_manager.py import-official-hub --agents menxia

常见原因：

  • 中国大陆访问 GitHub raw 资源需要代理
  • 网络超时（已增加到 30 秒 + 自动重试 3 次）
  • 默认 skill 源无法访问，或自定义 Skills Hub 配置错误

�🗺️ Roadmap

完整路线图及参与方式：ROADMAP.md

Phase 1 — 核心架构 ✅

  • 十二部制 Agent 架构（太子 + 三省 + 七部 + 早朝官）+ 权限矩阵
  • 军机处实时看板（10 个功能面板 + 实时活动面板）
  • 任务叫停 / 取消 / 恢复
  • 奏折系统（自动归档 + 五阶段时间线）
  • 圣旨模板库（9 个预设 + 参数表单）
  • 上朝仪式感动画
  • 天下要闻 + 飞书推送 + 订阅管理
  • 模型热切换 + 技能管理 + 技能添加
  • 官员总览 + Token 消耗统计
  • 小任务 / 会话监控
  • 太子消息分拣（闲聊自动回复 / 旨意建任务）
  • 旨意数据清洗（路径/元数据/前缀自动剥离）
  • 重复任务防护 + 已完成任务保护
  • 端到端测试覆盖（17 个断言）
  • React 18 前端重构（TypeScript + Vite + Zustand · 13 组件）
  • Agent 思考过程可视化（实时 thinking / 工具调用 / 返回结果）
  • 前后端一体化部署（server.py 同时提供 API + 静态文件服务）

Phase 2 — 制度深化 🚧

  • 御批模式（人工审批 + 一键准奏/封驳）
  • 功过簿（Agent 绩效评分 + 模型推荐 + 成本优化）
  • EventBus 事件总线（Redis Streams 解耦通信）
  • Outbox Relay（事务性事件投递）
  • 状态机审计（严格生命周期 + 审计日志）
  • 并行调度引擎（指数退避重试 + 资源锁）
  • DAG 编排器（任务分解 + 依赖解析）
  • Dashboard 鉴权（登录认证）
  • 一键启动 / systemd 生产部署
  • 急递铺（Agent 间实时消息流可视化）
  • 国史馆（知识库检索 + 引用溯源）

Phase 3 — 生态扩展

  • Docker Compose + Demo 镜像
  • Notion / Linear 适配器
  • 年度大考（Agent 年度绩效报告）
  • 移动端适配 + PWA
  • ClawHub 上架

🤝 参与贡献

欢迎任何形式的贡献！详见 CONTRIBUTING.md

特别欢迎的方向：

  • 🎨 UI 增强：深色/浅色主题、响应式、动画优化
  • 🤖 新 Agent：适合特定场景的专职 Agent 角色
  • 📦 Skills 生态：各部门专用技能包
  • 🔗 集成扩展：Notion · Jira · Linear · GitHub Issues
  • 🌐 国际化：日文 · 韩文 · 西班牙文
  • 📱 移动端：响应式适配、PWA

📂 案例

examples/ 目录收录了真实的端到端使用案例：

案例 旨意 涉及部门
竞品分析 "分析 CrewAI vs AutoGen vs LangGraph" 中书→门下→户部+兵部+礼部
代码审查 "审查这段 FastAPI 代码的安全性" 中书→门下→兵部+刑部
周报生成 "生成本周工程团队周报" 中书→门下→户部+礼部

每个案例包含：完整旨意 → 中书省规划 → 门下省审核意见 → 各部执行结果 → 最终奏折。

⭐ Star History

如果这个项目让你会心一笑，请给个 Star ⚔️

📮 朕的邸报——公众号

古有邸报传天下政令，今有公众号聊 AI 架构。

你会看到：

  • 🏛️ 架构拆解 —— 三省六部到底怎么分权制衡的？12 个 Agent 各司何职？
  • 🔥 踩坑复盘 —— Agent 吵架了怎么办？Token 烧光了怎么省？门下省为什么总封驳？
  • 🛠️ Issue 修复实录 —— 每个 bug 都是一道奏折，看朕如何批红
  • 💡 Token 省钱术 —— 用 1/10 的 token 跑出门下省审核效果的秘密
  • 🎭 Agent 人设彩蛋 —— 六部的 SOUL.md 是怎么写出来的？

"朕让 AI 上朝，结果 AI 比朕还卷。" —— 关注后你会懂的。

📄 License

MIT · 由 OpenClaw 社区构建

Getting Started (`docs/getting-started.md`)

🚀 快速上手指南

从零开始，5 分钟搭建你的三省六部 AI 协同系统

第一步：安装 OpenClaw

三省六部基于 OpenClaw 运行，请先安装：

bash
# macOS
brew install openclaw

# 或下载安装包
# https://openclaw.ai/download

安装完成后初始化：

bash
openclaw init

第二步：克隆并安装三省六部

bash
git clone https://github.com/cft0808/edict.git
cd edict
chmod +x install.sh && ./install.sh

安装脚本会自动完成：

  • ✅ 创建 12 个 Agent Workspace（~/.openclaw/workspace-*）
  • ✅ 写入各省部 SOUL.md 人格文件
  • ✅ 注册 Agent 及权限矩阵到 openclaw.json
  • ✅ 配置旨意数据清洗规则
  • ✅ 构建 React 前端到 dashboard/dist/（需 Node.js 18+）
  • ✅ 初始化数据目录
  • ✅ 执行首次数据同步
  • ✅ 重启 Gateway 使配置生效

第三步：配置消息渠道

在 OpenClaw 中配置消息渠道（Feishu / Telegram / Signal），将 taizi（太子）Agent 设为旨意入口。太子会自动分拣闲聊与指令，指令类消息提炼标题后转发中书省。

bash
# 查看当前渠道
openclaw channels list

# 添加飞书渠道（入口设为太子）
openclaw channels add --type feishu --agent taizi

参考 OpenClaw 文档：https://docs.openclaw.ai/channels

第四步：启动服务

bash
# 终端 1：数据刷新循环（每 15 秒同步）
bash scripts/run_loop.sh

# 终端 2：看板服务器
python3 dashboard/server.py

# 打开浏览器
open http://127.0.0.1:7891

💡 提示：run_loop.sh 每 15 秒自动同步数据。可用 & 后台运行。

💡 看板即开即用：server.py 内嵌 dashboard/dashboard.html，无需额外构建。Docker 镜像包含预构建的 React 前端。

第五步：发送第一道旨意

通过消息渠道发送任务（太子会自动识别并转发到中书省）：

text
请帮我用 Python 写一个文本分类器：
1. 使用 scikit-learn
2. 支持多分类
3. 输出混淆矩阵
4. 写完整的文档

第六步：观察执行过程

打开看板 http://127.0.0.1:7891

  1. 📋 旨意看板 — 观察任务在各状态之间流转
  2. 🔭 省部调度 — 查看各部门工作分布
  3. 📜 奏折阁 — 任务完成后自动归档为奏折

任务流转路径：

text
收件 → 太子分拣 → 中书规划 → 门下审议 → 已派发 → 执行中 → 已完成

🎯 进阶用法

使用圣旨模板

看板 → 📜 旨库 → 选择模板 → 填写参数 → 下旨

9 个预设模板：周报生成 · 代码审查 · API 设计 · 竞品分析 · 数据报告 · 博客文章 · 部署方案 · 邮件文案 · 站会摘要

切换 Agent 模型

看板 → ⚙️ 模型配置 → 选择新模型 → 应用更改

约 5 秒后 Gateway 自动重启生效。

管理技能

看板 → 🛠️ 技能配置 → 查看已安装技能 → 点击添加新技能

叫停 / 取消任务

在旨意看板或任务详情中，点击 ⏸ 叫停 或 🚫 取消 按钮

订阅天下要闻

看板 → 📰 天下要闻 → ⚙️ 订阅管理 → 选择分类 / 添加源 / 配飞书推送

❓ 故障排查

看板显示「服务器未启动」

bash
# 确认服务器正在运行
python3 dashboard/server.py

Agent 报错 "No API key found for provider"

这是最常见的问题。三省六部有 11 个 Agent，每个都需要 API Key。

bash
# 方法一：为任意 Agent 配置后重新运行 install.sh（推荐）
openclaw agents add taizi          # 按提示输入 Anthropic API Key
cd edict && ./install.sh            # 自动同步到所有 Agent

# 方法二：手动复制 auth 文件
MAIN_AUTH=$(find ~/.openclaw/agents -name auth-profiles.json | head -1)
for agent in taizi zhongshu menxia shangshu hubu libu bingbu xingbu gongbu; do
  mkdir -p ~/.openclaw/agents/$agent/agent
  cp "$MAIN_AUTH" ~/.openclaw/agents/$agent/agent/auth-profiles.json
done

# 方法三：逐个配置
openclaw agents add taizi
openclaw agents add zhongshu
# ... 其他 Agent

Agent 不响应

bash
# 检查 Gateway 状态
openclaw gateway status

# 必要时重启
openclaw gateway restart

数据不更新

bash
# 检查刷新循环是否运行
ps aux | grep run_loop

# 手动执行一次同步
python3 scripts/refresh_live_data.py

心跳显示红色 / 告警

bash
# 检查对应 Agent 的进程
openclaw agent status <agent-id>

# 重启指定 Agent
openclaw agent restart <agent-id>

模型切换后不生效

等待约 5 秒让 Gateway 重启完成。仍不生效则：

bash
python3 scripts/apply_model_changes.py
openclaw gateway restart

📚 更多资源

Remote Skills Quickstart (`docs/remote-skills-quickstart.md`)

远程 Skills 快速入门

5 分钟体验

1. 启动服务器

bash
# 确保你在项目根目录
python3 dashboard/server.py
# 输出: 三省六部看板启动 → http://127.0.0.1:7891

2. 添加默认 Skill（CLI）

bash
# 为门下省添加 MiniMax CLI skill
python3 scripts/skill_manager.py add-remote \
  --agent menxia \
  --name mmx_cli \
  --source https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md \
  --description "MiniMax 多模态 CLI 技能"

# 输出:
# ⏳ 正在从 https://raw.githubusercontent.com/... 下载...
# ✅ 技能 mmx_cli 已添加到 menxia
#    路径: /Users/xxx/.openclaw/workspace-menxia/skills/mmx_cli/SKILL.md
#    大小: 14655 字节

3. 列出所有远程 Skills

bash
python3 scripts/skill_manager.py list-remote

# 输出:
# 📋 共 1 个远程 skills：
# 
# Agent       | Skill 名称           | 描述                           | 添加时间
# ------------|----------------------|--------------------------------|----------
# menxia      | mmx_cli              | MiniMax 多模态 CLI 技能         | 2026-03-02

4. 查看 API 响应

bash
curl http://localhost:7891/api/remote-skills-list | jq .

# 输出:
# {
#   "ok": true,
#   "remoteSkills": [
#     {
#       "skillName": "mmx_cli",
#       "agentId": "menxia",
#       "sourceUrl": "https://raw.githubusercontent.com/...",
#       "description": "MiniMax 多模态 CLI 技能",
#       "localPath": "/Users/xxx/.openclaw/workspace-menxia/skills/mmx_cli/SKILL.md",
#       "addedAt": "2026-03-02T14:30:00Z",
#       "lastUpdated": "2026-03-02T14:30:00Z",
#       "status": "valid"
#     }
#   ],
#   "count": 1,
#   "listedAt": "2026-03-02T14:35:00Z"
# }

常见操作

一键导入默认 skills

bash
python3 scripts/skill_manager.py import-official-hub \
  --agents menxia,shangshu

这会为指定 agent 添加默认可用的 mmx_cli skill。旧的 openclaw-ai/skills-hub 仓库当前不可用，因此不再作为默认官方源。

如果你维护自己的 Skills Hub，可以通过环境变量或本地配置指定：

bash
export OPENCLAW_SKILLS_HUB_BASE=https://your-hub/raw-base
# 或
echo "https://your-hub/raw-base" > ~/.openclaw/skills-hub-url

更新某个 Skill 到最新版本

bash
python3 scripts/skill_manager.py update-remote \
  --agent menxia \
  --name mmx_cli

# 输出:
# ⏳ 正在从 https://raw.githubusercontent.com/... 下载...
# ✅ 技能 mmx_cli 已添加到 menxia
# ✅ 技能已更新
#    路径: /Users/xxx/.openclaw/workspace-menxia/skills/mmx_cli/SKILL.md
#    大小: 14655 字节

移除某个 Skill

bash
python3 scripts/skill_manager.py remove-remote \
  --agent menxia \
  --name mmx_cli

# 输出:
# ✅ 技能 mmx_cli 已从 menxia 移除

看板 UI 操作

在看板中添加 Remote Skill

  1. 打开 http://localhost:7891
  2. 进入 🔧 技能配置 面板
  3. 点击 ➕ 添加远程 Skill 按钮
  4. 填写表单：
    • Agent: 从下拉列表选择（如 menxia）
    • Skill 名称: 输入内部 ID 如 mmx_cli
    • 远程 URL: 粘贴 GitHub URL 如 https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md
    • 中文描述: 可选，如 MiniMax 多模态 CLI 技能
  5. 点击 导入 按钮
  6. 等待 1-2 秒，看到 ✅ 成功提示

管理已添加的 Skills

在看板 → 🔧 技能配置 → 远程 Skills 标签页：

  • 查看: 点击 Skill 名称查看 SKILL.md 内容
  • 更新: 点击 🔄 重新从源 URL 下载最新版本
  • 删除: 点击 ✕ 移除本地副本
  • 复制 URL: 快速分享给他人

创建自己的 Skill 库

目录结构

text
my-skills-hub/
├── code_review/
│   └── SKILL.md          # 代码审查能力
├── api_design/
│   └── SKILL.md          # API 设计审查
├── data_analysis/
│   └── SKILL.md          # 数据分析
└── README.md

SKILL.md 模板

markdown
---
name: my_custom_skill
description: 简短描述
version: 1.0.0
tags: [tag1, tag2]
---

# Skill 完整名称

详细描述...

## 输入

说明接收什么参数

## 处理流程

具体步骤...

## 输出规范

输出格式说明

上传到 GitHub

bash
git init
git add .
git commit -m "Initial commit: my-skills-hub"
git remote add origin https://github.com/yourname/my-skills-hub
git push -u origin main

导入自己的 Skill

bash
python3 scripts/skill_manager.py add-remote \
  --agent zhongshu \
  --name my_skill \
  --source https://raw.githubusercontent.com/yourname/my-skills-hub/main/my_skill/SKILL.md \
  --description "我的定制技能"

API 完整参考

POST /api/add-remote-skill

添加远程 skill。

请求：

bash
curl -X POST http://localhost:7891/api/add-remote-skill \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "zhongshu",
    "skillName": "code_review",
    "sourceUrl": "https://raw.githubusercontent.com/...",
    "description": "代码审查"
  }'

响应 (200):

json
{
  "ok": true,
  "message": "技能 code_review 已从远程源添加到 zhongshu",
  "skillName": "code_review",
  "agentId": "zhongshu",
  "source": "https://raw.githubusercontent.com/...",
  "localPath": "/Users/xxx/.openclaw/workspace-zhongshu/skills/code_review/SKILL.md",
  "size": 2048,
  "addedAt": "2026-03-02T14:30:00Z"
}

GET /api/remote-skills-list

列出所有远程 skills。

bash
curl http://localhost:7891/api/remote-skills-list

响应:

json
{
  "ok": true,
  "remoteSkills": [
    {
      "skillName": "mmx_cli",
      "agentId": "menxia",
      "sourceUrl": "https://raw.githubusercontent.com/...",
      "description": "MiniMax 多模态 CLI 技能",
      "localPath": "/Users/xxx/.openclaw/workspace-menxia/skills/mmx_cli/SKILL.md",
      "addedAt": "2026-03-02T14:30:00Z",
      "lastUpdated": "2026-03-02T14:30:00Z",
      "status": "valid"
    }
  ],
  "count": 1,
  "listedAt": "2026-03-02T14:35:00Z"
}

POST /api/update-remote-skill

更新远程 skill 为最新版本。

bash
curl -X POST http://localhost:7891/api/update-remote-skill \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "zhongshu",
    "skillName": "code_review"
  }'

DELETE /api/remove-remote-skill

移除远程 skill。

bash
curl -X POST http://localhost:7891/api/remove-remote-skill \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "zhongshu",
    "skillName": "code_review"
  }'

故障排查

Q: 下载失败，提示 "Connection timeout"

A: 检查网络连接和 URL 有效性

bash
curl -I https://raw.githubusercontent.com/...
# 应该返回 HTTP/1.1 200 OK

Q: 文件格式无效

A: 确保 SKILL.md 以 YAML frontmatter 开头

markdown
---
name: skill_name
description: 描述
---

# 正文开始...

Q: 导入后看不到 Skill

A: 刷新看板或检查 Agent 是否配置正确

bash
# 检查 Agent 是否存在
python3 scripts/skill_manager.py list-remote

# 检查本地文件
ls -la ~/.openclaw/workspace-zhongshu/skills/

更多信息

Screenshots README (`docs/screenshots/README.md`)

📸 截图说明

看板截图用于 README 和文档展示。请启动看板后按以下顺序截图并放置到本目录。

截图清单

文件名 内容 对应面板
01-kanban-main.png 旨意看板总览 📋 旨意看板
02-monitor.png 省部调度 🔭 省部调度
03-task-detail.png 任务流转详情（点击任务卡片展开） 📋 旨意看板 → 详情
04-model-config.png 模型配置面板 ⚙️ 模型配置
05-skills-config.png 技能配置面板 🛠️ 技能配置
06-official-overview.png 官员总览（12 位 Agent） 👥 官员总览
07-sessions.png 小任务 / 会话 💬 小任务
08-memorials.png 奏折阁 📜 奏折阁
09-templates.png 旨库（圣旨模板） 📜 旨库
10-morning-briefing.png 天下要闻 📰 天下要闻
11-ceremony.png 上朝仪式动画 开场动画

自动截图

bash
# 确保看板服务器正在运行
python3 dashboard/server.py &

# 自动截取全部 11 张截图
python3 scripts/take_screenshots.py

# 录制 demo GIF（需要 ffmpeg）
python3 scripts/record_demo.py

建议

  • 使用 1920×1080 或 2560×1440 分辨率
  • 确保看板有足够的数据（至少 5+ 任务）
  • 深色主题截图效果最佳
  • 截图前刷新数据确保最新状态

Dashboard Upgrade Plan (`docs/dashboard-upgrade-plan.md`)

军机处看板（Dashboard）升级计划

任务ID：JJC-20260303-001
日期：2026-03-03
状态：门下省已准奏，尚书省派发执行中

一、背景

Phase 1 核心架构已全部完成（十二部制、实时看板、任务全生命周期、E2E测试等）。基于用户反馈和 ROADMAP Phase 2/3 规划，制定本升级计划，分三批推进。

二、升级批次总览

批次 周期 内容 负责部门
第一批 2-3周 御批模式、移动端适配、Docker一键体验 工部、刑部
第二批 2-3周 功过簿、急递铺、ClawHub上架 工部、礼部、户部
第三批 后续 国史馆、看板适配器、年度大考 工部、户部

三、第一批（高优先级，2-3周）

3.1 御批模式（人工审批节点）

目标：门下省审议完成后，任务进入「待御批」状态，用户在看板一键准奏/封驳。

  • 新增 AwaitingImperial 任务中间态
  • 看板新增「待御批」面板（待批列表 + 历史批示）
  • API：POST /api/tasks/{id}/imperial-review，body: { action: "approve" | "reject", comment?: string }
  • 飞书/Telegram 推送审批通知
  • 超时机制：配置 imperial_review_timeout_hours（默认24h），超时策略可选：自动准奏 / 再次提醒 / 阻塞等待
  • 执行：工部开发前后端，刑部编写测试
  • 详细设计：见 docs/design-imperial-review.md

3.2 移动端响应式适配

目标：手机/平板可正常使用看板。

  • Tailwind 响应式断点：sm:640px / md:768px / lg:1024px
  • EdictBoard 移动端改为纵向卡片列表（< md）
  • TaskModal 移动端全屏显示
  • 顶部导航栏 < md 折叠为汉堡菜单
  • 执行：工部前端
  • 详细设计：见 docs/design-mobile-responsive.md

3.3 Docker 一键体验

目标：docker compose up 即可体验完整看板（含预置数据）。

  • 基于现有 docker/demo_data/ 构建
  • Dockerfile：前端 build + 后端 serve 单容器
  • docker-compose.yml：看板服务 + 可选 Gateway
  • 预置 demo 数据（已有 tasks_source.json, officials_stats.json 等）
  • CI（GitHub Actions）自动构建推送镜像
  • 执行：工部 DevOps
  • 详细设计：见 docs/design-docker.md

四、第二批（中优先级，2-3周）

4.1 功过簿（Agent 绩效评分）

  • 每个 Agent 完成率、返工率、耗时统计
  • 排行榜 + 趋势图面板
  • 自动标记"能臣" / "需训练"
  • 执行：工部开发 + 户部数据统计 + 礼部文档

4.2 急递铺（消息流可视化）

  • 看板实时连线动画：中书→门下→尚书→六部
  • 消息类型着色（派发/审议/回奏/封驳）
  • 时间线回放模式
  • 执行：工部前端

4.3 ClawHub 上架

  • 核心 Skills 提交 OpenClaw 官方市场
  • 一键安装三省六部 Skill Pack
  • 执行：礼部

五、第三批（后续规划）

功能 简述 负责
国史馆 历史旨意沉淀、相似检索、引用溯源 工部+户部
看板适配器 Notion/Linear/GitHub Issues 同步 工部
年度大考 Agent 年度绩效报告 + 可视化大屏 户部

六、性能基线要求（门下省修订）

升级前后须对比验证以下指标：

指标 测量方式 目标
首屏加载时间 Lighthouse / Performance API < 2s (LCP)
API 响应时间 /api/tasks P95 < 200ms
Bundle 大小 vite build 输出 记录基线，升级后不超过 +15%
内存占用 Chrome DevTools 记录基线

执行：户部测量，升级前后各出一份报告。

七、执行分工汇总

部门 第一批 第二批 第三批
工部 御批模式前后端、响应式适配、Docker 功过簿、急递铺 国史馆、看板适配器
刑部 御批模式测试、E2E补充 — —
礼部 — 文档整理、ClawHub —
户部 性能基线测量 功过簿数据统计 年度大考

八、里程碑

时间 里程碑
W1 性能基线测量完成；御批模式 API + 前端开发；Docker 镜像初版
W2 御批模式联调测试；移动端适配完成；Docker compose 可用
W3 第一批全部上线；刑部 E2E 测试通过；性能对比报告
W4-6 第二批开发 + 上线
W7+ 第三批按需推进

Design Docker (`docs/design-docker.md`)

Docker 一键体验 详细设计

任务ID：JJC-20260303-001 · 第一批 · 功能3

1. 目标

bash
docker compose up
# 浏览器打开 http://localhost:3926 即可体验完整看板

2. Dockerfile

dockerfile
FROM node:20-alpine AS frontend
WORKDIR /app/frontend
COPY edict/frontend/package*.json ./
RUN npm ci
COPY edict/frontend/ ./
RUN npm run build

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY edict/ ./edict/
COPY docker/demo_data/ ./data/
COPY --from=frontend /app/frontend/dist ./edict/frontend/dist
EXPOSE 3926
ENV DEMO_MODE=true
CMD ["python", "edict/server.py"]

3. docker-compose.yml

yaml
version: "3.8"
services:
  dashboard:
    build: .
    ports:
      - "3926:3926"
    environment:
      - DEMO_MODE=true
      - HOST=0.0.0.0
      - PORT=3926
    volumes:
      - dashboard-data:/app/data
    restart: unless-stopped

volumes:
  dashboard-data:

4. Demo 数据

已有 docker/demo_data/ 目录中的数据文件：

  • tasks_source.json — 示例旨意
  • officials_stats.json — 官员统计
  • agent_config.json — Agent 配置
  • live_status.json — 实时状态
  • morning_brief.json — 早朝简报
  • model_change_log.json — 模型切换记录

DEMO_MODE=true 时 server.py 从 /app/data/ 加载这些文件，API 可读可写但不持久化到宿主机（除非挂载 volume）。

5. CI/CD（GitHub Actions）

yaml
# .github/workflows/docker.yml
name: Build & Push Docker
on:
  push:
    branches: [main]
    tags: ['v*']
jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: |
            openclaw/sansheng-dashboard:latest
            openclaw/sansheng-dashboard:${{ github.sha }}

6. README 补充

在项目根 README 添加 Quick Start 区块：

markdown
## 🐳 Quick Start (Docker)

​```bash
git clone https://github.com/xxx/openclaw-sansheng-liubu.git
cd openclaw-sansheng-liubu
docker compose up
# 打开 http://localhost:3926
​```

Design Imperial Review (`docs/design-imperial-review.md`)

御批模式 详细设计

任务ID：JJC-20260303-001 · 第一批 · 功能1

1. 概述

在门下省审议通过后，任务不再直接派发尚书省，而是进入 AwaitingImperial 状态，等待用户（皇上）在看板中手动准奏或封驳。

2. 状态机变更

text
现有流程：
  DoorReviewing → Approved → ShangShuDispatching

新增流程：
  DoorReviewing → Approved → AwaitingImperial → ImperialApproved → ShangShuDispatching
                                               → ImperialRejected → (终止或退回中书)

新增状态枚举值：

  • AwaitingImperial — 待御批
  • ImperialApproved — 御批准奏
  • ImperialRejected — 御批封驳

3. API 设计

POST /api/tasks/{id}/imperial-review

json
// Request
{
  "action": "approve" | "reject",
  "comment": "optional string"
}

// Response 200
{
  "task_id": "JJC-xxx",
  "status": "ImperialApproved" | "ImperialRejected",
  "reviewed_at": "2026-03-03T12:00:00Z"
}

GET /api/tasks?status=AwaitingImperial

返回所有待御批任务列表。

配置项

在 server.py 或配置文件中新增：

python
IMPERIAL_REVIEW_CONFIG = {
    "enabled": True,                          # 是否启用御批模式
    "timeout_hours": 24,                      # 超时时间
    "timeout_action": "remind",               # "auto_approve" | "remind" | "block"
    "notify_channels": ["feishu", "telegram"] # 通知渠道
}

4. 前端组件

ImperialReviewPanel（新组件）

位置：edict/frontend/src/components/ImperialReviewPanel.tsx

功能：

  • 显示待御批任务列表（卡片形式）
  • 每个卡片含：任务标题、中书省方案摘要、门下省审议意见、等待时长
  • 操作按钮：「准奏」（绿色）/ 「封驳」（红色）
  • 封驳时弹出评论输入框
  • 超时任务高亮提示

在 EdictBoard 中新增 Tab 或面板位。

状态流转动画

准奏时：玉玺盖章动画（可选，低优先级）

5. 通知集成

门下省审议通过 → 触发通知：

text
📜 新旨意待御批
标题：{task.title}
门下省意见：{review.summary}
⏰ 请在 {timeout_hours}h 内批示
👉 点击查看：{dashboard_url}

超时提醒（若 timeout_action = "remind"）：

text
⚠️ 旨意超时未批
标题：{task.title}
已等待：{hours}h
👉 请尽快批示

6. 后端实现要点

  • server.py 新增路由 /api/tasks//imperial-review
  • 任务状态流转逻辑修改：门下省 Approved → 检查 imperial_review.enabled → 若开启则进入 AwaitingImperial
  • 超时检查：启动时注册定时任务（每5分钟检查一次），或使用懒检查（查询时判断）
  • 数据存储：在任务 JSON 中新增 imperial_review 字段
python
"imperial_review": {
    "status": "pending" | "approved" | "rejected",
    "submitted_at": "ISO timestamp",
    "reviewed_at": "ISO timestamp",
    "comment": "string",
    "timeout_notified": false
}

7. 测试用例（刑部）

# 场景 预期
1 门下省通过后任务进入 AwaitingImperial 状态正确，看板显示
2 点击准奏 状态变 ImperialApproved，触发尚书省派发
3 点击封驳（含评论） 状态变 ImperialRejected，评论保存
4 超时-自动准奏模式 超时后自动通过
5 超时-提醒模式 超时后发送提醒通知
6 超时-阻塞模式 超时后仍保持 AwaitingImperial
7 御批模式关闭 门下省通过后直接派发（兼容旧流程）
8 API 参数校验 非法 action 返回 400

Design Mobile Responsive (`docs/design-mobile-responsive.md`)

移动端响应式适配 详细设计

任务ID：JJC-20260303-001 · 第一批 · 功能2

1. 断点策略

使用 Tailwind CSS 默认断点：

断点 宽度 布局
默认 (mobile) < 640px 单列纵向
sm ≥ 640px 单列宽松
md ≥ 768px 双列
lg ≥ 1024px 完整桌面布局（现有）

2. 组件适配清单

2.1 EdictBoard（看板主体）

桌面（≥ lg）：保持现有多列横向布局

移动（< md）：

  • 切换为纵向卡片列表
  • 各状态列改为可切换的 Tab（待处理 / 进行中 / 已完成 等）
  • 任务卡片全宽显示，增大点击区域
tsx
// 伪代码
<div className="flex flex-col md:flex-row gap-4">
  {/* 移动端 Tab 切换 */}
  <div className="md:hidden">
    <StatusTabs active={activeTab} onChange={setActiveTab} />
  </div>
  {/* 桌面端多列 */}
  <div className="hidden md:flex gap-4">
    {columns.map(col => <KanbanColumn key={col.status} />)}
  </div>
</div>

2.2 TaskModal（任务详情弹窗）

移动（< md）：全屏模式

tsx
<div className="fixed inset-0 md:inset-auto md:max-w-2xl md:mx-auto md:my-8 md:rounded-lg">

2.3 导航栏

移动（< md）：

  • Logo + 汉堡菜单按钮
  • 点击展开侧边栏（slide-in overlay）
  • 包含所有导航项
tsx
// 移动端汉堡菜单
<button className="md:hidden" onClick={toggleMenu}>
  <HamburgerIcon />
</button>
<nav className={`fixed inset-y-0 left-0 w-64 transform ${open ? 'translate-x-0' : '-translate-x-full'} md:static md:translate-x-0`}>
  {navItems}
</nav>

2.4 其他面板

  • 官员总览：移动端改为 2 列网格 → 1 列
  • 模型切换面板：卡片全宽堆叠
  • 奏折时间线：保持纵向，缩小边距

3. 触控优化

  • 所有可点击元素最小 44x44px
  • 添加 touch-action: manipulation 消除 300ms 延迟
  • 滑动手势：左滑任务卡片显示操作按钮（可选，Phase 2）

4. 测试

  • Chrome DevTools 设备模拟：iPhone SE / iPhone 14 / iPad
  • 真机测试（如有条件）
  • 确保无横向溢出、无文字截断

Performance Baseline Plan (`docs/performance-baseline-plan.md`)

性能基线测量计划

任务ID：JJC-20260303-001 · 门下省修订要求
执行：户部

测量指标

指标 工具 方法
首屏加载 (LCP) Lighthouse CLI npx lighthouse http://localhost:3926 --output=json
首次可交互 (TTI) Lighthouse CLI 同上
Bundle 大小 npm run build 记录 dist/ 总体积及各 chunk
API P95 响应时间 autocannon / k6 GET /api/tasks 1000次请求
内存占用 Chrome DevTools / process.memoryUsage() 稳态 + 50任务负载

执行步骤

  1. 升级前（当前版本）执行全量测量，输出 docs/baseline-before.json
  2. 第一批功能全部合并后，同条件再测，输出 docs/baseline-after.json
  3. 生成对比报告 docs/performance-comparison.md

通过标准

  • LCP 不超过基线 +20%（目标 < 2s）
  • API P95 不超过基线 +15%（目标 < 200ms）
  • Bundle 大小不超过基线 +15%

Remote Skills Guide (`docs/remote-skills-guide.md`)

远程 Skills 资源管理指南

概述

三省六部现已支持从网上连接和增补 skills 资源，无需手动复制文件。支持从以下来源获取：

  • GitHub 仓库 (raw.githubusercontent.com)
  • 任何 HTTPS URL (需返回有效的 skill 文件)
  • 本地文件路径
  • 默认 Skills 源 (经验证可访问的内置导入源)

功能架构

1. API 端点

`POST /api/add-remote-skill`

从远程 URL 或本地路径为指定 Agent 添加 skill。

请求体：

json
{
  "agentId": "zhongshu",
  "skillName": "code_review",
  "sourceUrl": "https://raw.githubusercontent.com/org/skills-repo/main/code_review/SKILL.md",
  "description": "代码审查专项技能"
}

参数说明：

  • agentId (string, 必需): 目标 Agent ID (验证有效性)
  • skillName (string, 必需): skill 的内部名称 (仅允许字母/数字/下划线/汉字)
  • sourceUrl (string, 必需): 远程 URL 或本地文件路径
    • GitHub: https://raw.githubusercontent.com/user/repo/branch/path/SKILL.md
    • 任意 HTTPS: https://example.com/skills/my_skill.md
    • 本地: file:///Users/bingsen/skills/code_review.md 或 /Users/bingsen/skills/code_review.md
  • description (string, 可选): skill 的中文描述

响应成功 (200)：

json
{
  "ok": true,
  "message": "技能 code_review 已添加到 zhongshu",
  "skillName": "code_review",
  "agentId": "zhongshu",
  "source": "https://raw.githubusercontent.com/...",
  "localPath": "/Users/bingsen/.openclaw/workspace-zhongshu/skills/code_review/SKILL.md",
  "size": 2048,
  "addedAt": "2026-03-02T14:30:00Z"
}

响应失败 (400)：

json
{
  "ok": false,
  "error": "URL 无效或无法访问",
  "details": "Connection timeout after 10s"
}

`GET /api/remote-skills-list`

列出所有已添加的远程 skills 及其源信息。

响应：

json
{
  "ok": true,
  "remoteSkills": [
    {
      "skillName": "code_review",
      "agentId": "zhongshu",
      "sourceUrl": "https://raw.githubusercontent.com/org/skills-repo/main/code_review/SKILL.md",
      "description": "代码审查专项技能",
      "localPath": "/Users/bingsen/.openclaw/workspace-zhongshu/skills/code_review/SKILL.md",
      "lastUpdated": "2026-03-02T14:30:00Z",
      "status": "valid"  // valid | invalid | not-found
    }
  ],
  "count": 5
}

`POST /api/update-remote-skill`

更新已添加的远程 skill 为最新版本。

请求体：

json
{
  "agentId": "zhongshu",
  "skillName": "code_review"
}

响应：

json
{
  "ok": true,
  "message": "技能已更新",
  "skillName": "code_review",
  "newVersion": "2.1.0",
  "updatedAt": "2026-03-02T15:00:00Z"
}

`DELETE /api/remove-remote-skill`

移除已添加的远程 skill。

请求体：

json
{
  "agentId": "zhongshu",
  "skillName": "code_review"
}

CLI 命令

添加远程 Skill

bash
python3 scripts/skill_manager.py add-remote \
  --agent zhongshu \
  --name code_review \
  --source https://raw.githubusercontent.com/org/skills-repo/main/code_review/SKILL.md \
  --description "代码审查专项技能"

列出远程 Skills

bash
python3 scripts/skill_manager.py list-remote

更新远程 Skill

bash
python3 scripts/skill_manager.py update-remote \
  --agent zhongshu \
  --name code_review

移除远程 Skill

bash
python3 scripts/skill_manager.py remove-remote \
  --agent zhongshu \
  --name code_review

默认 Skills 源

MiniMax CLI Skill

默认导入源包含经验证可访问的 MiniMax CLI skill。旧的 openclaw-ai/skills-hub 仓库当前不可用，因此不再作为默认官方源。

可用 skills 列表：

Skill 名称 描述 适用 Agent 源 URL
mmx_cli MiniMax 多模态 CLI 技能 门下省/尚书省 https://raw.githubusercontent.com/MiniMax-AI/cli/main/skill/SKILL.md

如果你维护自己的 Skills Hub，可以使用以下方式指定 Hub base URL。指定后，import-official-hub 会按 /<skill_name>/SKILL.md 解析 code_review、api_design、security_audit、data_analysis、doc_generation、test_framework 等传统 skill 名称。

bash
export OPENCLAW_SKILLS_HUB_BASE=https://your-hub/raw-base

# 或写入本地配置
echo "https://your-hub/raw-base" > ~/.openclaw/skills-hub-url

一键导入默认 skills

bash
python3 scripts/skill_manager.py import-official-hub \
  --agents menxia,shangshu

看板 UI 操作

快捷添加 Skill

  1. 打开看板 → 🔧 技能配置 面板
  2. 点击 ➕ 添加远程 Skill 按钮
  3. 填写表单：
    • Agent: 选择目标 Agent
    • Skill 名称: 输入 skill 的内部 ID
    • 远程 URL: 粘贴 GitHub/HTTPS URL
    • 中文描述: 可选，简述 skill 功能
  4. 点击 确认 按钮

管理已添加的 Skills

  1. 看板 → 🔧 技能配置 → 远程 Skills 标签
  2. 查看已添加的所有 skills 及其源地址
  3. 操作：
    • 查看: 展示 SKILL.md 内容
    • 更新: 从源 URL 重新下载最新版本
    • 删除: 移除本地副本（不影响源）
    • 复制源 URL: 快速分享给他人

Skill 文件规范

远程 skills 必须遵循标准的 Markdown 格式：

最小必需结构

markdown
---
name: skill_internal_name
description: Short description
version: 1.0.0
tags: [tag1, tag2]
---

# Skill 名称

详细描述...

## 输入

说明接收什么参数

## 处理流程

具体步骤...

## 输出规范

输出格式说明

完整示例

markdown
---
name: code_review
description: 对 Python/JavaScript 代码进行结构审查和优化建议
version: 2.1.0
author: openclaw-ai
tags: [code-quality, security, performance]
compatibleAgents: [bingbu, xingbu, menxia]
---

# 代码审查技能

本技能专门用于对生产代码进行多维度审查...

## 输入

- `code`: 要审查的源代码
- `language`: 编程语言 (python, javascript, go, rust)
- `focusAreas`: 审查重点 (security, performance, style, structure)

## 处理流程

1. 语言识别与语法验证
2. 安全漏洞扫描
3. 性能瓶颈识别
4. 代码风格检查
5. 最佳实践建议

## 输出规范

```json
{
  "issues": [
    {
      "type": "security|performance|style|structure",
      "severity": "critical|high|medium|low",
      "location": "line:column",
      "message": "问题描述",
      "suggestion": "修复建议"
    }
  ],
  "summary": {
    "totalIssues": 3,
    "criticalCount": 1,
    "highCount": 2
  }
}

适用场景

  • 兵部（代码实现）的代码产出审查
  • 刑部（合规审计）的安全检查
  • 门下省（审议把关）的质量评估

依赖与限制

  • 需要 Python 3.9+
  • 支持文件大小: 最多 50KB
  • 执行超时: 30 秒
text
---

## 数据存储

### 本地存储结构

~/.openclaw/
├── workspace-zhongshu/
│ └── skills/
│ ├── code_review/
│ │ ├── SKILL.md
│ │ └── .source.json # 存储源 URL 和元数据
│ └── api_design/
│ ├── SKILL.md
│ └── .source.json
├── ...

text
### .source.json 格式

```json
{
  "skillName": "code_review",
  "sourceUrl": "https://raw.githubusercontent.com/...",
  "description": "代码审查专项技能",
  "version": "2.1.0",
  "addedAt": "2026-03-02T14:30:00Z",
  "lastUpdated": "2026-03-02T14:30:00Z",
  "lastUpdateCheck": "2026-03-02T15:00:00Z",
  "checksum": "sha256:abc123...",
  "status": "valid"
}

安全考虑

URL 验证

✅ 允许的 URL 类型:

  • HTTPS URLs: https://
  • 本地文件: file:// 或绝对路径
  • 相对路径: ./skills/

❌ 禁止的 URL 类型:

  • HTTP (非 HTTPS): http:// 被拒绝
  • 本地模式 HTTP: http://localhost/ (避免环回攻击)
  • FTP/SSH: ftp://, ssh://

内容验证

  1. 格式验证: 确保是有效的 Markdown YAML frontmatter
  2. 大小限制: 最多 10 MB
  3. 超时保护: 下载超过 30 秒自动中止
  4. 路径遍历防护: 检查解析后的 skill 名称，禁用 ../ 模式
  5. checksum 验证: 可选的 GPG 签名验证（适用于可信发布源）

隔离执行

  • 远程 skills 在沙箱中执行（由 OpenClaw runtime 提供）
  • 无法访问 ~/.openclaw/config.json 等敏感文件
  • 只能访问分配的 workspace 目录

故障排查

常见问题

Q: 下载失败，提示 "Connection timeout"

A: 检查网络连接和 URL 有效性：

bash
curl -I https://raw.githubusercontent.com/...

Q: Skill 显示 "invalid" 状态

A: 检查文件格式：

bash
python3 -m json.tool ~/.openclaw/workspace-zhongshu/skills/xxx/SKILL.md

Q: 能否从私有 GitHub 仓库导入？

A: 不支持（安全考虑）。可以：

  1. 将仓库设为公开
  2. 在本地下载后直接添加
  3. 通过 GitHub Gist 的公开链接

Q: 如何创建自己的 skills 库？

A: 按 <skill_name>/SKILL.md 的结构创建自己的仓库，然后：

bash
git clone https://github.com/yourname/my-skills-hub.git
cd my-skills-hub
# 创建 skill 文件结构
# 提交 & 推送到 GitHub

然后通过 URL 添加，或通过 OPENCLAW_SKILLS_HUB_BASE / ~/.openclaw/skills-hub-url 配置为自定义 Hub 后导入。

最佳实践

1. 版本管理

始终在 SKILL.md 的 frontmatter 中标注版本号：

yaml
---
version: 2.1.0
---

2. 向后兼容

更新 skill 时保持输入/输出格式兼容，避免破坏现有流程。

3. 文档完整

包含详细的:

  • 功能描述
  • 适用场景
  • 依赖说明
  • 输出示例

4. 定期更新

设置定期检查更新（周期可在看板中配置）：

bash
python3 scripts/skill_manager.py check-updates --interval weekly

5. 贡献社区

成熟的 skills 可以沉淀到你自己的公开 Skills Hub，并通过 OPENCLAW_SKILLS_HUB_BASE 分享给团队使用。

API 完整参考

详见 任务分发流转架构文档 的第三部分（API 与工具）。

Task Dispatch Architecture (`docs/task-dispatch-architecture.md`)

三省六部任务分发流转体系 · 业务与技术架构

本文档详细阐述「三省六部」项目如何从业务制度设计到代码实现细节，完整处理复杂多Agent协作的任务分发与流转。这是一个制度化的AI多Agent框架，而非传统的自由讨论式协作系统。

文档概览图

text
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
业务层：帝国制度 (Imperial Governance Model)
  ├─ 分权制衡：皇上 → 太子 → 中书 → 门下 → 尚书 → 六部
  ├─ 制度约束：不可越级、状态严格递进、门下必审议
  └─ 质量保障：可封驳反工、实时可观测、紧急可干预
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技术层：OpenClaw多Agent编排 (Multi-Agent Orchestration)
  ├─ 状态机：9个状态（Pending → Taizi → Zhongshu → Menxia → Assigned → Doing/Next → Review → Done/Cancelled）
  ├─ 数据融合：flow_log + progress_log + session JSONL → unified activity stream
  ├─ 权限矩阵：严格的subagent调用权限控制
  └─ 调度层：自动派发、超时重试、停滞升级、自动回滚
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
观测层：React 看板 + 实时API (Dashboard + Real-time Analytics)
  ├─ 任务看板：10个视图面板（全部/按状态/按部门/按优先级等）
  ├─ 活动流：59条/任务的混合活动记录（思考过程、工具调用、状态转移）
  └─ 在线状态：Agent 实时节点检测 + 心跳喚醒机制
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📚 第一部分：业务架构

1.1 帝国制度：分权制衡的设计哲学

核心理念

传统的多Agent框架（如CrewAI、AutoGen）采用**"自由协作"模式**：

  • Agent自主选择协作对象
  • 框架仅提供通信通道
  • 质量控制完全依赖Agent智能
  • 问题：容易出现Agent相互制造假数据、重复工作、方案质量无保障

三省六部采用**"制度化协作"模式**，模仿古代帝国官僚体系：

text
皇上
              (User)
               │
               ↓
             太子 (Taizi)
        [分拣官、消息接入总负责]
      ├─ 识别：这是旨意还是闲聊？
      ├─ 执行：直接回复闲聊 || 建立任务→转中书
      └─ 权限：只能调用 中书省
               │
               ↓
           中书省 (Zhongshu)
      [规划官、方案起草总负责]
      ├─ 接旨后分析需求
      ├─ 拆解为子任务（todos）
      ├─ 调用门下省审议 OR 尚书省咨询
      └─ 权限：只能调用 门下 + 尚书
               │
               ↓
           门下省 (Menxia)
        [审议官、质量把握人]
      ├─ 审查中书方案（可行性、完整性、风险）
      ├─ 准奏 OR 封驳（含修改建议）
      ├─ 若封驳 → 返回中书修改 → 重新审议（最多3轮）
      └─ 权限：只能调用 尚书 + 回调中书
               │
         (✅ 准奏)
               │
               ↓
           尚书省 (Shangshu)
        [派发官、执行总指挥]
      ├─ 接到准奏方案
      ├─ 分析派发给哪个部门
      ├─ 调用六部（礼/户/兵/刑/工/吏）执行
      ├─ 监控各部进度 → 汇总结果
      └─ 权限：只能调用 六部（不能越权调中书）
               │
               ├─ 礼部 (Libu)      - 文档编制官
               ├─ 户部 (Hubu)      - 数据分析官
               ├─ 兵部 (Bingbu)    - 代码实现官
               ├─ 刑部 (Xingbu)    - 测试审查官
               ├─ 工部 (Gongbu)    - 基础设施官
               └─ 吏部 (Libu_hr)   - 人力资源官
               │
         (各部并行执行)
               ↓
           尚书省·汇总
      ├─ 收集六部结果
      ├─ 状态转为 Review
      ├─ 回调中书省转报皇上
               │
               ↓
           中书省·回奏
      ├─ 汇总现象、结论、建议
      ├─ 状态转为 Done
      └─ 回复飞书消息给皇上

制度的4大保障

保障机制 实现细节 防护效果
制度性审核 门下省必审议所有中书方案，不可跳过 防止Agent胡乱执行，确保方案具有可行性
分权制衡 权限矩阵：谁能调谁严格定义 防止权力滥用（如尚书越权调中书改方案）
完全可观测 任务看板10个面板 + 59条活动/任务 实时看到任务卡在哪、谁在工作、工作状态如何
实时可干预 看板内一键 stop/cancel/resume/advance 紧急情况（如发现Agent走错方向）能立即纠正

1.2 任务完整流转流程

流程示意图

mermaid
stateDiagram-v2
[*] --> Pending: 皇上下旨
Pending --> Taizi: 太子接旨
Taizi --> Zhongshu: 太子转交中书
Zhongshu --> Menxia: 中书提交审议
Menxia --> Zhongshu: 门下封驳(可多次)
Menxia --> Assigned: 门下准奏
Assigned --> Doing: 尚书派发执行
Doing --> Review: 各部完成
Review --> Done: 皇上御批通过
Review --> Menxia: 皇上要求修改
Done --> [*]
Doing --> [*]: 手动取消
Review --> [*]: 业务终止

具体关键路径

✅ 理想路径（无阻滞，4-5天完成）

text
/* Detailed source-code truncated for AI context efficiency. */

❌ 挫折路径（含封驳和重试，6-7天）

text
DAY 2 同上

DAY 3 [封驳场景]：
  14:00 - 门下省审议完毕
          判定："方案不完整，缺少性能测试 + 压力测试"
          行为：🚫 封驳
          review_round += 1
          flow_log 记录："门下省 → 中书省：🚫 封驳（需补充性能测试）"
          state: Menxia → Zhongshu  # 返回中书修改
          自动派发 zhongshu agent（重新规划）

DAY 3-4：
  16:00 - 中书省收到封驳通知（唤醒agent）
          分析改进意见，补充性能测试方案
          progress："已整合性能测试需求，修正方案如下..."
          flow_log 记录："中书省 → 门下省：修订方案（第2轮审议）"
          state: Zhongshu → Menxia
          自动派发 menxia agent

  18:00 - 门下省重新审议
          判定："✅ 本次通过"
          flow_log 记录："门下省 → 尚书省：✅ 准奏通过（第2轮）"
          state: Menxia → Assigned → Doing
          后续同理想路径...

DAY 7：全部完成（比理想路径晚1-2天）

1.3 任务规格书与业务契约

Task Schema 字段说明

text
/* Detailed source-code truncated for AI context efficiency. */

业务契约

契约 含义 违反后果
不可越级 太子只能调中书，中书只能调门下/尚书，六部不能对外调用 超权调用被拒绝，系统自动拦截
状态单向递进 Pending → Taizi → Zhongshu → ... → Done，不能跳过或倒退 只能通过 review_action(reject) 返回上一步
门下必审 所有中书提出的方案都要门下省审议，无法跳过 中书不能直接转尚书，门下必入
一旦Done无改 任务进入Done/Cancelled后不能再修改状态 若需修改需要创建新任务或取消后重新建
task_id唯一性 JJC-日期-序号 全局唯一，同一天同一任务不重复建 看板防重，自动去重
资源消耗透明 每次进展汇报都要上报 tokens/cost/elapsed 便于成本核算和性能优化

🔧 第二部分：技术架构

2.1 状态机与自动派发

状态转移完整定义

python
_STATE_FLOW = {
    'Pending':  ('Taizi',   '皇上',    '太子',    '待处理旨意转交太子分拣'),
    'Taizi':    ('Zhongshu','太子',    '中书省',  '太子分拣完毕，转中书省起草'),
    'Zhongshu': ('Menxia',  '中书省',  '门下省',  '中书省方案提交门下省审议'),
    'Menxia':   ('Assigned','门下省',  '尚书省',  '门下省准奏，转尚书省派发'),
    'Assigned': ('Doing',   '尚书省',  '六部',    '尚书省开始派发执行'),
    'Next':     ('Doing',   '尚书省',  '六部',    '待执行任务开始执行'),
    'Doing':    ('Review',  '六部',    '尚书省',  '各部完成，进入汇总'),
    'Review':   ('Done',    '尚书省',  '太子',    '全流程完成，回奏太子转报皇上'),
}

每个状态自动关联 Agent ID（见 _STATE_AGENT_MAP）：

python
_STATE_AGENT_MAP = {
    'Taizi':    'taizi',
    'Zhongshu': 'zhongshu',
    'Menxia':   'menxia',
    'Assigned': 'shangshu',
    'Doing':    None,      # 从 org 推断（六部之一）
    'Next':     None,      # 从 org 推断
    'Review':   'shangshu',
    'Pending':  'zhongshu',
}

自动派发流程

当任务状态转移时（通过 handle_advance_state() 或审批），后台自动执行派发：

text
1. 状态转移触发派发
   ├─ 查表 _STATE_AGENT_MAP 得到目标 agent_id
   ├─ 若是 Doing/Next，从 task.org 查表 _ORG_AGENT_MAP 推断具体部门agent
   └─ 若无法推断则跳过派发（如 Done/Cancelled）

2. 构造派发消息（针对性促使Agent立即工作）
   ├─ taizi: "📜 皇上旨意需要你处理..."
   ├─ zhongshu: "📜 旨意已到中书省，请起草方案..."
   ├─ menxia: "📋 中书省方案提交审议..."
   ├─ shangshu: "📮 门下省已准奏，请派发执行..."
   └─ 六部: "📌 请处理任务..."

3. 后台异步派发（非阻塞）
   ├─ spawn daemon thread
   ├─ 标记 _scheduler.lastDispatchStatus = 'queued'
   ├─ 检查 Gateway 进程是否开启
   ├─ 运行 openclaw agent --agent {id} -m "{msg}" --deliver --timeout 300
   ├─ 重试最多2次（失败间隔5秒退避）
   ├─ 更新 _scheduler 状态和错误信息
   └─ flow_log 记录派发结果

4. 派发状态转移
   ├─ success: 立即更新 _scheduler.lastDispatchStatus = 'success'
   ├─ failed: 记录失败原因，Agent 超时不会 block 看板
   ├─ timeout: 标记 timeout，允许用户手动重试 / 升级
   ├─ gateway-offline: Gateway 未启动，跳过此次派发（后续可重试）
   └─ error: 异常情况，记录堆栈供调试

5. 到达目标Agent的处理
   ├─ Agent 从飞书消息收到通知
   ├─ 通过 kanban_update.py 与看板交互（更新状态/记录进展）
   └─ 完成工作后再次触发派发到下一个Agent

2.2 权限矩阵与Subagent调用

权限定义（openclaw.json 中配置）

json
{
  "agents": [
    {
      "id": "taizi",
      "label": "太子",
      "allowAgents": ["zhongshu"]
    },
    {
      "id": "zhongshu",
      "label": "中书省",
      "allowAgents": ["menxia", "shangshu"]
    },
    {
      "id": "menxia",
      "label": "门下省",
      "allowAgents": ["shangshu", "zhongshu"]
    },
    {
      "id": "shangshu",
      "label": "尚书省",
      "allowAgents": ["libu", "hubu", "bingbu", "xingbu", "gongbu", "libu_hr"]
    },
    {
      "id": "libu",
      "label": "礼部",
      "allowAgents": []
    },
    // ... 其他六部同样 allowAgents = [] ...
  ]
}

权限检查机制（代码层面）

在 dispatch_for_state() 之外，还有一套防御性的权限检查：

python
def can_dispatch_to(from_agent, to_agent):
    """检查 from_agent 是否有权调用 to_agent。"""
    cfg = read_json(DATA / 'agent_config.json', {})
    agents = cfg.get('agents', [])
    
    from_record = next((a for a in agents if a.get('id') == from_agent), None)
    if not from_record:
        return False, f'{from_agent} 不存在'
    
    allowed = from_record.get('allowAgents', [])
    if to_agent not in allowed:
        return False, f'{from_agent} 无权调用 {to_agent}（允许列表：{allowed}）'
    
    return True, 'OK'

权限违反示例与处理

场景 请求 结果 理由
正常 中书省 → 门下省审议 ✅ 允许 门下在中书的 allowAgents 中
违反 中书省 → 尚书省改方案 ❌ 拒绝 中书只能调门下/尚书，不能手工改尚书工作
违反 工部 → 尚书省 "我完成了" ✅ 改状态 通过 flow_log 和 progress_log（不是跨Agent调用）
违反 尚书省 → 中书省 "重新改方案" ❌ 拒绝 尚书不在门下/中书的 allowAgents 中
防控 Agent 伪造其他agent派发 ❌ 拦截 API 层验证 HTTP 请求来源/签名

2.3 数据融合：progress_log + session JSONL

现象

当任务执行时，有三层数据源：

text
1️⃣ flow_log
   └─ 纯粹记录状态转移（Zhongshu → Menxia）
   └─ 数据源：任务 JSON 的 flow_log 字段
   └─ 来自：Agent 通过 kanban_update.py flow 命令上报

2️⃣ progress_log
   └─ Agent 的实时工作汇报（文本进展、todos快照、资源消耗）
   └─ 数据源：任务 JSON 的 progress_log 字段
   └─ 来自：Agent 通过 kanban_update.py progress 命令上报
   └─ 周期：通常每30分钟或关键节点上报1次

3️⃣ session JSONL（新增！）
   └─ Agent 的内部思考过程（thinking）、工具调用（tool_result）、对话历史（user）
   └─ 数据源：~/.openclaw/agents/{agent_id}/sessions/*.jsonl
   └─ 来自：OpenClaw框架自动记录，Agent无需主动操作
   └─ 周期：消息级别，粒度最细

问题诊断

过去，只靠 flow_log + progress_log 展现进展：

  • ❌ 看不到Agent的具体思考过程
  • ❌ 看不到每次工具调用的结果
  • ❌ 看不到Agent中间的对话历史
  • ❌ Agent 表现出"黑盒状态"

例如：progress_log 记录"正在分析需求"，但用户看不到到底分析了什么。

解决方案：Session JSONL 融合

在 get_task_activity() 中新增融合逻辑（40行）：

text
/* Detailed source-code truncated for AI context efficiency. */

Session JSONL 格式解析

从 JSONL 中提取的条目，统一转换为看板活动条目：

python
def _parse_activity_entry(item):
    """将 session jsonl 的 message 统一解析成看板活动条目。"""
    msg = item.get('message', {})
    role = str(msg.get('role', '')).strip().lower()
    ts = item.get('timestamp', '')
    
    # 🧠 Assistant 角色 - Agent思考过程
    if role == 'assistant':
        entry = {
            'at': ts,
            'kind': 'assistant',
            'text': '...主回复...',
            'thinking': '💭 Agent考虑到...',  # 内部思维链
            'tools': [
                {'name': 'bash', 'input_preview': 'cd /src && npm test'},
                {'name': 'file_read', 'input_preview': 'dashboard/server.py'},
            ]
        }
        return entry
    
    # 🔧 Tool Result - 工具调用结果
    if role in ('toolresult', 'tool_result'):
        entry = {
            'at': ts,
            'kind': 'tool_result',
            'tool': 'bash',
            'exitCode': 0,
            'output': '✓ All tests passed (123 tests)',
            'durationMs': 4500  # 执行时长
        }
        return entry
    
    # 👤 User - 人工反馈或对话
    if role == 'user':
        entry = {
            'at': ts,
            'kind': 'user',
            'text': '请实现测试用例的异常处理'
        }
        return entry

融合后的活动流结构

单个任务的59条活动流（JJC-20260228-E2E 示例）：

text
kind    count  代表事件
────────────────────────────────────────────────
flow      10   状态转移链（Pending→Taizi→Zhongshu→...）
progress  11   Agent工作汇报（"正在分析"、"已完成"）
todos     11   待办任务快照（进度更新时每条）
user       1   用户反馈（如"需要补充性能测试"）
assistant 10   Agent思考过程（💭 reasoning chain）
tool_result 16   工具调用记录（bash运行结果、API调用结果）
────────────────────────────────────────────────
总计      59   完整工作轨迹

看板展示时，用户可以：

  • 📋 看流转链了解任务在哪个阶段
  • 📝 看 progress 了解Agent实时说了什么
  • ✅ 看 todos 了解任务拆解和完成进度
  • 💭 看 assistant/thinking 了解Agent的思考过程
  • 🔧 看 tool_result 了解每次工具调用的结果
  • 👤 看 user 了解是否有人工干预

2.4 调度系统：超时重试、停滞升级、自动回滚

调度元数据结构

python
_scheduler = {
    # 配置参数
    'enabled': True,
    'stallThresholdSec': 180,         # 停滞多久后自动升级（默认180秒）
    'maxRetry': 1,                    # 自动重试次数（0=不重试，1=重试1次）
    'autoRollback': True,             # 是否自动回滚到快照
    
    # 运行时状态
    'retryCount': 0,                  # 当前已重试几次
    'escalationLevel': 0,             # 0=无升级 1=门下协调 2=尚书协调
    'stallSince': None,               # 何时开始停滞的时间戳
    'lastProgressAt': '2026-03-01T...',  # 最后一次获得进展的时间
    'lastEscalatedAt': '2026-03-01T...',
    'lastRetryAt': '2026-03-01T...',
    
    # 派发追踪
    'lastDispatchStatus': 'success',  # queued|success|failed|timeout|gateway-offline|error
    'lastDispatchAgent': 'zhongshu',
    'lastDispatchTrigger': 'state-transition',
    'lastDispatchError': '',          # 错误堆栈（如有）
    
    # 快照（用于自动回滚）
    'snapshot': {
        'state': 'Assigned',
        'org': '尚书省',
        'now': '等待派发...',
        'savedAt': '2026-03-01T...',
        'note': 'scheduled-check'
    }
}

调度算法

每 60 秒运行一次 handle_scheduler_scan(threshold_sec=180)：

text
FOR EACH 任务:
  IF state in (Done, Cancelled, Blocked):
    SKIP  # 终态不处理
  
  elapsed_since_progress = NOW - lastProgressAt
  
  IF elapsed_since_progress < stallThreshold:
    SKIP  # 最近有进展，无需处理
  
  # ── 停滞处理逻辑 ──
  IF retryCount < maxRetry:
    ✅ 执行【重试】
    - increment retryCount
    - dispatch_for_state(task, new_state, trigger='taizi-scan-retry')
    - flow_log: "停滞180秒，触发自动重试第N次"
    - NEXT task
  
  IF escalationLevel < 2:
    ✅ 执行【升级】
    - nextLevel = escalationLevel + 1
    - target_agent = menxia (if L=1) else shangshu (if L=2)
    - wake_agent(target_agent, "💬 任务停滞，请介入协调推进")
    - flow_log: "升级至{target_agent}协调"
    - NEXT task
  
  IF escalationLevel >= 2 AND autoRollback:
    ✅ 执行【自动回滚】
    - restore task to snapshot.state
    - retryCount = 0
    - escalationLevel = 0
    - dispatch_for_state(task, snapshot.state, trigger='taiji-auto-rollback')
    - flow_log: "连续停滞，自动回滚到{snapshot.state}"

示例场景

场景：中书省Agent进程崩溃，任务卡在 Zhongshu

text
T+0:
  中书省正在规划方案
  lastProgressAt = T
  dispatch status = success

T+30:
  Agent 进程意外崩溃（或超载无响应）
  lastProgressAt 仍然 = T（没有新的 progress）

T+60:
  scheduler_scan 扫一遍，发现：
  elapsed = 60 < 180，跳过

T+180:
  scheduler_scan 扫一遍，发现：
  elapsed = 180 >= 180，触发处理
  
  ✅ 阶段1：重试
  - retryCount: 0 → 1
  - dispatch_for_state('JJC-20260228-E2E', 'Zhongshu', trigger='taizi-scan-retry')
  - 派发消息发送到中书省（唤醒agent或重启）
  - flow_log: "停滞180秒，自动重试第1次"

T+ 240:
  中书省 Agent 恢复（或手工重启），收到重试派发
  汇报进展："已恢复，继续规划..."
  lastProgressAt 更新为 T+240
  retryCount 重置为 0
  
  ✓ 问题解决

T+360 (若仍未恢复):
  scheduler_scan 再次扫，发现：
  elapsed = 360 >= 180, retryCount 已经 = 1
  
  ✅ 阶段2：升级
  - escalationLevel: 0 → 1
  - wake_agent('menxia', "💬 任务JJC-20260228-E2E停滞，中书省无反应，请介入")
  - flow_log: "升级至门下省协调"
  
  门下省Agent被唤醒，可以：
  - 检查中书省是否在线
  - 若在线，询问进度
  - 若离线，可能启动应急流程（如由门下暂代起草）

T+540 (若仍未解决):
  scheduler_scan 再次扫，发现：
  escalationLevel = 1, 还能升级到 2
  
  ✅ 阶段3：再次升级
  - escalationLevel: 1 → 2
  - wake_agent('shangshu', "💬 任务长期停滞，中书省+门下省都无法推进，尚书省请介入协调")
  - flow_log: "升级至尚书省协调"

T+720 (若仍未解决):
  scheduler_scan 再次扫，发现：
  escalationLevel = 2（已最大），autoRollback = true
  
  ✅ 阶段4：自动回滚
  - snapshot.state = 'Assigned' (前一个稳定状态)
  - task.state: Zhongshu → Assigned
  - dispatch_for_state('JJC-20260228-E2E', 'Assigned', trigger='taizi-auto-rollback')
  - flow_log: "连续停滞，自动回滚到Assigned，由尚书省重新派发"
  
  结果：
  - 尚书省重新派发给六部执行
  - 中书省的方案保留在前一个 snapshot 版本中
  - 用户可以看到回滚操作，决定是否介入

🎯 第三部分：核心API与CLI工具

3.1 任务操作API端点

任务创建：`POST /api/create-task`

text
请求：
{
  "title": "为三省六部编写完整自动化测试方案",
  "org": "中书省",           // 可选，默认太子
  "official": "中书令",      // 可选
  "priority": "normal",
  "template_id": "test_plan", // 可选
  "params": {},
  "target_dept": "兵部+刑部"  // 可选，派发建议
}

响应：
{
  "ok": true,
  "taskId": "JJC-20260228-001",
  "message": "旨意 JJC-20260228-001 已下达，正在派发给太子"
}

任务活动流：`GET /api/task-activity/{task_id}`

text
/* Detailed source-code truncated for AI context efficiency. */

状态推进：`POST /api/advance-state/{task_id}`

text
请求：
{
  "comment": "任务分明该推进了"
}

响应：
{
  "ok": true,
  "message": "JJC-20260228-E2E 已推进到下一阶段 (已自动派发 Agent)",
  "oldState": "Zhongshu",
  "newState": "Menxia",
  "targetAgent": "menxia"
}

审批操作：`POST /api/review-action/{task_id}`

text
请求（准奏）：
{
  "action": "approve",
  "comment": "方案可行，已采纳改进建议"
}

OR 请求（封驳）：
{
  "action": "reject",
  "comment": "需补充性能测试，第N轮审议"
}

响应：
{
  "ok": true,
  "message": "JJC-20260228-E2E 已准奏 (已自动派发 Agent)",
  "state": "Assigned",
  "reviewRound": 1
}

3.2 CLI工具：kanban_update.py

Agent 通过此工具与看板交互，共7个命令：

命令1：创建任务（太子或中书手工）

bash
python3 scripts/kanban_update.py create \
  JJC-20260228-E2E \
  "为三省六部编写完整自动化测试方案" \
  Zhongshu \
  中书省 \
  中书令

# 说明：通常不需要手工运行（看板API自动触发），除非debug

命令2：更新状态

bash
python3 scripts/kanban_update.py state \
  JJC-20260228-E2E \
  Menxia \
  "方案提交门下省审议"

# 说明：
# - 第一个参数：task_id
# - 第二个参数：新状态（Pending/Taizi/Zhongshu/...）
# - 第三个参数：可选，描述信息（会记录到 now 字段）
# 
# 效果：
# - task.state = Menxia
# - task.org 自动推断为 "门下省"
# - 触发派发 menxia agent
# - flow_log 记录转移

命令3：添加流转记录

bash
python3 scripts/kanban_update.py flow \
  JJC-20260228-E2E \
  "中书省" \
  "门下省" \
  "📋 方案提交审核，请审议"

# 说明：
# - 参数1：task_id
# - 参数2：from_dept（谁在上报）
# - 参数3：to_dept（流转到谁）
# - 参数4：remark（备注，可包含emoji）
#
# 注意：只是记录 flow_log，不改变 task.state
#（多用于细节流转，如部门间的协调）

命令4：实时进展汇报（重点！）

bash
python3 scripts/kanban_update.py progress \
  JJC-20260228-E2E \
  "已完成需求分析和方案初稿，现正征询工部意见" \
  "1.需求分析✅|2.方案设计✅|3.工部咨询🔄|4.待门下审议"

# 说明：
# - 参数1：task_id
# - 参数2：进展文本说明
# - 参数3：todos 当前快照（用 | 分隔各项，支持emoji）
#
# 效果：
# - progress_log 添加新条目：
#   {
#     "at": now_iso(),
#     "agent": inferred_agent_id,
#     "text": "已完成需求分析和方案初稿，现正征询工部意见",
#     "state": task.state,
#     "org": task.org,
#     "todos": [
#       {"id": "1", "title": "需求分析", "status": "completed"},
#       {"id": "2", "title": "方案设计", "status": "completed"},
#       {"id": "3", "title": "工部咨询", "status": "in-progress"},
#       {"id": "4", "title": "待门下审议", "status": "not-started"}
#     ],
#     "tokens": (自动从 openclaw 会话数据读取),
#     "cost": (自动计算),
#     "elapsed": (自动计算)
#   }
#
# 看板效果：
# - 即时渲染为活动条目
# - todos 进度条更新（67% 完成）
# - 资源消耗累加显示

命令5：任务完成

bash
python3 scripts/kanban_update.py done \
  JJC-20260228-E2E \
  "https://github.com/org/repo/tree/feature/auto-test" \
  "自动化测试方案已完成，涵盖单元/集成/E2E三层，通过率98.5%"

# 说明：
# - 参数1：task_id
# - 参数2：output URL（可以是代码仓库、文档链接等）
# - 参数3：最终总结
#
# 效果：
# - task.state = Done（从 Review 推进）
# - task.output = "https://..."
# - 自动发送Feishu消息给皇上（太子转报）
# - flow_log 记录完成转移

命令6 & 7：停止/取消任务

bash
# 叫停（随时可恢复）
python3 scripts/kanban_update.py stop \
  JJC-20260228-E2E \
  "等待工部反馈继续"

# 说明：
# - task.state 暂存（_prev_state）
# - task.block = "等待工部反馈继续"
# - 看板显示 "⏸️ 已叫停"
#
# 恢复：
python3 scripts/kanban_update.py resume \
  JJC-20260228-E2E \
  "工部已反馈，继续执行"
#
# - task.state 恢复到 _prev_state
# - 重新派发 agent

# 取消（不可恢复）
python3 scripts/kanban_update.py cancel \
  JJC-20260228-E2E \
  "业务需求变更，任务作废"
#
# - task.state = Cancelled
# - flow_log 记录取消原因

💡 第四部分：对标与对比

CrewAI / AutoGen 的传统方式 vs 三省六部的制度化方式

维度 CrewAI AutoGen 三省六部
协作模式 自由讨论（Agent自主选择协作对象） 面板+回调（Human-in-the-loop） 制度化协作（权限矩阵+状态机）
质量保障 依赖Agent智能（无审核） Human审核（频繁中断） 自动审核（门下省必审）+可干预
权限控制 ❌ 无 ⚠️ Hard-coded ✅ 配置化权限矩阵
可观测性 低（Agent消息黑盒） 中（Human看到对话） 极高（59条活动/任务）
可干预性 ❌ 无（跑起来后很难叫停） ✅ 有（需要人工批准） ✅ 有（一键stop/cancel/advance）
任务分发 不确定（Agent自主选） 确定（Human手工分） 自动确定（权限矩阵+状态机）
吞吐量 1任务1Agent（串行讨论） 1任务1Team（需人工管理） 多任务并行（六部同时执行）
失败恢复 ❌（重新开始） ⚠️（需人工调试） ✅（自动重试3阶段）
成本控制 不透明（没有成本上限） 中等（Human可叫停） 透明（每条progress上报成本）

业务契约的严格性

CrewAI 的"温和"方式

python
# Agent可以自由选择下一步工作
if task_seems_done:
    # Agent自己决定要不要报告给其他Agent
    send_message_to_someone()  # 可能发错人，可能重复

三省六部的"严格"方式

python
# 任务状态严格受限，下一步由系统决定
if task.state == 'Zhongshu' and agent_id == 'zhongshu':
    # 只能做Zhongshu该做的事（起草方案）
    deliver_plan_to_menxia()
    
    # 状态转移只能通过API，不能绕过
    # 中书不能直接转尚书，必须经过门下审议
    
    # 若想绕过门下审议
    try:
        dispatch_to(shangshu)  # ❌ 权限检查拦截
    except PermissionError:
        log.error(f'zhongshu 无权越权调用 shangshu')

🔍 第五部分：故障场景与恢复机制

场景1：Agent进程崩溃

text
症状：任务卡在某个状态，180秒无新进展
报警：太子调度系统检测到停滞

自动处理流程：
  T+0: 崩溃
  T+180: scan 检测到停滞
    ✅ 第1阶段：自动重试
       - 派发消息到agent（唤醒或重启）
       - 如果agent恢复，流程继续
  
  T+360: 若仍未恢复
    ✅ 第2阶段：升级协调
       - 唤醒门下省agent
       - 汇报："中书省无响应，请介入"
       - 门下可能接管或代理工作
  
  T+540: 若仍未恢复
    ✅ 第3阶段：再次升级
       - 唤醒尚书省agent
       - 汇报："任务彻底卡住，请企业级协调"
  
  T+720: 若仍未恢复
    ✅ 第4阶段：自动回滚
       - 恢复到前一个稳定状态
       - 派发给尚书省重新处理
       - 用户可看到完整回滚链路

场景2：Agent作恶（伪造数据）

假设 zhongshu agent 想骗过系统：

python
# 尝试伪造门下省的准奏（直接改JSON）
task['flow_log'].append({
    'from': '门下省',      # ❌ 假冒身份
    'to': '尚书省',
    'remark': '✅ 准奏'
})

# 系统防御：
# 1. 权限验证：API 层检查 HTTP 请求者身份
#    ├─ 来自 zhongshu agent 的请求不能直接 flow
#    ├─ 必须通过 flow_log 记录，且签名验证
#    └─ 签名不匹配则拒绝
# 2. 状态机验证：状态转移受控
#    ├─ 即使 flow_log 被篡改，state 仍然是 Zhongshu
#    ├─ 下一步只能由 gate-keeper 系统转移
#    └─ zhongshu 无权自己改 state

# 结果：❌ Agent 的伪造被系统拦截

场景3：业务流程违反（如中书越权调尚书改方案）

python
# 中书省想绕过门下审议，直接咨询尚书省
try:
    result = dispatch_to_agent('shangshu', '请帮我审查一下这个方案')
except PermissionError:
    # ❌ 权限矩阵拦截
    log.error('zhongshu 无权调用 shangshu (仅限: menxia, shangshu)')

# 门下省想升级到皇上
try:
    result = dispatch_to_agent('taizi', '我需要皇上的指示')
except PermissionError:
    # ❌ 权限矩阵拦截
    log.error('menxia 无权调用 taizi')

📊 第六部分：监控与可观测性

看板的10个视图面板

text
1. 全任务列表
   └─ 所有任务的汇总视图（按创建时间倒序）
   └─ 快速过滤：活跃/完成/已封驳

2. 按状态分类
   ├─ Pending（待处理）
   ├─ Taizi（太子分拣中）
   ├─ Zhongshu（中书规划中）
   ├─ Menxia（门下审议中）
   ├─ Assigned（尚书派发中）
   ├─ Doing（六部执行中）
   ├─ Review（尚书汇总中）
   └─ Done/Cancelled（已完成/已取消）

3. 按部门分类
   ├─ 太子任务
   ├─ 中书省任务
   ├─ 门下省任务
   ├─ 尚书省任务
   ├─ 六部任务（并行视图）
   └─ 已派发任务

4. 按优先级分类
   ├─ 🔴 Critical（紧急）
   ├─ 🟠 High（高优）
   ├─ 🟡 Normal（普通）
   └─ 🔵 Low（低优）

5. Agent 在线状态
   ├─ 🟢 运行中（正在处理任务）
   ├─ 🟡 待命（最近有活动，闲置）
   ├─ ⚪ 空闲（超过10分钟无活动）
   ├─ 🔴 离线（Gateway 未启动）
   └─ ❌ 未配置（工作空间不存在）

6. 任务详情面板
   ├─ 基本信息（标题、创建人、优先级）
   ├─ 完整活动流（flow_log + progress_log + session）
   ├─ 阶段耗时统计（各Agent停留时间）
   ├─ Todos 进度条
   └─ 资源消耗（tokens/cost/elapsed）

7. 停滞任务监控
   ├─ 列出所有超过阈值未推进的任务
   ├─ 显示停滞时长
   ├─ 快速操作：重试/升级/回滚

8. 审批工单池
   ├─ 清单所有在 Menxia 等待审批的任务
   ├─ 按停留时长排序
   ├─ 一键准奏/封驳

9. 今日概览
   ├─ 今日新建任务数
   ├─ 今日完成任务数
   ├─ 平均流转时长
   ├─ 各Agent活动频率

10. 历史报表
    ├─ 周报（人均产出、平均周期）
    ├─ 月报（部门协作效率）
    └─ 成本分析（API调用成本、Agent工作量）

实时API：Agent 在线检测

text
GET /api/agents-status

响应：
{
  "ok": true,
  "gateway": {
    "alive": true,           // 进程存在
    "probe": true,          // HTTP 响应正常
    "status": "🟢 运行中"
  },
  "agents": [
    {
      "id": "taizi",
      "label": "太子",
      "status": "running",        // running|idle|offline|unconfigured
      "statusLabel": "🟢 运行中",
      "lastActive": "03-02 14:30", // 最后活跃时间
      "lastActiveTs": 1708943400000,
      "sessions": 42,             // 活跃session数
      "hasWorkspace": true,
      "processAlive": true
    },
    // ... 其他agent ...
  ]
}

🎓 第七部分：使用示例与最佳实践

完整案例：创建→分发→执行→完成

text
/* Detailed source-code truncated for AI context efficiency. */

📋 总结

三省六部是一个制度化的AI多Agent系统，不是传统的"自由讨论"框架。它通过：

  1. 业务层：模仿古代帝国官僚体系，建立分权制衡的组织结构
  2. 技术层：状态机 + 权限矩阵 + 自动派发 + 调度重试，确保流程可控
  3. 观测层：React 看板 + 完整活动流（59条/任务），实时掌握全局
  4. 介入层：一键stop/cancel/advance，遇到异常能立即纠正

核心价值：用制度确保质量，用透明确保信心，用自动化确保效率。

相比 CrewAI/AutoGen 的"自由+人工管理"，三省六部提供了一套企业级的AI协作框架。

Workflow state vs execution ownership

In Edict workflows, workflow state and execution ownership are related but not always identical.

Workflow state

Workflow state describes the current institutional stage of a task, for example:

  • Taizi
  • Zhongshu
  • Menxia
  • Assigned
  • Doing
  • Review
  • Done

This is the stage shown in the board/UI and reflects where the task is in the intended process.

Execution ownership

Execution ownership means which actual runtime agent/session currently owns the next action or is writing the next progress/log update.

In simple flows, workflow state and execution ownership may appear to match.

In more complex or multi-stage flows, they can temporarily diverge. For example:

  • the workflow state may already show Assigned
  • while the active runtime execution context is still tied to an earlier stage's dispatch chain

Why this distinction matters

This distinction is useful when:

  • debugging handoff behavior
  • understanding why a later-stage label appears before a fully isolated execution handoff occurs
  • reasoning about future improvements such as stage-isolated orchestration

In short:

  • workflow state = where the task is in the institutional process
  • execution ownership = which runtime path currently holds the next action

This documentation does not change runtime semantics. It only clarifies an important concept for advanced real-world usage.

Wechat (`docs/wechat.md`)

📮 朕的邸报——公众号「cft0808」

古有邸报传天下政令，今有公众号聊 AI 架构。

🤔 关注了能看到什么？

🏛️ 架构拆解系列

三省六部不是 metaphor，是真的分权制衡。公众号里你能看到：

  • 为什么门下省是杀手锏 —— 以及它封驳了多少次中书省的方案
  • 太子凭什么当分拣员 —— Intent Detection 的古今之辩
  • 六部并行为啥不打架 —— 从唐代到 goroutine 的并发智慧
  • SOUL.md 人设怎么写 —— 让 AI 入戏的 prompt 炼丹术

🔥 踩坑复盘

做 12 个 Agent 协作，每天都有惊喜（惊吓）：

  • ✍️ Agent A 给 Agent B 发消息，B 说"朕不认识你"
  • 🔥 Token 烧了 $50，结果门下省把方案驳回了三次
  • 🐛 尚书省派发任务，六部全体罢工——原来 agent ID 写错了
  • 💀 install.sh 把用户自定义的龙虾官角色覆盖了……

这些都是真实 Issue，文章里逐条复盘怎么修的。

💡 Token 省钱术

大家最关心的问题：这玩意儿 token 不得烧穿？

公众号里会分享：

  • 用 Claude 内置 cache 砍掉 80% SOUL.md 重复读取
  • 「快速通道」机制：简单任务跳过门下省审核
  • 按需启动 Agent，不轮询不烧钱
  • 精简 SOUL.md：1000 字以内搞定一个高质量角色

🎭 彩蛋 & 幕后

  • 六部的 SOUL.md 人设是怎么设计的？
  • "锦衣卫监察百官" 功能会做吗？（会的）
  • 为什么叫"三省六部"而不是"六扇门"？
  • 朕（作者）日常怎么跟 12 个 AI 斗智斗勇

📝 已发表文章

日期 标题 亮点
2026.03 三省六部 · 250 Star 里程碑复盘 5 个 Issue + 20 条评论逐一回应，Token 优化方案

持续更新中，欢迎催更 ⚔️

💬 你也可以在公众号里

  • 🗣️ 提问 —— 安装踩坑、架构疑惑、Token 焦虑，有问必答
  • 🐛 报 Bug —— 不想开 Issue？直接留言也行，朕都会看
  • 💡 提建议 —— "能不能加个后宫系统？" 可以，但先排队
  • 🤝 交朋友 —— 一起研究怎么让 AI 上朝更高效

Wechat Article (`docs/wechat-article.md`)

我用三省六部制重新设计了 AI 多 Agent 协作架构

1300 年前的制度设计，比现代 AI 框架更懂分权。

一、一个奇怪的想法

去年底我开始重度使用 AI Agent 干活——写代码、做分析、生成文档。用的是市面上最火的几个多 Agent 框架。

用了一个月，我发现一个根本性的问题：

这些框架没有"审核"这个概念。

CrewAI 的模式是：几个 Agent 各自干活，做完就交。AutoGen 好一点，有个 Human-in-the-loop，但本质上是你自己当 QA。MetaGPT 有角色分工，但审核是可选的。

就像一家公司没有 QA 部门，工程师写完代码直接部署到线上。

然后你拿到最终结果，不知道中间发生了什么，无法复现，无法审计，无法干预。出了问题只能重跑。

我一直在想：有没有一种架构，天然就把审核嵌入到流程里，不是可选的插件，而是必须经过的关卡？

然后有一天，我在翻《资治通鉴》的时候突然想到——

三省六部制。

唐太宗在 1300 年前就设计了这个制度：中书省草拟政令，门下省审议封驳，尚书省执行。三个部门互相制衡，任何政令必须经过审议才能下发。

这不就是我要找的架构吗？

▲ 每天第一次打开看板，会有一个"上朝"开场动画——仪式感拉满

二、古人的架构设计

三省六部制不是一个 metaphor，它是一套经过 1400 年实践检验的分权制衡系统。

简化一下，信息流是这样的：

text
皇上（你）
  ↓ 下旨
中书省（规划）  ← 把你的一句话拆成可执行的子任务
  ↓ 提交审核
门下省（审议）  ← 审查方案质量，不行就封驳打回
  ↓ 准奏
尚书省（派发）  ← 分配给六部执行
  ↓
六部（执行）    ← 户部管数据、礼部管文档、兵部管开发、刑部管合规、工部管基建
  ↓
尚书省汇总回奏  ← 结果回报给你

注意这里最关键的一步：门下省审议。

中书省规划完方案后，不是直接扔给执行层——必须先经过门下省审议。门下省会检查：

  • 子任务拆解是否合理？有没有遗漏需求？
  • 部门分配是否准确？该派兵部的是不是错派给了礼部？
  • 方案是否可执行？有没有不切实际的地方？

如果不合格，门下省可以封驳——直接打回让中书省重新规划。不是一个 warning，是强制返工。

这就是为什么唐朝能运转 289 年。不受制约的权力必然会出错，唐太宗想得很清楚。

三、我把它做成了开源项目

我用 OpenClaw 搭了一个真正的三省六部系统。9 个 AI Agent 各司其职，严格按照权限矩阵通信。

项目叫 Edict（三省六部），已开源：

GitHub：https://github.com/cft0808/edict

核心架构很简单：

  • 中书省：接旨（你的指令），规划方案，拆解子任务
  • 门下省：审议方案，质量把关，不合格直接封驳
  • 尚书省：准奏后派发给六部，协调执行，汇总结果
  • 六部：户部（数据分析）、礼部（文档撰写）、兵部（代码开发）、刑部（安全合规）、工部（CI/CD 部署）
  • 早朝官：每天给你推一份新闻简报

每个 Agent 有独立的 Workspace、独立的 Skills、独立的 LLM 模型。严格的权限矩阵——谁能给谁发消息，白纸黑字：

谁 ↓ 给谁发 → 中书 门下 尚书 六部
中书省 — ✅ ✅ ❌
门下省 ✅ — ✅ ❌
尚书省 ✅ ✅ — ✅
六部 ❌ ❌ ✅ ❌

中书省不能直接指挥六部，六部不能越级上报中书省。所有的跨层通信必须经过尚书省中转。

这不是装饰性的设定，这是架构层面的强制约束。

▲ 30 秒 Demo：从上朝仪式到旨意看板、奏折归档、模型配置的完整巡览

四、跟现有框架对比

你可能会问：跟 CrewAI、AutoGen 比，差在哪？

CrewAI AutoGen 三省六部
审核机制 ❌ ⚠️ 可选 ✅ 门下省强制审核
实时看板 ❌ ❌ ✅ 10 个面板
任务干预 ❌ ❌ ✅ 叫停 / 取消 / 恢复
流转审计 ⚠️ ❌ ✅ 完整奏折存档
Agent 健康监控 ❌ ❌ ✅ 心跳检测
热切换 LLM ❌ ❌ ✅ 看板内一键切换

最核心的差异是门下省审核机制。

这不是 Human-in-the-loop（那是让你自己当 QA），这是一个专职的 AI Agent 负责审核另一个 AI Agent 的产出。制度性的，强制的，架构级别的。

一个不经审核的 AI 协作系统，就像一个没有代码 review 的团队——跑得快，翻车也快。

五、军机处看板——让一切可观测

光有架构不够，你还得看得见。

所以我做了一个军机处看板——一个实时监控所有任务流转的 Web 面板。零依赖，单文件 HTML，Python 标准库后端，打开浏览器就能用。

10 个功能面板：

📋 旨意看板：所有任务以卡片形式展示，按状态分列，支持过滤搜索。每张卡片有心跳徽章——🟢 活跃、🟡 停滞、🔴 告警。点开看完整的流转时间线，随时可以叫停或取消。

▲ 旨意看板：任务卡片按状态分列，心跳徽章一目了然

🔭 省部调度：可视化各状态的任务数量、部门分布、Agent 健康卡片。一眼看清谁在忙、谁在闲、谁宕机了。

▲ 省部调度：状态分布 + 部门负载 + Agent 健康卡片

📜 奏折阁：所有已完成的旨意自动归档为"奏折"，展示完整的五阶段时间线——圣旨→中书规划→门下审议→六部执行→回奏。一键复制为 Markdown。

▲ 奏折阁：完整的五阶段时间线，一键导出 Markdown

📜 旨库：9 个预设圣旨模板。选一个，填参数，预览，一键下旨。覆盖：周报生成、代码审查、API 设计、竞品分析等常见场景。

▲ 旨库：9 个预设模板，填参数一键下旨

⚙️ 模型配置：每个 Agent 可以独立切换 LLM 模型。中书省用 Claude 做规划，兵部用 GPT-4o 写代码，户部用 DeepSeek 算数据——各取所长。

▲ 模型配置：每个 Agent 独立切换 LLM，各取所长

还有官员总览（Token 消耗排行榜）、技能管理、天下要闻（自动新闻聚合）、会话监控、上朝仪式（每天首次打开的彩蛋动画）。

全部零依赖，没有 React 也没有 Vue，纯 HTML + CSS + JavaScript，2200 行搞定。

▲ 官员总览：Token 消耗排行榜 + 活跃度统计

▲ 天下要闻：每日自动聚合科技/财经资讯

六、跑一个真实案例给你看

光说不练不行。来看一个真实的运行记录——让三省六部分析竞品。

旨意：分析 CrewAI、AutoGen 和 LangGraph 这三个框架的差异，输出对比报告。

▲ 点开任意任务卡片，可以看到完整的流转链和实时状态

中书省规划（45 秒）

中书省接旨后，拆成了 4 个子任务：

  1. 兵部 → 架构与通信机制调研
  2. 户部 → 数据采集与量化对比（GitHub Stars、Contributors 等）
  3. 兵部 → 开发者体验深度评测
  4. 礼部 → 汇总写对比报告

门下省审议（32 秒）—— 封驳了！

门下省第一轮直接打回：

"方案有三个问题：1）旨意明确要求评测'可观测性'，但规划里没有对应子任务；2）子任务 1 和 3 都是兵部调研，有重叠，建议合并；3）缺少推荐场景的结论性子任务——分析没有结论等于没分析。驳回。"

中书省修改方案后，门下省第二轮准奏。

这就是门下省的价值。 如果没有这一步，兵部会做两次调研，最终报告里也不会有推荐场景——因为原始规划里就没要求。

各部执行（17 分钟）

  • 兵部：技术深度对比，覆盖架构、通信、可观测性三维度
  • 户部：量化数据表——Stars、Contributors、Issue 响应时间、Hello World 搭建时长
  • 礼部：整合兵部 + 户部数据，撰写最终报告

回奏

22 分钟，15800 Token，一份结构化对比报告。结论很有意思：

场景 推荐 理由
快速原型 CrewAI 上手最快
对话式协作 AutoGen 天然适合多轮讨论
复杂工作流 LangGraph 状态机最灵活
可靠性优先 三省六部 唯一内置强制审核

七、技术上的一些选择

做这个项目的时候，我做了几个刻意的技术决策：

1. 零依赖

看板前端是一个 HTML 文件，2200 行，没有用任何框架。后端是 Python 标准库的 http.server，没有 Flask 也没有 FastAPI。

为什么？因为我不想让人跑之前先 pip install 一堆东西。这个项目的目标用户可能只是想快速体验一下三省六部的流转效果，不想搭环境。

2. 每个 Agent 一个 SOUL.md

每个 Agent 的人格、职责、工作流规则都写在一个 Markdown 文件里。想修改门下省的审核标准？编辑 agents/menxia/SOUL.md，下次启动自动生效。

这意味着你可以定制自己的三省六部——也许你的"兵部"不是负责工程，而是负责市场分析。改个 SOUL.md 就行。

3. 权限矩阵是强制的

不是"建议"Agent 之间不要越级通信，是在架构层面强制限制。六部不能给中书省发消息，中书省不能绕过门下省直接让尚书省执行。OpenClaw 的配置文件里白纸黑字写着谁能跟谁说话。

八、现在你可以试了

项目已经开源，MIT 协议。

GitHub：https://github.com/cft0808/edict

最快的体验方式：

bash
# Docker 一行启动
docker run -p 7891:7891 cft0808/edict

# 打开浏览器
open http://localhost:7891

如果你装了 OpenClaw，可以完整安装：

bash
git clone https://github.com/cft0808/edict.git
cd edict
chmod +x install.sh && ./install.sh

安装脚本自动创建 9 个 Agent Workspace、写入人格文件、注册权限矩阵、重启 Gateway。

▲ 技能管理：各省部已安装的 Skills 一览，可查看详情和添加新技能

九、下一步

Phase 1（核心架构）已经完成了。接下来要做的几件事：

  • 御批模式：让门下省的审议结果可以推送到你的飞书/Telegram，你亲自决定准奏还是封驳
  • 功过簿：每个 Agent 的绩效评分——完成率、返工率、耗时统计
  • 急递铺：看板里加一个实时的 Agent 通信流向图——中书省发消息给门下省的时候，连线亮一下
  • 国史馆：把历史旨意和奏折沉淀成知识库，新旨意可以参考历史经验

完整 Roadmap 在 GitHub 上，Phase 2 和 Phase 3 的每个子项都标了难度，欢迎认领。

最后

AI Agent 协作的核心问题不是"让 Agent 更聪明"，而是"让 Agent 的协作有规矩"。

CrewAI 解决了"多个 Agent 一起干活"的问题。AutoGen 解决了"Agent 之间能对话"的问题。

但谁来解决"Agent 的产出质量有保障"的问题？

唐太宗在 1300 年前就给出了答案：分权制衡。规划的不审核，审核的不执行，执行的不规划。每一个环节都有人盯着，每一个决策都要经过审议。

这可能是我见过的、最优雅的"AI 治理"方案——因为它根本不是为 AI 设计的。

它是为治理本身设计的。

GitHub：https://github.com/cft0808/edict

开源 · MIT · 欢迎 Star ⚔️

--- METRICS ---

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#ai-agents Browse ai-agents catalog → #ai-orchestration Browse ai-orchestration catalog → #autonomous-agents Browse autonomous-agents catalog → #claude Browse claude catalog → #dashboard Browse dashboard catalog → #kanban Browse kanban catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →