【2026 最新】Lemmalog 教學：用 Datalog 建立可撤回、可追溯的 AI 記憶（MCP 實作）

Lemmalog 教學真正要解的，不是「AI 能不能找回昨天的筆記」，而是更麻煩的一題：如果昨天的前提今天被推翻，所有依賴它的結論會不會一起失效？安全研究員 Jordy Zomer 在 2026 年 8 月 28 日公開方法文章後，相關 Hacker News 討論於台灣時間 8 月 29 日出現，至 8 月 31 日已累積 299 points、82 則留言，大家追問的正是 Datalog、事實更新與長任務記憶怎麼落地。

這篇專為第一次接觸 Datalog 與 MCP 的讀者寫。我們會先用白話拆開 fact、rule、derived fact、provenance 與 retraction，再鎖定官方程式碼 commit，編譯本機 MCP、接上 Claude Code，最後用 6 筆觀察驗收「新增 → 推導 → 更新 → 追溯」。你不需要先會資料庫理論，但需要一個可丟棄的測試資料夾，以及已安裝的 Git、Rust／Cargo 與 Claude Code。

先說結論：Lemmalog 教學的核心不是「記更多」

• 向量檢索回答「哪段舊資料相關」；Lemmalog 維護「在已接受的 facts 與 rules 下，哪些結論目前仍有支持」。兩者處理的是不同問題，也可以一起用。
• 最小心智模型只有五個零件：事實、規則、推導事實、來源證明、撤回／更新。
• 可追溯不等於一定正確。why能回答一個結論由哪些 facts 與 rules 推出，卻不會替你判斷輸入觀察是否看錯。
• 截至 2026 年 8 月 31 日，它仍是很新的開源專案，Cargo.toml套件版本為 0.1.0。作者回報的兩組對話記憶評測都由 PropMem 領先；目前證據支持「值得做小型驗收」，不支持把它當成所有 Agent 記憶的標準答案。

Lemmalog ＝ 結構化事實 ＋ 推導規則 ＋ 依賴證明；前提失去支持，依賴它的結論就重新計算。

Lemmalog 是什麼？把 Agent memory 當成「會重算的帳本」

Lemmalog 是一個以 Rust 寫成的 Datalog 引擎，官方把它定位為 LLM Agent memory 的 deductive database（演繹式資料庫）。Datalog可以先理解成「用 facts 與 rules 查出必然結果的資料庫語言」：LLM 負責把自然語言、程式碼或除錯輸出轉成結構化觀察，Lemmalog 再負責固定點推導、依賴維護與查詢。

日常比喻是會自動重算的試算表。儲存格 A、B 是輸入，C 是公式；A 改了，C 不該繼續保留舊答案。Lemmalog 多做一步：它還記得 C 用了 A、B 和哪條規則，所以你能問「為什麼相信 C？」作者的方法文章把這個需求稱為維護「目前知道什麼」，而不只是把過去對話找回來。

這和 RAG／向量檢索不是二選一。純檢索很適合找「之前談過哪段配置」；推導狀態適合回答「某個前提更新後，哪些結論仍成立」。作者目前的管線也把 BM25、entity／graph boost、原始片段與 deductive state 組在一起。

先學會 Lemmalog 的 5 個零件

① Fact：「目前收進帳本的觀察」

Fact 是結構化輸入，例如 alex --works_at--> acme。它不是宇宙真理，只表示系統接受了一筆觀察。Lemmalog 的 MCP line protocol 讓每次 observation call 帶時間與來源 episode，之後的 proof tree 才有路可回。

② Rule：「如果 A 與 B 成立，就推出 C」

Rule 是可重複執行的判斷式，例如「某人任職的公司擁有實驗室，而且他有該實驗室門禁，就能接觸裡面的服務」。規則和 Prompt 最大差別，是相同輸入會走相同推導；它不靠模型每次重新讀一遍長對話再猜。

③ Derived fact：「公式算出的結果」

Derived fact 不是手動寫入，而是 facts 滿足 rule 後產生的結論。這個區分很重要：當輸入更新時，你不需要自己刪除每一個下游句子，系統會依賴關係重新維護結果。

④ Provenance：「這個結論從哪裡來？」

