用Clawdbot和Qwen搭建7x24小时AI助理：从Docker部署到实战踩坑

1. 先说清楚：为什么我需要一个 7x24 的 AI 助理

你要是跟我一样，电脑里躺着十几个模型，手机上装了四五个 AI 应用，但真正干活的时候总感觉差一步——不是模型不够聪明，而是它们都太“被动”了。你得打开网页、输入提示词、等它回答，然后复制粘贴，这一套流程走下来，三分钟过去了，只解决了一个小问题。

所以我一直想搭一个常驻后台的 AI 助理：能接收消息自动回复，能定时干活，能处理一些重复性事务，最好还能通过对话直接操作我自己的工具链。这听起来像科幻，但实际做起来就是一个开源机器人程序加上一个大模型 API。我把这个组合叫“私人大内参”，白天帮我对接工作流，晚上挂着帮我整理日报，真正做到 7x24 小时不下班。

这次选的两件套是 Clawdbot 和 Qwen。

Clawdbot 是一个可以把大模型接到即时通讯、任务队列和自动化流程里的机器人框架，部署起来很轻，一条命令就能跑。Qwen 是当前开源和 API 两条线都做得比较均衡的模型系列，尤其是阿里云百炼平台提供的 DashScope API，新用户有免费额度，日常个人使用基本花不了几个钱。

这篇文章就是完整的部署记录。我会从环境准备讲到容器启动，从接入 Qwen 讲到进程守护，最后附上我踩过的坑。适合谁看？想给团队或自己搭 AI 助理的人，懂一点 Docker 但没搞过完整部署的人，还有想在周末花 10 分钟搞一个能一直跑着的东西的人。

2. 部署前的三件事：设备、Docker 和网络规划

2.1 设备选型：不是越贵越好，但要能一直开机

Clawdbot 本身只是一个调度壳子，不真正跑大模型推理。真正出力的地方在 Qwen 那边，要么走云端 API，要么你本地单独用 vLLM 或 Ollama 拉一个 Qwen 模型。所以我跑的这台机器不需要高端显卡，2 核 4G 的云服务器、树莓派、老笔记本，甚至一台能跑 Docker 的 NAS 都行。

我自己用的是家里一台闲置的迷你主机，Intel N100 处理器，16G 内存，装了 Ubuntu 22.04，功耗很低，一个月电费也就几块钱。之所以强调“能一直开机”，是因为 7x24 助理最怕的不是性能不够，而是断电重启之后没人管。后面我会专门讲守护进程。

如果你已经有云服务器，不管哪家的轻量应用服务器，只要系统是 Debian 或 Ubuntu，都能直接照做。Windows 用户也别慌，Docker Desktop 装好之后，命令基本一样，只有后面 systemd 那部分需要换成计划任务（NSSM 之类的工具），我会在对应位置标注。

2.2 Docker 和 Compose 插件：这是唯一绕不开的依赖

Clawdbot 官方最推荐的方式就是容器化部署，因为它的依赖项里有 Node.js 运行时、Python 子进程、Redis 缓存，手动装的话版本冲突能折腾一晚上。Docker 可以把这些全部隔离在一个镜像里，升级就是重新拉一次镜像，回滚就是切回旧标签，省心。

安装 Docker 我建议用官方脚本，注意别用系统自带的旧版本源。

bash复制curl -fsSL https://get.docker.com | bash -
systemctl enable --now docker

Compose 插件在 Ubuntu 新版源里通常自带。验证一下：

bash复制docker compose version

如果提示找不到命令，装一下：

bash复制apt-get update && apt-get install -y docker-compose-plugin

这里有个小经验：不要用 docker-compose 这个老命令，也不要单独装 Python 版的 docker-compose。 新项目统一用 docker compose 子命令，配置格式也更规范。

2.3 网络规划：提前想好端口和域名

Clawdbot 跑起来后会暴露两个东西：管理面板 Web 端口和机器人回调端口。默认可能是 3000 和 8000 之类，但我建议你在部署之前就定好一个固定端口，比如我用的是 18080 做管理面板，18081 做 Webhook 回调。

