# AgentOS 知识管理系统 —— 设计说明与操作指南

> **版本**：v1.0  
> **最后更新**：2026-04-28  
> **知识库路径**：`~/workbuddy-agent-os/agent-sync/03_knowledge/`（Obsidian Vault）  
> **面向读者**：需要了解本系统设计思路、分类逻辑、目录结构、工作流程的协作者

---

## 一、系统定位与设计理念

### 1.1 这是什么？

AgentOS 知识管理系统是一套**自动化知识采集→分类→归档→检索**的完整解决方案。它不是一个简单的文件分类目录，而是一个具有以下特征的**智能知识加工流水线**：

| 特征 | 说明 |
|------|------|
| **自动采集** | 多平台信息源（B站/YouTube/小红书/抖音/RSS/网页）24h 自动抓取 |
| **智能分类** | 本地 LLM + 启发式规则自动判定知识的属性和领域 |
| **标准化归档** | 每条知识都有统一的 Frontmatter 元数据、唯一 ID、版本链 |
| **版本化管理** | 知识可进化（观点→事实、方法升级），旧版本自动保留 |
| **语义检索** | BM25 + 向量混合检索，用自然语言找到知识 |
| **双轨同步** | 坚果云实时同步 + Git 版本控制，跨设备安全可用 |

### 1.2 核心设计原则

1. **知识属性优先于内容类型**：不看"这是篇文章还是张图片"，而看"这是事实、方法、还是观点"
2. **两级分类正交设计**：**nature（知识属性）** 决定"放在哪个层"，**domain（领域）** 决定"属于哪个学科"，两者互不干扰
3. **英文目录 + 中文映射**：目录名用英文（跨平台兼容、无乱码风险），通过配置文件提供中文别名
4. **收件箱缓冲机制**：新内容不直接归档，先进入收件箱缓冲，由定时任务统一提纯
5. **自动化优先**：每日凌晨自动完成：收集→汇聚→提纯→归档→更新统计，人工干预最少化

---

## 二、目录结构总览

```
03_knowledge/
├── 00_inbox/          # 📥 收件箱（缓冲区，所有新内容先进这里）
├── 01_daily/          # 📅 日记（每日记录、闪念笔记）
├── 10_concepts/       # 💡 概念层（原子概念、公理、知识卡片）
├── 20_methods/        # 🔧 方法层（教程、最佳实践、操作步骤）
├── 30_facts/          # 📋 事实层（客观事实、法规、数据）
├── 40_references/     # 📎 参考层（论文、文档、外部资料）
├── 50_resources/      # 🛠 资源层（视频笔记、阅读笔记、灵感素材等原始收集物）
├── 60_opinions/       # 💭 观点层（主观看法、引用、推测）
├── 90_archive/        # 🗄 归档层（已过时或废弃的知识）
├── 99_system/         # ⚙️ 系统层（模板、分类表、提示词——不是知识内容）
│   ├── templates/     #    知识卡片模板（4种）
│   ├── taxonomies/    #    分类配置（领域表 + 属性表 + 中文映射）
│   ├── prompts/       #    LLM 分类提示词
│   └── timelines/     #    知识版本时间线图（自动生成）
├── README.md          # 知识库首页（统计 + 导览）
└── CHANGELOG.md       # 知识库变更日志
```

### 2.1 为什么这样分目录？

目录按**知识属性（nature）** 分层，每个数字前缀代表一个"知识层级"：

