對照熱門自架軟體 Open WebUI、AnythingLLM 的對話與記憶設計，對 Chatmery 的取捨與可改進處做簡要建議。
- 記憶：內建 Memory（beta），兩種模式
- 手動：設定 → 個人化 → Memory，可增刪改。
- 自主：開啟 Native Function Calling 後，模型用工具
add_memory/search_memories/replace_memory_content自己存、查、改記憶。
- 對話：每則對話有歷史，但已知問題是 只存 LLM 回覆，不存 tool 輸出（搜尋結果、API 回傳等），脈絡會缺一塊。
- 社群：如 open-webui-memory 用「抽事實 + 過濾瑣碎」做自動記憶，可搭配本機或遠端模型。
- RAG：文件切 chunk、向量庫，依語意取 4–6 段注入，不整檔塞 context。
- 文件：附檔（僅當前 thread） vs 嵌入（workspace 級、所有 thread 可用）。
- 對話：thread 為單位，附檔跟對話都 thread-scoped；可看當前 context 用量。
- Agent 長期記憶：
agent_memory.txt，Agent 自己寫、用 RAG 讀，但何時寫入、如何檢索、能否關閉等文件較少。
| 項目 | 說明 |
|---|---|
| 四池一魂 | 當前→短期→長期→核心→靈魂，滿池濃縮、靈魂單檔成長，階層清楚、可解釋，和「只做向量檢索」或「只做一層記憶」的產品有明顯區隔。 |
| 答覆注入固定 | 當前 1 + 靈魂 1 + 核心 2 + 長期 3 + 短期 5，token 用量可預估，不會因「塞滿整段歷史」爆窗。 |
| 知識庫分離 | 知識庫（RAG + 摘要 + 存檔）與「記憶」分開，附檔／網頁／本機讀檔也獨立區塊，脈絡清楚。 |
| 全檔案、可編輯 | SOUL.md、MEMORY.md、memory/*.jsonl、knowledge/ 都是檔，可手動改、可備份、可版控，符合「自架、可控」需求。 |
| 無需額外服務 | 記憶與知識庫可純關鍵字；embed 為選配，不必綁死向量庫或雲端。 |
-
近期輪次可調
- 現況：最近 20 輪寫死在程式裡。
- 建議：改成 config / tuning（例如
CHATMERY_RECENT_TURNS=20），讓重對話型可調高、省 token 型可調低。
-
Tool 輸出也進「可被記住的脈絡」
- Open WebUI 的問題是只存 LLM 回覆、不存 tool 輸出。
- Chatmery 的「即時搜尋結果」「附檔內容」目前只當輪注入，解構濃縮時若只送「使用者＋助手」原文，搜尋結果與附檔就不會進短期／長期。
- 建議：解構／濃縮的輸入可選包含「本輪附檔摘要」或「本輪網搜摘要」（例如一行描述），讓「因為搜到 X 所以回答了 Y」能被記住，而不是只記「回答了 Y」。
-
（選配）多對話 thread
- AnythingLLM / Open WebUI 都有「多對話」或 workspace 內多 thread。
- Chatmery 目前是單一 recentTurns，一 workspace 一脈絡。若未來要「多主題／多專案」並存，可考慮：
- 對話列表 + 每則對話有 ID，
- 記憶仍可 global（同一靈魂／池），或可選「此 thread 專用短期池」（實作成本較高，可列為後期）。
-
「這輪用了哪些記憶」可視
- 建議：在 API 或 UI 可選回傳「本輪注入的 [當前/靈魂/核心/長期/短期] 條目」或至少條數，方便除錯與理解「模型是根據什麼在回」。Open WebUI / AnythingLLM 的 RAG 常會標「用了哪幾段文件」，記憶區塊也可以類似。
-
靈魂／長期的手動編輯
- 已有：SOUL.md、MEMORY.md 是檔，可手動改。
- 可加強：在 doc 或 UI 註明「改 SOUL.md 會直接影響身份與偏好」「長期池在 memory/long_term.jsonl」，減少「不知道要改哪個檔」的門檻。
-
關閉或清空某一層
- 建議：tuning 或環境變數可關閉「自動解構進短期」或「自動濃縮進長期」（例如僅用靈魂 + 知識庫），方便只想「輕量對話」的使用情境。
-
知識庫 vs 記憶
- 現況：知識庫 = 我的閱讀材料（檢索注入）；記憶 = 四池一魂（對話濃縮）。邊界清楚。
- 建議保持：不要讓「知識庫內容」自動寫進靈魂或長期池，除非使用者明確說「把這段加入記憶」並由你實作對應意圖。
-
檢索結果一併存進脈絡（選配）
- 若希望「這次搜到什麼」也能被之後的記憶檢索用到，可在解構／濃縮時把「本輪即時區塊的簡短摘要」當成一句事實寫進短期（同上 3.1）。
-
文件對齊
記憶模式—設計對齊.md寫「最近 10 輪」；程式為 20 輪。建議文件改為 20，或改為「由 config 決定」並在 doc 寫出 key。
-
預設與範例
chatmery.tuning.example已含記憶／提煉／知識庫等鍵，建議在 README 或 doc 加一節「對話與記憶」：近期輪次、四池一魂、知識庫各負責什麼、哪些 key 會影響行為，方便和 Open WebUI / AnythingLLM 對照取捨。
| 優先 | 建議 | 理由 |
|---|---|---|
| 高 | 近期輪次可配置（如 CHATMERY_RECENT_TURNS） |
實作小、影響大，兼顧省 token 與長對話。 |
| 高 | 解構／濃縮時納入「本輪附檔／網搜摘要」 | 與 Open WebUI 的教訓對齊，避免「只記得回覆、不記得依據」。 |
| 中 | 回傳或標示「本輪注入的記憶條目」 | 可解釋性、除錯、與他家的「用了哪幾段 RAG」對齊。 |
| 中 | 文件：20 輪、config key、記憶 vs 知識庫 | 降低誤解、方便自架用戶對照。 |
| 低 | 可選關閉自動寫入短期／長期 | 滿足「只要靈魂+知識庫」的輕量用法。 |
| 低 | 多 thread／多對話 | 產品差異化可之後再評估。 |
整體而言，Chatmery 的四池一魂 + 固定注入 + 全檔案已經在「可解釋、可手動、可自架」上比多數產品清楚；對照 Open WebUI、AnythingLLM 後，最值得先做的是近期輪次可調與把本輪 tool/附檔脈絡納入解構，其餘再依使用情境逐步補上。
以下為目前影響「對話＋記憶」行為的設定（chatmery.tuning 或環境變數），方便與他家對照。
| 鍵 | 說明 | 預設 |
|---|---|---|
| CHATMERY_RECENT_TURNS | 送進模型的近期對話輪次上限（1–100） | 20 |
| CHATMERY_MEMORY_AUTO_SHORT | 是否每 20 輪濃縮 1 句進短期 | true |
| CHATMERY_MEMORY_AUTO_LONG | 短期滿時是否濃縮進長期→核心→靈魂 | true |
| CHATMERY_MEMORY_LONG_K / SESSION_K / CORE_K / SHORT_K | 答覆時各階層注入條數 | 3 / 5 / 2 / 5 |
| CHATMERY_REFINE_ROLLOVER / BATCH_MAX / RUNES_PER_ITEM | 短期滿時提煉進長期的觸發與批次 | 20 / 15 / 120 |
記憶 vs 知識庫邊界：記憶＝四池一魂（由對話解構／濃縮產生，SOUL.md、memory/*.jsonl）；知識庫＝使用者主動攝入的閱讀材料（knowledge/chunks.jsonl、summary.md、archives/）。答覆時兩者皆注入 prompt，但寫入來源與時機分開：記憶由系統依輪次自動寫入，知識庫由使用者「加入知識庫」或附檔勾選寫入。