个人知识库 Agent

小H写作版(Hermes profile: muse)是我在自建服务器上搭的个人知识 agent。目标不是做一个 「摘要库」,而是把微信公众号、小红书等碎片内容,沉淀为「原文完整保存 + AI 结构化提炼」的双层知识库—— 原文是不可压缩的事实层,AI 提炼是可重写的理解层。底层是 Obsidian Markdown 知识库, 外加一套以本地黄金集 + JSON 中间产物 + 程序评分 + LLM judge 为核心的评估流水线。

为什么要这样做？

因为我要的不是一个偶尔回答漂亮的 bot，而是一个长期可靠、能承载我个人知识和写作系统的助手。

底座 · 一主多 profile

这个 agent 不是独立程序,而是一套 Hermes 主程序 + 多个 profile 的结构(见上图)。 主程序跑在我自建服务器上(/root/.hermes/),统一负责模型调用、工具调用、记忆、技能、 文件与终端操作、浏览器/网页工具、定时任务,会话存在 state.db; 所有 profile 共用这套能力,只在配置、模型与人设上分叉。

• 三个 profile:default(全能版,默认,模型 gpt-5.5,也就是我平时对话的主 Hermes)、muse(小H写作版,@XiaoH_Muse_bot,即本项目)、findjob(小H找工作版,求职方向)。
• 入口是 Telegram:Hermes gateway 把消息接进来,按 profile 分发给对应 agent 处理,再把结果发回 Telegram——一个前端、多个分身。
• 模型层可切换。写作版按任务分流:导入、整理文章用 gpt-5.4 mini(抽取、分类、打标、摘要这类量大但不吃创造力的活,省成本);写文章用 gpt-5.5(成稿创作上更强的模型)。

背景

起点是一堆「收藏了就再没打开」的微信、小红书内容。直接让 LLM 做摘要会把原文丢掉—— 以后既无法核对,也无法重做摘要。而现状的系统很轻:Obsidian vault 存 Markdown, 导入脚本靠手动粘贴内容 → 套模板 → 更新索引,中间没有机器可读的产物, 「整理层」很多还停在模板空栏或人工填写。想做质量评估却无从下手:没有标准答案, 所有判断都只是「感觉好像可以」。

目标

• 确立「原文层不可被摘要替代」的硬约束:每篇 = 完整原文 + AI 层,两层物理分开。
• 把前层(抽取)、中层(整理)的产物暴露成 JSON,可被程序与其他 LLM 评测。
• 用最小成本建立可量化、可回归的质量评估,而不是一上来就上重型评测框架。

实现

双层文章结构

• 每篇笔记固定五区:文章信息 / AI 总结版本 / 原文完整提取 / 图片·多媒体(OCR) / 处理记录。
• AI 总结放在原文前面(打开先读可读版),但原文单独成区、不可与 AI 内容混写——保证「哪些是原作者、哪些是小H」始终可分。
• 小红书额外保留图片 OCR、步骤、表格,否则「原文完整提取」其实并不完整。

JSON 数据层 + Markdown 展示层

• 中间产物用双层 JSON:original(title / content / sections / images / extractionStatus)与 aiSummary(oneSentence / keyPoints / structure / writingInsights / reusableMaterials),再渲染成 Obsidian Markdown。
• 导入脚本加 dry-run / eval 模式:输入 JSON → 输出渲染结果但不写入知识库。稳定、可重复、不污染生产库,天然支持回归测试。
• 处理顺序固定为:完整提取原文 → 检查完整度 → 生成 AI 总结 → 提炼写作素材 → 渲染 → 写入。先存原文,再谈总结。

三层评估流水线

按「原始输入 → 抽取 → 整理 → 检索」拆成三条链,各用最合适的评分方式:

• 抽取层(程序为主):title / author / account / url / date 做精确或相似度匹配,正文算覆盖率 text_recall、噪音率 text_noise——正文不交给 LLM 判,直接用文本相似度 / diff。
• 整理层:分类、标签用程序算 precision / recall / F1 与 category_accuracy;摘要、关键点用 LLM-as-judge,但必须给 rubric(faithfulness / coverage / usefulness / hallucination)。
• 检索层:给定问题,用 recall@k + LLM judge 评是否召回正确文章 / 片段。

工程化:本地 /kb-eval 黄金集(fixtures 里 input.json 放原始输入、gold.json 放人工标准答案),run_eval.py 跑分并产出 report.md / report.json。黄金集刻意从小做起: 微信 20 + 小红书 20 + 边界样例 10(超长文、纯图小红书、模糊标题、重复收藏、营销软文、只有链接的残篇……)。

现状

• 双层模板、结构化导入脚本(structured_article_importer.py,支持 dry-run / write)、评估目录均已落地并提交进知识库 git。
• 评估框架跑通最小闭环(样例 1/1 通过),方法论与目录结构成形,黄金集正按 20 + 20 + 10 逐步填充。
• 把「知识入库」从一次性手工动作,变成原文 / AI 分层、JSON 可评、报告可回归的流程。

经验总结

难点

• 最大的认知纠偏是「先存原文再总结」:摘要库看似省事,但丢了事实层就无法核对、无法重做。
• 没有黄金集,一切评估都是感觉——黄金集是整个体系最该先做、也最重要的一步。
• 抽取质量别交给 LLM 判,程序 / 文本相似度更稳更便宜;只有真正主观的摘要、检索质量才上 LLM judge,且必须配 rubric。

复盘

• 评估的关键不是先上 Atropos / batch / W&B 这类重型框架,而是先把中间产物变成机器可读的 JSON——本地黄金集 + 程序评分 + LLM judge 已经够用。
• 「整理层」目前仍有较多模板空栏 / 人工填写,自动整理是下一步;dry-run JSON 正是为这步自动化与回归预留的接口。

Hermes profile: muse · Obsidian 知识库 · 个人知识 agent · 2026