pj0235-eai_agentplatform/docs/2026-09-17_六层架构与三对象建设重点阶段性复盘.md

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

日期：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. “先强对象，再补关系”是当前阶段更合理的优先级

这个判断成立。

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

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

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

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

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

这个判断成立。

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

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

不应盲目学习：

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

---

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

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

这个推导证据不足。

三个对象重要，说明：

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

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

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

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

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

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

更准确的表达应为：

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

也就是说：

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

---

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

4.1 六层架构继续成立

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

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

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

对象层（Expert / Skill / App）

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

4.2 六层架构仍然有意义

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

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

因此它仍应继续作为：

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

而不是被轻易推翻。

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

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

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

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

---

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

1. 专员

当前优先级应放在：

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

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

2. 技能

当前优先级应放在：

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

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

3. 应用

当前优先级应放在：

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

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

---

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

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

更准确的判断是：

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

因此当前应坚持：

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

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

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

---

七、与 AionUi 的客观比较

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

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

因此：

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

换句话说：

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

---

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

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

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

最终可统一表述为：

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