一、问题现象

OpenClaw 执行任务并调用长期记忆时，返回下面的错误：

{"results": [],"disabled": true,"unavailable": true,"error": "memory_search timed out after 15s","warning": "Memory search is unavailable due to an embedding/provider error."}

错误信息看起来像是 embedding provider 配置异常，但真正需要关注的是：

memory_search timed out after 15s

本机检查后确认，Memory 索引完整，向量维度正常， 

indexIdentity=valid， embeddingProbe.ok=true。

因此，这次问题并不是索引损坏，也不需要反复执行 openclaw memory index --force。

二、真正的原因

当前使用的 embedding 模型是：

qwen3-embedding:0.6b

模型空闲后被 Ollama 卸载↓下一次 memory_search 触发模型冷启动↓冷启动耗时约 22 秒↓OpenClaw 在第 15 秒结束查询↓返回 embedding/provider error

所以，错误中的 embedding/provider error 只是外层提示，根本原因是：

embedding 模型还没有完成加载，OpenClaw 就已经超时了。

三、优先方案：让模型保持加载

最有效的处理方式，是避免 Ollama 在模型空闲后将其卸载。

调用 Ollama 的 /api/embed 接口时，传入：

{"keep_alive": -1}

keep_alive: -1 表示让模型持续驻留。

可以编写一个简单的保活脚本：

#!/bin/zshOLLAMA_HOST="http://127.0.0.1:11434"MODEL="qwen3-embedding:0.6b"curl -fsS "${OLLAMA_HOST}/api/embed" -H "Content-Type: application/json" -d "{"model": "${MODEL}","input": "OpenClaw memory keepalive","keep_alive": -1}" >/dev/null

执行后检查模型状态：

ollama ps

如果看到下面的状态，说明保活已经生效：

qwen3-embedding:0.6b    UNTIL Forever

为避免电脑或 Ollama 重启后失效，也可以通过 macOS LaunchAgent 在登录后执行一次，并每隔 300 秒再次执行保活脚本。

四、为什么保活后还可能超时

模型保持热状态后，本机真实查询耗时约为 12.13 秒。

虽然低于 15 秒，但只剩不到 3 秒余量。机器负载稍高时，仍有可能触发超时。

在 OpenClaw 2026.7.1 中，Memory Search 的工具级超时不是配置项， 而是写死在运行时代码中的：

const MEMORY_SEARCH_TOOL_TIMEOUT_MS = 15e3;

下面的配置不能延长查询时间：

{"memory": {"timeoutMs": 60000}}

memory.timeoutMs 并不是当前版本支持的配置项。

embeddingBatchTimeoutSeconds 也只影响建立索引时的批量 embedding， 不影响 Agent 调用 memory_search 时的 15 秒限制。

五、可选方案：把 15 秒改为 60 秒

如果热查询本身已经接近 15 秒，可以临时修改 OpenClaw 的构建文件。

1. 定位文件

DIST_DIR="/usr/local/lib/node_modules/openclaw/dist"TARGET="$(rg -l 'const MEMORY_SEARCH_TOOL_TIMEOUT_MS = 15e3;' "$DIST_DIR" --glob '!control-ui/**')"printf '%s\n' "$TARGET"

2. 备份原文件

sudo cp \"$TARGET" "$TARGET.bak-$(date +%Y%m%d-%H%M%S)"

3. 将 15 秒改为 60 秒

sudo perl -0pi -e \'s/const MEMORY_SEARCH_TOOL_TIMEOUT_MS = 15e3;/const MEMORY_SEARCH_TOOL_TIMEOUT_MS = 60e3;/' "$TARGET"

检查修改结果：

rg -n 'MEMORY_SEARCH_TOOL_TIMEOUT_MS' "$TARGET"

预期看到：

const MEMORY_SEARCH_TOOL_TIMEOUT_MS = 60e3;

4. 重启 Gateway

openclaw gateway restart

提高超时时间只是让 OpenClaw 愿意多等一会儿，并不会让 embedding 模型本身变快。 如果查询经常需要几十秒，应该考虑降低机器负载，或者更换更轻量的 embedding 模型。

六、不要混淆 timeout 和 cooldown

OpenClaw 中还存在另一个常量：

const MEMORY_SEARCH_TOOL_COOLDOWN_MS = 6e4;

• Timeout：
  一次查询最多等待多久。
• Cooldown：
  查询失败后，多久再允许重试。

建议只修改 MEMORY_SEARCH_TOOL_TIMEOUT_MS， 不要随意取消 cooldown。

模型预热后，可以执行：

openclaw gateway restart

这样可以清除当前 Gateway 中已经记录的 provider 失败状态。 不重启的话，通常等待约一分钟也可以重新尝试。

七、日常自检

以后再遇到 Memory Search 超时，先执行下面三条命令。

ollama ps

openclaw memory status \--deep --agent main --json

openclaw memory search \--agent main --query "测试查询" --max-results 3 --json

主要确认三项：

• Ollama 模型的 UNTIL 是否为 Forever；
• embeddingProbe.ok
   是否为 true；
• 真实检索耗时是否稳定低于当前 timeout。

最终处理思路

1. 先确认索引和 embedding provider 是否正常。
2. 使用 keep_alive: -1 让 Ollama 模型保持驻留。
3. 通过 LaunchAgent 定时执行保活脚本。
4. 热查询仍接近 15 秒时，再把 timeout 提高到 45～60 秒。
5. 如果查询长期过慢，换用更轻量的 embedding 模型并重新建立索引。