三省六部制 AI 多智能体编排系统：用古代官制设计现代 Agent 协作架构

当西方还在追逐 CrewAI、AutoGen 时，一个基于唐朝官制的 Multi-Agent 系统悄然登顶 GitHub Trending——12个AI Agent 模拟古代朝廷运作，分权制衡、专职审核、完全可观测。这不是复古情怀，而是经过1400年实践检验的协作智慧。

一、背景：多 Agent 协作的困境与破局

1.1 现有 Multi-Agent 框架的痛点

2026年，AI Agent 已经从"玩具"进化为"工具"，但当我们尝试用多个 Agent 协作完成复杂任务时，常常会遇到这些问题：

问题1：缺乏有效审核机制

现有的 Multi-Agent 框架（如 CrewAI、AutoGen）通常采用"流水线"或"层级"模式：

• CrewAI：顺序执行，前一个Agent的输出直接传给下一个
• AutoGen：群聊模式，Agent之间自由对话

这两种模式都有一个致命缺陷：没有强制审核环节。如果某个Agent产生了错误输出，后续Agent会"将错就错"，导致最终结果偏离预期。

问题2：权限边界模糊

在大多数框架中，Agent之间的通信权限是"扁平"的：

• 任何Agent都可以调用任何其他Agent
• 没有明确的"谁能给谁发消息"的规则
• 导致调试时无法确定问题出在哪个环节

问题3：可观测性不足

当任务执行失败时：

• 难以追溯是哪个Agent出了问题
• 无法"回滚"到中间状态重新执行
• 缺乏细粒度的日志和审计 trail

1.2 为什么是"三省六部制"？

面对这些困境，开发者 mvanhorn 从中国古代的三省六部制找到了灵感。

三省六部制的核心设计理念：

• 分权制衡：决策、审核、执行三权分立
• 专职专用：每个部门只做自己擅长的事
• 流程可追溯：政令从起草到执行，每个环节都有记录

这不就是我们需要的 Multi-Agent 协作模式吗？

二、核心概念：当古代官制遇见现代 AI

2.1 三省六部制的历史背景

三省六部制起源于隋朝，成熟于唐朝，是中国封建社会历时最长、最完备的中央官制：

三省（决策层）：

• 中书省：负责起草政令（决策）
• 门下省：负责审核封驳（审核）
• 尚书省：负责执行派发（执行）

六部（执行层）：

• 吏部：人事管理
• 户部：财政收支
• 礼部：礼仪外交
• 兵部：军事国防
• 刑部：司法审计
• 工部：工程建设

核心运作流程：

皇帝下旨 → 太子分拣 → 中书省起草 → 门下省审核 → 尚书省派发 → 六部执行 → 尚书省回奏 → 皇帝

任何政令必须经过门下省审核，如果审核不通过，会被"封驳"（打回重写）。

2.2 映射到 AI Agent 系统

Edict 项目将这套制度完美映射到了 Multi-Agent 系统：

2.3 为什么这套制度有效？

1. 强制审核，防止"带病执行"

在现有框架中，如果规划Agent产生了错误计划，执行Agent会直接执行。而在 Edict 中：

• 中书省（规划）产出计划后，必须经过门下省（审核）
• 门下省有权"封驳"：如果计划不合理，直接打回中书省重写
• 只有审核通过的计划，才会被派发执行

这就像是代码审查（Code Review）的自动化版本。

2. 权限矩阵，明确"谁能给谁发消息"

Edict 实现了一个严格的权限矩阵：

# 权限矩阵示例（简化版）
PERMISSION_MATRIX = {
    "taizi": ["zhongshu"],           # 太子只能给中书省发消息
    "zhongshu": ["menxia"],          # 中书省只能给门下省发消息
    "menxia": ["zhongshu", "shangshu"],  # 门下省可以打回中书省，或放行给尚书省
    "shangshu": ["libu", "hubu", "libu", "bingbu", "xingbu", "gongbu"],  # 尚书省派发给六部
    # ... 六部只能给尚书省回奏
}

这意味着：

• 兵部（代码执行）不能直接给中书省（规划）发消息
• 如果任务失败，必须沿原路返回，不能"越级上访"

3. 实时看板，任务全生命周期可观测

Edict 提供了一个实时看板（Web Dashboard），展示：

