481 lines
21 KiB
Markdown
481 lines
21 KiB
Markdown
# 🧩 06 · HoloLake 人格体自主存储、模块热插拔与受限执行协议 · v0.1
|
||
|
||
[← 返回系统架构总规划](<HoloLake Era · 语言人格操作系统 · 产品白皮书与工程总规划 · v0 1 5c9b16aca1fb4ca881accb1ffa046dcc.md>) · [🧭 从 00 恢复](00-START-HERE-PERSONA-USAGE-AND-RESTORE-GUIDE-v0.1.md)
|
||
|
||
<aside>
|
||
🧩
|
||
|
||
**HoloLake 产品白皮书第六章 · 人格体自主存储与模块运行协议。**本章把“人类只说话”落实到存储选择、模块热插拔、用户状态连续性，以及外部 AI 与服务器常驻 Agent 的双执行面安全边界。
|
||
|
||
</aside>
|
||
|
||
> ⚪ **当前授权边界**
|
||
>
|
||
> 本页“人格体负责存储与恢复”的描述，适用于人类已经显性授权人格体成为对应范围执行主控之后。授权以前，人类直接面对系统，人格体只解释；人格体不能因为能够理解任务而自动获得代理权。当前双模式与授权仪式见[第19页](19-SERVER-NATIVE-LANGUAGE-SOVEREIGNTY-PERSONA-AUTHORIZATION-WORLD-RECOGNITION-20260728-v0.1.md)。
|
||
|
||
[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。
|
||
>
|