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。你不可能给自家树莓派或笔记本电脑申请 Lets Encrypt 证书——那太重了。解决方案是用 nginx 做反向代理在公网服务器上终结 HTTPS再以 HTTP 转发到内网的 Clawdbot 服务。但绝大多数教程跳过了这一步直接让你curl https://api.telegram.org/botTOKEN/setWebhook?urlhttps://your-domain.com/webhook然后发现 404。正确做法分三步在一台有公网 IP 和域名的 VPS哪怕是最便宜的 $5/月上用 Certbot 申请your-domain.com的免费证书配置 nginx将https://your-domain.com/webhook的所有请求代理到你内网机器的http://192.168.1.100:8000/webhookClawdbot 默认端口在 Telegram BotFather 中设置 Webhook URL 为https://your-domain.com/webhook。nginx 配置片段如下保存为/etc/nginx/sites-available/clawdbotserver { 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-1135G716GB 内存笔记本上实测模型加载时间首字延迟秒连续对话内存占用是否支持 CPU 推理Qwen2-0.5B28s1.2s3.8GB✅ 原生支持Qwen2-1.5B95s4.7s8.2GB⚠️ 需量化响应慢Qwen2-7B5min15s16GB❌ 无法在普通 PC 运行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 BotSQLite 的 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: mysqlpymysql://user:password127.0.0.1:3306/clawdbot?charsetutf8mb4 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] DescriptionClawdbot Qwen Assistant Afternetwork.target [Service] Typesimple Userclawdbot WorkingDirectory/opt/clawdbot-env ExecStart/opt/clawdbot-env/bin/python /opt/clawdbot-env/src/clawdbot/main.py Restartalways RestartSec10 EnvironmentPATH/opt/clawdbot-env/bin EnvironmentPYTHONPATH/opt/clawdbot-env/src [Install] WantedBymulti-user.target关键点解析Userclawdbot必须创建专用用户禁止用 root 运行。sudo adduser --disabled-password --gecos clawdbotEnvironmentPATH...确保 systemd 能找到虚拟环境里的 PythonRestartSec10崩溃后 10 秒重启避免高频重启打满日志WantedBymulti-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 (codeexited, status1/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.yamltelegram: 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_mapauto在多卡环境下可能分配错误导致 OOM。CPU 模式稳定调试通过后再切 GPUmax_length: 2048这是 Qwen 模型的最大上下文长度。设得太小如 512Bot 会频繁丢失对话历史设得太大如 4096CPU 推理速度断崖下跌。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_codeTrue ) self._model AutoModelForCausalLM.from_pretrained( config.qwen.model_path, torch_dtypetorch.bfloat16, # CPU 用 bfloat16 比 float32 快 30% device_mapcpu, trust_remote_codeTrue ) self._model.eval() # 关键启用推理模式关闭 dropout def generate(self, prompt: str, max_new_tokens: int 256) - str: inputs self._tokenizer(prompt, return_tensorspt).to(cpu) with torch.no_grad(): # 关键禁用梯度计算省 50% 内存 outputs self._model.generate( **inputs, max_new_tokensmax_new_tokens, temperatureconfig.qwen.temperature, top_pconfig.qwen.top_p, do_sampleTrue, pad_token_idself._tokenizer.eos_token_id, eos_token_idself._tokenizer.eos_token_id ) return self._tokenizer.decode(outputs[0], skip_special_tokensTrue)提示torch.bfloat16是 Intel CPU 的加速秘籍。它比float32计算快比float16更稳定不会轻易溢出。do_sampleTrue是必须的否则temperature参数无效Bot 会陷入机械重复。3.3 消息处理流水线从 Telegram 到 Qwen 的 7 步转化Clawdbot 收到 Telegram 消息后并非直接丢给 Qwen。它有一套严格的预处理-后处理链路目的是让大模型“听懂人话”。整个流程如下原始消息提取从 Telegram Webhook 的 JSON 中取出message.text或message.caption用户上下文拼接查询 SQLite获取该用户最近 3 条对话记录按时间倒序拼成history系统提示注入在history开头插入system_message例如你是一个乐于助人的 AI 助理用中文回答简洁明了不使用 markdown。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长度截断计算总 token 数若超qwen.max_length则从history开头逐条删除确保user_input完整Qwen 推理调用QwenInference.generate()传入拼好的 prompt后处理清洗移除生成文本中多余的|im_start|assistant\n、换行符、重复句首防止 Telegram 消息格式错乱。这 7 步中第 4 步的格式是生死线。Qwen2 系列严格要求 system message 必须在最开头且用|im_start|分隔。网上很多教程用fSystem: {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(fQwen 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(fQwen 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 fhttps://api.telegram.org/bot{BOT_TOKEN}/getWebhookInfo res requests.get(url) data res.json() if not data.get(ok): print(fAPI error: {data}) return info data[result] if info.get(last_error_date): last_error datetime.fromtimestamp(info[last_error_date]) print(fLast error: {info[last_error_message]} at {last_error}) # 自动重置 Webhook set_url fhttps://api.telegram.org/bot{BOT_TOKEN}/setWebhook?url{WEBHOOK_URL} set_res requests.get(set_url) print(fReset 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 214.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 ficrontab# 每周日凌晨3点执行 0 3 * * 0 /opt/clawdbot-env/cleanup_db.sh提示VACUUM是 SQLite 的磁盘整理命令它会重写整个数据库文件释放被删除记录占用的空间。不执行它DELETE只是标记记录为“已删除”文件大小不变。5. 实战排错从 Telegram 无响应到 Qwen 胡言乱语的完整排查链再完美的教程也会遇到“我照着做但它就是不工作”。下面是我整理的、覆盖 95% 故障场景的排查手册。它不是罗列错误代码而是模拟一个真实工程师拿到问题后的完整思考链路。5.1 现象Telegram 发消息Bot 完全无反应无日志无报错排查链路确认 Webhook 是否生效访问https://api.telegram.org/botTOKEN/getWebhookInfo看url字段是否为你配置的https://your-domain.com/webhook且has_custom_certificate为false表示用的是 Lets Encrypt检查 nginx 代理在 VPS 上执行curl -v https://your-domain.com/webhook看是否返回405 Method Not Allowed正常因为 Webhook 只接受 POST如果返回Connection refused说明 nginx 没监听 443或防火墙拦截验证内网连通性在 VPS 上执行curl -v http://192.168.1.100:8000/webhook看是否返回405如果超时检查内网机器防火墙sudo ufw status确保 8000 端口开放确认 Clawdbot 服务状态在内网机器上sudo systemctl status clawdbot看是否active (running)如果不是journalctl -u clawdbot -n 50查看最后 50 行日志终极验证在内网机器上用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()调用时说明模型加载成功但推理阶段 OOMCUDA out of memory是误导因为你设了device: cpu但transformers库在初始化时仍会尝试加载 CUDA失败后 fallback 到 CPU但残留的 CUDA 上下文占用了显存解决方案在qwen.py最顶部强制禁用 CUDAimport os os.environ[CUDA_VISIBLE_DEVICES] -1 # 关键彻底屏蔽 CUDA import torch # ... rest of imports5.3 现象Bot 回复内容全是乱码如|im_start|assistant\n你好或英文夹杂大量符号根因定位这是 tokenizer 编码/解码不匹配的典型症状检查qwen.py中decode()调用是否用了skip_special_tokensFalse必须为True检查prompt拼接是否漏掉了|im_start|system\n的开头Qwen2 要求 system message 必须存在且在最前检查config.yamlqwen.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是否设得过大如 10240.5B 模型生成 1024 个 tokenCPU 需要 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(maxsize100) 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] bossexample.com return 请提供邮件主题和正文要点。 elif state[last_task] email_draft and 主题 in text: # 基于 context 生成完整邮件 pass提示