MCP

Dense-Mem 自托管 MCP 记忆服务器首用指南

Dense-Mem 适合要为 AI agent 建自托管、可溯源长期记忆并愿意运维 PostgreSQL 的团队，但启动前必须配齐 AI 供应商的五个环境变量，且证据文本、proposal 上下文与 recall 查询会发送到所配置的供应商——只有供应商自托管才能把这些流量留在自己的边界内。

官方来源 · Dense-Mem

安装

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d

适合谁

Dense-Mem 适合要给 AI agent 配一套自托管长期记忆、并愿意同时运维 PostgreSQL 与 Redis 的开发者或团队；如果只想给会话加临时上下文、不想引入数据库运维，它不合适。它以 MCP 对外提供记忆自动化契约（Streamable HTTP，端点 /mcp）：先暂存精确证据，由服务端经过校验的策略推导语义状态，再返回活动证据上下文与图状 Relationship 句柄；知识、生命周期、溯源、搜索、授权与审计都以 PostgreSQL 为持久权威，Redis 只负责协调。浏览器路由只是第一方界面，不是对外自动化入口。

使用前提与不适合的情况：

  • 启动必须配齐 embedding 与 verifier 两个 AI 服务的配置（五个变量见下文），没有免配置模式。
  • 数据出站副作用要在使用前知道：证据文本、proposal 上下文与 recall 查询都会发送给你配置的供应商；供应商自托管时流量留在你的边界内，用托管服务则不。
  • 官方支持的 MCP 客户端清单、资源需求与运维成本证据未说明，这些尚未确认。

3 分钟完成第一次尝试

前提：一台能运行 docker compose 的机器；.env 里填 POSTGRES_PASSWORD、CONTROL_PORTAL_TOKEN、AI_API_KEY；启动还要求完整的 embedding 与 verifier 配置：AI_API_URL、AI_API_KEY、AI_API_EMBEDDING_MODEL、AI_API_EMBEDDING_DIMENSIONS、AI_VERIFIER_MODEL——官方明说的启动前提，不要当成可选项。

提醒：查询型首试同样会把 recall 查询发给你配置的供应商。

官方主路径（Docker Compose）：

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d

容器启动后，在 MCP 客户端里接入 /mcp。第一次调用建议选查询型的 recall_memory：官方描述它返回活动证据上下文与 Relationship 句柄。刚启动、还没写入证据的实例上它会返回什么，证据未说明。成功信号：docker compose up -d 正常执行完，客户端能经 /mcp 访问该服务。

使用案例

案例一：为 agent 建立带溯源的跨会话记忆。场景：agent 要记住跨会话的事实，之后还能说明出处。做法：调用 remember 写入证据，之后用 recall_memory 召回活动证据上下文核对。remember 的参数与输入格式证据未给出，可确认到“这是官方的证据写入入口”。可期待的结果：证据被接收，语义状态由服务端策略推导。

案例二：解释一条关系是怎么来的。场景：向他人或下游系统说明某条 Relationship 的形成过程。做法：调用 trace_memory，官方描述它沿同一条 Relationship 追踪证据、决策与 lineage。参数与返回结构证据未给出，可确认到“提供该查询能力”为止，不在此编造示例。

使用边界

  • 读写性质：remember 写入证据；retract_evidence 退役调用方拥有的证据并保留 append-only 溯源；correct_relationship 仅限 owner 替换活动 Relationship（取代原关系、保留 support lineage）。recall_memory、trace_memory、export_memory_pack 是查询/导出类。官方未逐工具标注读写标志，查询类是否绝不写入尚未确认。
  • 更正通道只有上述退役与替换两种，其他写入不应理解为可撤销。
  • 凭证与数据面：.env 必填三值之外，运行依赖 PostgreSQL（持久）、Redis（协调）与外部 AI 供应商；证据文本、proposal 上下文与 recall 查询会出站到供应商，是否留在你的边界内取决于其部署位置。
  • 尚未确认：默认端口与完整 URL、数据保留与删除策略、团队或租户隔离语义、CONTROL_PORTAL_TOKEN 之外的鉴权细节。