三省六部制遇上AI：edict 如何用唐代官制重构 Multi-Agent 编排系统

当现代 AI 工程师还在为 Multi-Agent 系统的混乱协作头疼时，一位中国开发者从唐朝的"三省六部制"找到了答案。7639 星、周增长 199%——edict 正在用古典治理智慧重新定义 AI Agent 编排。

引言：当 AI Agent 遇上古典治理智慧

2026 年，Multi-Agent 系统已经从概念验证走向生产部署。但开发者们普遍面临一个核心困境：多个 AI Agent 如何高效协作而不陷入混乱？

OpenAI 的 delegation patterns、Claude Code 的 subagents、OpenClaw 的 runtime orchestration——各家都在尝试回答这个问题。但大多数方案仍然停留在"技术补丁"的层面：用消息队列、用共享状态、用人工定义的 workflow。

edict 项目给出了一个令人耳目一新的答案：回到 1400 年前的中国唐代，借鉴"三省六部制"的治理架构。

这个创意并非简单的文化包装。三省六部制作为中国古代最成熟的政治制度之一，其核心设计思想——权力分立、职能专业化、流程标准化、监督审计——恰恰是现代 Multi-Agent 系统最需要的架构原则。

在本文中，我们将深度解析 edict 项目：

• 三省六部制与 Multi-Agent 架构的精妙映射
• 9 个专业 Agent 的角色设计与协作机制
• 实时仪表盘与全链路审计的实现原理
• 从部署到生产实践的完整指南
• 与 OpenAI、Claude Code、OpenClaw 方案的对比分析

第一章：三省六部制——被低估的系统设计范式

1.1 历史背景：为什么是唐代？

唐朝的三省六部制（公元 618-907 年）被认为是中国古代政治制度的最高成就。它不仅支撑了"贞观之治"、"开元盛世"的辉煌，更在接下来的 1300 年里成为东亚政治制度的模板。

核心架构：

┌─────────────────────────────────────────────────────┐
│                  皇帝（最高决策）                     │
├─────────────────────────────────────────────────────┤
│  中书省（决策）  →  门下省（审议）  →  尚书省（执行）  │
├─────────────────────────────────────────────────────┤
│        尚书省下设六部：                               │
│        吏部（人事）  户部（财政）  礼部（教育外交）       │
│        兵部（军事）  刑部（司法）  工部（工程）         │
└─────────────────────────────────────────────────────┘

1.2 三省六部制的系统设计精髓

从这个架构中，我们可以提取出 5 个核心设计原则，它们直接对应现代 Multi-Agent 系统的关键问题：

1.3 为什么现有 Multi-Agent 框架缺少这些？

让我们坦诚地分析现有方案的局限：

OpenAI Swarm / Assistants API：

• ✅ 支持 Agent 切换
• ❌ 缺少强制的流程约束，Agent 可能"越权"
• ❌ 审计能力弱，难以追溯决策链

Claude Code subagents：

• ✅ 上下文隔离做得好
• ❌ 缺少全局协调者，依赖人工定义 workflow
• ❌ 记忆隔离导致知识无法跨 Agent 积累

OpenClaw runtime：

• ✅ 强大的运行时编排
• ❌ 配置复杂，学习曲线陡峭
• ❌ 缺少可视化的系统状态展示

edict 的创新之处：它不是简单地"加一个编排层"，而是从制度设计的高度，引入了一套完整的 角色-流程-监督-审计 体系。

第二章：edict 架构深度解析

2.1 核心设计：9 个专业 Agent 的分工协作

edict 项目实现了 9 个专业 AI Agent，它们分别对应三省六部制中的不同职能：

