EverOS：以 Markdown 為核心的本地優先 AI 記憶層，值得一試嗎？
One portable memory layer for every AI agent: local-first, Markdown-native, user-owned, and self-evolving across apps, tools, and workflows.
秒懂
- 它是什麼？
- EverOS 是一個 Python 函式庫與本地優先的記憶執行環境，承諾讓 AI agent 的記憶可攜、可讀且自主演化。本文剖析其 Markdown 加上 SQLite 與 LanceDB 的架構，並從實際使用角度評估其適用邊界。
- 適合誰用？
- EverOS 適合那些重視記憶可讀性、可攜性與 Git 版本控制的開發者，尤其是同時使用多個 agent 平台（如 DeepSeek Harness、Dify 或自家 Raven）且不願把記憶鎖在單一供應商後端的人。若你的記憶需求僅限於單一 chatbot 的對話歷史，或你的團隊無法接受以 OpenRouter 作為唯一 LLM 入口，則 EverOS 的抽象層反而增加不必要的複雜度。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 7 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
EverOS 要解決的問題：agent 記憶被綁死在單一後端
多數 agent 記憶函式庫把狀態存在 API、向量資料庫或圖形資料庫裡，使用者只能透過 SDK 或儀表板存取。EverOS 的立場很直接：記憶應該是一份可讀、可編輯、可 diff、可放進 Git 的 Markdown 檔案。這個設計讓記憶脫離特定平台的綁定，也讓開發者能直接修改 `.md` 檔，而不必繞過抽象層。
專案的主要對象是那些同時使用多種 coding assistant、app 與 workflow 的 makers，他們需要一個統一的記憶層，而不是每個工具各存一份不相通的歷史。EverOS 強調 user 與 agent 的記憶分軌，使用者側有 `episodes/profile`，agent 側有 `cases/skills`，兩者都是第一等公民，這與一般只記錄對話歷史的函式庫有明顯區別。
三層架構：Markdown 為源頭，SQLite 與 LanceDB 當索引
EverOS 的資料流很明確：對話、檔案與 agent 軌跡先寫成 Markdown，然後同步到本地端的 SQLite 與 LanceDB 索引。SQLite 大概負責結構化查詢，LanceDB 則處理向量檢索。這個三層設計刻意排除了 MongoDB、Elasticsearch 或 Redis，也不需要托管服務，整包都能在本地跑。README 裡提到一個「cascade watcher」，當你直接編輯 `.md` 檔時，它會自動同步索引，這意味著檔案系統是真相來源，資料庫只是加速層。
檢索是正交的，你可以用 `user_id`、`agent_id`、`app_id`、`project_id` 或 `session_id` 任意組合來搜尋，而不是像多數系統那樣被綁在單一 scope（例如 thread 或 tenant）。這種設計對多 agent 協作場景很有用，但也讓索引的維護變得更複雜，因為每個維度都需要正確的 metadata 寫入 Markdown。文件沒有明說 metadata 的格式，實際使用時可能得自己摸索。
從安裝到實際操作：一個 API key 就能起步
安裝指令很直接：`uv pip install everos` 或 `pip install everos`，前提是 Python 3.12 以上。最吸引人的是 `everos demo`，這個指令不需要 API key，也不需要伺服器，就能體驗記憶從 ingest 到 extract、index、recall 的流程。對一個想快速驗證概念的工程師來說，這比讀一堆文件有用得多。
正式使用時，`everos init` 會建立 `~/.everos/everos.toml` 與 `~/.everos/ome.toml`。設定檔裡已經預填了 model 與 base_url，你只需要把空的 `api_key` 換成 OpenRouter 的 key。文件特別強調這是「最小的 Tier 1 設定」，只涵蓋記憶新增、flush、Markdown 持久化、cascade 索引與關鍵字搜尋。之後用 `everos server start` 啟動服務，再用 `curl http://127.0.0.1:8000/health` 檢查狀態。值得注意的是，文件明確指出這個單 key 設定下，`capabilities.llm` 為 true，但 embedding 與 rerank 都是 false，直到你另外設定。
記憶如何自我演化：reflection 機制的承諾與現實
EverOS 最特別的賣點是「reflection」，也就是離線的記憶演化。文件描述它會合併 episode 叢集，並在 session 之間精煉 profile 與 skills。這聽起來像是一個背景程序定期整理記憶，而不是每次查詢時即時處理。這種設計的優點是長期下來記憶會越來越精準，缺點是演化過程對使用者來說不透明。你怎麼知道它合併了哪些 episode？精煉後的 profile 是否真的反映了你的偏好？文件沒有提供任何可視化工具或審計日誌，這對需要除錯的開發者來說是個障礙。
另一個問題是，reflection 依賴 LLM 來做合併與精煉，這意味著它會消耗 API 額度，而且結果品質取決於你設定的模型。如果你用的是免費或低成本的模型，演化品質可能不如預期。文件沒有說明 reflection 的觸發條件，是定時執行還是手動呼叫？這點需要查閱文件或原始碼才能確定，但以目前的資訊來看，這個功能更像是實驗性質。
整合廣度：從 DeepSeek Harness 到 Dify，但 Raven 才是親兒子
EverOS 的整合清單包括 DeepSeek Harness、Hermes、OpenClaw、Dify，以及自家專案 Raven。其中 Raven 被描述為「built into」，也就是 EverOS 直接內建在 Raven 裡，其他平台則需要透過 plugins 目錄下的個別設定指南來串接。這種策略很務實：先讓自家 agent 產品完全支援，再逐步擴展到第三方平台。
但這也暗示了一個風險，如果 EverOS 的維護者把大部分心力放在 Raven 上，其他整合可能更新較慢。以 Dify 為例，它是一個成熟的開源 LLM 應用平台，有自己的記憶與知識庫機制，EverOS 要怎麼與之共存？文件沒有深入說明。對潛在使用者來說，選擇 EverOS 等於接受它與 Raven 的緊密綁定，即使你根本不用 Raven。
真正的限制：OpenRouter 依賴與 embedding 的缺席
EverOS 的快速入門只提到 OpenRouter API key，這表示 LLM 呼叫是透過 OpenRouter 進行的。如果你已經使用其他供應商（例如直接呼叫 OpenAI 或 Anthropic），你得確認 EverOS 是否支援自訂 base_url，文件中的範例是 `https://openrouter.ai/api/v1`，但沒有說死只能用它。然而，既然 README 強調「one OpenRouter API key is enough」，暗示這是最佳路徑，其他供應商可能不在官方支援範圍內。
更明顯的限制是，單 key 設定下 embedding 與 rerank 功能是關閉的。也就是說，你得另外設定 embedding 模型才能做向量檢索，否則只能靠關鍵字搜尋。文件沒有提供這部分的設定範例，也沒有說明支援哪些 embedding 提供者。對於想立刻做 RAG 的人來說，這是一個需要自行填補的坑。如果你的應用場景需要語意搜尋，EverOS 的初期設定成本會比文件暗示的高。
替代方案比較：Mem0 與 Zep 的差異在哪裡
市面上常見的 agent 記憶函式庫如 Mem0 或 Zep，通常把記憶儲存在雲端或自建的向量資料庫，並提供 API 給 agent 呼叫。它們的記憶格式是內部狀態，使用者無法直接編輯，也難以用 Git 做版本控制。EverOS 的切入點正好相反，它以 Markdown 檔案為核心，讓記憶變成一般檔案，你可以用任何編輯器修改，也可以用 Git 追蹤變更。
這個差異對團隊協作影響很大。假設你有一個 agent 的記憶需要人工修正，在 Mem0 裡你得寫程式呼叫 API，在 EverOS 裡你直接開檔案改一行字就好。但代價是，EverOS 的檢索效能可能不如那些專為向量搜尋調校的系統，因為 LanceDB 雖然是本地端，但它的索引更新依賴 cascade watcher，如果檔案很多，同步延遲可能會成為瓶頸。文件沒有提供任何效能數據，這點只能靠實際測試。
維護成本與授權：Apache-2.0 的雙面性
EverOS 採用 Apache-2.0 授權，這對商業使用相對友善，你可以自由修改與再散佈，只要保留著作權聲明。但這也代表專案沒有提供任何官方支援服務，除錯得靠自己或社群。從 GitHub 的活躍度來看，最近一次 push 是 2026 年 9 月，且 v1.3.1 在 2026 年 9 月 8 日發布，顯示開發節奏還算穩定。
升級成本方面，EverOS 的設定檔放在 `~/.everos/`，版本升級時可能不會自動遷移既有記憶。Markdown 檔案本身是純文字，理論上不會因為升級而損壞，但 SQLite 與 LanceDB 的 schema 可能變動，這在 minor version 之間（例如 1.2.3 到 1.3.0）就需要留意。文件沒有提供 migration 指南，這對長期使用者來說是一個潛在的痛點。如果你打算把 EverOS 放進生產環境，務必先測試從舊版匯出 Markdown 再匯入新版的路徑。
編輯結論
EverOS 適合那些重視記憶可讀性、可攜性與 Git 版本控制的開發者，尤其是同時使用多個 agent 平台（如 DeepSeek Harness、Dify 或自家 Raven）且不願把記憶鎖在單一供應商後端的人。若你的記憶需求僅限於單一 chatbot 的對話歷史，或你的團隊無法接受以 OpenRouter 作為唯一 LLM 入口，則 EverOS 的抽象層反而增加不必要的複雜度。採用前應先確認三件事：你的 Python 環境是 3.12 以上，你能接受 Markdown 檔案作為記憶的唯一真相來源（而非資料庫），以及你願意維護一個常駐的 `everos server` 程序。若上述條件皆成立，EverOS 的本地優先設計確實提供了其他記憶函式庫少見的透明性，但若你期待開箱即用的 embedding 與 rerank 功能，則需要自行補上對應的 API 設定，這點在官方文件中並未詳述。
社群筆記