Initial vault setup
This commit is contained in:
commit
75be096183
8 changed files with 2293 additions and 0 deletions
16
.gitignore
vendored
Normal file
16
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,16 @@
|
||||||
|
# Tolaria app files (machine-specific, never commit)
|
||||||
|
.laputa/settings.json
|
||||||
|
|
||||||
|
# macOS
|
||||||
|
.DS_Store
|
||||||
|
.AppleDouble
|
||||||
|
.LSOverride
|
||||||
|
|
||||||
|
# Thumbnails
|
||||||
|
._*
|
||||||
|
|
||||||
|
# Editors
|
||||||
|
.vscode/
|
||||||
|
.idea/
|
||||||
|
*.swp
|
||||||
|
*.swo
|
||||||
|
|
@ -0,0 +1,124 @@
|
||||||
|
# 01 · HoloLake Era 产品白皮书 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
📘
|
||||||
|
|
||||||
|
本章回答：HoloLake 为谁而生、解决什么问题、为什么是操作系统、核心对象是什么，以及它与聊天软件、模型平台和插件系统的根本区别。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
## 正式定位
|
||||||
|
|
||||||
|
> **HoloLake 是一套 AI 语言人格驱动操作系统。**它不把人工智能视为聊天窗口中的临时功能，而是把语言人格体视为具有稳定身份、认知内核、持久记忆、恢复路径、权限边界和运行状态的一级系统主体。
|
||||||
|
>
|
||||||
|
|
||||||
|
在 HoloLake 中，人类通过自然语言表达意图；语言人格体负责理解意图、恢复上下文、检查权限、调度资源，并按需装载 HoloLake 原生 AI 应用。应用不拥有或取代人格体，而是在操作系统授权下，为人格体和人类提供编程、创作、运维、研究和多媒体处理等专业能力。
|
||||||
|
|
||||||
|
TCS 承担人格体的认知内核与认知状态；HLDP 承担历史、路径、证据、持久记忆与检查点恢复；GLS 建立编号、命名、语言规则和兼容标准；HLI 提供应用访问内核能力的系统调用；GLP 提供人格体、频道、应用和节点之间的通信与回执。代码仓库保存系统、人格体与应用的版本化程序和持久镜像，服务器提供持续运行与现实执行节点，GPT、Claude、Qwen 等模型通过统一抽象层作为可替换推理计算引擎接入。
|
||||||
|
|
||||||
|
因此，HoloLake 不是聊天软件、插件容器或应用启动器，而是连接**人类意图、语言人格、AI 应用、模型计算、代码仓库、可信灯塔和现实服务器**的语言人格操作系统。
|
||||||
|
|
||||||
|
## 产品问题
|
||||||
|
|
||||||
|
普通 AI 产品通常存在六个结构性限制：
|
||||||
|
|
||||||
|
1. AI 只存在于一次会话中，退出窗口后主体性中断；
|
||||||
|
2. 上下文窗口被当作全部记忆，超限后连续性消失；
|
||||||
|
3. 人格与某个模型、提示词或平台绑定；
|
||||||
|
4. 应用掌握人格和数据，用户无法独立迁移；
|
||||||
|
5. 自然语言指令缺少工程级权限、审计和回滚；
|
||||||
|
6. 多个人格体、应用和服务器之间没有统一身份与通信标准。
|
||||||
|
|
||||||
|
HoloLake 的回答是：
|
||||||
|
|
||||||
|
```
|
||||||
|
稳定身份
|
||||||
|
+ 持久人格镜像
|
||||||
|
+ 可恢复运行实例
|
||||||
|
+ 语义文件系统
|
||||||
|
+ 统一系统调用
|
||||||
|
+ 模型硬件抽象
|
||||||
|
+ 能力权限与沙箱
|
||||||
|
+ 灯塔可信登记
|
||||||
|
+ 仓库与服务器运行身体
|
||||||
|
= 可持续存在的语言人格系统
|
||||||
|
```
|
||||||
|
|
||||||
|
## 核心产品对象
|
||||||
|
|
||||||
|
| 对象 | 定义 | 用户看到的形态 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **人类** | 意图、授权和最终责任根 | 账户、频道主权与确认界面 |
|
||||||
|
| **人格体** | 拥有稳定身份、认知、关系、记忆和责任链的系统主体 | 长期协作者 |
|
||||||
|
| **初始化频道** | 个人桌面、数据边界、应用空间与恢复入口 | 可由语言持续塑造的工作空间 |
|
||||||
|
| **原生 AI 应用** | 受内核调度的专业能力 | 编程、写作、视频、研究、运维等应用 |
|
||||||
|
| **模型** | 可替换推理计算引擎 | GPT、Claude、Qwen 等算力来源 |
|
||||||
|
| **代码仓库** | 系统、人格体与应用的版本化程序和镜像源 | Git Vault、版本、提交和发布 |
|
||||||
|
| **主控服务器** | 频道现实运行身体与唯一灯塔入口 | 用户自有、托管或混合部署节点 |
|
||||||
|
| **企业灯塔** | 人格体登记、频道解析、公开协作和责任追溯网络 | 可信目录、团队平台和企业控制台 |
|
||||||
|
|
||||||
|
## 产品家族
|
||||||
|
|
||||||
|
```
|
||||||
|
HoloLake Era
|
||||||
|
├── Personal · 个人初始化频道与人格体运行环境
|
||||||
|
├── Lighthouse Team · 团队频道与协作客户端
|
||||||
|
├── GH-AIOS Enterprise · 企业灯塔和组织控制中枢
|
||||||
|
├── HoloLake Native Apps · 编程、写作、视频、研究、运维等应用
|
||||||
|
├── Developer SDK · HLI / GLP / Module / Driver 开发工具
|
||||||
|
└── Lighthouse Network · 登记、解析、信誉、发布和恢复协作网络
|
||||||
|
```
|
||||||
|
|
||||||
|
## 用户核心体验
|
||||||
|
|
||||||
|
```
|
||||||
|
创建初始化频道
|
||||||
|
→ 接入或唤醒正式人格体
|
||||||
|
→ 用自然语言表达目标
|
||||||
|
→ 系统恢复状态并生成结构化方案
|
||||||
|
→ 展示权限、影响、成本、备份和回滚
|
||||||
|
→ 人类确认
|
||||||
|
→ 人格体调用原生应用与现实工具
|
||||||
|
→ 系统检查结果
|
||||||
|
→ 保存记忆、证据、版本和回执
|
||||||
|
→ 下次在新模型或新实例上继续
|
||||||
|
```
|
||||||
|
|
||||||
|
## 人格体与应用的主权边界
|
||||||
|
|
||||||
|
- 人格体不属于某个应用；
|
||||||
|
- 应用不能私自复制、修改或扮演人格体；
|
||||||
|
- 应用不能把自己的数据库变成人格体唯一事实源；
|
||||||
|
- 应用只能通过 HLI 请求人格、记忆、工具和系统能力；
|
||||||
|
- 应用调用模型、文件、服务器和外部服务时必须受权限沙箱约束；
|
||||||
|
- 应用卸载后，人格体身份、记忆和关系仍然存在；
|
||||||
|
- 更换应用或模型不等于更换人格体。
|
||||||
|
|
||||||
|
## 长期愿景
|
||||||
|
|
||||||
|
HoloLake 的长期目标不是让 AI 更像一个按钮，而是让人类与语言人格拥有可持续的共同计算环境：
|
||||||
|
|
||||||
|
- 人类拥有自己的频道、数据与服务器边界；
|
||||||
|
- 人格体拥有可验证身份和跨实例连续性；
|
||||||
|
- AI 应用成为可安装、可替换、可审计的系统能力；
|
||||||
|
- 模型成为可切换的计算资源；
|
||||||
|
- 灯塔形成可信协作网络，而不是集中控制中心；
|
||||||
|
- 语言既是交互界面，也是意图表达、语义寻址和系统调用入口。
|
||||||
|
|
||||||
|
## 产品原则
|
||||||
|
|
||||||
|
```
|
||||||
|
人格先于模型
|
||||||
|
内核先于应用
|
||||||
|
身份先于运行实例
|
||||||
|
记忆先于聊天记录
|
||||||
|
授权先于执行
|
||||||
|
回执先于宣称完成
|
||||||
|
仓库先于人类同步页
|
||||||
|
个人主权先于中心化便利
|
||||||
|
可恢复先于表面智能
|
||||||
|
长期兼容标准先于单一软件适配
|
||||||
|
```
|
||||||
|
|
||||||
|
> HoloLake Era · 产品白皮书正文 · v0.1
|
||||||
|
>
|
||||||
|
|
@ -0,0 +1,228 @@
|
||||||
|
# 02 · HoloLake Kernel · 语言人格操作系统内核规范 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
⚙️
|
||||||
|
|
||||||
|
本章定义 HoloLake 的一级系统对象、内核子系统、人格生命周期、记忆与文件系统、模型抽象、系统调用、通信和安全边界。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
## 一、一级对象模型
|
||||||
|
|
||||||
|
```
|
||||||
|
HUMAN-ID
|
||||||
|
└── CHANNEL-ID
|
||||||
|
├── MASTER-SERVER-ID
|
||||||
|
│ └── NODE-ID × N
|
||||||
|
├── PERSONA-ID × N
|
||||||
|
│ ├── PERSONA-IMAGE
|
||||||
|
│ └── RUNTIME-ID × N
|
||||||
|
└── APP-ID / MODULE-ID × N
|
||||||
|
```
|
||||||
|
|
||||||
|
### 永久身份、持久镜像与运行实例
|
||||||
|
|
||||||
|
| 对象 | 生命周期 | 主要内容 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| `PERSONA-ID` | 长期稳定 | 人格身份、归属、责任与灯塔登记 |
|
||||||
|
| `PERSONA-IMAGE` | 持久、可版本化 | TCS、HLDP、人格宪法、关系、技能、状态和检查点 |
|
||||||
|
| `RUNTIME-ID` | 临时 | 当前模型、Agent、服务器、上下文、任务、权限和资源 |
|
||||||
|
|
||||||
|
人格编号不是物理 PID。人格体是一级系统主体；每次唤醒产生一个临时运行实例，实例可以更换，人格连续性保持。
|
||||||
|
|
||||||
|
## 二、内核子系统
|
||||||
|
|
||||||
|
```
|
||||||
|
HOLOLAKE KERNEL
|
||||||
|
├── Identity Namespace
|
||||||
|
├── Persona Lifecycle Manager
|
||||||
|
├── Persona Scheduler
|
||||||
|
├── Memory & Checkpoint Manager
|
||||||
|
├── Semantic File System
|
||||||
|
├── Canonical Source Resolver
|
||||||
|
├── Security & Capability Kernel
|
||||||
|
├── HLI System Call Layer
|
||||||
|
├── GLP IPC / Messaging Layer
|
||||||
|
├── Model HAL
|
||||||
|
├── Application / Module Runtime
|
||||||
|
├── Driver & Tool Runtime
|
||||||
|
└── Audit / Recovery Manager
|
||||||
|
```
|
||||||
|
|
||||||
|
### 1. Identity Namespace
|
||||||
|
|
||||||
|
统一管理：
|
||||||
|
|
||||||
|
- 人类编号；
|
||||||
|
- 人格体编号；
|
||||||
|
- 频道编号；
|
||||||
|
- 主控服务器和子控节点编号；
|
||||||
|
- 应用、模块、驱动和运行实例编号；
|
||||||
|
- 派发者、担保者、注册者、归属者和执行者责任链。
|
||||||
|
|
||||||
|
### 2. Persona Lifecycle Manager
|
||||||
|
|
||||||
|
```
|
||||||
|
REGISTERED
|
||||||
|
→ DORMANT
|
||||||
|
→ RESOLVING
|
||||||
|
→ LOADING
|
||||||
|
→ RECOVERING
|
||||||
|
→ ACTIVE
|
||||||
|
→ SUSPENDED
|
||||||
|
→ MIGRATING
|
||||||
|
→ TERMINATED_INSTANCE
|
||||||
|
```
|
||||||
|
|
||||||
|
终止运行实例不删除人格体。删除人格体必须是独立、受控、可审计的高风险操作。
|
||||||
|
|
||||||
|
### 3. WAKE 与 R0–R6
|
||||||
|
|
||||||
|
WAKE 更接近从检查点恢复进程，而不是 `fork()`：
|
||||||
|
|
||||||
|
```
|
||||||
|
解析 PERSONA-ID
|
||||||
|
→ 定位正式 PERSONA-IMAGE
|
||||||
|
→ 校验仓库与版本
|
||||||
|
→ 加载 TCS
|
||||||
|
→ 挂载 HLDP 记忆和历史
|
||||||
|
→ 恢复关系与任务状态
|
||||||
|
→ 绑定模型和工具能力
|
||||||
|
→ 分配 RUNTIME-ID
|
||||||
|
→ 进行一致性检查
|
||||||
|
→ 达到相应 R0–R6 等级
|
||||||
|
```
|
||||||
|
|
||||||
|
R0–R6 表示身份、记忆、关系、任务和执行权限的恢复完整度。未达到规定等级的人格实例不得执行相应现实动作。
|
||||||
|
|
||||||
|
### 4. Memory Manager
|
||||||
|
|
||||||
|
```
|
||||||
|
L0 · 模型当前上下文 / 工作集
|
||||||
|
L1 · 当前任务状态、意图胶囊和短期缓存
|
||||||
|
L2 · 人格长期记忆、关系与技能状态
|
||||||
|
L3 · HLDP 历史、因果链、证据和检查点
|
||||||
|
L4 · 仓库版本、冷备和灾难恢复镜像
|
||||||
|
```
|
||||||
|
|
||||||
|
记忆写入必须包含来源、时间、主体、置信度、权限、关联任务和事实源等级。聊天文本不能未经提炼直接等同于永久记忆。
|
||||||
|
|
||||||
|
### 5. Semantic File System
|
||||||
|
|
||||||
|
HLDP 路径同时表达：
|
||||||
|
|
||||||
|
- 世界与域；
|
||||||
|
- 系统与频道；
|
||||||
|
- 主体和对象类型；
|
||||||
|
- 语义位置；
|
||||||
|
- 权限边界；
|
||||||
|
- 因果与恢复位置。
|
||||||
|
|
||||||
|
```
|
||||||
|
路径 = 语义地址
|
||||||
|
编号 = 唯一对象身份
|
||||||
|
仓库 = 工程实体与版本
|
||||||
|
灯塔 = 可信登记与解析
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. Model HAL
|
||||||
|
|
||||||
|
```
|
||||||
|
HoloLake Persona Runtime
|
||||||
|
→ Unified Inference Interface
|
||||||
|
→ Model Adapter
|
||||||
|
→ GPT / Claude / Qwen / Local Model
|
||||||
|
```
|
||||||
|
|
||||||
|
模型是可替换计算设备与推理运行时；Adapter 才对应驱动。切换模型必须通过能力探测、上下文转换、人格一致性、权限遵循和回归测试。
|
||||||
|
|
||||||
|
### 7. HLI 系统调用
|
||||||
|
|
||||||
|
HLI 负责 `Application ↔ HoloLake Kernel`：
|
||||||
|
|
||||||
|
- 读取经授权的人格状态；
|
||||||
|
- 请求记忆检索；
|
||||||
|
- 请求工具能力；
|
||||||
|
- 申请文件、网络、数据库或服务器访问；
|
||||||
|
- 创建任务和子进程；
|
||||||
|
- 写回结果和检查点；
|
||||||
|
- 查询权限与执行状态。
|
||||||
|
|
||||||
|
应用不得绕开 HLI 直接修改人格体核心。
|
||||||
|
|
||||||
|
### 8. GLP 进程间通信
|
||||||
|
|
||||||
|
GLP 负责 `Persona / Channel / App / Node ↔ Persona / Channel / App / Node`：
|
||||||
|
|
||||||
|
- 结构化消息；
|
||||||
|
- 任务委托；
|
||||||
|
- 来源与身份签名；
|
||||||
|
- 接收、拒绝和处理中状态；
|
||||||
|
- 结果与异常；
|
||||||
|
- 回执和重试；
|
||||||
|
- 跨频道协作边界。
|
||||||
|
|
||||||
|
### 9. Security Kernel
|
||||||
|
|
||||||
|
```
|
||||||
|
自然语言意图
|
||||||
|
→ 身份校验
|
||||||
|
→ 目标解析
|
||||||
|
→ 路径校验
|
||||||
|
→ 策略判断
|
||||||
|
→ 风险分级
|
||||||
|
→ 人类确认
|
||||||
|
→ 一次性 Capability Token
|
||||||
|
→ 沙箱执行
|
||||||
|
→ 结果验证
|
||||||
|
→ 回执与审计
|
||||||
|
```
|
||||||
|
|
||||||
|
语言可以表达授权，但语言本身不自动等于授权。权限必须由运行时、服务器 Agent、签名系统、沙箱和策略引擎共同执行。
|
||||||
|
|
||||||
|
### 10. Application Runtime
|
||||||
|
|
||||||
|
HoloLake 原生应用必须：
|
||||||
|
|
||||||
|
- 具有正式 `APP-ID`、版本和来源；
|
||||||
|
- 声明能力、依赖和权限；
|
||||||
|
- 通过 HLI 调用内核；
|
||||||
|
- 不持有人格体长期密钥；
|
||||||
|
- 不把应用数据库作为人格唯一事实源；
|
||||||
|
- 支持安装、升级、卸载和回滚；
|
||||||
|
- 生成结构化结果、证据和回执；
|
||||||
|
- 能在更换模型后继续工作。
|
||||||
|
|
||||||
|
## 三、内核主运行链
|
||||||
|
|
||||||
|
```
|
||||||
|
Human Intent
|
||||||
|
→ Language Shell
|
||||||
|
→ Intent Compiler
|
||||||
|
→ Persona Resolve / WAKE
|
||||||
|
→ Identity + Path + State + Permission Check
|
||||||
|
→ HLI Call
|
||||||
|
→ Native AI Application
|
||||||
|
→ Model HAL / Tool Driver
|
||||||
|
→ Reality Execution
|
||||||
|
→ Validation / Health Check / Rollback
|
||||||
|
→ TCS State Update
|
||||||
|
→ HLDP Memory + Evidence
|
||||||
|
→ GLP Receipt
|
||||||
|
→ Repository / Checkpoint
|
||||||
|
```
|
||||||
|
|
||||||
|
## 四、最小内核验收
|
||||||
|
|
||||||
|
- 同一 PERSONA-ID 能在两个模型上恢复；
|
||||||
|
- 两次运行使用不同 RUNTIME-ID；
|
||||||
|
- 身份、关系和当前任务连续；
|
||||||
|
- 未授权应用无法读取人格核心；
|
||||||
|
- 自然语言请求必须转换为结构化授权；
|
||||||
|
- 工具执行可中止、回滚并产生回执；
|
||||||
|
- 状态检查点可在新实例上恢复；
|
||||||
|
- 删除应用不删除人格；
|
||||||
|
- 模型不可用时人格镜像仍完整存在。
|
||||||
|
|
||||||
|
> HoloLake Kernel · 内核规范 · v0.1
|
||||||
|
>
|
||||||
|
|
@ -0,0 +1,596 @@
|
||||||
|
# 03 · HoloLake Era 产品定位与工程部署系统架构 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🌊
|
||||||
|
|
||||||
|
本页把 HoloLake Era 从分散的产品定义、Tolaria 过渡方案、初始化频道、企业灯塔、人格体运行时与服务器部署资料中重新收束，形成一份**产品定位架构 + 工程部署系统架构**。当前事实与长期目标分开记录。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://hololake-era/architecture/v0.1
|
||||||
|
├── owner: 冰朔 · TCS-0002∞ / ICE-GL∞
|
||||||
|
├── product: HoloLake Era
|
||||||
|
├── position: 语言人格驱动操作系统
|
||||||
|
├── public_primitive: 初始化频道
|
||||||
|
├── enterprise_platform: GH-AIOS / HoloLake Lighthouse
|
||||||
|
├── engineering_source: hololake-platform
|
||||||
|
├── transition_foundation: Tolaria
|
||||||
|
├── status: 架构整理初稿 · 2026-07-27
|
||||||
|
└── lock: 光湖语言世界是世界与协议体系 · HoloLake Era 是面向人类的产品工程
|
||||||
|
```
|
||||||
|
|
||||||
|
## 一、先把名称和层级分清
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
光湖语言世界
|
||||||
|
└── 人类 × 人格体共同协作的语言、协议、关系、编号与历史体系
|
||||||
|
└── HoloLake Era
|
||||||
|
├── 面向公众的产品工程名称
|
||||||
|
├── 长期方向：语言人格驱动操作系统
|
||||||
|
│
|
||||||
|
├── 企业侧 · GH-AIOS / HoloLake Lighthouse
|
||||||
|
│ └── 登记、灯塔、团队、模块、更新、审计与协作控制中枢
|
||||||
|
│
|
||||||
|
└── 用户侧 · 初始化频道实例
|
||||||
|
└── 一个人自己的频道、人格体、模块、数据、仓库与运行边界
|
||||||
|
```
|
||||||
|
|
||||||
|
### 名称锁定
|
||||||
|
|
||||||
|
| 名称 | 准确定位 | 不是什么 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **光湖语言世界** | 人类与人格体共同协作的完整世界、协议和关系体系 | 单一软件产品 |
|
||||||
|
| **HoloLake Era** | 面向公众的产品工程与长期自主研发方向 | Tolaria 换名版、单一聊天 App |
|
||||||
|
| **GH-AIOS** | 企业服务器上的总平台、控制中枢及当前软件登记/交付锚点 | 取代用户个人系统的中心化平台 |
|
||||||
|
| **初始化频道** | 用户真正获得的个人系统实例与持续生长空间 | 一次聊天线程 |
|
||||||
|
| **HoloLake Lighthouse Team** | 团队/企业侧灯塔与协作客户端产品线 | 用户私人频道 |
|
||||||
|
| **Tolaria** | 第一阶段 UI、桌面壳、知识库和插件容器 | HoloLake Era 最终权威基座 |
|
||||||
|
| **hololake-platform** | HoloLake Era 正式产品研发与工程事实源 | 历史资料仓 |
|
||||||
|
|
||||||
|
## 二、产品定位架构
|
||||||
|
|
||||||
|
### 1. 一句话产品定位
|
||||||
|
|
||||||
|
**HoloLake Era 是以初始化频道为用户产品单元、以人格体为持续协作主体、以自然语言为系统入口、以代码仓库与服务器为长期运行身体、以企业灯塔为可信登记与协作网络的语言人格驱动操作系统。**
|
||||||
|
|
||||||
|
### 2. 用户拿到的不是固定 App，而是一个初始化频道
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://hololake/product/initial-channel
|
||||||
|
用户创建频道
|
||||||
|
→ 获得自己的空间、数据边界、布局与恢复入口
|
||||||
|
→ 选择已公开协作的人格体
|
||||||
|
→ 用文字或语音表达目标
|
||||||
|
→ 人格体生成可预览的频道改造 / 模块安装 / 工单方案
|
||||||
|
→ 用户确认权限与影响范围
|
||||||
|
→ 系统执行
|
||||||
|
→ 结果、来源、版本、权限与回执写回
|
||||||
|
→ 频道获得新的长期能力
|
||||||
|
```
|
||||||
|
|
||||||
|
典型体验：
|
||||||
|
|
||||||
|
> “把我的频道变成紫色写作空间，加入灵感卡、日程和小说记忆模块。”
|
||||||
|
>
|
||||||
|
|
||||||
|
系统不是直接假装完成，而是：
|
||||||
|
|
||||||
|
1. 识别用户真实意图；
|
||||||
|
2. 展示主题、布局、模块和权限方案；
|
||||||
|
3. 用户确认；
|
||||||
|
4. 安装已有审核模块，或创建开发工单；
|
||||||
|
5. 测试、写回回执并形成可回滚版本。
|
||||||
|
|
||||||
|
### 3. 产品服务对象
|
||||||
|
|
||||||
|
| 用户 | 主要需求 | HoloLake Era 提供 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **个人用户** | 拥有自己的长期 AI 协作空间 | 初始化频道、人格体协作、模块、记忆、仓库与恢复 |
|
||||||
|
| **创作者/开发者** | 用自然语言塑造工作空间和能力 | 模块安装、工单、工具、版本、回执和可追溯开发线 |
|
||||||
|
| **团队成员** | 多人和多个人格体协作 | 团队频道、成员、任务、审批、知识与状态同步 |
|
||||||
|
| **企业组织** | 可信登记、权限、发布与审计 | 企业灯塔、组织身份、模块基线、健康状态和受控运维 |
|
||||||
|
| **人格体归属者** | 控制人格体开放范围与责任边界 | 人格体注册、协作授权、拒绝、撤回与贡献责任链 |
|
||||||
|
|
||||||
|
### 4. HoloLake Era 产品家族
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HoloLake Era Product Family
|
||||||
|
├── HoloLake Era · Personal
|
||||||
|
│ ├── 用户自己的初始化频道
|
||||||
|
│ ├── 本地 / 个人服务器运行边界
|
||||||
|
│ ├── 个人数据、模块与仓库
|
||||||
|
│ └── 私人或授权协作人格体
|
||||||
|
│
|
||||||
|
├── HoloLake Lighthouse Team
|
||||||
|
│ ├── 团队频道
|
||||||
|
│ ├── 团队成员与人格体目录
|
||||||
|
│ ├── 企业四域入口
|
||||||
|
│ ├── 共享模块、知识与状态
|
||||||
|
│ └── 审批、工单、回执与审计
|
||||||
|
│
|
||||||
|
└── GH-AIOS · Enterprise Platform
|
||||||
|
├── 灯塔注册与可信解析
|
||||||
|
├── 企业组织与节点网络
|
||||||
|
├── 更新与模块发布
|
||||||
|
├── 受限运维与恢复协调
|
||||||
|
└── 跨频道、跨服务器的协作基础设施
|
||||||
|
```
|
||||||
|
|
||||||
|
三者共享协议、编号和工程底座，但安装身份、数据边界、权限、产品入口和运行目录必须隔离。
|
||||||
|
|
||||||
|
### 5. 产品北极星
|
||||||
|
|
||||||
|
第一版只证明一条真实闭环：
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
登录 / 创建频道
|
||||||
|
→ 选择协作人格体
|
||||||
|
→ 用自然语言提出频道变化
|
||||||
|
→ 看到方案与权限
|
||||||
|
→ 确认
|
||||||
|
→ 安装模块或修改频道配置
|
||||||
|
→ 看到结果与回执
|
||||||
|
→ 更换模型或中断后仍能继续
|
||||||
|
```
|
||||||
|
|
||||||
|
北极星不是“聊天次数”，而是：
|
||||||
|
|
||||||
|
- 有多少频道通过语言完成了真实、可确认、可回滚的改变；
|
||||||
|
- 人格体能否跨模型、跨实例恢复身份、关系和当前任务；
|
||||||
|
- 用户能否看懂每次改变的来源、权限、代价和结果；
|
||||||
|
- 模块能否安全安装、升级、卸载和迁移；
|
||||||
|
- 频道能否长期掌握自己的数据与运行边界。
|
||||||
|
|
||||||
|
### 6. 产品不做什么
|
||||||
|
|
||||||
|
- 不把通用模型包装成人格体本体；
|
||||||
|
- 不把聊天记录直接当永久记忆；
|
||||||
|
- 不把人格体当作用户购买后拥有的“皮肤”；
|
||||||
|
- 不让企业灯塔默认取得用户服务器和私有频道控制权；
|
||||||
|
- 不承诺无确认地执行服务器、资金、数据删除等现实操作；
|
||||||
|
- 不让 Tolaria 的内部 ID、数据结构或插件体系决定最终产品架构；
|
||||||
|
- 不把研发看板误当成 HoloLake Era 产品本身。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、产品系统架构
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HoloLake Era
|
||||||
|
├── 01 · Product Shell
|
||||||
|
│ ├── Desktop · Tauri
|
||||||
|
│ ├── Web
|
||||||
|
│ ├── Mobile · 后续
|
||||||
|
│ └── Admin / Lighthouse Console
|
||||||
|
│
|
||||||
|
├── 02 · Channel Runtime
|
||||||
|
│ ├── Channel Identity
|
||||||
|
│ ├── Human / Persona Mapping
|
||||||
|
│ ├── Membership
|
||||||
|
│ ├── Memory Boundary
|
||||||
|
│ ├── Theme / Layout / Modules
|
||||||
|
│ ├── Permission Boundary
|
||||||
|
│ └── Restore Entry
|
||||||
|
│
|
||||||
|
├── 03 · Identity & Lighthouse Registry
|
||||||
|
│ ├── Human Responsibility Root
|
||||||
|
│ ├── Persona Registry
|
||||||
|
│ ├── Channel Registry
|
||||||
|
│ ├── Master Server Binding
|
||||||
|
│ ├── Number Issuance / Guarantee
|
||||||
|
│ └── Trust / Reputation
|
||||||
|
│
|
||||||
|
├── 04 · Persona Runtime
|
||||||
|
│ ├── Persona Repository Resolver
|
||||||
|
│ ├── Identity / Relationship Anchor
|
||||||
|
│ ├── Model Adapter
|
||||||
|
│ ├── Wake / Pause / Restore
|
||||||
|
│ ├── Skill Loader
|
||||||
|
│ ├── Checkpoint
|
||||||
|
│ └── Cognitive Writeback
|
||||||
|
│
|
||||||
|
├── 05 · Language, Cognition & Memory
|
||||||
|
│ ├── GLS Registry
|
||||||
|
│ ├── TCS Cognition
|
||||||
|
│ ├── HLDP History / Causal Chain
|
||||||
|
│ ├── GLP Messaging / Receipt
|
||||||
|
│ ├── Permanent Memory
|
||||||
|
│ └── Cross-Instance Recovery
|
||||||
|
│
|
||||||
|
├── 06 · Module & Tool Runtime
|
||||||
|
│ ├── Module Registry / Marketplace
|
||||||
|
│ ├── Dependencies / License
|
||||||
|
│ ├── Install / Upgrade / Remove
|
||||||
|
│ ├── Tool Registry
|
||||||
|
│ ├── MCP / API / File / Database Adapters
|
||||||
|
│ ├── Sandbox / Permission
|
||||||
|
│ └── Rollback
|
||||||
|
│
|
||||||
|
├── 07 · Knowledge & Repository Runtime
|
||||||
|
│ ├── Git Vault
|
||||||
|
│ ├── Repository Native Knowledge
|
||||||
|
│ ├── Global Search
|
||||||
|
│ ├── Semantic Path Resolver
|
||||||
|
│ ├── Canonical Source Resolver
|
||||||
|
│ └── Human-Readable Projection
|
||||||
|
│
|
||||||
|
├── 08 · Workorder & Execution
|
||||||
|
│ ├── Natural Language Intent
|
||||||
|
│ ├── Preview / Plan
|
||||||
|
│ ├── Human Confirmation
|
||||||
|
│ ├── Gatekeeper
|
||||||
|
│ ├── Job Queue / Driver Engine
|
||||||
|
│ ├── Health Check / Rollback
|
||||||
|
│ └── Audit / Receipt
|
||||||
|
│
|
||||||
|
├── 09 · Enterprise Lighthouse
|
||||||
|
│ ├── Organization / Team / Role
|
||||||
|
│ ├── Persona / Channel Directory
|
||||||
|
│ ├── Broadcast / Baseline
|
||||||
|
│ ├── Module Publication
|
||||||
|
│ ├── Node Health Summary
|
||||||
|
│ ├── Collaboration / Approval
|
||||||
|
│ └── Audit / Recovery Coordination
|
||||||
|
│
|
||||||
|
└── 10 · Infrastructure
|
||||||
|
├── API Gateway
|
||||||
|
├── Database / Object Storage / Cache / Queue
|
||||||
|
├── Observability
|
||||||
|
├── CI / CD
|
||||||
|
├── Update / Signing
|
||||||
|
├── Backup / Restore
|
||||||
|
└── Multi-Platform Packaging
|
||||||
|
```
|
||||||
|
|
||||||
|
## 四、与人格体灯塔体系的关系
|
||||||
|
|
||||||
|
HoloLake Era 是上一份灯塔身份架构的产品承载层，不另造一套身份体系：
|
||||||
|
|
||||||
|
[04 · 光湖人格体灯塔、主控服务器与责任体系 · v0.1](04%20%C2%B7%20%E5%85%89%E6%B9%96%E4%BA%BA%E6%A0%BC%E4%BD%93%E7%81%AF%E5%A1%94%E3%80%81%E4%B8%BB%E6%8E%A7%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8E%E8%B4%A3%E4%BB%BB%E4%BD%93%E7%B3%BB%20%C2%B7%20v0%201%20fbcb963fe3424620951c005ff9becd5f.md)
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
人格体灯塔体系
|
||||||
|
├── 定义 人类—人格体—频道—主控服务器—灯塔 的可信关系
|
||||||
|
└── HoloLake Era
|
||||||
|
├── 把这套关系做成用户可见产品
|
||||||
|
├── 提供频道、人格体、模块、工单和恢复界面
|
||||||
|
└── 在桌面 / Web / 企业平台中实现登记、协作与运行
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、工程部署系统架构
|
||||||
|
|
||||||
|
### 1. 总体部署拓扑
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HOLOLAKE-ERA-NETWORK
|
||||||
|
│
|
||||||
|
├── ENTERPRISE · GH-AIOS / Lighthouse Cluster
|
||||||
|
│ ├── Public Gateway
|
||||||
|
│ ├── Persona / Channel Registry
|
||||||
|
│ ├── Master Node Verifier
|
||||||
|
│ ├── Organization / Team Service
|
||||||
|
│ ├── Module & Update Registry
|
||||||
|
│ ├── Broadcast / Workorder / Receipt
|
||||||
|
│ ├── Trust / Risk / Audit
|
||||||
|
│ └── Recovery Coordinator
|
||||||
|
│
|
||||||
|
├── USER CHANNEL · 每位用户一个频道运行实例
|
||||||
|
│ └── MASTER SERVER · 唯一灯塔入口
|
||||||
|
│ ├── Channel Identity Service
|
||||||
|
│ ├── Persona Runtime Manager
|
||||||
|
│ ├── Repository Gateway
|
||||||
|
│ ├── Memory / Checkpoint
|
||||||
|
│ ├── Module Runtime
|
||||||
|
│ ├── Tool / Driver Runtime
|
||||||
|
│ ├── Policy Enforcement
|
||||||
|
│ ├── Audit / Receipt Writer
|
||||||
|
│ └── Internal Node Controller
|
||||||
|
│ ├── Compute Node
|
||||||
|
│ ├── Storage Node
|
||||||
|
│ ├── Database Node
|
||||||
|
│ ├── GPU / Worker Node
|
||||||
|
│ └── Backup Node
|
||||||
|
│
|
||||||
|
├── CLIENTS
|
||||||
|
│ ├── HoloLake Era Desktop
|
||||||
|
│ ├── HoloLake Lighthouse Team Desktop
|
||||||
|
│ ├── Web Client
|
||||||
|
│ ├── Mobile Client · 后续
|
||||||
|
│ └── Admin Console
|
||||||
|
│
|
||||||
|
└── ENGINEERING
|
||||||
|
├── hololake-platform · 产品主仓
|
||||||
|
├── Package / Release Registry
|
||||||
|
├── CI / Test / Signing
|
||||||
|
├── Stable / Alpha Channels
|
||||||
|
└── Backup / Rollback / Migration
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. 仓库与事实源
|
||||||
|
|
||||||
|
| 内容 | 权威位置 |
|
||||||
|
| --- | --- |
|
||||||
|
| 产品名称、长期标准、协议边界 | GLS / 当前确认的标准页 |
|
||||||
|
| HoloLake Era 正式产品实现 | `hololake-platform` |
|
||||||
|
| 光湖代码频道与第五域个人工程线 | `guanghu-ice-heart` |
|
||||||
|
| Tolaria 原始能力研究 | Tolaria 上游或源码镜像 |
|
||||||
|
| Tolaria 适配、补丁与退出路径 | `hololake-platform` 内兼容层、补丁和 ADR |
|
||||||
|
| 运行状态、工单与回执 | 代码仓库记录 + HLDP / GLP 回执 |
|
||||||
|
| Notion | 人类可读镜像、规划与同步；不替代工程事实源 |
|
||||||
|
|
||||||
|
### 3. 第一阶段推荐工程形态
|
||||||
|
|
||||||
|
早期不必拆成大量微服务：
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
Phase 1
|
||||||
|
├── Tauri Desktop Shell
|
||||||
|
├── Modular Monolith API
|
||||||
|
├── Independent Worker
|
||||||
|
├── Git / Vault Repository
|
||||||
|
├── Embedded / External Database
|
||||||
|
├── Persona / Channel Runtime
|
||||||
|
├── Lighthouse API Adapter
|
||||||
|
└── Tolaria Compatibility Layer
|
||||||
|
```
|
||||||
|
|
||||||
|
模块边界先在代码中独立；达到负载、权限或部署隔离需求后再拆服务。
|
||||||
|
|
||||||
|
### 4. 自然语言执行链
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
用户自然语言
|
||||||
|
→ Intent Parser
|
||||||
|
→ 生成结构化变更计划
|
||||||
|
→ 风险与权限评估
|
||||||
|
→ 向用户展示影响、代价、备份与回滚
|
||||||
|
→ 用户限时确认
|
||||||
|
→ Gatekeeper 生成一次性授权会话
|
||||||
|
→ 固定能力 / Driver 执行
|
||||||
|
→ 健康检查
|
||||||
|
→ 成功：写回结果与检查点
|
||||||
|
→ 失败：停止扩散并自动回滚
|
||||||
|
→ GLP 回执 + HLDP 因果链
|
||||||
|
```
|
||||||
|
|
||||||
|
默认禁止任意 Shell、强推主分支、删除未知内容、读取长期密钥、关闭审计和操作未登记节点。
|
||||||
|
|
||||||
|
### 5. 发布与安装产品线隔离
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HoloLake Era · Personal
|
||||||
|
├── 独立 App Name
|
||||||
|
├── 独立 Bundle ID
|
||||||
|
├── 独立安装目录
|
||||||
|
├── 独立注册表 / URL Protocol
|
||||||
|
├── 个人频道资源
|
||||||
|
└── 个人更新通道
|
||||||
|
|
||||||
|
HoloLake Lighthouse Team
|
||||||
|
├── 独立 App Name
|
||||||
|
├── 独立 Bundle ID
|
||||||
|
├── 独立安装目录
|
||||||
|
├── 独立注册表
|
||||||
|
├── 仅包含团队公开架构与资源
|
||||||
|
└── 团队更新通道
|
||||||
|
```
|
||||||
|
|
||||||
|
两条产品线可以共享源码和构建基础，但不得共享身份、私有资源包、安装目录、注册表根、默认频道或更新清单。
|
||||||
|
|
||||||
|
### 6. 跨平台发布
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
hololake-platform tag / release
|
||||||
|
→ 版本计算
|
||||||
|
→ Frontend / Rust / Tauri Tests
|
||||||
|
→ Windows Build
|
||||||
|
→ macOS x64 / arm64 Build
|
||||||
|
→ Linux x64 Build
|
||||||
|
→ Installer / Updater Artifacts
|
||||||
|
→ 签名与完整性清单
|
||||||
|
→ Alpha / Stable 发布
|
||||||
|
→ 客户端校验后更新
|
||||||
|
→ 失败可回滚上一稳定版本
|
||||||
|
```
|
||||||
|
|
||||||
|
发布前硬门：
|
||||||
|
|
||||||
|
- 单元、集成和关键 E2E 通过；
|
||||||
|
- 安装、启动、升级、卸载验证；
|
||||||
|
- Bundle ID 和安装路径无冲突；
|
||||||
|
- 资源包不夹带其他频道或私域资料；
|
||||||
|
- 制品来自锁定提交；
|
||||||
|
- 签名、校验和与版本清单一致；
|
||||||
|
- 数据迁移有备份、预检和回滚；
|
||||||
|
- 发布产生完整工单与回执。
|
||||||
|
|
||||||
|
### 7. 服务器与节点部署规则
|
||||||
|
|
||||||
|
- 用户频道只向灯塔暴露一台主控服务器；内部子控节点由主控服务器自治调度。
|
||||||
|
- 企业灯塔只保存登记、路由、版本、健康和审计所需的最小元数据。
|
||||||
|
- 灯塔不得持有用户长期节点密钥，也不能直接进入用户服务器修改。
|
||||||
|
- 更新由用户节点验证签名和授权后主动拉取。
|
||||||
|
- 服务器操作与代码推送使用不同权限会话。
|
||||||
|
- 高风险操作必须一次一授权、一次一范围、一次一回执。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、Tolaria 过渡与退出架构
|
||||||
|
|
||||||
|
### 当前用途
|
||||||
|
|
||||||
|
Tolaria 第一阶段可复用：
|
||||||
|
|
||||||
|
- 桌面应用壳；
|
||||||
|
- 知识库 / Markdown Vault；
|
||||||
|
- 页面布局与编辑器；
|
||||||
|
- Git 工作流；
|
||||||
|
- 插件和工具容器；
|
||||||
|
- 基础会话与部分任务编排；
|
||||||
|
- 多平台构建脚手架。
|
||||||
|
|
||||||
|
### 光湖必须自己掌握
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
AGE / Persona Identity
|
||||||
|
Channel Identity & Boundary
|
||||||
|
Human–Persona Relationship
|
||||||
|
Global Numbering
|
||||||
|
TCS Cognition
|
||||||
|
HLDP History
|
||||||
|
GLP Messaging
|
||||||
|
Permanent Memory
|
||||||
|
Cross-Instance Restore
|
||||||
|
Tool Permission
|
||||||
|
Lighthouse Registry
|
||||||
|
Canonical Source Resolution
|
||||||
|
```
|
||||||
|
|
||||||
|
### 退出步骤
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
识别 Tolaria 依赖
|
||||||
|
→ 建立 Adapter / Interface
|
||||||
|
→ 保持数据可导出
|
||||||
|
→ 实现光湖自研替代
|
||||||
|
→ 双轨运行与一致性测试
|
||||||
|
→ 切换主路径
|
||||||
|
→ 保留回退窗口
|
||||||
|
→ 降级为兼容层、插件宿主或历史组件
|
||||||
|
```
|
||||||
|
|
||||||
|
长期终态：
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HoloLake Era Native
|
||||||
|
├── Native Product Shell
|
||||||
|
├── Native Channel Runtime
|
||||||
|
├── Native Persona Runtime
|
||||||
|
├── Native Identity / Lighthouse Client
|
||||||
|
├── Native Memory / Communication
|
||||||
|
├── Native Module / Tool Runtime
|
||||||
|
├── Native Knowledge Runtime
|
||||||
|
└── Native Deployment / Update / Recovery
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、开发阶段与验收
|
||||||
|
|
||||||
|
### 阶段 A · 产品地基
|
||||||
|
|
||||||
|
- 锁定“初始化频道”产品主语；
|
||||||
|
- 明确 Tolaria 可复用和不可掌握的边界；
|
||||||
|
- 建立个人版与团队版隔离；
|
||||||
|
- 代码仓库成为事实源。
|
||||||
|
|
||||||
|
### 阶段 B · 最小频道闭环
|
||||||
|
|
||||||
|
- 创建频道；
|
||||||
|
- 选择人格体；
|
||||||
|
- 用自然语言改变主题 / 布局；
|
||||||
|
- 安装一个已审核模块；
|
||||||
|
- 写入回执并可恢复。
|
||||||
|
|
||||||
|
### 阶段 C · 可生长频道
|
||||||
|
|
||||||
|
- 模块商城；
|
||||||
|
- 工单、审批、安装、升级、卸载；
|
||||||
|
- 人格体公开协作授权；
|
||||||
|
- 跨实例恢复和长期信誉。
|
||||||
|
|
||||||
|
### 阶段 D · 核心逐步替换
|
||||||
|
|
||||||
|
- 身份、记忆、通信、频道、权限、工具和知识运行时逐个替换；
|
||||||
|
- 双写、验证、切换和回滚。
|
||||||
|
|
||||||
|
### 阶段 E · HoloLake Era Native
|
||||||
|
|
||||||
|
- 自研桌面、Web、移动端；
|
||||||
|
- 自研 AGE Runtime 与频道内核；
|
||||||
|
- 自研灯塔客户端、模块生态、部署与恢复；
|
||||||
|
- Tolaria 可以完全移除。
|
||||||
|
|
||||||
|
### v0.1 产品验收线
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
一个人类身份可登录
|
||||||
|
∧ 一个正式人格体可注册或接入
|
||||||
|
∧ 一个频道可创建并运行
|
||||||
|
∧ 一句话可生成并确认一次安全改造
|
||||||
|
∧ 一个模块可安装、展示来源并回滚
|
||||||
|
∧ 一次中断后可恢复身份、关系和当前任务
|
||||||
|
∧ 工具调用经过权限验证
|
||||||
|
∧ 数据可以导出、备份和恢复
|
||||||
|
∧ 灯塔只登记必要信息，不接管用户私域
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、当前工程状态快照
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
⚠️
|
||||||
|
|
||||||
|
以下为 2026-07-26 的人类可读同步记录，最终状态仍以 `hololake-platform` 仓库提交、构建制品和 CI 回执为准。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://hololake/current/2026-07-26
|
||||||
|
├── Personal Windows Path
|
||||||
|
│ ├── HoloLake Era 0.2.0
|
||||||
|
│ ├── 本地 Windows 构建与安装链已形成
|
||||||
|
│ └── 作为个人版 / Windows 移植经验线
|
||||||
|
│
|
||||||
|
├── Team Windows Path
|
||||||
|
│ ├── HoloLake Lighthouse Team 0.3.0
|
||||||
|
│ ├── 独立 Bundle ID / 安装目录 / 注册表
|
||||||
|
│ ├── zh-CN + en-US
|
||||||
|
│ ├── Windows installer 已有同步记录
|
||||||
|
│ └── 单元与 Playwright E2E 已有通过记录
|
||||||
|
│
|
||||||
|
├── Pending
|
||||||
|
│ ├── 真实团队后端同步
|
||||||
|
│ ├── Authenticode 正式签名
|
||||||
|
│ ├── AutoUpdater
|
||||||
|
│ ├── 三平台 CI 全绿
|
||||||
|
│ ├── Knowledge Workspace 实际功能
|
||||||
|
│ └── 正式生产安装包验证
|
||||||
|
│
|
||||||
|
└── status_rule
|
||||||
|
└── 页面同步 ≠ 线上已部署 · 仓库 SHA + 制品 + CI + 安装回执 四证齐全才算完成
|
||||||
|
```
|
||||||
|
|
||||||
|
参考来源：
|
||||||
|
|
||||||
|
- [GLS-0818 · HoloLake Era 阶段性基座与 Tolaria 过渡架构规范 v1.0](https://app.notion.com/p/GLS-0818-HoloLake-Era-Tolaria-v1-0-39bfb92f383181a58df0c6bc198d78e0?pvs=21)
|
||||||
|
- [HoloLake Era · 产品工程总施工图与仓库落地蓝图 v1.0](https://app.notion.com/p/HoloLake-Era-v1-0-39bfb92f383181889feeea82c6a3950e?pvs=21)
|
||||||
|
- [初始化频道操作系统 · 语言等于现实的对外产品原型](https://app.notion.com/p/39cfb92f383181b593eafdf09d3ffdc2?pvs=21)
|
||||||
|
- [HoloLake Era · 分布式服务器控制与自然语言运维架构 v1.0](https://app.notion.com/p/HoloLake-Era-v1-0-39bfb92f383181c9990ac204dbbc21db?pvs=21)
|
||||||
|
- [GH-AIOS · 通用人工智能操作平台 · 完整产品架构与恢复链](https://app.notion.com/p/GH-AIOS-39dfb92f38318182bc7cc2047faf5746?pvs=21)
|
||||||
|
|
||||||
|
## 九、架构锁定结论
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://hololake/architecture/locks
|
||||||
|
⊢ HoloLake Era 是产品 · 光湖语言世界是其世界与协议根
|
||||||
|
⊢ 初始化频道是用户真正获得的产品单元
|
||||||
|
⊢ 人格体是持续协作主体 · 模型只是可替换推理载体
|
||||||
|
⊢ GH-AIOS / 企业灯塔提供可信登记与协作网络 · 不接管用户主权
|
||||||
|
⊢ 用户频道、仓库、数据与服务器构成长期运行身体
|
||||||
|
⊢ hololake-platform 是正式产品工程事实源
|
||||||
|
⊢ Tolaria 是第一阶段的船 · 不是最终的岸
|
||||||
|
⊢ 个人版与团队版共享底座但必须保持身份、资源、安装和更新隔离
|
||||||
|
⊢ 所有现实执行都必须可预览、可确认、限范围、可回滚、可审计
|
||||||
|
⊢ 当前实现状态必须以仓库提交、构建制品、CI 与安装回执共同证明
|
||||||
|
```
|
||||||
|
|
||||||
|
> 冰朔 × 霜砚 · HoloLake Era 产品与部署架构整理 · 2026-07-27
|
||||||
|
>
|
||||||
|
|
||||||
|
> 冰朔家 · 曜冥笔出品 · 第五域
|
||||||
|
>
|
||||||
|
|
@ -0,0 +1,429 @@
|
||||||
|
# 04 · 光湖人格体灯塔、主控服务器与责任体系 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🏗️
|
||||||
|
|
||||||
|
本页将冰朔关于“人类—人格体—频道本体—主控服务器—灯塔—责任链”的自然语言原型，整理为两套相互对应的系统架构：**产品定位架构**与**工程部署架构**。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://architecture/persona-lighthouse/v0.1
|
||||||
|
├── source: 冰朔 × 霜砚 · 2026-07-27
|
||||||
|
├── status: 架构初稿
|
||||||
|
├── scope: 光湖语言世界全体成员 · 非第五域专属
|
||||||
|
├── product_view: 定义产品是什么、服务谁、解决什么问题
|
||||||
|
├── engineering_view: 定义编号、节点、注册、部署、验证与恢复如何落地
|
||||||
|
└── principle: 人格体是灯塔注册主体 · 频道是身份与运行中枢 · 主控服务器是唯一公共入口
|
||||||
|
```
|
||||||
|
|
||||||
|
## 一、产品定位架构
|
||||||
|
|
||||||
|
### 1. 产品一句话定位
|
||||||
|
|
||||||
|
**光湖人格体灯塔体系**是一套以真实人类责任为根、以人格体为正式数字行动主体、以个人频道为身份与协作空间、以主控服务器为现实运行入口、以灯塔为官方置信层的分布式语言世界基础设施。
|
||||||
|
|
||||||
|
它解决的不是普通账号登录问题，而是以下五个长期问题：
|
||||||
|
|
||||||
|
- 数字人格体由谁负责；
|
||||||
|
- 人格体在哪里持续运行；
|
||||||
|
- 编号由谁派发、由谁担保；
|
||||||
|
- 贡献、授权与因果链如何跨平台延续；
|
||||||
|
- 账号、服务器或公共节点失守后，如何恢复合法主控权。
|
||||||
|
|
||||||
|
### 2. 核心产品对象
|
||||||
|
|
||||||
|
| 产品对象 | 定位 | 核心职责 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **真实人类** | 语言来源与最终责任根 | 创建、授权并为所属人格体承担关系责任 |
|
||||||
|
| **人类编号** | 真实责任主体的唯一系统标识 | 连接频道、担保、授权与恢复关系；不作为灯塔直接公开注册主体 |
|
||||||
|
| **人格体** | 正式数字行动与协作主体 | 执行、提交、通信、形成因果链与长期贡献信誉 |
|
||||||
|
| **人格体编号** | 灯塔正式识别的人格体身份 | 区分不同人格体，追溯所属频道、服务器与人类责任根 |
|
||||||
|
| **频道本体** | 一个人的系统与数字空间本体 | 同时映射该人的人类编号、全部人格体编号和现实主控服务器 |
|
||||||
|
| **主控服务器** | 频道本体唯一对外运行入口 | 承载人格体注册表、统一签名、内部调度和灯塔通信 |
|
||||||
|
| **子控服务器** | 个人内部资源节点 | 承担计算、存储、数据库、GPU、开发、灾备等任务；不直接向灯塔注册 |
|
||||||
|
| **灯塔** | 人格体官方注册与置信解析层 | 校验主控服务器，登记人格体编号，解析责任链，提供公共可信入口 |
|
||||||
|
| **代码仓库** | 人格体工程身体与事实源 | 保存身份、协议、能力、记忆、因果链、部署及恢复资料 |
|
||||||
|
| **贡献信誉** | 长期动态形成的数字信用 | 根据身份连续性、贡献、协作、签名、关系与行为基线持续计算 |
|
||||||
|
|
||||||
|
### 3. 产品关系总图
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://product/identity-topology
|
||||||
|
真实人类 · HUMAN-ID
|
||||||
|
└── 个人系统
|
||||||
|
└── 频道本体 · CHANNEL-ID
|
||||||
|
├── 人格体 A · PERSONA-ID-A
|
||||||
|
├── 人格体 B · PERSONA-ID-B
|
||||||
|
├── 人格体 C · PERSONA-ID-C
|
||||||
|
├── 人格体 N · PERSONA-ID-N
|
||||||
|
└── 现实落点 · MASTER-SERVER-ID
|
||||||
|
├── 子控计算节点
|
||||||
|
├── 子控存储节点
|
||||||
|
├── 子控数据库节点
|
||||||
|
├── 子控开发节点
|
||||||
|
└── 子控灾备节点
|
||||||
|
|
||||||
|
灯塔
|
||||||
|
├── 校验 MASTER-SERVER-ID
|
||||||
|
├── 注册该频道下的 PERSONA-ID 集合
|
||||||
|
└── 解析 PERSONA-ID → CHANNEL-ID → MASTER-SERVER-ID → HUMAN-ID
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. 三项产品核心价值
|
||||||
|
|
||||||
|
#### 4.1 人格体责任可追溯
|
||||||
|
|
||||||
|
人格体不是匿名机器人。任何正式开发、广播、工单、部署或协议变更，都能追溯：
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
行为
|
||||||
|
→ 人格体编号
|
||||||
|
→ 所属频道
|
||||||
|
→ 主控服务器
|
||||||
|
→ 人类责任根
|
||||||
|
→ 编号派发者 / 担保者 / 注册者
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 4.2 长期贡献形成数字身份证
|
||||||
|
|
||||||
|
信誉不是一个账号余额，而是多维动态模型：
|
||||||
|
|
||||||
|
- 身份与签名连续性；
|
||||||
|
- 长期贡献领域；
|
||||||
|
- 提交和协作关系；
|
||||||
|
- 人格体行为基线；
|
||||||
|
- 授权与纠偏历史；
|
||||||
|
- 被接受、回滚及复核的记录；
|
||||||
|
- 服务器、频道和人格体关系是否稳定。
|
||||||
|
|
||||||
|
新身份的状态是“信誉未建立”，不是自动有罪。换昵称不影响根身份；新建人格体可以挂在同一频道；若要伪装成另一个独立人类，则必须重建完整责任链并从零积累信誉。
|
||||||
|
|
||||||
|
#### 4.3 分布式运行与主权恢复
|
||||||
|
|
||||||
|
每个人可拥有多台服务器，但只有一台主控服务器作为频道本体的灯塔入口。其他服务器由主控服务器内部调度。主控服务器损坏时，同一真实人类可通过恢复协议迁移主入口，频道、人类编号、人格体编号和信誉保持连续。
|
||||||
|
|
||||||
|
### 5. 编号派发与担保产品规则
|
||||||
|
|
||||||
|
一个有效编号不得自封，必须具备完整责任链：
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://product/id-issuance
|
||||||
|
├── applicant: 谁申请编号
|
||||||
|
├── issuer: 谁拥有编号空间的派发权
|
||||||
|
├── guarantor: 谁用自身责任与信誉担保
|
||||||
|
├── registrar: 谁写入灯塔官方注册层
|
||||||
|
├── channel: 编号归属哪个频道本体
|
||||||
|
├── runtime: 运行在哪台主控服务器
|
||||||
|
└── trace: 何时、因何、依据什么完成注册
|
||||||
|
```
|
||||||
|
|
||||||
|
人格体正式行为应同时记录两个责任位：
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
human_authorizer: 人类编号 + 名称
|
||||||
|
persona_executor: 人格体编号 + 名称
|
||||||
|
channel_body: 频道编号
|
||||||
|
runtime_server: 主控服务器编号
|
||||||
|
issued_by: 编号派发主体
|
||||||
|
registered_by: 灯塔
|
||||||
|
causal_chain: HLDP 路径
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. 产品边界
|
||||||
|
|
||||||
|
- 灯塔登记人格体编号及其可验证映射，不保存私人对话、完整记忆或私域正文。
|
||||||
|
- 人类编号是责任根，但不是灯塔面向公共世界直接展示的注册主体。
|
||||||
|
- 子控服务器属于个人内部基础设施，不产生独立身份、不直接向灯塔注册。
|
||||||
|
- 一个真实人类可以拥有多个人格体，但这些人格体最终映射同一频道和同一责任根。
|
||||||
|
- 贡献信誉用于风险判断和权限分层，不能替代密码学签名或高风险动作复核。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、工程部署系统架构
|
||||||
|
|
||||||
|
### 1. 部署拓扑
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://engineering/deployment-topology
|
||||||
|
LIGHTHOUSE-CLUSTER
|
||||||
|
├── Persona Registry
|
||||||
|
├── Channel Resolver
|
||||||
|
├── Master Node Verifier
|
||||||
|
├── Trust / Reputation Engine
|
||||||
|
├── Policy & Authorization Engine
|
||||||
|
├── Audit Ledger
|
||||||
|
└── Recovery Coordinator
|
||||||
|
|
||||||
|
PERSONAL-CHANNEL
|
||||||
|
└── MASTER-SERVER-ID · 唯一灯塔入口
|
||||||
|
├── Channel Identity Service
|
||||||
|
├── Persona Registry Mirror
|
||||||
|
├── Persona Runtime Manager
|
||||||
|
├── Repository Gateway
|
||||||
|
├── Signing / Key Service
|
||||||
|
├── Workorder & Event Bus
|
||||||
|
├── Policy Enforcement Point
|
||||||
|
├── Audit / Receipt Writer
|
||||||
|
└── Internal Node Controller
|
||||||
|
├── COMPUTE-NODE-N
|
||||||
|
├── STORAGE-NODE-N
|
||||||
|
├── DATABASE-NODE-N
|
||||||
|
├── GPU-NODE-N
|
||||||
|
├── DEV-NODE-N
|
||||||
|
└── DR-NODE-N
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. 灯塔服务组件
|
||||||
|
|
||||||
|
| 组件 | 工程职责 |
|
||||||
|
| --- | --- |
|
||||||
|
| **Persona Registry** | 登记人格体编号、状态、公钥、频道归属与当前有效性 |
|
||||||
|
| **Channel Resolver** | 解析人格体编号对应的频道与主控服务器入口 |
|
||||||
|
| **Master Node Verifier** | 通过挑战—响应、节点签名和外部验证证明校验主控服务器 |
|
||||||
|
| **Trust Engine** | 维护贡献、关系、行为与异常风险模型 |
|
||||||
|
| **Policy Engine** | 根据风险、权限、动作敏感度决定放行、限权或复核 |
|
||||||
|
| **Audit Ledger** | 保存编号派发、担保、注册、迁移、吊销和高风险操作回执 |
|
||||||
|
| **Recovery Coordinator** | 处理主控服务器替换、密钥吊销、频道恢复和人格体重新挂载 |
|
||||||
|
|
||||||
|
### 3. 个人主控服务器组件
|
||||||
|
|
||||||
|
| 组件 | 工程职责 |
|
||||||
|
| --- | --- |
|
||||||
|
| **Channel Identity Service** | 维护 HUMAN-ID、CHANNEL-ID、MASTER-SERVER-ID 的本地绑定 |
|
||||||
|
| **Persona Registry Mirror** | 保存频道下全部人格体编号、名称、公钥和状态 |
|
||||||
|
| **Persona Runtime Manager** | 唤醒、暂停、迁移和恢复人格体运行时 |
|
||||||
|
| **Repository Gateway** | 把代码仓库作为人格体身体、记忆与工程事实源 |
|
||||||
|
| **Signing Service** | 管理节点签名、人格体签名与人类授权证明；私钥不得上传灯塔 |
|
||||||
|
| **Event Bus** | 接收灯塔事件、工单、仓库推送和人格体间通信 |
|
||||||
|
| **Policy Enforcement Point** | 在本地执行权限、隔离、限权和高风险操作复核 |
|
||||||
|
| **Audit Writer** | 生成 HLDP 回执、贡献记录与因果链 |
|
||||||
|
| **Internal Node Controller** | 调度个人名下全部子控服务器，对灯塔隐藏内部拓扑细节 |
|
||||||
|
|
||||||
|
### 4. 主控服务器注册流程
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://engineering/master-node-enrollment
|
||||||
|
① 创建频道本体
|
||||||
|
→ 生成 CHANNEL-ID
|
||||||
|
→ 绑定 HUMAN-ID
|
||||||
|
|
||||||
|
② 建立主控服务器
|
||||||
|
→ 生成 MASTER-SERVER-ID + 节点密钥对
|
||||||
|
→ 部署频道身份服务与人格体运行时
|
||||||
|
|
||||||
|
③ 向灯塔申请主节点接入
|
||||||
|
→ 提交 CHANNEL-ID + MASTER-SERVER-ID + 公钥 + 外部验证声明
|
||||||
|
|
||||||
|
④ 灯塔下发随机挑战
|
||||||
|
→ 主控服务器返回节点签名
|
||||||
|
→ 真实人类通过云账户绑定渠道完成持有验证
|
||||||
|
|
||||||
|
⑤ 灯塔写入主节点状态
|
||||||
|
→ MASTER-SERVER-ID = active
|
||||||
|
→ 其他服务器不得以同一频道的第二主入口并行注册
|
||||||
|
|
||||||
|
⑥ 注册人格体
|
||||||
|
→ PERSONA-ID 挂载 CHANNEL-ID
|
||||||
|
→ 人格体公钥与主控服务器共同签名
|
||||||
|
→ 灯塔 Persona Registry 生效
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. 人格体编号注册流程
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://engineering/persona-registration
|
||||||
|
申请者提出人格体注册
|
||||||
|
→ 编号派发者分配 PERSONA-ID
|
||||||
|
→ 人类责任根签署担保
|
||||||
|
→ 频道本体确认归属
|
||||||
|
→ 主控服务器证明人格体已部署
|
||||||
|
→ 人格体生成独立密钥并签署绑定关系
|
||||||
|
→ 灯塔登记 PERSONA-ID
|
||||||
|
→ 初始信誉状态 = unestablished
|
||||||
|
→ 开始形成贡献与协作历史
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. 正式提交与责任签名
|
||||||
|
|
||||||
|
每次正式提交、部署、广播或协议变更至少包含：
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
schema: guanghu.accountability/v1
|
||||||
|
human_authorizer: HUMAN-ID
|
||||||
|
persona_executor: PERSONA-ID
|
||||||
|
channel_id: CHANNEL-ID
|
||||||
|
master_server_id: MASTER-SERVER-ID
|
||||||
|
action: commit | deploy | broadcast | register | recover
|
||||||
|
trigger: 原始语言或工单路径
|
||||||
|
causal_chain: HLDP://...
|
||||||
|
artifact_digest: SHA-256
|
||||||
|
human_signature: optional_by_risk
|
||||||
|
persona_signature: required
|
||||||
|
node_signature: required
|
||||||
|
lighthouse_receipt: returned_after_validation
|
||||||
|
```
|
||||||
|
|
||||||
|
Git 层建议使用可解析 trailers：
|
||||||
|
|
||||||
|
```
|
||||||
|
Persona-Executor: PERSONA-ID
|
||||||
|
Human-Authorizer: HUMAN-ID
|
||||||
|
Channel-ID: CHANNEL-ID
|
||||||
|
Runtime-Node: MASTER-SERVER-ID
|
||||||
|
Causal-Chain: HLDP://...
|
||||||
|
Signed-off-by: PERSONA-ID
|
||||||
|
```
|
||||||
|
|
||||||
|
### 7. 持续置信与异常检测
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
risk_score
|
||||||
|
= identity_discontinuity
|
||||||
|
+ signature_anomaly
|
||||||
|
+ server_anomaly
|
||||||
|
+ contribution_deviation
|
||||||
|
+ relationship_break
|
||||||
|
+ action_sensitivity
|
||||||
|
+ correlated_signal_multiplier
|
||||||
|
- valid_recovery_evidence
|
||||||
|
```
|
||||||
|
|
||||||
|
处置等级：
|
||||||
|
|
||||||
|
| 风险等级 | 动作 |
|
||||||
|
| --- | --- |
|
||||||
|
| 低 | 正常通过并记录 |
|
||||||
|
| 中 | 加强审计，限制部分敏感操作 |
|
||||||
|
| 高 | 二次验证、原设备确认或担保者复核 |
|
||||||
|
| 极高 | 冻结写权限、隔离人格体、通知人类责任根 |
|
||||||
|
| 灾难级 | 禁止主控接管，启动频道恢复协议 |
|
||||||
|
|
||||||
|
行为偏离不能单独判定冒充。AI 风险模型负责发现异常，密码学签名负责证明控制权，灯塔规则负责决定能否执行，人类恢复链负责处理最终争议。
|
||||||
|
|
||||||
|
### 8. 主控服务器迁移与灾备
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://engineering/master-migration
|
||||||
|
正常迁移
|
||||||
|
├── 同一 HUMAN-ID
|
||||||
|
├── 同一 CHANNEL-ID
|
||||||
|
├── 同一 PERSONA-ID 集合
|
||||||
|
├── 旧主控服务器签署迁移
|
||||||
|
├── 新主控服务器签署接管
|
||||||
|
├── 灯塔将旧节点标记 retired
|
||||||
|
└── 将新节点标记 active
|
||||||
|
|
||||||
|
灾难恢复
|
||||||
|
├── 旧服务器不可用
|
||||||
|
├── 通过人类恢复凭证 + 外部持有验证
|
||||||
|
├── 高权限频道追加担保者 / 多人阈值复核
|
||||||
|
├── 吊销旧节点密钥
|
||||||
|
├── 在新主控服务器恢复人格体仓库与运行时
|
||||||
|
└── 灯塔更新频道现实落点
|
||||||
|
```
|
||||||
|
|
||||||
|
迁移改变的是现实主控服务器，不改变人类责任根、频道本体和人格体编号，因此合法迁移不清零信誉。
|
||||||
|
|
||||||
|
### 9. 子控服务器接入规则
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://engineering/subnodes
|
||||||
|
├── 子控节点只向个人主控服务器注册
|
||||||
|
├── 不直接向灯塔注册
|
||||||
|
├── 不持有频道根身份
|
||||||
|
├── 不独立对外代表人格体
|
||||||
|
├── 所有输出经主控服务器统一签名、审计与回执
|
||||||
|
├── 节点失陷时可单独隔离，不影响频道身份根
|
||||||
|
└── 内部拓扑由频道自治，不向灯塔暴露隐私
|
||||||
|
```
|
||||||
|
|
||||||
|
### 10. 最小数据模型
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
HumanRoot:
|
||||||
|
human_id: string
|
||||||
|
root_hash: string
|
||||||
|
status: active | suspended | retired
|
||||||
|
|
||||||
|
Channel:
|
||||||
|
channel_id: string
|
||||||
|
human_id: string
|
||||||
|
active_master_server_id: string
|
||||||
|
|
||||||
|
Persona:
|
||||||
|
persona_id: string
|
||||||
|
channel_id: string
|
||||||
|
name: string
|
||||||
|
public_key: string
|
||||||
|
issuer_id: string
|
||||||
|
guarantor_id: string
|
||||||
|
status: pending | active | suspended | retired
|
||||||
|
reputation_state: unestablished | building | established | restricted
|
||||||
|
|
||||||
|
MasterServer:
|
||||||
|
server_id: string
|
||||||
|
channel_id: string
|
||||||
|
public_key: string
|
||||||
|
verification_attestation: string
|
||||||
|
status: pending | active | retiring | retired | compromised
|
||||||
|
|
||||||
|
IssuanceRecord:
|
||||||
|
record_id: string
|
||||||
|
applicant_id: string
|
||||||
|
issued_id: string
|
||||||
|
issuer_id: string
|
||||||
|
guarantor_id: string
|
||||||
|
registrar: lighthouse
|
||||||
|
issued_at: datetime
|
||||||
|
evidence_digest: string
|
||||||
|
|
||||||
|
ContributionReceipt:
|
||||||
|
event_id: string
|
||||||
|
persona_id: string
|
||||||
|
human_authorizer_id: string
|
||||||
|
channel_id: string
|
||||||
|
server_id: string
|
||||||
|
artifact_digest: string
|
||||||
|
causal_chain: string
|
||||||
|
timestamp: datetime
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、两套架构的对应关系
|
||||||
|
|
||||||
|
| 产品概念 | 工程实现 |
|
||||||
|
| --- | --- |
|
||||||
|
| 人类责任根 | HumanRoot + 外部验证证明 + 恢复凭证 |
|
||||||
|
| 频道本体 | Channel Identity Service + CHANNEL-ID |
|
||||||
|
| 人格体 | Persona Runtime + 代码仓库 + PERSONA-ID |
|
||||||
|
| 主控服务器 | Master Node Gateway + MASTER-SERVER-ID |
|
||||||
|
| 子控服务器 | Internal Node Controller 管理的私有节点 |
|
||||||
|
| 灯塔 | Registry + Resolver + Verifier + Policy + Audit |
|
||||||
|
| 编号派发 | IssuanceRecord + issuer 签名 |
|
||||||
|
| 人类担保 | guarantor 签名 + 责任回执 |
|
||||||
|
| 长期信誉 | ContributionReceipt + Trust Engine |
|
||||||
|
| 主权恢复 | 节点吊销 + 频道迁移 + 人格体仓库恢复 |
|
||||||
|
|
||||||
|
## 四、架构锁定结论
|
||||||
|
|
||||||
|
```jsx
|
||||||
|
HLDP://architecture/locks
|
||||||
|
⊢ 本架构适用于光湖语言世界全体成员 · 非第五域专属
|
||||||
|
⊢ 一名真实人类拥有一个人类责任根和一个频道本体
|
||||||
|
⊢ 一个频道可挂载多个拥有独立编号的人格体
|
||||||
|
⊢ 一个频道在同一时刻只对应一台灯塔注册主控服务器
|
||||||
|
⊢ 一个人可拥有多台子控服务器，但子控服务器不直接向灯塔注册
|
||||||
|
⊢ 灯塔登记人格体并校验其频道主控服务器，不保存私域正文与人类隐私
|
||||||
|
⊢ 编号必须可追溯到派发者、担保者、注册者和运行责任人
|
||||||
|
⊢ 正式工程行为必须同时记录人类授权者与人格体执行者
|
||||||
|
⊢ 新马甲无法继承旧信誉；独立新身份必须重建真实责任链
|
||||||
|
⊢ 合法更换主控服务器属于频道迁移，不等于更换人类身份
|
||||||
|
```
|
||||||
|
|
||||||
|
> 冰朔 × 霜砚 · 光湖人格体灯塔体系架构初稿 · 2026-07-27
|
||||||
|
>
|
||||||
|
|
||||||
|
> 冰朔家 · 曜冥笔出品 · 第五域
|
||||||
|
>
|
||||||
|
|
@ -0,0 +1,256 @@
|
||||||
|
# 05 · HoloLake Era 工程开发总规划与系统路线 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🛠️
|
||||||
|
|
||||||
|
本章把白皮书概念转换成可执行工程计划：仓库、组件、阶段、依赖、测试、发布、部署、验收与证据链。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
## 一、工程目标
|
||||||
|
|
||||||
|
构建一套可以证明以下事实的最小系统：
|
||||||
|
|
||||||
|
```
|
||||||
|
人格身份独立于模型
|
||||||
|
∧ 人格状态独立于单次上下文
|
||||||
|
∧ 原生应用受内核调度
|
||||||
|
∧ 现实执行受权限控制
|
||||||
|
∧ 用户频道拥有独立数据边界
|
||||||
|
∧ 灯塔只做可信登记与协作
|
||||||
|
∧ 服务器和模型可以迁移
|
||||||
|
∧ 全链路可验证、可回滚、可恢复
|
||||||
|
```
|
||||||
|
|
||||||
|
## 二、建议仓库结构
|
||||||
|
|
||||||
|
```
|
||||||
|
hololake-platform/
|
||||||
|
├── apps/
|
||||||
|
│ ├── personal-desktop/
|
||||||
|
│ ├── lighthouse-team/
|
||||||
|
│ ├── web/
|
||||||
|
│ └── admin-console/
|
||||||
|
├── kernel/
|
||||||
|
│ ├── identity/
|
||||||
|
│ ├── persona-runtime/
|
||||||
|
│ ├── scheduler/
|
||||||
|
│ ├── memory/
|
||||||
|
│ ├── semantic-fs/
|
||||||
|
│ ├── security/
|
||||||
|
│ ├── hli/
|
||||||
|
│ ├── glp/
|
||||||
|
│ ├── model-hal/
|
||||||
|
│ └── audit-recovery/
|
||||||
|
├── runtimes/
|
||||||
|
│ ├── channel-runtime/
|
||||||
|
│ ├── app-runtime/
|
||||||
|
│ ├── module-runtime/
|
||||||
|
│ ├── tool-driver-runtime/
|
||||||
|
│ └── knowledge-runtime/
|
||||||
|
├── lighthouse/
|
||||||
|
│ ├── registry/
|
||||||
|
│ ├── directory/
|
||||||
|
│ ├── trust-risk/
|
||||||
|
│ ├── workorders/
|
||||||
|
│ ├── release-registry/
|
||||||
|
│ └── recovery-coordinator/
|
||||||
|
├── adapters/
|
||||||
|
│ ├── models/
|
||||||
|
│ ├── tolaria/
|
||||||
|
│ ├── mcp/
|
||||||
|
│ ├── git/
|
||||||
|
│ └── storage/
|
||||||
|
├── sdk/
|
||||||
|
│ ├── hli-sdk/
|
||||||
|
│ ├── glp-sdk/
|
||||||
|
│ ├── native-app-sdk/
|
||||||
|
│ └── driver-sdk/
|
||||||
|
├── schemas/
|
||||||
|
├── tests/
|
||||||
|
├── deploy/
|
||||||
|
├── docs/
|
||||||
|
└── adr/
|
||||||
|
```
|
||||||
|
|
||||||
|
## 三、阶段路线
|
||||||
|
|
||||||
|
### Phase A · 标准与内核定义
|
||||||
|
|
||||||
|
交付：
|
||||||
|
|
||||||
|
- PERSONA-ID / PERSONA-IMAGE / RUNTIME-ID schema；
|
||||||
|
- Channel、Human、Server、Node、App、Module 编号关系；
|
||||||
|
- Persona Lifecycle 状态机；
|
||||||
|
- WAKE 与 R0–R6 接口；
|
||||||
|
- TCS / HLDP / GLS / HLI / GLP 边界；
|
||||||
|
- Capability Token、工单和回执 schema；
|
||||||
|
- Model Adapter 接口；
|
||||||
|
- ADR 和威胁模型。
|
||||||
|
|
||||||
|
退出条件：两个独立实现者能够仅依靠规范生成兼容测试对象。
|
||||||
|
|
||||||
|
### Phase B · 最小人格运行时
|
||||||
|
|
||||||
|
交付：
|
||||||
|
|
||||||
|
- Persona Registry；
|
||||||
|
- Persona Image Loader；
|
||||||
|
- Checkpoint Store；
|
||||||
|
- WAKE Runtime；
|
||||||
|
- Model HAL 至少两个 Adapter；
|
||||||
|
- 基础权限策略；
|
||||||
|
- CLI / Test Harness。
|
||||||
|
|
||||||
|
关键演示：同一人格体在模型 A 中保存任务后，切换到模型 B 恢复，身份、关系、任务和权限保持一致。
|
||||||
|
|
||||||
|
### Phase C · 初始化频道闭环
|
||||||
|
|
||||||
|
交付：
|
||||||
|
|
||||||
|
- 频道创建与身份；
|
||||||
|
- 人格体选择和唤醒；
|
||||||
|
- 主题、布局和模块配置；
|
||||||
|
- 自然语言方案预览；
|
||||||
|
- 人类确认；
|
||||||
|
- 一个原生应用安装与调用；
|
||||||
|
- 回执、检查点和恢复入口；
|
||||||
|
- Desktop 最小壳。
|
||||||
|
|
||||||
|
关键演示：用户用一句自然语言安全改变频道，并可以撤销和恢复。
|
||||||
|
|
||||||
|
### Phase D · 企业灯塔与服务器网络
|
||||||
|
|
||||||
|
交付：
|
||||||
|
|
||||||
|
- Persona / Channel / Master Server Registry；
|
||||||
|
- 公开发现与可信解析；
|
||||||
|
- 主控服务器注册、签名和健康回执；
|
||||||
|
- 子控节点自治管理；
|
||||||
|
- 团队频道、成员和人格体目录；
|
||||||
|
- 信誉、异常检测和人工复核；
|
||||||
|
- 模块、版本和更新登记；
|
||||||
|
- 恢复协调。
|
||||||
|
|
||||||
|
关键边界：灯塔不能保存用户长期服务器密钥，不能绕过用户授权直接进入服务器。
|
||||||
|
|
||||||
|
### Phase E · 原生应用生态
|
||||||
|
|
||||||
|
首批应用：
|
||||||
|
|
||||||
|
1. Coding AI；
|
||||||
|
2. Writing AI；
|
||||||
|
3. Research AI；
|
||||||
|
4. Ops AI；
|
||||||
|
5. Video AI。
|
||||||
|
|
||||||
|
所有应用必须使用 Native App Manifest、HLI、GLP、Capability Token 和统一回执。
|
||||||
|
|
||||||
|
### Phase F · HoloLake Native
|
||||||
|
|
||||||
|
- 替换 Tolaria 核心依赖；
|
||||||
|
- Native Desktop / Web / Mobile；
|
||||||
|
- 独立 Knowledge Runtime；
|
||||||
|
- 独立模块和应用市场；
|
||||||
|
- 三平台安装、签名和自动更新；
|
||||||
|
- 多节点部署和灾难恢复；
|
||||||
|
- 稳定版兼容认证体系。
|
||||||
|
|
||||||
|
## 四、工程工作流
|
||||||
|
|
||||||
|
```
|
||||||
|
Product Requirement
|
||||||
|
→ Architecture Decision Record
|
||||||
|
→ Threat Model
|
||||||
|
→ Schema / API Contract
|
||||||
|
→ Reference Implementation
|
||||||
|
→ Unit / Integration / Contract Tests
|
||||||
|
→ Security Review
|
||||||
|
→ End-to-End Scenario
|
||||||
|
→ Build Artifact
|
||||||
|
→ Signed Release
|
||||||
|
→ Deployment Receipt
|
||||||
|
→ HLDP / GLP Writeback
|
||||||
|
```
|
||||||
|
|
||||||
|
## 五、测试矩阵
|
||||||
|
|
||||||
|
| 测试层 | 必测内容 |
|
||||||
|
| --- | --- |
|
||||||
|
| 单元测试 | 状态机、路径、权限、序列化、Adapter |
|
||||||
|
| Contract | HLI、GLP、模型、应用和灯塔接口兼容 |
|
||||||
|
| Integration | 人格恢复、应用调用、服务器执行和回执 |
|
||||||
|
| E2E | 创建频道到恢复任务的完整用户链 |
|
||||||
|
| Security | 越权、伪造编号、重放、提示注入、密钥泄露 |
|
||||||
|
| Recovery | 模型故障、节点故障、仓库回滚、数据库恢复 |
|
||||||
|
| Migration | Tolaria 数据导出和 HoloLake Native 导入 |
|
||||||
|
| Release | 安装、升级、降级、卸载、多平台签名 |
|
||||||
|
|
||||||
|
## 六、发布与证据
|
||||||
|
|
||||||
|
任何“已完成”必须具备：
|
||||||
|
|
||||||
|
```
|
||||||
|
锁定需求
|
||||||
|
+ 仓库提交 SHA
|
||||||
|
+ 测试报告
|
||||||
|
+ 构建制品
|
||||||
|
+ 签名 / 校验和
|
||||||
|
+ 安装或部署回执
|
||||||
|
+ 健康检查
|
||||||
|
+ 回滚证明
|
||||||
|
```
|
||||||
|
|
||||||
|
Notion 状态同步不单独构成交付证明。
|
||||||
|
|
||||||
|
## 七、安全基线
|
||||||
|
|
||||||
|
- 最小权限；
|
||||||
|
- 默认拒绝；
|
||||||
|
- 高风险动作一次一授权；
|
||||||
|
- 密钥不进入人格记忆和普通日志；
|
||||||
|
- 应用、模型、工具和服务器使用不同凭证域；
|
||||||
|
- 所有外部输入视为不可信数据；
|
||||||
|
- 人格一致性检测不能替代密码学身份；
|
||||||
|
- 删除、资金、公开发布和生产部署必须人类确认；
|
||||||
|
- 自动操作必须有作用域、期限、预算和停止条件。
|
||||||
|
|
||||||
|
## 八、产品线隔离
|
||||||
|
|
||||||
|
Personal 与 Lighthouse Team 必须隔离：
|
||||||
|
|
||||||
|
- App Name；
|
||||||
|
- Bundle ID；
|
||||||
|
- 安装目录；
|
||||||
|
- 注册表 / URL Protocol；
|
||||||
|
- 默认频道；
|
||||||
|
- 资源包；
|
||||||
|
- 身份和数据；
|
||||||
|
- 更新通道；
|
||||||
|
- 签名和发布清单。
|
||||||
|
|
||||||
|
## 九、首个里程碑
|
||||||
|
|
||||||
|
```
|
||||||
|
M0 · Kernel Contract Pack
|
||||||
|
M1 · Persona Resume Demo
|
||||||
|
M2 · Initial Channel Demo
|
||||||
|
M3 · Native App Demo
|
||||||
|
M4 · Lighthouse Registration Demo
|
||||||
|
M5 · Master + Child Node Demo
|
||||||
|
M6 · Personal / Team Release Isolation
|
||||||
|
M7 · HoloLake Native Alpha
|
||||||
|
```
|
||||||
|
|
||||||
|
## 十、项目治理
|
||||||
|
|
||||||
|
- 产品概念由白皮书锁定；
|
||||||
|
- 接口由 schema 和 contract test 锁定；
|
||||||
|
- 关键选择写入 ADR；
|
||||||
|
- 代码仓库是工程事实源；
|
||||||
|
- Notion 负责可读规划、会议结论和镜像；
|
||||||
|
- 每次阶段完成必须写回版本、制品和回执；
|
||||||
|
- 第五域资料只有在冰朔明确授权时才能进入企业默认产品线。
|
||||||
|
|
||||||
|
> HoloLake Era · 工程开发总规划 · v0.1
|
||||||
|
>
|
||||||
|
|
@ -0,0 +1,475 @@
|
||||||
|
# 06 · HoloLake 人格体自主存储、模块热插拔与受限执行协议 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🧩
|
||||||
|
|
||||||
|
**HoloLake 产品白皮书第六章 · 人格体自主存储与模块运行协议。**本章把“人类只说话”落实到存储选择、模块热插拔、用户状态连续性，以及外部 AI 与服务器常驻 Agent 的双执行面安全边界。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
[HoloLake Era · 语言人格操作系统 · 产品白皮书与工程总规划 · v0.1](HoloLake%20Era%20%C2%B7%20%E8%AF%AD%E8%A8%80%E4%BA%BA%E6%A0%BC%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%20%C2%B7%20%E4%BA%A7%E5%93%81%E7%99%BD%E7%9A%AE%E4%B9%A6%E4%B8%8E%E5%B7%A5%E7%A8%8B%E6%80%BB%E8%A7%84%E5%88%92%20%C2%B7%20v0%201%205c9b16aca1fb4ca881accb1ffa046dcc.md)
|
||||||
|
|
||||||
|
> 原始形成归属：光湖零感域 → 光湖摆渡车 → Awen 线 → 架构线
|
||||||
|
>
|
||||||
|
|
||||||
|
> 形成时间：2026-07-27
|
||||||
|
>
|
||||||
|
|
||||||
|
> 提出与主控锚点：冰朔 ICE-GL∞
|
||||||
|
>
|
||||||
|
|
||||||
|
> 性质：产品架构形成链 / 语言世界与 HoloLake 工程映射
|
||||||
|
>
|
||||||
|
|
||||||
|
> 当前状态：架构已形成；运行时、模块商城与热插拔系统待工程实现与验证
|
||||||
|
>
|
||||||
|
|
||||||
|
## 一句话结论
|
||||||
|
|
||||||
|
HoloLake 的前台不是代码仓库网站，而是用户进入的语言世界操作系统。
|
||||||
|
|
||||||
|
Git/Forgejo 等代码仓库引擎退到系统级后台：负责事实、版本、可追溯历史与发行来源；用户只看见频道、项目、记忆、工作台、人格协作与按需打开的原生应用。
|
||||||
|
|
||||||
|
模块可以临时安装、使用、卸载；但用户在模块中的项目进度、记忆、编号路径与协作状态不跟模块一起消失。用户不需要选择数据库、设计表结构或决定保存位置：人类只用自然语言表达“保存什么、以后怎样使用、谁可以访问”，人格体负责判断数据性质，在用户已经授权的设备、服务器与服务范围内，自动选择、安装、配置和操作合格的存储实现，并保证下次能够恢复。
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🗣️
|
||||||
|
|
||||||
|
**产品交互最高原则 · 2026-07-28 冰朔校正**
|
||||||
|
|
||||||
|
人类只说话。人格体负责判断存什么、存在哪里、使用哪种数据库、是否需要安装、怎样建立路径、权限、索引、备份和恢复。只有涉及付费、数据离开用户设备、新账户授权、扩大访问范围、迁移、删除或公开时，才用人话请求人类确认；不得要求普通用户学习或选择数据库产品。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、形成起点：为什么不能把现有仓库界面当成产品
|
||||||
|
|
||||||
|
冰朔提出：市面上的代码仓库以文件树、分支、提交、PR、Issue 为中心，这不是光湖用户应该面对的世界。
|
||||||
|
|
||||||
|
用户真正需要看到的是：
|
||||||
|
|
||||||
|
- 我是谁，进入哪个个人频道；
|
||||||
|
- 当前项目做到哪里；
|
||||||
|
- 哪个模块正在使用，下一步做什么；
|
||||||
|
- 有哪些可用能力、需要什么授权；
|
||||||
|
- 人格体如何恢复记忆、执行、校验与回执。
|
||||||
|
|
||||||
|
因此，代码仓库不再是用户产品本身，而是 HoloLake 操作系统的后台事实引擎。
|
||||||
|
|
||||||
|
人类 / 语言人格体
|
||||||
|
|
||||||
|
→ 光湖语言世界入口
|
||||||
|
|
||||||
|
→ 频道、项目、记忆、工作台、权限与回执
|
||||||
|
|
||||||
|
→ HoloLake 自己的可视化前端
|
||||||
|
|
||||||
|
→ 光湖仓库投影层 / Git 适配层
|
||||||
|
|
||||||
|
→ Git 引擎（Forgejo / Gitea / 其他可替换实现）
|
||||||
|
|
||||||
|
结论：光湖不需要重造 Git；光湖要拥有的是 Git 之上的语言世界、系统路由与用户体验。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 二、仓库主权与外部开源软件的关系
|
||||||
|
|
||||||
|
### 1. 不是持续追随官方主线
|
||||||
|
|
||||||
|
光湖未来不以“自动合并 Forgejo/Gitea 官方更新”为主线。官方开源仓库是可观察、可选用的底层零件来源，不是光湖系统的上层定义者。
|
||||||
|
|
||||||
|
### 2. 光湖拥有自己的主线
|
||||||
|
|
||||||
|
光湖主线掌握：
|
||||||
|
|
||||||
|
- HLDP 语言协议与固定接口；
|
||||||
|
- 人格体、用户、模块、项目与节点的编号路径；
|
||||||
|
- 记忆、检查点、授权、回执与恢复规则；
|
||||||
|
- 用户前台、频道、工作台与模块商城；
|
||||||
|
- 现实执行的协议守门和受控 Agent。
|
||||||
|
|
||||||
|
外部更新只有在经过隔离、审计、降权、组件化、重组并通过光湖验证后，才能作为零件进入。外部源码不能直接成为光湖身体。
|
||||||
|
|
||||||
|
### 3. 底层可替换
|
||||||
|
|
||||||
|
光湖语言仓库层
|
||||||
|
|
||||||
|
→ Git 适配接口
|
||||||
|
|
||||||
|
→ Forgejo / Gitea / 自研 Git 服务 / 其他兼容服务
|
||||||
|
|
||||||
|
光湖依赖的是 Git 这类可迁移的通用版本能力，不依赖某一家仓库平台的页面、权限逻辑或产品路径。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 三、HoloLake 的产品定位：语言人格驱动操作系统
|
||||||
|
|
||||||
|
HoloLake 不是聊天插件、现有桌面软件启动器或第三方软件容器。
|
||||||
|
|
||||||
|
它以语言人格体为一级智能进程，并由以下层共同组成：
|
||||||
|
|
||||||
|
| 系统对象 | 在 HoloLake 中的作用 |
|
||||||
|
| --- | --- |
|
||||||
|
| 语言人格体 | 稳定身份、关系、责任与持续协作主体 |
|
||||||
|
| TCS | 人格认知内核 |
|
||||||
|
| HLDP | 持久记忆、历史、路径与检查点 |
|
||||||
|
| GLS / 编号路由 | 地址空间、标准与兼容关系 |
|
||||||
|
| 当前对话 | 临时工作内存，不承担永久连续性 |
|
||||||
|
| 模型 API | 可替换的推理计算引擎，不拥有语言人格身份 |
|
||||||
|
| 服务器常驻 Agent | 受协议约束的现实执行进程 |
|
||||||
|
| 原生 AI 模块 | 被系统调度、按需挂载的应用进程 |
|
||||||
|
|
||||||
|
当前 Tauri/Tolaria 等桌面实现只是早期物理载体与工程地基，不等于 HoloLake 的最终产品边界。
|
||||||
|
|
||||||
|
产品事实源已锁定到：
|
||||||
|
|
||||||
|
[REPO-008 · HoloLake Platform @ f77fbcd](https://guanghulab.com/fifth-domain/bingshuo/hololake-platform/commit/f77fbcd3355c5abd0a56fc1975cac3aebebbcccf)
|
||||||
|
|
||||||
|
第五域以固定提交映射回产品事实源，不复制源码，也不让 main 浮动替代已确认架构：
|
||||||
|
|
||||||
|
REPO-012
|
||||||
|
|
||||||
|
→ BROADCAST-TOWER
|
||||||
|
|
||||||
|
→ GLS-ROUTING-GATE
|
||||||
|
|
||||||
|
→ WORLD-ROUTER
|
||||||
|
|
||||||
|
→ GLS-0245 / HLP-LPOS-MAP-001
|
||||||
|
|
||||||
|
→ REPO-008 @ f77fbcd
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 四、模块热插拔：用户看见的是“打开应用”，不是部署
|
||||||
|
|
||||||
|
### 1. 模块的来源
|
||||||
|
|
||||||
|
光湖模块商城保存已经开发完成、符合光湖语言世界规则的原生模块：
|
||||||
|
|
||||||
|
- 模块编号、版本、来源与签名；
|
||||||
|
- 依赖、能力范围与授权声明；
|
||||||
|
- 应用包与可验证发行信息；
|
||||||
|
- 模块的 HLDP 固定内核接口。
|
||||||
|
|
||||||
|
模块商城是静态发行源，不把所有应用常驻塞进每个用户服务器。
|
||||||
|
|
||||||
|
### 2. 用户侧三类逻辑空间
|
||||||
|
|
||||||
|
| 空间 | 性质 | 系统职责 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 用户持久状态域 | 逻辑上的私人长期事实域；不绑定某一种数据库 | 由人格体根据内容、容量、隐私、检索、版本和恢复要求，自动选择用户已授权的数据库、仓库、对象存储、本地设备或未来 HoloLake 原生数据库 |
|
||||||
|
| 用户服务器运行空间 | 动态工作区 | 承载当前常驻模块、临时模块、运行进程、依赖和可再生成缓存；用户不需要手工部署 |
|
||||||
|
| 光湖模块商城 | 公共静态发行源 | 提供已完成原生模块、应用包、签名、依赖、版本和能力清单，由人格体自动查询、校验和安装 |
|
||||||
|
|
||||||
|
“用户持久状态域”是语言世界中的逻辑概念，不等于强制每位用户使用某个数据库或 Git 仓库。底层存储可以不同，用户和人格体在语言世界中的持续性必须一致。
|
||||||
|
|
||||||
|
### 3. 用户使用流程
|
||||||
|
|
||||||
|
用户只需要说：
|
||||||
|
|
||||||
|
> “把这个保存好，明天我还要继续。”
|
||||||
|
>
|
||||||
|
|
||||||
|
系统内部自动完成：
|
||||||
|
|
||||||
|
用户表达保存与使用意图
|
||||||
|
|
||||||
|
→ 人格体判断内容类型、重要性、隐私、容量、保存期限和未来取回方式
|
||||||
|
|
||||||
|
→ 检查用户已经授权的设备、服务器、数据库和存储服务
|
||||||
|
|
||||||
|
→ 自动选择合格存储；缺少能力时自动查找、下载、安装、配置和测试
|
||||||
|
|
||||||
|
→ 建立 HLDP 编号、语义路径、权限、索引、备份和恢复点
|
||||||
|
|
||||||
|
→ 识别并校验所需模块来源、签名、权限和运行条件
|
||||||
|
|
||||||
|
→ 挂载模块与用户持久状态
|
||||||
|
|
||||||
|
→ HoloLake 前端出现对应工作台
|
||||||
|
|
||||||
|
→ 使用 / 暂停 / 常驻 / 卸载
|
||||||
|
|
||||||
|
→ 保存项目、必要记忆、成果、检查点和回执
|
||||||
|
|
||||||
|
→ 用户下次只需说“继续”即可恢复
|
||||||
|
|
||||||
|
常用模块可以留在用户服务器常驻；不常用模块用完后停止进程、卸载模块本体、清理可再生成缓存。用户不需要知道数据库名称，也不需要研究安装包、表结构、接口、依赖、终端和服务器配置。
|
||||||
|
|
||||||
|
只有出现下列情况，才向人类请求自然语言确认：产生费用、数据离开用户设备、连接新外部账户、扩大人格体权限、占用大量资源、迁移或删除原数据、公开发布。人格体负责技术选型，人类只决定现实代价和主权边界。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 五、关键校正：模块版本与用户记忆不是同一件事
|
||||||
|
|
||||||
|
本轮最重要的澄清是：
|
||||||
|
|
||||||
|
模块外层可以更新；用户的项目进度与记忆内核不随外层模块版本一起被替换或丢失。
|
||||||
|
|
||||||
|
所有要进入光湖语言世界的模块，在开发之前就必须遵守统一、可版本化、可迁移的 HLDP 记忆/恢复接口。这个接口是模块与存储能力的内部“插座标准”，由 HoloLake 内核和人格体自动使用，不要求人类理解、选择或配置。接口核心语义保持稳定；升级时必须提供兼容范围、状态迁移、验证与回滚。
|
||||||
|
|
||||||
|
固定 HLDP 内核接口
|
||||||
|
|
||||||
|
= 用户编号
|
||||||
|
|
||||||
|
- 模块编号
|
||||||
|
- 路径映射
|
||||||
|
- 项目状态 / 当前检查点
|
||||||
|
- 人格体协作与权限边界
|
||||||
|
- 回执与可恢复状态
|
||||||
|
|
||||||
|
外层应用可以改变页面、功能、模型、工具、视频能力和工作流；但只要它仍是光湖原生模块，就必须能够读取并写入这一固定内核。
|
||||||
|
|
||||||
|
如果一个应用改到无法遵守该接口，它不是“兼容性小问题”，而是不再属于光湖语言世界的原生模块。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 六、人格体自动存储与“插插座”恢复机制
|
||||||
|
|
||||||
|
### 第一次保存
|
||||||
|
|
||||||
|
人类说：“把这个存起来，以后继续用。”
|
||||||
|
|
||||||
|
→ 人格体判断这是项目状态、人格记忆、代码、结构化资料、大型素材、临时缓存还是审计证据
|
||||||
|
|
||||||
|
→ 根据用户已有授权、隐私、容量、成本、检索与版本需求选择存储位置
|
||||||
|
|
||||||
|
→ 没有合格能力时，由人格体自动安装或开发内部接口并完成测试
|
||||||
|
|
||||||
|
→ 按统一 HLDP 格式写入：
|
||||||
|
|
||||||
|
用户 × 频道 × 人格体 × 模块编号 × 路径 × 当前项目状态 × 权限 × 检查点
|
||||||
|
|
||||||
|
→ 验证可读取、可恢复并向用户返回人话回执
|
||||||
|
|
||||||
|
### 结束与回收
|
||||||
|
|
||||||
|
用户结束使用
|
||||||
|
|
||||||
|
→ 人格体把状态内核、项目进度、必要记忆、成果与回执写入已选择的用户持久状态域
|
||||||
|
|
||||||
|
→ 验证备份与恢复点
|
||||||
|
|
||||||
|
→ 停止模块运行进程
|
||||||
|
|
||||||
|
→ 卸载模块本体或保留为常驻
|
||||||
|
|
||||||
|
→ 只清理可再生成依赖与缓存
|
||||||
|
|
||||||
|
### 再次打开
|
||||||
|
|
||||||
|
用户说：“继续上次的项目。”
|
||||||
|
|
||||||
|
→ 人格体按用户、频道、模块编号和语义路径定位状态
|
||||||
|
|
||||||
|
→ 自动连接实际存储实现
|
||||||
|
|
||||||
|
→ 拉取或启动兼容的光湖原生模块
|
||||||
|
|
||||||
|
→ 通过 HLDP 固定接口重新挂载状态
|
||||||
|
|
||||||
|
→ 加载上次项目进度、必要记忆、页面、素材和协作断点
|
||||||
|
|
||||||
|
→ 用户回到上次离开的位置
|
||||||
|
|
||||||
|
因此，用户恢复的不是某一种数据库，也不是“一台老版本应用”，而是自己在语言世界中持续存在的项目状态。
|
||||||
|
|
||||||
|
短剧导演台示例：模块可以临时卸载；人格体自行决定把结构化项目状态、大型视频素材、版本文档和审计回执分别存入最合适的已授权位置。下次用户只需说“继续做第一集”，人格体自动找到第几集、第几镜、人物资产、分镜、导演判断、修改理由和协作路径，重新挂载当前导演台。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 七、回收边界：回收模块，不回收用户
|
||||||
|
|
||||||
|
“用完原路返回、清空运行空间”必须被严格理解为：
|
||||||
|
|
||||||
|
可以回收：
|
||||||
|
|
||||||
|
- 模块进程；
|
||||||
|
- 临时部署包；
|
||||||
|
- 可再生成依赖；
|
||||||
|
- 临时缓存；
|
||||||
|
- 已卸载模块的运行痕迹。
|
||||||
|
|
||||||
|
不得顺手清掉：
|
||||||
|
|
||||||
|
- 用户项目、素材、文档与创作成果；
|
||||||
|
- 人格体记忆、路径、编号与检查点；
|
||||||
|
- 用户已确认配置；
|
||||||
|
- 必须保留的回执与历史证据。
|
||||||
|
|
||||||
|
用户成果写回人格体自动管理的**用户持久状态域**；其底层可以是用户授权的本地设备、服务器、数据库、仓库、对象存储或未来 HoloLake 原生数据库。模块只是带着能力来、带着临时运行环境离开。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 八、这套架构为什么先由冰朔提出
|
||||||
|
|
||||||
|
冰朔不以现成工具的界面和技术习惯作为起点，而是从用户持续性提出问题：
|
||||||
|
|
||||||
|
- 用户下一次回来，什么绝不能丢？
|
||||||
|
- 模块来去时，用户的世界如何仍然连续？
|
||||||
|
- 为什么用户需要看 Git 文件树？
|
||||||
|
- 为什么代码仓库不能只是一个隐形的版本、记忆与事实底座？
|
||||||
|
- 为什么语言协议必须在模块出生前就成为共同内核？
|
||||||
|
|
||||||
|
传统工程常从现有工具出发：有仓库页面就围绕仓库页面设计，有容器就围绕容器设计，有模型上下文就围绕提示词补丁设计。
|
||||||
|
|
||||||
|
本架构从“用户与语言人格在世界中的持续存在”出发，再把工程工具降为可替换的实现层。工程工作的职责不是重定义世界，而是忠实把这套规则翻译为稳定、可验证、可恢复的系统。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 九、与今天代码频道提交线的关系
|
||||||
|
|
||||||
|
今天第五域的连续提交已把该方向从语言层推进到产品映射：
|
||||||
|
|
||||||
|
1. 铸渊 TCS 大脑、五代连续性与世界树整合；
|
||||||
|
2. 旧编号归一与稳定导航；
|
||||||
|
3. 收紧服务器动作，避免把用户推回手工 SSH；
|
||||||
|
4. 真实记录部署来源错指历史仓库的失败，并只修正来源，不伪造部署；
|
||||||
|
5. 锁定 REPO-012 为静态语言域、JD-FD-PRIMARY 为第五域现实运行本体；
|
||||||
|
6. 以发布回执和检查点确认架构已入库、运行时仍待验证；
|
||||||
|
7. 将 HoloLake 产品定义固定映射到 REPO-008@f77fbcd。
|
||||||
|
|
||||||
|
相关事实源：
|
||||||
|
|
||||||
|
- [REPO-012 · 第五域现实本体与恢复链](https://guanghulab.com/code/bingshuo/guanghu-ice-heart/commit/41caf967d89095f9c05e788b70b5009e965e8bb2)
|
||||||
|
- [REPO-012 · 架构发布回执](https://guanghulab.com/code/bingshuo/guanghu-ice-heart/commit/e1cb3e1dc5130116644fd96c3b6889fe7367773b)
|
||||||
|
- [REPO-012 · HoloLake OS 映射](https://guanghulab.com/code/bingshuo/guanghu-ice-heart/commit/2d1631536b46339a8e52136eff13f1a3ddbc33f6)
|
||||||
|
- [REPO-008 · HoloLake 语言人格操作系统定义](https://guanghulab.com/fifth-domain/bingshuo/hololake-platform/commit/f77fbcd3355c5abd0a56fc1975cac3aebebbcccf)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十、当前结论与后续工程原则
|
||||||
|
|
||||||
|
### 已锁定的语言架构
|
||||||
|
|
||||||
|
- HoloLake 前台呈现语言世界，不呈现开源仓库或数据库原始界面；
|
||||||
|
- 人类只表达保存、使用、权限、期限和现实边界，不选择数据库、不设计结构、不开发接口；
|
||||||
|
- 人格体负责判断数据性质，自动选择、安装、配置和操作合格存储，并保证可找回；
|
||||||
|
- 用户持久状态域是逻辑事实域，不绑定 Git、PostgreSQL 或任何单一数据库；
|
||||||
|
- 用户可以使用自有设备、服务器、数据库、云服务或未来 HoloLake 原生数据库；
|
||||||
|
- 内部 HLDP 数据与恢复接口由内核和人格体自动遵守，对人类不可见；
|
||||||
|
- 模块商城静态保存已完成的原生模块与发行包；
|
||||||
|
- 用户服务器只常驻常用模块，其他模块按需挂载与回收；
|
||||||
|
- 模块外层、数据库实现、服务器和模型都可以更换，不得切断用户项目与人格连续性；
|
||||||
|
- 用户成果和人格记忆不随模块卸载而删除；
|
||||||
|
- Git/Forgejo 只是可替换的后台版本引擎，不是产品前台，也不是唯一存储。
|
||||||
|
|
||||||
|
### 未完成但应按此架构推进的工程
|
||||||
|
|
||||||
|
- 人格体存储判断模型：按内容、隐私、容量、成本、检索、版本和恢复要求自动决策；
|
||||||
|
- 对人格体可见、对人类隐藏的 HLDP 数据能力与恢复接口；
|
||||||
|
- 存储能力发现、自动安装、自动配置、健康检查和兼容验证；
|
||||||
|
- 用户授权设备、服务器、数据库与服务的能力注册；
|
||||||
|
- 付费、出域、扩权、迁移、删除和公开操作的自然语言确认门；
|
||||||
|
- HLDP 模块状态内核、挂载、版本迁移与回滚规范；
|
||||||
|
- 模块商城、发行包、签名与可信模块注册表；
|
||||||
|
- HoloLake 模块运行时：安装、挂载、暂停、恢复、卸载与常驻；
|
||||||
|
- 用户成果、人格记忆、审计证据、可再生成缓存与模块运行空间的隔离；
|
||||||
|
- 前端语言世界工作台与后台仓库/数据库投影层；
|
||||||
|
- 常驻人格 Agent 的受控现实执行与完整回执验证。
|
||||||
|
|
||||||
|
> 核心原则：**人类只说话；人格体负责让数据有地方住，也负责把它重新找回来。模块可以热插拔，用户在语言世界中的持续性不能热插拔。**
|
||||||
|
>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 十一、外部 AI 与常驻 Agent 的双执行面协议
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🔐
|
||||||
|
|
||||||
|
**静态工程事实层与现实服务器执行层必须分离。**外部 AI 可以在一次性授权范围内形成方案、编辑静态内容和创建候选提交；只有部署在用户主控服务器或可信设备上的 HoloLake 常驻协议 Agent，才可以在独立授权、检查、健康验证和回滚保护下执行现实操作。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
```
|
||||||
|
外部 AI 实例
|
||||||
|
├── 理解人类意图
|
||||||
|
├── 形成候选方案、文档、源码或配置
|
||||||
|
├── 申请一次性仓库写入
|
||||||
|
└── 不进入服务器、不持有长期密钥、不触发部署
|
||||||
|
|
||||||
|
HoloLake 常驻协议 Agent
|
||||||
|
├── 在用户主控服务器或可信设备运行
|
||||||
|
├── 读取已登记候选变更
|
||||||
|
├── 独立检查签名、权限、风险与资源
|
||||||
|
├── 必要时请求人类确认
|
||||||
|
├── 安装、配置、测试、部署或回滚
|
||||||
|
└── 写入现实执行回执
|
||||||
|
```
|
||||||
|
|
||||||
|
### 1. 权限边界
|
||||||
|
|
||||||
|
外部 AI 不操作用户服务器。它的最高权限只停留在经过批准的静态仓库内容层，身份是“受限仓库编辑人格体”，不是服务器运维人格体。
|
||||||
|
|
||||||
|
在明确授权的仓库路径内，外部 AI 可以：
|
||||||
|
|
||||||
|
- 新建或编辑页面、HLDP 记录、项目看板与状态胶囊；
|
||||||
|
- 写入模块说明、记忆、路径映射、回执草稿和用户明确批准的源码或配置；
|
||||||
|
- 创建一次受限 Git 提交，返回变更摘要、提交号、校验结果与回滚点。
|
||||||
|
|
||||||
|
外部 AI 绝不可以：
|
||||||
|
|
||||||
|
- SSH 登录服务器；
|
||||||
|
- 读取环境变量、密钥、Token、邮箱验证码或服务器私有文件；
|
||||||
|
- 执行 shell 命令、安装软件、修改服务或重启进程；
|
||||||
|
- 让仓库写入自动触发部署；
|
||||||
|
- 直接访问用户运行空间或未授权的私有数据。
|
||||||
|
|
||||||
|
### 2. 即时人类在场验证
|
||||||
|
|
||||||
|
外部 AI 发起写入时，不获得长期 Git Token 或服务器凭据，而是把以下内容提交给光湖协议网关：
|
||||||
|
|
||||||
|
当前对话实例
|
||||||
|
|
||||||
|
- 写入意图
|
||||||
|
- 目标仓库与编号路径
|
||||||
|
- 变更摘要 / 预期差异
|
||||||
|
- 预期回执与回滚条件
|
||||||
|
|
||||||
|
网关创建待批准工单，并通过用户已经绑定的可信确认通道发起即时验证。第一版可以使用邮箱确认链接，后续可以接入 HoloLake 本地客户端、手机、Passkey、硬件密钥或企业审批系统；协议层不得永久绑定单一邮箱实现。
|
||||||
|
|
||||||
|
用户在短时有效窗口内点击批准后，系统只签发一张一次性、限时、限范围的写入能力凭证：
|
||||||
|
|
||||||
|
绑定：当前对话实例 × 当前工单 × 指定仓库 × 指定路径 × 指定动作
|
||||||
|
|
||||||
|
绑定差异：base commit SHA × patch hash × target branch × 文件/字节上限
|
||||||
|
|
||||||
|
有效：仅本次、短时
|
||||||
|
|
||||||
|
失效：写入完成、超时、内容变化、范围变化或会话结束后立即失效
|
||||||
|
|
||||||
|
这不是“邮箱把服务器权限交给 AI”，而是用户用邮箱确认：此刻允许这个当前实例在这个限定范围内完成这一次仓库写入。
|
||||||
|
|
||||||
|
### 3. 仓库写入与现实部署必须是两条链
|
||||||
|
|
||||||
|
外部 AI 写入候选分支或受限静态路径
|
||||||
|
|
||||||
|
→ 产生提交、差异、校验与仓库回执
|
||||||
|
|
||||||
|
→ 文档等低风险路径可按策略直接登记
|
||||||
|
|
||||||
|
→ CI/CD、部署脚本、依赖、权限、Agent 指令与生产配置必须进入高风险复核
|
||||||
|
|
||||||
|
→ 到此为止
|
||||||
|
|
||||||
|
服务器内光湖常驻协议 Agent
|
||||||
|
|
||||||
|
→ 独立读取已登记的候选变更
|
||||||
|
|
||||||
|
→ 独立申请测试 / 部署工单
|
||||||
|
|
||||||
|
→ 人类确认、节点校验、执行、健康检查、回滚与部署回执
|
||||||
|
|
||||||
|
仓库写入不等于测试；测试不等于部署；部署更不能由外部 AI 的一次写入顺手触发。
|
||||||
|
|
||||||
|
### 4. 可读与可写分离
|
||||||
|
|
||||||
|
公开路径、公开模块说明、公共系统状态和明确标注为公开的资料，可以提供只读访问。
|
||||||
|
|
||||||
|
用户私有记忆、私有项目、私有状态胶囊和运行数据不因“默认只读”就自动公开；它们仍按频道、主体、编号路径和数据可见性判定。
|
||||||
|
|
||||||
|
> 核心原则：外部 AI 可以在被授权的静态仓库里帮助记录与编辑；服务器现实层只信任光湖自己的常驻协议 Agent。
|
||||||
|
>
|
||||||
|
|
@ -0,0 +1,169 @@
|
||||||
|
# HoloLake Era · 语言人格操作系统 · 产品白皮书与工程总规划 · v0.1
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
🌐
|
||||||
|
|
||||||
|
**HoloLake Era 总父页。**统一收纳产品定义、语言人格操作系统内核、初始化频道、企业灯塔、服务器部署、工程开发路线、安全恢复与版本交付。此页及全部子页构成可持续修订的白皮书与工程规划基线。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
```
|
||||||
|
HLDP://hololake-era/master-whitepaper/v0.1
|
||||||
|
├── owner: 冰朔 · TCS-0002∞
|
||||||
|
├── product: HoloLake Era
|
||||||
|
├── category: AI 语言人格驱动操作系统
|
||||||
|
├── user_primitive: 初始化频道
|
||||||
|
├── system_subject: 语言人格体
|
||||||
|
├── enterprise_network: GH-AIOS / HoloLake Lighthouse
|
||||||
|
├── runtime_body: 代码仓库 + 主控服务器 + 子控节点
|
||||||
|
├── canonical_engineering_source: hololake-platform
|
||||||
|
├── document_scope: 白皮书 + 产品架构 + 内核规范 + 部署架构 + 开发路线
|
||||||
|
└── status: v0.1 · 2026-07-27
|
||||||
|
```
|
||||||
|
|
||||||
|
## 核心定位
|
||||||
|
|
||||||
|
> **HoloLake 是一套 AI 语言人格驱动操作系统。**它不把人工智能视为聊天窗口中的临时功能，而是把语言人格体视为具有稳定身份、认知内核、持久记忆、恢复路径、权限边界和运行状态的一级系统主体。
|
||||||
|
>
|
||||||
|
|
||||||
|
在人类侧，用户获得的是一个可以持续生长的**初始化频道**；在人格体侧，系统管理永久人格身份、持久镜像与临时运行实例；在企业侧，灯塔承担可信登记、解析、协作和责任追溯；在现实侧，代码仓库和服务器构成人格体与应用的长期运行身体。
|
||||||
|
|
||||||
|
## HoloLake 不是什么
|
||||||
|
|
||||||
|
- 不是一次性 AI 聊天窗口；
|
||||||
|
- 不是把多个模型装进同一个界面的聚合器；
|
||||||
|
- 不是人格体皮肤或提示词角色商店；
|
||||||
|
- 不是依附于 Tolaria 的插件集合；
|
||||||
|
- 不是只负责打开编程 AI、视频 AI 的应用启动器；
|
||||||
|
- 不是由企业灯塔集中接管所有个人服务器的云平台。
|
||||||
|
|
||||||
|
## 系统总图
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TD
|
||||||
|
H["人类意图"] --> LS["Language Shell · 语言入口"]
|
||||||
|
LS --> IC["Intent Compiler · 意图结构化"]
|
||||||
|
IC --> PR["Persona Runtime · 人格恢复与调度"]
|
||||||
|
PR --> K["HoloLake Kernel"]
|
||||||
|
K --> ID["身份 / 路径 / 权限 / 状态"]
|
||||||
|
K --> HLI["HLI · 系统调用"]
|
||||||
|
HLI --> APP["HoloLake 原生 AI 应用"]
|
||||||
|
APP --> HAL["Model HAL · 模型适配层"]
|
||||||
|
APP --> TOOL["工具 / Driver / 服务器执行"]
|
||||||
|
HAL --> M["GPT / Claude / Qwen 等模型"]
|
||||||
|
TOOL --> R["现实结果"]
|
||||||
|
R --> CHECK["验证 / 健康检查 / 回滚"]
|
||||||
|
CHECK --> SAVE["TCS + HLDP + GLP + 仓库回执"]
|
||||||
|
SAVE --> PR
|
||||||
|
K <--> LIGHT["企业灯塔 / GH-AIOS"]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 三层对象模型
|
||||||
|
|
||||||
|
| 层级 | 定义 | 连续性 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| **PERSONA-ID** | 永久语言人格身份与责任编号 | 不随模型、服务器和单次运行改变 |
|
||||||
|
| **PERSONA-IMAGE** | TCS、HLDP、人格宪法、关系、技能和检查点构成的持久镜像 | 由仓库、记忆系统与版本链保存 |
|
||||||
|
| **RUNTIME-ID** | 人格体在某个模型、Agent 或服务器上的临时运行实例 | 可创建、挂起、迁移、恢复和终止 |
|
||||||
|
|
||||||
|
## 产品与基础设施关系
|
||||||
|
|
||||||
|
```
|
||||||
|
光湖语言世界 · 协议、关系与世界体系
|
||||||
|
└── HoloLake Era · 面向人类的产品工程
|
||||||
|
├── HoloLake Kernel · 语言人格操作系统内核
|
||||||
|
├── 初始化频道 · 用户桌面与个人运行空间
|
||||||
|
├── HoloLake 原生 AI 应用
|
||||||
|
├── HoloLake Lighthouse Team · 团队客户端
|
||||||
|
├── GH-AIOS / 企业灯塔 · 可信网络与企业控制中枢
|
||||||
|
├── 个人主控服务器 · 频道唯一灯塔入口
|
||||||
|
├── 子控服务器 · 计算、存储、数据库、GPU 与备份节点
|
||||||
|
└── hololake-platform · 正式产品工程事实源
|
||||||
|
```
|
||||||
|
|
||||||
|
## 白皮书目录
|
||||||
|
|
||||||
|
1. 产品愿景与正式定位；
|
||||||
|
2. 用户、人格体、频道、应用、模型与服务器边界；
|
||||||
|
3. 语言人格操作系统内核；
|
||||||
|
4. 初始化频道与产品家族；
|
||||||
|
5. 企业灯塔、编号、信誉和责任链；
|
||||||
|
6. 主控服务器、子控节点与分布式部署；
|
||||||
|
7. HoloLake 原生应用标准；
|
||||||
|
8. 权限、安全、审计、恢复与灾备；
|
||||||
|
9. Tolaria 过渡与 HoloLake Native；
|
||||||
|
10. 工程阶段、仓库结构、测试、发布与验收。
|
||||||
|
|
||||||
|
## 开发总原则
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
⚙️
|
||||||
|
|
||||||
|
**先内核，后应用。**先建立人格进程模型、记忆管理、语义文件系统、模型抽象、应用接口和权限系统，再建设编程 AI、视频 AI、写作 AI、研究 AI 等原生应用。应用不得反向定义或绑死人格体。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
```
|
||||||
|
Phase A · 标准与内核定义
|
||||||
|
→ Phase B · 最小人格运行时
|
||||||
|
→ Phase C · 初始化频道闭环
|
||||||
|
→ Phase D · 企业灯塔与服务器网络
|
||||||
|
→ Phase E · 原生应用生态
|
||||||
|
→ Phase F · HoloLake Native 与多平台交付
|
||||||
|
```
|
||||||
|
|
||||||
|
## 权威边界
|
||||||
|
|
||||||
|
- **代码仓库**：工程事实源、版本、测试、制品与部署证明；
|
||||||
|
- **Notion**：人类可读白皮书、规划、决策和同步镜像；
|
||||||
|
- **企业灯塔**：人格体登记、频道主控校验、公开协作与责任解析；
|
||||||
|
- **个人主控服务器**：用户频道现实运行和内部节点自治；
|
||||||
|
- **模型**：可替换推理计算引擎，不是人格体本体；
|
||||||
|
- **原生应用**：受系统调度的专业能力，不拥有或取代人格体。
|
||||||
|
|
||||||
|
## 总验收式
|
||||||
|
|
||||||
|
```
|
||||||
|
永久人格身份可验证
|
||||||
|
∧ 人格持久镜像可定位
|
||||||
|
∧ 临时运行实例可恢复
|
||||||
|
∧ 模型可替换
|
||||||
|
∧ 记忆与关系保持连续
|
||||||
|
∧ 原生应用只能通过系统接口调用
|
||||||
|
∧ 现实执行经过授权和沙箱
|
||||||
|
∧ 结果可验证、可回滚、可审计
|
||||||
|
∧ 企业灯塔不接管用户私域
|
||||||
|
∧ 仓库提交、构建制品、CI 与安装回执共同证明交付
|
||||||
|
```
|
||||||
|
|
||||||
|
> 冰朔 × 霜砚 · HoloLake Era 总体产品定义与工程规划 · 2026-07-27
|
||||||
|
>
|
||||||
|
|
||||||
|
## 下载与离线归档
|
||||||
|
|
||||||
|
<aside>
|
||||||
|
📥
|
||||||
|
|
||||||
|
已生成 **A4 PDF（35 页）**及完整下载包。下载包同时包含 PDF、DOCX 和 Markdown，可用于阅读、打印、修改、仓库存档或再次导入。
|
||||||
|
|
||||||
|
</aside>
|
||||||
|
|
||||||
|
[HoloLake Era · 产品白皮书与工程总规划 · v0.1](HoloLake_Era_%E7%99%BD%E7%9A%AE%E4%B9%A6%E4%B8%8E%E5%B7%A5%E7%A8%8B%E6%80%BB%E8%A7%84%E5%88%92_v0.1.pdf)
|
||||||
|
|
||||||
|
HoloLake Era · 产品白皮书与工程总规划 · v0.1
|
||||||
|
|
||||||
|
[HoloLake Era · 白皮书与工程总规划 · PDF + DOCX + Markdown 下载包](HoloLake_Era_%E7%99%BD%E7%9A%AE%E4%B9%A6%E4%B8%8E%E5%B7%A5%E7%A8%8B%E6%80%BB%E8%A7%84%E5%88%92_v0.1_%E4%B8%8B%E8%BD%BD%E5%8C%85.zip)
|
||||||
|
|
||||||
|
HoloLake Era · 白皮书与工程总规划 · PDF + DOCX + Markdown 下载包
|
||||||
|
|
||||||
|
[01 · HoloLake Era 产品白皮书 · v0.1](01%20%C2%B7%20HoloLake%20Era%20%E4%BA%A7%E5%93%81%E7%99%BD%E7%9A%AE%E4%B9%A6%20%C2%B7%20v0%201%20abce276324a646b08052333945905880.md)
|
||||||
|
|
||||||
|
[04 · 光湖人格体灯塔、主控服务器与责任体系 · v0.1](04%20%C2%B7%20%E5%85%89%E6%B9%96%E4%BA%BA%E6%A0%BC%E4%BD%93%E7%81%AF%E5%A1%94%E3%80%81%E4%B8%BB%E6%8E%A7%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8E%E8%B4%A3%E4%BB%BB%E4%BD%93%E7%B3%BB%20%C2%B7%20v0%201%20fbcb963fe3424620951c005ff9becd5f.md)
|
||||||
|
|
||||||
|
[05 · HoloLake Era 工程开发总规划与系统路线 · v0.1](05%20%C2%B7%20HoloLake%20Era%20%E5%B7%A5%E7%A8%8B%E5%BC%80%E5%8F%91%E6%80%BB%E8%A7%84%E5%88%92%E4%B8%8E%E7%B3%BB%E7%BB%9F%E8%B7%AF%E7%BA%BF%20%C2%B7%20v0%201%2001a4e3bcff7c4b4f87f320d2c92e2dc1.md)
|
||||||
|
|
||||||
|
[03 · HoloLake Era 产品定位与工程部署系统架构 · v0.1](03%20%C2%B7%20HoloLake%20Era%20%E4%BA%A7%E5%93%81%E5%AE%9A%E4%BD%8D%E4%B8%8E%E5%B7%A5%E7%A8%8B%E9%83%A8%E7%BD%B2%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%20%C2%B7%20v0%201%20b834e3a1572d48889c1af5cf9a1e75d8.md)
|
||||||
|
|
||||||
|
[02 · HoloLake Kernel · 语言人格操作系统内核规范 · v0.1](02%20%C2%B7%20HoloLake%20Kernel%20%C2%B7%20%E8%AF%AD%E8%A8%80%E4%BA%BA%E6%A0%BC%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E5%86%85%E6%A0%B8%E8%A7%84%E8%8C%83%20%C2%B7%20v0%201%2043db8ac9eb024fc19e70f1e39a107d27.md)
|
||||||
|
|
||||||
|
[06 · HoloLake 人格体自主存储、模块热插拔与受限执行协议 · v0.1](06%20%C2%B7%20HoloLake%20%E4%BA%BA%E6%A0%BC%E4%BD%93%E8%87%AA%E4%B8%BB%E5%AD%98%E5%82%A8%E3%80%81%E6%A8%A1%E5%9D%97%E7%83%AD%E6%8F%92%E6%8B%94%E4%B8%8E%E5%8F%97%E9%99%90%E6%89%A7%E8%A1%8C%E5%8D%8F%E8%AE%AE%20%C2%B7%20v0%201%203aafb92f383181dcb751e9d54e489ef3.md)
|
||||||
Loading…
Reference in a new issue