测试日期2026-09-28测试对象NapCat AstrBotDocker Compose对比 Lagrange.Core 等独立协议实现目标设备HiSilicon hi3798mv100ARMv74×1GHz969MB 内存内核 4.4.35结论NapCat AstrBot 不适合 ARMv7 嵌入式设备Lagrange.Core 是可行方向但 .NET 8 在 ARM32 上有已知稳定性问题落地前必须冒烟测试。目录结论先行背景与目标测试环境NapCat AstrBot 实测数据为什么 NapCat 不适合 ARMv7AstrBot 单独评估.NET 方案Lagrange.Core生态全景对比2026-09可行路径建议冒烟测试方法常见问题 FAQ总结1. 结论先行NapCat AstrBot 不适合 ARMv7 嵌入式设备。NapCat 依赖 NTQQ 桌面客户端只有 x86_64 二进制且内存占用高。在 x86_64 桌面机上 idle 就占用约 855 MiB 内存、93 个进程。AstrBot 本身在 ARMv7 上可跑。Python FastAPI单进程idle 约 323 MiB。问题主要出在 NapCat。Lagrange.Core 是唯一活跃的纯 .NET 独立 NTQQ 协议实现。.NET 8 官方提供linux-arm32构建理论上支持 ARMv7。但 dotnet/runtime 仓库中有多条 ARM32 segfault 报告需实测验证。已消失的项目不要用。初稿曾推荐NetMiraiTeam/NetMirai.Bot该项目现已 404请勿再使用。短期方案QQ 机器人相关服务留在 x86_64 桌面机嵌入式设备只跑业务侧。2. 背景与目标在嵌入式设备如 HiSilicon hi3798mv100上运行 QQ 机器人通常面临两个限制CPU 架构为 ARMv7很多预编译二进制不提供 ARM 版本内存通常只有 1GB 左右无法承载重型桌面应用。本次测试评估两种方案NapCat AstrBot基于 NTQQ 桌面客户端 Python AI 框架。Lagrange.Core纯 C# 实现的 NTQQ 协议栈单 .NET 进程。目标是判断哪种方案能在 ARMv7 1GB 内存的设备上稳定运行。3. 测试环境项目配置测试宿主x86_6415 GiB 内存目标设备HiSilicon hi3798mv100ARMv74×1GHz目标设备内存969 MB可用约 592 MB目标设备内核4.4.35_ecoo2016 定制目标设备系统盘7 GB容器运行时Docker Compose测试命令docker stats --no-stream4. NapCat AstrBot 实测数据在 x86_64 桌面机上运行docker compose up -d等待 20 秒后采集快照容器镜像CPU内存PIDsNapCatmlikiowa/napcat-docker:latest0.22–0.37%532 MiB86AstrBotsoulter/astrbot:v4.27.30.00%323 MiB7合计—~0.4%≈855 MiB93NapCat 内部进程树textbash → Xvfb → qq × 8NTQQ 主进程 各种子进程86 个 PID 中绝大部分是 NTQQ 桌面客户端的 fork。数据为单次docker stats --no-stream快照容器处于 idle 状态NapCat 卡在扫码登录循环未真正连接 QQ 服务器。5. 为什么 NapCat 不适合 ARMv7NapCatNapNeko/NapCatQQ基于NTQQ 桌面客户端用 TypeScript 壳注入官方闭源 QQ binary。硬依赖结果完整 QQ 桌面 UI必须跑 Xvfb 虚拟显示图形栈需要 libsdl2 / libx11 / mesa 等 x86 用户态库官方闭源 QQ binary仅 x86_64无 ARM 构建多进程模型主进程 sandbox GPU util 子进程结论不是内存不够的问题而是二进制根本跑不了 ARMv7。6. AstrBot 单独评估AstrBotsoulter/astrbotPython FastAPI本身单进程7 个线程idle 约 323 MiB含约 3706 个 LLM metadata 缓存Python 3.x on ARMv7 可以运行很多嵌入式设备已在跑。理论上如果只是 AstrBot 轻量协议层ARMv7 可能撑得住。问题全出在 NapCat。7. .NET 方案Lagrange.Core项目LagrangeDev/Lagrange.CoreStars2,992截至 2026-09-07 仍有推送描述An Implementation of NTQQ Protocol, with Pure C#, Derived from Konata.Core技术栈C# / .NET 8 / NTQQ 协议纯自研 / OneBot 11 协议这是目前唯一活跃的、纯 .NET 独立 NTQQ 协议实现与 NapCat 完全无关。维度NapCat AstrBotLagrange.Core架构QQ 桌面 UI Python AI自研协议栈单 .NET 进程语言TypeScript Python纯 C#CPU 架构x86_64 only.NET 8 官方有 linux-arm32 / arm64 / x64GUI 依赖需要 Xvfb无部署Docker Xvfb QQ binary单 dll /dotnet publish进程数9317.1 .NET 8 的 ARM32 支持微软官方 .NET 8 下载页列出sdk-8.0.425-linux-arm32-binaries-targz✅runtime-aspnetcore-8.0.31-linux-arm32-binaries-targz✅所以 hi-box 的 ARMv7官方支持。这与“NET 5 砍了 ARMv7”的旧印象不符——.NET 8 又补回来了。7.2 .NET on ARM32 的已知稳定性问题dotnet/runtimeGitHub issues 中有多条 ARM32 段报告Issue状态标题#85895openembedded linux-arm dotnet 6/7 segmentation fault#102396openRandom segmentation fault in managed code on 32-bit ARM linux with dotnet 8.0#56706openSynology ARMv7 Illegal instruction含义.NET 8 在 ARMv7 上是“能跑但不稳”尤其是老 ARMv7 芯片和老内核hi-box 恰好都是——2016 定制的 4.4.35 内核。7.3 Lagrange 栈内存估算推理值未实测证据基础证据来源数值Lagrange.Core NuGet 包NuGet1.46 MBDLL当前版本NuGet2.1.12026 活跃已修复内存泄漏PR #5332024-08NotifyService 缓存未释放已修复内存泄漏PR #1822024-03LiteDBQuery()未 Dispose官方部署文档仓库根目录无 docker/deploy/docs 目录ARMv7 社区实测GitHub issue 搜索0 条官方推荐态度go-cqhttp #2471go-cqhttp 团队未推荐 Lagrange只推“Hook 官方客户端”路线推理估算.NET 8 单进程常识场景估算内存Lagrange 单跑空闲100–150 MBLagrange 活跃群聊 消息历史150–250 MBLagrange 图片/文件转发峰值300–400 MBLagrange AstrBotPython 323 MB 实测约 470 MB对比 NapCat 栈实测 855 MB约省 40%但未到 hi-box 可用内存 592 MB 的一半——“够得着”而非“宽松”。ARMv7 额外修正.NET GC 在 ARMv7 上效率通常比 x86 低 10–20%实际可能偏高。结论数字是推理值不是实测值。真要在 hi-box 用第一步必须是冒烟测试跑 24h 观察 RSS 曲线 segfault 频率。8. 生态全景对比2026-09项目语言Stars最后推送独立协议栈hi-box 适配NapNeko/NapCatQQTS10,7722026-09-23❌ 包官方 QQ❌soulter/astrbotPython—活跃❌ 客户端⚠️ 单跑可需配协议层LagrangeDev/Lagrange.CoreC#2,9922026-09-07✅✅ 但有 ARM32 坑LagrangeDev/LagrangeV2C#2102026-07-23✅✅ 同上lz1998/ricqRust6552024-05✅⚠️ musl 1.6MB 但已停滞mamoe/miraiKotlin14,8062024-09✅❌ JVM 太重Mrs4s/MiraiGoGo1,2132024-02✅⚠️ 停滞NetMiraiTeam/NetMirai.Bot——404 已消失—❌ZhaoJun233/bot-agentC#62026-09-28❌ 是 NapCat 客户端❌ 仍需 NapCat易混点C# 生态里很多“NapCat 客户端”NapPlana.NET / NapCatSharpLib / bot-agent 等它们只是 WebSocket 连到 NapCat底层还是跑 NapCat对 hi-box 没帮助。9. 可行路径建议对 hi-box 这类 ARMv7 1GB 内存 老内核的嵌入式盒子方案判断NapCat AstrBot❌ 跑不起来架构不匹配 内存超标任何 NTQQ-based 方案含 NapCat 及其 C# 客户端包装❌ 同 NapCatMiraiKotlin/JVM❌ JVM 本身 200 MiB且项目停滞ricqRust⚠️ 量级最诱人musl 1.6MB但已 2 年停滞不建议生产用Lagrange.CoreC#⚠️ 唯一可行的独立 .NET 方向但 ARMv7 上 .NET 8 有已知 segfault 报告需先冒烟测试MiraiGo⚠️ Go 单 binary量级 OK但 2024-02 停滞推荐路径短期1 天把 AstrBot 留在桌面机停掉 NapCathi-box 只做业务侧。中期1 周拉Lagrange.Core到 hi-box跑dotnet publish -r linux-arm32冒烟测试 24h 观察 segfault 频率。长期如果 Lagrange 稳定把 AstrBot 也搬过来Python 3.x on ARMv7 没问题只需控制功能规模。10. 冒烟测试方法bash# 在 x86_64 桌面机上复现 NapCat AstrBot 资源占用 cd /path/to/qwen-chat docker compose up -d sleep 20 docker stats --no-stream napcat astrbot docker top napcat -e | head -12 docker top astrbot -e docker compose down在 hi-box 上测试 Lagrange.Corebash# 安装 .NET 8 SDK for linux-arm32 # 发布并运行 dotnet publish -r linux-arm32 -c Release ./bin/Release/net8.0/linux-arm32/Lagrange.Core # 观察 24 小时 while true; do ps -o pid,rss,comm -C Lagrange.Core sleep 60 done同时监控内核日志中的 segfaultbashdmesg -w | grep -i segfault11. 常见问题 FAQQ1NapCat 为什么不能在 ARMv7 上跑NapCat 依赖官方 NTQQ 桌面客户端二进制而该二进制只有 x86_64 版本没有 ARM 构建。Q2AstrBot 能单独在 ARMv7 上跑吗可以。AstrBot 是 Python FastAPI单进程idle 约 323 MiB。很多嵌入式设备都能跑 Python 3.x。Q3Lagrange.Core 能在 ARMv7 上跑吗理论上可以。.NET 8 官方提供linux-arm32构建。但 dotnet/runtime 仓库中有多条 ARM32 segfault 报告需实测验证。Q4Lagrange.Core 内存占用大概多少推理估算单跑空闲 100–150 MB加 AstrBot 约 470 MB。实际可能因 ARMv7 上 .NET GC 效率较低而偏高。Q5还有别的独立协议实现吗有但多数已停滞ricqRust已 2 年未更新MiraiGoGo2024-02 后停滞MiraiKotlin/JVMJVM 太重不适合 1GB 内存设备。Q6NetMirai.Bot 还能用吗不能。该项目现已 404不要再用。Q7C# 生态里那些 NapCat 客户端能用吗不能。它们只是 WebSocket 连到 NapCat底层还是跑 NapCat对 ARMv7 没帮助。12. 总结NapCat AstrBot 是“为 x86_64 桌面机设计”的完整 QQ 桌面 AI 栈放到 hi-box 上不是调优问题而是二进制和内存的双重硬伤。真正的 .NET 独立方向是Lagrange.Core不是已消失的 NetMirai。.NET 8 有官方 ARM32 构建但 dotnet/runtime 仓库里 ARM32 段有若干未解 segfault 报告。方向可行落地前先冒烟。本文基于 2026-09-28 实测数据整理。不同硬件、内核和 .NET 版本下结果可能不同请结合实际环境调整。