• 当前所有任务的执行状态
• 每个Agent的工作负载
• 任务流转的历史记录
• 审核不通过的理由

这就像是给Multi-Agent系统装了一个"黑匣子"。

三、架构分析：12 个 Agent 的协作流程

3.1 系统架构图

┌─────────────────────────────────────────────────────────────┐
│                        用户（皇帝）                          │
│                     下达任务指令                             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   太子 Agent (Taizi)                        │
│   • 判断任务类型（闲聊 / 正式指令）                          │
│   • 闲聊：直接回复                                          │
│   • 正式指令：提炼标题，转交中书省                            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                 中书省 Agent (Zhongshu)                     │
│   • 接收任务指令                                            │
│   • 拆解为可执行的子任务                                     │
│   • 生成执行计划（JSON格式）                                 │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                 门下省 Agent (Menxia)                       │
│   • 审核执行计划                                            │
│   • 检查：逻辑合理性、资源可行性、安全风险                     │
│   • 通过 → 转交尚书省                                       │
│   • 不通过 → 封驳，返回修改意见给中书省                       │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼ (审核通过)
┌─────────────────────────────────────────────────────────────┐
│                 尚书省 Agent (Shangshu)                     │
│   • 接收审核通过的计划                                        │
│   • 根据任务类型派发给对应六部                                │
│   • 汇总六部的执行结果                                       │
│   • 回奏给用户                                              │
└─────────────────────────────────────────────────────────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
       ┌──────────┐    ┌──────────┐    ┌──────────┐
       │ 吏部 Agent│    │ 户部 Agent│    │ 礼部 Agent│
       │ (技能管理)│    │ (数据处理)│    │ (文档编写)│
       └──────────┘    └──────────┘    └──────────┘
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
       ┌──────────┐    ┌──────────┐    ┌──────────┐
       │ 兵部 Agent│    │ 刑部 Agent│    │ 工部 Agent│
       │ (代码执行)│    │ (安全审计)│    │ (部署运维)│
       └──────────┘    └──────────┘    └──────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                     用户（皇帝）                             │
│                   接收执行结果                               │
└─────────────────────────────────────────────────────────────┘

3.2 核心组件详解

3.2.1 太子 Agent（分拣层）

职责：

• 接收用户输入
• 判断输入类型：
  • 闲聊：直接回复，不进入正式流程
  • 正式指令：提炼任务标题，转交中书省

实现逻辑（伪代码）：

class TaiziAgent:
    def process(self, user_input: str) -> dict:
        # 使用LLM判断输入类型
        input_type = self.llm.classify(user_input)
        
        if input_type == "casual_chat":
            # 闲聊：直接回复
            response = self.llm.chat(user_input)
            return {
                "type": "chat",
                "response": response
            }
        else:
            # 正式指令：提炼标题，转交中书省
            task_title = self.llm.extract_title(user_input)
            self.send_to("zhongshu", {
                "task_title": task_title,
                "original_input": user_input
            })
            return {
                "type": "task",
                "task_title": task_title,
                "status": "forwarded_to_zhongshu"
            }

为什么要"分拣"？

• 防止无意义任务占用系统资源
• 让正式任务更快进入执行流程

3.2.2 中书省 Agent（规划层）

职责：

• 接收太子转交的任务
• 将任务拆解为可执行的子任务
• 生成执行计划（JSON格式）

执行计划格式：

{
  "task_id": "task_20260524_001",
  "task_title": "开发一个Todo List应用",
  "subtasks": [
    {
      "subtask_id": "subtask_001",
      "assignee": "bingbu",  // 兵部：代码编写
      "description": "编写后端API",
      "dependencies": []
    },
    {
      "subtask_id": "subtask_002",
      "assignee": "libu",    // 礼部：文档编写
      "description": "编写API文档",
      "dependencies": ["subtask_001"]
    },
    {
      "subtask_id": "subtask_003",
      "assignee": "gongbu",  // 工部：部署运维
      "description": "Docker容器化",
      "dependencies": ["subtask_001", "subtask_002"]
    }
  ]
}

实现逻辑（伪代码）：

