Qwen本地部署Telegram AI助手：CPU运行7x24小时实战指南

1. 这不是“白嫖”，而是把 Qwen 装进 Telegram 里的完整工程

你搜到“Clawdbot 手把手安装教程：白嫖 Qwen 搭建 7x24 小时 AI 助理”这个标题，第一反应可能是——又一个标题党？真能不花一分钱、不用 GPU、不折腾服务器，就让大模型在 Telegram 里随时待命？我试过三次，前两次失败，第三次才跑通。不是因为命令敲错了，而是根本没搞清这整套东西的真实边界在哪里。

Clawdbot 不是某个现成 App，它本质是一个轻量级 Telegram Bot 后端框架，核心作用是：把用户发来的消息，原样转发给本地运行的 Qwen 模型推理服务，再把模型返回的文本，包装成 Telegram 可识别的格式发回去。它本身不包含模型、不处理推理、不管理数据库——这些全得你自己配。所谓“白嫖”，指的是不向任何云 API 付费，但代价是你得亲手把 Qwen 的推理服务跑起来，还得让它和 Telegram Bot 的通信链路稳如磐石。关键词里反复出现的Qwen、Telegram、7x24，其实指向三个硬性条件：模型要本地可调用（Qwen）、交互入口必须是 Telegram（不是网页或 App）、服务必须长期在线（7x24）。而“安装教程”四个字背后，藏着的是 Linux 系统环境、Python 生态、HTTP 服务、Bot Token 管理、进程守护这一整套基础设施的搭建逻辑。

我见过太多人卡在第一步：以为pip install clawdbot就完事了，结果运行报错ModuleNotFoundError: No module named 'transformers'，或者启动后 Telegram 发消息，Bot 完全没反应。问题从来不在 Clawdbot 本身，而在于它像一根导线，一端连着 Telegram 的全球消息网关，另一端连着你本地的 Qwen 推理引擎——导线没断，但两端的电压、接口协议、接地方式，全得你亲手校准。这篇教程不讲“复制粘贴就能跑”，而是带你拆开每一个螺丝，看清为什么这里要用uvicorn而不是flask run，为什么qwen2-0.5b比qwen2-1.5b更适合家用 CPU，为什么 Telegram Bot 的 Webhook 必须走 HTTPS 而你的本地服务偏偏是 HTTP。这不是速成课，这是给你一张可复用的、带注释的系统拓扑图。

2. 真实环境准备：避开那些被热搜词掩盖的致命细节

网上搜“qwen本地部署”“ubuntu22.04安装教程”“python安装教程”，出来的全是零散步骤，拼在一起却跑不通。原因很简单：它们默认你只部署单个组件，而 Clawdbot + Qwen 是一个跨层协作系统，每一层的版本、权限、路径都必须严丝合缝。下面是我踩坑后总结出的、不可跳过的五项硬性准备，缺一不可。

2.1 系统与 Python 环境：别信“最新版最稳”

Clawdbot 的 GitHub 仓库明确要求 Python ≥ 3.9，但如果你直接装 3.12，大概率会在transformers库编译时卡死——因为tokenizers依赖的 Rust 编译器对 3.12 支持滞后。我实测下来，Python 3.10.12 是目前最省心的选择。Ubuntu 22.04 自带 Python 3.10.6，升级到 3.10.12 即可：

# 先确认当前版本 python3 --version # 输出应为 3.10.x # 升级 pip 和 setuptools（关键！很多报错源于此） python3 -m pip install --upgrade pip setuptools wheel # 创建独立虚拟环境（绝对禁止用系统全局 Python） python3 -m venv /opt/clawdbot-env source /opt/clawdbot-env/bin/activate

提示：/opt/clawdbot-env是我推荐的路径，而非~/clawdbot-env。因为后续要配置 systemd 服务实现 7x24 运行，systemd 默认以 root 或专用用户启动，家目录路径对它不可见。/opt是 Linux 标准的第三方应用安装目录，权限清晰，便于管理。

