2026-08-02
三省六部制 Multi-Agent：可换装的制度化智能体组织
核心 Idea
把古代政治制度的组织结构直接当作 multi-agent 系统的编排架构。Agent 必须严格遵循职位职责，不能越权；用户扮演"皇帝"，只负责下达任务（上谕）、审批（朱批/驳回）、阅取汇报（奏章）。
与常规 multi-agent 系统（随意拆几个 role 拼一个 pipeline）的本质区别：
- 制度是一等公民：系统支持多种制度"换装"，每种制度定义完整的角色体系、职权边界、通信协议、汇报链路。
- 权力制衡内置：不是"流水线式"的接力，而是有审核、有驳回、有复审的真实治理结构。
- 职位即约束：Agent 的行为边界由制度严格限定，越权在系统层面被拦截，而不是靠提示词自觉。
制度一：唐代三省六部制
组织映射
┌─────────────────┐
│ 皇 帝 (用户) │ ← 上谕 / 朱批 / 阅奏章
└────────┬────────┘
┌────────▼────────┐
│ 中书省 · 拟旨 │ ← Planner：把上谕变成可执行方案（只负责想）
└────────┬────────┘
┌────────▼────────┐
│ 门下省 · 封驳 │ ← Reviewer：审核方案，有权打回重拟（只负责审）
└────────┬────────┘
┌────────▼────────┐
│ 尚书省 · 奉旨 │ ← Orchestrator：拆解任务、分派六部（只负责派）
└────────┬────────┘
┌──────────┬────────┼────────┬──────────┬──────────┐
┌──▼───┐ ┌──▼───┐ ┌──▼───┐ ┌──▼───┐ ┌──▼───┐ ┌──▼───┐
│ 吏部 │ │ 户部 │ │ 礼部 │ │ 兵部 │ │ 刑部 │ │ 工部 │
│人事调配│ │资源预算│ │文档规范│ │部署安全│ │测试质检│ │实现构建│
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘
└──────────┴────────┴────────┴──────────┴──────────┘
│ 复奏（结果上行）
┌────────▼────────┐
│ 皇帝阅示 (用户) │
└─────────────────┘
制度机制 → 现代对应
| 唐代机制 | 现代对应 | 价值 |
|---|---|---|
| 事权分离（中书拟/门下审/尚书行） | Plan → Review → Execute 三权分立 | 杜绝"自写自审"，低质量方案进不了执行 |
| 封驳权（门下省驳回诏令） | 硬性 quality gate + 驳回理由 | 审核不只是打勾，必须给出结构化反馈 |
| 职位边界（各司其职） | 每职位独立 system prompt + IO schema | 越权被系统拦截，而非靠模型自觉 |
| 奏章/敕令格式 | 上下行固定协议（结构化消息） | 通信协议即制度的一部分 |
| 政事堂会议（三省长官合议） | 顶层多 agent 会商（廷议模式） | 重大事项先辩论再上报 |
| 品级官阶 | 模型 tiering（决策用强模型，执行用快模型） | 决策贵精、执行贵快 |
制度二：郡县制（研究方向 / 管理内容即郡县）
用户已有方向：把研究方向和日常管理内容当作"郡县"来治理。
- 每个研究方向（LLM 算子 / Agent 测试 / 博客 / 政务报送 / 数学项目…）= 一个郡/县
- 郡县有自己的"太守/县令"Agent，负责该方向日常事务自治
- 郡县之间平级、不相隶属（郡县制的核心），需要跨郡协调时上报中央（皇帝）
- 皇帝只关注：郡县自治不了的大事、跨郡冲突、最终成果汇报
- 优点：天然贴合"多个并行研究项目"的组织方式，每个方向有专职 Agent 长期跟踪，不必每次都从零开始
动态制度核心设计（未来要做的事）
- 制度定义层：每种制度 = 一份结构化定义（角色清单 / 层级关系 / 职权边界 / 消息协议 / 汇报链 / 审批节点）
- 运行层：通用的流程引擎读取制度定义，驱动 Agent 流转
- 换装能力：同一套 Agent 底层，换一份制度定义就换一套组织方式
- 约束强制：职位边界、汇报链路在运行层强制校验，违反即拦截
- 皇帝视图：用户只看最终汇报 + 关键审批点，过程全程留痕可查
待定问题（下次继续）
- 底层实现：自研 Python 编排引擎 / 基于 Hermes delegate_task / 基于 NanoHarness
- 第一个落地场景：代码任务全流程验证（需求→设计→评审→实现→测试）
- 皇帝参与度：每步朱批 vs 只审最终奏章