# 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 才是产品。 光湖标准定义方向，代码仓库实现方向。 先借助成熟开源能力启动， 再逐步替换， 最终完成光湖自己的语言人格驱动操作系统。 ```