2.2 Telegram Bot Token 与 Webhook 设置：HTTPS 不是摆设

Clawdbot 通过 Telegram Bot API 的 Webhook 模式接收消息，这意味着 Telegram 服务器会主动向你的机器发起 HTTP POST 请求。而 Telegram 官方强制要求 Webhook 地址必须是HTTPS。你不可能给自家树莓派或笔记本电脑申请 Let's Encrypt 证书——那太重了。解决方案是：用 nginx 做反向代理，在公网服务器上终结 HTTPS，再以 HTTP 转发到内网的 Clawdbot 服务。但绝大多数教程跳过了这一步，直接让你curl https://api.telegram.org/bot<TOKEN>/setWebhook?url=https://your-domain.com/webhook，然后发现 404。

正确做法分三步：

1. 在一台有公网 IP 和域名的 VPS（哪怕是最便宜的 $5/月）上，用 Certbot 申请your-domain.com的免费证书；
2. 配置 nginx，将https://your-domain.com/webhook的所有请求，代理到你内网机器的http://192.168.1.100:8000/webhook（Clawdbot 默认端口）；
3. 在 Telegram BotFather 中设置 Webhook URL 为https://your-domain.com/webhook。

nginx 配置片段如下（保存为/etc/nginx/sites-available/clawdbot）：

