首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >从 Windows 到 ARM 开发板:#WorkBuddy# 帮我把 QQ 机器人搬进了 24 小时开机的小盒子

从 Windows 到 ARM 开发板:#WorkBuddy# 帮我把 QQ 机器人搬进了 24 小时开机的小盒子

原创
作者头像
今周末
发布于 2026-09-12 17:22:31
发布于 2026-09-12 17:22:31
1460
举报

从 Windows 到 ARM 开发板:#WorkBuddy# 帮我把 QQ 机器人搬进了 24 小时开机的小盒子

本文是个人实战记录:把一台 Windows 上运行的 QQ 机器人整体迁移到 ARM 开发板(Debian ARM64 无桌面环境),实现 24 小时挂机在线。全程用 WorkBuddy(腾讯的 AI 助手客户端)做方案设计和命令生成,我负责执行和验收。

一、为什么要迁移

我的 QQ 机器人(NapCat + NoneBot2 方案,接大模型 API 做问答)之前跑在日常用的 Windows 电脑上。问题很明显:电脑一关机机器人就下线,而让人为了一个机器人 24 小时开台式机,电费和磨损都不划算。

解决方案是一块 4GB 内存的 ARM 开发板(Cubie A7S),装 64 位 Debian(无桌面、纯 SSH),插 64GB TF 卡,功耗低到可以常年插着不管。

二、架构选型:不换方案,只换地板

迁移的第一原则是方案不动、环境重搭——原来的代码和插件全部保留,只在新系统上重建运行环境:

组件

角色

说明

NapCat(Shell 模式)

QQ 协议端

headless 运行,不用 Docker 也不依赖图形界面

NoneBot2

机器人框架

反向 WebSocket 连 NapCat,端口 8080

NapCat WebUI

管理面板

端口 6099,浏览器远程管理登录和配置

systemd

进程托管

napcat、qqbot、healthcheck 三个服务,开机自启、掉线自动拉起

WorkBuddy 在这一步干了什么

选型阶段我把需求和板子配置发给 WorkBuddy,它直接给出了上表的架构方案,并且明确指出两条关键决策:NapCat 用 Shell 模式而不是 Docker(板子内存只有 4GB,省掉 Docker 开销),以及用 systemd 而不是 screen/nohup(崩溃自动重启,不用人工盯)。这两条后来都被证明是对的。

三、迁移四步走

第 1 步:系统准备

代码语言:javascript
复制
sudo apt update && sudo apt upgrade -y
# 确认架构(应输出 aarch64)
uname -m

第 2 步:装 NapCat(Shell 模式)

用官方一键脚本安装,装完在 WebUI(6099 端口)扫码登录 QQ:

代码语言:javascript
复制
curl -o napcat.sh https://fastly.jsdelivr.net/gh/NapNeko/NapCat-Installer@main/script/install.sh
sudo bash napcat.sh

第 3 步:装 NoneBot2 并恢复插件

把 Windows 上的机器人项目目录整个拷过来(含插件、配置、数据文件),装依赖:

代码语言:javascript
复制
pip install nonebot2 nonebot-adapter-onebot
# 进入项目目录,按 requirements 装齐其余依赖
pip install -r requirements.txt

第 4 步:systemd 服务托管

这是无桌面环境稳定挂机的关键。三个服务的核心是让每个组件开机自启 + 崩溃自动重启:

代码语言:javascript
复制
# /etc/systemd/system/qqbot.service(示例)
[Unit]
Description=QQ Bot (NoneBot2)
After=network.target

[Service]
WorkingDirectory=/home/user/qqbot
ExecStart=/usr/bin/python3 bot.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
代码语言:javascript
复制
sudo systemctl daemon-reload
sudo systemctl enable --now napcat qqbot healthcheck

healthcheck 服务定时探测 NapCat 的 API 端口,发现协议端假死就自动重启对应服务——挂机场景下这个保命服务比什么都重要。

四、踩坑记录(迁移最容易翻车的地方)

  • Windows 专用 API 是最大的坑:原代码里藏着 taskkill 强杀进程、CREATE_NO_WINDOW 子进程标志这类 Windows-only 写法,Linux 上直接报错。迁移前先全局搜一遍这类调用,逐个换成跨平台写法。
  • 路径分隔符:代码里写死的反斜杠路径在 Linux 上全部失效,统一改用 os.path 或 pathlib。
  • 别裸跑:不用 systemd 托管的话,SSH 一断机器人就死。所有常驻进程必须进 systemd 或等价机制。
  • WebUI 端口别暴露公网:6099 这类管理端口只在内网访问,或者加防火墙规则。

五、战果

指标

迁移前(Windows)

迁移后(ARM 板)

在线时长

跟电脑开关机走

7×24

功耗

整机 100W+ 级

个位数瓦特级

掉线恢复

人工重启

systemd 自动拉起

现在机器人常年在线,我的 Windows 电脑该关就关。整个过程从搭系统到机器人稳定跑起来,实际动手时间不长——方案设计、跨平台代码排查、每一步的命令,基本都是 WorkBuddy 生成、我照着执行和验收。AI 助手 + 一块小板子,就搭出了一个以前要伺候一台整机才能有的服务。

有在折腾 QQ 机器人或者 ARM 挂机的欢迎评论区交流。

板子实图:

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 从 Windows 到 ARM 开发板:#WorkBuddy# 帮我把 QQ 机器人搬进了 24 小时开机的小盒子
    • 一、为什么要迁移
    • 二、架构选型:不换方案,只换地板
      • WorkBuddy 在这一步干了什么
    • 三、迁移四步走
      • 第 1 步:系统准备
      • 第 2 步:装 NapCat(Shell 模式)
      • 第 3 步:装 NoneBot2 并恢复插件
      • 第 4 步:systemd 服务托管
    • 四、踩坑记录(迁移最容易翻车的地方)
    • 五、战果
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档