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.

无需输入参数。