ZenBrain Memory

ai.zensation由 zensation.ai 發布v0.3.1更新於 Nov 3, 2026

Agent memory: working, episodic, semantic, procedural and core layers. Local SQLite, no account.

發布方自己的服務：Memory.fit

已驗證STDIO僅桌面資料庫知識與記憶

服務詳細資訊

識別碼: ai.zensation/zenbrain
傳輸: STDIO
執行環境: Desktop only
信任: Verified
發布於: Sep 16, 2026

安全提示

MCP 服務會接收對話中的工具呼叫請求，並可能執行外部操作。啟用前請先了解該服務能做什麼，並只授予它所需的權限。

註冊中心已驗證此服務的命名空間屬於 zensation.ai。它以軟體包形式執行，而不是託管端點，因此沒有可與該網域比對的端點。

SourceWeft 的檢查只涵蓋條目是否完整、端點是否回應；不審查伺服器的程式碼，也不審查其工具的行為。

在 README 中新增徽章

向讀者展示該 MCP 服務已收錄於 SourceWeft，徽章連結到本頁。

[![Listed on SourceWeft](https://sourceweft.com/badge/mcp/ai.zensation%2Fzenbrain.svg)](https://sourceweft.com/mcp/ai.zensation%2Fzenbrain?utm_source=readme&utm_medium=badge)

概覽

AI 產生的概覽

本機 MCP 伺服器，為助理提供跨對話持久的分層長期記憶，資料存於單一 SQLite 檔案，不需帳號也不連網。

可以做什麼: 寫入新記憶，並依內容自動歸入程序性、情境、語意或核心層
依查詢跨層檢索記憶，回傳附分數與 id 的結果
依 id 與層永久刪除某筆記憶，連同整併時與它關聯的內容
執行一次整併，把情緒權重高的情境轉為事實，並讓工作記憶衰減
以唯讀方式查看各記憶層的使用情況
適用情境: 適合希望助理在同一台機器上跨多次對話記住事實、流程與過往經驗，又不想使用託管記憶服務的情境。適用於單一使用者的本機環境，且能接受以一般檔案形式保存資料。
執行需求: 需要 Node.js 22 或更新版本；以 npm 套件 @zensation/mcp 安裝並透過 stdio 在本機執行。需將 ZENBRAIN_DB 設為絕對路徑或以 ~/ 開頭的路徑，因為相對路徑可能落在用戶端無法寫入的目錄。不需帳號、API 金鑰或網路存取。

安裝前請注意

SQLite 儲存是未加密的一般檔案，應放在類似筆記本的私密位置。zenbrain_forget 會永久刪除記憶及整併關聯內容，無法復原；zenbrain_consolidate 也被標示為破壞性操作，因為它會清除已衰減的工作記憶槽位。除非在程式庫中設定嵌入提供者，檢索是依字面而非語意。

安裝

在 SourceWeft 中

開啟儀表板中的 ZenBrain Memory，將其新增到工作區。
為需要使用其工具的對話啟用該服務。

Desktop only，透過 STDIO。 STDIO 服務會啟動本機處理程序，因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照儲存庫中的啟動說明。

README

@zensation/mcp

Status: early release. The tool surface is small on purpose and may still change before 1.0. The memory layers underneath it are the same ones the ZenBrain paper describes and the benchmarks measure.

An MCP server that gives any MCP client — Claude Desktop, Claude Code, Cursor, or your own — a memory that survives the conversation.

Five tools, one local SQLite file, no account and no network call.

Tool	What it does
`zenbrain_store`	Write something into long-term memory. Routing is automatic, first match wins: `steps` or wording such as "How to", "Steps:", "workflow:" make a procedure, an emotional weight above 0.5 an episode, a confidence above 0.9 a pinned core memory, anything else a semantic fact. Each call adds a memory; the same core memory stored again is updated.
`zenbrain_recall`	Search the episodic, semantic, procedural and core layers for what is relevant to a query; working memory only when you name it. Results come back sorted by a score from 0 to 1, each with its id and the layer it came from; a layer in which nothing matches returns recent episodes and facts, or its most successful procedures, at score 0, behind every hit, and `minScore` above 0 leaves them out. Every core block scores 0.5 or 0.8.
`zenbrain_forget`	Delete a memory for good, by the id and layer `zenbrain_recall` returned, together with what consolidation linked to it: forgetting an episode deletes the fact made from it, forgetting such a fact every episode consolidated into it, and both delete the working-memory copies of that content. `alsoForgotten` lists what went with it. A memory stored on its own and never consolidated keeps its long-term entry (`duplicates` on a recall result names such copies); forget a long-term result rather than a working-memory slot, which is only a copy. To correct a memory, forget it and store the corrected version.
`zenbrain_consolidate`	One maintenance pass: among the 100 most recent episodes, each with an emotional weight above 0.5 becomes a semantic fact, only once; working-memory slots decay, and those at a relevance of 0.01 or below are removed. Deletes nothing from long-term memory.
`zenbrain_health`	How full each layer is: slots in use, episodes, facts and how many are due for review, procedures, core blocks.

Each tool also tells the client what it does to the store, through the MCP tool annotations: zenbrain_recall and zenbrain_health are read-only; zenbrain_store only adds; zenbrain_forget and zenbrain_consolidate are marked destructive (consolidation removes decayed working-memory slots), so a client that asks before destructive calls asks before these two. No tool reaches anything outside the local file.

Install

Requires Node.js 22 or newer.

Configure your client

json

{  "mcpServers": {    "zenbrain": {      "command": "npx",      "args": ["-y", "@zensation/mcp"],      "env": {        "ZENBRAIN_DB": "~/.zenbrain/memory.db"      }    }  }}

{  "mcpServers": {    "zenbrain": {      "command": "npx",      "args": ["-y", "@zensation/mcp"],      "env": {        "ZENBRAIN_DB": "~/.zenbrain/memory.db"      }    }  }}

Variable	Default	Meaning
`ZENBRAIN_DB`	`./zenbrain.db`	Path to the SQLite file. A leading `~/` means your home directory. A relative path is relative to the directory your client starts the server in — some clients, Claude Desktop among them, may start it in `/`, where nothing can be written — so give an absolute or `~/` path. `:memory:` gives a store that is discarded when the process exits. A value that is only an unfilled placeholder such as `${user_config.db_path}`, which a host may pass on when it does not fill in plugin settings, counts as `~/.zenbrain/memory.db`; the server says so on stderr.
`ZENBRAIN_CONTEXTS`	`personal,work,learning,creative`	Comma-separated context domains, passed to the cross-context layer. None of the five tools uses that layer yet, so the value currently has no effect.

The server speaks MCP over stdio. Stdout carries protocol traffic only; diagnostics go to stderr.

In Claude Code, one line does the same with the memory in ~/.zenbrain/memory.db:

bash

claude mcp add --scope user zenbrain -e ZENBRAIN_DB=~/.zenbrain/memory.db -- npx -y @zensation/mcp

claude mcp add --scope user zenbrain -e ZENBRAIN_DB=~/.zenbrain/memory.db -- npx -y @zensation/mcp

or install the Claude Code plugin, which runs this server at a pinned version, keeps the memory in the same file and lets you choose another (db_path):

The seven layers

Storing is not filing. Which layer a memory lands in decides how it is retrieved and what consolidation does with it. The five tools reach working, episodic, semantic, procedural and core memory; short-term memory shows up only as a counter in zenbrain_health, and cross-context memory is not wired to any tool.

	Layer	Holds
7	Cross-Context Memory	Links between entities of different domains (experimental; no tool uses it)
6	Core Memory	Pinned facts
5	Procedural Memory	"How to do X" — skills and workflows
4	Long-Term Semantic	Facts, with FSRS-style scheduling
3	Episodic Memory	Concrete experiences and events
2	Short-Term / Session	Current conversation context
1	Working Memory	Active task focus, 7±2 items

Nothing in long-term memory decays or is deleted on its own; only working memory decays. Every fact gets an FSRS-style review schedule, but no tool reports a review, so through this server the schedule is not advanced. Emotional weight decides routing (above 0.5: an episode) and which episodes consolidation turns into facts. The algorithms are in @zensation/algorithms and can be read line by line.

This server configures no LLM provider, so nothing in it calls a model: routing on store is a content heuristic, and consolidation runs without generated summaries.

What this release does not do

Worth knowing before you wire it in:

No embedding provider is configured by default, so recall is lexical, not semantic. Without vectors, recall ranks by folded token overlap — umlauts and accents are folded, rarer words weigh more, and an adjacent phrase beats the same words scattered. It will find "Kieler Foerde" in a note about the "Kieler Förde"; it will not connect "car" to "automobile". Episodes and facts are ranked over the most recent 500 of each, procedures over the 500 with the highest success rate. A layer in which the query matches nothing returns its most recent episodes and facts, or its most successful procedures, at score: 0, behind every hit; every core block comes with 0.5 or 0.8, so a block can rank above a weak hit. Working memory, when you ask for it, is ranked the same way. Pass an EmbeddingProvider through the library for true semantic matching — that is the configuration the published benchmarks were measured with.
SQLite similarity search is a full scan. Fine for one person's memory; use @zensation/adapter-postgres for larger volumes.
Consolidation is a tool call, not a schedule. Nothing runs it for you.
The store is a plain file. It is not encrypted. Put it somewhere you would put a notebook. While the server runs, SQLite keeps -wal and -shm files next to it.

Using it as a library

The server factory is exported, so you can mount ZenBrain's tools on a server of your own or drive them in tests. The package is ESM; require() loads it on Node 22.12 and later (on 22.0–22.11, use import).

typescript

import { createZenBrainServer } from '@zensation/mcp/server';import { MemoryCoordinator } from '@zensation/core';import { SqliteAdapter } from '@zensation/adapter-sqlite';
const coordinator = new MemoryCoordinator({  storage: new SqliteAdapter({ filename: './memory.db' }),});
const server = createZenBrainServer(coordinator);// connect it to any transport you like — the caller owns the coordinator's lifecycle

import { createZenBrainServer } from '@zensation/mcp/server';import { MemoryCoordinator } from '@zensation/core';import { SqliteAdapter } from '@zensation/adapter-sqlite';
const coordinator = new MemoryCoordinator({  storage: new SqliteAdapter({ filename: './memory.db' }),});
const server = createZenBrainServer(coordinator);// connect it to any transport you like — the caller owns the coordinator's lifecycle

Zero-dependency, and where that stops

@zensation/algorithms and @zensation/core pull nothing but each other. That claim is checked in CI on every push against the packed tarballs, not against the source tree.

This package is deliberately outside that boundary. An MCP server needs the protocol SDK, so it carries one. Keeping it in its own package is what lets the core stay clean: installing @zensation/core never pulls the MCP SDK, and installing this never weakens the claim the core makes.

About ZenBrain

ZenBrain is a seven-layer, neuroscience-derived memory architecture for LLM agents, built in TypeScript and published under Apache-2.0; @zensation/algorithms and @zensation/core have no third-party dependencies. The benchmark results, and the configuration they were measured in, are reported in the paper; the reproduction packages are on Zenodo.

Works out of the box without an embedding provider — lexical ranking, nothing extra to install. In the paper, ZenBrain's benchmark runs against other systems used nomic-embed-text as the embedding provider; the retrieval ablations used OpenAI text-embedding-3-small.

Source and issues: github.com/zensation-ai/zenbrain
Paper: arXiv:2604.23878 · Open-access archive: 10.5281/zenodo.19353663
Try it in the browser: zensation.ai/en/playground
Model card: huggingface.co/zensation-ai/zenbrain
Packages: @zensation/algorithms · @zensation/core · @zensation/adapter-postgres · @zensation/adapter-sqlite · @zensation/mcp · @zensation/ai-sdk
Registry entry: ai.zensation/zenbrain

License: Apache-2.0

來源：packages/mcp/README.md，提交 937b091

工具

zenbrain_store

Store a memory

Write something into long-term memory so it survives this conversation. Routing is automatic by default, first match wins: `steps`, or wording such as "How to", "Steps:" or "workflow:", make a procedure; an emotional weight above 0.5 (detected, or set via `emotionalWeight`) an episode; a `confidence` above 0.9 a pinned core memory; anything else a semantic fact. Set `type` only when you want to override that. Every call adds a new memory, except that storing the same core memory again updates it; the content is also kept in working memory (the most recent seven) while the server runs, so once seven are held each store replaces the oldest copy there. Long-term memory is never changed by a store. Returns the id of the stored memory. If it may already be stored, check with zenbrain_recall first: storing it again adds a duplicate.

輸入參數typestepstoolssourcecontent必填contextoutcomeconfidenceemotionalWeight

zenbrain_recall

Recall memories

Search long-term memory for anything relevant to a query. By default it searches the episodic, semantic, procedural and core layers; working memory (the most recent stores, held only while the server runs, up to five results) is searched only when named in `layers`. Returns results sorted by score, each with its id and the layer it came from; zenbrain_forget takes both. The score runs from 0 to 1 and says how well a result matches the query; a layer in which nothing matches returns recent memories (or its most successful procedures) at 0, behind every hit, and minScore above 0 leaves them out. Every core block scores 0.5 or 0.8, so a block can rank above a weak hit. Use this before answering when the user refers to something from an earlier session. To see how much is stored rather than what, use zenbrain_health; to save something, use zenbrain_store.

輸入參數limitquery必填layersminScoreminConfidence

zenbrain_forget

Forget a memory

Permanently delete a memory, addressed by the id and layer that zenbrain_recall returned for it, together with what consolidation linked to it; this cannot be undone. Forgetting an episode also deletes the fact zenbrain_consolidate made from it; forgetting such a fact also deletes every episode consolidated into it; both also delete the working-memory copies of that content. Forgetting a working-memory result deletes only that copy. alsoForgotten lists everything deleted besides the memory itself. A memory stored on its own and never consolidated keeps its long-term entry. Use it when the user asks to forget something or a stored memory is wrong; to correct a memory, forget it and store the corrected version with zenbrain_store. An id the layer does not hold is reported as not forgotten, not as an error.

輸入參數id必填layer必填

zenbrain_consolidate

Consolidate memory

Run one consolidation pass: among the 100 most recent episodes, each one with an emotional weight above 0.5 becomes a semantic fact — once, however often the pass runs. Working-memory slots lose relevance with age, and slots whose relevance has dropped to 0.01 or below are removed; that is the only deletion, and nothing in long-term memory is deleted. Run it between sessions or after a batch of zenbrain_store calls, not on every turn; compare zenbrain_health before and after to see the effect.

無需輸入參數。

zenbrain_health

Inspect memory state

Report how full the memory layers are: working-memory slots in use, interactions held, episodes, facts and how many are due for review, procedures, core blocks. Read-only and cheap, safe to call at any time. It returns counts only; to read the memories themselves, use zenbrain_recall.

無需輸入參數。