为 AI 智能体提供持久化、可搜索的记忆，基于 模型上下文协议。实体及其观察结果存储在一个带有校验和与版本历史的压缩 SQLite 数据库中；上层是分层存储和多策略检索管道；整个系统通过 MCP 工具暴露给客户端。
工具的数量取决于你安装的内容，这种差异并非缺陷：后端缺失的工具根本不会被注册。核心安装（requirements.txt）注册 186 个；添加可选后端（requirements-optional.txt）后增至 204 个。如果你在仅执行 pip install -r requirements.txt 后数到 186，系统并未损坏。
两个数字均在 Python 3.11.11 上通过 tools/list 经 stdio 测量，且 AGENTIC_SYSTEM_PATH 未设置。最后一个条件并非吹毛求疵。如果该变量指向 GraphRAG 下描述的独立系统，则会额外注册七个工具，数字变为 193 和 211。本文件的早期草稿曾写为 188 和 206，因为测量时所在机器已导出该变量，我们中有两人在未察觉共同原因的情况下复现了相同的错误数字。重新测量前请先取消设置该变量。
核心功能全部在本地运行，无需 API 密钥，无需网络。可选的向量栈（Qdrant 加 ollama）将检索从关键词匹配升级为基于语义的检索，缺失时系统会优雅降级而非崩溃。
这是两个进程，而非一个。 关于此项目的几乎所有支持问题都源于只运行了其中一半。
your MCP client (Claude Code, Claude Desktop, an SDK, curl)
|
| stdio JSON-RPC, one server process per client session
v
+-------------------------------------------------------+
| MCP server server.py |
| start with setup/bin/mcp-server.sh |
+-------------------------------------------------------+
|
| JSON over a Unix socket: $MEMORY_DB_SOCKET_PATH
| (default /tmp/memory-db.sock)
v
+-------------------------------------------------------+
| memory-db daemon memory_db_service.py |
| start with setup/bin/memory-db-daemon.sh |
| REQUIRED. Owns the database file exclusively so that |
| several clients can share it without corrupting it. |
+-------------------------------------------------------+
|
v
memory.db (SQLite, default ~/.claude/enhanced_memories/)
optional, off to the side:
Qdrant http://localhost:6333 vector index for semantic recall
ollama http://127.0.0.1:11434 local embeddings that feed that index守护进程不是可选的，MCP 服务器不会为你启动它。没有守护进程时，服务器仍然启动、仍然响应，并返回如下对象：
{"query": "anything", "count": 0, "results": [],
"error": "Memory-DB service error: [Errno 2] No such file or directory"}
{"error": "Memory-DB service error: ...", "entities": {"total": 0},
"compression": {"ratio": "N/A"}}格式正确、可解析，但内容为空。智能体读取后会认为你的记忆为空，而非失聪。./healthcheck.sh 用于区分这两种情况。
Related MCP server: Strata Memory MCP Server
Python 3.11 或更新版本。在某些 macOS 机器上，裸 python3 可能仍是 3.9，因此安装程序会优先查找带版本号的名称。
git，以及用于虚拟环境的磁盘空间。在 macOS arm64 上使用 Python 3.11 测量：核心安装 83 MB，添加可选后端后 964 MB（因为后者会拉取 sentence-transformers 和 torch）。在 Linux x86_64 上，核心安装为 131 MB（在 python:3.11-slim 容器中测量）—— wheel 因平台而异，因此数字会随你的平台变化。代码仓库本身为 5 MB。
可选：podman 或 docker，如果你需要容器路径或本地 Qdrant。
可选：ollama，用于本地嵌入。
全程无需 sudo。不会在系统范围内安装任何内容。
如果此机器可能已经存在一个系统（旧版本检出、第二个克隆、数月前安装的服务），请在下面的步骤 2 之前阅读此内容。默认情况下，每个安装都希望使用相同的两个东西——套接字 /tmp/memory-db.sock 和数据库 ~/.claude/enhanced_memories/memory.db——并且它们不能被共享。
首先检查：
lsof /tmp/memory-db.sock # macOS or Linux
ss -xl | grep memory-db.sock # Linux
pgrep -af memory_db_service.py任何列出的内容都表示安装正在运行。在已被占用的套接字上启动第二个守护进程会被拒绝：它以非零退出码退出，并打印套接字路径和正在响应的守护进程所使用的数据库，而不是接管套接字。这是一种保护机制，而非共存——第二个守护进程根本不会运行。
要并排运行两个安装，请在 .env 中为这个安装提供其专属的一切：
ENHANCED_MEMORY_DIR=/home/you/.enhanced-memory-second
MEMORY_DB_SOCKET_PATH=/tmp/memory-db-second.sock
# Only if you want the Neural Memory Fabric somewhere else again; by default it
# follows ENHANCED_MEMORY_DIR:
# NMF_SQLITE_PATH=/home/you/.enhanced-memory-second/nmf.db
# NMF_FILES_ROOT=/home/you/.enhanced-memory-second/nmf_filesENHANCED_MEMORY_DIR 是最容易被遗忘的变量。两个守护进程在两个套接字上共享一个 memory.db 并非共存：这是两个独占所有者操作同一个文件，而这正是守护进程要防止的情况。
git clone <this-repo> enhanced-memory-mcp
cd enhanced-memory-mcp
# 1. venv, dependencies, .env, database directory. Idempotent, re-runnable.
setup/setup.sh
# 2. start the daemon (foreground). Leave it running, or install it as a
# background service: setup/service/install-services.sh
setup/bin/memory-db-daemon.sh &
# 3. prove the install works before you trust it
./healthcheck.sh健康运行以 Required checks passed. 和退出码 0 结束。其他任何情况都是真正的问题：请参阅 故障排除。
设置存储在 .env 中，步骤 1 仅在 .env 不存在时从 .env.example 创建它。编辑该文件是使设置持久化的方式；重新运行 setup/setup.sh 不会覆盖它。
然后在 MCP 客户端中注册服务器。在 ~/.claude.json 中：
{
"mcpServers": {
"enhanced-memory": {
"command": "/absolute/path/to/enhanced-memory-mcp/setup/bin/mcp-server.sh"
}
}
}将客户端指向 启动器，而非 python server.py。启动器会应用此代码仓库的 .env，这保证了 MCP 服务器和守护进程解析到相同的数据库文件。直接执行 python 的客户端只会继承该客户端当时拥有的环境，两个进程会悄然漂移。请参阅 分裂脑陷阱。
至此安装完成，工具在被调用时即可工作。但没有任何工具会自动调用：每个会话都从冷启动开始，除非智能体选择写入，否则不会写回任何内容。这不是故障，也没有检查会报告它，因此很容易将正常工作的安装误认为正常工作的记忆。docs/AUTOMATION.md 介绍了如何弥补这一差距，从每次提示时运行的回忆钩子开始。
stdio 为每个客户端会话生成一个服务器进程，这是桌面客户端所期望的。如果你更愿意通过 HTTP 运行单个共享服务器，请使用 SSE 传输：
MCP_TRANSPORT=sse setup/bin/mcp-server.sh # or setup/bin/mcp-server-sse.sh{
"mcpServers": {
"enhanced-memory": { "type": "sse", "url": "http://127.0.0.1:9106/sse" }
}
}该端口上没有身份验证。请将 MCP_HOST 保持为 127.0.0.1。
配置通过环境变量进行。setup/setup.sh 从 .env.example 写入一个 .env，其中内联记录了每个设置。编辑 .env 是持久化机制：复制仅在 .env 不存在时发生，因此你的编辑会在每次重新运行安装程序后保留（同样，新版本的默认值不会自动生效——升级后请比较两个文件）。环境中已设置的变量会在单次调用中覆盖文件中的值：
MEMORY_DB_SOCKET_PATH=/tmp/other.sock ./healthcheck.sh变量 | 默认值 | 用途 |
|
| 存放 |
| (未设置) | 数据库文件的完整路径。覆盖目录设置。 |
|
| 两个进程之间的 Unix 套接字。保持简短，请参见下面的 AF_UNIX 说明。在同一台机器上的第二个安装应使用自己的路径。 |
|
| 可选。神经记忆结构（Neural Memory Fabric）数据库。它默认跟随 |
|
| 可选。NMF 文件存储，规则同上。 |
|
|
|
|
| 仅用于 HTTP 传输。不要将其暴露到网络中。 |
|
| 仅用于 HTTP 传输。 |
|
|
|
|
|
|
|
| 可选的向量存储。 |
|
| 可选的嵌入提供者。 |
|
| 要拉取和使用的嵌入模型。 |
|
| 低于此分数的结果被标记为低置信度。 |
| (未设置) | JSON 文件，声明 |
|
| 将 |
| (未设置) | 仅启用 GraphRAG，其实现未在此处提供。设置此变量后，工具数量从 186 增加到 193，或在使用可选后端时从 204 增加到 211。 |
| (未设置) | 固定 |
ENHANCED_MEMORY_SURFACE 和 MEMORY_PROFILE 都会改变 tools/list 返回的工具数量，安装的可选依赖项也会影响该数量：缺少后端的工具不会被注册。仅核心安装与包含可选扩展的安装会从同一代码报告不同的数量。预期的工具数量只有在三者都确定的情况下才有意义。
两者都不是必需的。但两者都值得拥有。
存在时 | 缺失时 | |
Qdrant | 搜索按含义排序：关于“权限门控”的查询可以找到从未使用过这些词的实体。 | 搜索仍然有效并返回结果，但排序退回到词汇匹配。不会报错，这就是为什么很容易被忽视。 |
ollama | 生成 Qdrant 索引所需的嵌入。 | Qdrant 没有可索引的内容，因此即使 Qdrant 在运行，召回仍然停留在词汇层面。 |
提供其中之一或两者：
setup/setup.sh --with-qdrant # container on 127.0.0.1:6333, named volume
setup/setup.sh --with-ollama # verifies ollama, pulls the embedding model./healthcheck.sh 将两者都报告为 OPTIONAL，并且不会因它们缺失而失败。如果需要更严格的契约，请传递 --require-optional。
已经在运行 Qdrant？将 MEMORY_QDRANT_URL 指向它，并完全跳过 --with-qdrant；这里不需要拥有该实例。下面容器配置文件中讨论的端口冲突仅针对该配置文件，该配置文件在 6333 端口上发布自己的容器，并且无法绑定已被其他进程占用的端口。主机安装仅发出出站请求。
GraphRAG 工具（graph_enhanced_search、get_entity_neighbors）不在此处提供。graphrag_tools.py 从 $AGENTIC_SYSTEM_PATH/scripts/graph-rag.py 加载其实现，该文件属于一个独立的系统，不是本包的一部分。AGENTIC_SYSTEM_PATH 默认为检出目录的父目录的父目录，因此在独立安装中该路径不存在。
不会出现任何问题。注册被包装，服务器记录 GraphRAG integration skipped: ... 并在没有这些工具的情况下启动。如果你确实拥有该系统，请将 AGENTIC_SYSTEM_PATH 指向其根目录，它们就会注册。请注意，跳过消息会写入日志文件，而不是你的终端，因此缺失的工具看起来就像从未存在过一样。
共享环境的交付路径。优先使用 Podman，兼容 Docker。
podman-compose up --build # core only
WITH_OPTIONAL=1 podman-compose --profile qdrant up # with a USABLE vector storeWITH_OPTIONAL=1 对 qdrant 配置文件至关重要。 默认镜像仅安装 requirements.txt，其中不包含 qdrant-client——因此没有它而使用 --profile qdrant 会给你一个健康、可访问但完全未使用的 Qdrant：健康检查报告服务可访问（true），而服务器记录“qdrant-client not installed - vector search disabled”，每次搜索都停留在词汇层面。一个绿色信号旁边是一个无用的能力，这正是本项目旨在消除的失败模式，因此在此明确指出，而不是留给你去发现。WITH_OPTIONAL=1 构建的镜像包含 requirements-optional.txt，向量路径才会真正启用。（实测：一个核心镜像与 qdrant 配置文件一起运行时，对 /readyz 响应“all shards are ready”，但实际上并未使用它。）
使用连字符。在 Fedora 44 上，podman compose（带空格）会交给外部提供者 /usr/libexec/docker/cli-plugins/docker-compose，后者需要 Docker 兼容的 API 套接字。当 podman.socket 未激活（默认情况）时，podman compose up 会失败：
failed to connect to the docker API at unix:///run/user/1000/podman/podman.sock:
connect: no such file or directorysystemctl --user start podman.socket 可以解决这个问题，或者直接使用 podman-compose（此处为 1.6.0），它直接驱动 podman，不需要 socket。在 Fedora 44 上使用 podman 5.8.4 实测：podman compose up 如上所述失败，podman-compose up -d 成功启动堆栈，容器报告为 healthy。
该镜像在 container-entrypoint.sh 下运行两个进程，该脚本启动守护进程，等待 socket 响应，然后才在 SSE 传输上启动 MCP 服务器。如果任一进程退出，容器就会退出，因为一个活着的 MCP 服务器旁边是一个死掉的守护进程，正是那种永远返回格式良好的零的状态。
一些能节省你时间的说明：
podman build 会丢弃 HEALTHCHECK。 Podman 默认使用 OCI 镜像格式，该格式没有对应字段。它确实会在构建时警告一次：
HEALTHCHECK is not supported for OCI image format and will be ignored.
Must use `docker` format如果错过了构建输出中的那一行，就再也不会有人提及它：镜像不携带健康检查，podman ps 也永远不会显示健康状态。在 podman 5.8.4、Fedora 44 上实测：OCI 镜像的 .HealthCheck 检查为 nil，使用 podman build --format docker 重新构建会得到 [CMD /app/setup/lib/container-health.sh]。
有三种解决方法，均已验证：使用 --format docker 构建；使用 compose，其服务级健康检查在 compose.yaml 中定义，无论镜像格式如何都适用（由 compose 管理的容器从同一个检查为 nil 的镜像报告为 healthy）；或者使用 podman exec <name> /app/healthcheck.sh --skip-mcp 按需检查。
MCP 端口仅发布在主机回环地址上（127.0.0.1:9106:9106）。在容器内部，服务器绑定 0.0.0.0，这在容器内是正确的，但在工作站上则是错误的。
Qdrant 的主机端口是 ${QDRANT_PORT:-6333} 和 ${QDRANT_ADMIN_PORT:-6334}。如果你已经在 6333 端口上运行 Qdrant，请在 .env 中设置它们，否则会发生绑定冲突，导致配置文件无法启动。
该镜像是核心安装，因此 qdrant 配置文件本身不会做任何事情。 podman-compose --profile qdrant up 会给你一个能启动、通过健康检查并响应其端口的 Qdrant，而服务器没有 qdrant-client 可以与之通信。一切看起来都是绿色的，但没有任何内容被索引。使用可选堆栈构建以实际使用它：
podman build --build-arg WITH_OPTIONAL=1 -t enhanced-memory:local -f Containerfile .
# or, through compose:
WITH_OPTIONAL=1 podman-compose up --build./healthcheck.sh 区分了这两种情况：只有当客户端库可导入时，它才报告 Qdrant 既可访问又可用，并在服务已启动但没有任何东西可以使用它时发出警告。
数据库位于命名卷 enhanced-memory-data 中。没有卷，你的记忆会随容器一起消亡。
ollama 在你的主机上运行，容器无法通过 127.0.0.1 访问它。取消注释 compose.yaml 中的 MEMORY_OLLAMA_URL（podman 使用 host.containers.internal，docker 使用 host.docker.internal）。
验证正在运行的容器的方式与验证主机安装的方式相同。使用绝对路径：并非每个引擎都会将相对路径解析为相对于 WORKDIR 的路径。
podman exec enhanced-memory /app/healthcheck.sh --skip-mcp你本地的 .env 不是容器的配置。镜像故意附带一个空的 .env，所有真实配置都来自 compose.yaml 中的运行时环境。.containerignore 和 .dockerignore 排除了该文件，但并非每个引擎都遵守它们（Apple 的 container build 没有遵守，已于 2026-08-14 验证），因此 Containerfile 还会在一个被丢弃的构建阶段将其清空，如果填充后的文件幸存下来，则构建失败。
setup/service/install-services.sh # daemon only
setup/service/install-services.sh --with-sse # and a shared SSE server
setup/service/uninstall-services.shmacOS 上的 launchd 用户代理（~/Library/LaunchAgents），Linux 上的 systemd 用户单元（~/.config/systemd/user）。不需要 root，不需要系统单元。所有路径都根据此检出位置渲染，因此如果你给它们不同的 --label-prefix 值、不同的 MEMORY_DB_SOCKET_PATH 值以及不同的 ENHANCED_MEMORY_DIR 值，两个检出可以共存。三个都要，而不是前两个：仅使用不同的 socket 会导致两个守护进程打开同一个 memory.db，而每个守护进程都应该独占该文件。
安装程序会等待 socket，如果服务未启动，则会大声失败并显示日志尾部。日志位于 ~/Library/Logs/enhanced-memory 或 ${XDG_STATE_HOME:-~/.local/state}/enhanced-memory/log，故意不在检出目录中：launchd 无法在生成时在外部卷上创建日志文件，作业会在你的代码运行之前以退出码 78 死亡。
在 Linux 上，除非你启用 lingering，否则用户单元会在注销时停止：
loginctl enable-linger $USER两个门槛，按此顺序。
./healthcheck.sh # the post-install gate
python3 comprehensive_test.py # the functional suite (needs the daemon running)第三个面向开发者的套件位于 tests/ 下，需要先执行 pip install -r dev-requirements.txt —— pytest 故意不包含在任何运行时需求文件中，上述两个门槛仅依赖标准库即可运行。
根据 comprehensive_test.py 的退出代码来判断，而不是通过计数。检查次数取决于它选择的模式：如果没有设置 ENHANCED_MEMORY_* 或 MEMORY_DB_* 变量，它会构建自己的沙箱并运行所有内容；如果设置了这些变量，它会针对你的部署运行，并跳过描述它未创建的沙箱的检查。在一台机器、一次提交上实测：106 个隔离检查和 102 个操作员导向检查，均退出码为 0。运行时会打印自己的模式并说明跳过了什么。
安装可选后端会使该计数改变零，两种方式都实测过。此文件的早期修订版说后端是原因。它们不是，而且在任何人测试之前，同样的错误猜测也被附加到了 pytest 跳过计数上；有关实际影响该计数的内容，请参阅 RELEASE_NOTES.md 中的测试套件部分。
./healthcheck.sh 的设计使其可能失败。它通过守护进程 socket 写入一个探针实体，搜索回来，然后删除它。它将任何响应中的 error 或 daemon 键视为失败，无论其余负载如何，并将守护进程报告的数据库路径与你的环境解析的路径进行比较。它检查：
venv、解释器版本、.env、socket 路径长度、源文件存在性
守护进程往返（状态、数据库一致性、写入、读回、清理）以及模式检查：拥有此数据库的两个文件中的每个字面 INSERT 都与实时表定义进行比较，因为模式缺少的列会导致每次写入失败，而守护进程会逐行报告失败而不是抛出异常
通过 stdio 的 MCP 握手、工具数量，以及 stdout 没有被污染
Qdrant 和 ollama，标记为 OPTIONAL，绝不致命
有用的标志：--skip-mcp 用于快速的仅守护进程检查，--expect-tools N 用于固定数量，--require-optional 用于要求向量堆栈。
/tmp/enhanced-memory-mcp.log，始终如此，适用于主机上的所有安装。
MCP 服务器在启动时清除所有日志处理程序，并将所有内容发送到该单个轮转文件（50 MB，两个备份），因为在 stdio 传输上，stdout 上的任何内容都会破坏协议。常规 INFO 仅存在于那里，路径是固定的，因此一台机器上的两个检出会交错写入同一个文件，时间戳和 pid 是你唯一的区分方式。
WARNING 及以上级别还会额外发送到 stderr，除非你设置 MEMORY_LOG_STDERR=0。这是故意的：每个 ... integration skipped: <reason> 行都是一个未加载的功能，仅将它们路由到 /tmp 下的文件意味着没有人会阅读它们。如果你的 MCP 客户端将任何 stderr 输出视为错误，请将该变量设置为 0 并改为读取文件。
./healthcheck.sh 也会报告这些，作为 WARN mcp-startup 行列出不同的警告，因此缺失的功能会出现在门槛中，而不仅仅是在日志中。在此分支上实测：核心安装产生 11 个（numpy、qdrant-client、sentence-transformers、redis、neo4j 等），完整安装产生 3 个。它们都不会导致门槛失败。它们是你的安装所没有的内容清单，值得读一次然后忽略。
提交使用 SSH 签名。Git 在你告诉它信任哪些密钥之前不会验证它们，并且该配置不会随克隆一起传播：
git config gpg.ssh.allowedSignersFile .allowed_signers
git log --show-signature -1没有第一行，git log --format=%G? 会为每个提交报告 N，这意味着“无法验证”，而不是“未签名”。签名无论哪种方式都存在：git cat-file commit HEAD 会显示 gpgsig 块。
error 字段守护进程未运行。这是绝大多数情况。
{"count": 0, "results": [], "error": "Memory-DB service error: ..."}setup/bin/memory-db-daemon.sh # foreground, watch it
./healthcheck.sh --skip-mcp # confirm the round trip症状：写入似乎成功，但搜索永远找不到它们，或者 get_memory_status 报告的计数与你存储的不匹配。两个进程解析了不同的文件，并且两者都没有报错。
./healthcheck.sh 直接检测到这一点：
FAIL db-agreement SPLIT BRAIN: daemon holds /path/A/memory.db,
this environment resolves /path/B/memory.db原因：某个进程以与另一个进程不同的 ENHANCED_MEMORY_DIR、ENHANCED_MEMORY_DB_PATH 或 HOME 启动。通常是 MCP 客户端配置为直接执行 python server.py，绕过了应用 .env 的启动器。修复客户端配置以使用 setup/bin/mcp-server.sh，然后重新启动两个进程。
自 e9ca30c 起，这不会静默发生：当搜索无法看到观察内容时，响应会说明这一点——
{"count": 0, "results": [], "degraded": "name-only (observations_fts missing)"}degraded 表示数据库早于全文索引，并且自升级以来没有守护进程对其初始化。重新启动守护进程：init_database() 现在会创建索引并回填所有现有行。另一个值 name-only (FTS query error) 是每个查询的，表示查询文本在清理后破坏了 FTS 语法；名称/类型匹配仍然运行。
已在 e9ca30c 中修复：create_entities 会跳过该实体已存在完全相同内容的观察，并在其响应中将跳过报告为 observations_deduped，因此重复的种子导入是幂等的。真正的新观察仍然会追加。修复前重新导入创建的重复项不会为你删除——issue #8 中有一次性清理 SQL。
重新措辞的重新导入（同一种子文件稍作编辑）也会被检测到，通过确定性 simhash——不涉及 LLM。默认情况下，它们会存储并报告在 near_duplicates 响应字段中，指明每个相似于哪个现有行：在此层，更正（“62Gi” → “125Gi”）与重新措辞无法区分，而记忆存储绝不能静默丢弃更正。知道自己在重新导入的导入管道可以设置 ENHANCED_MEMORY_NEAR_DUP_POLICY=skip 来丢弃它们；该变量的任何其他值都会回退到安全的存储并报告。距离阈值和测量的校准带位于 simhash_dedup.py 中。
OSError，没有有用的消息socket 路径太长。AF_UNIX 在 macOS 上将路径字符串限制为 104 字节，在 Linux 上为 108 字节，bind() 会失败，并出现一个既不提及限制也不提及路径的错误。深层检出在 socket 放置在其中时立即遇到此问题。
保持 MEMORY_DB_SOCKET_PATH 简短并在检出目录之外，例如 /tmp/em-myproject.sock。setup/setup.sh 会测量它，如果太长则拒绝继续。
如果日志在启动器路径上显示 Operation not permitted，则检出位于 launchd 不允许执行的位置。已于 2026-08-14 验证：在 /Volumes 下的外部卷上的检出可以正常安装和加载，然后每次生成都会因 EPERM 失败，因为 launchd 在没有你的终端所具有的磁盘访问权限的情况下运行。
将检出移动到你的主目录或其他本地路径并重新安装，或者如果位置不可协商，则授予 launchd 完全磁盘访问权限。安装程序会暴露这一点而不是隐藏它：它等待 socket，30 秒后失败，并打印错误日志的尾部。
ConnectionRefusedError 而 socket 文件存在被终止的守护进程留下了这个文件。重新启动守护进程后，它会自行删除该文件，并记录 removed stale socket <path>；启动器在执行前也会执行相同操作。不要养成手动删除套接字文件的习惯——一个仍在服务的文件看起来与过时的文件完全一样，删除它会切断该守护进程所有客户端的连接。
REFUSING TO START: another daemon is already serving ...这是预期行为：其他进程正在该套接字路径上响应。消息会指明套接字名称，以及当另一个守护进程回复状态请求时，它所持有的数据库。要么停止那个守护进程，要么为当前守护进程指定自己的 MEMORY_DB_SOCKET_PATH 和 ENHANCED_MEMORY_DIR——请参阅已在运行增强型内存系统？。
有内容打印到了 stdout，而 stdout 在 stdio 传输上专属于 JSON-RPC 流。./healthcheck.sh 的检查 3 会将其报告为 FAIL mcp-stdout，并附上违规行。
python3 是 3.9 版本这在 macOS 上很常见。安装一个受支持的解释器（brew install python@3.11），然后重新运行 setup/setup.sh，该脚本会优先使用带版本号的名称。要强制指定一个：setup/setup.sh --python /path/to/python3.11。
这些内容编写出来是为了重新检查，而非完全信任。
健康检查未测试 SSE 传输，未调用单个工具（仅列出它们），未测试多个客户端的并发访问，也未测量有无向量栈时的召回质量。
本 README 旧版本中引用的性能数据未在此处复现，已被删除而非重复。本文件中的任何内容均不声称吞吐量、延迟或压缩比。
容器路径已在 Fedora 44、linux/amd64 上使用 podman 5.8.4 验证：构建、运行，内部完整健康检查通过，监督测试产生 Exited (1)，入口点指明了哪一半失败，并且 podman-compose 使整个栈健康运行。开发期间也在 Apple 的 container 和 macOS/arm64 上的 Docker 下构建并运行。未涵盖：除 Fedora 44 外的任何发行版，以及 rootful podman（上述所有操作均为 rootless）。
服务单元由安装程序安装并启动，安装程序会等待套接字，如果套接字未出现则会大声报错。未测试在真实重启或注销后的存活能力。
工具数量因界面、配置文件以及安装的可选依赖项而异。任何单一数字都应视为特定于某台机器的配置。
MIT
This server cannot be deployed
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Memory for AI agent teams across tools, sessions, repositories, and teammates.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
