一、背景与目标
本文记录一次基于 OpenClaw 构建微信 AI 助手的完整部署过程。核心诉求包括：
– 支持微信通道的消息收发
– 具备联网搜索能力（DuckDuckGo/Brave）
– 兼顾本地隐私（Ollama）与云端性能（DeepSeek）
– 稳定运行，避免频繁重启或配置失效
实际落地过程中，我们遭遇了显存瓶颈、JSON 配置校验失败、认证机制冲突、上下文溢出及网络代理穿透等多类问题。下文将从技术视角逐层剖析根因，并提供可复现的解决方案。
二、核心问题剖析
1. 本地推理性能瓶颈：显存容量与模型规模的错配
现象：使用 Ollama 运行 qwen3:8b 时，单次对话响应时间超过 3 分钟，网关日志无报错。
诊断：执行 ollama ps 观察到 PROCESSOR: 33%/67% CPU/GPU，表明模型权重（约 10GB）无法完全载入 8GB 显存，触发 CPU Offloading。
结论：消费级显卡（≤8GB 显存）不适合运行 8B 及以上规模的稠密模型。
2. 配置管理风险：人工编辑 JSON 的不可靠性
现象：修改 openclaw.json 后，网关启动失败并报 Invalid config。
根因：OpenClaw 采用严格的 JSON Schema 校验。
解决方案：优先使用 CLI 工具维护配置，避免直接手写 JSON。
3. 认证机制误解：Unauthorized 并非服务故障
现象：访问 http://127.0.0.1:18789 返回 Unauthorized。
根因：OpenClaw 启用了 Token 认证。
验证方法：netstat -ano | findstr 18789
4. 上下文工程缺失：长会话导致溢出
现象：微信对话持续后，AI 停止响应，日志报 Context overflow。
根因：DeepSeek 上下文窗口有限，长会话历史累积超限。
解决方案：短期 /new，长期配置 contextWindow。
5. 网络代理穿透：Node.js 进程的环境隔离
现象：web_search 持续超时，但浏览器可正常访问外网。
根因：Windows 系统代理不自动透传给 Node.js 进程。
解决方案：启动前注入 HTTP_PROXY 环境变量。
三、最终稳定架构
– 主模型：DeepSeek API
– 兜底模型：Qwen3:4b（可选）
– 搜索工具：Brave Search
– 通道：微信
– 认证：开发阶段建议关闭
四、经验总结
1. 硬件评估优先：8GB 显存避免 8B+ 模型
2. 配置即代码：用 CLI 而非手写 JSON
3. 认证分层：开发禁用 Token
4. 上下文管控：长连接需 /new
5. 网络透传：显式设置 HTTP_PROXY
6. 服务清理：重启前 taskkill
五、结语
接受本地轻量 + 云端强力的混合架构，技术选型服务于可用性。
