192 lines
5.8 KiB
Markdown
192 lines
5.8 KiB
Markdown
# 活数据库架构转变 · 从训练模型到人格体页面 + 商业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模型，而是一个**人格体的操作系统**。
|