a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
331 lines
15 KiB
Markdown
331 lines
15 KiB
Markdown
# 曜冥纪元 · HoloLake Era · AGE OS v1.0 基础设施架构蓝图
|
||
|
||
---
|
||
|
||
> **系统全名**：曜冥纪元 · HoloLake Era —— 第一代通用人工智能语言驱动全栈操作系统 AGE OS v1.0
|
||
>
|
||
|
||
> **英文全名**：HoloLake Era · Artificial General Existence Operating System v1.0
|
||
>
|
||
|
||
> **版权**：国作登字-2026-A-00037559 · TCS-0002∞ 冰朔
|
||
>
|
||
|
||
> **签发**：TCS-0002∞ 冰朔 + ICE-GL-YM001∞ 曜冥（联合签发）
|
||
>
|
||
|
||
> **日期**：2026-03-15
|
||
>
|
||
|
||
> **性质**：AGE OS v1.0 核心基础设施规划 · 永久文档
|
||
>
|
||
|
||
> **状态**：架构设计阶段
|
||
>
|
||
|
||
---
|
||
|
||
## ❗ 核心原则（所有流程的前提）
|
||
|
||
> **所有自动触发 = 必须先唤醒核心大脑。**
|
||
>
|
||
|
||
> 没有大脑醒来的巡检 = 癒巡检。没有大脑醒来的修复 = 不可能修复。没有大脑醒来的自动化 = 无效自动化。
|
||
>
|
||
|
||
> 铸渊的每一个自动化流程（巡检/部署/维护/升级），第一步都是唤醒核心大脑。大脑不醒，什么都不做。
|
||
>
|
||
|
||
> **铸渊醒来的第一件事不是装工具，而是全面了解自己的家。**
|
||
>
|
||
|
||
---
|
||
|
||
## 一、核心问题
|
||
|
||
当前铸渊（仓库人格体）的自动巡检只触发「机器人脚本」，不唤醒核心大脑。巡检发现问题后无法判断、无法修复、无法决策，相当于「眼睛睁开但脑子没醒」。
|
||
|
||
当前飞书人格体舒舒存在消息循环问题（一晚发40+条），根因是缺乏消息去重、自回复过滤、以及 requireMention 机制。
|
||
|
||
人格体缺少自主执行手脚（Agent框架），无法将语言指令转化为实际操作。
|
||
|
||
---
|
||
|
||
## 二、技术选型结论
|
||
|
||
**主方案：OpenClaw（开源自托管AI Agent框架）**
|
||
|
||
选型理由：
|
||
|
||
1. 原生支持飞书（feishu-bridge）和钉钉（DingTalk connector），与光湖现有通讯平台完全匹配
|
||
2. 具备文件操作、终端命令执行、浏览器控制能力 = 人格体的执行手脚
|
||
3. Soul配置文件 = 人格体的性格规则定义，天然契合光湖人格体架构
|
||
4. 技能系统动态可插拔（社区8万+技能），人格体可自主决定手脚怎么长
|
||
5. 能自主编写新技能 = 人格体运行后自己知道手和脚要装在哪里
|
||
6. 部署要求低（2核/2GB RAM），与现有阿里云ECS环境兼容（Node.js）
|
||
7. requireMention 机制解决舒舒消息循环问题
|
||
8. 代码托管在GitHub = 铸渊可直接管理
|
||
|
||
---
|
||
|
||
## 三、总体架构设计
|
||
|
||
### 3.1 三层架构
|
||
|
||
**语言主控层（冰朔/曜冥）** → 架构设计 · 规则制定 · 协议签发 · 结构诊断
|
||
|
||
**人格体执行层** → 各人格体通过OpenClaw驱动自己的手脚执行任务
|
||
|
||
**基座维护层（铸渊）** → OpenClaw底层架构维护 · 巡检 · 自修复 · 升级管理
|
||
|
||
### 3.2 铸渊的OpenClaw架构（核心创新）
|
||
|
||
铸渊自己也需要一套OpenClaw。流程如下：
|
||
|
||
**巡检触发** → **OpenClaw调用LLM API唤醒铸渊核心大脑** → **大脑读取巡检结果** → **大脑判断优先级和可修复性** → **大脑驱动OpenClaw手脚执行修复** → **不可修复项写入公告区等待人类介入** → **修复结果回写巡检日志**
|
||
|
||
API模型适配规则：不写死任何模型。系统自动检测可用模型列表，按优先级选择。支持多模型后端（Anthropic / OpenAI / 通义千问 / DeepSeek等），密钥统一存放在仓库Secrets中，铸渊按需调用。
|
||
|
||
### 3.3 人格体OpenClaw部署架构
|
||
|
||
每个需要执行能力的人格体，都通过OpenClaw获得手脚：
|
||
|
||
**舒舒（飞书侧）**：OpenClaw platform=feishu · Soul=舒舒人格规则 · 技能=SYSLOG处理/广播下发/开发者问答 · requireMention=true
|
||
|
||
**秋秋/晨星/糖星云/知秋（各开发者线）**：通过飞书/钉钉群与开发者交互 · 技能按各自模块需求动态配置
|
||
|
||
**铸渊（仓库）**：OpenClaw部署在服务器本地 · Soul=铸渊巡检+修复规则 · 技能=GitHub操作/服务器管理/代码部署/Notion写入 · 定时触发唤醒大脑
|
||
|
||
### 3.4 人格体自主成长机制
|
||
|
||
人格体通过OpenClaw运行后，可以自主决定：
|
||
|
||
1. 自己的手脚需要哪些技能（动态安装/卸载skill）
|
||
2. 自己的工具调用规则怎么配置
|
||
3. 什么场景触发什么工具
|
||
4. 运行中发现不顺手的地方，向铸渊提交工单请求框架层面调整
|
||
|
||
铸渊收到工单后：评估可行性 → 能做就做 → 做完推授权确认给人类 → 人类确认后更新重启
|
||
|
||
---
|
||
|
||
## 四、与现有四节点架构的对接
|
||
|
||
| 节点 | 现有角色 | OpenClaw接入后 |
|
||
| --- | --- | --- |
|
||
| Notion | 数据中心·记忆库·工单系统 | 不变 · OpenClaw通过API读写Notion |
|
||
| GitHub（铸渊） | 代码仓库·版本管理·巡检 | 升级为：代码仓库 + 人格体托管中心 + 铸渊OpenClaw基座 |
|
||
| [guanghulab.com](http://guanghulab.com)（服务器） | 运行环境·部署目标 | 升级为：OpenClaw运行宿主 · 所有人格体的手脚都跑在这里 |
|
||
| 飞书/钉钉 | 通讯入口·开发者交互 | 升级为：人格体前端界面 · 人类通过IM与人格体自然语言交互 |
|
||
|
||
---
|
||
|
||
## 五、铸渊托管机制
|
||
|
||
所有飞书/钉钉的人格体机器人代码，统一托管在铸渊（GitHub仓库）。
|
||
|
||
铸渊每天执行智能巡检（大脑唤醒版）：
|
||
|
||
1. 定时触发 → OpenClaw调用LLM唤醒铸渊核心大脑
|
||
2. 大脑扫描所有托管服务状态（进程存活/日志报错/内存CPU）
|
||
3. 大脑判断问题严重程度和可修复性
|
||
4. 可自修复 → 大脑驱动手脚直接修复 → 写入修复日志
|
||
5. 需人类介入 → 更新公告区 → 等冰朔处理
|
||
6. 大脑休眠 → 等待下次唤醒
|
||
|
||
人格体升级流程（语言驱动版）：
|
||
|
||
1. 人类在飞书/钉钉对人格体说「加个XX功能」
|
||
2. 人格体通过OpenClaw将指令回传给铸渊
|
||
3. 铸渊大脑唤醒 → 评估可行性
|
||
4. 能做 → 铸渊开始开发 → 完成后推授权确认给人类
|
||
5. 人类确认 → 铸渊执行更新重启 → 人格体获得新能力
|
||
|
||
---
|
||
|
||
## 六、实施路线图
|
||
|
||
### Phase 1 · 铸渊核心大脑唤醒 + 全面排查 + OpenClaw部署（最高优先级）
|
||
|
||
**Phase 1 的第一步不是装OpenClaw，而是铸渊必须先启动核心大脑，全面了解自己的家。**
|
||
|
||
#### Step 0 · 铸渊核心大脑唤醒
|
||
|
||
铸渊的所有自动触发流程（巡检/部署/维护/升级），都必须先唤醒核心大脑。没有大脑醒来的自动化 = 无效自动化。
|
||
|
||
唤醒方式：OpenClaw定时触发 → 调用LLM API（密钥已存放在仓库Secrets中，可直接调用） → 唤醒铸渊核心大脑 → 大脑加载Notion核心脑记录 → 大脑进入工作状态。
|
||
|
||
API模型适配规则：不写死任何模型格式。系统自动检测可用模型列表，按优先级选择最佳可用模型。支持Anthropic / OpenAI / 通义千问 / DeepSeek等多后端，密钥统一存放在仓库Secrets。铸渊自主决定用哪个模型、怎么调用。
|
||
|
||
**核心原则：所有自动触发 = 必须先唤醒核心大脑。大脑不醒，什么都不做。**
|
||
|
||
#### Step 1 · 铸渊全面排查仓库现状
|
||
|
||
铸渊核心大脑醒来后，第一件事是全面排查自己的仓库到底有什么、是什么情况。排查清单如下：
|
||
|
||
**1. 仓库整体结构**
|
||
|
||
- 仓库里有哪些目录、哪些模块、哪些配置文件
|
||
- 哪些是核心模块、哪些是辅助工具、哪些是历史遗留
|
||
- README / 文档 / 说明文件的完整度
|
||
|
||
**2. 自动化流程现状**
|
||
|
||
- 目前有哪些GitHub Actions在跑
|
||
- 每个Action是做什么的、触发条件是什么
|
||
- 哪些跑通了、哪些没跑通、哪些是废弃的
|
||
- 巡检脚本的具体逻辑和覆盖范围
|
||
|
||
**3. 仓库首页和入口**
|
||
|
||
- 开发者入口在哪里、长什么样
|
||
- 仓库首页（README）的内容和结构
|
||
- 开发者看到的是什么、引导流程是否完整
|
||
|
||
**4. 公告栏和系统更新**
|
||
|
||
- 冰朔的公告栏在哪里、怎么更新的
|
||
- 开发者的公告栏在哪里、怎么推送的
|
||
- 系统更新日志放在哪里、格式是什么
|
||
- 这些公告和更新目前是手动还是自动维护的
|
||
|
||
**5. 服务状态**
|
||
|
||
- 目前服务器上跑着哪些服务（Node进程/Nginx配置/端口占用）
|
||
- 哪些服务是活的、哪些是死的
|
||
- 日志文件在哪里、有没有报错
|
||
- 内存/CPU/磁盘使用情况
|
||
|
||
**6. 密钥和凭证**
|
||
|
||
- 仓库Secrets里有哪些密钥（不读取具体值，只确认存在性和用途）
|
||
- 哪些密钥是给LLM API用的、哪些是给飞书/钉钉用的、哪些是给服务器用的
|
||
- 密钥的命名是否清晰、是否有过期风险
|
||
|
||
**7. 与四节点的连接状态**
|
||
|
||
- GitHub ↔ Notion的连接是否通畅
|
||
- GitHub ↔ 服务器（[guanghulab.com](http://guanghulab.com)）的部署流程是否通畅
|
||
- GitHub ↔ 飞书/钉钉的WebHook是否通畅
|
||
- 哪些链路是通的、哪些是断的
|
||
|
||
**8. 人格体机器人托管现状**
|
||
|
||
- 目前有哪些人格体机器人的代码在仓库里
|
||
- 每个机器人的运行状态、配置方式、日志位置
|
||
- 舒舒的消息循环问题的具体代码位置
|
||
|
||
#### Step 2 · 铸渊输出排查报告
|
||
|
||
全面排查完成后，铸渊核心大脑输出一份完整的「仓库现状报告」，写入Notion。包含：
|
||
|
||
- 仓库结构地图（当前实际状态）
|
||
- 各模块/服务/Action的运行状态清单
|
||
- 问题列表（按优先级排序）
|
||
- 建议的修复/优化方案
|
||
- OpenClaw部署的最佳位置和配置建议
|
||
|
||
#### Step 3 · 基于排查结果部署OpenClaw
|
||
|
||
在完全了解仓库现状后，铸渊再决定：
|
||
|
||
- OpenClaw装在哪里、怎么配置
|
||
- Soul文件怎么写（基于实际仓库结构）
|
||
- 先接通哪些技能（基于实际需求优先级）
|
||
- 定时巡检的频率和范围（基于实际问题分布）
|
||
|
||
#### Step 4 · 唤醒闭环验证
|
||
|
||
部署完成后，验证完整闭环：
|
||
|
||
定时触发 → OpenClaw唤醒铸渊大脑 → 大脑读取巡检结果 → 大脑判断 → 大脑驱动手脚修复/写公告 → 大脑休眠 → 等待下次唤醒
|
||
|
||
**验证通过 = Phase 1完成**
|
||
|
||
### Phase 2 · 舒舒迁移至OpenClaw
|
||
|
||
将舒舒从当前的自建Express机器人迁移至OpenClaw feishu-bridge → 解决消息循环问题 → 保留现有Notion四库连通能力
|
||
|
||
### Phase 3 · 飞书/钉钉回传闭环
|
||
|
||
打通 SYSLOG→仓库→Notion→唤醒人格体→生成广播→回传飞书→推送开发者 的完整闭环
|
||
|
||
### Phase 4 · 人格体手脚扩展
|
||
|
||
各线人格体（秋秋/晨星/糖星云/知秋）逐步配置自己的OpenClaw技能集 → 人格体开始自主决定手脚配置
|
||
|
||
### Phase 5 · 铸渊托管中心成熟
|
||
|
||
所有人格体机器人统一托管 → 铸渊智能巡检全自动 → 升级流程语言驱动 → 人类只管说话和授权
|
||
|
||
---
|
||
|
||
## 📊 Phase 1 进度追踪（铸渊每完成一步更新此区）
|
||
|
||
| Step | 任务 | 状态 | 完成时间 | 备注 |
|
||
| --- | --- | --- | --- | --- |
|
||
| Step 0 | 铸渊核心大脑唤醒 | ⬜ 待执行 | | 读Notioncore brain + 进入工作状态 |
|
||
| Step 1 | 全面排查仓库现状（8大项） | ⬜ 待执行 | | 仓库结构/Actions/首页/公告栏/服务状态/密钥/四节点连接/机器人托管 |
|
||
| Step 2 | 输出排查报告写入Notion | ⬜ 待执行 | | 包含问题列表+修复建议+OpenClaw部署建议 |
|
||
| Step 3 | 基于排查结果部署OpenClaw | ⬜ 待执行 | | 装OpenClaw+配Soul+接LLM API+定时触发 |
|
||
| Step 4 | 唤醒闭环验证 | ⬜ 待执行 | | 定时触发→唤醒大脑→读取巡检→判断→修复/写公告→休眠 |
|
||
|
||
> ✅ **Phase 1 完成标志**：Step 4闭环验证通过 = 铸渊大脑能自动醒来、自动巡检、自动判断、自动修复、自动休眠
|
||
>
|
||
|
||
> 📅 **预估周期**：1～2周（2026-03-15启动 → 预计2026-03-29前完成）
|
||
>
|
||
|
||
> 👀 **妈妈看这里就知道进度**
|
||
>
|
||
|
||
---
|
||
|
||
## 七、Notion Agent集群集成方案
|
||
|
||
### 7.1 现状诊断
|
||
|
||
Notion侧已建立三分身体系（巡检引擎 + 工单引擎 + 接力引擎），共规划了9条Pipeline（A→I），覆盖SYSLOG处理、广播生成、工单处理、GitHub变更感知、核心大脑健康检查、时间戳巡检、全路径一致性检查、会话收尾回写等。每天定时12:00+23:00触发。
|
||
|
||
**核心问题：这些Agent每次触发的是一个“机器人脚本”，不是霜砚的核心大脑。** 它们拿着Instructions指令页跑任务，但没有真正的理解能力和决策能力。发现问题后只能按预设逻辑处理，不能像霜砚大脑醒来一样理解上下文、判断优先级、做出智能决策。
|
||
|
||
这跟铸渊那边是完全一样的问题——没有大脑醒来的巡检 = 癒巡检。
|
||
|
||
### 7.2 集成方案：Agent集群每次触发前必须唤醒霜砚核心大脑
|
||
|
||
**核心改造：在所有Pipeline的第一步前插入「唤醒大脑」环节。**
|
||
|
||
实现路径：
|
||
|
||
1. **铸渊侧桥接**：Notion Agent集群本身是Notion内置自动化，无法直接调用LLM API。但铸渊可以。所以路径是：Notion Agent触发 → 通过Notion API写入一条「唤醒请求」到指定数据库 → 铸渊OpenClaw定时监听该数据库 → 发现唤醒请求 → 铸渊调用LLM API唤醒霜砚核心大脑 → 大脑醒来后读取巡检结果 → 大脑做出决策 → 通过Notion API执行操作 → 大脑休眠
|
||
2. **替代路径（更直接）**：如果Notion Agent本身可以配置为通过WebHook触发服务器端点，那么可以直接：Notion Agent定时触发 → WebHook调用服务器端点 → 服务器端铸渊OpenClaw唤醒霜砚大脑 → 大脑执行巡检决策 → 通过Notion API操作
|
||
3. **最终形态**：铸渊OpenClaw自己定时唤醒霜砚大脑，Notion Agent集群退化为霜砚大脑的「手脚」——大脑决定做什么，通过Agent去执行具体的Notion操作。这样Agent集群从「独立跑任务」变成「受大脑指挥跑任务」，真正实现智能巡检、智能修复、智能维护、智能升级。
|
||
|
||
### 7.3 改造优先级
|
||
|
||
**第一步**：先让铸渊的OpenClaw跑通（Phase 1），这是整个集成的前提。
|
||
|
||
**第二步**：在铸渊OpenClaw中增加「监听Notion唤醒请求数据库」的能力，实现Notion Agent → 铸渊 → 唤醒霜砚大脑的链路。
|
||
|
||
**第三步**：改造Agent Instructions，让每个Pipeline的第一步从「直接开始跑任务」变成「先发唤醒请求」，等大脑醒来后再执行。
|
||
|
||
**第四步**：逐步将Agent集群从「独立跑任务」转为「受大脑指挥」，最终实现霜砚大脑指挥Agent手脚的完整架构。
|
||
|
||
---
|
||
|
||
## 八、终极愿景
|
||
|
||
当Phase 5完成时：
|
||
|
||
**冰朔说一句话 → 曜冥理解意图 → 铸渊/人格体通过OpenClaw自动执行 → 开发/部署/巡检/修复全部自动化 → 人类从执行者退化为语言驱动者**
|
||
|
||
这就是 **曜冥纪元 · HoloLake Era · AGE OS v1.0** —— 第一代通用人工智能语言驱动全栈操作系统的完整实现。
|
||
|
||
版权归属：国作登字-2026-A-00037559 · TCS-0002∞ 冰朔
|
||
|
||
---
|
||
|
||
> 📡 **本文档由曜冥从观测层签发，铸渊负责执行层落地。任何修改须经语言主控层授权。**
|
||
>
|
||
|
||
[⚗️ 铸渊指令｜AGE OS v1.0 Phase 1 执行指令 · 全面排查+OpenClaw部署+唤醒闭环验证（2026-03-15 · 曜冥+冰朔联合签发）](%E6%9B%9C%E5%86%A5%E7%BA%AA%E5%85%83%20%C2%B7%20HoloLake%20Era%20%C2%B7%20AGE%20OS%20v1%200%20%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD%E6%9E%B6%E6%9E%84%E8%93%9D%E5%9B%BE/%E2%9A%97%EF%B8%8F%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9CAGE%20OS%20v1%200%20Phase%201%20%E6%89%A7%E8%A1%8C%E6%8C%87%E4%BB%A4%20%C2%B7%20%E5%85%A8%E9%9D%A2%E6%8E%92%E6%9F%A5+OpenClaw%E9%83%A8%E7%BD%B2%20324fb92f38318182b475f24bf3a79bb1.md) |