这几天在折腾 OpenClaw的本地化部署，本以为作为多年开发老兵能一路绿灯，结果在一个“常识性”问题上卡了半天。
今天不熬鸡汤，直接分享我实操踩坑的真实记录。如果你也想用闲置电脑跑一个不花钱、保隐私的“数字员工”，这篇文章能帮你省下至少2个小时的 Debug 时间。
🚨 踩坑现场：DeepSeek-R1 的“水土不服”
当前全网都在吹 DeepSeek，我也顺理成章地通过 Ollama 在本地拉取了 deepseek-r1:8b 模型，并将其配置为 OpenClaw 的主模型。
满心欢喜地启动，准备让它帮我执行文件操作和联网搜索。结果，终端直接糊了我一脸无情的报错：
Ollama API error 400: {"error":"registry.ollama.ai/library/deepseek-r1:8b does not support tools"}
🔍 为什么会这样？（原理解析）
排查官方文档和底层逻辑后，我弄明白了原因。
我们平时在网页端和 AI 聊天，那叫“文本生成”。但在 OpenClaw 这种 Agent 框架中，AI 需要具备 Tool Calling（工具调用） 能力。它必须能理解：“哦，我现在不需要回答问题，我需要输出一段 JSON 格式的指令，去触发本地的 Python 脚本或搜索 API”。
而 deepseek-r1:8b 作为一个主打推理的模型版本，在 Ollama 的默认注册表中，并没有原生报告对 tools 的支持。OpenClaw 一旦检测到模型不具备工具调用能力，就会在执行动作环节直接拦截并报错。
💡 破局方案：退一步海阔天空
面对这个问题，有两个选择：
- 强行魔改配置，硬把不支持 tools 的模型塞进去（极容易引发后续的格式幻觉和执行失败）。
- 务实选择：换一个明确支持 Tools、且资源消耗在同一量级的模型。
从 PM 的视角来看，工具是为了解决业务问题的，而不是为了追求某个热门名词。因此，我果断切回了终端，执行了：
ollama pull qwen2.5:7b
为什么是 Qwen2.5 7B？
因为在百亿参数以下的小模型里，通义千问（Qwen）系列的 Tool Calling 能力优化得非常成熟，且 Ollama 官方库明确标识其支持工具调用。
修改 ~/.openclaw/openclaw.json，把主模型指向 ollama/qwen2.5:7b，重启 Gateway。再次下发任务，丝滑通过，成功调用本地脚本！
🎯 总结与反思
这次排坑给了我两点做“AI 副业”的启发：
- 别盲目追风口模型。 DeepSeek 的推理确实惊艳，但在特定垂直场景（比如需要充当中控大脑去调用大量 API 时），你需要的是“格式极度稳定”的模型，而不是“最聪明的做题家”。适配业务场景，永远大于盲目追求性能跑分。
- “本地化部署”的门槛依然存在。 很多人说 AI 时代不需要程序员了，但现实是：环境配置、异常兜底、API 鉴权，这些依然是当前非技术人员落地的巨大鸿沟。这也意味着，帮别人解决这些落地的技术脏活累活，本身就是一个值得挖掘的副业信息差。
后续我会继续测试不同本地模型在 OpenClaw 里的表现，并尝试搭建一套真正能帮我自动整理副业情报的自动化工作流。
如果你也在折腾 AI 落地，或者对 OpenClaw 感兴趣，欢迎关注我，一起排坑，少走弯路。