原因很简单：如果之后接入即时通讯（比如飞书、钉钉、Telegram），回调地址必须是公网可达的。如果你用的是云服务器，需要在安全组里放行这两个端口；如果你在家里跑，最好配一个内网穿透工具，但我个人不推荐把家庭设备的端口直接暴露到公网，做一个带认证的反代更稳妥。

3. 开始部署：10 分钟跑起 Clawdbot 容器

3.1 拉取项目配置，别自己手搓 yaml

Clawdbot 项目仓库里有一个 docker-compose.yml 示例，我的建议是直接把它克隆下来作为基础，不要在什么都不看的情况下凭感觉写配置。因为不同版本的环境变量名会有差异，官方示例永远是最新的。

bash复制git clone https://github.com/clawdbot/clawdbot-deploy.git
cd clawdbot-deploy

如果没有 git，也可以直接在 Release 页面下载打包好的部署目录，里面通常包含 .env.example、docker-compose.yml、Dockerfile 三件套。

3.2 配置 .env：这是最核心的一步

部署目录下复制一份环境变量文件：

bash复制cp .env.example .env
vim .env

我用的最简配置长这样，注意每一项都解释一下，不然你填的时候会心虚：

env复制# 管理面板的本地访问地址
APP_PORT=18080
# 回调端口，具体看你的渠道要求
WEBHOOK_PORT=18081
# 这个密钥用于保护管理面板和管理接口
ADMIN_TOKEN=请换成一段随机字符串
# 当前环境名称，不影响功能，但日志里会显示
NODE_ENV=production
# 默认时区
TZ=Asia/Shanghai

生成随机字符串的方法用系统自带命令就行：

bash复制openssl rand -hex 32

为什么要单独配一个 ADMIN_TOKEN 而不是用默认的？因为 Clawdbot 的管理面板能查看日志、修改机器人配置、手动触发任务，如果端口不小心被扫到，默认 token 等于裸奔。我用 1Password 生成了一串，然后存在密码管理器里，服务器上不留明文副本。

3.3 启动容器：第一次跑起来注意看日志

配置写好后，执行：

bash复制docker compose up -d
docker compose logs -f

第一次启动会拉取镜像，速度取决于网络。等日志里出现“server running on port 18080”之类的字样，就说明起来了。

这时候打开浏览器访问 http://服务器IP:18080，输入 ADMIN_TOKEN 进入管理面板。如果页面打不开，先别急着怀疑配置，用 docker ps 看下容器状态是不是 Up。 很多时候是端口没放行或者镜像没拉完。

我实测从拉取仓库到面板可访问，总共用了不到 8 分钟。如果你卡在镜像拉取那一步，可以配一下镜像加速源，这个在 Docker 的 /etc/docker/daemon.json 里加 registry-mirrors 即可。

3.4 验证机器人“本体”是否健康

面板能开只是第一步，还要确认 bot 内部组件正常。Clawdbot 跑起来后会依赖 Redis 做队列缓存，如果 Redis 没起来，你发消息他会“装死”。所以部署完先看一眼整体状态：

bash复制docker compose ps

正常情况会看到 app、redis、worker 这几个服务都是 Up。如果 worker 反复重启，看一下日志是不是连不上 Redis，这类问题通常出现在内存不足的机器上，给 Redis 容器加个 mem_limit: 256m 就能缓解。

4. 接入 Qwen：让助理真正有脑子

4.1 先理解 Clawdbot 是怎么调用模型的

很多人以为 Clawdbot 是内置了模型，其实不是。它的角色更像一个“调度员”：收到消息后，把对话历史和工具定义打包发给模型，模型返回下一步动作，机器人再执行。所以要让 Clawdbot 跑起来，关键不是安装模型，而是填对一个模型 API 的地址和密钥。

Clawdbot 在模型接入层兼容 OpenAI 的协议格式，这意味着任何提供“OpenAI 兼容接口”的大模型服务都能直接接。Qwen 的云端服务 DashScope 正好就提供了这种兼容模式，这点是它接入起来特别顺手的原因。

4.2 开通 Qwen API 并拿到密钥

去阿里云百炼平台，用支付宝或淘宝账号就能登录。找到 DashScope，开通模型服务。个人用户实名认证之后，平台会赠送一定的免费额度，具体以页面显示为准，但日常测试完全够用。