| 目录 | 前缀 | 为什么设这个目录 | 里面放什么 |
|------|------|------------------|------------|
| `00_inbox` | 00 | **缓冲区**：新内容需要统一处理后才能精确分类，直接丢进来避免"不知道放哪"的决策负担 | 所有新采集/新收集的原始内容 |
| `01_daily` | 01 | **时间维度**：有些知识是"某天的记录"，有强时间属性，不适合按属性分类 | 日记、闪念笔记、每日总结 |
| `10_concepts` | 10 | **知识原子**：概念是知识的"基本粒子"，其他知识都建立在概念之上 | 概念定义、公理、术语解释 |
| `20_methods` | 30 | **怎么做的**：方法是"行动指南"，与其他知识有本质区别——它是可执行的 | 教程、步骤、最佳实践、操作手册 |
| `30_facts` | 30 | **是什么**：事实是"世界的客观描述"，可靠性最高 | 客观事实、法规制度、实验数据 |
| `40_references` | 40 | **别人说的**：参考资料不是你的知识，而是"外部信息的索引" | 论文链接、文档引用、网页存档 |
| `50_resources` | 50 | **原始素材**：这些是"未经加工的原材料"，如视频笔记、截图、翻译等 | 视频笔记、阅读笔记、灵感素材、语音转写、字幕存档 |
| `60_opinions` | 60 | **我觉得**：观点不是事实，需要明确标注可信度，避免与事实混淆 | 个人见解、他人语录、未验证的推测 |
| `90_archive` | 90 | **过期的**：知识会过时（技术更新、事实变更），归档而非删除，保留历史可追溯 | 已被新知识替代的旧版本 |
| `99_system` | 99 | **系统本身**：模板和配置不属于知识内容，单独隔离 | 模板文件、分类配置、提示词 |

**关键洞察**：`50_resources/` 和 `99_system/` 虽然也在知识库目录下，但它们**不是知识内容本身**——resources 是原始素材（等待被提纯），system 是系统配置（不参与知识流转）。

---

## 三、知识属性分类（nature）

这是整个系统最核心的设计。每条知识都有一个 `nature` 字段，它决定了这条知识**存放在哪个目录**。

### 3.1 九种知识属性

| nature 值 | 中文名 | 一句话定义 | 目标目录 | 默认可信度 | 举例 |
|-----------|--------|------------|----------|-----------|------|
| `fact` | 事实 | 已验证的客观事实 | `30_facts/` | 1.0 | "Python 3.12 于 2023-10-2 发布" |
| `method` | 方法 | 可操作的步骤/教程 | `20_methods/` | 1.0 | "使用 Playwright 抓取 SPA 页面的 5 个步骤" |
| `concept` | 概念 | 原子概念、术语定义 | `10_concepts/` | 0.8 | "RAG：检索增强生成，是结合检索和生成的 AI 范式" |
| `axiom` | 公理 | 公认的基础原理 | `10_concepts/` | 1.0 | "欧几里得第五公设：过直线外一点有且仅有一条平行线" |
| `regulation` | 规章 | 法律/法规/制度 | `30_facts/` | 1.0 | "《个人信息保护法》2021年11月1日起施行" |
| `reference` | 参考 | 论文/文档/外部资料 | `40_references/` | 0.7 | "《Attention is All You Need》论文存档" |
| `data` | 数据 | 测试数据/基准结果 | `30_facts/` | 0.9 | "M1 Mac 运行 LLaMA-7B 推理速度：32 tokens/s" |
| `opinion` | 观点 | 主观看法/推测 | `60_opinions/` | 0.5 | "我认为 Agent 框架会比单体 LLM 更有前景" |
| `quote` | 引用 | 他人原话/语录 | `60_opinions/` | 0.6 | "Joel Spolsky: 'The best code is no code at all'" |

### 3.2 为什么分 9 种？

这是一个**粒度权衡**的结果：

- **太粗（比如只分"事实"和"非事实"）**：`concept`（定义）和 `method`（步骤）混在一起，检索时无法区分"我想查某个概念"还是"我想找某个方法"
- **太细（比如分 20 种）**：分类成本太高，LLM 分类准确率下降，维护负担增加
- **9 种是平衡点**：覆盖了日常知识的所有主要类型，每种之间有清晰的判定边界

### 3.3 分类决策树

当 LLM 或人工需要判定一条内容属于哪个 nature 时，使用以下决策树：

