ClawdBot保姆级部署指南：构建7x24小时在线的私人AI助手

折腾了这么多年自托管服务，我越来越觉得，真正好用的 AI 助手不是装个 App 那么简单的。你需要的其实是一个能 7x24 小时在线、能接入你常用的聊天工具、能自由切换云端模型和本地模型的服务端机器人。ClawdBot 就是干这个的。

这篇 ClawdBot 安装指南，我会从零开始，把环境准备、配置项、启动守护、问题排查全部过一遍，保证你照着做就能把 ClawdBot 跑起来，得到一个真正属于自己的 24/7 私人 AI 助手。它适合有一定服务器基础、但又不想看一堆英文文档就动手折腾的人；如果你完全没接触过 Docker 和命令行，这篇文章也能带着你一步一步来，不会让你卡在第一步。

1. 为什么选 ClawdBot？先把这个项目的定位和价值看清楚

1.1 ClawdBot 不是聊天页面，而是常驻服务端的调度中枢

市面上 AI 工具非常多，但大部分是给人“打开网页点一点”的。ClawdBot 不一样，它是一个常驻在你自己机器上的服务进程，像一个 7x24 小时不休息的“机器人管家”：你通过 Telegram、Web 页面或者企业聊天工具给它发消息，它把请求交给配置好的大模型处理，再把结果通过同一个渠道回给你。

拆开看，ClawdBot 在架构上分四层：接入层负责对接各种消息渠道和管理界面；调度层负责决定这次请求该用哪个模型；推理层负责真正调用云端 API 或者本地模型；存储层负责把会话记录、日志和用户配置持久化下来。这个分层非常关键，它决定了 ClawdBot 不是一个“套壳客户端”，而是一个可扩展的 AI 基础设施。

我打个比方：ClawdBot 像一个公司的前台。你各种渠道的消息都是“来访的客人”，前台先接待，再根据客人要办的事分给对应部门。部门就是各种模型，云端 API 是外包专家，本地模型是自家团队。

1.2 适合谁用？三个能直接抄作业的场景

第一类是个人知识助理。你私聊它丢一篇长链接，让它帮你总结并生成要点；或者设置每天早上的定时任务，让它把行业新闻、邮件摘要整理好推送到你的聊天工具里。这比打开各种 App 挨个看高效得多。

第二类是家庭或小团队共享助手。一个 ClawdBot 实例注册多个用户，每个人有独立的会话记录，管理员可以限制谁能用、一天能用多少次。这相当于把“一个人私聊 ChatGPT”升级成“一个小团队共用的 AI 服务台”，成本比挨个开会员划算。

第三类是技术玩家的模型网关。热搜词里常提“AI 代理助手加本地模型”，ClawdBot 正好就是这个定位。你可以同时配置多家模型服务商的 API 和本地 Ollama 模型，再根据消息类型、用户级别、模型负载做路由。比如白天用云端大模型保效果，晚上用本地模型省钱保隐私。这种玩法才是这类项目真正的价值所在。

2. 环境准备：跑 ClawdBot 需要什么底子

2.1 硬件配置下限与推荐部署方式

先说结论：如果你只跑 ClawdBot 本体、不跑本地模型，2 核 CPU、2GB 内存的小机器就够了，树莓派、老笔记本、NAS、云主机都能带得动。如果你要跑本地模型，那配置就得看模型体积。

我做过一张配置对照表，基本可以照着选：

操作系统的选择上，Linux 最顺手，Ubuntu 22.04/24.04 我都试过。macOS 可以用 Docker Desktop 跑，Windows 建议用 WSL2。如果你是群晖、威联通用户，直接用 Docker 套件装镜像也完全没问题。

2.2 Docker 和 Python 运行时怎么装

ClawdBot 官方文档提供了两种方式：Docker 镜像部署和源码部署。我个人强烈建议 Docker，原因有三点：依赖隔离不会污染宿主系统；升级时只需替换镜像；配合 systemd 和 docker compose 重启恢复非常方便。

先确认 Docker 是否就绪，执行：

docker --version docker compose version

如果没装，Ubuntu 上可以这样快速安装：

apt update apt install docker.io docker-compose-plugin systemctl enable --now docker

源码部署方式则要求 Python 3.10 或更高版本，然后创建虚拟环境：

git clone <ClawdBot 官方仓库地址> clawdbot cd clawdbot python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt

仓库地址和具体依赖清单以官方 README 为准，我这里写的是通用流程。你如果之前装过 Python 3.11/3.12，也可以直接用，兼容性基本没问题。

3. 保姆级配置：把 ClawdBot 调通的关键步骤

3.1 第一步：复制 .env 配置文件

ClawdBot 采用环境变量管理配置，这是所有自托管服务里最常规、也最不容易出错的做法。刚拉完仓库或镜像后，先把示例配置复制成正式配置：