在控制台的 API-KEY 管理里创建密钥，格式是一串 sk- 开头的字符。拿到之后把它存到上面说过的 .env 里：

env复制# Qwen 的 OpenAI 兼容模式地址
LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
LLM_API_KEY=sk-你的密钥
# 模型名，推荐 qwen-plus，兼顾速度和效果
LLM_MODEL=qwen-plus

这里的 base_url 是常见坑点。很多人习惯性地填 https://dashscope.aliyuncs.com，结果报 404。必须带 /compatible-mode/v1 这个前缀，因为这是 DashScope 专门为 OpenAI 兼容客户端保留的路由。

4.3 模型选择：qwen-turbo 还是 qwen-plus，不只是钱的事

Qwen 系列目前个人使用最多的两个型号是 qwen-turbo 和 qwen-plus。turbo 便宜、响应快，适合处理日志、简短的提问；plus 更聪明，适合写代码、分析长上下文。

我给 Clawdbot 配的是 qwen-plus，因为 AI 助理在对话时经常需要理解多轮上下文，turbo 在复杂指令上的表现差距比较明显。

如果你跑的是本地模型，比如用 Ollama 拉一个 qwen2.5:7b，那 base_url 就填 http://主机IP:11434/v1，模型名填 qwen2.5:7b。协议也是兼容的。不过本地版对机器内存要求不低，7B 模型建议 16G 内存以上，不然对话速度会很痛苦。

4.4 在管理面板里绑定模型

拿到密钥、填好 .env 后，重启服务让配置生效：

bash复制docker compose restart

然后在管理面板里找到模型配置页，确认默认模型已经切换成 qwen-plus。这一步我吃过亏：环境变量虽然改了，但面板里之前手动选过另一个模型，导致聊天一直走的旧配置，日志里排查半天才找到原因。所以在面板里也要同步改。

5. 7x24 小时运行的关键：守护进程、自动重启和日志管理

5.1 容器重启策略：docker 层面先兜底

Docker 本身支持重启策略，这是第一层防线。在 docker-compose.yml 里给服务都加上：

yaml复制restart: unless-stopped

这个策略的意思是：容器异常退出会自动拉起，但如果你手动 stop，它不会被拉起。这个语义很适合长驻服务，日常维护时手动停容器不会被反复拉起干扰。

5.2 systemd 兜底：机器重启后自动恢复

重启策略只能防容器崩溃，防不了服务器重启后 Docker 没启动的情况。虽然 Docker 服务默认会开机自启，但加上一层 systemd 服务更安心。我写了一个简单的服务单元：

