【踩坑实录】OpenClaw 更换 DeepSeek 模型后：从频频卡死到系统级排障实录

一、 背景与灾难现场：好端端的为什么要换模型？

我的 OpenClaw 运行在一台 Ubuntu 服务器的 systemd 服务上，主力交互通道是微信 ClawBot（日常我称它为“同志”）。

基于成本考量，我决定将底层模型替换为性价比极高的 DeepSeek。原以为只是改个 BaseUrl 和 API Key 的小事，没想到却打开了潘多拉魔盒。

💥 灾难表现

二、 抽丝剥茧：9 大核心坑点与排障实战

遇到灾难不要慌，优先看日志。通过 SSH 登录服务器，执行 journalctl –user -u openclaw-gateway –no-pager | grep -iE "error|model|fallback"，我们开始一步步填坑。

🔴 坑点 1：模型隐式 Fallback，导致长上下文卡死

• 表现：日志疯狂报错 Model "deepseek-chat" specified without provider. Falling back to "openai/deepseek-chat".。DeepSeek 的模型没被识别为独立 Provider，被降级到了 openai 通道下，处理长文本时链路极不稳定，极易卡断。
• 解决方案：在 ~/.openclaw/openclaw.json 中，将 agents.defaults.model 从 "deepseek-chat" 修正为带 Provider 前缀的 "openai/deepseek-chat"。
• 实战命令（操作前注意备份）：cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.model
  sed -i 's/"model": "deepseek-chat"/"model": "openai\\/deepseek-chat"/g' ~/.openclaw/openclaw.json

🔴 坑点 2：AI 自己重启自己，触发 SIGTERM 死循环

• 表现：让 AI 改完配置后，它执行了 systemctl –user restart openclaw-gateway。因为重启会杀死承载对话的网关进程，它把自己“杀”掉了，日志都来不及回传，直接失联。
• 解决方案：绝对不要在大模型对话中执行重启网关的命令！ 修改配置后，必须由开发者在 SSH 终端手动执行 systemctl –user restart openclaw-gateway。

🔴 坑点 3：Embedding 模型用错，记忆系统瘫痪

• 表现：解决模型后，报错 EmbeddingService is not available.。
• 排查：检查配置，发现 memorySearch 的模型竟然也是 openai/deepseek-chat。对话模型不能做向量化（Embedding）！这就是记忆检索崩溃的元凶。
• 解决方案：需要引入真正的 Embedding 模型。

🔴 坑点 4 & 5：本地 llama-cpp 插件失败，转投 Ollama

• 表现：尝试安装 llama-cpp 本地插件，虽然显示安装成功，但在网关实际启动的插件列表中静默消失了。
• 排查与破局：检查系统发现，系统根本没装 Ollama 服务（Unit ollama.service could not be found）。果断放弃折腾 llama-cpp，转用相对稳妥的 Ollama。
• 解决方案：# 一键安装 Ollama
  curl -fsSL https://ollama.com/install.sh | sh
  # 拉取轻量级向量化模型
  ollama pull nomic-embed-text

  然后将配置改为指向本地的 OpenAI 兼容接口："memorySearch": {
  "enabled": true,
  "provider": "openai-compatible",
  "model": "nomic-embed-text",
  "remote": {
  "baseUrl": "http://127.0.0.1:11434/v1",
  "apiKey": "ollama"
  },
  "fallback": "none"
  }

  💡验证妙招：使用 curl http://127.0.0.1:11434/v1/embeddings … 确认本地接口能正确返回向量数组。

🔴 坑点 6：第三方记忆插件“占山为王”

• 表现：即使配置了 Ollama，EmbeddingService 依然报错。
• 排查：日志显示插件列表里是 memory-tencentdb（某第三方记忆插件），而非内置的 memory-core。该第三方插件不读取全局 memorySearch 配置，一直在用自己错误的内部逻辑单干。
• 解决方案：直接禁用捣乱的第三方插件，让核心插件接管。# 使用 python 安全修改 json 配置，禁用该第三方记忆插件
  import json
  p='/home/user/.openclaw/openclaw.json'
  c=json.load(open(p))
  if 'plugins' not in c: c['plugins'] = {}
  if 'entries' not in c['plugins']: c['plugins']['entries'] = {}
  c['plugins']['entries']['memory-tencentdb'] = {'enabled': False}
  json.dump(c, open(p,'w'), indent=2, ensure_ascii=False)

🔴 坑点 7：历史残留引发“插件白名单警告”

• 表现：日志反复提示 plugins.allow is empty; discovered non-bundled plugins may auto-load…。
• 解决方案：在配置中显式添加 plugins.allow 白名单，将 lightclawbot、ollama、memory-core 等受信任的插件加进去。

🔴 坑点 8：环境变量未注入，微信发布 Skill 哑火

• 表现：排查微信公众号发布 skill wechat-publisher 时，发现其依赖的 WECHAT_APP_ID 和 WECHAT_SECRET 并没有在 .env 文件中加载。
• 解决方案：
• 在 ~/.openclaw/.env 中补全密钥。
• 确认 openclaw.json 中该 skill 的 enabled 状态为 true。
• 手动重启网关，日志显示 [openclaw-weixin] config cached，环境打通。

🔴 坑点 9：工具链设计严谨，主动放弃“群发测试”

• 表现：准备测试公众号发布时，查阅 wenyan publish –help 发现，该 CLI 没有任何草稿箱（–draft）或预览选项。一旦执行，就是直接向所有粉丝群发。
• 解决方案：出于平台合规考量，主动叫停实际发布测试。 环境配置已完成，调用链路就绪，但实际发布需人工极度谨慎，切勿盲目自动化测试。这也提醒我们，调用涉及外部平台（特别是微信生态）的 API 时，务必守住合规底线。

三、 终极清理：理清“半死不活”的 Skill 资产

排障最后，回归最初的诉求：“全面检查所有 skill”。

通过 find ~/.openclaw/workspace/skills/ -maxdepth 3 -name "SKILL.md" | sort，我们理清了真正的 SKILL 目录。

• 冗余归档：将重复目录、乱码安装残留、废弃的副本物理移入 backup 文件夹。
• 配置禁用：利用 Python 脚本，将 tencent-docs、github、tavily-search 等未装底层依赖或缺失 API Key 的“僵尸”skill 全部设为 enabled: false，避免未来污染日志。

四、 复盘与升华：AI Agent 开发者的 4 条铁律

经历了这次“抢救”，我从单纯的“应用者”变成了“底层维护者”。总结出以下血泪经验：

五、 最终战报

经过一系列的手术，我们在 SSH 终端敲下 journalctl，看到了极度清爽的启动日志：

Sep 16 18:23:23 [gateway] http server listening
(7 plugins: browser, lightclawbot, memory-core, ollama, openai, openclaw-weixin, qqbot; 1.7s)

没有报错，没有 Fallback，没有 Embedding 缺失。OpenClaw 不仅恢复了正常，而且比换成 DeepSeek 之前更健康、更可控。

写在最后：
如果你也在折腾本地 AI Agent 或 OpenClaw，遇到模型替换后卡死，不要慌。先看日志，查 Provider，查 Embedding，管住重启，清理冗余。你的 AI 会活过来的！

⚠️ 免责声明：
1、本文仅记录个人服务器环境下的技术排障过程，涉及的所有命令及脚本仅供学习交流。
2、本文基于真实排障经历整理，未经授权禁止转载。部分命令已做脱敏处理，实际操作请结合自身环境。