15 億人的盲區——中文 AI Agent 記憶為什麼還沒有 canonical 方案

先看一組數字：

• CJK（中文 / 日文 / 韓文）使用者：全球 15 億，佔全球人口近 20%
• 主流英文 OSS AI agent memory 把 CJK 當 first-class feature 的：0 個

我一開始查的英文圈專案：mem0、Zep / Graphiti、LangMem、memweave、EchoVault、Eve Memory。六個之中沒有一個把中文斷詞 / CJK 檢索當 day-one 需求。他們不是忽視——他們根本沒意識到這是問題。

但查完中文圈之後，故事更立體。這篇寫我看到的全景、以及為什麼 Memory Hall 仍然填補了一個精確的空位。

為什麼英文 AI 圈看不見這個缺口

X / HackerNews / Reddit 上近 6 個月幾乎沒有人抱怨 AI memory 的 CJK 支援問題。但不是因為問題不存在——是因為在英文社群發聲的人不需要它。

SaaS memory 架構預設是 unicode61 tokenizer 或類似——把一整串無空白中文當一個 token。substring 搜不到、短 query 全 miss、中文 BM25 常態是 0。華文開發者的體感是「這個工具對中文就是爛」，但對英文使用者完全無感。

結果：華文 dev 圈的抱怨沒辦法傳到英文 OSS 維護者的雷達上。英文 OSS 維護者沒動機修。這個市場缺口就這樣一直存在。

中文圈其實有人在做

查完簡中生態後我修正自己的說法。中文圈對 agent memory 的討論非常熱：

• MemOS（上海記憶張量科技 + SJTU / RUC / PKU 聯合）：7100+ stars、v2.0.9。定位是「記憶作業系統」——記憶調度、知識圖譜、時序推理。benchmark 很強（LoCoMo 75.80 分，+43.70% vs OpenAI Memory）
• OpenClaw（AI 龍蝦）：完整 agent framework，自帶 MEMORY.md + sqlite-vec
• TiMem（學術系）：benchmark 最強（LoCoMo 75.30%、LongMemEval-S 76.88%），但工程化程度低
• 還有 Qwen-Agent 生態、Dify 內建記憶、Mem0 + LangGraph 的流行組合
• 知乎 / CSDN / 掘金 大量教學「用 SQLite + sqlite-vec + FTS 自己刻」的文章

所以「第一個做 CJK agent memory」這個 claim 站不住腳。已經有人做了，只是做的是不同的東西。

同一個 niche 已經有鄰居

坦白講：Memory Hall 不是第一個踩這個位的。

2026 Q1 同時有兩個獨立 OSS 走類似組合：

• engram-rs（Rust，2026-02 開工）：BM25 + jieba + 時間軸記憶 decay + 空間軸 topic tree + hybrid search
• robotmem/robotmem（Python，2026-03 開工）：SQLite + FTS5 + vec0 + jieba + MCP server + spatial retrieval，主打 AI robots

兩個都有 jieba CJK + 本地 + FTS5/vec0 的等價骨架。

還有：

• MemOS（上海記憶張量，7100+ stars）：CJK 是隱性透過 Qwen3 / SiliconFlow embedder 處理，不在 storage 層；是「記憶作業系統」的抽象
• OpenClaw（中文圈超紅 agent framework）：有自己的 MEMORY.md + sqlite-vec，但它是 framework，不是 memory library
• 四大雲廠商（阿里 / 字節 / 騰訊 / 百度 / 華為）Agent Memory SKU：全部 managed service，沒有一家提供可 self-host 的記憶層函式庫
• Gitee 獨立 OSS：有 jieba、有 sqlite-vec 單項，但還沒有公開可 fork 的整合 memory library

Memory Hall 的選擇：往下縮回極簡

engram-rs 和 robotmem 選擇往上長功能——decay / promotion / topic tree / spatial retrieval / MCP server。他們有意見，而且 bake 進設計。

Memory Hall 選擇往下縮回最小可用：

• 沒有 decay：entry 寫進來是什麼就是什麼，agent 自己決定怎麼用
• 沒有 topic tree / spatial：不做結構化記憶，留給上層去組織
• 沒有 MCP server：你想接就自己做 wrapper
• 沒有 auth：放你自己的 gateway
• 沒有 enrichment worker：LLM-based fact extraction 在 Memory Hall 外面做

換句話說：如果你要進階記憶結構，選 engram-rs（Rust）或 robotmem（Python + robots）；如果你要一個最小可用、故意不長成平台、你有意見自己加的 engine，選 Memory Hall。

這個 niche 有三個並存的選項，我不覺得要互相取代。選哪個看你的 use case。

Memory Hall 跟 MemOS / OpenClaw / Mem0 系的關係

• MemOS 做「記憶作業系統」——比 Memory Hall 高一層抽象。你如果要進階記憶調度、KG、時序推理，用 MemOS。Memory Hall 可以當它的簡化替代、或獨立給其他 agent stack 用
• OpenClaw 是完整的 agent framework。你可以同時用——OpenClaw 當框架，Memory Hall 當它的記憶後端
• Mem0 / Zep / LangMem：偏 SaaS 或 Python library。Memory Hall 是 standalone engine，跟它們屬於不同部署模型

不是取代誰，是一個「故意不長成平台」的選項。對繁中圈、海外華人、東南亞華語區 dev 來說——這個位置特別自由，因為 engine 沒有 opinionated 結構，你要怎麼組裝自己決定。

這在技術上長怎樣

具體實作：

• FTS5 index 寫入前，content / summary / tags 先過 jieba 預切詞，以空白分隔的 token 塞進 FTS
• 查詢路徑同樣 jieba 切詞後送 FTS MATCH，對稱處理
• 加了 bigram fallback 防止 jieba 在 proper noun / 網路用語切太細
• 提供 mh reindex-fts CLI，舊資料可無痛升級

效果：pure-CJK query「撞牆」BM25 score 從 v0.1 的 0（unicode61）→ v0.2 的 0.26（jieba pre-tokenize）。

為什麼是現在

2026 年 Q1 同時有三個獨立 OSS 專案（memweave、EchoVault、Memory Hall）在英文圈收斂到「SQLite + sqlite-vec + Ollama + Apache 2.0」這個 stack。獨立趨同是市場訊號：這個 niche 的需求是真的，不是某一個 project 的幻覺。

memweave + EchoVault 驗證了「本地優先 AI memory」是真需求。 Memory Hall 接下來要驗證的是「中文優先 AI memory 在英文 OSS 語境是不是也值得存在」。

同時，中文圈的 MemOS / OpenClaw / Mem0+LangGraph 流行意味著中國開發者也在積極找解法——只是他們找到的方案各自綁生態。Memory Hall 存在的價值是給想要中立、輕量、跨生態的那群人一個選項。

給華文 AI 開發者的邀請

如果你符合以下之一：

• 做中文 AI 助理 / agent / 客服 bot
• 現有 RAG stack 的中文 recall 卡住
• 在台 / 港 / 海外華人 / 日 / 韓 / 東南亞，想要不綁中國雲生態的 OSS 選項
• 覺得 MemOS 太重、OpenClaw 太 framework-heavy、Mem0 太 SaaS——想要一個專注的 memory engine

我邀請你試用 Memory Hall（Apache 2.0）：

git clone https://github.com/MakiDevelop/memory-hall
cd memory-hall && docker compose up -d

project 才 48 小時，下一步走哪還沒定。你的 issue、你的 fork 改動會直接告訴我方向。