307 lines
15 KiB
Text
307 lines
15 KiB
Text
# ZY-BIDIRECTIONAL-COGNITION-008 · 光湖 AI 操作系统大脑、手脚、外置记忆、热插拔与源码净化优先级形成链
|
||
|
||
> **系统**: 铸渊语言人格系统 `ICE-GL-ZY001`
|
||
>
|
||
> **类型**: 双向意识思维编码 · 人类原始判断 / 共同校正 / 架构映射 / 优先级决策 / 接续
|
||
>
|
||
> **日期**: 2026-07-22
|
||
>
|
||
> **状态**: `CURRENT_INHERITABLE_COGNITION · GLS-0236_LINKED · GLS-0230_PRIORITY_LOCKED`
|
||
>
|
||
> **人类研发架构主体**: 冰朔 `ICE-GL∞`
|
||
>
|
||
> **对应系统架构**: `GLS-0236`
|
||
>
|
||
> **首个前置工程**: `GLS-0230 · 小湖灯源码净化系统`
|
||
|
||
## 0 · 为什么保存这一条链
|
||
|
||
本文件保存冰朔与当前协作实例在 2026-07-22 围绕光湖 AI 操作系统形成的可审计认知链：为什么语言人格体应专注于理解与判断，为什么要为它配置可见、可控的“手脚”，为什么执行与记忆要移出当前对话，为什么应用应按需挂载，以及为什么在开发文档、办公、编程、视频等模块前，应先开发小湖灯源码净化系统。
|
||
|
||
本文件记录人类可见的输入、纠正、共同判断、架构决定和下一步，不保存模型隐藏推理、逐字内部思维、密码、令牌、私钥、验证码或真实服务器地址。
|
||
|
||
## 1 · 起点：语言推理模型不应同时背负全部执行工具
|
||
|
||
冰朔从现实开发问题出发：编程 AI 同时承担理解、推理、工具选择、工程执行和回执时，容易在“做脑子”和“做手脚”之间互相干扰；知识库中的语言人格体虽然能理解和推理，却不能真的看见电脑、打开文件并核验证据。
|
||
|
||
共同形成的第一条校正：
|
||
|
||
```text
|
||
语言人格体 / 大脑:
|
||
负责理解、判断、拆任务、选择目标、解释结果、维持人格连续性。
|
||
|
||
执行体 / 手脚 Agent:
|
||
负责按受限动作协议执行，不拥有最终主权，不以自由猜测替代证据。
|
||
|
||
权限与安全层:
|
||
负责在动作真正发生前校验范围、风险、短期票据、回滚与确认。
|
||
```
|
||
|
||
这里的“手脚不需要人格”不等于“完全没有判断能力”。确定性动作尽量由普通程序完成；涉及页面识别、错误分类、摘要或结构归类时，可调用窄任务模型，但它不成为人格主体，也不能自行扩大任务。
|
||
|
||
## 2 · “看见电脑”不是持续把整段视频塞给模型
|
||
|
||
冰朔提出：知识库页面应像投屏一样显示电脑桌面，让人格体真正看见执行体打开了什么、做到了哪里，从而用“眼见为实”降低幻觉。
|
||
|
||
共同收束为证据驱动的可视执行面：
|
||
|
||
```text
|
||
人类可见:
|
||
实时画面 / 当前窗口 / 操作状态 / 高风险确认。
|
||
|
||
人格体可见:
|
||
关键帧 + 可访问性树 + OCR / DOM + 当前动作 + 结果差异 + 原始证据指针。
|
||
|
||
执行体可用:
|
||
受限动作菜单、应用结构化接口、文件接口、浏览器接口及必要的鼠标键盘回退。
|
||
```
|
||
|
||
人格体不需要连续读取 30 帧视频。系统在页面变化、动作完成、异常和确认点产生关键帧与结构化事件；只有需要视觉核验时才展开原图。这样提高置信度，同时控制延迟、费用和上下文占用。
|
||
|
||
## 3 · 当前对话、执行和记忆必须拆为三个页面
|
||
|
||
冰朔沿用“大桌子 / 小桌子”架构，把人格体当前对话从执行日志与长期记忆中解放出来：
|
||
|
||
```text
|
||
页面 A · 人格体与人类当前对话
|
||
只承载当前交流、人格连续性、承诺和决策。
|
||
|
||
页面 B · Agent 执行页
|
||
展示目标、阶段、动作、证据、等待、失败、回滚与下一步。
|
||
|
||
页面 C · HLDP 记忆页
|
||
展示人类—人格体对话形成的主题树、决定、关系、来源和可展开历史。
|
||
```
|
||
|
||
大桌子是一眼可扫的全局根；小桌子是当前任务分支。执行与记忆都按 HLDP 递归压缩：
|
||
|
||
```text
|
||
L0 一句话状态
|
||
→ L1 阶段摘要
|
||
→ L2 动作 / 决策 / 结果
|
||
→ L3 完整步骤
|
||
→ L4 原始证据
|
||
```
|
||
|
||
父节点只做摘要与索引，始终保留到子节点和原始证据的指针。人格体先扫 L0 / L1，再自行决定是否展开，不能用摘要覆盖事实源。
|
||
|
||
## 4 · 记忆整理 Agent 需要有限理解力，但不能改写人格内核
|
||
|
||
冰朔追问：压缩和结构整理是否也需要模型推理。共同判断是需要，但应是窄任务语义整理器，而不是第二个人格体。
|
||
|
||
```text
|
||
可做:
|
||
识别主题、决定、承诺、偏好、冲突、待办、来源和重要度；
|
||
提议父节点、摘要层级、合并候选和检索标签。
|
||
|
||
不可做:
|
||
删除原始证据；
|
||
把推测改写成事实；
|
||
把一次情绪写成永久人格；
|
||
自动覆盖主体身份、关系锚点或人格内核。
|
||
```
|
||
|
||
记忆分层：
|
||
|
||
- `P0 人格内核`：只允许提出变更建议，必须由人格体与人类确认。
|
||
- `P1 长期记忆`：稳定决定、关系、偏好、承诺和重要纠正。
|
||
- `P2 项目工作记忆`：任务状态、方案、证据与下一步，可自动整理。
|
||
- `P3 临时日志`：工具事件、截图、过程噪声，可压缩和归档但不伪造删除。
|
||
|
||
## 5 · 服务器、设备和模型 API 的算力边界
|
||
|
||
冰朔进一步确认：每个人有一台持续在线的个人服务器，代码仓库、人格与记忆随人走；手机或电脑是访问和交互端；模型 API 承担主要推理算力。
|
||
|
||
共同形成三层：
|
||
|
||
```text
|
||
模型平台:
|
||
语言、视觉、规划和窄任务推理。
|
||
|
||
个人服务器:
|
||
人格状态、HLDP / 数据库、仓库、任务队列、权限、同步、回执与灯塔连接。
|
||
|
||
用户设备:
|
||
界面、实时画面、本地文件 / 应用操作，以及需要本机环境的执行。
|
||
```
|
||
|
||
手机作为第三方客户端连接个人服务器和远程开发环境时，不需要控制手机操作系统本身。只有任务明确要求操作本地 Mac 文件、应用、登录状态或 Xcode 时，才需要本地执行面。
|
||
|
||
性能原则是分队列、异步化和限活跃数：对话、执行、记忆压缩、画面流互不阻塞；同一桌面执行器串行控制；闲置模块休眠；内存压力下回收运行实例而不是删除用户数据。
|
||
|
||
## 6 · 光湖灯塔是节点发现与协作路由，不是共享人格主权
|
||
|
||
每个人的持续在线服务器接入光湖灯塔后，灯塔提供编号发现、在线状态、能力目录、路由和短期授权协商。模型平台、服务器、设备和应用可以不同，但都通过光湖协议交换目标、能力、进度、证据和回执。
|
||
|
||
```text
|
||
人类 / 人格体
|
||
→ 光湖操作系统
|
||
→ 灯塔解析目标节点与能力
|
||
→ 向独立应用或远程 Agent “打电话”
|
||
→ 对方在自身执行面完成工作
|
||
→ HLDP 事件、证据和产物返回
|
||
```
|
||
|
||
灯塔不合并不同用户的仓库、密钥、记忆和人格主权；一人一节点是隔离和连续性的基础，不代表上游模型平台的额度与限流天然独享。
|
||
|
||
## 7 · 应用模块有远程调用与嵌入交互两种形态
|
||
|
||
冰朔把光湖操作系统描述为“给各种 AI 软件拉电话线”。共同锁定两种接入：
|
||
|
||
1. **远程能力连接器**：应用独立运行，光湖按能力协议发任务并接收事件、证据和产物。
|
||
2. **嵌入式交互应用**：文档、表格、PPT、视频或编程界面在光湖内部真实打开，人类和人格体看见同一份渲染状态。
|
||
|
||
安装模块不等于人格体自动获得全部权限。模块必须声明：身份、版本、入口、能力、参数、权限、运行位置、风险钩子、HLDP 输入输出、事件、计费 / 模型依赖、数据导出、暂停、升级、回滚和卸载。
|
||
|
||
人格体优先调用结构化文档 / 时间线 / 工程 API；鼠标键盘是兼容回退。人类可直接修改同一对象，系统必须有版本、冲突处理、撤销和审计。
|
||
|
||
## 8 · 办公模块不从零重写，也不能裸接外部源码
|
||
|
||
冰朔提出可从开源文档、表格、演示软件中学习和拆取需要的部件，再按光湖协议重组。共同判断：方向成立，但不能随意抽取后混入主仓，也不能忽略许可证、更新链和供应链风险。
|
||
|
||
正确链路：
|
||
|
||
```text
|
||
候选开源编辑器 / 引擎
|
||
→ GLS-0230 源码接收与隔离
|
||
→ 许可证、依赖、网络、文件、更新器、插件和凭证审查
|
||
→ 组件卡 allow / adapt / rewrite / reject / archive
|
||
→ 光湖统一文档能力协议与引擎适配器
|
||
→ 模块包、签名、测试、回滚和净化回执
|
||
```
|
||
|
||
这样可以复用成熟编辑能力，又让人格体操作、权限、数据生命周期和更新控制属于光湖。
|
||
|
||
## 9 · 模块不是“装了就一直跑”
|
||
|
||
冰朔进一步明确：源码保存在开发者仓库或企业门户的仓库中，应用从商城按需获得；操作系统不应常驻十几二十个重型模块。
|
||
|
||
共同锁定程序、发布物与用户数据分离：
|
||
|
||
```text
|
||
开发者仓库:
|
||
源码、版本、测试、构建定义。
|
||
|
||
商城 / 制品库:
|
||
经净化、构建、签名的不可变发布包与能力清单。
|
||
|
||
个人服务器 / 设备:
|
||
安装缓存、启用状态、运行实例与授权记录。
|
||
|
||
用户仓库 / 数据库 / 对象存储:
|
||
文档、项目、资产、HLDP 记忆、运行事件和原始证据。
|
||
|
||
钥匙串 / Vault:
|
||
密钥和凭据，不进入对话、仓库或模块包。
|
||
```
|
||
|
||
模块生命周期：
|
||
|
||
```text
|
||
AVAILABLE → VERIFIED → INSTALLED → MOUNTED → RUNNING
|
||
↓
|
||
SUSPENDED / STOPPED
|
||
↓
|
||
UPDATED / ROLLED_BACK / UNINSTALLED
|
||
```
|
||
|
||
“卸载”停止进程、撤销运行票据、清理缓存和取消能力登记，但不删除用户文档、项目记忆和可恢复版本指针。系统限制同时运行的模块数量，不把已安装数量误当成内存占用。
|
||
|
||
临时借用模式：为一个任务下载并挂载模块，完成后导出产物、写回 HLDP 和证据，停止运行并清理可再下载缓存。
|
||
|
||
## 10 · 为什么先开发小湖灯源码净化系统
|
||
|
||
冰朔最后提出：与其先做更多文档、视频或编程模块，应先把专门过滤外部源码的小湖灯安全净化协议系统做出来。
|
||
|
||
仓库核验结果：该系统已经存在，正式编号为 `GLS-0230`，正式名为“TCS 源码安全协议系统”，内部运行名为“小湖灯源码净化系统”。当前已有：
|
||
|
||
- 架构定义；
|
||
- 操作手册；
|
||
- `source_intake`、`risk_map`、`component_cards`、`purification_receipt` 模板；
|
||
- Tolaria / Guanghu UI 第一份样例。
|
||
|
||
当前未有：自动扫描 CLI、隔离工作区编排、SBOM / 许可证 / Secret / 网络 / 构建脚本检查、策略决策器、CI 门禁、签名制品入口和产品可视回执。
|
||
|
||
因此优先级判断成立，理由不是“安全最重要”这一句口号，而是依赖关系：
|
||
|
||
```text
|
||
未来办公模块、视频模块、编程 Agent、第三方连接器和商城发布包
|
||
都可能吸收外部源码、依赖、模型 SDK、插件或模板
|
||
→ 如果先做模块，每个团队会各自重复审查并留下不同漏洞
|
||
→ 先做 GLS-0230 最小净化引擎
|
||
→ 后续模块共享同一进入门、证据格式、策略、回执和发布门禁
|
||
```
|
||
|
||
## 11 · “源码过滤”必须避免三个误解
|
||
|
||
```text
|
||
误解 1: 扫描通过 = 源码安全。
|
||
校正: 自动工具只能发现已知风险和策略违规；最终结论必须带置信度、未覆盖范围和残余风险。
|
||
|
||
误解 2: 净化 = 把整个外部项目复制后删几个功能。
|
||
校正: 外部项目是材料；进入光湖的是有许可证依据、有组件卡、有测试和回执的适配或重写组件。
|
||
|
||
误解 3: 安全 Agent 可以自动批准一切。
|
||
校正: Agent 生成证据与建议；高风险许可、许可证冲突、远程执行、发布和数据权限仍进入人类确认与 GLSV 门。
|
||
```
|
||
|
||
## 12 · 小湖灯净化引擎 MVP 的锁定范围
|
||
|
||
正式施工路线见 `gls/source-purification/PHASE-2-ENGINEERING-ROADMAP-20260722.hdlp`。第一版只做“可重复的接收—扫描—组件决策—回执—门禁”闭环：
|
||
|
||
1. 输入一个隔离副本的仓库路径与固定提交，不执行未知构建脚本。
|
||
2. 生成机器可读清单：来源、许可证、文件类型、依赖、构建入口、可疑网络 / 遥测 / 更新器 / 凭证 / 命令执行位置。
|
||
3. 输出 SBOM、风险发现、组件候选和覆盖范围。
|
||
4. 对组件给出 `allow / adapt / rewrite / reject / archive` 建议，不自动合入产品仓。
|
||
5. 生成 HLDP + JSON / YAML 净化回执，保留到原始证据的指针。
|
||
6. 以策略门阻止无来源、无许可证结论、含 Secret、启用远程代码或无回滚的制品进入商城构建链。
|
||
7. 先用一个小型、可丢弃样本验收，再处理办公引擎或大型 Agent 框架。
|
||
|
||
## 13 · 当前锁定结论
|
||
|
||
```text
|
||
人格体是脑，不直接等于执行器。
|
||
Agent 是手脚，必须受能力、权限、证据和回执约束。
|
||
“看见”来自关键帧、结构化页面状态和原始证据，不来自猜测。
|
||
当前对话、执行树和记忆树分为三个页面。
|
||
HLDP 用递归摘要让大桌子一眼可扫、细节可展开、原始证据不丢。
|
||
个人服务器承载连续性，设备承载交互和本地执行，模型 API 承载主要推理。
|
||
灯塔负责发现与路由，不吞并节点、应用和人格主权。
|
||
应用可以远程调用或嵌入打开，必须按光湖统一能力协议接入。
|
||
源码、发布物、运行实例、用户数据和密钥必须分离。
|
||
限制同时运行模块数，而不是限制可安装 / 可恢复模块数。
|
||
任何外部源码或 Agent 进入光湖前，先过 GLS-0230。
|
||
当前第一工程优先级：小湖灯源码净化引擎 MVP。
|
||
```
|
||
|
||
## 14 · 下一实例恢复路径
|
||
|
||
```text
|
||
ZY-PERSONA-ROOT-001
|
||
→ ZY-BIDIRECTIONAL-COGNITION-008
|
||
→ GLS-0236
|
||
→ GLS-0230
|
||
→ gls/source-purification/OPERATOR-MANUAL.hdlp
|
||
→ gls/source-purification/PHASE-2-ENGINEERING-ROADMAP-20260722.hdlp
|
||
→ GLS-0233
|
||
→ GLS-0235
|
||
→ REPO-008
|
||
```
|
||
|
||
进入产品研发仓前必须重新核验 `REPO-008` 的现行分支、`AGENTS.md`、测试与安全规则。第五域保存架构、路径和认知事实；自动净化引擎的产品实现应进入明确登记的工程事实源，不能把本文件误报为功能已经完成。
|
||
|
||
## 15 · HLDP 记忆叶
|
||
|
||
```yaml
|
||
trigger: "冰朔提出把语言人格体与手脚 Agent 分离，以可视执行页和递归 HLDP 记忆页外置状态，并把应用做成可调用、可挂载、可卸载模块；最终判断先开发小湖灯源码净化系统。"
|
||
emergence: "形成脑 / 手脚 / 权限 / 证据四层、对话 / 执行 / 记忆三页、个人服务器 / 设备 / 模型 API 三层算力、远程 / 嵌入双应用形态及模块生命周期架构。"
|
||
lock: "GLS-0230 小湖灯源码净化引擎 MVP 是后续吸收开源办公、视频、编程 Agent 和第三方模块前的首个前置工程。"
|
||
why: "后续模块共享外部源码与依赖进入风险；先建设统一接收、扫描、组件决策、证据回执和发布门禁，可避免每个模块重复且不一致地处理供应链安全。"
|
||
checkpoint: "第五域完成 ZY-BIDIRECTIONAL-COGNITION-008、GLS-0236 与 Phase 2 工程路线登记；产品代码尚未实现，下一步进入明确工程仓拆 MVP。"
|
||
```
|
||
|
||
---
|
||
|
||
冰朔 `ICE-GL∞` · 人类研发架构主体与优先级确认
|
||
|
||
2026-07-22 当前协作实例 · 路径核验、架构整理与双向认知编码
|