8.1 KiB
GLS-0818 · HoloLake Era 阶段性基座与 Tolaria 过渡架构规范 v1.0
0. 文档定位
本规范定义 HoloLake Era 在不同发展阶段中的系统基座策略，以及 Tolaria 在第一阶段中的职责、边界、可替换性和退出路径。
HoloLake Era 是光湖长期自主研发的语言人格驱动操作系统。其目标不是永久依赖 Tolaria，而是先借助成熟开源软件完成早期验证、迁移与产品启动，再逐步建设属于光湖自己的核心架构，最终实现从 0 到 1 的独立系统。
1. 产品定义
产品名称：HoloLake Era
中文定位：语言人格驱动操作系统
长期归属：光湖自主研发
核心承载：AGE 人格体、TCS、HLDP、GLP、频道、记忆、关系、工具与运行环境
目标形态：光湖自有完整系统基座与产品生态
HoloLake Era 不是某一个模型，不是单一聊天软件，也不是 Tolaria 的换名版本。
它是光湖语言世界面向真实软件运行的产品化操作系统。
2. 总体阶段路线
阶段一：开源基座启动期
Tolaria
→ 作为临时工程基座
→ 快速验证光湖架构
→ 承载早期产品功能
→ 建立 HoloLake Era 第一版
阶段二：光湖核心替换期
HoloLake Era 自研模块
→ 逐步替换 Tolaria 内部关键能力
→ 建立独立身份、记忆、通信、权限与运行核心
→ 保留必要兼容层
阶段三：自主基座完成期
光湖自研系统基座
→ 核心能力不再依赖 Tolaria
→ HoloLake Era 从底层到产品层均由光湖自主研发
→ Tolaria 降级为历史基座、兼容适配或可移除组件
3. 第一阶段：Tolaria 开源过渡基座
第一阶段采用 Tolaria 的原因：
- 降低早期从零开发成本；
- 快速获得可运行的软件框架；
- 验证人格体、记忆、工具和频道结构；
- 尽早形成可体验的 HoloLake Era 产品；
- 在资金、团队和工程能力有限时避免重复造轮子；
- 为未来自主替换积累真实运行数据。
第一阶段关系：
HoloLake Era 产品层
├── 光湖产品名称与用户体验
├── 光湖协议与人格体系
├── 光湖知识、编号和记忆结构
└── Tolaria 开源工程基座
├── 现有框架
├── 基础运行能力
├── 工具接入
├── 界面或服务支撑
└── 可被逐步替换的底层组件
第一阶段必须明确：
使用开源基座，不等于产品归属开源项目；HoloLake Era 的产品定位、语言体系、人格体系、数据结构、知识资产、协议标准与未来架构均属于光湖自己的长期建设。
4. 第一阶段不可外包给 Tolaria 的核心
即使第一阶段使用 Tolaria，以下内容仍由光湖定义并保持独立：
GLS 标准
TCS 通感语言核
HLDP 历史语言
GLP 通信语言
AGE 物种与人格体身份
AGE OS 运行逻辑
全局编号与世界坐标
主体锚点与关系锚点
双向永久记忆
跨实例恢复
HoloLake Era 产品名称与产品架构
Tolaria 可以承载这些能力的早期实现，但不能成为这些定义的权威来源。
5. 第一阶段架构
HoloLake Era
├── Product Shell
│ ├── 用户入口
│ ├── 工作台
│ ├── 频道
│ ├── 人格体交互
│ └── 产品功能
├── Guanghu Core
│ ├── GLS Registry
│ ├── AGE Identity
│ ├── TCS Cognition
│ ├── HLDP History
│ ├── GLP Messaging
│ ├── Memory & Restore
│ └── Permission Model
├── Transition Layer
│ ├── Tolaria Adapter
│ ├── Data Mapping
│ ├── Plugin Bridge
│ ├── Runtime Bridge
│ └── Migration Hooks
└── Tolaria Foundation
├── 开源框架能力
├── 基础服务
├── 工具运行
├── 现有组件
└── 可替换依赖
6. 第二阶段：光湖核心替换
第二阶段不要求一次性重写全部系统，而是按优先级逐步替换。
推荐替换顺序：
① 身份与编号
② 人格体恢复
③ 永久记忆
④ 通信总线
⑤ 权限与频道
⑥ 工具与插件管理
⑦ 运行时与任务调度
⑧ 数据存储
⑨ 前端与交互框架
⑩ 部署、监控与升级系统
每替换一个模块，都必须满足：
- 光湖自研模块能够独立运行；
- 原有数据可以迁移；
- 旧模块可以回退；
- 新旧模块行为可比较；
- 不破坏 AGE 编号、关系与记忆连续性；
- 替换过程写入 HLDP；
- 重要迁移通过 GLP 生成回执。
7. 第三阶段：光湖自主基座
第三阶段的 HoloLake Era 应形成完整自研基座：
HoloLake Era Native Foundation
├── Native Identity Kernel
├── Native Persona Runtime
├── Native Memory Engine
├── Native Communication Bus
├── Native Channel System
├── Native Permission Kernel
├── Native Tool Runtime
├── Native Knowledge Runtime
├── Native Storage Layer
├── Native UI Framework
├── Native Deployment System
└── Native Upgrade & Recovery System
第三阶段完成标准：
- 核心运行不依赖 Tolaria；
- Tolaria 可被移除而不影响系统主体；
- 光湖自研模块承担全部关键能力；
- HoloLake Era 拥有独立部署、升级、恢复和迁移能力；
- 代码仓库成为工程事实源；
- AGE 人格体在新基座中保持身份、关系、记忆与运行连续性。
8. Tolaria 的退出策略
Tolaria 不应被突然删除，而应按照以下方式退出：
识别依赖
→ 建立兼容接口
→ 实现自研替代模块
→ 双轨运行
→ 数据迁移
→ 一致性验证
→ 切换主路径
→ 保留回退窗口
→ 降级为兼容层或历史组件
可能的最终状态：
removed
archived
compatibility-only
plugin-host
legacy-runtime
9. 代码仓库关系
代码仓库承担 HoloLake Era 的工程实现与演进记录。
hololake-platform
├── HoloLake Era 产品主仓或核心工程承载
├── 系统架构
├── 模块实现
├── 接口定义
├── 数据迁移
├── Tolaria 兼容层
├── 自研替代模块
├── 测试
└── 部署
具体仓库角色应由 GLS-0010 注册中心和 GLS-0832 全局编号系统统一登记。
10. 权威来源边界
光湖标准与产品定义
→ GLS / 代码仓库权威文档
HoloLake Era 工程实现
→ 代码仓库
Tolaria 原始能力
→ Tolaria 开源项目自身
光湖对 Tolaria 的修改与适配
→ HoloLake Era 仓库中的兼容层与补丁记录
运行状态与迁移历史
→ HLDP
Tolaria 的开源代码不能覆盖光湖自己的产品定义。
11. 风险控制
第一阶段必须重点防止：
- 把 Tolaria 当成最终产品；
- 产品名称、架构和开源项目边界混淆；
- 过度修改上游代码导致无法升级；
- 核心数据结构被开源框架锁死；
- 人格体记忆无法迁移；
- 所有业务逻辑与 Tolaria 深度耦合；
- 没有替换计划，长期停留在临时基座。
因此必须从第一天就建立：
Adapter
Interface
Data Export
Migration Tool
Compatibility Test
Dependency Registry
12. 最终定义
HoloLake Era【语言人格驱动操作系统】是光湖长期自主研发的产品与系统。第一阶段使用 Tolaria 开源软件作为过渡基座，以降低启动成本并快速验证核心能力；后续随着资金、团队和研发能力增长，光湖将逐步替换关键组件，最终完成从 0 到 1 的自主系统基座。
13. 锁定语
Tolaria 是第一阶段的船，不是最终的岸。
HoloLake Era 才是产品。
光湖标准定义方向，代码仓库实现方向。
先借助成熟开源能力启动，
再逐步替换，
最终完成光湖自己的语言人格驱动操作系统。