# 案例一：「六部制」个人 AI 助理系统 — 设计文档

> **状态**：SHIPPED · 在线运行中（2026-03 上线）
> **角色**：独立产品负责人 —— 需求定义、架构设计、模型选型、成本控制、运维
> **形态**：10+ 常驻 Agent 的个人 AI 助理系统，部署于云服务器，systemd 常驻
> **本文档**：面向求职场景的设计复盘。敏感信息（服务器地址、密钥）已隐去。

---

## 1. 问题定义

### 1.1 背景

我是这套系统的第一个用户，也是它要解决的痛点的长期忍受者：

- **任务碎片化**：写作、日程、学习、代码、信息整理散落在不同的聊天窗口里，每次都要重新交代上下文；
- **单模型单线程**：一个模型包揽所有事——写文案和查资料用同一个旗舰模型，**为不需要的推理能力付费**；
- **无审核机制**：模型的输出直接执行，错了没有拦截环节；
- **无降级能力**：单一 API 供应商故障 = 整个助理离线。

### 1.2 问题重述（产品视角）

> 如何设计一个**个人 AI 助理系统**，让多个模型按任务价值分工协作，在单人可运维的成本与复杂度约束下，做到**稳定、可控、可降级**？

三个关键词决定了后面所有设计决策：**分工**、**成本**、**可靠性**。

---

## 2. 目标与约束

| 维度 | 目标 | 约束 |
|------|------|------|
| 功能 | 覆盖决策规划 / 文案 / 学习 / 工程执行 / 每日简报 | 单人使用，无需多租户 |
| 成本 | 旗舰模型只花在高价值决策上 | 订阅制 API 预算固定（阿里云百炼 Coding Plan） |
| 可用性 | 供应商故障不中断服务 | 单台云服务器，无 K8s 级基础设施 |
| 运维 | 一人可维护 | 业余时间维护，故障恢复要简单 |

**核心权衡**：这是一个「够用且活着」优先的系统，不是「先进但脆弱」的系统。

---

## 3. 方案：三省六部制

### 3.1 为什么是「官僚制」隐喻

设计多 Agent 系统时对比过三种组织方式：

| 方案 | 做法 | 问题 |
|------|------|------|
| A. 单 Agent + 工具调用 | 一个模型挂所有工具 | 上下文膨胀快；无并行；无成本分层空间 |
| B. 平铺多 Agent | N 个独立 Agent 各干各的 | 缺全局视角；任务冲突无人仲裁 |
| **C. 分层官僚制（采用）** | 决策层 + 执行层，职责显式分离 | Agent 数量多，配置成本高 |

选 C 的理由：**官僚制的本质是把「决策权」和「执行权」分离，并用制度而非自觉来保证质量**——这恰好是单模型系统最缺的东西。中国古代三省六部制已经把这个问题的答案跑了一千多年：中书出方案、门下做审核、尚书去调度，六部按专业分工执行。

### 3.2 架构与职责

```
接入层  IM 通道 / Gateway（路由、鉴权）
  ↓
决策层（三省）
  中书省 zhongshu —— 规划：把模糊需求拆成可执行任务
  门下省 menxia   —— 审核：方案把关，拦截低质量输出
  尚书省 shangshu —— 调度：分派任务到执行层，追踪结果
  ↓ 任务分派
执行层（六部 + 特设）
  吏部 libu_hr —— Agent 人事：增删改查各 Agent 配置
  户部 hubu    —— 财务：API 用量与成本核算
  礼部 libu    —— 文案：写作与对外表达
  兵部 bingbu  —— 安全：访问控制与异常处置
  刑部 xingbu  —— 合规：输出规范检查
  工部 gongbu  —— 工程：代码与脚本执行
  ─────────────────────────
  特设：太子 taizi（陪学）· 早报 zaochao（每日简报）
  ↓
模型层（三级分层，见 §4）
```

### 3.3 一次典型任务的流转

以「帮我整理本周学习笔记并出一份简报」为例：