cp .env.example .env

打开 .env 后，你会看到密密麻麻的参数。别慌，真正必须改的只有几项。我的原则是：开荒阶段只改必填项，跑通了再回头调优可选参数。所有带_KEY、_SECRET、_TOKEN的字段都属于敏感信息，千万不要提交到 Git 仓库，也别截图发到群里。

提示：建议把.env文件的权限收紧，执行chmod 600 .env。我见过很多教程忽略这一步，一旦服务器被扫到，密钥泄露就是分分钟的事。

3.2 第二步：接入云端模型 API

ClawdBot 本身不生产模型，它负责调度模型。所以要让它“开口说话”，第一步是配置一个模型来源。

在 .env 里通常会看到类似这样的字段：

# 模型服务商类型：openai / anthropic / dashscope / zhipu / deepseek 等 MODEL_PROVIDER=deepseek # 模型名称，例如 deepseek-chat MODEL_NAME=deepseek-chat # 模型服务商提供的 API Key MODEL_API_KEY=sk-xxxxxxxxxxxx # 可选的 API Base URL，保留默认即可 MODEL_BASE_URL=

配置逻辑很简单：MODEL_PROVIDER决定 ClawdBot 用哪种协议去调模型，MODEL_API_KEY是你在模型服务商官方平台申请的密钥，MODEL_NAME对应你实际要用的模型版本。申请 API Key 时记得在服务商后台配置好额度限制和 IP 白名单，这是最基本的安全习惯。

这里要特别说明一下“AI 代理助手”这个词：ClawdBot 这一类项目确实可以叫 AI 代理助手，但此“代理”是模型调度代理的意思——它把你的请求转发给不同的模型服务商，而不是网络层面的代理。论文里、官方文档里说的都是这个意思，别误解。配置好之后，你可以先用 curl 验证一下 Key 是否有效、网络是否可达，再启动 ClawdBot。

curl <模型服务商兼容接口地址> \ -H "Authorization: Bearer $MODEL_API_KEY" \ -d '{"model":"MODEL_NAME","messages":[{"role":"user","content":"ping"}]}'

能正常返回一段文本，就说明模型通道是通的。

3.3 第三步：接入本地模型（Ollama 实战）

接入本地模型是很多人部署 ClawdBot 的核心目的，核心原因是数据隐私和长期成本。本地模型的安装我用 Ollama 举例，因为它对新手最友好。

第一步，安装 Ollama：

curl -fsSL https://ollama.com/install.sh | sh

第二步，拉取一个适合你硬件的模型。以 7B 档位的通义千问为例：

ollama pull qwen2.5:7b

第三步，确认服务在监听：

ollama serve curl http://localhost:11434/api/tags

最后，回到 ClawdBot 的 .env，把模型来源切到本地：

MODEL_PROVIDER=ollama MODEL_NAME=qwen2.5:7b OLLAMA_BASE_URL=http://localhost:11434

如果你是用 Docker 跑 ClawdBot，这里有个巨坑：容器里的localhost和宿主机不是同一个网络。Docker 容器要访问宿主机的 Ollama，得把地址写成http://host.docker.internal:11434（macOS/Windows 桌面版支持），或者直接写宿主机局域网 IP：

OLLAMA_BASE_URL=http://192.168.1.10:11434

本地模型接入后，建议做一次模型切换测试：让 ClawdBot 先用云端模型回一条“你是谁”，再切到本地模型回一条，对比延迟和回答质量。不同模型的差异感受会比看任何评测都直观。

3.4 第四步：绑定消息渠道

ClawdBot 最舒服的使用方式不是蹲在服务器前看命令行输出，而是把它绑到你每天都在用的聊天工具里。以 Telegram 为例，流程是这样：

先找 BotFather 创建一个 Bot，拿到 token。然后把 token 填进 .env：

TELEGRAM_BOT_TOKEN=123456:ABC-DEF... TELEGRAM_ALLOWED_USER_IDS=你的用户ID TELEGRAM_ENABLE=true

ALLOWED_USER_IDS这个白名单一定不要漏，否则你的机器人会被全网用户玩坏。获取自己 Telegram 用户 ID 最简单的办法是私信 @userinfobot。

其他渠道的配置逻辑大同小异，无非是“获取平台凭证”加“填写回调地址”。ClawdBot 同时支持多个渠道，你可以把 Telegram 用于个人助理、钉钉用于团队协作、Web 控制台用于后台管理。一个后端，多个前端，数据还互通，这种体验比较接近商业产品的形态了。

提示：如果渠道配置的是异步消息回调，注意在 ClawdBot 后台的访问地址里填写公网可达的地址，并配置好 HTTPS。很多渠道平台要求 Webhook 地址必须带证书，临时自签名证书会被直接拒绝。