┌──────────────────────────────────────────────────────────┐
│                    edict Multi-Agent System               │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  【决策层】相当于"中书省"                                │
│  ├── Coordinator Agent（协调者）                          │
│  │   - 接收用户请求，分解为子任务                         │
│  │   - 选择合适的专业 Agent 执行                          │
│  │   - 维护全局上下文和任务状态                           │
│  └── Planner Agent（规划者）                          │
│      - 制定长期执行计划                                   │
│      - 处理多步骤、多 Agent 的复杂任务                     │
│                                                          │
│  【审议层】相当于"门下省"                                │
│  ├── Reviewer Agent（审查者）                          │
│  │   - 审查其他 Agent 的输出质量                         │
│  │   - 检测错误、偏见、安全风险                           │
│  └── Auditor Agent（审计者）                           │
│      - 记录所有 Agent 的行为日志                          │
│      - 生成可追溯的决策审计报告                           │
│                                                          │
│  【执行层】相当于"尚书省 + 六部"                         │
│  ├── Coder Agent（码农）   ← 工部                       │
│  ├── DBAgent（数据）      ← 户部                        │
│  ├── Tester Agent（测试）  ← 刑部                       │
│  ├── DocAgent（文档）     ← 礼部                        │
│  └── DevOps Agent（运维）  ← 兵部                       │
│                                                          │
└─────────────────────────────────────────────────────────────┘

2.2 Agent 间的消息协议设计

edict 定义了一套严格的消息协议，确保 Agent 间的通信像唐代的"制敕"一样规范：

# edict 消息协议（简化版）

class AgentMessage:
    """Agent 间通信的标准消息格式"""
    
    def __init__(
        self,
        msg_id: str,              # 唯一消息 ID（类似公文编号）
        from_agent: str,           # 发送者
        to_agent: str,             # 接收者
        msg_type: str,             # 消息类型：request/response/approval/rejection
        content: dict,             # 消息内容
        context_ref: str,          # 关联的上下文 ID
        priority: int = 1,         # 优先级（1-5）
        timestamp: float = None,    # 时间戳
        signature: str = None      # 数字签名（防篡改）
    ):
        self.msg_id = msg_id
        self.from_agent = from_agent
        self.to_agent = to_agent
        self.msg_type = msg_type
        self.content = content
        self.context_ref = context_ref
        self.priority = priority
        self.timestamp = timestamp or time.time()
        self.signature = signature
    
    def sign(self, private_key: str):
        """使用私钥签名，确保消息来源可信"""
        data = f"{self.msg_id}{self.from_agent}{self.to_agent}{self.content}"
        self.signature = sign_data(data, private_key)
    
    def verify(self, public_key: str) -> bool:
        """验证签名"""
        data = f"{self.msg_id}{self.from_agent}{self.to_agent}{self.content}"
        return verify_signature(data, self.signature, public_key)

设计亮点：

1. 消息可追溯：每个消息都有唯一 msg_id 和 context_ref，可以完整还原一次任务的执行链路
2. 数字签名：防止恶意 Agent 伪造消息（对应唐代的"印信"制度）
3. 优先级机制：紧急任务可以"加急"（类似古代的"驰驿"）

2.3 实时仪表盘：可视化"朝堂议事"

edict 的一个杀手级功能是 实时仪表盘（Real-time Dashboard），它让你像观看"朝堂议事"一样监控所有 Agent 的状态：

# dashboard/server.py（概念代码）

from fastapi import FastAPI
from fastapi.websockets import WebSocket
import json

app = FastAPI()

class AgentDashboard:
    """实时仪表盘后端"""
    
    def __init__(self):
        self.agents_status = {}  # agent_id -> status
        self.message_log = []     # 所有消息的日志
        self.websocket_connections = []  # 前端 WebSocket 连接
    
    async def broadcast_update(self, event: dict):
        """向所有前端连接广播更新"""
        for ws in self.websocket_connections:
            await ws.send_json(event)
    
    def on_agent_state_change(self, agent_id: str, new_state: str, task: dict):
        """Agent 状态变化时的回调"""
        event = {
            "type": "agent_state_change",
            "agent_id": agent_id,
            "old_state": self.agents_status.get(agent_id),
            "new_state": new_state,
            "task": task,
            "timestamp": time.time()
        }
        self.agents_status[agent_id] = new_state
        asyncio.create_task(self.broadcast_update(event))
    
    def on_message_sent(self, msg: AgentMessage):
        """记录消息并通知前端"""
        self.message_log.append(msg)
        event = {
            "type": "message",
            "message": {
                "from": msg.from_agent,
                "to": msg.to_agent,
                "type": msg.msg_type,
                "content_preview": str(msg.content)[:100]
            }
        }
        asyncio.create_task(self.broadcast_update(event))

