
在上一篇文章中,我們探討了 AI Agent(代理)的本質——它不再只是在對話框裡教你「怎麼做」,而是具備了手腳與工具呼叫能力,直接「幫你做」。
但當你興沖沖地部署好 Agent,準備讓它接管日常工作時,很快就會撞上下一道高牆:「對話框的健忘症」。
每一次你開啟新的對話視窗(New Chat),AI 就成了一個對你一無所息的陌生人。你上週與它反覆討論定案的技術架構、你個人偏好的程式碼命名規範、甚至專案的背景脈絡,全部煙消雲散。你必須不厭其煩地重新餵給它「前情提要」,否則它給出的建議就會開始偏離軌道。
要解決這個問題,我們必須為分身打造一套專屬的長期記憶系統。本篇我們就從實作邏輯出發,聊聊我如何用 LLM Wiki 作為中樞,結合 SQLite 關係庫 與 ChromaDB 向量庫,建立起一套讓 AI 分身不會斷片的雙軌制長期記憶。
一、 脈絡視窗的謊言:大容量不等於好記憶
目前很多大型語言模型都宣稱支援 100 萬甚至 200 萬的 Token 上下文(Context Window)。許多人因此產生一個誤解:「那我把過去幾十萬字的對話歷史和專案文件全部塞給它不就好了?」
但在實際運作中,這會帶來三個致命痛點:
- Lost in the Middle(注意力分散):模型在面對極長上下文時,容易忽略中間段落的關鍵細節,甚至產生邏輯混淆與幻覺。
- Token 費費用的財務黑洞:每次對話你每輸入一個字,AI 都要把過去的幾十萬字重新讀取一遍。如果使用的是付費 API,你的 Token 帳單會以驚人的速度爆炸。
- 資訊污染:垃圾資訊(過時的程式碼嘗試、冗長對話)與黃金決策(最終選用的技術規格)混雜在一起,會直接降低 AI 的輸出智商。
因此,真正合格的 AI 分身,不能只有「大容量硬碟」,更需要一套能夠自動過濾、提煉與分類的長期記憶架構。
二、 記憶的中樞:LLM Wiki (知識合成層)
如果把原始資料(Raw Sources)比喻成未經開採的礦石,LLM Wiki 就是提煉出來的黃金。
在我的個人助理(代號 Antigravity)記憶系統中,我沒有讓 AI 直接去讀取混亂的聊天紀錄或原始檔案,而是引入了 LLM Wiki 作為核心中樞。
簡單來說,LLM Wiki 是一套以人機協同為核心、採用 Markdown 格式書寫的結構化知識庫,它通常被存放在我的本地 Obsidian 筆記庫中,並分成四大維度:
- 實體 (Entities):記錄人物背景、合作夥伴公司,或特定軟硬體產品的技術規格(例如:Vizrt TriCaster, KarismaCG3)。
- 概念 (Concepts):記錄抽象的技術邏輯或工作流(例如:NDI IP 工作流、賽事數據大腦)。
- 綜合 (Synthesis):將多個原始文件融會貫通後的實務調優指引(例如:KCG 控播系統 TVBS 測試與排障紀錄)。
- Blog:存放已發布或撰寫中的個人部落格文章與企劃。
LLM Wiki 最強大的武器,在於它支援 Markdown 的 [[雙向連結]] (Bi-directional Links)。 這讓知識點之間不再孤立,而是像人腦的突觸一樣,縱橫交錯成一張有脈絡的知識網。
三、 三位一體:雙軌制記憶的技術實作
有了 LLM Wiki 作為知識中樞後,我們就可以利用程式碼,圍繞它搭建出「三位一體」的記憶檢索網絡:
graph TD
A["混沌原始資料 raw_sources
會議記錄、對話 Log、PDF"] -->|經過人機協同提煉與合成| B("LLM Wiki 知識中樞
利用雙連結的 MD 筆記")
B --> C["精準關係索引
SQLite 資料庫"]
B --> D["模糊語意檢索
ChromaDB 向量庫"]
C -->| 筆記拓撲與對話決策| E["全局脈絡大卷軸
Notebook Scrolls"]
D -->| 檔案切塊與語意比對| E
E -->| 提供給大腦進行全局推理| F("(AI 分身大腦)")
style B fill:#f9f,stroke:#333,stroke-width:2px
style E fill:#bbf,stroke:#333,stroke-width:1px
1. 精準關係索引庫 (SQLite)
我們使用 SQLite 資料庫(llm_wiki_index.db)來解決「精確定位」的問題。
- 解析雙連結:透過 Python 腳本(
rebuild_index.py)定期掃描 LLM Wiki 筆記,將[[雙向連結]]解析出來並記錄在資料庫的 Link 表中,建立起實體與概念之間的物理關聯。 - 引用出處追蹤 (Citations):明確記錄哪篇 Wiki 頁面是由哪份原始文獻所支持,確保 AI 給出的資訊有據可查。
- 對話決策歸檔 (Agent Memories):每次對話結束前,AI 會自動將最終決策(Decisions)、我的習慣偏好(Preferences)以及關鍵技術細節存入 SQLite,防止下次對話時「忘記約定」。
2. 語意相似度檢索庫 (ChromaDB)
我們使用 ChromaDB 作為向量資料庫,負責「模糊查詢與經驗召回」。
- 腳本會將 LLM Wiki 的 Markdown 文件與原始文獻自動切成碎片(Chunks)並進行向量化。
- 當我提出一個含糊的問題(例如:「之前那個鏡面變藍的問題怎麼解?」),系統會自動進行向量比對,將關聯性最高的排障 Wiki 碎片即時塞給 AI 的上下文。
3. NotebookLM 專用大卷軸 (Notebook Scrolls)
當我們需要 AI 進行全局系統分析或撰寫複雜架構時,碎片的向量檢索會讓 AI「只見樹木不見林」。 因此,我們寫了編譯器(notebook_compiler.py),將 LLM Wiki 中的關聯筆記與 SQLite 中的對話決策,自動融合成數個 NOTEBOOK 大卷軸。你可以直接把這些大卷軸上傳至 NotebookLM,讓 AI 在幾秒鐘內讀完你的完整專案脈絡。
四、 關鍵心法:如何打造「不會退化」的記憶?
在建置這套系統時,我也踩過不少坑,以下是三個我認為最重要的實作心法:
💡 心法 1:智能 Markdown 標題分塊
如果你粗暴地以「每 500 字」切碎文件,AI 檢索到代碼片段時,會因為失去標題,根本不知道這段指令是屬於哪一個專案。 我們在切塊時,必須基於 Markdown 的標題(H1/H2/H3)進行語意切分,並在每個碎片最前方自動補上「麵包屑 context」:
Plaintext
Document: Voxel 專案
Section: 公視台語台採購案
Subsection: 字幕機規格測試
-------------------
(實際的測試數據與代碼...)
這能讓 AI 即使拿到的是碎片記憶,也能瞬間恢復全局背景。
💡 心法 2:對話軌跡壓縮(Conversational Compaction)
在關閉任何長對話之前,先引導 AI 助理執行對話壓縮。讓它總結出本輪對話的關鍵決策、代碼修改軌跡與討論日期,自動寫入 SQLite 長期記憶。下次開啟新視窗時,它讀入這些壓縮後的記錄,就能「一秒接軌」之前的狀態。
💡 心法 3:Obsidian 的人機閉環
將 AI 助理工作區的 Wiki 目錄,直接與你的 Obsidian 本地筆記庫進行雙向同步(利用自動化同步腳本 sync_all)。 你在 Obsidian 裡寫下的專案筆記,會自動成為 AI 的大腦養分;而 AI 幫你整理的決策與排障紀錄,也會同步回你的 Obsidian 供你查閱。至此,你與你的 AI 分身,開始共享同一個知識庫。
結語:記憶,是分身與聊天機器人的分水嶺
一個沒有記憶的 AI,充其量只是個拋棄式的「聊天工具」;而一個擁有長期記憶、與你共享 LLM Wiki 知識庫、記住你每一次決策的分身,才開始真正具備「助理」的靈魂。
這套系統讓我的個人助理 Antigravity 不再需要繁瑣的初始化引導。下一篇,我們將進入實戰的下半場:如何讓具備記憶的分身,透過本地工具呼叫(System Calling)真正幫我們自動化執行工作。