# 🧠 铸渊落地架构 · 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>