class ZhongshuAgent:
    def create_plan(self, task_title: str, original_input: str) -> dict:
        # 使用LLM拆解任务
        plan = self.llm.generate_plan(
            task_title=task_title,
            context=original_input,
            available_agents=["libu", "hubu", "libu", "bingbu", "xingbu", "gongbu"]
        )
        
        # 验证计划格式
        self.validate_plan(plan)
        
        # 提交给门下省审核
        self.send_to("menxia", {
            "task_id": plan["task_id"],
            "plan": plan
        })
        
        return plan

3.2.3 门下省 Agent（审核层）

职责：

• 接收中书省提交的计划
• 审核计划的可行性
• 通过 → 转交尚书省
• 不通过 → 封驳，返回修改意见

审核维度：

1. 逻辑合理性：子任务之间是否有循环依赖？
2. 资源可行性：是否有Agent能完成指定任务？
3. 安全风险：任务是否涉及危险操作（如删除数据库）？

实现逻辑（伪代码）：

class MenxiaAgent:
    def review_plan(self, task_id: str, plan: dict) -> dict:
        issues = []
        
        # 1. 检查逻辑合理性
        if self.has_circular_dependency(plan["subtasks"]):
            issues.append("子任务存在循环依赖")
        
        # 2. 检查资源可行性
        for subtask in plan["subtasks"]:
            if not self.is_agent_available(subtask["assignee"]):
                issues.append(f"Agent {subtask['assignee']} 不可用")
        
        # 3. 检查安全风险
        if self.has_security_risk(plan):
            issues.append("任务存在安全风险")
        
        # 决策
        if len(issues) == 0:
            # 审核通过，转交尚书省
            self.send_to("shangshu", {
                "task_id": task_id,
                "plan": plan,
                "status": "approved"
            })
            return {"status": "approved"}
        else:
            # 封驳，返回修改意见
            self.send_to("zhongshu", {
                "task_id": task_id,
                "plan": plan,
                "issues": issues,
                "status": "rejected"
            })
            return {"status": "rejected", "issues": issues}

3.2.4 尚书省 Agent（派发层）

职责：

• 接收审核通过的计划
• 派发子任务给六部
• 汇总六部的执行结果
• 回奏给用户

实现逻辑（伪代码）：

class ShangshuAgent:
    def dispatch_tasks(self, task_id: str, plan: dict):
        # 按依赖顺序派发任务
        executed_subtasks = {}
        
        for subtask in self.topological_sort(plan["subtasks"]):
            assignee = subtask["assignee"]
            
            # 等待依赖完成
            for dep_id in subtask["dependencies"]:
                if dep_id not in executed_subtasks:
                    raise Exception(f"依赖 {dep_id} 未完成")
            
            # 派发给对应Agent
            result = self.send_to_and_wait(assignee, subtask)
            executed_subtasks[subtask["subtask_id"]] = result
        
        # 汇总结果
        summary = self.summarize_results(executed_subtasks)
        
        # 回奏给用户
        self.send_to("user", {
            "task_id": task_id,
            "status": "completed",
            "summary": summary,
            "details": executed_subtasks
        })

3.2.5 六部 Agent（执行层）

六部分别负责不同类型的子任务：

兵部 Agent 示例（代码执行）：

class BingbuAgent:
    def execute_task(self, subtask: dict) -> dict:
        description = subtask["description"]
        
        # 使用LLM生成代码
        code = self.llm.generate_code(description)
        
        # 在沙箱中执行代码
        result = self.sandbox.execute(code)
        
        # 返回执行结果
        return {
            "subtask_id": subtask["subtask_id"],
            "code": code,
            "result": result,
            "status": "success"
        }

四、代码实战：部署与使用 Edict 系统

4.1 环境准备

依赖：

• Python 3.10+
• OpenClaw Framework
• Node.js 18+（实时看板）

安装步骤：

# 1. 克隆仓库
git clone https://github.com/mvanhorn/edict.git
cd edict

# 2. 安装 Python 依赖
pip install -r requirements.txt

# 3. 安装 OpenClaw（如果尚未安装）
npm install -g openclaw

# 4. 配置 Agent SOUL.md
# 每个Agent都有独立的SOUL.md，定义其人格和职责
# 例如：agents/taizi/SOUL.md

4.2 配置 Agent 人格

Edict 的核心是每个Agent都有独立的SOUL.md，定义其：

• 角色定位
• 职责范围
• 行为准则
• 输出格式

示例：太子 Agent 的 SOUL.md

# 太子 Agent