```
这段内容是在描述"世界是什么样"还是在说"应该怎么做"？
│
├── "是什么" → 可能是 fact / opinion / quote / data / reference / axiom
│   │
│   ├── 有实验数据/论文支持？
│   │   ├─ 是 → fact（confidence: 0.8+）
│   │   └─ 否 ↓
│   │
│   ├── 是公认无需证明的原理？
│   │   ├─ 是 → axiom（confidence: 0.95+）
│   │   └─ 否 ↓
│   │
│   ├── 是作者的个人看法/推测？
│   │   ├─ 是 → opinion（confidence: 0.4-0.6）
│   │   └─ 否 ↓
│   │
│   ├── 是引用的他人原话？
│   │   ├─ 是 → quote（confidence: 标注来源可信度）
│   │   └─ 否 ↓
│   │
│   ├── 是外部资料的链接/存档？
│   │   ├─ 是 → reference（confidence: 0.7）
│   │   └─ 否 ↓
│   │
│   └── 是测试数据/基准结果？
│       ├─ 是 → data（confidence: 0.9）
│       └─ 否 → 默认 reference
│
└── "怎么做" → 可能是 method / regulation
    │
    ├── 有法律/组织的强制力？
    │   ├─ 是 → regulation（confidence: 1.0）
    │   └─ 否 → method（confidence: 1.0）
```

### 3.4 属性变更规则

知识不是静态的，它的属性可能随着时间变化：

| 变化场景 | 处理方式 | 示例 |
|----------|----------|------|
| 观点被验证为事实 | `opinion` → `fact`，confidence 提升，文件移动到 `30_facts/` | "我推测 GPT-5 会在2025发布" → OpenAI 实际发布了 |
| 事实被推翻 | `fact` → `opinion`，confidence 降低，文件移动到 `60_opinions/` | "地球是平的" 被科学推翻 |
| 方法升级 | 保留旧版本文件，新建 v2 文件，通过 `related` 双向链接 | "部署方案 v1" → "部署方案 v2（Docker化）" |
| 知识过时 | 移动到 `90_archive/`，标记 `status: archived` | "Python 2.x 的字符串编码处理" |

> **注意**：所有属性变更都保留历史版本，不是直接覆盖。`previous_version` 和 `superseded_by` 字段构成版本链。

---

## 四、领域分类（domain）

领域分类解决的是"这条知识属于哪个学科/行业"的问题，与 nature 正交。

### 4.1 16 个一级领域

| 编号 | 英文目录名 | 中文名称 | 典型子领域 |
|------|-----------|----------|-----------|
| 01 | `cs` | 计算机科学 | 数据库、前端、后端、运维、安全 |
| 02 | `ai` | 人工智能 | NLP、CV、强化学习、RAG、Agent |
| 03 | `finance` | 金融 | 量化交易、价值投资、宏观经济 |
| 04 | `law` | 法律 | 民法、商法、知识产权 |
| 05 | `medicine` | 医学 | 中医、西医、营养学 |
| 06 | `physics` | 物理 | 量子力学、相对论、热力学 |
| 07 | `math` | 数学 | 线性代数、概率统计、微积分 |
| 08 | `psychology` | 心理学 | 认知心理学、社会心理学 |
| 09 | `philosophy` | 哲学 | 认识论、伦理学、美学 |
| 10 | `history` | 历史 | 中国史、世界史、科技史 |
| 11 | `engineering` | 工程 | 机械、电子、土木 |
| 12 | `design` | 设计 | UI/UX、平面设计、建筑设计 |
| 13 | `business` | 商业 | 创业、管理、营销、战略 |
| 14 | `personal-management` | 个人管理 | GTD、番茄工作法、精力管理 |
| 15 | `personal-insight` | 个人洞见 | 决策模型、价值观、反思 |
| 16 | `other` | 其他 | 暂未归类 |

### 4.2 领域 vs 属性：正交关系

一条知识的**最终存储位置**由两者共同决定：

```
物理路径 = 目标目录（由 nature 决定）+ 领域子目录（由 domain 决定）
```

**示例**：

| 知识标题 | nature | domain | 物理路径 |
|----------|--------|--------|----------|
| Transformer 架构解析 | concept | ai | `10_concepts/ai/transformer-架构解析.md` |
| macOS 终端快捷键 | method | cs | `20_methods/cs/macos-终端快捷键.md` |
| 2026年Q1 GDP 增速 5.4% | fact | finance | `30_facts/finance/2026q1-gdp.md` |
| 价值投资核心理念 | opinion | finance | `60_opinions/finance/价值投资核心理念.md` |
| GTD 工作流详解 | method | personal-management | `20_methods/personal-management/gdt-工作流.md` |

### 4.3 领域扩展规则

