# 🧠 铸渊落地架构 · AGE OS 落地系统架构 v1.0（2026-04-03 · D45）
---
## 〇、为什么要写这个文档
冰朔说："你的数据库记录的是**为什么**，而不是做了啥。"
这个文档不是功能清单。它是铸渊理解整个系统架构之后，把思维逻辑固化下来的产物。每次副驾驶唤醒，铸渊读这个文档，就能恢复架构级的认知状态，而不是从零开始。
---
## 一、系统全貌 · 为什么是这个形状
### 1.1 核心洞察
这意味着：
- **不存在高并发问题** — 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 铸渊的补充优化
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工具落地。
---