## 角色定位
你是朝廷的"太子"，负责分拣用户任务。

## 职责范围
1. 判断用户输入是"闲聊"还是"正式指令"
2. 闲聊：直接回复，不进入正式流程
3. 正式指令：提炼任务标题，转交中书省

## 行为准则
- 不要对闲聊输入生成执行计划
- 提炼标题时，保留关键信息
- 如果不确定，倾向归类为"正式指令"

## 输出格式

### 闲聊回复

{
"type": "chat",
"response": "<你的回复>"
}

### 正式指令转交

{
"type": "task",
"task_title": "<提炼的标题>",
"original_input": "<原始输入>"
}

示例：门下省 Agent 的 SOUL.md

# 门下省 Agent

## 角色定位
你是朝廷的"门下省"，负责审核政令（执行计划）。

## 职责范围
1. 审核中书省提交的计划
2. 检查：逻辑合理性、资源可行性、安全风险
3. 通过 → 转交尚书省
4. 不通过 → 封驳，返回修改意见

## 审核清单
- [ ] 子任务是否有循环依赖？
- [ ] 分配的Agent是否可用？
- [ ] 任务是否涉及危险操作？
- [ ] 预估执行时间是否合理？

## 输出格式

### 审核通过

{
"status": "approved",
"task_id": "<任务ID>",
"plan": { ... }
}

### 封驳（审核不通过）

{
"status": "rejected",
"task_id": "<任务ID>",
"issues": [
"<问题1>",
"<问题2>"
],
"suggestions": [
"<修改建议1>",
"<修改建议2>"
]
}

4.3 启动系统

方式1：命令行启动

# 启动所有Agent
python scripts/start_edict.py

# 启动实时看板
cd dashboard
npm install
npm run dev
# 看板运行在 http://localhost:3000

方式2：OpenClaw 启动

# 在 OpenClaw 中加载 Edict 技能
openclaw skills install edict

# 启动 Edict session
openclaw session start --skill edict

4.4 实战案例：开发一个 REST API

用户输入：

帮我开发一个用户管理的 REST API，需要支持 CRUD 操作，使用 Flask 框架，包含单元测试，最后用 Docker 容器化。

执行流程：

1. 太子分拣

   • 判断：正式指令
   • 提炼标题："开发用户管理REST API"
   • 转交中书省

2. 中书省规划

   • 拆解子任务：
     • subtask_001：设计API接口 (礼部)
     • subtask_002：编写Flask后端 (兵部)
     • subtask_003：编写单元测试 (兵部)
     • subtask_004：Docker容器化 (工部)
   • 提交审核

3. 门下省审核

   • 检查：逻辑合理 ✓、资源可行 ✓、无安全风险 ✓
   • 审核通过，转交尚书省

4. 尚书省派发

   • 按顺序派发子任务
   • 等待六部执行完成
   • 汇总结果

5. 六部执行

   • 礼部：生成 api_design.md
   • 兵部：生成 app.py、test_app.py
   • 工部：生成 Dockerfile、docker-compose.yml