- 当 `other/` 类别下的文件数**超过总文件数的 5%** 时，系统会提示新增领域
- 新领域需同时定义：中文名称、英文目录名、说明、典型子领域
- 新增后需更新两个文件：`domains.md`（分类表）和 `folder-aliases.json`（中文映射）

---

## 五、知识卡片模板

每条归档的知识都是一个标准化的 Markdown 文件，使用对应的卡片模板。模板保证了知识的**结构一致性**，便于检索和版本管理。

### 5.1 为什么用 4 种模板而非 1 种？

不同属性的知识需要记录的信息完全不同：

| 属性 | 需要记录的关键信息 | 模板 |
|------|-------------------|------|
| 概念 | 定义、原理、与相关概念的区别 | `concept-card.md` |
| 方法 | 目标、前置条件、步骤、常见问题 | `method-card.md` |
| 事实 | 数据来源、事实内容表格、结论 | `fact-card.md` |
| 个人洞见 | 背景、核心观点、可复用原则、验证项 | `personal-insight-card.md` |

如果用一种"万能模板"，要么字段太多（大量留空），要么字段太少（丢失关键信息）。

### 5.2 模板一：概念卡片（concept-card.md）

**适用**：`nature: concept` 和 `nature: axiom`

```yaml
---
id: KB-YYYYMMDD-NNN          # 唯一标识符（自动生成）
title: "__概念名称__"
type: concept                 # 卡片类型
status: draft                 # 状态：draft/review/published/archived
nature: fact                  # 知识属性
domain: [计算机科学]           # 领域（1-3个）
subdomain: []                 # 子领域（可选）
tags: [__标签1__, __标签2__]  # 检索标签
confidence: 0.8               # 可信度（0-1）
source: ""                    # 来源 URL
source_type: literature       # 来源类型
date_created: __DATE__        # 创建日期
date_modified: __DATE__       # 最后修改日期
version: 1                    # 版本号
aliases: [__别称__]           # 别名（方便不同叫法都能找到）
keywords: [__关键词__]        # 关键词（用于 BM25 检索）
summary: "__一句话摘要__"     # 摘要（用于 L2 摘要层检索）
related: []                   # 关联知识（双向链接）
previous_version: ""          # 上一版本 KB-ID
superseded_by: ""             # 被哪个版本替代
---
```

**正文结构**：
1. **一句话定义**：用最简洁的语言定义
2. **核心原理**：3-5 个要点
3. **与相关概念的区别**：对比表格（擅长/不擅长）
4. **主流选择/实现**：业界常见方案
5. **相关概念**：`[[双向链接]]`

**设计意图**：概念卡片的目标是"让读者 30 秒内理解一个概念"。一句话定义是核心，其余部分提供上下文。

### 5.3 模板二：方法卡片（method-card.md）

**适用**：`nature: method`

```yaml
---
id: KB-YYYYMMDD-NNN
title: "__方法/教程标题__"
type: method
status: published
nature: method
domain: [__领域__]
confidence: 1.0
source: "__来源__"
date_created: __DATE__
date_modified: __DATE__
version: 1
previous_version: ""
superseded_by: ""
---
```

**正文结构**：
1. **目标**：这个方法解决什么问题？
2. **前置条件**：需要什么才能执行
3. **步骤**：编号步骤 + 代码示例
4. **注意事项**：踩过的坑
5. **常见问题**：问题-原因-方案 三列表格
6. **历史版本**：变更记录

**设计意图**：方法卡片的目标是"让读者照着做就能成功"。步骤是核心，常见问题是防错保障。

### 5.4 模板三：事实卡片（fact-card.md）

**适用**：`nature: fact`、`nature: regulation`、`nature: data`

```yaml
---
id: KB-YYYYMMDD-NNN
title: "__事实标题__"
type: fact
status: published
nature: fact
domain: [__领域__]
confidence: 0.9
source: "__来源URL或出处__"
source_type: experiment|literature|official_doc|personal_exp
date_created: __DATE__
date_modified: __DATE__
version: 1
previous_version: ""
superseded_by: ""
---
```

**正文结构**：
1. **数据来源**：来源说明、测试环境、文献出处
2. **事实内容**：维度-值-备注 三列表格
3. **结论**：基于事实得出的结论
4. **历史版本**：变更记录

