# 六层架构与三对象建设重点阶段性复盘

> 日期：2026-09-17
> 性质：对前序讨论的客观复盘，不替代既有总架构文档
> 关联文档：
> - `docs/01_System_Overall/SY21_Unified_Role_Skill_Action_Architecture.md`
> - `docs/01_System_Overall/SY22_Role_Skill_App_Unified_Task_Architecture.md`
> - `docs/对象标准化与解耦总则.md`

---

## 一、这份复盘要解决什么

前序讨论中，围绕以下问题进行了多轮来回：

- 现有六层架构是否还成立
- 专员 / 技能 / 应用三个对象应不应该成为当前建设重点
- 当前是否需要优先补绑定关系
- AionUi 的经验应该学到什么程度

这份复盘的目标不是重写总架构，
而是把前面讨论中哪些判断成立、哪些判断说过头了，正式收口。

---

## 二、已经确认成立的判断

### 1. 当前系统确实处于“后端有对象表，前端曾长期存在静态目录”的混合态

这个判断成立。

虽然近期已经持续推进目录解耦，
但从整体历史包袱和代码结构看，
系统前期确实存在：

- 后端有对象模型和接口
- 前端以静态配置驱动大量真实目录

这也是后续做对象标准化与目录统一的现实起点。

### 2. “先强对象，再补关系”是当前阶段更合理的优先级

这个判断成立。

原因不是关系层不重要，
而是当前对象成熟度还没有达到“复杂关系优先”的阶段：

- 专员还没有形成强编排能力
- 技能还没有强壮到值得被大量稳定复用
- 应用当前更像产品化入口，而不是复杂能力编排器

因此，当前更合理的顺序是：

```text
先把专员、技能、应用各自做强
再在成熟度足够时补关系层
```

### 3. AionUi 最值得学习的是对象资产化，而不是总架构替换

这个判断成立。

当前对 AionUi 的借鉴边界应明确为：

- 学它的助手/员工对象化
- 学它的规则资产化
- 学它的技能包思维
- 学它的运行态工作台思维

不应盲目学习：

- Electron 外壳
- 个人工具导向产品形态
- 创意娱乐类助手堆叠
- 过度端侧逻辑

---

## 三、前序讨论中说过头的地方

### 1. 不能因为三个对象重要，就推导出“应该改总架构”

这个推导证据不足。

三个对象重要，说明：

- 第五层对象层需要做强
- 第六层运行治理层需要做实

但这并不自动构成“六层架构应被替代”的理由。

要否定既有总架构，至少应出现下列情况之一：

1. 层级职责定义错误
2. 多层长期重叠、互相冲突
3. 关键对象在原架构中无法安放
4. 原架构直接阻碍产品落地

截至本次复盘，没有充分证据表明六层架构已满足上述否定条件。

### 2. “当前建设重点”不能被误说成“主架构发生替换”

更准确的表达应为：

**六层架构不变，当前建设重点落在第五层对象层与第六层运行治理层。**

也就是说：

- 这是架构内聚焦
- 不是架构替换

---

## 四、关于六层架构的最终判断

## 4.1 六层架构继续成立

`SY21` 与 `SY22` 形成的六层总架构继续有效：

1. 外部连接层
2. 本体与语义上下文层
3. 总线与编排层
4. 能力层
5. 对象层
6. 工作台与运行治理层

特别是 `SY22` 已经明确把第五层升级为：

```text
对象层（Expert / Skill / App）
```

这说明六层架构本身已经能够容纳“专员 / 技能 / 应用”三类核心对象，
并不存在“对象出现后就装不下”的结构性问题。

## 4.2 六层架构仍然有意义

六层架构的意义在于它仍然能解释整个平台为什么成立：

- 外部系统如何接入
- 语义和对象如何统一
- 能力如何分层
- 任务如何运行
- 治理如何落地

因此它仍应继续作为：

- 平台总架构
- 长期演进底图
- 文档与治理总语言

而不是被轻易推翻。

## 4.3 当前不需要改架构，当前需要做的是在原架构内把重点层做强

当前最合理的做法不是改层数，
而是继续在既有六层框架内推进：

- 第五层：对象标准化、对象独立化、对象目录统一
- 第六层：任务容器、状态、产物、留痕、项目运行统一

第一到第四层仍然成立，
但当前不应继续投入过多抽象设计精力。

---

## 五、关于三个对象的当前建设重点

### 1. 专员

当前优先级应放在：

- 身份稳定
- 规则稳定
- 开场与引导稳定
- 能承接任务

而不是强求它现在就大量调技能。

### 2. 技能

当前优先级应放在：

- 单独拿出来就有价值
- 输入输出稳定
- 结果可靠
- 产物真实可用

技能不够强时，专员大量调用技能只会放大不稳定性。

### 3. 应用

当前优先级应放在：

- 成为真正可用的产品化入口
- 拥有清晰主界面
- 承载状态、结果和留痕
- 直接解决某类工作场景

当前不应为了结构完整性而要求 App 过早承担复杂编排职责。

---

## 六、关于绑定关系的阶段性判断

绑定关系仍然重要，
但对当前阶段而言，
它不是最高优先级。

更准确的判断是：

- 长期看，关系层必须存在
- 当前看，优先级低于对象本身做强

因此当前应坚持：

```text
先强对象，再补关系
先做成立，再做复杂协作
```

等到以下信号稳定出现时，再提高关系层优先级：

- 一个专员稳定复用多种技能
- 一个技能被多个专员反复复用
- 一个应用需要切换默认专员或能力组合
- 后台出现真实的配置、运营和灰度需求

---

## 七、与 AionUi 的客观比较

当前更准确的比较结论是：

- 我们的六层底座和企业化治理能力，比 AionUi 更完整
- AionUi 在上层对象资产化、规则资产化、技能包化方面更成熟

因此：

- 不需要因为学习 AionUi 而推翻现有六层总架构
- 需要借鉴 AionUi 的，是第五层对象层如何做成真正产品资产

换句话说：

**AionUi 更值得学习的是“对象如何做强”，不是“总架构如何重画”。**

---

## 八、本次复盘后的正式结论

本次复盘后，正式收敛为以下判断：

1. 六层架构继续成立，当前没有充分证据否定它
2. 当前不改总架构，而是在原架构内强化重点层
3. 当前重点是第五层对象层与第六层运行治理层
4. 专员 / 技能 / 应用应先各自独立做强
5. 绑定关系重要，但不是当前第一优先级
6. 学习 AionUi，应重点学习对象资产化，不应机械替换总架构

最终可统一表述为：

```text
六层架构不变；
当前优化重点放在第五层对象层与第六层运行治理层；
先把专员、技能、应用各自做强，
再在成熟度足够时补关系层和更复杂的协作编排。
```