dashboard = AgentDashboard()

@app.websocket("/ws/dashboard")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    dashboard.websocket_connections.append(websocket)
    try:
        while True:
            # 保持连接，接收前端的控制命令
            data = await websocket.receive_json()
            await handle_frontend_command(data)
    except:
        dashboard.websocket_connections.remove(websocket)

前端展示效果（概念）：

┌─────────────────────────────────────────────────────────────┐
│  edict Dashboard  |  系统状态：运行中  |  活跃 Agent：7/9    │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  【决策层】                                                   │
│  ✓ Coordinator  ← 空闲                                     │
│  ✓ Planner      ← 正在制定计划 (任务 #1234)                  │
│                                                              │
│  【审议层】                                                   │
│  ✓ Reviewer     ← 审查中 (Coder 的输出)                      │
│  ✓ Auditor      ← 记录日志 (消息 #5678)                      │
│                                                              │
│  【执行层】                                                   │
│  ✓ Coder        ← 编写代码 (任务 #1235)                      │
│  ✓ DBAgent      ← 查询数据库 (任务 #1236)                    │
│  ✓ Tester       ← 空闲                                     │
│  ✓ DocAgent      ← 生成文档 (任务 #1237)                    │
│  ✓ DevOps       ← 部署中 (任务 #1238)                        │
│                                                              │
│  【实时消息流】                                               │
│  14:32:01  Coordinator → Planner      REQUEST  制定执行计划   │
│  14:32:03  Planner    → Coordinator   RESPONSE 计划已制定    │
│  14:32:05  Coordinator → Coder        ASSIGN   任务 #1235    │
│  14:32:08  Coder      → Reviewer      SUBMIT  代码待审查     │
│  ...                                                         │
└─────────────────────────────────────────────────────────────┘

第三章：代码实战——从零部署 edict

3.1 环境准备

edict 使用 Python 开发，依赖以下核心库：

# 基础环境
Python >= 3.10
pip install -r requirements.txt

# 核心依赖（requirements.txt）
openai>=1.0.0
anthropic>=0.8.0
fastapi>=0.110.0
uvicorn>=0.27.0
websockets>=12.0
pydantic>=2.0.0
sqlalchemy>=2.0.0
redis>=5.0.0

3.2 配置文件详解

edict 使用 YAML 配置文件定义 Agent 的行为：

# config/edict.yaml

# 全局配置
global:
  log_level: INFO
  audit_enabled: true
  dashboard_enabled: true
  dashboard_port: 8080

# 模型配置（支持多个 LLM 后端）
models:
  default:
    provider: openai
    model: gpt-4-turbo
    temperature: 0.7
    max_tokens: 4096
  
  # 不同 Agent 可以使用不同的模型
  coder:
    provider: anthropic
    model: claude-3-5-sonnet-20241022
    temperature: 0.3
    max_tokens: 8192
  
  reviewer:
    provider: openai
    model: gpt-4-turbo
    temperature: 0.5

# Agent 定义
agents:
  coordinator:
    enabled: true
    system_prompt: |
      你是 edict 系统的协调者（相当于唐代的"中书令"）。
      你的职责是：
      1. 理解用户的请求，将其分解为可执行的子任务
      2. 根据任务类型，选择合适的专业 Agent 执行
      3. 监控任务执行状态，处理异常情况
      4. 维护全局上下文，确保各 Agent 之间的信息流畅
      
      你应当遵循"三省六部制"的原则：
      - 决策（中书省）：制定执行方案
      - 审议（门下省）：提交审查者审核
      - 执行（尚书省）：委派专业 Agent 实施
    max_iterations: 10
  
  coder:
    enabled: true
    system_prompt: |
      你是 edict 系统的编程专家（相当于唐代的"工部"）。
      你负责：
      1. 编写高质量、可维护的代码
      2. 遵循最佳实践和编码规范
      3. 编写单元测试
      4. 优化代码性能
    language: python
    max_iterations: 5
  
  reviewer:
    enabled: true
    system_prompt: |
      你是 edict 系统的审查者（相当于唐代的"门下省给事中"）。
      你的职责是严格审查其他 Agent 的输出：
      1. 代码质量：是否有 bug、是否可维护
      2. 安全审查：是否有安全漏洞
      3. 性能审查：是否有性能瓶颈
      4. 合规性：是否符合需求和规范
      
      你有权"封驳"（拒绝通过）不符合标准的输出。
    strict_mode: true

  # ... 其他 Agent 的配置

# 审计配置
audit:
  storage: sqlite  # 或 mysql, postgresql
  retention_days: 30
  pii_detection: true  # 自动检测并脱敏个人信息

# 仪表盘配置
dashboard:
  enabled: true
  host: 0.0.0.0
  port: 8080
  auth_enabled: false  # 生产环境建议开启

3.3 启动系统

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

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

# 配置环境变量
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
export EDICT_CONFIG_PATH="./config/edict.yaml"

# 初始化数据库
python scripts/init_db.py

# 启动系统
python -m edict.main

# 另一种方式：使用 Docker（推荐）
docker build -t edict:latest .
docker run -d \
  -p 8080:8080 \
  -v $(pwd)/config:/app/config \
  -e OPENAI_API_KEY \
  -e ANTHROPIC_API_KEY \
  --name edict \
  edict:latest

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

让我们用一个完整的例子来展示 edict 的工作流程：用户请求"开发一个用户管理的 REST API"。

Step 1: 用户提交任务

# 通过 API 提交任务
import requests

response = requests.post("http://localhost:8080/api/task", json={
    "task": "开发一个用户管理的 REST API，使用 FastAPI",
    "requirements": [
        "支持用户的 CRUD 操作",
        "使用 SQLite 数据库",
        "包含单元测试",
        "生成 API 文档"
    ]
})

task_id = response.json()["task_id"]
print(f"任务已提交，ID: {task_id}")

Step 2: Coordinator Agent 分解任务

[Coordinator Agent 的思考过程]

用户需求：开发用户管理 REST API

任务分解：
1. 设计 API 接口和数据模型 → 派给 Planner Agent
2. 编写 API 实现代码 → 派给 Coder Agent
3. 编写单元测试 → 派给 Tester Agent
4. 编写 API 文档 → 派给 DocAgent
5. 部署到测试环境 → 派给 DevOps Agent

执行顺序：
Planner → Coder → Tester → DocAgent → DevOps

依赖关系：
- Coder 依赖 Planner 的输出（接口设计）
- Tester 依赖 Coder 的输出（代码）
- DocAgent 可以并行执行（不依赖其他人）
- DevOps 依赖 Coder 和 Tester 都完成

开始执行...

Step 3: 各 Agent 协同工作（消息流）

14:30:01  [Coordinator] → [Planner]     任务 #1001：设计 API 接口
14:30:05  [Planner]    → [Coordinator]  完成：API 接口设计文档
14:30:06  [Coordinator] → [Coder]       任务 #1002：编写 API 实现（参考设计文档）
14:30:30  [Coder]      → [Reviewer]     提交代码，请求审查
14:30:35  [Reviewer]   → [Coder]        审查意见：第 45 行缺少错误处理，请修复
14:30:40  [Coder]      → [Reviewer]     已修复，请重新审查
14:30:44  [Reviewer]   → [Coordinator]  审查通过
14:30:45  [Coordinator] → [Tester]      任务 #1003：编写单元测试
14:31:00  [Tester]     → [Reviewer]     提交测试代码，请求审查
14:31:05  [Reviewer]   → [Coordinator]  审查通过
14:31:06  [Coordinator] → [DocAgent]    任务 #1004：生成 API 文档
14:31:20  [DocAgent]   → [Coordinator]  完成：API 文档已生成
14:31:21  [Coordinator] → [DevOps]      任务 #1005：部署到测试环境
14:31:40  [DevOps]     → [Coordinator]  完成：已部署到 http://localhost:8000
14:31:41  [Coordinator] → [Auditor]     请求生成审计报告
14:31:43  [Auditor]    → [Coordinator]  审计完成，报告已保存

任务 #1001 执行完成，总耗时：102 秒

Step 4: 查看结果

# 访问 API 文档
open http://localhost:8000/docs

# 查看审计报告
cat audits/task_1001.json

# 在仪表盘查看实时执行过程
open http://localhost:8080/dashboard

审计报告示例：

{
  "task_id": "1001",
  "start_time": "2026-05-23T14:30:01Z",
  "end_time": "2026-05-23T14:31:43Z",
  "total_duration_seconds": 102,
  "agents_involved": [
    "Coordinator", "Planner", "Coder", "Reviewer", "Tester", "DocAgent", "DevOps", "Auditor"
  ],
  "messages_exchanged": 15,
  "review_cycles": 2,  // Coder 第一次被 Reviewer 打回，修复后通过
  "artifacts": {
    "code_files": ["api/main.py", "api/models.py", "api/crud.py"],
    "test_files": ["tests/test_api.py"],
    "doc_files": ["docs/api.md"],
    "deployment_url": "http://localhost:8000"
  },
  "quality_score": 92,  // Reviewer 给出的综合评分
  "issues_found": [
    {
      "agent": "Reviewer",
      "severity": "medium",
      "description": "第 45 行缺少错误处理",
      "resolution": "已修复"
    }
  ]
}

第四章：深度对比——edict vs 其他 Multi-Agent 框架

4.1 架构理念对比

4.2 代码级对比：实现一个"代码审查"流程

使用 OpenAI Swarm：

from swarm import Swarm, Agent

client = Swarm()

# 定义 Agent
coder = Agent(
    name="Coder",
    instructions="你是一个程序员，负责编写代码"
)

reviewer = Agent(
    name="Reviewer",
    instructions="你是一个代码审查者，检查代码质量"
)

# 手动定义流程
response = client.run(
    agent=coder,
    messages=[{"role": "user", "content": "写一个快排"}]
)
# 需要手动把 coder 的输出传给 reviewer
review = client.run(
    agent=reviewer,
    messages=response.messages + [{"role": "user", "content": "审查这段代码"}]
)

问题：

• ❌ 流程需要手动编排
• ❌ 没有强制的审查机制（coder 可以跳过审查）
• ❌ 缺少审计日志

使用 edict：

# 配置文件（config.yaml）
agents:
  coder:
    enabled: true
    system_prompt: "你是程序员"
    # 关键：coder 的输出必须经过 reviewer 审查
    output_requires_review: true
    reviewer_agent: reviewer
  
  reviewer:
    enabled: true
    system_prompt: "你是审查者"
    # 审查不通过可以打回
    can_reject: true

# 代码
from edict import EdictSystem

system = EdictSystem(config_path="config.yaml")
result = system.submit_task("写一个快排")

# edict 自动执行：
# 1. Coder 生成代码
# 2. 自动提交给 Reviewer 审查
# 3. 如果审查不通过，Coder 自动修复（最多 3 次）
# 4. 审查通过后，返回结果
# 5. 全程记录审计日志

优势：

• ✅ 流程自动编排
• ✅ 强制审查机制
• ✅ 完整的审计追踪

4.3 性能对比（模拟测试）

我们设计了一个 benchmark：实现一个完整的用户管理系统（CRUD + 测试 + 文档）。

分析：

• 单一 GPT-4：最快，但质量不稳定，需要多次人工介入修正
• OpenAI Swarm：最慢，因为 Agent 之间需要多轮对话才能协调好
• Claude Code：速度快，质量高，但复杂任务需要人工分解
• edict：速度中等，但无需人工介入（Coordinator 自动分解任务），且质量最高（因为有 Reviewer 把关）

第五章：生产实践与性能优化

5.1 生产环境部署架构

在生产环境中，edict 通常采用以下部署架构：

┌─────────────────────────────────────────────────────────────┐
│                      负载均衡（Nginx）                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ edict Instance 1 │  │ edict Instance 2 │  │ edict Instance 3 │      │
│  │                │  │                │  │                │      │
│  │ Coordinator   │  │ Coordinator   │  │ Coordinator   │      │
│  │ Planner       │  │ Planner       │  │ Planner       │      │
│  │ ...           │  │ ...           │  │ ...           │      │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘      │
│         │                  │                  │                │
│         └──────────────────┼──────────────────┘                │
│                            │                                   │
│                    ┌───────▼────────┐                         │
│                    │  Redis (消息队列) │                         │
│                    └───────┬────────┘                         │
│                            │                                   │
│                    ┌───────▼────────┐                         │
│                    │ PostgreSQL      │                         │
│                    │ (审计日志)       │                         │
│                    └────────────────┘                         │
│                                                              │
└─────────────────────────────────────────────────────────────┘

关键优化点：

1. Agent 池化：多个 edict 实例共享一个 Agent 池，避免重复创建 Agent
2. 消息队列：使用 Redis 实现 Agent 间的异步通信
3. 水平扩展：无状态设计，可以通过增加实例提高并发能力

5.2 Token 成本优化

edict 的 9 个 Agent 如果每个都使用 GPT-4，Token 成本会很高。以下是成本优化策略：

策略 1：模型分级

# config.yaml

# 高级推理任务使用强模型
coordinator:
  model: gpt-4-turbo  # $0.01/1k tokens

# 中等复杂度任务使用中档模型
coder:
  model: claude-3-5-sonnet  # $0.003/1k tokens

# 简单任务使用廉价模型
doc_agent:
  model: gpt-3.5-turbo  # $0.0005/1k tokens

# 审查任务使用专用模型（可以选择开源模型）
reviewer:
  model: local/code-llama-34b  # 自托管，边际成本为 0

策略 2：上下文压缩

# edict/context_manager.py

class ContextManager:
    """管理 Agent 的上下文窗口，避免 Token 浪费"""
    
    def __init__(self, max_context_tokens=8000):
        self.max_context_tokens = max_context_tokens
        self.summary_agent = None  # 用于压缩上下文的轻量模型
    
    def compress_context(self, messages: list) -> list:
        """当上下文超过限制时，自动压缩历史消息"""
        total_tokens = sum(len(m["content"]) // 4 for m in messages)
        
        if total_tokens <= self.max_context_tokens:
            return messages
        
        # 保留最近的 10 条消息
        recent_messages = messages[-10:]
        
        # 将 older messages 压缩为摘要
        older_messages = messages[:-10]
        summary = self._summarize(older_messages)
        
        # 返回：摘要 + 最近消息
        return [
            {"role": "system", "content": f"历史对话摘要：{summary}"}
        ] + recent_messages
    
    def _summarize(self, messages: list) -> str:
        """使用轻量模型生成摘要"""
        # 使用 GPT-3.5 或本地模型
        ...

策略 3：缓存常用响应

# edict/cache.py

import hashlib
import json
import redis

class ResponseCache:
    """缓存 Agent 的响应，避免重复调用 LLM"""
    
    def __init__(self, redis_client: redis.Redis):
        self.redis = redis_client
        self.ttl = 3600  # 1 小时过期
    
    def _make_cache_key(self, agent_name: str, prompt: str) -> str:
        """生成缓存键"""
        content = f"{agent_name}:{prompt}"
        return f"edict:cache:{hashlib.md5(content.encode()).hexdigest()}"
    
    def get(self, agent_name: str, prompt: str) -> str | None:
        """查询缓存"""
        key = self._make_cache_key(agent_name, prompt)
        cached = self.redis.get(key)
        return cached.decode() if cached else None
    
    def set(self, agent_name: str, prompt: str, response: str):
        """写入缓存"""
        key = self._make_cache_key(agent_name, prompt)
        self.redis.setex(key, self.ttl, response)

5.3 容错与重试机制

在生产环境中，LLM API 可能会超时或返回错误。edict 实现了多级容错：

# edict/fault_tolerance.py

import tenacity
from openai import OpenAIError

class FaultTolerantAgent:
    """带容错能力的 Agent 包装器"""
    
    def __init__(self, agent, max_retries=3):
        self.agent = agent
        self.max_retries = max_retries
    
    @tenacity.retry(
        stop=tenacity.stop_after_attempt(3),
        wait=tenacity.wait_exponential(multiplier=1, min=4, max=60),
        retry=tenacity.retry_if_exception_type((OpenAIError, TimeoutError)),
        before_sleep=self._log_retry
    )
    def run_with_retry(self, prompt: str) -> str:
        """带指数退避的重试机制"""
        return self.agent.run(prompt)
    
    def _log_retry(self, retry_state):
        """记录重试日志"""
        print(f"[重试] Agent {self.agent.name} 第 {retry_state.attempt_number} 次重试")
    
    def run(self, prompt: str) -> str:
        """带熔断器的执行"""
        try:
            return self.run_with_retry(prompt)
        except Exception as e:
            # 熔断器：连续失败 5 次后，暂时禁用该 Agent
            self._record_failure()
            if self._failure_count >= 5:
                self._disable_agent()
                raise AgentDisabledError(f"Agent {self.agent.name} 已被禁用")
            raise e
    
    def _record_failure(self):
        self._failure_count += 1
    
    def _disable_agent(self):
        """禁用 Agent，并通知 Coordinator 重新分配任务"""
        self.agent.enabled = False
        # 通知 Coordinator
        ...

第六章：edict 的局限与未来演进

6.1 当前局限性

尽管 edict 在架构设计上非常创新，但它也有一些局限性：

1. 配置复杂

edict 的 YAML 配置文件非常详细，对新手不够友好。一个有经验的开发者可能需要 1-2 小时才能理解所有配置项。

改进方向：提供交互式配置向导（edict init --interactive）。

2. 资源消耗较高

运行完整的 9 个 Agent 需要较多的内存和计算资源。如果每个 Agent 都加载一个 LLM 实例，内存消耗可能超过 10GB。

改进方向：

• Agent 池化（多个任务共享同一个 Agent 实例）
• 使用更轻量的模型（如 Phi-3、Gemma）
• 支持 Agent 的按需加载/卸载

3. 学习曲线较陡

要充分发挥 edict 的威力，用户需要理解：

• 三省六部制的设计思想
• 每个 Agent 的角色和职责
• 如何编写高质量的 System Prompt
• 如何解读审计日志和仪表盘

改进方向：提供更丰富的文档、教程和示例项目。

6.2 未来演进方向

方向 1：动态 Agent 编排

当前的 edict 使用静态的 9 个 Agent，未来可以支持动态创建和销毁 Agent：

# 未来特性（概念代码）

# 用户提交一个从未见过的任务类型
task = "用 Rust 实现一个高性能的 JSON 解析器"

# edict 自动分析：需要一个"Rust 专家 Agent"
# 如果不存在，自动创建
if "rust_expert" not in system.agents:
    system.create_agent(
        name="rust_expert",
        system_prompt="你是 Rust 编程专家...",
        model="claude-3-5-sonnet",
        tools=["rust_analyzer", "cargo"]
    )

# 执行任务
result = system.submit_task(task)

方向 2：跨系统协作

未来的 edict 可以与其他 Multi-Agent 系统协作：

# edict 调用外部的 Claude Code subagent

from edict.bridges import ClaudeCodeBridge

bridge = ClaudeCodeBridge()

# edict 的 Coder Agent 可以调用 Claude Code 来执行特定子任务
result = bridge.call_claude_code(
    prompt="帮我重构这段 Python 代码",
    code=python_code
)

方向 3：强化学习优化 Agent 协作

使用 RL 来优化 Agent 之间的协作策略：

# 未来特性（概念代码）

from edict.rl import MultiAgentRL

# 定义一个奖励函数
def reward_function(task_result):
    """根据任务结果计算奖励"""
    quality_score = task_result.quality_score  # 0-100
    time_penalty = -task_result.duration / 100  # 越快越好
    cost_penalty = -task_result.token_cost / 1000  # 越省钱越好
    return quality_score + time_penalty + cost_penalty

# 使用 PPO 训练 Agent 的协作策略
rl_trainer = MultiAgentRL(
    agents=system.agents,
    reward_function=reward_function,
    algorithm="PPO"
)

rl_trainer.train(num_episodes=1000)

第七章：总结与展望

7.1 核心要点回顾

在本文中，我们深度解析了 edict 项目：

1. 创新的设计理念：将唐代"三省六部制"的治理智慧应用于现代 Multi-Agent 系统
2. 严格的角色分工：9 个专业 Agent 各司其职，通过标准消息协议协作
3. 强大的可观测性：实时仪表盘 + 全链路审计，让 AI 系统的决策过程透明可查
4. 生产级特性：容错机制、成本优化、水平扩展能力

7.2 适合使用 edict 的场景

✅ 适合：

• 复杂、多步骤的任务（如全栈开发、数据分析 pipeline）
• 对输出质量有高要求的场景（有 Reviewer Agent 把关）
• 需要审计和追溯的行业（金融、医疗、法律）
• 希望减少人工介入的自动化流程

❌ 不适合：

• 简单的单轮对话任务（用 GPT-4 直接对话更高效）
• 实时性要求极高的场景（edict 的多 Agent 协作会引入延迟）
• 资源受限的环境（无法承担 9 个 Agent 的内存消耗）

7.3 对 Multi-Agent 领域的启示

edict 的成功（7639 星、周增长 199%）说明了一个重要趋势：

未来的 Multi-Agent 系统，不仅仅是技术的堆砌，更需要从制度设计、流程规范、监督审计等"社会科学"角度去思考。

计算机科学从来不是一座孤岛。从操作系统的"花园城市"理论，到分布式系统的"拜占庭将军"问题，再到 edict 的"三省六部制"——跨学科的灵感往往是突破技术瓶颈的关键。

7.4 行动建议

如果你对 edict 感兴趣，以下是一些入手建议：

1. 快速体验：

   git clone https://github.com/cft0808/edict.git
   cd edict
   docker-compose up -d
   open http://localhost:8080/dashboard
   

2. 阅读源码：重点看 edict/agents/ 目录，理解每个 Agent 的实现

3. 加入社区：在 GitHub Discussions 中分享你的使用案例和优化建议

4. 贡献代码：edict 是一个年轻的项目，有很多可以贡献的地方（文档、测试、新 Agent 类型...）

附录：edict 快速参考

A. 配置文件模板

（见第三章的 config/edict.yaml）

B. API 参考

# 提交任务
POST /api/task
{
  "task": "你的任务描述",
  "requirements": ["需求1", "需求2"]
}

# 查询任务状态
GET /api/task/{task_id}

# 查看审计日志
GET /api/audit/{task_id}

# WebSocket 仪表盘
WS /ws/dashboard

C. 常用命令

# 启动系统
python -m edict.main

# 运行测试
pytest tests/

# 查看日志
tail -f logs/edict.log

# 数据库迁移
alembic upgrade head

参考资源：

• edict GitHub：https://github.com/cft0808/edict
• 三省六部制维基百科：https://zh.wikipedia.org/wiki/三省六部
• OpenAI Swarm：https://github.com/openai/swarm
• Claude Code 文档：https://docs.anthropic.com/claude-code

作者注：本文撰写时使用 edict v0.2.1，后续版本可能有所变化。欢迎在评论区分享你的使用体验！