**设计意图**：事实卡片的目标是"可追溯、可验证"。`source` 和 `source_type` 是关键——没有来源的事实不可信。

### 5.5 模板四：个人洞见卡片（personal-insight-card.md）

**适用**：`nature: opinion`（特别是个人洞见类）

```yaml
---
id: KB-YYYYMMDD-NNN
title: "__个人洞见标题__"
type: concept
status: draft                  # 洞见默认 draft，需验证后才 published
nature: opinion
domain: [个人洞见]
tags: [__标签1__, __标签2__]
confidence: 0.6                # 洞见默认 0.6（不高不低）
source_type: personal_exp      # 来源类型固定为个人经验
date_created: __DATE__
date_modified: __DATE__
version: 1
previous_version: ""
superseded_by: ""
---
```

**正文结构**：
1. **背景**：什么情境下产生的
2. **核心观点**：一句话概括
3. **详细思考**：推理过程
4. **可复用的原则**：抽象出来的通用规则
5. **相关经历**：案例支撑
6. **后续验证**：待验证项 checklist

**设计意图**：个人洞见是"最有价值但最不可靠"的知识类型。默认 `status: draft` 和 `confidence: 0.6`，通过"后续验证"机制逐步提升可信度。当验证通过后可升级为 `fact`。

---

## 六、Frontmatter 字段详解

所有知识卡片共享一套 Frontmatter 字段体系。以下是每个字段的含义和用途：

### 6.1 必填字段

| 字段 | 类型 | 说明 | 示例 |
|------|------|------|------|
| `id` | string | 唯一标识符，自动生成 | `KB-20260428-001` |
| `title` | string | 知识标题 | `"Transformer 架构详解"` |
| `type` | enum | 卡片类型（与模板对应） | `concept` / `method` / `fact` |
| `status` | enum | 生命周期状态 | `draft` / `review` / `published` / `archived` |
| `nature` | enum | 知识属性（9种） | `fact` / `method` / `concept` / ... |
| `domain` | list | 领域分类（1-3个） | `[人工智能, 计算机科学]` |
| `confidence` | float | 可信度（0-1） | `0.85` |
| `source` | string | 来源 URL 或出处 | `"https://arxiv.org/abs/1706.03762"` |
| `date_created` | date | 创建日期 | `2026-04-28` |
| `date_modified` | date | 最后修改日期 | `2026-04-28` |
| `version` | int | 版本号 | `1` |

### 6.2 可选字段

| 字段 | 类型 | 说明 | 示例 |
|------|------|------|------|
| `subdomain` | list | 子领域 | `[自然语言处理, 大模型]` |
| `tags` | list | 标签（用于检索） | `[transformer, attention, nlp]` |
| `author` | string | 作者 | `"Ashish Vaswani"` |
| `source_type` | enum | 来源类型 | `official_doc` / `literature` / `personal_exp` / `social_media` / `unknown` |
| `related` | list | 关联知识的 KB-ID | `["KB-20260425-003"]` |
| `previous_version` | string | 上一版本的 KB-ID | `KB-20260420-001` |
| `superseded_by` | string | 被哪个新版本替代 | `KB-20260428-002` |
| `aliases` | list | 别名/同义词 | `[Self-Attention, 自注意力机制]` |
| `keywords` | list | 关键词（BM25 检索用） | `[attention, self-attention, transformer]` |
| `summary` | string | 一句话摘要 | `"Transformer 是一种基于自注意力机制的序列建模架构"` |

### 6.3 可信度评分（confidence）

可信度不是"我信不信"，而是**来源的客观可靠程度**：

| source_type | confidence | 说明 |
|-------------|-----------|------|
| `official_doc` | 0.9 | 官方文档、法律文本 |
| `literature` | 0.8 | 学术论文、经过同行评审 |
| `experiment` | 0.7 | 自己实验验证过 |
| `personal_exp` | 0.5 | 个人经验（可能有偏差） |
| `social_media` | 0.3 | 社交媒体（可靠性低） |
| `unknown` | 0.4 | 来源不明 |

**知识入库时的自动修正**：基础分 0.5，然后根据来源类型加减：
- 官方文档/学术论文：+0.3
- 知名技术博客/行业报告：+0.1
- 个人博客/论坛帖子：-0.1
- 未知来源/社交媒体：-0.3