lemmalog_why會展開 proof tree，列出支持一個 derived fact 的規則與 episode。白話說，它是「計算過程的收據」。收據能證明推導鏈存在，不能替來源背書；如果 extractor 把原文看錯，proof tree 只會忠實解釋錯誤輸入如何一路傳下去。

⑤ Retraction／update：「前提改了，修復 closure」

同一個結論可能有兩條支持路徑。撤掉其中一條時，另一條仍在，結論就應保留；只有全部支持都失效，結論才消失。這是資料庫增量維護與 truth maintenance 長期研究的題目，Lemmalog 是把既有方法組進 Agent memory，而不是憑空發明一套新邏輯。

Lemmalog 教學第 1 步：鎖定 Commit、測試、編譯 MCP

本文鎖定官方 commit 7d6f1541130aba53949a2da90cc3e134cb0aac01。這樣做不是追求「永遠最新」，而是讓你今天複製的指令、工具名稱與本文相同。先在拋棄式資料夾檢查環境；若 cargo尚未安裝，從 Rust 官方安裝頁選擇你的作業系統做法。

git --version
cargo --version
claude --version

git clone https://github.com/JordyZomer/lemmalog.git
cd lemmalog
git checkout --detach 7d6f1541130aba53949a2da90cc3e134cb0aac01
git show -s --format='%H %cI'

cargo test --locked
cargo build --release --locked --features mcp

Cargo 官方文件說明 --release會使用最佳化 profile，--features mcp則啟用專案在 Cargo.toml宣告的 MCP binary。建置完成後，預期檔案是 target/release/lemmalog-mcp。若測試或編譯失敗，就停在這裡讀錯誤，不要改用來路不明的預編譯檔繞過。

Lemmalog 教學第 2 步：透過 MCP 接到 Claude Code

Claude Code 的官方 MCP 文件把本機 stdio server 定義為由 Claude Code 啟動的 local process，指令與參數要放在雙破折號 --之後。以下使用 local scope，避免把你電腦的絕對路徑寫進團隊 Git：

LEMMALOG_BIN="$PWD/target/release/lemmalog-mcp"
LEMMALOG_SNAPSHOT="$PWD/.lemmalog-lab.snapshot"

if [ -e "$LEMMALOG_SNAPSHOT" ]; then
  echo "Snapshot already exists; choose a fresh test folder." >&2
  exit 1
fi

claude mcp add --scope local \
  --env LEMMALOG_MCP_PATH="$LEMMALOG_SNAPSHOT" \
  --transport stdio lemmalog -- "$LEMMALOG_BIN"

claude mcp get lemmalog
claude mcp list

LEMMALOG_MCP_PATH會讓 server 在成功的 lemmalog_observe、lemmalog_install_rules、lemmalog_uninstall與lemmalog_canonicalize call 後嘗試寫入 snapshot；請先確認路徑可寫。本文鎖定 commit 有一個重要限制：透過 MCP 動態安裝的 rule batch 不會寫進 snapshot。Base facts、episode 與時鐘會保存，derived facts 不直接保存；server 重啟後要先重裝本文兩條規則，才能從 base facts 重建 can_access與high_risk。測試檔留在隔離資料夾，別加入版本控制。若 claude mcp list顯示連線失敗，先核對 binary 絕對路徑與執行權限，再進 Claude Code 用 /mcp看詳細狀態。

本文以 commit 內 tools()原始碼為準，會用到 lemmalog_observe、lemmalog_install_rules、lemmalog_query與lemmalog_why。官方 README 的工具總數文字和該 commit 的實際清單不同，因此不要用「數量對不對」判斷連線；直接確認這四個名稱是否可見。

Lemmalog 教學第 3 步：用 6 筆觀察推導一個結論

現在做一個能判分的小題。情境是：Alex 任職的公司擁有一間實驗室，他有門禁，實驗室裡有 critical 服務，而且 review 把 Alex 列為候選人。把下面整段貼進已連好 MCP 的 Claude Code，要求它逐步回傳原始工具結果：

請只用 lemmalog MCP 依序完成，不要自行補 facts：

1. 呼叫 lemmalog_observe，ts=100，facts 完全照抄：
alex --works_at--> acme
acme --owns--> red_lab
red_lab --hosts--> payment_api
alex --has_badge--> red_lab
payment_api --status--> critical
review --candidate--> alex

