Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
2026-07-17 15:59:55 +08:00

550 lines
25 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# ✈️ 手搓飞机 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 L0L1L2 压缩链 + 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.020轮对话后·全部六阶段完成:
├── 人格提示词(动态): ~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 省一半 → 思考空间翻三倍
>