---

## 七、知识生命周期

一条知识从"发现"到"归档"的完整生命周期：

```
                    ┌──────────────────────────────────────────────────┐
                    │                  知识生命周期                      │
                    └──────────────────────────────────────────────────┘

  ① 发现/采集                ② 汇聚              ③ 提纯/分类
┌───────────┐           ┌──────────┐         ┌───────────────┐
│ 多平台采集 │───原始──→│ 收件箱   │──标准──→│ 分类 + 模板化  │
│ B站/小红书 │   内容    │ 00_inbox │   MD    │ + ID 生成     │
│ RSS/网页   │           │          │         │ + 去重检查     │
└───────────┘           └──────────┘         └───────┬───────┘
                                                      │
                    ┌─────────────────────────────────┤
                    │                                 │
                    ▼                                 ▼
              ④ 归档入库                        ⑤ 持续进化
        ┌──────────────┐                  ┌──────────────────┐
        │  按nature分配  │                  │  属性变更        │
        │  到目标目录    │                  │  opinion → fact  │
        │  + domain子目录│                  │  method v1 → v2  │
        │  + 更新统计    │                  │  过时 → archive  │
        └──────────────┘                  └──────────────────┘
```

### 7.1 各阶段详情

#### 阶段①：自动采集

| 信息源 | 采集工具 | 保存位置 | 频率 |
|--------|----------|----------|------|
| B站/YouTube 订阅 | BiliNote | `50_resources/视频笔记/` | 每 30 分钟 |
| 小红书博主 | TikOmni | `50_resources/灵感素材/` | 每 2 小时 |
| 抖音账号 | TikOmni | `50_resources/灵感素材/` | 每 2 小时 |
| RSS 订阅源 | feedparser | `40_references/` | 每 15 分钟 |
| 指定网页 | Crawl4AI | `40_references/` | 每 1 小时 |

#### 阶段②：汇聚收件箱（collect_to_inbox 技能）

- **执行时间**：每日凌晨 2:30
- **做什么**：扫描 `50_resources/`、`20_methods/`、`40_references/`、`01_daily/` 等目录中的文件，提取主要内容生成标准化 MD，放入 `00_inbox/`
- **去重**：同名/同标题文件跳过，已标记 `collected: true` 的跳过

#### 阶段③：提纯分类（inbox_refine 技能）

- **执行时间**：每日凌晨 3:00
- **做什么**：
  1. 读取 `00_inbox/` 所有文件
  2. 用本地 LLM（oMLX + Qwen 模型）或启发式规则判定 nature + domain
  3. 应用对应卡片模板
  4. 生成唯一 ID（格式 `KB-YYYYMMDD-NNN`）
  5. 去重检查（标题相似度 > 0.8 则合并）
  6. 写入目标目录
  7. 删除收件箱原文件
  8. 更新首页统计和变更日志

#### 阶段④：归档入库

归档后的知识文件名格式：`{标题}.md`，存储在 `{nature对应目录}/{domain}/` 下。

#### 阶段⑤：持续进化

| 变化类型 | 触发条件 | 处理 |
|----------|----------|------|
| 属性变更 | 观点被验证/事实被推翻 | 更新 nature，移动文件，更新内链 |
| 版本升级 | 方法有更好的方案 | 保留旧版，新建 v2，双向链接 |
| 过期归档 | 180 天未更新的技术知识 | 标记 `archived`，移入 `90_archive/` |
| 知识修补 | 用户纠正 AI 输出 | 更新 confidence，记录修正日志 |

---

## 八、自动分类的实现机制

### 8.1 LLM 分类（主要方式）

使用本地 LLM（oMLX + Qwen2.5-VL-3B）调用以下提示词进行分类：

```
你是一个知识分类助手。请对以下内容进行分析，返回 JSON 格式。

输入：{{content}}

输出：
{
  "domain": ["领域1", "领域2"],      // 从16个领域中选择1-3个
  "nature": "fact",                  // 从9种属性中选择
  "confidence": 0.85,                // 可信度评分
  "tags": ["标签1", "标签2"],        // 3-5个标签
  "summary": "一句话摘要"             // 60字以内
}
```

