夜雨聆风学习资料网

ARTICLE · 1130941

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

发布时间：2026-10-06 15:19:10 最近访问：2026-10-06 15:19:10
【踩坑实录】OpenClaw 更换 DeepSeek 模型后:从频频卡死到系统级排障实录

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

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

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

💥 灾难表现

  1. AI 频繁“假死”
    ：当让它执行“全面检查所有 skill”这类复合任务时，它生成了大量臆测内容，并在执行时频繁卡死，停在 🛠️ 执行命令 的界面毫无动静。
  2. 逻辑混乱与“暴力美学”
    ：它会一次性吐出十几条超长组合命令（如全盘 find、包含分页的 journalctl），最终把 Agent 本身卡死在超长命令链中。
  3. 记忆系统崩溃
    ：网关日志反复弹出 Recall strategy "hybrid" requires EmbeddingService but it is not available.，我的同志完全丢失了上下文记忆。

二、 抽丝剥茧：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.modelsed -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。
  • 解决方案
    ：
    # 一键安装 Ollamacurl -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 jsonp='/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 文件中加载。
  • 解决方案
    ： 
    1. 在 ~/.openclaw/.env 中补全密钥。
    2. 确认 openclaw.json 中该 skill 的 enabled 状态为 true。
    3. 手动重启网关，日志显示 [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 条铁律

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

  1. AI 的报告再漂亮，也必须用“证据”校验
    。 大模型天然有“幻觉”倾向。初期它列出的 16 个 Skill 状态，大量是臆测。只读命令、原始日志输出（脱敏）、which 结果，是唯一的事实来源。
  2. “改配置”与“重启服务”必须解耦
    。 切勿让 Agent 自己执行 systemctl restart。AI 意识不到它正在杀死自己的宿主进程。配置修改必须交由后台 SSH 脚本或人工完成。
  3. 长上下文是国产模型的软肋，工具调用需“碎片化”
    。 替换为 DeepSeek 后，大模型倾向于生成超长组合命令链。这极易触发网关超时。必须通过系统提示词严格限制：“每轮最多 3 条命令，输出不超过 100 行”。
  4. 第三方插件是深水区，保持敬畏
    。 原本以为换个 Embedding 模型就行，结果被第三方记忆插件拦截。能用内置核心组件（如 memory-core）配合成熟的外部工具（如 Ollama），就不要去折腾冷门插件。

五、 最终战报

经过一系列的手术，我们在 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、本文基于真实排障经历整理，未经授权禁止转载。部分命令已做脱敏处理，实际操作请结合自身环境。

相关学习资料