去年我开始给 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 协议。
Top comments (0)