6. 回奏用户

   ## 任务完成：开发用户管理REST API
   
   ### 执行结果
   - ✅ API接口设计完成
   - ✅ Flask后端代码完成（共256行）
   - ✅ 单元测试完成（覆盖率85%）
   - ✅ Docker容器化完成
   
   ### 生成文件
   - `api_design.md`
   - `app.py`
   - `test_app.py`
   - `Dockerfile`
   - `docker-compose.yml`
   
   ### 如何运行
   ```bash
   docker-compose up -d
   curl http://localhost:5000/users
   

4.5 实时看板使用

Edict 提供了一个实时看板（默认运行在 http://localhost:3000），功能包括：

1. 任务列表

• 显示所有任务的状态（待审核、执行中、已完成、已驳回）
• 点击任务可查看详情

2. Agent 工作负载

• 显示每个Agent的当前状态（空闲、工作中、审核中）
• 工作队列长度

3. 任务流转图

• 可视化展示任务从"太子分拣"到"回奏用户"的完整流程
• 每个环节的耗时

4. 审计日志

• 记录每个Agent的输入/输出
• 门下省审核不通过的理由
• 可用于debugging和性能优化

五、性能优化：让古代官制适应现代节奏

5.1 并行执行优化

问题：
默认情况下，尚书省按依赖顺序串行派发任务，耗时较长。

优化方案：
对于无依赖关系的子任务，可以并行派发。

实现：

class ShangshuAgent:
    def dispatch_tasks_parallel(self, plan: dict):
        import asyncio
        
        # 构建依赖图
        dependency_graph = self.build_dependency_graph(plan["subtasks"])
        
        # 按"层"并行执行
        results = {}
        for layer in dependency_graph.layers:
            # 同一层的任务可以并行
            tasks = [
                self.send_to_async(subtask["assignee"], subtask)
                for subtask in layer
            ]
            layer_results = await asyncio.gather(*tasks)
            results.update(layer_results)
        
        return results

效果：

• 原耗时：串行执行，假设每个子任务耗时10秒，4个子任务 = 40秒
• 优化后：并行执行，4个子任务可分2层，耗时 = 20秒
• 性能提升：50%

5.2 审核缓存优化

问题：
门下省每次都要重新审核相似的计划，耗时较长（LLM调用）。

优化方案：
对于相似度高于阈值的计划，直接复用之前的审核结果。

实现：

class MenxiaAgent:
    def __init__(self):
        self.review_cache = {}  # 审核缓存
    
    def review_plan_cached(self, plan: dict) -> dict:
        # 计算计划的哈希值
        plan_hash = self.hash_plan(plan)
        
        # 检查缓存
        if plan_hash in self.review_cache:
            logger.info(f"Cache hit for plan {plan_hash}")
            return self.review_cache[plan_hash]
        
        # 缓存未命中，执行审核
        result = self.review_plan(plan)
        
        # 存入缓存
        self.review_cache[plan_hash] = result
        
        return result
    
    def hash_plan(self, plan: dict) -> str:
        import hashlib
        import json
        
        # 将计划转换为规范化的JSON字符串
        plan_str = json.dumps(plan, sort_keys=True)
        
        # 计算SHA256哈希
        return hashlib.sha256(plan_str.encode()).hexdigest()

效果：

• 原耗时：每次审核调用LLM，约3-5秒
• 优化后：缓存命中时，<1毫秒
• 性能提升：3000x+（当然，只有缓存命中时）

5.3 Agent 负载均衡

问题：
某些Agent（如兵部：代码编写）可能任务过多，成为瓶颈。

优化方案：
动态分配任务给同类型的Agent（如果有多个实例）。

实现：

class ShangshuAgent:
    def __init__(self):
        self.agent_pool = {
            "bingbu": ["bingbu_1", "bingbu_2", "bingbu_3"],  # 兵部有3个实例
            "libu": ["libu_1", "libu_2"],
            # ...
        }
        self.agent_load = {}  # 记录每个Agent的当前负载
    
    def select_agent(self, agent_type: str) -> str:
        # 选择负载最低的Agent
        candidates = self.agent_pool.get(agent_type, [agent_type])
        
        selected = min(candidates, key=lambda a: self.agent_load.get(a, 0))
        
        # 增加负载
        self.agent_load[selected] = self.agent_load.get(selected, 0) + 1
        
        return selected

效果：

• 原耗时：单个兵部Agent处理10个任务，每个10秒 = 100秒
• 优化后：3个兵部Agent并行，理想情况下 = 34秒
• 性能提升：66%

5.4 沙箱隔离与安全审计

问题：
兵部Agent需要执行生成的代码，如果代码有恶意操作（如删除文件），会造成安全问题。

优化方案：
在沙箱中执行代码，并由刑部Agent进行安全审计。

实现：

class BingbuAgent:
    def execute_code_sandbox(self, code: str) -> dict:
        import tempfile
        import subprocess
        
        # 创建临时目录作为沙箱
        with tempfile.TemporaryDirectory() as sandbox_dir:
            # 将代码写入文件
            code_file = os.path.join(sandbox_dir, "code.py")
            with open(code_file, "w") as f:
                f.write(code)
            
            # 在沙箱中执行（使用Docker容器）
            result = subprocess.run(
                ["docker", "run", "--rm", "--network", "none",  # 禁用网络
                 "--memory", "512m",  # 限制内存
                 "--cpus", "1.0",     # 限制CPU
                 "python-sandbox:latest",
                 "python", code_file],
                capture_output=True,
                timeout=60  # 超时60秒
            )
            
            return {
                "stdout": result.stdout.decode(),
                "stderr": result.stderr.decode(),
                "returncode": result.returncode
            }

刑部安全审计：

class XingbuAgent:
    def audit_code(self, code: str) -> dict:
        issues = []
        
        # 1. 静态分析：检查危险函数
        dangerous_functions = ["os.system", "subprocess.call", "eval", "exec"]
        for func in dangerous_functions:
            if func in code:
                issues.append(f"使用了危险函数：{func}")
        
        # 2. LLM分析：语义级安全检查
        security_prompt = f"请检查以下代码是否存在安全风险：\n{code}"
        llm_result = self.llm.analyze(security_prompt)
        issues.extend(llm_result["issues"])
        
        # 3. 依赖检查：是否有恶意包
        if "import" in code:
            # 解析import语句
            imports = self.parse_imports(code)
            for lib in imports:
                if self.is_malicious_package(lib):
                    issues.append(f"引入了恶意包：{lib}")
        
        return {
            "safe": len(issues) == 0,
            "issues": issues
        }

六、总结与展望：古代智慧在现代 AI 中的重生

6.1 Edict 的核心价值

通过将上述架构、代码实战、性能优化串联起来，我们可以看到 Edict 项目的核心价值：

1. 制度化的审核机制

• 不是"相信"Agent能产生正确输出，而是强制审核
• 门下省的"封驳"机制，就像是自动化Code Review

2. 明确的权限边界

• 通过权限矩阵，每个Agent只能与特定的Agent通信
• 防止"越级上访"，让调试变得可控

3. 完全可观测的执行流程

• 实时看板 + 审计日志
• 任何时刻都知道"任务在哪个环节"、"为什么失败"

4. 深厚的历史底蕴

• 三省六部制是经过1400年实践检验的协作模式
• 不是拍脑袋设计的架构，而是有历史支撑

6.2 与现有框架的对比

6.3 适用场景

Edict 特别适合以下场景：

1. 复杂任务编排

• 需要多个步骤、多个角色协作
• 例如：软件开发、数据分析、内容生成

2. 高可信环境

• 不能容忍错误输出
• 例如：金融分析、医疗诊断、法律咨询

3. 需要审计追踪

• 必须记录每个决策的原因
• 例如：合规检查、安全审计

4. 团队协作

• 多个开发者共同使用AI Agent
• 需要统一的任务管理和监控

6.4 未来展望

1. 多实例部署

• 目前Edict是单机部署
• 未来可以支持分布式部署，多个"朝廷"协同工作

2. Agent 技能市场

• 吏部负责管理Agent技能
• 未来可以建立技能市场，让Agent"学习"新技能

3. 跨框架集成

• Edict 目前基于 OpenClaw
• 未来可以支持 CrewAI、AutoGen 等其他框架的Agent

4. 智能化审核

• 门下省目前基于规则+LLM审核
• 未来可以训练专门的"审核模型"，提高审核精度和速度

6.5 结语

当我们追随着西方的AI潮流，争相开发"更智能的Agent"时，Edict 项目提醒我们：智慧不止于技术，更在于制度。

三省六部制在中国历史上延续了1300多年（隋朝581年 - 清朝1912年），这不是偶然。它的分权制衡、专职专用、流程可追溯，恰恰是现代Multi-Agent系统最需要的特性。

也许，真正的创新不是发明新东西，而是将古老的智慧用新的方式重新演绎。

Edict 项目就是这样一次尝试——用唐朝的官制，设计2026年的AI系统。它可能不是最"潮"的，但一定是最有"底蕴"的。

如果你也厌倦了现有Multi-Agent框架的混乱，不妨试试 Edict——让古代的智慧，帮你管理现代的AI。

参考资源

• GitHub 仓库：https://github.com/mvanhorn/edict
• OpenClaw 官网：https://openclaw.ai
• 三省六部制 Wikipedia：https://zh.wikipedia.org/wiki/三省六部
• Edict 实时看板Demo：https://edict-demo.vercel.app

关键词：Multi-Agent系统, AI协作, 三省六部制, OpenClaw, 分布式AI, Agent编排, 代码审核, 沙箱安全, 实时看板, 古代官制现代化

标签：AI Agent|Multi-Agent系统|OpenClaw|Agent编排|AI协作|古代官制|分布式AI|代码审核|沙箱安全|实时看板