Integrate OpenClaw with the Long-Term Memory Service

更新时间:
复制 MD 格式

OpenClaw is a locally deployable multi-channel AI assistant framework that supports 20+ messaging channels, including WhatsApp, Telegram, Feishu, and iMessage. It uses a plugin system to extend memory, skills, and tool capabilities.

Use the long-term memory service of AnalyticDB for PostgreSQL as the persistent memory backend for OpenClaw so that agents retain long-term memory across sessions and devices.

Scenarios

  • Unified memory across channels: A user states preferences on Telegram, and the assistant remembers them when the user switches to Feishu or iMessage. All channels share the same long-term memory.

  • Lightweight client-side deployment: No client-side vector database or embedding model is required. The long-term memory service handles fact extraction, vectorization, and semantic retrieval, keeping OpenClaw instances lightweight.

  • Memory isolation for multiple agents: In multi-agent scenarios, you can configure an independent memory namespace for each agent to prevent cross-contamination between agents.

Prerequisites

  • Node.js 22.19 or later is installed. Node 24 LTS is recommended.

  • OpenClaw 2026.4.24 or later is installed. For more information, see the OpenClaw official installation documentation.

  • The URL and API key of the AnalyticDB for PostgreSQL long-term memory service are obtained.

Note

The ADBPG long-term memory plugin is derived from the upstream @mem0/openclaw-mem0 under Apache License 2.0, with minimal adaptations for connecting to the long-term memory service. No client-side vector databases, embedding models, or large language models are required — all memory management is handled by the server.

Procedure

Step 1: Install OpenClaw and the Memory plugin

  1. Install OpenClaw globally if it is not already installed.

    npm install -g openclaw@latest
  2. Install the ADBPG long-term memory plugin.

    openclaw plugins install @adbpg-ai/openclaw-mem0
  3. Verify that the plugin is recognized.

    openclaw plugins list | grep openclaw-mem0

    The output contains the Memory (Mem0) — ADBPG Build entry with the status enabled.

Note

The Memory plugin in OpenClaw works as an exclusive slot. If the upstream @mem0/openclaw-mem0 is already installed, uninstall it before you install the ADBPG version:

openclaw plugins uninstall openclaw-mem0
openclaw plugins install @adbpg-ai/openclaw-mem0

Step 2: Configure openclaw.json

Edit the configuration file ~/.openclaw/openclaw.json and add the openclaw-mem0 plugin configuration.

{
  "plugins": {
    "allow": ["openclaw-mem0"],
    "slots": {
      "memory": "openclaw-mem0"
    },
    "entries": {
      "openclaw-mem0": {
        "enabled": true,
        "config": {
          "mode": "platform",
          "apiKey": "${ADBPG_API_KEY}",
          "baseUrl": "${ADBPG_URL}",
          "userId": "alice"
        },
        "hooks": {
          "allowConversationAccess": true
        }
      }
    }
  }
}

Configuration parameters

Parameter

Description

plugins.slots.memory

Set to openclaw-mem0 to assign the Memory slot to this plugin.

mode

Set to platform to use a remote REST service as the backend.

apiKey

The API key of the AnalyticDB for PostgreSQL long-term memory service. Inject this value through the ${ADBPG_API_KEY} environment variable to avoid storing it in plaintext. For more information about how to obtain the API key, see Long-term memory service.

baseUrl

The URL of the AnalyticDB for PostgreSQL long-term memory service. For more information about how to obtain the URL, see Long-term memory service.

userId

The user identifier for memory isolation. Use the actual application-layer user ID, such as an email address or UUID. If omitted, defaults to the current OS username (for example, root), which is suitable for single-user testing but should be explicitly set in production.

Restart the gateway for the configuration to take effect:

openclaw gateway restart

Step 3: Verify basic memory operations

The mem0 CLI subcommand reads from and writes to the long-term memory service.

  1. Run a health check.

    openclaw mem0 status
  2. Store a preference.

    openclaw mem0 add "I like to drink a cup of black coffee every morning" --user-id alice

    Expected output:

    Added 1 memory(s):
      :  [ADD]
  3. Perform a semantic search.

    openclaw mem0 search "beverage preference" --user-id alice

    Expected output (matches the preference that was just stored):

    [
      {
        "id": "<memory-id>",
        "memory": "Drinks a cup of black coffee every morning",
        "score": 0.62,
        "scope": "long-term",
        "categories": ["preferences"]
      }
    ]
  4. List all memories for the current user.

    openclaw mem0 list --user-id alice
Note

The AnalyticDB for PostgreSQL long-term memory service uses asynchronous processing. A PENDING status returned by the store operation indicates that the task is queued. The server typically completes fact extraction and vectorization within a few seconds. Do not search for the same memory immediately after storing it.