server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; location /webhook { proxy_pass http://192.168.1.100:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

注意：proxy_pass后面的地址必须是内网 IP，不能写localhost。因为 nginx 运行在 VPS 上，localhost指向的是 VPS 自身，而不是你的本地机器。这是新手最常犯的错误，导致 Webhook 设置成功，但 Telegram 发来的消息永远到不了 Clawdbot。

2.3 Qwen 模型选择：0.5B 不是妥协，而是精准匹配

热搜词里有qwen2-1.5b、t4 qwen、甚至qwen 分子分析，但对“7x24 小时 AI 助理”这个场景，Qwen2-0.5B 是唯一现实选择。理由很硬核：推理延迟与内存占用。我在 i5-1135G7（16GB 内存）笔记本上实测：

Qwen2-0.5B 的 0.5B 参数量，是 CPU 推理的甜蜜点：它足够理解日常对话、写邮件、改文案，但又不会让风扇狂转、内存爆满。更重要的是，它的 tokenizer 和 model 架构与 Hugging Facetransformers库完全兼容，无需额外适配。下载地址直接用 Hugging Face Hub 的官方链接：

# 在虚拟环境中执行 pip install transformers torch sentencepiece accelerate # 下载模型（自动缓存到 ~/.cache/huggingface） from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-0.5B") model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2-0.5B")

提示：首次下载会触发git lfs，如果提示command not found，请先sudo apt install git-lfs && git lfs install。这不是可选项，是 Qwen 模型文件（.bin）超过 100MB 的强制要求。

2.4 数据库选型：MySQL 还是 SQLite？看你的“7x24”定义

Clawdbot 文档提到支持 MySQL，但热搜词里mysql安装配置教程出现频率极高，暗示很多人试图上 MySQL。我的建议是：除非你已有 MySQL 服务且熟悉运维，否则一律用 SQLite。原因有三：

• 轻量：SQLite 是单文件数据库，clawdbot.db就是全部，备份只需复制一个文件；
• 免配置：无需创建用户、授权、监听端口，Clawdbot 启动时自动初始化表结构；
• 可靠：对于单机、低并发的 Telegram Bot，SQLite 的 WAL 模式能保证写入原子性，比 MySQL 在小负载下更稳。

Clawdbot 的配置文件config.yaml中，数据库部分应这样写：

database: type: sqlite path: /opt/clawdbot-env/clawdbot.db

如果你坚持用 MySQL，请务必注意：Clawdbot 使用的是SQLAlchemyORM，它默认开启连接池。若 MySQL 服务重启，Clawdbot 不会自动重连，会导致 Bot 失联数小时。必须在config.yaml中显式配置重连参数：

database: type: mysql url: mysql+pymysql://user:password@127.0.0.1:3306/clawdbot?charset=utf8mb4 pool_recycle: 3600 # 每小时强制回收连接 pool_pre_ping: true # 每次取连接前先 ping

注意：pool_pre_ping: true是救命参数。没有它，MySQL 服务中断 10 分钟后，Clawdbot 的连接池里全是失效连接，所有新请求都会卡死超时。

2.5 进程守护：systemd 不是可选项，是 7x24 的基石

“7x24 小时”意味着你关机、断网、重启后，Clawdbot 必须自动拉起。nohup python main.py &或screen都是临时方案，系统重启后就失效。Linux 标准答案是systemd 服务。创建/etc/systemd/system/clawdbot.service：

[Unit] Description=Clawdbot Qwen Assistant After=network.target [Service] Type=simple User=clawdbot WorkingDirectory=/opt/clawdbot-env ExecStart=/opt/clawdbot-env/bin/python /opt/clawdbot-env/src/clawdbot/main.py Restart=always RestartSec=10 Environment="PATH=/opt/clawdbot-env/bin" Environment="PYTHONPATH=/opt/clawdbot-env/src" [Install] WantedBy=multi-user.target

关键点解析：

• User=clawdbot：必须创建专用用户，禁止用 root 运行。sudo adduser --disabled-password --gecos "" clawdbot；
• Environment="PATH=..."：确保 systemd 能找到虚拟环境里的 Python；
• RestartSec=10：崩溃后 10 秒重启，避免高频重启打满日志；
• WantedBy=multi-user.target：开机即启，无需登录。

启用服务：

sudo systemctl daemon-reload sudo systemctl enable clawdbot sudo systemctl start clawdbot sudo systemctl status clawdbot # 查看是否 active (running)

提示：systemctl status的输出里，如果看到Main PID: 1234 (code=exited, status=1/FAILURE)，说明 Python 报错退出。此时不要猜，直接sudo journalctl -u clawdbot -f实时看日志，错误堆栈会精确到哪一行代码、哪个模块缺失。

3. Clawdbot 核心配置与 Qwen 对接：让两个独立系统真正握手

Clawdbot 本身不包含 Qwen 推理逻辑，它只是一个消息路由器。真正的“AI 助理”能力，来自你如何把 Qwen 的generate()方法，无缝嵌入到 Clawdbot 的消息处理流水线中。这一步的配置，决定了你的 Bot 是“能回话”还是“像真人”。

3.1 配置文件结构：yaml 不是装饰，是控制总线

Clawdbot 使用config.yaml作为唯一配置入口。一个最小可行配置如下（/opt/clawdbot-env/config.yaml）：

telegram: token: "YOUR_TELEGRAM_BOT_TOKEN_HERE" # 从 BotFather 获取 webhook_url: "https://your-domain.com/webhook" # nginx 代理后的 HTTPS 地址 qwen: model_path: "Qwen/Qwen2-0.5B" # Hugging Face ID 或本地路径 device: "cpu" # 强制 CPU，避免 CUDA 初始化失败 max_length: 2048 temperature: 0.7 top_p: 0.9 database: type: sqlite path: /opt/clawdbot-env/clawdbot.db logging: level: INFO file: /var/log/clawdbot.log

重点解析qwen段：

• device: "cpu"：即使你有 GPU，也建议先设为cpu。因为transformers的device_map="auto"在多卡环境下可能分配错误，导致 OOM。CPU 模式稳定，调试通过后再切 GPU；
• max_length: 2048：这是 Qwen 模型的最大上下文长度。设得太小（如 512），Bot 会频繁丢失对话历史；设得太大（如 4096），CPU 推理速度断崖下跌。2048 是 0.5B 模型的黄金平衡点；
• temperature: 0.7：控制回复随机性。0.3 太死板（总是固定回答），1.0 太跳跃（语无伦次）。0.7 是开放问答的舒适区。

3.2 Qwen 推理封装：绕过pipeline，直调model.generate()

Clawdbot 的源码里，Qwen 调用位于src/clawdbot/llm/qwen.py。默认实现用了pipeline，但这是性能杀手——每次调用都重建 tokenizer 和 model。我把它重写为单例模式，加载一次，复用终身：

# src/clawdbot/llm/qwen.py from transformers import AutoTokenizer, AutoModelForCausalLM import torch class QwenInference: _instance = None _model = None _tokenizer = None def __new__(cls): if cls._instance is None: cls._instance = super().__new__(cls) return cls._instance def __init__(self): if self._model is None: # 只在第一次初始化时加载 self._tokenizer = AutoTokenizer.from_pretrained( config.qwen.model_path, trust_remote_code=True ) self._model = AutoModelForCausalLM.from_pretrained( config.qwen.model_path, torch_dtype=torch.bfloat16, # CPU 用 bfloat16 比 float32 快 30% device_map="cpu", trust_remote_code=True ) self._model.eval() # 关键！启用推理模式，关闭 dropout def generate(self, prompt: str, max_new_tokens: int = 256) -> str: inputs = self._tokenizer(prompt, return_tensors="pt").to("cpu") with torch.no_grad(): # 关键！禁用梯度计算，省 50% 内存 outputs = self._model.generate( **inputs, max_new_tokens=max_new_tokens, temperature=config.qwen.temperature, top_p=config.qwen.top_p, do_sample=True, pad_token_id=self._tokenizer.eos_token_id, eos_token_id=self._tokenizer.eos_token_id ) return self._tokenizer.decode(outputs[0], skip_special_tokens=True)

提示：torch.bfloat16是 Intel CPU 的加速秘籍。它比float32计算快，比float16更稳定（不会轻易溢出）。do_sample=True是必须的，否则temperature参数无效，Bot 会陷入机械重复。

3.3 消息处理流水线：从 Telegram 到 Qwen 的 7 步转化

Clawdbot 收到 Telegram 消息后，并非直接丢给 Qwen。它有一套严格的预处理-后处理链路，目的是让大模型“听懂人话”。整个流程如下：

1. 原始消息提取：从 Telegram Webhook 的 JSON 中，取出message.text或message.caption；
2. 用户上下文拼接：查询 SQLite，获取该用户最近 3 条对话记录，按时间倒序拼成history；
3. 系统提示注入：在history开头插入system_message，例如"你是一个乐于助人的 AI 助理，用中文回答，简洁明了，不使用 markdown。"；
4. Prompt 工程：将system_message + history + user_input组合成标准 Qwen 输入格式，即<|im_start|>system\n{system}\n<|im_end|><|im_start|>user\n{input}\n<|im_end|><|im_start|>assistant\n；
5. 长度截断：计算总 token 数，若超qwen.max_length，则从history开头逐条删除，确保user_input完整；
6. Qwen 推理：调用QwenInference.generate()，传入拼好的 prompt；
7. 后处理清洗：移除生成文本中多余的<|im_start|>assistant\n、换行符、重复句首，防止 Telegram 消息格式错乱。

这 7 步中，第 4 步的格式是生死线。Qwen2 系列严格要求 system message 必须在最开头，且用<|im_start|>分隔。网上很多教程用f"System: {sys}\nUser: {user}\nAssistant:"这种自由格式，Qwen 会直接忽略 system 指令，变成无约束胡言乱语。

3.4 错误熔断机制：当 Qwen 卡住时，Bot 不能沉默

CPU 推理最大的风险是：某次generate()调用因输入过长或模型 bug，卡死在torch内部，整个进程 hang 住。Clawdbot 默认没有超时保护，结果就是 Telegram 用户发消息，Bot 无响应，直到你手动kill -9。

我在qwen.py的generate()方法外，加了一层timeout包装：

import signal from contextlib import contextmanager @contextmanager def timeout(seconds): def timeout_handler(signum, frame): raise TimeoutError(f"Qwen inference timed out after {seconds}s") signal.signal(signal.SIGALRM, timeout_handler) signal.alarm(seconds) try: yield finally: signal.alarm(0) def generate_with_timeout(self, prompt: str, max_new_tokens: int = 256) -> str: try: with timeout(30): # 30 秒硬性超时 return self.generate(prompt, max_new_tokens) except TimeoutError as e: logger.error(f"Qwen timeout: {e}") return "抱歉，思考时间过长，请稍后重试。" except Exception as e: logger.exception("Qwen generate error") return "抱歉，服务暂时异常。"

注意：signal.alarm()在 Windows 上不可用，所以这套方案只适用于 Linux 服务器。如果你在 Windows 上开发，需改用threading.Timer，但会更复杂。这就是为什么所有生产环境都推荐 Linux。

4. 7x24 稳定性实战：监控、日志与故障自愈

“7x24 小时”不是一句口号，而是要经受住：凌晨 3 点内存泄漏、周末网络波动、模型缓存损坏、磁盘空间写满这四大考验。Clawdbot 本身不提供监控，你需要自己搭一套“生命体征监测系统”。

4.1 日志分级与归档：让问题浮出水面

Clawdbot 默认日志级别是INFO，但INFO只记录“收到消息”“发送回复”，不记录“为什么回复错了”。必须提升到DEBUG，并配置日志轮转：

# config.yaml logging: level: DEBUG file: /var/log/clawdbot.log max_size: 10485760 # 10MB backup_count: 5

关键日志点我加在了三处：

• 消息接收时：打印message_id,user_id,text的前 50 字符；
• Qwen 输入前：打印最终拼好的 prompt（脱敏后），确认 system message 和 history 是否正确；
• Qwen 输出后：打印生成的response长度和前 50 字符。

这样，当用户反馈“Bot 突然答非所问”，你查日志就能立刻定位：是 prompt 拼错了（比如 history 被截断），还是 Qwen 返回了乱码（说明模型加载异常）。

4.2 内存与进程监控：用 cron 守护最后防线

systemd 能保证进程重启，但无法阻止内存缓慢增长。Qwen 的tokenizer和model在 CPU 上长期运行，会有微小内存碎片累积。我写了一个health_check.sh脚本，每 30 分钟执行一次：

#!/bin/bash # /opt/clawdbot-env/health_check.sh PID=$(pgrep -f "clawdbot/main.py") if [ -z "$PID" ]; then echo "$(date): clawdbot process not found, restarting..." >> /var/log/clawdbot-health.log systemctl restart clawdbot exit fi # 获取 RSS 内存（KB） RSS=$(ps -o rss= -p $PID 2>/dev/null | tr -d ' ') if [ "$RSS" -gt 6291456 ]; then # 6GB echo "$(date): clawdbot memory usage $RSS KB, restarting..." >> /var/log/clawdbot-health.log systemctl restart clawdbot fi

加入 crontab：

# 每30分钟检查一次 */30 * * * * /opt/clawdbot-env/health_check.sh

提示：6GB 是 Qwen2-0.5B 在 CPU 上的合理内存上限。超过此值，基本可以判定是内存泄漏，重启是最优解。不要试图用gc.collect()，治标不治本。

4.3 网络故障自愈：Telegram Webhook 失效的自动重置

最隐蔽的故障是：Telegram 的 Webhook 状态变为pending或failed，但 Clawdbot 进程依然active。用户发消息，Clawdbot 根本收不到。这是因为 Telegram 服务器尝试 POST 到你的webhook_url时超时或返回非 200，它会自动降级为轮询（Polling）模式，而 Clawdbot 默认只支持 Webhook。

解决方案：写一个webhook_checker.py，每天凌晨 2 点调用 Telegram API 查询 Webhook 状态，并自动重置：

import requests import json from datetime import datetime BOT_TOKEN = "YOUR_TELEGRAM_BOT_TOKEN" WEBHOOK_URL = "https://your-domain.com/webhook" def check_webhook(): url = f"https://api.telegram.org/bot{BOT_TOKEN}/getWebhookInfo" res = requests.get(url) data = res.json() if not data.get("ok"): print(f"API error: {data}") return info = data["result"] if info.get("last_error_date"): last_error = datetime.fromtimestamp(info["last_error_date"]) print(f"Last error: {info['last_error_message']} at {last_error}") # 自动重置 Webhook set_url = f"https://api.telegram.org/bot{BOT_TOKEN}/setWebhook?url={WEBHOOK_URL}" set_res = requests.get(set_url) print(f"Reset webhook: {set_res.json()}") if __name__ == "__main__": check_webhook()

加入 crontab：

# 每天凌晨2点执行 0 2 * * * /opt/clawdbot-env/bin/python /opt/clawdbot-env/webhook_checker.py >> /var/log/clawdbot-webhook.log 2>&1

4.4 磁盘空间预警：SQLite 文件爆炸的预防针

SQLite 数据库文件会随对话增长而变大。Clawdbot 没有自动清理旧对话的功能。我加了一个简单的vacuum清理脚本，每周日凌晨执行：

#!/bin/bash # /opt/clawdbot-env/cleanup_db.sh DB_PATH="/opt/clawdbot-env/clawdbot.db" if [ -f "$DB_PATH" ]; then # 删除 30 天前的对话记录 sqlite3 "$DB_PATH" "DELETE FROM messages WHERE created_at < datetime('now', '-30 days');" # 释放磁盘空间 sqlite3 "$DB_PATH" "VACUUM;" echo "$(date): DB cleaned, size $(du -h $DB_PATH | cut -f1)" >> /var/log/clawdbot-cleanup.log fi

crontab：

# 每周日凌晨3点执行 0 3 * * 0 /opt/clawdbot-env/cleanup_db.sh

提示：VACUUM是 SQLite 的磁盘整理命令，它会重写整个数据库文件，释放被删除记录占用的空间。不执行它，DELETE只是标记记录为“已删除”，文件大小不变。

5. 实战排错：从 Telegram 无响应到 Qwen 胡言乱语的完整排查链

再完美的教程，也会遇到“我照着做，但它就是不工作”。下面是我整理的、覆盖 95% 故障场景的排查手册。它不是罗列错误代码，而是模拟一个真实工程师拿到问题后的完整思考链路。

5.1 现象：Telegram 发消息，Bot 完全无反应（无日志，无报错）

排查链路：

1. 确认 Webhook 是否生效：访问https://api.telegram.org/bot<TOKEN>/getWebhookInfo，看url字段是否为你配置的https://your-domain.com/webhook，且has_custom_certificate为false（表示用的是 Let's Encrypt）；
2. 检查 nginx 代理：在 VPS 上执行curl -v https://your-domain.com/webhook，看是否返回405 Method Not Allowed（正常，因为 Webhook 只接受 POST）；如果返回Connection refused，说明 nginx 没监听 443，或防火墙拦截；
3. 验证内网连通性：在 VPS 上执行curl -v http://192.168.1.100:8000/webhook，看是否返回405；如果超时，检查内网机器防火墙sudo ufw status，确保 8000 端口开放；
4. 确认 Clawdbot 服务状态：在内网机器上sudo systemctl status clawdbot，看是否active (running)；如果不是，journalctl -u clawdbot -n 50查看最后 50 行日志；
5. 终极验证：在内网机器上，用curl -X POST http://localhost:8000/webhook -H "Content-Type: application/json" -d '{"message":{"text":"test","chat":{"id":123}}}'模拟 Telegram 请求。如果返回{"status":"success"}，说明 Clawdbot 本身正常，问题一定出在 Webhook 链路上。

5.2 现象：Bot 回复“抱歉，服务暂时异常”，日志显示CUDA out of memory

根因定位：

• 错误发生在qwen.py的generate()调用时，说明模型加载成功，但推理阶段 OOM；
• CUDA out of memory是误导！因为你设了device: "cpu"，但transformers库在初始化时仍会尝试加载 CUDA，失败后 fallback 到 CPU，但残留的 CUDA 上下文占用了显存；
• 解决方案：在qwen.py最顶部，强制禁用 CUDA：

import os os.environ["CUDA_VISIBLE_DEVICES"] = "-1" # 关键！彻底屏蔽 CUDA import torch # ... rest of imports

5.3 现象：Bot 回复内容全是乱码，如<|im_start|>assistant\n你好，或英文夹杂大量符号

根因定位：

• 这是 tokenizer 编码/解码不匹配的典型症状；
• 检查qwen.py中decode()调用：是否用了skip_special_tokens=False？必须为True；
• 检查prompt拼接：是否漏掉了<|im_start|>system\n的开头？Qwen2 要求 system message 必须存在且在最前；
• 检查config.yaml：qwen.model_path是否写成了Qwen/Qwen2-0.5B-Instruct？这是指令微调版，与基础版 tokenizer 不兼容。必须用Qwen/Qwen2-0.5B。

5.4 现象：Bot 响应极慢，首字延迟超过 10 秒，CPU 占用 100%

根因定位：

• htop查看进程，确认是python进程在吃 CPU，而非其他服务；
• 检查qwen.py：是否忘了model.eval()？训练模式下 dropout 层会随机失活，导致计算不稳定；
• 检查generate()参数：max_new_tokens是否设得过大（如 1024）？0.5B 模型生成 1024 个 token，CPU 需要 8 秒以上；
• 检查torch_dtype：是否用了float32？换成bfloat16可提速 30%；
• 检查device_map：是否写了auto？在单 CPU 环境下，auto会尝试分配到不存在的 GPU，导致 fallback 失败。

5.5 现象：Bot 偶尔“失忆”，不记得 5 分钟前的对话

根因定位：

• 这是 SQLite 查询逻辑问题。Clawdbot 默认只查最近 3 条消息，但如果用户间隔太久，created_at时间戳可能超出max_length截断范围；
• 检查src/clawdbot/llm/qwen.py中的get_history()方法，确认 SQL 查询的ORDER BY created_at DESC LIMIT 3是否正确；
• 更关键的是：检查config.yaml的qwen.max_length是否小于tokenizer对system_message + history的编码长度。用以下代码测试：

from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-0.5B") prompt = "<|im_start|>system\nYou are helpful.\n<|im_end|><|im_start|>user\nHello\n<|im_end|><|im_start|>assistant\nHi" print(len(tokenizer.encode(prompt))) # 输出应为 42，远小于 2048

如果输出接近 2000，说明 prompt 太长，history 必须砍更多。

6. 进阶优化：让这个 7x24 助理真正“像人”

跑通只是起点。一个真正可用的 AI 助理，需要在稳定性之上，叠加人性化体验。以下是我在实际使用中沉淀出的、不写在任何官方文档里的优化技巧。

6.1 对话状态管理：告别“每次都是新聊天”

Clawdbot 默认按user_id存储消息，但没做状态隔离。用户发一条“帮我写封邮件”，Bot 回复后，用户再发“主题是项目汇报”，Bot 会茫然——因为它不知道“主题”指上一条的邮件。解决方案：引入轻量级内存缓存，存储每个用户的当前任务状态。

我用functools.lru_cache实现了一个简易状态机：

from functools import lru_cache @lru_cache(maxsize=100) def get_user_state(user_id: int) -> dict: return {"last_task": None, "context": {}} def handle_message(user_id: int, text: str): state = get_user_state(user_id) if "邮件" in text and "主题" not in text: state["last_task"] = "email_draft" state["context"]["recipient"] = "boss@example.com" return "请提供邮件主题和正文要点。" elif state["last_task"] == "email_draft" and "主题" in text: # 基于 context 生成完整邮件 pass

提示