去年我开始给 Hermes Agent 搞知识库。最初的想法很简单：装个向量数据库，查资料时能命中就行。结果跑了一圈发现——纯向量检索在 Agent 场景下不够用。
有些记忆是你能精确描述的（"帮我查上次那篇讲 gbrain 孤页的文章"），有些记忆你只记得个大概（"有个关于知识图谱的……"），有些记忆你甚至不知道你该知道什么（"我有哪些笔记是没关联起来的？"）。一个检索策略覆盖不了这三种场景。
这就是 Knowledge-and-Memory-Management v0.0.2 解决的问题。
三层不是为了「多」，而是为了互补
项目是目前运行在 Hermes Agent 生态里的扩展层，底座是 hermes-memory-installer 提供的 gbrain（知识图谱）+ Hindsight（向量记忆）。KMM 在这上面加了四组模块：采集、笔记/RAG、云盘同步、知识增广。
其中最有工程价值的设计是三层跨层召回：
FTS5 全文搜索 → 精确命中，知道你要什么
Hindsight 向量语义 → 模糊配匹，关键词不够时靠语义
gbrain 知识图谱 → 关系探索，你不知道但相关的节点
lightweight_recall.py 把这三级串联成一条管线——先查本地 SQLite FTS5，命中直接返回；没命中走 Hindsight 的文本嵌入匹配；还不满意就用 gbrain 展开知识图谱的邻接节点。
代码在 $AGENT_HOME/scripts/lightweight_recall.py，调用并不复杂：
# 三层召回示例
from knowledge_collector.knowledge_management import KnowledgeManager
km = KnowledgeManager()
# 一次调用，三级自动回退
results = km.tiered_search(
query="Agent 记忆系统设计",
tiers=["fts5", "hindsight", "gbrain"],
limit_per_tier=5
)
for tier, hits in results.items():
print(f"[{tier}] {len(hits)} 条结果")
for h in hits[:2]:
print(f" → {h['title']} ({h['relevance']:.2f})")
FTS5 走 SQLite 内置，零依赖；Hindsight 端口 8890；gbrain 端口 8787。每层都是独立的可降级——向量服务挂了，全文搜索照样能跑。
真正干活的是这 40+ 工具
三层召回是检索层，采集层才是让知识库有东西可喂的入口。项目塞了 40+ 采集分析工具，按类型分：
- 网页采集（9 引擎）：Scrapling 做反检测，Crawl4AI 做智能路由，爬公众号不走弯路
- 视频采集（12 工具）：yt-dlp 拖流 → Whisper ASR 转写 → PaddleOCR 关键帧，抖音/YouTube 一把抓
- 文档分析（9 工具）：SenseNova 三件套（PDF/PPT/Word）处理扫描件和复杂排版
-
书籍精炼（6 工具）：
book_to_skill管线把 PDF/EPUB 拆成结构化 Skill + KMM 笔记
每周日凌晨还有个 knowledge_discovery.py 爬起来，扫 OneDrive 上的新笔记，自动录入 gbrain，顺便跑孤页链接修复——这些属于「你不需要知道它存在，但它让系统不腐烂」的基建。
几个工程取舍
- 不做纯向量优先：FTS5 第一级是因为延迟低（毫秒级），且精确关键词匹配在查代码、查配置时远好于语义
- gbrain 孤页处理是刚需：知识图谱不加链接维护，三个月后 90% 的页面都成孤岛（亲测 10,666 页从 1,716 个孤页降到 33）
- 采集优先于检索：没有好的采集管线，检索再强也是对着空库跑——项目把采集工具堆到 40+ 不是炫技
适用场景
如果你的 Agent 需要从多个来源（网页、视频、文档、公众号）持续摄入知识，并且知识需要在精确搜索、模糊回忆和关系探索三个维度上都能命中——三层模式值得一试。不需要全部部署，只接 FTS5 + gbrain 两层也能跑，每层独立可降级。
GitHub: mage0535/Knowledge-and-Memory-Management，MIT 协议。