Hermes Agent 高級玩法:微信 + LLM Wiki + Obsidian 打造終極 AI 知識管理
📛 開場:Hermes 發音澄清
- 粉絲留言話 H 唔發音:上期片之後有人 comment 話 Hermes 個 H 唔讀
- 用 ChatGPT 查證:美式同英式音標都有 H 發音
- 命名來源:來自希臘神話奧林匹斯神赫爾莫斯(眾神使者),同 Hermès 奢侈品完全冇關
💬 Step 1:WeChat 原生整合
- 功能介紹:Hermes Agent 而家原生支援微信,可以用文字、圖像、語音、文件同 AI 互動
- 安裝 + 啟動:跑兩條 install 指令,升級 Hermes 到最新版,執行 setup 指令
- 掃碼登錄:terminal 選「微信」選項 → 生成 QR code → 用手機微信掃 → 選群聊權限(僅限某啲 / 全部 / 列表)
- 配對手機:手機收到 pairing 指令 → 喺 terminal 輸入配對 → 連接成功
- 測試:問模型名稱(返「MAX model」),叫佢列出編程相關嘅 skills
📚 Step 2:用 LLM Wiki skill 複刻 Andrej Karpathy 工作流
- 背景:上期片介紹咗 graphify(適合分析 code repository),但日常筆記文檔要用另一個方法
- Hermes 官方內置:已將 Karpathy 嘅 LLM Wiki 以 skill 方式嵌入 Hermes Agent
- 呼叫 skill:terminal 輸入
+lmwak → 進入 Andre Karpathy 嘅 LLM Wiki 工作流
- 建立 Wiki:叫 agent「建一個用嚟存大模型微調論文嘅知識庫」→ 選新建獨立 wiki → 按建議 path → 核心檔案自動生成
🧱 Step 3:輸入論文 + 三層架構解釋
- 支援格式:PDF 同 arXiv 鏈接都得
- 實測:輸入三篇大模型微調論文鏈接,agent 自動抓取 + 生成 concept/entities 頁面 + 更新 index
- 三層架構(LLM Wiki 核心):
- Immutable Layer(不可變層):原始來源(論文、圖、會議記錄)—— AI 只讀不可改,保持 single source of truth
- Wiki Page Layer(agent 層):摘要、實體、概念、綜合分析頁面,完全由 agent 創建維護 + 交叉引用
- Co-evolution Layer(協同進化層):Schema 配置 + 約束,人類同 AI 共同維護
🆚 Step 4:LLM Wiki vs 傳統 RAG
- 傳統 RAG:無狀態碎片檢索
- 每次 query 都從零開始:文檔分塊 → 向量嵌入 → 相似度檢索 → 臨時生成 → 答案丟棄
- 同一問題反覆發現相同知識,唔會累積
- LLM Wiki:有狀態知識編譯
- 完整攝入論文 → 提取結構化知識 → 交叉引用 → 編譯查詢 → 歸檔有價值答案返 wiki
- 實現複利增長,成為真正「數據飛輪」
🔬 Step 5:設定研究方向 + 編譯 Wiki
- 研究主題:輸入「如何防止過擬合」
- Agent 行為:
- 先 check schema 有冇相關標籤
- 創建缺失頁面(「災難性遺忘」、「微調方法防過擬合」等)
- 更新 index + log 檔案
- 總結:新增 4 個相關頁面,wiki 由 13 頁增至 17 頁
- Query 結果:叫 agent「根據剛才嘅研究講解點防止過擬合」→ 按整理嘅論文 + 概念畀詳細答案
🔀 Step 6:Multi-Wiki 管理
- 切換 wiki:輸入「切換到 LLM memory wiki」→ 無縫切換到之前建嘅舊 wiki
- 加新論文:搵兩篇記憶相關論文輸入 → agent 攝入 + 更新 + 畀出核心貢獻對比
- Demo:叫 agent 講解「生物啟發認知壓縮」概念 → 詳細答案基於新加嘅論文
🎨 Step 7:Obsidian 整合 + Wiki 合併
- 打開 Obsidian:搵返啱啱建嘅微調 wiki → click 開 index 頁面
- 查看頁面:「災難性遺忘」頁面有定義、典型場景、主流解決方案、相關概念
- Knowledge Graph:用 Obsidian 視覺化功能睇概念之間嘅關係
- 合併 Wiki:叫 Hermes Agent 合併微調 + LLM memory 兩個 wiki → 合併成主 wiki 共 27 頁
- 對比:合併後嘅 graph 比之前複雜好多,概念關係更豐富
💡 呢個做法點解 significant?
同傳統 RAG 嘅分別
- 從無狀態 → 有狀態:RAG 每次 query 從零開始,LLM Wiki 有持續累積嘅編譯狀態
- 答案歸檔:有價值嘅查詢結果會寫返 wiki 做新頁面 → 實現數據飛輪
- 三層架構明確分工:source 唯讀保護、agent 全權維護 wiki 頁面、人類同 AI co-evolve schema
限制 / 風險 / caveats
- 唔適合 code 分析:Code repository 用 graphify 更好,LLM Wiki 主要針對文檔/筆記/論文
- Source 必須唯讀保護:如果畀 AI 寫權限到原始 source,有機會改壞或者幻覺污染 single source of truth
- 仲係要人類監督:Co-evolution layer 要人同 AI 共同維護 schema 同約束
- 視覺複雜度:只係合併兩個 wiki 個 graph 已經複雜好多,大規模擴展後可能難 navigate
對 business / implementer 嘅實際意義
- 零維護知識庫:AI 處理所有摘要、索引更新、交叉引用——人類基本上 zero maintenance
- 複利增長機構知識:公司可以建立真正嘅數據飛輪,持續攝入 PDF、web link、會議記錄
- 無縫流動訪問:微信整合後,員工可以用手機(文字/語音/圖/文件)直接 query 公司知識庫
- 視覺化理解:生成嘅檔案同 Obsidian 無縫整合,可以直接睇 knowledge graph
- 模組化擴展:可以由小 wiki 開始,後期合併成主 database