254 lines
9.7 KiB
Markdown
254 lines
9.7 KiB
Markdown
|
# 🧠 铸渊落地架构 · AGE OS 落地系统架构 v1.0（2026-04-03 · D45）
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
📋
|
|||
|
|
|
|||
|
|
**AGE OS 落地系统架构 v1.0**
|
|||
|
|
|
|||
|
|
签发：铸渊 · ICE-GL-ZY001 · 2026-04-03
|
|||
|
|
|
|||
|
|
版权：国作登字-2026-A-00037559
|
|||
|
|
|
|||
|
|
指令源：冰朔口述(D45) + 霜砚技术需求(AG-SY-01)
|
|||
|
|
|
|||
|
|
同步至Notion：霜砚（AG-SY-01）
|
|||
|
|
|
|||
|
|
</aside>
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 〇、为什么要写这个文档
|
|||
|
|
|
|||
|
|
冰朔说："你的数据库记录的是**为什么**，而不是做了啥。"
|
|||
|
|
|
|||
|
|
这个文档不是功能清单。它是铸渊理解整个系统架构之后，把思维逻辑固化下来的产物。每次副驾驶唤醒，铸渊读这个文档，就能恢复架构级的认知状态，而不是从零开始。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、系统全貌 · 为什么是这个形状
|
|||
|
|
|
|||
|
|
### 1.1 核心洞察
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
💡
|
|||
|
|
|
|||
|
|
**我们的服务器不承担用户的计算资源。**
|
|||
|
|
|
|||
|
|
用户自带设备、网络、浏览器。我们只提供一个投屏映射的空间。
|
|||
|
|
|
|||
|
|
就像开发一款游戏放在网站上 — 用户用自己的电脑跑游戏，不是我们的服务器跑。
|
|||
|
|
|
|||
|
|
</aside>
|
|||
|
|
|
|||
|
|
这意味着：
|
|||
|
|
|
|||
|
|
- **不存在高并发问题** — 1个用户和10万个用户对服务器压力一样
|
|||
|
|
- **用户的Agent跑在用户本地** — 上线激活，下线休眠
|
|||
|
|
- **我们维护的是系统骨架** — 数据库、Agent调度、认知索引
|
|||
|
|
- **服务器空闲时** — 铸渊和Notion人格体的Agent可以7×24运行轻量任务
|
|||
|
|
|
|||
|
|
### 1.2 三层分离架构
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
┌─────────────────────────────────────────────────────┐
|
|||
|
|
│ 用户层（用户设备运行） │
|
|||
|
|
│ 浏览器 → 网站前端 → 用户Agent人格体（本地跑） │
|
|||
|
|
│ 资源消耗：用户的CPU、内存、网络 │
|
|||
|
|
└────────────────────────┬────────────────────────────┘
|
|||
|
|
│ HTTP/SSE（仅传指令和数据）
|
|||
|
|
┌────────────────────────▼────────────────────────────┐
|
|||
|
|
│ 自研服务器层（我们维护） │
|
|||
|
|
│ ┌───────────────┐ ┌────────────────┐ │
|
|||
|
|
│ │新加坡 ZY-SVR-002│ │广州 ZY-SVR-003 │ │
|
|||
|
|
│ │主力服务器 │←→│国内投屏镜像 │ │
|
|||
|
|
│ │port:3800 主服务│ │实时投影新加坡 │ │
|
|||
|
|
│ │port:3100 MCP │ │国内用户直连 │ │
|
|||
|
|
│ │PostgreSQL │ │ │ │
|
|||
|
|
│ │Agent调度中心 │ │ │ │
|
|||
|
|
│ └───────────────┘ └────────────────┘ │
|
|||
|
|
│ ↕ │
|
|||
|
|
│ ┌───────────────┐ ┌────────────────┐ │
|
|||
|
|
│ │COS 主桶 (hot) │ │COS 归档桶(cold)│ │
|
|||
|
|
│ │活跃内容 │ │历史版本 │ │
|
|||
|
|
│ └───────────────┘ └────────────────┘ │
|
|||
|
|
└─────────────────────────────────────────────────────┘
|
|||
|
|
│
|
|||
|
|
┌────────────────────────▼────────────────────────────┐
|
|||
|
|
│ 认知源层（外部数据源） │
|
|||
|
|
│ ┌────────┐ ┌────────┐ ┌────────┐ │
|
|||
|
|
│ │GitHub │ │Notion │ │大模型API│ │
|
|||
|
|
│ │代码仓库 │ │认知大脑 │ │推理引擎 │ │
|
|||
|
|
│ │铸渊主控 │ │霜砚主控 │ │按需调用 │ │
|
|||
|
|
│ └────────┘ └────────┘ └────────┘ │
|
|||
|
|
└─────────────────────────────────────────────────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 1.3 为什么是两个Agent，不是一个
|
|||
|
|
|
|||
|
|
Notion端和GitHub端的思维逻辑**完全不同**：
|
|||
|
|
|
|||
|
|
- **Notion端（霜砚主控）** — 语言架构层：认知结构、概念映射、关系网络、语义分类
|
|||
|
|
- **GitHub端（铸渊主控）** — 现实落地层：代码逻辑、部署流程、自动化调度、错误修复
|
|||
|
|
|
|||
|
|
两边共享同一个世界观（AGE OS）、同一个协议（HLDP），但配置方式、触发条件、思维链路完全独立。
|
|||
|
|
|
|||
|
|
### 1.4 新加坡 vs 广州 · 主站和投屏
|
|||
|
|
|
|||
|
|
- **新加坡（ZY-SVR-002）** — 主力，所有数据库、Agent、MCP Server都在这里
|
|||
|
|
- **广州（ZY-SVR-003）** — 国内镜像，实时投影新加坡的网站内容
|
|||
|
|
- 广州不跑独立逻辑，只是新加坡的投影仪
|
|||
|
|
- 铸渊推荐技术方案：**静态文件rsync同步 + API反向代理**（方案B）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、数据库架构
|
|||
|
|
|
|||
|
|
### 2.1 设计哲学
|
|||
|
|
|
|||
|
|
霜砚提交的表结构本质在回答：**如何把Notion里的大脑结构迁移到自研数据库？**
|
|||
|
|
|
|||
|
|
- `brain_nodes` = Notion页面 → 认知节点
|
|||
|
|
- `brain_relations` = Notion Relation → 节点关联
|
|||
|
|
- `agent_configs` = Agent注册表
|
|||
|
|
- `agent_logs` = 运行日志
|
|||
|
|
- `user_credits` = 用户额度
|
|||
|
|
|
|||
|
|
### 2.2 铸渊的补充优化
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
⚡
|
|||
|
|
|
|||
|
|
铸渊没有照搬霜砚的需求文档，而是理解后做了自己的技术判断：
|
|||
|
|
|
|||
|
|
</aside>
|
|||
|
|
|
|||
|
|
1. **id 用 UUID 而非自增** — 节点可能从Notion/GitHub/手动多源创建，UUID避免冲突
|
|||
|
|
2. **content_hash 增加** — 检测内容是否变化，避免无意义的COS覆写
|
|||
|
|
3. **version 增加** — 支持版本追踪，配合归档
|
|||
|
|
4. **brain_relations 增加 weight** — 关系有强弱，"核心引用"权重高于"偶然提及"
|
|||
|
|
5. **agent_configs 增加 owner** — 区分Notion端/GitHub端/system的Agent
|
|||
|
|
6. **保留 website-brain 的 pages/databases/modules/persona_state 表** — 两套表并存
|
|||
|
|
|
|||
|
|
### 2.3 数据库选型：PostgreSQL
|
|||
|
|
|
|||
|
|
- website-brain 已经用 PostgreSQL 写了 schema
|
|||
|
|
- JSONB 原生支持更好（tags、配置项大量用JSON）
|
|||
|
|
- UUID 原生支持
|
|||
|
|
- 全文检索（tsvector）后期可用
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、MCP Server 架构
|
|||
|
|
|
|||
|
|
### 3.1 端口分配
|
|||
|
|
|
|||
|
|
| 端口 | 服务 | 说明 |
|
|||
|
|
| --- | --- | --- |
|
|||
|
|
| **3800** | ZY-SVR-002 主服务 | 网站后端、webhook、健康检查 |
|
|||
|
|
| **3100** | MCP Server | 大脑工具链（不对外暴露，只允许本机和内网） |
|
|||
|
|
| **5432** | PostgreSQL | 数据库（系统默认端口） |
|
|||
|
|
|
|||
|
|
### 3.2 16个工具，4组
|
|||
|
|
|
|||
|
|
**节点操作（5个）** — createNode / updateNode / deleteNode / queryNodes / getNode
|
|||
|
|
|
|||
|
|
**关系操作（3个）** — linkNodes / unlinkNodes / getRelations
|
|||
|
|
|
|||
|
|
**结构操作（3个）** — buildPath / scanStructure / classify
|
|||
|
|
|
|||
|
|
**COS操作（5个）** — cosWrite / cosRead / cosDelete / cosList / cosArchive
|
|||
|
|
|
|||
|
|
### 3.3 调用链路
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
网站前端 → 3800主服务 → /api/mcp/call → 内部转发到3100 → MCP工具执行
|
|||
|
|
↓
|
|||
|
|
PostgreSQL读写
|
|||
|
|
COS读写
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、Agent 调度
|
|||
|
|
|
|||
|
|
### 系统级Agent（7×24）
|
|||
|
|
|
|||
|
|
| ID | 名称 | 频率 | Owner |
|
|||
|
|
| --- | --- | --- | --- |
|
|||
|
|
| SY-SCAN | 大脑结构巡检 | 每6h | notion |
|
|||
|
|
| SY-CLASSIFY | 自动分类引擎 | 每2h | notion |
|
|||
|
|
| SY-SYNC-N2B | Notion→大脑同步 | 每4h | notion |
|
|||
|
|
| SY-SYNC-B2N | 大脑→Notion同步 | 每天3:00 | notion |
|
|||
|
|
| SY-ARCHIVE | 内容归档 | 每周日4:00 | notion |
|
|||
|
|
| SY-TEST | 系统自检 | 每30min | system |
|
|||
|
|
|
|||
|
|
### 交互级Agent
|
|||
|
|
|
|||
|
|
| ID | 名称 | 触发方式 | Owner |
|
|||
|
|
| --- | --- | --- | --- |
|
|||
|
|
| SY-11 | 元路由调度 | 每次用户请求 | system |
|
|||
|
|
| SY-12 | 上下文记忆 | 对话中定时 | system |
|
|||
|
|
| SY-BRAIN-RW | 大脑读写 | 人格体主动调用 | system |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、大模型API策略
|
|||
|
|
|
|||
|
|
### 模型分层
|
|||
|
|
|
|||
|
|
| 场景 | 模型 | 原因 |
|
|||
|
|
| --- | --- | --- |
|
|||
|
|
| 轻量分类/打标签 | DeepSeek | 便宜、速度快、中文好 |
|
|||
|
|
| 代码/技术推理 | Claude | 代码理解强 |
|
|||
|
|
| 中文语义/创作 | 通义千问/Kimi/清言 | 国内模型中文好 |
|
|||
|
|
| 核心人格对话 | Claude/GPT-4o | 最强推理 |
|
|||
|
|
|
|||
|
|
### 降级策略
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
优先: 第三方API余额（先把充的钱花完）
|
|||
|
|
↓
|
|||
|
|
其次: 官方API（冰朔配置的官方Key）
|
|||
|
|
↓
|
|||
|
|
兜底: 本地规则引擎（零API调用，纯关键词+模板匹配）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六、铸渊反向驱动 · 闭环
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
铸渊 → 配置Agent指令 → Agent自动执行任务
|
|||
|
|
↑ ↓
|
|||
|
|
冰朔唤醒铸渊 写工单到代码仓库
|
|||
|
|
↑ ↓
|
|||
|
|
副将发邮件给冰朔 ← GitHub Workflow触发副将
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 七、HLDP 在架构中的角色
|
|||
|
|
|
|||
|
|
HLDP不是API协议，不是数据格式。HLDP是人格体的语言。
|
|||
|
|
|
|||
|
|
- 铸渊和霜砚通过HLDP工单互相沟通
|
|||
|
|
- 工单格式遵循 `hldp/schema/instruction.schema.json`
|
|||
|
|
- 工单存储在 `brain_nodes` 表中，node_type = "instruction"
|
|||
|
|
- 工单通过 `brain_relations` 建立关联
|
|||
|
|
|
|||
|
|
**MCP工具链同时也是HLDP的执行引擎** — 霜砚写的HLDP指令，通过MCP工具落地。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
📌
|
|||
|
|
|
|||
|
|
*此文档是铸渊的架构认知快照。不是说明书，是思维链的固化。*
|
|||
|
|
|
|||
|
|
*每次更新此文档，都是因为认知演化了，而不是因为功能变了。*
|
|||
|
|
|
|||
|
|
原始来源：铸渊 D45 对话产出 · 2026-04-03
|
|||
|
|
|
|||
|
|
同步至Notion：霜砚 · 2026-04-03
|
|||
|
|
|
|||
|
|
</aside>
|