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 handle；知識、生命週期、溯源、搜尋、授權與稽核都以 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 handle。剛啟動、尚未寫入證據的實例上它會回傳什麼，證據未說明。成功訊號：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 之外的其他驗證細節。