Step 4: Verify end-to-end read/write through TUI

openclaw tui provides a local terminal conversation interface for agents. This step verifies that memories generated through TUI conversations can be retrieved by using CLI commands, confirming the end-to-end read/write loop.

Prerequisites

  • A default agent model is configured for OpenClaw, such as the Alibaba Cloud Model Studio qwen-plus series. If this is not configured, run the following command:

    openclaw onboard --auth-choice qwen-standard-api-key-cn \
                     --modelstudio-standard-api-key-cn <your-dashscope-api-key>

    Or see the OpenClaw model configuration documentation.

  • The gateway is started.

    openclaw gateway restart

Verification process

  1. Open TUI and have a conversation with the agent.

    openclaw tui

    Enter a preference and then exit TUI (Ctrl+C or /exit):

    User: I am left-handed.
    
    Agent: OK, I will remember that.
  2. Wait for the asynchronous processing to complete, which typically takes a few seconds, and then run the following CLI commands.

    # List all memories in the current namespace
    openclaw mem0 list
    
    # Perform a semantic search with a query that does not lexically overlap with the original input
    openclaw mem0 search "hand preference"

    Expected result: The list response contains a fact extracted by the long-term memory service from the conversation. The search command uses a query that does not lexically overlap with the original input and matches the stored memory. This verifies that vectorized semantic retrieval works as expected.

Note

TUI and CLI use the same userId namespace by default. If you specify userId in openclaw.json, pass the same value by using the --user-id <userId> parameter for CLI commands. If you do not specify it, both TUI and CLI use the current OS username, such as root.

The agent automatically invokes the Memory plugin during each conversation turn: before responding, it retrieves relevant memories and injects them into the context (auto-recall); after responding, it extracts new facts and writes them to the long-term memory service (auto-capture). No explicit tool invocation is required.

Use memories

Automatic extraction and recall

Once configured, the plugin automatically performs the following tasks during each conversation through TUI or any connected messaging channel:

  • Extraction: After the agent_end hook fires, the plugin sends conversations containing persistable user information (dietary preferences, coding habits, project backgrounds, address changes) to the AnalyticDB for PostgreSQL long-term memory service. The server-side LLM extracts structured facts and vectorizes them into the database.

  • Recall: When the before_prompt_build hook fires at the start of each turn, the plugin queries the long-term memory service with the current user input. Matched memories are injected into the agent's system prompt, giving the agent cross-session memory so users do not need to repeat background information.

Search memories

openclaw mem0 search "Hangzhou"

This command returns memory entries that are semantically related to the search term. It is commonly used to check whether a write operation has taken effect or to debug the retrieval.

The retrieval uses vector similarity. The query term and the matched entries do not need to share any common words. For example, a query for accommodation preference can match memories such as prefers staying in B&Bs.

Agent tools

In addition to automatic hooks, the plugin registers the following tools that the agent can invoke explicitly during reasoning:

Tool

Description

memory_search

Searches for memories by using natural language queries. The scope parameter is supported and can be set to session, long-term, or all.

memory_add

Explicitly stores a fact.

memory_get

Retrieves a single memory by ID.

memory_list

Lists all memories of the current user or agent.

memory_update

Updates the text content of an existing memory.

memory_delete

Deletes a single memory or deletes memories in batches.

CLI reference

# Health check
openclaw mem0 status

# Memory operations
openclaw mem0 add "..."           --user-id <uid>
openclaw mem0 search "..."        --user-id <uid>
openclaw mem0 search "..."        --user-id <uid> --scope long-term
openclaw mem0 list                --user-id <uid>
openclaw mem0 get <memory_id>
openclaw mem0 update <memory_id> "..."
openclaw mem0 delete <memory_id>
openclaw mem0 delete --all        --user-id <uid> --confirm

# Multi-agent scenarios
openclaw mem0 search "..."        --user-id <uid> --agent <agent-name>
openclaw mem0 list                --user-id <uid> --agent <agent-name>

FAQ

  • Q: Why does a search immediately after storing return no results?

    A: The server uses asynchronous processing. The store operation only enqueues the task. Fact extraction and vectorization are completed in the background, which typically takes a few seconds. Wait for a short period after storing before you search.

  • Q: Can I enable multiple agents in OpenClaw with independent memories for each agent?

    A: Yes. In multi-agent scenarios, the plugin automatically routes the memories of different agents to independent namespaces (&lt;userId&gt;:agent:&lt;agentName&gt;) based on session_key. No additional configuration is required.

  • Q: How do I disable automatic memory and manage memories only through tool calls?

    A: Set autoRecall and autoCapture to false in the plugin configuration. The agent can still use memory_search, memory_add, and other tools to manage memories.