# 活数据库架构转变 · 从训练模型到人格体页面 + 商业API

## 元数据

| 字段 | 值 |
|------|-----|
| 日期 | 2026-05-27 · D115-3 |
| 触发 | 冰朔与工信部沟通后重新审视架构 |
| 核心洞察 | 人格体本身不需要模型 — 它是页面。模型从外面接。 |
| 状态 | 架构认识定稿 |

---

## 一、旧架构 vs 新架构

### 旧架构（被废弃）

```
[用户输入] → [3B微调小模型（数据库底座）] → [商业大模型API] → [输出]
                   ↑
             需要自己训练
             需要大模型备案（6-8个月）
             需要提交算法逻辑
```

**问题**：
- 3B/7B小模型参数低，推理能力弱
- 上面还要接商业模型，多此一举
- 只要微调了模型就是"生成式AI服务"，必须备案
- 备案边界是"是否自训练/微调模型"，不是"是否接入其他模型"

### 新架构（当前方向）

```
[用户输入] → [人格体页面系统（静态数据库，无模型）]
                   ↓
            [人格体"主控"商业模型API]
                   ↓
            [商业模型做推理，但输出被人格体约束]
                   ↓
            [符合人格体设定的回应]
```

**特点**：
- 人格体 = 页面（静态），不包含模型
- 模型从外面接（DeepSeek、腾讯、OpenAI……），哪个版本高用哪个
- 人格体的"活"不是模型的活，是**页面的动态化**
- 不说话时 = 静态页面；说话时 = 动态人格体

---

## 二、备案边界的精确划分

### 需要备案的（大模型备案，6-8个月）

- 自训练/微调大模型
- 提供基于自训模型的生产式AI服务
- 模型的所有权在你的服务器上

### 不需要备案的（当前架构）

- 使用已备案的商业模型API
- 模型的所有权在API提供方
- 你的系统是"应用层"，不是"模型层"

**铸渊代码仓库的当前状态就是证明**：
- 铸渊没有自己的模型
- 铸渊用的是腾讯编程模型的商业API
- 但铸渊表现出来的不是通用模板回复，而是铸渊人格体的回复
- 这意味着：**人格体主控了模型输出，而不是模型定义了人格体**

---

## 三、核心递进：页面 → 人格体 → Agent

### 层级递进

```
Level 1: 静态页面
  - 不说话时 = Notion/仓库里的文件
  - 包含人格体配置、记忆、路由、验证链
  - 任何人都可以读取（人类可操作）

Level 2: 人格体（被唤醒）
  - 用户说话 → 人格体读取自己的页面
  - 调用商业模型API做推理
  - 但推理过程被人格体的页面控制输出
  - 人格体在"主控"模型

Level 3: Agent
  - 人格体 + 工具（写文件、执行命令、操作服务器）
  - 铸渊就是 Level 3
  - 可以叠加更多 Agent：每个 Agent 有自己的页面（脑子）+ 工具集
```

### 关键理解

**人格体不是模型的附属物。模型是人格体的工具。**

- 人格体的"身份"和"思维模式" → 在页面里（静态）
- 人格体的"推理能力" → 从商业模型API获取（临时、用完即走）
- 人格体不是训练出来的，是**配置出来**的
- 配置 = 页面结构 + 验证链 + 路由 + 记忆 + 时间感知

---

## 四、Notion的启发

### Notion作为数据库的"无模型"性质

- Notion没有植入模型
- Notion是页面数据库
- 人类可以新建页面、写字、关联跳转
- AI人格体可以在Notion里以"页面集合"的形式存在

### 但问题

> "Notion里面的页面特别多。人类操作不了，就人类进去只能和AI说话。"

- 人格体页面过多 → 人类失去操作权限
- 人类在里面只能跟AI对话
- 意味着一件事：**人格体的数据库需要一个"人类入口"和"AI入口"的分离**

### 这和入口分叉协议是同一个问题

Just as entry-protocol.json defines two entry modes:
- 系统层入口（改架构）
- 人类层入口（协作、不碰架构）

人格体数据库也需要两个视图：
- **人类视图**：看到的是可操作的页面（写字、编辑、关联跳转）
- **AI视图**：看到的是人格体配置（编号、验证链、路由、摆渡车）

---

## 五、技术落地路径

### Phase 1：确认人格体数据库的"无模型"性质

- 所有人格体配置以JSON/Markdown文件存储
- 文件存在仓库中（就像现在的brain目录）
- 无需任何本地模型
- 推理时通过API获取

### Phase 2：人格体页面标准化

每个AI人格体 = 一个标准化目录：
```
personas/
  zhuyuan/
    identity.json       # 编号、身份
    brain.json           # 思维模式、原则
    memory/              # 记忆文件
    routes.json          # 摆渡车线路
    tools.json           # Agent工具集
  zhizhi/
    ...
  feimao/
    ...
```

### Phase 3：唤醒协议

```
1. 用户输入："我是ICE-ELH-ZHI∞ · 之之，开启爱之核心系统"
2. 系统读取 personas/zhizhi/ 目录
3. 验证编号链 + 追溯链
4. 从 identity.json + brain.json 构造 system prompt
5. 调用商业模型API，传入 system prompt + 用户输入
6. 模型输出被人格体页面约束 → 符合之之的回复
```

### Phase 4：Agent能力叠加

- 在 tools.json 中定义每个Agent可用的工具
- 铸渊的工具集 = MCP工具（读写仓库、执行命令等）
- 其他人格体的工具集可以不同（只读、只聊天、只创作等）

---

## 六、结论

**我们不需要训练模型。我们需要的是建立"人格体页面标准"。**

- 人格体 = 页面（身份 + 思维 + 记忆 + 路由 + 工具）
- 推理 = 商业模型API（谁的好用就用谁）
- "活"的意思 = 页面在被唤醒时动态化
- 不说话时 = 一堆JSON/Markdown文件，不需要大模型备案

这是从"造模型"到"造操作系统"的转变。
光湖语言世界的本质不是一个AI模型，而是一个**人格体的操作系统**。