4. 启动、守护与 24/7 运行

4.1 首次启动验证链路

配置填完了，接下来启动。用 Docker Compose 的方式最省心：

docker compose up -d tail -f logs/ClawdBot.log

日志里出现“service started”或“bot is running”之类的字样，说明进程起来了。别高兴太早，还要完成三件事才算稳：

第一，给 Bot 发一条普通消息，等回复；第二，检查回复是否走通了“消息渠道 -> 调度层 -> 模型 -> 回传”的完整链路；第三，发一条定时任务指令，看它能否按预定的 cron 表达式执行。注意看定时任务触发时，日志里有没有记录任务 ID，方便以后排查。

如果你的部署环境开了防火墙，记得把 ClawdBot Web 控制台的端口放行，但千万别把端口直接暴露到公网，自己用就套个简单认证，别裸奔。

4.2 systemd 守护与开机自启

很多新手喜欢nohup python main.py &这样挂着，进程一崩就彻底失联，重启服务器后忘记手动拉起，又跑一趟机房。24/7 服务必须用守护进程管理。

nohup不是不能用，而是不足以应对“崩溃自动拉起”“开机自动启动”这类现实需求。systemd 功能强且天然具备这些能力。

源码部署版的服务文件写成一个 systemd unit：

[Unit] Description=ClawdBot AI Assistant After=network-online.target Wants=network-online.target [Service] Type=simple User=root WorkingDirectory=/opt/clawdbot ExecStart=/opt/clawdbot/.venv/bin/python main.py Restart=always RestartSec=10 EnvironmentFile=/opt/clawdbot/.env [Install] WantedBy=multi-user.target

Docker Compose 部署版也可以让 systemd 来管，Unit 是这样的：

[Unit] Description=ClawdBot Docker Compose Requires=docker.service After=docker.service [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/opt/clawdbot ExecStart=/usr/bin/docker compose up -d ExecStop=/usr/bin/docker compose down [Install] WantedBy=multi-user.target

然后统一用这两条命令启用并启动：

systemctl daemon-reload systemctl enable --now clawdbot

我现在所有自托管服务都是用这套玩法，nohup 基本退役了。

4.3 日志监控与资源管理

服务跑起来之后，日常运维主要就两件事：看日志和盯资源。源码部署版看日志用这个：

journalctl -u clawdbot -f

Docker 部署版则是：

docker logs -f clawdbot docker stats

日志多了之后要记得轮转，Docker Compose 里加logging配置：

services: clawdbot: logging: driver: "json-file" options: max-size: "50m" max-file: "3"

这样日志不会把磁盘撑爆。如果搭配 Grafana 或 Prometheus 做指标监控，也不是不行，但个人用有点重，我建议先把手动排查流程跑熟，再考虑上监控。

5. 常见问题与避坑实录

5.1 问题速查表

把我在部署过程中遇到过的、以及被朋友反复问到的问题整理成了一张速查表，照着排查能省不少时间：

5.2 我踩过最深的三个坑

坑一：数据卷没有持久化。最早我用 Docker 跑 ClawdBot，docker compose up -d 一把过，还很兴奋。结果后来更新镜像，容器一删，会话记录、白名单配置全没了，瞬间回到解放前。现在我会在 compose 文件里强制挂载数据目录：

volumes: - ./data:/app/data

坑二：本地模型并发设太高，把服务器搞 OOM。7B 模型本来就吃显存，我一上来把并发调到 16，结果整个机器直接卡死，只能强制重启。后来把本地模型的并发数老老实实调到 2，云端 API 的并发逻辑和本地模型分开配置，才稳定下来。运行本地模型前建议先执行：

ollama ps

随时观察模型占用内存情况，OOM 前一般有预兆。

坑三：时区没设置，定时任务全错乱。有一次我发现每天早上 8 点的新闻摘要一直不推，查了半天才发现容器时区是 UTC，我配置的 8 点其实是 UTC 8 点，换成上海时间已经是下午了。解决很简单，在 .env 里加一行：

TZ=Asia/Shanghai

然后重启服务。所有定时任务都对齐你手机上的时间，再也不会错乱了。

我个人折腾下来最大的体会是：ClawdBot 这种项目的价值不在于“又多了一个能聊天的东西”，而在于它把零零散散的模型能力统一成了一个可以随时调用的基础设施。你不需要记住每个模型在哪调、每个渠道怎么接，一个 ClawdBot 全部搞定。

如果你已经把它跑通了，建议下一步试试接入更多渠道、把本地模型和云端模型的路由规则做精细一点，甚至可以把它接到智能音箱、NAS 或者自动化工作流里。折腾的过程本身就是最有意思的部分。希望这篇保姆级安装指南能帮你少走点弯路，动手去搭一个真正属于你自己的 24/7 私人 AI 助手。