增强型记忆 MCP 服务器

为 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_files

ENHANCED_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 介绍了如何弥补这一差距，从每次提示时运行的回忆钩子开始。

替代方案：一个共享的 HTTP 服务器

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

ENHANCED_MEMORY_SURFACE 和 MEMORY_PROFILE 都会改变 tools/list 返回的工具数量，安装的可选依赖项也会影响该数量：缺少后端的工具不会被注册。仅核心安装与包含可选扩展的安装会从同一代码报告不同的数量。预期的工具数量只有在三者都确定的情况下才有意义。

可选服务，以及没有它们会失去什么

两者都不是必需的。但两者都值得拥有。

提供其中之一或两者：

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 是可选的且外部的

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 store

WITH_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 directory

systemctl --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.sh

macOS 上的 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 键视为失败，无论其余负载如何，并将守护进程报告的数据库路径与你的环境解析的路径进行比较。它检查：

1. venv、解释器版本、.env、socket 路径长度、源文件存在性

2. 守护进程往返（状态、数据库一致性、写入、读回、清理）以及模式检查：拥有此数据库的两个文件中的每个字面 INSERT 都与实时表定义进行比较，因为模式缺少的列会导致每次写入失败，而守护进程会逐行报告失败而不是抛出异常

3. 通过 stdio 的 MCP 握手、工具数量，以及 stdout 没有被污染

4. 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 会测量它，如果太长则拒绝继续。

macOS：服务安装但守护进程从未启动

如果日志在启动器路径上显示 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——请参阅已在运行增强型内存系统？。

MCP 客户端在握手时因 JSON 解析错误而失败

有内容打印到了 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