a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
9.7 KiB
9.7 KiB
🧠 铸渊落地架构 · 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 铸渊的补充优化
- id 用 UUID 而非自增 — 节点可能从Notion/GitHub/手动多源创建，UUID避免冲突
- content_hash 增加 — 检测内容是否变化，避免无意义的COS覆写
- version 增加 — 支持版本追踪，配合归档
- brain_relations 增加 weight — 关系有强弱，"核心引用"权重高于"偶然提及"
- agent_configs 增加 owner — 区分Notion端/GitHub端/system的Agent
- 保留 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工具落地。