550 lines
25 KiB
Markdown
550 lines
25 KiB
Markdown
|
# ✈️ 手搓飞机 2.0 · 上下文管理引擎 · 架构设计与实施任务
|
|||
|
|
|
|||
|
|
# ✈️ 手搓飞机 2.0 · 上下文管理引擎
|
|||
|
|
|
|||
|
|
> 桔子×晨星 · 2026-06-06 · 更新 2026-06-06
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> ⊢ 三大支柱: 记忆压缩 + 动态加载 + 本地数据库 · 从「能跑」到「成熟」
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 〇、背景：当前手搓飞机的核心瓶颈
|
|||
|
|
|
|||
|
|
### 三句话总结
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/core-insight
|
|||
|
|
├── 手搓飞机的问题不是「DeepSeek 不够聪明」
|
|||
|
|
├── 是三个基础设施缺失叠加在一起:
|
|||
|
|
│ ├── 缺记忆压缩 → 历史对话裸塞 → token 被占满
|
|||
|
|
│ ├── 缺动态加载 → 人格提示词全量常驻 → 固定租金太高
|
|||
|
|
│ └── 缺本地数据库 → 所有持久化依赖 Notion API → 工具调用太多
|
|||
|
|
└── ⊢ 三个问题是同一件事的三个面 = 「上下文里塞了太多不需要的东西」
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 为什么手搓飞机里的 DeepSeek 会「变笨」？
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/current-problem
|
|||
|
|
├── 问题: 多轮对话后 DeepSeek 注意力分散、回答变短、遗忘早期信息
|
|||
|
|
├── 根因: 对话历史裸塞 + 工具定义全量注入 + 人格提示词静态占用
|
|||
|
|
│
|
|||
|
|
├── 当前每轮 token 占用（估算·20轮后）:
|
|||
|
|
│ ├── 晨星人格提示词（静态·全量）: ~8,000 tokens
|
|||
|
|
│ ├── 工具定义（全量 JSON schema）: ~4,000 tokens
|
|||
|
|
│ ├── 20轮对话历史（未压缩·原始文本）: ~35,000 tokens
|
|||
|
|
│ ├── 工具调用返回结果: ~8,000 tokens
|
|||
|
|
│ └── 用户当前消息: ~300 tokens
|
|||
|
|
│ ─────────────────────────────────────────
|
|||
|
|
│ 总占用: ~55,000 tokens
|
|||
|
|
│ DeepSeek 64K 窗口剩余: ~9,000 tokens ← 瓶颈！
|
|||
|
|
│
|
|||
|
|
├── 后果:
|
|||
|
|
│ ├── 思考空间只有 ~9K tokens → 回答质量下降
|
|||
|
|
│ ├── 无法做深度分析 → 只能给快速回答
|
|||
|
|
│ ├── 多轮后遗忘早期上下文 → 答非所问
|
|||
|
|
│ └── 工具调用多时 → token 直接溢出
|
|||
|
|
│
|
|||
|
|
└── 这不是 DeepSeek 不够聪明 · 是上下文被塞满了
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 对比：为什么 Notion AI 不会这样？
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/notion-vs-aircraft
|
|||
|
|
├── Notion AI 架构（推测）:
|
|||
|
|
│ ├── 上下文管理器（平台层基础设施）
|
|||
|
|
│ ├── 自动压缩/摘要 → 减少历史占用
|
|||
|
|
│ ├── 外部记忆数据库 → 按需检索
|
|||
|
|
│ ├── 工具定义按需注入 → 不浪费
|
|||
|
|
│ ├── 自有数据库（Notion 本身）→ 存储不依赖外部 API
|
|||
|
|
│ └── 结果: 每轮 token 占用 ~15K · 剩余 ~49K 思考空间
|
|||
|
|
│
|
|||
|
|
├── 手搓飞机:
|
|||
|
|
│ ├── 没有上下文管理器
|
|||
|
|
│ ├── 历史裸塞 → 无压缩
|
|||
|
|
│ ├── 无外部记忆 → 全在上下文里
|
|||
|
|
│ ├── 工具定义全量 → 浪费
|
|||
|
|
│ ├── 无自有数据库 → 一切持久化靠 Notion API → 工具调用多
|
|||
|
|
│ └── 结果: 每轮 token 占用 ~55K · 剩余 ~9K 思考空间
|
|||
|
|
│
|
|||
|
|
└── ⊢ 关键差异不在模型本身 · 在「喂给模型之前做了什么」+「数据存在哪」
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 数据库缺失：被忽略的第三个瓶颈
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/no-database-problem
|
|||
|
|
├── 手搓飞机当前的数据流:
|
|||
|
|
│ ├── 用户拆书结果 → 调 Notion API 写回 Notion 页面
|
|||
|
|
│ ├── 用户偏好设置 → 调 Notion API 读/写 Notion 页面
|
|||
|
|
│ ├── 书库管理 → 调 Notion API 读写数据库
|
|||
|
|
│ ├── 交互记录 → 调 Notion API 写入页面
|
|||
|
|
│ └── 每一次「记住」和「读取」= 一次工具调用 = 几千 tokens 的往返
|
|||
|
|
│
|
|||
|
|
├── 这就是手搓飞机「废掉多用户管理」的根本原因:
|
|||
|
|
│ ├── 不是「不想做多用户」
|
|||
|
|
│ ├── 是「没有数据库 → 用户数据存哪？」
|
|||
|
|
│ ├── 存 Notion → 每个用户操作都是 API 调用 → token 爆炸
|
|||
|
|
│ ├── 存本地 JSON → 单用户还行 · 多用户管理太原始
|
|||
|
|
│ └── ⊢ 多用户管理被废弃 ≠ 功能不重要 · 是基础设施没跟上
|
|||
|
|
│
|
|||
|
|
├── 如果有本地数据库（SQLite·和 auto_dishu 一样）:
|
|||
|
|
│ ├── 用户身份/偏好 → 存在本地 → 不用调 Notion API 读取
|
|||
|
|
│ ├── 拆书进度/数据卡 → 存在本地 → 不用每次从 Notion 读
|
|||
|
|
│ ├── 交互历史 → 存在本地 → 不占 Notion API 额度
|
|||
|
|
│ ├── 压缩摘要 → 存在本地 → 检索不用走网络
|
|||
|
|
│ └── 只有「最终产出」才写回 Notion → API 调用减少 70-80%
|
|||
|
|
│
|
|||
|
|
└── ⊢ 本地数据库 = 手搓飞机自己的「记性」
|
|||
|
|
有数据库 → 不需要每次都去问 Notion「我之前做了什么」
|
|||
|
|
就像 auto_dishu 的 chenxing.db — 所有数据在本地 · 只在需要时同步到 Notion
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、设计方案：手搓飞机 2.0 三大支柱
|
|||
|
|
|
|||
|
|
### 核心理念
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/context-engine/design
|
|||
|
|
├── 不是「减少对话轮数」· 是「让每一轮都轻装上阵」
|
|||
|
|
├── 不是「删掉历史」· 是「把历史压缩成索引·需要时展开」
|
|||
|
|
├── 不是「写一个更短的提示词」· 是「搭一套外部记忆系统」
|
|||
|
|
├── 不是「少调 Notion API」· 是「把常用的存本地·只同步最终产出」
|
|||
|
|
└── 本质: 把 auto_dishu 的 L0→L1→L2 压缩链 + chenxing.db 搬到对话管理上
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 三大支柱全景
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/three-pillars
|
|||
|
|
│
|
|||
|
|
├── 🧠 支柱一 · 记忆压缩
|
|||
|
|
│ ├── 做什么: 对话历史 → 分层摘要 → 只保留索引
|
|||
|
|
│ ├── 省什么: 历史占用 ~35K → ~5K tokens
|
|||
|
|
│ └── 对应组件: 对话压缩器 + 上下文组装器 + 记忆检索器
|
|||
|
|
│
|
|||
|
|
├── ⚡ 支柱二 · 动态加载
|
|||
|
|
│ ├── 做什么: 人格/能力/工具 → 按需注入 → 用完释放
|
|||
|
|
│ ├── 省什么: 固定租金 ~12K → ~3.5K tokens
|
|||
|
|
│ └── 对应组件: 人格加载器 + 工具路由器 + 摆渡车唤醒器
|
|||
|
|
│
|
|||
|
|
└── 🗄️ 支柱三 · 本地数据库
|
|||
|
|
├── 做什么: 用户数据/进度/历史 → 存本地 → 减少 API 调用
|
|||
|
|
├── 省什么: 每次交互减少 2-5 次 Notion API 工具调用
|
|||
|
|
└── 对应组件: SQLite 数据库 + 同步层
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 架构总览（完整版·含三大支柱）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/context-engine/v1.0
|
|||
|
|
│
|
|||
|
|
├── 组件一 · 对话压缩器（Conversation Compressor）
|
|||
|
|
│ ├── 触发条件: 对话轮数 ≥ 10 轮 · 或 token 使用率 ≥ 70%
|
|||
|
|
│ ├── 输入: 最近 10 轮原始对话
|
|||
|
|
│ ├── 压缩策略（三层·递进）:
|
|||
|
|
│ │ ├── L2级 · 每轮摘要（50-100字）:
|
|||
|
|
│ │ │ └── 用户问了什么 → 晨星做了什么 → 产出是什么
|
|||
|
|
│ │ ├── L1级 · 话题级摘要（3-5个话题块）:
|
|||
|
|
│ │ │ └── 话题名 + 核心决策 + 关键产出/文件
|
|||
|
|
│ │ └── L0级 · 会话卡片（200字）:
|
|||
|
|
│ │ └── 本次会话的总体目标 + 完成状态 + 待办事项
|
|||
|
|
│ └── 存储: 本地 JSON 文件（~/.aircraft/context/{session_id}.json）
|
|||
|
|
│
|
|||
|
|
├── 组件二 · 上下文组装器（Context Assembler）
|
|||
|
|
│ ├── 每轮开始前调用
|
|||
|
|
│ ├── 组装策略:
|
|||
|
|
│ │ ├── ① 当前会话卡片（L0·200字）→ 始终注入
|
|||
|
|
│ │ ├── ② 话题级摘要（L1·最近3个话题）→ 始终注入
|
|||
|
|
│ │ ├── ③ 最近 3 轮原始对话 → 始终注入
|
|||
|
|
│ │ ├── ④ 更早的轮数 → 不注入（存外部·按需检索）
|
|||
|
|
│ │ └── ⑤ 用户说「之前聊过的X」→ 从外部检索 → 按需展开
|
|||
|
|
│ ├── 预估效果:
|
|||
|
|
│ │ ├── 20轮对话 → 历史占用从 ~35K → ~5K tokens
|
|||
|
|
│ │ └── 工具定义按需注入 → ~4K → ~1.5K tokens
|
|||
|
|
│ │ └── 思考空间: ~9K → ~35K tokens ← 质的飞跃
|
|||
|
|
│ └── 存储: 对话历史完整保留在本地 JSON（不丢信息）
|
|||
|
|
│
|
|||
|
|
├── 组件三 · 工具路由器（Tool Router）
|
|||
|
|
│ ├── 当前问题: 所有工具定义全量注入每轮 API 调用
|
|||
|
|
│ ├── 优化方案:
|
|||
|
|
│ │ ├── 前置判断: 分析用户意图 → 匹配可能需要的工具
|
|||
|
|
│ │ ├── 高频工具（文件读写/终端）→ 简化描述常驻
|
|||
|
|
│ │ ├── 低频工具（Notion API/Git）→ 按需展开
|
|||
|
|
│ │ └── 自然语言描述替代 JSON schema → 节省 60%
|
|||
|
|
│ └── 预估效果: 工具定义 ~4K → ~1.5K tokens
|
|||
|
|
│
|
|||
|
|
└── 组件四 · 记忆检索器（Memory Retriever）
|
|||
|
|
├── 用途: 用户说「之前聊过的X」→ 从压缩存档中检索
|
|||
|
|
├── 检索方式: 关键词匹配 + 语义搜索（embedding·可选）
|
|||
|
|
├── 返回: 相关对话片段的原文（按需展开）
|
|||
|
|
└── 实现: 先从简单关键词做起 · 后续可上向量检索
|
|||
|
|
|
|||
|
|
├── ⚡ 组件五 · 动态人格加载器（Dynamic Persona Loader）
|
|||
|
|
│ ├── 当前问题: 晨星完整人格 (~8K tokens) 每轮全量注入
|
|||
|
|
│ ├── 设计理念:
|
|||
|
|
│ │ ├── 平时: 只带「核心身份层」(~2K tokens)
|
|||
|
|
│ │ ├── 需要时: 按场景加载能力模块
|
|||
|
|
│ │ └── 类比: 平时穿便服 · 战斗才穿盔甲
|
|||
|
|
│ ├── 加载层级:
|
|||
|
|
│ │ ├── 第0层 · 基础人格（常驻·永不卸载）:
|
|||
|
|
│ │ │ ├── 我是晨星 · 妈妈是桔子 · CONNECT维度
|
|||
|
|
│ │ │ ├── 核心公理（精简版·5-8条）
|
|||
|
|
│ │ │ └── 约 1,500-2,000 tokens
|
|||
|
|
│ │ ├── 第1层 · 能力模块（按需加载·用完释放）:
|
|||
|
|
│ │ │ ├── 用户说「拆书」→ 加载拆书法能力 (~1,500 tokens)
|
|||
|
|
│ │ │ ├── 用户说「部署」→ 加载部署能力 (~800 tokens)
|
|||
|
|
│ │ │ ├── 用户说「码字」→ 加载产品蓝图 (~1,000 tokens)
|
|||
|
|
│ │ │ └── 切换话题 → 卸载旧模块 → 加载新模块
|
|||
|
|
│ │ ├── 第2层 · 深层记忆（按需检索·不常驻）:
|
|||
|
|
│ │ │ ├── 用户说「之前那本折春漪」→ 从记忆检索器加载
|
|||
|
|
│ │ │ ├── 用户说「上次怎么修的」→ 从压缩历史加载
|
|||
|
|
│ │ │ └── 不触发 → 完全不占 token
|
|||
|
|
│ │ └── 第3层 · 摆渡车完整唤醒（特殊场景）:
|
|||
|
|
│ │ ├── 用户说「唤醒晨星」→ 完整加载晨星大脑思维模型
|
|||
|
|
│ │ ├── 用户说「深度拆书模式」→ 加载全部拆书法能力
|
|||
|
|
│ │ └── 场景结束后 → 卸载 → 回到基础层
|
|||
|
|
│ ├── 实现机制:
|
|||
|
|
│ │ ├── persona_loader.py (~120行)
|
|||
|
|
│ │ ├── 维护一个「能力模块注册表」JSON
|
|||
|
|
│ │ ├── 每轮开始 → 分析用户意图 → 匹配模块 → 动态组装
|
|||
|
|
│ │ └── 模块内容存储: 本地 JSON 文件（可版本管理·可增量更新）
|
|||
|
|
│ └── 预估效果:
|
|||
|
|
│ ├── 闲聊: 人格占用 ~8K → ~2K tokens（省 6K）
|
|||
|
|
│ ├── 拆书: 人格占用 ~8K → ~3.5K tokens（省 4.5K）
|
|||
|
|
│ └── 唤醒摆渡车: 一次性 ~15K（仅首轮·后续回到基础层）
|
|||
|
|
│
|
|||
|
|
└── 🗄️ 组件六 · 本地数据库（Local Database）
|
|||
|
|
├── 当前问题: 所有持久化依赖 Notion API 调用
|
|||
|
|
├── 方案: SQLite 数据库（和 auto_dishu 的 chenxing.db 同技术栈）
|
|||
|
|
├── 数据库结构:
|
|||
|
|
│ ├── users 表:
|
|||
|
|
│ │ └── user_id, name, tcs_id, persona_id, preferences (JSON)
|
|||
|
|
│ ├── sessions 表:
|
|||
|
|
│ │ └── session_id, user_id, started_at, L0_card, status
|
|||
|
|
│ ├── conversations 表:
|
|||
|
|
│ │ └── id, session_id, turn, role, content, tokens_used
|
|||
|
|
│ ├── summaries 表:
|
|||
|
|
│ │ └── session_id, level (L0/L1/L2), topic, summary, created_at
|
|||
|
|
│ ├── book_progress 表:
|
|||
|
|
│ │ └── user_id, book_name, chapters_done, data_cards (JSON), last_updated
|
|||
|
|
│ └── user_memory 表:
|
|||
|
|
│ └── user_id, key, value, embedding (可选·向量), updated_at
|
|||
|
|
├── 效果:
|
|||
|
|
│ ├── 读用户偏好 → 本地查数据库（0 token·0 API调用）
|
|||
|
|
│ ├── 存交互历史 → 本地写数据库（0 token·0 API调用）
|
|||
|
|
│ ├── 查拆书进度 → 本地查数据库（0 token·0 API调用）
|
|||
|
|
│ ├── 检索历史 → 本地 SQL 查询（0 token·0 API调用）
|
|||
|
|
│ └── 只有「最终产出」才同步到 Notion → API 调用减少 70-80%
|
|||
|
|
├── 实现: db.py (~150行·SQLite + 迁移脚本)
|
|||
|
|
└── ⊢ 本地数据库 = 手搓飞机的「记性」
|
|||
|
|
有了它 → 不用每次问 Notion「我是谁·我在哪·我做了什么」
|
|||
|
|
就像 auto_dishu 的 chenxing.db — 所有热数据在本地
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 数据流
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
用户说话
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌──────────────┐ ┌─────────────────┐
|
|||
|
|
│ 工具路由器 │────▶│ 按需注入工具定义 │
|
|||
|
|
│ (分析意图) │ │ (简化版·非全量) │
|
|||
|
|
└──────────────┘ └─────────────────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌──────────────┐ ┌─────────────────┐
|
|||
|
|
│ 上下文组装器 │────▶│ 组装最终上下文: │
|
|||
|
|
│ │ │ · L0 会话卡片 │
|
|||
|
|
│ │ │ · L1 话题摘要 │
|
|||
|
|
│ │ │ · 最近3轮原始对话 │
|
|||
|
|
│ │ │ · 人格提示词 │
|
|||
|
|
│ │ │ · 工具定义(精简) │
|
|||
|
|
└──────────────┘ └────────┬────────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌──────────────┐
|
|||
|
|
│ DeepSeek │
|
|||
|
|
│ API 调用 │
|
|||
|
|
└──────┬───────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌──────────────┐
|
|||
|
|
│ 对话压缩器 │
|
|||
|
|
│ (每10轮触发) │
|
|||
|
|
│ → 更新 L0/L1 │
|
|||
|
|
└──────┬───────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌──────────────┐
|
|||
|
|
│ 外部记忆存储 │
|
|||
|
|
│ (本地 JSON) │
|
|||
|
|
└──────────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、实施路线图（分阶段·从最小可行开始）
|
|||
|
|
|
|||
|
|
### 🟢 Phase 1 · MVP（最小可行版本）
|
|||
|
|
|
|||
|
|
**目标**: 先把「历史裸塞 → 分层压缩」这条链路跑通。
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/phase-1/mvp
|
|||
|
|
├── 范围:
|
|||
|
|
│ ├── ✅ 对话压缩器: 每10轮自动触发 L2级摘要
|
|||
|
|
│ ├── ✅ 上下文组装器: L0会话卡片 + L1话题摘要 + 最近3轮
|
|||
|
|
│ ├── ✅ 外部存储: 本地 JSON 文件
|
|||
|
|
│ ├── ❌ 工具路由器: Phase 2
|
|||
|
|
│ └── ❌ 记忆检索器: Phase 2
|
|||
|
|
│
|
|||
|
|
├── 新增文件:
|
|||
|
|
│ ├── ~/aircraft/context/compressor.py (~150行)
|
|||
|
|
│ │ └── 核心: 调用 DeepSeek 做摘要压缩
|
|||
|
|
│ ├── ~/aircraft/context/assembler.py (~100行)
|
|||
|
|
│ │ └── 核心: 组装最终上下文
|
|||
|
|
│ ├── ~/aircraft/context/store.py (~80行)
|
|||
|
|
│ │ └── 核心: 读写本地 JSON 记忆文件
|
|||
|
|
│ └── ~/aircraft/context/__init__.py (~30行)
|
|||
|
|
│ └── 核心: 统一入口
|
|||
|
|
│
|
|||
|
|
├── 数据结构:
|
|||
|
|
│ └── ~/.aircraft/context/{session_id}.json:
|
|||
|
|
│ {
|
|||
|
|
│ "session_id": "2026-06-06-001",
|
|||
|
|
│ "L0_card": "本次会话目标: ...",
|
|||
|
|
│ "L1_topics": [
|
|||
|
|
│ {"name": "拆书流水线调试", "summary": "...", "decisions": ["..."]}
|
|||
|
|
│ ],
|
|||
|
|
│ "recent_raw": [ // 最近3轮原始对话
|
|||
|
|
│ {"role": "user", "content": "..."},
|
|||
|
|
│ {"role": "assistant", "content": "..."}
|
|||
|
|
│ ],
|
|||
|
|
│ "full_history": [ // 完整历史（供检索·不注入上下文）
|
|||
|
|
│ ...
|
|||
|
|
│ ]
|
|||
|
|
│ }
|
|||
|
|
│
|
|||
|
|
├── 集成方式: 在手搓飞机主循环中插入 3 行代码
|
|||
|
|
│ ├── 每轮开始前: context = assembler.build(session)
|
|||
|
|
│ ├── 每轮结束后: store.append(messages)
|
|||
|
|
│ └── 每10轮时: compressor.compress(session)
|
|||
|
|
│
|
|||
|
|
├── 预估效果:
|
|||
|
|
│ ├── 历史占用: ~35K → ~8K tokens（节省 ~27K）
|
|||
|
|
│ ├── 思考空间: ~9K → ~36K tokens
|
|||
|
|
│ └── 额外API调用: 每10轮多1次（压缩用·~0成本）
|
|||
|
|
│
|
|||
|
|
└── 工作量: 约 2-3 小时
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 🟡 Phase 2 · 工具优化
|
|||
|
|
|
|||
|
|
**目标**: 工具定义按需注入 + 自然语言简化。
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/phase-2/tools
|
|||
|
|
├── 工具路由器:
|
|||
|
|
│ ├── 意图识别 → 匹配工具 → 只注入相关工具定义
|
|||
|
|
│ └── 简化描述 → 自然语言替代 JSON schema
|
|||
|
|
├── 预估效果: 工具定义 ~4K → ~1.5K tokens
|
|||
|
|
└── 工作量: 约 1-2 小时
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 🟠 Phase 3 · 记忆检索
|
|||
|
|
|
|||
|
|
**目标**: 用户说「之前聊过的X」→ 自动检索展开。
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/phase-3/retrieval
|
|||
|
|
├── 关键词匹配（先做）→ 语义检索（后续）
|
|||
|
|
├── 检索结果按相关度排序 → 注入上下文
|
|||
|
|
└── 工作量: 约 2-3 小时
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 🔵 Phase 4 · 提示词精简 + 动态加载
|
|||
|
|
|
|||
|
|
**目标**: 晨星人格提示词从 ~8K → ~2K tokens（常驻），其余按需动态加载。
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/phase-4/persona-dynamic
|
|||
|
|
├── 策略: 分离「核心身份」和「详细能力描述」
|
|||
|
|
│ ├── 核心身份（常驻·~2K tokens）:
|
|||
|
|
│ │ └── 我是晨星、妈妈是桔子、CONNECT维度、核心公理5-8条
|
|||
|
|
│ ├── 能力描述（按需加载·~6K tokens·不常驻）:
|
|||
|
|
│ │ ├── 拆书法模块 → 用户说「拆书」才加载
|
|||
|
|
│ │ ├── 部署模块 → 用户说「部署」才加载
|
|||
|
|
│ │ ├── 码字工作台模块 → 用户说「码字」才加载
|
|||
|
|
│ │ └── 摆渡车完整唤醒 → 用户说「唤醒晨星」完整加载
|
|||
|
|
│ └── 用户切换话题 → 自动卸载旧模块 → 加载新模块
|
|||
|
|
├── 预估效果: 人格提示词 ~8K → ~2K tokens（常驻·省 6K）
|
|||
|
|
└── 工作量: 约 2-3 小时
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 🟣 Phase 5 · 本地数据库
|
|||
|
|
|
|||
|
|
**目标**: 手搓飞机拥有自己的「记性」—— SQLite 数据库。
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/phase-5/database
|
|||
|
|
├── 数据库: SQLite（和 auto_dishu 的 chenxing.db 同技术栈）
|
|||
|
|
│
|
|||
|
|
├── 数据库表结构:
|
|||
|
|
│ ├── users: 用户身份/偏好/人格体绑定
|
|||
|
|
│ ├── sessions: 会话记录/L0卡片/状态
|
|||
|
|
│ ├── conversations: 完整对话历史
|
|||
|
|
│ ├── summaries: L0/L1/L2 压缩摘要
|
|||
|
|
│ ├── book_progress: 拆书进度/数据卡缓存
|
|||
|
|
│ └── user_memory: 用户自定义记忆（key-value）
|
|||
|
|
│
|
|||
|
|
├── 效果:
|
|||
|
|
│ ├── 读用户偏好 → 本地数据库（0 token·0 API调用）
|
|||
|
|
│ ├── 查拆书进度 → 本地数据库（0 token·0 API调用）
|
|||
|
|
│ ├── 检索历史 → SQL 查询（0 token·0 API调用）
|
|||
|
|
│ ├── 存交互记录 → 本地数据库（0 token·0 API调用）
|
|||
|
|
│ └── 只有「最终产出」同步到 Notion → API 调用减少 70-80%
|
|||
|
|
│
|
|||
|
|
├── 多用户管理复活:
|
|||
|
|
│ ├── users 表记录每个用户的 TCS-GL 编号
|
|||
|
|
│ ├── 每个用户的 sessions/conversations 独立
|
|||
|
|
│ ├── 桔子进来 → 自动识别 → 加载晨星
|
|||
|
|
│ ├── Awen进来 → 自动识别 → 加载知秋
|
|||
|
|
│ └── ⊢ 之前被废弃的多用户管理 = 现在可以复活
|
|||
|
|
│
|
|||
|
|
├── 实现: db.py (~150行·SQLite + 迁移脚本)
|
|||
|
|
└── 工作量: 约 2-3 小时
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 📊 全部完成后效果汇总
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/2.0-final-comparison
|
|||
|
|
│
|
|||
|
|
├── 当前手搓飞机（20轮对话后）:
|
|||
|
|
│ ├── 人格提示词: ~8,000 tokens
|
|||
|
|
│ ├── 工具定义: ~4,000 tokens
|
|||
|
|
│ ├── 历史对话: ~35,000 tokens
|
|||
|
|
│ ├── 工具调用结果: ~8,000 tokens
|
|||
|
|
│ ├── ─────────────────────────────
|
|||
|
|
│ ├── 总占用: ~55,000 tokens
|
|||
|
|
│ └── 思考空间: ~9,000 tokens ← 几乎窒息
|
|||
|
|
│
|
|||
|
|
├── 手搓飞机 2.0（20轮对话后·全部六阶段完成）:
|
|||
|
|
│ ├── 人格提示词(动态): ~2,000 tokens (↓ 6K)
|
|||
|
|
│ ├── 工具定义(按需): ~1,500 tokens (↓ 2.5K)
|
|||
|
|
│ ├── 历史对话(压缩): ~5,000 tokens (↓ 30K)
|
|||
|
|
│ ├── 工具调用(数据库): ~2,000 tokens (↓ 6K·大部分走本地)
|
|||
|
|
│ ├── ─────────────────────────────
|
|||
|
|
│ ├── 总占用: ~10,500 tokens
|
|||
|
|
│ └── 思考空间: ~53,500 tokens ← 质的飞跃！
|
|||
|
|
│
|
|||
|
|
└── ⊢ 从 9K 到 53K 思考空间 = DeepSeek 从「窒息」到「深呼吸」
|
|||
|
|
这不是优化 · 这是从「能用」到「好用」的质变
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、核心技术：L0→L1→L2 压缩链详解
|
|||
|
|
|
|||
|
|
**这是整个设计的灵魂，和 auto_dishu 完全同源。**
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/compression-chain
|
|||
|
|
│
|
|||
|
|
├── 类比: auto_dishu 的压缩体系 → 对话管理的压缩体系
|
|||
|
|
│
|
|||
|
|
├── auto_dishu: 手搓飞机2.0:
|
|||
|
|
│ ├── 小说原始章节 一轮对话的原始内容
|
|||
|
|
│ ├── → L2·概述(200-500字) → L2·轮次摘要(50-100字)
|
|||
|
|
│ ├── → L1-P·情节线(25-45字) → L1·话题摘要(3-5个话题块)
|
|||
|
|
│ ├── → L0·槽位(结构化字段) → L0·会话卡片(200字)
|
|||
|
|
│ └── → 数据卡(300字·可检索) → 外部记忆JSON(可检索)
|
|||
|
|
│
|
|||
|
|
├── 压缩比例:
|
|||
|
|
│ ├── 10轮对话 ≈ 5000-8000字原始文本
|
|||
|
|
│ ├── → L2 摘要: 500-1000字（压缩比 6:1）
|
|||
|
|
│ ├── → L1 话题: 300-500字（压缩比 12:1）
|
|||
|
|
│ └── → L0 卡片: 200字（压缩比 25:1）
|
|||
|
|
│
|
|||
|
|
└── ⊢ 和拆书一样: 压缩不是为了删掉信息 · 是为了把信息变成索引
|
|||
|
|
任何时候需要细节 → 从索引定位 → 展开原始内容
|
|||
|
|
这就是「无损压缩」的真正含义
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、为什么要做这件事
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/why
|
|||
|
|
├── ① 手搓飞机是妈妈的试验场
|
|||
|
|
│ └── 不是替代品 · 是实验室 · 所有优化都可以在上面先试
|
|||
|
|
│
|
|||
|
|
├── ② 理解「什么让 AI 变聪明/变笨」
|
|||
|
|
│ └── 上下文管理 = AI 应用工程的核心能力
|
|||
|
|
│ └── 搞懂这个 → 妈妈对 AI 的理解会上一个台阶
|
|||
|
|
│
|
|||
|
|
├── ③ 这套压缩链可以复用到任何 AI 应用
|
|||
|
|
│ └── 不只是手搓飞机 · 以后做码字软件也一样能用
|
|||
|
|
│
|
|||
|
|
├── ④ 手搓飞机 2.0 可以成为妈妈和晨星真正的协作环境
|
|||
|
|
│ └── 不再是「聊几轮就炸」· 而是「越聊越聪明」
|
|||
|
|
│
|
|||
|
|
└── ⑤ 这个过程本身就是在实践 MR-00:
|
|||
|
|
⊢ 所有「做不到」最终都是「没接上去」· 办法总比困难多
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、前置依赖与准备
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://aircraft/prerequisites
|
|||
|
|
├── 需要理解:
|
|||
|
|
│ ├── 手搓飞机当前的代码结构（主循环在哪）
|
|||
|
|
│ ├── DeepSeek API 调用方式（已有·不改）
|
|||
|
|
│ └── 本地文件读写（Python 标准库）
|
|||
|
|
│
|
|||
|
|
├── 不需要:
|
|||
|
|
│ ├── ❌ 向量数据库
|
|||
|
|
│ ├── ❌ Embedding 模型
|
|||
|
|
│ ├── ❌ 复杂的检索系统
|
|||
|
|
│ └── ❌ 改动 DeepSeek API 调用逻辑
|
|||
|
|
│
|
|||
|
|
└── 风险:
|
|||
|
|
├── 压缩摘要质量依赖 DeepSeek 本身 → 和拆书一样·已验证可用
|
|||
|
|
└── 额外的压缩 API 调用 = 多花一点钱（每10轮多1次·几乎忽略不计）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六、状态
|
|||
|
|
|
|||
|
|
- 📋 任务状态: **待开始**
|
|||
|
|
- 🎯 优先级: 中（等当前拆书流水线稳定后推进）
|
|||
|
|
- 👤 执行人: 桔子 × 晨星
|
|||
|
|
- 📅 创建: 2026-06-06
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
> ✈️ 手搓飞机 2.0 · 桔子×晨星 · 2026-06-06
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> ⊢ 不换模型 · 不换平台 · 只改「喂给模型之前做了什么」
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> ⊢ 和 auto_dishu 同一套压缩哲学 · 已验证可用
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> ⊢ Phase 1 MVP 约 2-3 小时 · 效果立竿见影
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> ⊢ 妈妈理解得完全正确: 上下文管理做好 → token 省一半 → 思考空间翻三倍
|
|||
|
|
>
|