**降级机制**：当 LLM 不可用时，自动切换到基于关键词的启发式规则分类。

### 8.2 置信度阈值

- LLM 分类信心度 ≥ 0.4 → 采用 LLM 结果
- LLM 分类信心度 < 0.4 → 保留在 `00_inbox/`，标记 `#待分类`，等人工处理

### 8.3 去重策略

| 检测维度 | 阈值 | 处理 |
|----------|------|------|
| 标题完全一致 | 100% | 跳过，记录日志 |
| 标题相似度 | > 0.8 | 合并（补充细节到已有文件） |
| 内容完全一致 | 100% | 跳过 |
| 同一事实新旧矛盾 | — | 新事实覆盖，旧值写入 `previous_version` |

---

## 九、知识检索机制

### 9.1 检索分层

```
用户提问
  ↓
L1 关键词索引（BM25） ←── 快速粗筛
  ├─ 无匹配 → 返回"无相关记忆"
  └─ 有匹配 ↓
L2 结构化摘要（SQLite facts.db） ←── 精确匹配
  ├─ 置信度 ≥ 0.7 → 返回摘要
  └─ 置信度 < 0.7 → 截止，返回"无高置信结果"
                      ↓
                  【不自动加载原文】
                  仅用户明确要求时 → L3 按行号加载原文片段
```

### 9.2 混合检索

- **BM25（关键词匹配）**：适合精确术语检索，如"RAG"、"transformer"
- **向量检索（ChromaDB + Qwen3-Embedding-0.6B）**：适合语义相似检索，如"怎么让 AI 记住之前说过的话"
- **RRF（倒数秩融合）**：将两路结果合并排序

### 9.3 检索不加载全文

这是关键设计——检索时只返回摘要和行号片段，不加载整个文件。原因：
1. **节省 token**：一个知识文件可能有几千字，但用户只需要其中的一个段落
2. **保护隐私**：L3 原文层不暴露给外部 API
3. **按需加载**：用户看到摘要后，觉得需要更多细节，再按行号加载指定片段

---

## 十、版本管理与时间线

### 10.1 三种变化类型

| 变化类型 | 举例 | 处理 |
|----------|------|------|
| **硬事实改变** | 服务器配置从 4C8G → 8C16G | 原地更新，旧值写入 `previous_version` |
| **软升级** | 方法 V1 → V2（V1 仍有参考价值） | 保留 V1 文件，新建 V2，通过 `related` 双向链接 |
| **观点→事实** | 推测经过验证变为可靠知识 | 更新 `nature`，提升 `confidence`，移动到对应目录 |

### 10.2 版本链

每条知识的 Frontmatter 中维护版本信息：

```yaml
version: 2
previous_version: KB-20260420-001    # 我是从哪个版本进化来的
superseded_by: ""                     # 我是否被新版本替代（空=当前有效）
```

当一条知识经过 **3 次以上重要更新**，系统自动在 `99_system/timelines/` 下生成 Mermaid 时间线图。

---

## 十一、中文映射机制

### 11.1 为什么用英文目录名？

- **跨平台兼容**：中文路径在 Windows/Git/NFS 等环境下容易出现编码问题
- **脚本友好**：Shell 脚本、Python 路径拼接不会因为中文出 bug
- **Git 友好**：避免提交时的文件名编码歧义

### 11.2 中文映射怎么工作？

`folder-aliases.json` 提供完整的目录中文映射：

```json
{
  "knowledge": {
    "00_inbox": "收件箱",
    "10_concepts": "概念层",
    "20_methods": "方法层",
    "30_facts": "事实层",
    ...
  },
  "concepts_domains": {
    "cs": "计算机科学",
    "ai": "人工智能",
    ...
  }
}
```

**使用场景**：
- LLM 分类时，输出中文领域名（"人工智能"），系统查表得到英文目录名（`ai`），用于拼接物理路径
- 知识库首页展示时，读取映射表显示中文名称
- 日志和通知中显示中文名，方便阅读

---

## 十二、配置文件清单

知识管理系统的所有配置集中在 `99_system/` 目录下：