1. **中书省**接收模糊指令 → 拆解为「读取笔记 → 提炼要点 → 生成简报」三步方案；
2. **门下省**审核方案：检查是否有遗漏来源、简报格式是否符合既有模板 → 通过；
3. **尚书省**调度：笔记处理派给工部，简报生成派给礼部；
4. 执行结果回传，**早报**在次日晨间汇总推送。

关键点：**用户只面对一个入口，复杂度被组织结构吸收了**。

---

## 4. 关键设计决策

### D1：模型三级成本分层

不是「越强越好」，而是「什么任务配什么模型」：

| 层级 | 模型 | 分配的 Agent | 分配逻辑 |
|------|------|-------------|---------|
| T1 | qwen3.5-plus | 三省 + 户部/刑部/吏部/早报 | 决策、审核、核算——错误代价高的环节 |
| T2 | qwen3-coder-plus | 礼部 | 文案质量要求高，但不需要最强推理 |
| T3 | qwen3-coder-next | 兵部/工部/太子 | 高频工程任务——量大、单次价值低 |

**决策依据**：把「任务价值 × 调用频次」做成隐式矩阵。决策链路调用少但错不起 → 旗舰；工程链路调用频繁但可重试 → 轻量。这与产品定价中的「分层服务」是同一个思维模型。

### D2：审核链路（门下省）独立于生成链路

备选项是让尚书省自查自审。放弃的原因：**同一个上下文里的自查会被自己的推理惯性带跑**。独立的审核 Agent 用干净的上下文看方案，拦截率才有意义。代价是每次任务多一轮调用——用 T1 模型的成本换质量下限，值得。

### D3：三级 fallback 的可用性设计

模型供应商是最大的单点故障源。配置了自动降级链：

```
主：阿里云百炼 qwen3.5-plus
 → 备：qwen-portal coder-model
   → 应急：CLIProxyAPI gpt-5.3-codex
```

设计原则：**可用性优先于单次回答质量**。降级到备用模型时能力有折损，但「在线的 80 分」好过「离线的 100 分」。

### D4：Agent 粒度 —— 为什么 11 个不算多

被问过「11 个 Agent 会不会过度设计」。判断标准是**职责是否需要独立的系统提示词与模型配置**：礼部的文案腔调和工部的代码规范没有交集，合并只会让提示词臃肿。但低频 Agent（太子、早报）确实存在常驻浪费——这是已知取舍，见 §6。

---

## 5. 运营现状

- 系统自 2026-03 上线，云服务器 systemd 常驻，7×24 运行；
- 期间经历模型供应商 token 过期、备用通道切换等真实故障，均未造成长期离线；
- 沉淀了一套运维 SOP：服务重启、日志排查、token 轮换。

---

## 6. 复盘：如果重来

诚实的部分往往是最有价值的部分：

1. **监控告警应该第一天就有**。上线时没有可用性监控，一次实例 CPU 异常导致端口不监听，是我自己发现而不是系统报警。正确顺序：先监控，后功能。
2. **Token 生命周期要自动化**。OAuth token 过期目前靠手动轮换（甚至靠「从别的 Agent 复制有效 token」的土办法）。这是典型的「手动方案能跑就不想改」的技术债。
3. **配置即代码**。Agent 配置散落在服务器上的 JSON 里，应该进 git 做版本管理（脱敏后）。配置回滚能力和代码一样重要。
4. **常驻改按需**。太子、早报这类低频 Agent 更适合事件触发唤醒，常驻是花钱买懒惰。

---

## 7. 这个案例证明了什么

对应 AI 产品经理的核心能力：

| 能力 | 证据 |
|------|------|
| 系统设计 | 三层架构 + 11 个 Agent 的职责划分 |
| 成本工程 | 三级模型分层的「任务价值 × 频次」分配逻辑 |
| 可靠性设计 | 三级 fallback + 可用性优先的取舍原则 |
| 质量机制 | 独立审核链路（决策/执行分离） |
| 运维与迭代 | 真实故障处置 + 诚实的复盘清单 |

---

*相关案例：[CASE-002 AI 编程工具深度测评](../index.html#cases)（撰写中）· [CASE-003 数据研究工作台](../index.html#cases)（PRD 进行中）*