OpenClaw 部署与故障修复全记录

最近几天在折腾 OpenClaw 助手服务，记录一下整个过程和遇到的问题。

一、背景介绍

OpenClaw 是一个强大的 AI 助手框架，支持多平台、多模型接入。本次部署主要为了搭建一个稳定的 AI 对话服务，连接 Telegram 与各种大模型 API。

二、服务器概况

本次部署了两台 OpenClaw 服务器：

• 主控服务器：systemd 管理，负责主要调度
• 远程服务器：运行本地 GLM 模型 API，提供推理服务

三、API Provider 配置详解

1. local（本地模型）

• 模型：GLM-5、GLM-4.7
• 用途：主要对话模型，响应速度快

2. chao（EdgeFn API）

• 模型：GLM-4.7
• 用途：备用模型，提供更稳定的推理服务

3. nvidia（NVIDIA NIM）

• 模型：Llama 3.3 70B、DeepSeek V3.1 等
• 用途：高端模型备选

4. openrouter（OpenRouter）

• 模型：免费模型池
• 用途：免费模型试用

四、故障排查与修复

问题描述

远程服务器上的 OpenClaw 在收到 Telegram 消息后，持续返回 400 status code (no body) 错误，无法正常回复用户。

排查过程

1. 检查 API 服务是否正常运行 – 确认本地 API 工作正常
2. 检查网络连通性 – 确认网络畅通
3. 直接调用 EdgeFn API 测试 – 返回正常
4. 查看详细日志 – 发现是 OpenClaw 与 EdgeFn API 的兼容性问题

根本原因

EdgeFn API 的 GLM-4.7 模型返回的响应格式比较特殊：

• content：空字符串
• reasoning_content：实际的推理内容

当 OpenClaw 配置文件中开启 reasoning: true 时，尝试处理这种格式失败，导致 400 错误。

解决方案

将模型配置中的 reasoning 设置为 false

五、自动维护配置

Cron 任务

添加了定时任务，每 5 分钟自动清理会话存储

六、经验总结

• 配置兼容性：OpenClaw 配置文件有严格的 schema，不是所有 JSON 键都支持
• 进程管理：多进程容易导致端口冲突，建议统一使用 systemd 管理
• API 兼容性问题：不同模型 API 的响应格式可能存在差异，需要针对性调整配置
• 日志查看：使用 journalctl 可以实时查看服务日志