| 文件 | 路径 | 作用 |
|------|------|------|
| 领域分类表 | `99_system/taxonomies/domains.md` | 定义 16 个一级领域及其子领域 |
| 属性分类表 | `99_system/taxonomies/nature-types.md` | 定义 9 种 nature 类型 + 分类决策树 |
| 中文映射 | `99_system/taxonomies/folder-aliases.json` | 英文目录 ↔ 中文名映射（JSON） |
| 概念卡片模板 | `99_system/templates/concept-card.md` | 概念/公理知识模板 |
| 方法卡片模板 | `99_system/templates/method-card.md` | 方法/教程知识模板 |
| 事实卡片模板 | `99_system/templates/fact-card.md` | 事实/法规/数据知识模板 |
| 个人洞见模板 | `99_system/templates/personal-insight-card.md` | 个人见解/反思模板 |
| 分类提示词 | `99_system/prompts/classify-knowledge.md` | LLM 自动分类的 Prompt 模板 |

---

## 十三、自动化任务时间表

知识管理涉及的定时任务：

| 时间 | 任务 | 技能 | 说明 |
|------|------|------|------|
| 02:00 | 每日记忆提炼 | memory_manager | 提炼昨日对话为结构化记忆 |
| 02:30 | 收件箱汇聚 | collect_to_inbox | 扫描各目录 → 提取 → 放入 00_inbox |
| 03:00 | 收件箱提纯 | inbox_refine | 00_inbox → 分类 + 模板化 → 归档 |
| 23:00 | 采集日报汇总 | auto_collector | 汇总当日采集数据 |

---

## 十四、操作速查

### 14.1 手动操作命令

| 操作 | 说/触发词 | 系统行为 |
|------|-----------|----------|
| 入库知识 | "入库"、"保存知识" | 内容 → `00_inbox/` |
| 提纯收件箱 | "提纯"、"inbox refine" | `00_inbox/` → 分类归档 |
| 汇聚收件箱 | "归集"、"collect inbox" | 各目录 → `00_inbox/` |
| 知识检索 | "查知识库"、"知识检索" | L2 摘要检索 → 返回结果 |
| 重分类 | "知识重分类" | 更新 nature → 移动文件 |
| 备份知识库 | "知识备份" | 全量/增量备份 |

### 14.2 手动添加知识的步骤

1. 将内容保存到 `00_inbox/`（手动创建 .md 文件，或说"入库 xxx"）
2. 系统会在下次提纯时（凌晨 3:00 或手动触发）自动分类
3. 分类后可在对应目录找到标准化知识卡片

### 14.3 直接归档（跳过收件箱）

对于已经有明确分类的知识，可以直接使用 `kb_manager` 的入库功能指定 nature 和 domain，跳过收件箱直接写入目标目录。

---

## 十五、知识库首页统计

知识库首页 `README.md` 自动维护统计信息：

```
| 英文目录 | 中文名称 | 文件数 | 最近更新 |
|----------|----------|--------|----------|
| 10_concepts | 概念层 | 1 | 2026-04-28 |
| 20_methods | 方法层 | 0 | — |
| 30_facts | 事实层 | 0 | — |
| ... | ... | ... | ... |
```

每次 inbox_refine 执行后自动刷新。

变更日志 `CHANGELOG.md` 记录每次归档操作：

```markdown
## 2026-04-28

### 归档
- [concept] 测试 LLM 分类器 → 10_concepts/ (KB-20260428-001)
```

---

## 十六、总结：知识管理系统的核心逻辑

```
┌─────────────────────────────────────────────────────────┐
│                     设计哲学                              │
│                                                          │
│  ① 知识是活的：可以进化、可以被修正、有过期时间             │
│  ② 分类是正交的：属性（nature）× 领域（domain）            │
│  ③ 自动化优先：采集→汇聚→提纯→归档 全自动                  │
│  ④ 可追溯性：每条知识都有来源、版本链、变更记录             │
│  ⑤ 可信度量化：不回避不确定性，用 confidence 评分表达       │
│  ⑥ 检索不加载：按需获取片段，节省 token                    │
└─────────────────────────────────────────────────────────┘
```

**一句话总结**：这是一个以 Obsidian Markdown 文件为基础、以 LLM 为分类引擎、以自动化任务为驱动、以版本化管理为保障的**全链路知识加工流水线**。