[Bug] memory_search always returns no results with reasoning-enabled models (MiniMax) #1324

Bug Description

memory_search always returns "No relevant memories found" when using the filterRelevant task with models that have reasoning enabled (e.g., MiniMax M2.7-highspeed with reasoning: true).

The root cause: these models output thinking/reasoning text inside tags like <think>...</think> or think>...</think> for the analysis phase, but then never output the required JSON ({"relevant":[...],"sufficient":...}) after the thinking block. The thinking consumes all tokens.

Environment

• MemOS version: @memtensor/memos-local-openclaw-plugin (latest, 2026-03-23)
• Node.js: v22.22.1
• OS: macOS 25.3.0 (Darwin x64)
• OpenClaw: latest
• Model: MiniMax M2.7-highspeed (reasoning: true)

Steps to Reproduce

1. Configure MemOS with a reasoning-enabled model (MiniMax M2.7-highspeed with reasoning: true in openclaw.json)
2. Have some memories stored in the database
3. Call memory_search with any query
4. Observe: always returns "No relevant memories found"

Root Cause Analysis

The raw LLM response for filterRelevant looks like:

think>
Let me analyze the query and candidate memories...
文字分析内容...
</think>"{"subsystem":"gateway"}

Key observations:

• Model uses think> (not <think>) — missing leading <
• The response ends with </think> followed by a stray "
• No JSON output after thinking block — the thinking text consumes all tokens
• parseFilterResult expects {"relevant":[...],"sufficient":...} but never receives it

Evidence

Raw response structure:
- Position 0: "think>" (6 chars)
- Position ~891: "]]" (end of thinking block marker)
- After greedy strip of thinking block: only `>"` remains
- JSON object count in raw response: 0

Current Workaround

Parsing-side fix (PR pending): strip <think>...</think> and think>...</think> tags before JSON parsing. This handles cases where JSON IS output but wrapped in thinking tags.

However, the fundamental issue remains: reasoning models do not output JSON for this task.

Suggested Fixes

Option A — Prompt Engineering (recommended)

Modify the filterRelevant system prompt to force JSON output after thinking:

IMPORTANT: After your analysis, you MUST output a valid JSON object in this exact format:
{"relevant":[1,2,3],"sufficient":true}
Do not output any text after the JSON object.

Option B — Regex Fallback

When JSON parsing fails, extract candidate IDs from thinking text:

// Extract "Candidate N" style references from thinking content
const candidates = thinkingText.match(/Candidate\s+(\d+)/gi)?.map(n => parseInt(n)) || [];

Option C — Disable Reasoning for This Task

Pass thinking: false when calling the filterRelevant task (if the API supports per-request override).

Related Issues

• Possibly related to: Zhipu reasoning_tokens issue in PR fix: disable zhipu thinking mode to prevent summarizer output truncation #1310 (not yet merged)
• Similar pattern: parseDedupResult had the same thinking-tag stripping issue (fixed in PR fix(openclaw): strip <think/> tags from assistant messages #1287)

Tags

bug, memory-search, filterRelevant, reasoning-models, MiniMax