ini复制[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
StandardOutput=journal

[Install]
WantedBy=multi-user.target

放在 /etc/systemd/system/clawdbot.service，然后：

bash复制systemctl daemon-reload
systemctl enable clawdbot
systemctl start clawdbot

这样即使服务器意外断电重启，开机后 Docker 起来，Clawdbot 也会跟着起来。实测模拟过一次断电重启，约 2 分钟恢复。

5.3 日志别无限涨，定期清理

容器跑久了日志文件会越来越大，特别是机器人频繁收发消息的场景。Docker 默认 logging driver 会保留全部日志，几个月能涨到几个 GB。在 compose 文件里加日志轮转：

yaml复制logging:
  driver: json-file
  options:
    max-size: "20m"
    max-file: "5"

设置完重启服务才生效。这里不用额外装 logrotate，Docker 自己就能搞定。

5.4 健康检查：让坏状态能被发现

Clawdbot 有管理接口，可以用 curl 做健康检查。加一个脚本检测面板接口是否返回 200，如果不健康就通过钉钉/Server酱发条通知。

bash复制#!/bin/bash
CODE=$(curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $ADMIN_TOKEN" http://localhost:18080/api/health)
if [ "$CODE" != "200" ]; then
  curl -s "https://sctapi.ftqq.com/YOUR_SENDKEY.send?text=Clawdbot挂了"
fi

扔到 cron 里每 5 分钟跑一次：

bash复制*/5 * * * * /opt/scripts/check_clawdbot.sh

这一步是可选的，但如果你想真正让它“7x24”，告警比什么优化都重要。挂了不可怕，可怕的是挂了一天你都不知道。

6. 接入后的实测感受与常见问题排查

6.1 我实际跑了哪些场景

部署完我拿它干了三件事：

第一，把团队聊天机器人接上了 Clawdbot。同事在群里发“帮我翻译这段”“项目日报生成一下”，机器人通过 webhook 收到消息后调用 qwen-plus，再把结果推回群，整个链路延迟大约 2 到 3 秒。

第二，设置了一个定时任务：每天早上 9 点让机器人根据我的待办清单生成一份当日计划，推送到私聊。这个通过管理面板配置定时触发即可，不用写代码。

第三，让它当我的“文档问答助手”。我把本地几份 Markdown 笔记挂到知识库目录，机器人引用相关片段后回答问题，回答质量挺惊喜的。

整体感受是：Clawdbot 作为一个壳子，灵活性很强，Qwen 在中文理解和指令跟随上也足够稳。有几次上下文很长导致回答变差，但把模型改成 qwen-plus 后明显改善。

6.2 高频问题排查表

部署和使用的过程中，我整理了一张排查表，基本覆盖了能遇到的大部分问题。

6.3 几个让我印象深刻的坑

第一个坑是上下文数量设置。Clawdbot 默认会保留最近 20 轮对话，但有一些渠道消息一多，直接把上下文撑爆，导致接口报错。我后来把最大上下文轮数调成 10，既保住了多轮连贯性，也省 token。

第二个坑是并发限制。DashScope 免费额度对并发有配额限制，消息一多会返回 429。解决办法是在 Clawdbot 的渠道设置里把“并发数”调低，比如设成 5，让消息排队处理。

第三个坑是时区。容器默认 UTC，定时任务如果按本地时间配置，会差 8 小时。所以一定在 .env 里设置 TZ=Asia/Shanghai，并且在配置定时任务时确认管理面板显示的是本地时间。

6.4 后续还能怎么扩展

Clawdbot 的能力不限于即时通讯。你可以给它加自定义工具，比如让它调用维基百科搜索、执行 SQL 查询、读取 Grafana 监控数据，本质上就是给它配一套函数调用（function calling）的白名单。

我目前的规划是：下一步接入邮箱，让机器人每天汇总未读邮件，把重要的挑出来加上摘要发给我；再后面研究一下 RAG 流程，把本地文档切成向量存进 Milvus，让机器人的回答有更好的私域知识支撑。

但要提醒一句，功能越多，出故障的点就越多。每加一个工具，都要确认它的权限边界够小，别为了省事直接给机器人一把“万能钥匙”。我的做法是机器人跑在一个专用目录里，只给它访问该目录的权限，不碰系统其他路径。

7. 最后分享几个我验证过的小技巧

如果你打算照做，有几个小技巧能让你少走弯路。

第一，不要在生产目录里直接 git pull 升级，先用一份拷贝测试。Clawdbot 更新速度快，有些版本的配置格式不兼容，直接覆盖可能连管理面板都进不去。我是把配置文件整个复制到 dev 目录先跑一遍，确认没问题再切正式目录。

第二，容器内的模型配置优先级高于环境变量。如果你在管理面板里手动选过模型或修改过超参，重启后可能不会覆盖面板里的设置。所以改配置之前，先看一眼面板里有没有残留的手动设置。

第三，记录每次改动。我写了一个 CHANGELOG 文件，每次改了什么、为什么改、测试结果如何，都记一行。这不是什么高级习惯，但机器人在生产环境跑久了，你根本想不起来上个月是怎么配的。这个文件已经帮了我三次。

第四，给自己的 AI 助理做“最小权限”。不要让它拥有所有渠道的管理权限，也不需要它能删除消息或拉人进群。控制台能做很多事，但你要让它只管好自己的本职工作。我踩过坑，给了机器人全员管理权限，结果一次测试指令差点把群公告改了——还好权限收回得快。

Clawdbot 加 Qwen 这套组合，真正吸引我的不是“免费”或“强大”，而是它把“能聊天的模型”变成了“能替你办事的工具”。过程中会踩坑，但只要把部署、接入、守护这几关过了，它就能安安静静地在后台帮你扛下那些重复又琐碎的事情。这就是我想要的那种，不会下班的助理。