2. 呼叫 lemmalog_install_rules，rules 完全照抄：
can_access(P,S) :- current(P,"works_at",C), current(C,"owns",L), current(P,"has_badge",L), current(L,"hosts",S).
high_risk(P) :- can_access(P,S), current(S,"status","critical"), current("review","candidate",P).

3. 呼叫 lemmalog_query，goal 是 high_risk(P)
4. 呼叫 lemmalog_why，fact 是 high_risk(alex)
5. 逐步列出工具原始輸出，不要只寫摘要。

在上一步建立的全新 snapshot、四個 tool call 都成功時，驗收點很明確：observe 報告應顯示 6 筆新增；query 應出現 P=alex；why tree 應一路連回規則與 episode ID。這一段在測「有支持時能否推出結論」，不是請 Claude 用常識判斷 Alex 是否真的危險。

Lemmalog 教學第 4 步：更新關鍵前提，再用 why 驗收

目前 commit 的預設規則把 works_at列為 exclusive relation。同一 subject 出現新的 employer 時，update policy 會關閉舊 fact 的 current validity interval、留下已閉合的歷史 edge，再重新維護依賴它的 derived facts。接著貼上：

請繼續只用 lemmalog MCP：

1. 呼叫 lemmalog_observe，ts=200，facts 是：
alex --works_at--> beta

2. 呼叫 lemmalog_query，goal 是 current("alex","works_at",Employer)
3. 呼叫 lemmalog_query，goal 是 high_risk(P)
4. 呼叫 lemmalog_why，fact 是 high_risk(alex)
5. 逐步列出工具原始輸出。

第二輪的判分標準是：目前 employer 變成 beta；high_risk(P)回到 (no answers)；舊結論的 why 結果標示 [unknown fact]。注意，這裡不是手動刪掉 high_risk，而是它失去唯一支持路徑後不再出現在 maintained state。

想看 literal retraction？跑官方 investigation example

上面的 MCP 路徑示範 temporal supersession。若要看底層 Engine::retract逐筆撤回 foundational observations，官方已在 examples/investigation.rs準備完整範例：

cargo run --release --locked --example investigation

它會先為 exploit decision 印出 proof tree，再撤回兩筆 target-mapping evidence、執行 maintenance，最後核對依賴該 mapping 的 decision 與 exploit viability 消失，而擁有獨立 evidence 的 hypothesis 仍保留。這正是「一條支持消失」與「所有支持消失」的差別。

向量記憶、Full Context、Lemmalog 怎麼選？

• 選向量／RAG：你的主要問題是從大量舊文字找出語意相關片段，答案仍需要原文細節與模糊語境。
• 選 Full Context 做基線：資料量仍放得下，而且你要先知道「完全不做外部 memory」的表現。它適合當比較組，不代表長任務一定可靠。
• 試 Lemmalog：任務有反覆使用的關係規則、狀態更新、互相依賴的假設，而且你需要問 why。
• 實務上常是混合：用 deductive state 保存可計算關係，用 episodic／vector memory 保留語氣、條件與原始片段。這也和 Semantica Context Graph的 evidence lineage，以及 OpenViking Memory A/B 驗收形成很好的對照。

作者 benchmark 怎麼讀？先看它沒證明什麼

作者在 2026 年 8 月 28 日方法文章與本文鎖定 commit 所報的管線，於 102 題 stratified LongMemEval subset 與完整 LoCoMo 對話 QA 上各跑三次。結果顯示 Lemmalog 在部分知識更新、時間與 false-premise 題型有亮點，但整體仍由 PropMem 領先；LongMemEval 上也低於 SimpleMem。下圖只整理作者回報的 overall F1，不是 AlphaLab 本機重現。

更關鍵的限制有三個。第一，102 題每類只有 17 題，而且作者看過錯題後調整 extraction、refusal、stemming、count 與日期處理，同一評測集上的進步較像 development-set performance。第二，三次 run 的 extraction 使用 cache，所以 ±數字不是完整端到端信賴區間。第三，整套管線同時包含 Datalog、BM25、embedding、entity reconciliation 與 Prompt 政策；截至本文鎖定 commit 的 README 與公開結果未見 isolating ablation，因此無法把全部增益單獨歸因於 Datalog。

