MediaCrawler/mac-agent-os-main/90_archive/docs/AgentOS-知识管理系统说明文档.md

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

---
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

---
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

---
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（特别是个人洞见类）

---
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 中维护版本信息：

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 提供完整的目录中文映射：

{
  "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 记录每次归档操作：

## 2026-04-28

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

---

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

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

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