因此，最實用的做法不是抄排行榜，而是替自己的任務固定 10～20 題：同一批 facts，同一批更新，分別跑 Full Context 與 Lemmalog，記錄答案是否仍引用失效前提、why 能否回到原始 episode、輸入 context 大小與 extraction 漏失。這和 Context 壓縮的 reacquisition cost一樣，只有固定題目與判分標準，輸入量比較才有意義。

5 個常見坑：推理引擎正確，不代表記憶就完整

1. Extractor 漏掉關鍵事實。症狀是 query 找不到答案，但原文其實有寫。解法不是加更多 rules，而是核對 observe 的 added／dropped 報告與來源 episode。
2. 把兩個名字當成兩個 entity。Honda Civic、the car與Civic如果未 reconciliation，推導鏈會斷。先用小題檢查 entity naming，再考慮 lemmalog_canonicalize。
3. 把 provenance 當成真值。Proof tree 只說「從何推得」，不說 evidence 是否可信。每個關鍵 base fact 仍要有可回看的來源錨點。
4. 規則寫得比需求更廣。一條過度泛化 rule 會產生大量看似合理的 derived facts。每個 rule batch 只測一個假設，先 query、why，再決定是否保留。
5. 只看 overall 分數。你的任務若重視 multi-session synthesis，作者的 LongMemEval 分類結果明顯比 knowledge update 弱；應按自己的失敗成本配題，而不是用單一 F1 決定採用。

Lemmalog 常見問題 FAQ

1. Lemmalog 會取代向量資料庫嗎？

不需要二選一。向量檢索負責找相關 episode，Datalog state 負責維護明確 facts、rules 與依賴。作者目前的架構本身就是 hybrid。

2. 完全不會 Rust，也能跟完這篇 Lemmalog 教學嗎？

可以完成編譯與 MCP 操作。你只需照官方 Cargo 指令建置，實驗主要在 Claude Code 呼叫 tools；只有 literal Engine::retract範例需要閱讀少量 Rust。

3. why能證明答案是真的嗎？

不能。它證明的是目前知識庫內的推導支持。Base fact 若來自誤讀，proof tree 仍可能結構完整，所以要回到 episode 與原始 evidence 核對。

4. Query 沒答案，代表現實中為假嗎？

不代表。(no answers)只表示在目前接受的 facts 與 rules 下沒有支持；也可能是 extractor 漏掉資訊、entity 未對齊或 rule 尚未涵蓋。

5. 為什麼範例更新 works_at，而不是任意刪除 fact？

因為這是本文採用的可觀察知識更新路徑。本文鎖定 commit 的工具清單沒有任意刪除 base fact 的 lemmalog_retract；default rules 則明確把 works_at設為 exclusive，因此能用新 employer 觸發 supersession。底層逐筆 retraction 由官方 investigation example 示範。

6. Snapshot 可以直接放進 Git 嗎？

不要把本文測試 snapshot 納入版本控制。它可能包含 base facts、來源 episode、時鐘與 escalation；而且本文鎖定版本不會可靠保存透過 MCP 動態安裝的 rule batch。請把規則文字另外版本化，server 重啟後重新安裝，再從保存的 base facts 重建結論。

7. 作者 benchmark 能證明漏洞研究更有效嗎？

不能外推到這一步。公開評測是對話記憶 QA；作者也把長時間漏洞調查列為下一個真正想做的實驗，而非已完成驗證。

8. 什麼任務最適合先試？

規則清楚、狀態會更新、錯用舊前提代價高的小任務。例如除錯假設、資安調查候選鏈、需求依賴或多 Agent evidence ledger；先做 10～20 題驗收，再決定是否擴大。

給新手的 5 個重點

• 把 Agent memory 分成「找相關資料」與「維護目前支持狀態」兩題。
• 鎖定 commit、跑測試、從本機 source build，不猜工具名稱。
• 先用 6 筆 facts 跑通 query 與 why，再談長任務。
• 更新前先保存 proof tree，更新後同時驗收 query 與 why。
• 把 benchmark 當成題庫設計參考，不把作者 overall F1 當成自己的成效。