★ FEATURED ARTICLE 1. 项目概述在树莓派上跑起一个真正能“思考”的AI智能体我在树莓派上构建了一个个人 AI 智能体 —— Jeremy AdamsNeo4j。这句话不是标题党也不是概念演示而是我过去三个月每天下班后真实打磨出来的可交互、可记忆、可推理的本地化AI系统。它不依赖任何云端API所有模型推理、知识图谱存储、任务编排都在一台树莓派58GB内存版上完成。核心关键词——树莓派、Neo4j、Docker、MCP、POLE——每一个都不是装饰词树莓派是物理载体和成本锚点Neo4j是它的长期记忆中枢负责结构化存储用户习惯、设备状态、对话上下文Docker是运行环境的“安全舱”隔离模型服务、图数据库、协议网关MCPModel Control Protocol是它对外暴露的标准化控制接口让手机App、Home Assistant甚至另一台树莓派都能用统一方式调用它的能力POLEPlan-Observe-Learn-Execute则是它内部的决策循环框架决定了它不是被动应答的聊天机器人而是能主动规划、观察环境、学习反馈、执行动作的智能体。这个项目解决的不是“能不能跑通LLM”的问题而是“如何在资源受限的边缘设备上构建一个有记忆、懂逻辑、能闭环的AI实体”。它适合三类人一是想摆脱大模型厂商锁定、真正掌控自己AI数据主权的技术爱好者二是需要轻量级本地AI能力嵌入智能家居/实验室/教育场景的工程师三是正在探索AI Agent落地路径、苦于找不到可拆解、可复现、可调试的微型参考架构的开发者。它不追求参数量或benchmark分数但每一步操作都经得起推敲——从树莓派5的散热压频策略到Neo4j在ARM64上的JVM堆内存精调再到MCP协议在Docker网络中的端口映射陷阱全是实测踩坑后沉淀下来的硬核细节。2. 整体架构设计与技术选型逻辑2.1 为什么必须是树莓派5而非树莓派4或PC很多人看到“树莓派AI”第一反应是“性能不够”。这恰恰是本项目设计的起点——不是妥协而是主动约束。树莓派5搭载Broadcom BCM27124核Cortex-A76 2.4GHz VideoCore VII GPU提供了足够支撑量化模型推理的算力同时其功耗典型负载下约5–7W、体积85.6×56.5mm、价格裸板约¥399形成了不可替代的三角平衡。我对比过树莓派4B4GB在运行Qwen2-0.5B-int4模型时4B的CPU温度在65℃即触发降频而树莓派5通过更换导热硅脂加装铝制散热片启用vcgencmd动态风扇调速非简单PWM硬启停可将满载温度稳定在62℃持续推理吞吐提升23%。更重要的是树莓派5原生支持PCIe 2.0 x1接口这意味着未来可扩展NVMe SSD作为Neo4j数据盘当前使用USB3.0 SSD已满足需求彻底解决microSD卡I/O瓶颈——这是树莓派4B永远无法突破的物理限制。提示树莓派5安装Windows XP纯属网络梗实际毫无意义。本项目所有软件栈基于Raspberry Pi OS64-bit, Bookworm内核版本6.6。任何试图在树莓派上运行x86 Windows应用的行为都会因指令集不兼容而失败且严重拖累系统稳定性。2.2 Neo4j为何选择图数据库而非SQLite或PostgreSQL当AI智能体需要记住“张三上周三晚上八点在客厅打开了空调当时室温26℃他偏好24℃”传统关系型数据库会将其拆解为多张表用户表、设备表、事件表、环境表查询时需多次JOIN。而Neo4j直接建模为节点与关系(张三:Person)-[LAST_CONTROLLED]-(空调:Device),(空调)-[HAS_CURRENT_TEMP]-(26℃:Temperature)。这种表达天然契合AI的常识推理链。更重要的是Neo4j的Cypher查询语言能高效执行“找出所有曾被张三控制过、且当前温度高于25℃的设备”这类语义查询响应时间稳定在12ms以内实测10万节点50万关系数据集。相比之下同等数据规模下PostgreSQL的JSONB字段查询平均延迟达87ms且无法表达“设备A与设备B存在物理空间邻近关系”这类拓扑信息。我放弃SQLite是因为其无原生图查询能力强行用邻接表模拟图结构会导致复杂查询性能断崖式下跌放弃PostgreSQL则因其事务模型与AI智能体高频、小粒度的状态更新不匹配——Neo4j的ACID事务针对图操作优化单次写入延迟低于0.8ms而PostgreSQL在高并发INSERT下易出现锁等待。2.3 Docker不是为了“时髦”而是解决树莓派上的环境地狱树莓派生态的碎片化是真实痛点Python 3.11与PyTorch 2.3的ARM64 wheel包需手动编译Ollama官方镜像仅支持amd64Neo4j 5.x要求Java 17而树莓派OS默认源只提供OpenJDK 11。Docker在此处的价值是“确定性封装”我构建了三个专用镜像——jeremy-adams/ollama-arm64预编译PyTorchllama.cppQwen2-0.5B量化权重、jeremy-adams/neo4j-rpi5定制JVM参数ARM64优化的Neo4j 5.13、jeremy-adams/mcp-server基于FastAPI实现的MCP v0.3.1协议服务。每个镜像均通过docker build --platform linux/arm64显式指定架构避免运行时架构错配。更关键的是Docker Compose文件定义了服务间的网络策略Neo4j容器仅对MCP服务开放7474端口对外完全隔离Ollama容器通过--network container:neo4j共享网络命名空间规避了树莓派上iptables规则混乱导致的容器间通信失败问题。2.4 MCP为什么不用REST或WebSocket而选Model Control ProtocolMCPModel Control Protocol是2024年新兴的AI模型控制标准由LangChain团队主导制定核心目标是解耦“模型能力”与“调用方”。它定义了一套JSON-RPC 2.0兼容的标准化方法mcp.tools.list列出可用工具、mcp.send发送消息、mcp.observe订阅状态变更。相比REST APIMCP的优势在于状态感知客户端可主动observe智能体的内部状态如“当前执行计划”、“最近一次工具调用结果”而非被动轮询工具发现tools.list返回结构化工具描述含参数类型、必填项、示例前端可自动生成表单无需硬编码API文档协议中立同一MCP服务可同时支持HTTP、WebSocket、Unix Socket三种传输层我的树莓派智能体通过mcp-server暴露HTTP端点供Home Assistant调用同时通过WebSocket供手机App实时交互。注意网络热词中“dify neo4j 0.0.7”指Dify平台早期版本对Neo4j的实验性集成但Dify本身是中心化SaaS架构与本项目“全本地、去中心化”理念相悖故未采用。2.5 POLE框架让AI从“应答者”变成“执行者”POLEPlan-Observe-Learn-Execute不是抽象理论而是我写死在MCP服务主循环里的四步状态机Plan接收用户指令如“调暗卧室灯并播放轻音乐”调用LLM生成分步执行计划[{tool: light_control, params: {room: bedroom, brightness: 30}}, {tool: music_play, params: {genre: ambient}}]Observe执行前主动查询Neo4j获取当前状态“卧室灯当前亮度80%音乐播放器状态paused”验证计划可行性Learn执行后将结果成功/失败、耗时、环境反馈以(Execution:Log)-[CAUSED_BY]-(PlanStep)关系存入Neo4j形成可追溯的学习日志Execute调用对应工具插件如light_control.py通过GPIO控制PWM输出完成物理动作。这个循环每300ms执行一次确保智能体始终基于最新环境状态做决策。它与传统Agent框架如AutoGen的关键区别在于所有状态观测与学习都强制经过Neo4j图谱而非内存变量——这保证了重启后智能体仍能继承历史经验。3. 核心组件部署与配置详解3.1 树莓派5基础环境加固部署始于一块全新的32GB microSD卡推荐Samsung EVO Plus使用Raspberry Pi Imager烧录Raspberry Pi OS 64-bit (Bookworm)。关键加固步骤如下第一步禁用不必要的服务sudo systemctl disable bluetooth.service sudo systemctl disable hciuart.service sudo systemctl disable paxctld.service蓝牙服务在树莓派5上占用约120MB内存且无实际用途hciuart是蓝牙串口驱动禁用后释放UART0供后续传感器接入paxctld是PaX内存保护模块在ARM64上与PyTorch存在兼容性问题禁用后LLM推理稳定性提升。第二步优化GPU内存分配编辑/boot/config.txt添加gpu_mem128 arm_64bit1 over_voltage2 temp_limit70gpu_mem128将GPU内存固定为128MB足够VideoCore VII解码H.264视频流避免动态分配导致的内存抖动over_voltage2允许CPU在高温下维持2.4GHz频率实测比默认1.8GHz提升推理速度37%temp_limit70是安全阈值超过此温度自动降频。第三步配置智能风扇调速树莓派5的风扇控制需通过vcgencmd命令实现。创建/usr/local/bin/fan-control.sh#!/bin/bash TEMP$(vcgencmd measure_temp | sed s/temp//; s/\C//) if (( $(echo $TEMP 55 | bc -l) )); then echo 255 /sys/class/gpio/gpio256/value elif (( $(echo $TEMP 45 | bc -l) )); then echo 0 /sys/class/gpio/gpio256/value fi通过systemd定时每5秒执行该脚本使风扇转速随温度线性变化既保证散热又降低噪音。3.2 Neo4j图数据库的ARM64深度调优Neo4j官方未提供ARM64原生包需手动编译。我基于Neo4j 5.13源码修改pom.xml中maven-compiler-plugin的source和target为17并替换neo4j-kernel模块的JNI调用为纯Java实现规避ARM64不支持的汇编指令。编译后得到neo4j-community-5.13.0-arm64.tar.gz。关键配置位于conf/neo4j.conf# JVM内存精调树莓派5 8GB内存 dbms.memory.heap.initial_size2g dbms.memory.heap.max_size3g dbms.memory.pagecache.size1g # 启用LZ4压缩减少SSD写入 dbms.directories.data/mnt/ssd/neo4j/data dbms.directories.logs/mnt/ssd/neo4j/logs dbms.directories.plugins/mnt/ssd/neo4j/plugins dbms.tx_log.rotation.size256m dbms.tx_log.rotation.keep_number5 # 禁用全文索引节省内存 dbms.index.fulltext.enabledfalseheap.max_size3g是经过压力测试后的最优值小于2.5g时GC频繁每2分钟一次Full GC大于3.5g时Linux OOM Killer会杀死Neo4j进程。pagecache.size1g将SSD读取缓存设为1GB使Cypher查询响应时间从平均42ms降至12ms。所有数据目录挂载到USB3.0 NVMe SSD通过ASMedia ASM1083 PCIe桥接芯片避免microSD卡成为I/O瓶颈。3.3 Ollama模型服务的树莓派适配Ollama官方不支持ARM64我基于其v0.1.42源码重写server/routes.go中的模型加载逻辑使其支持GGUF格式量化模型。构建镜像jeremy-adams/ollama-arm64的核心Dockerfile片段FROM balenalib/raspberry-pi64-debian:bookworm-build RUN apt-get update apt-get install -y \ build-essential \ libz-dev \ libssl-dev \ rm -rf /var/lib/apt/lists/* COPY ./ollama-src /src WORKDIR /src RUN make build cp ./ollama /usr/local/bin/ COPY ./models/qwen2-0.5b.Q4_K_M.gguf /root/.ollama/models/ EXPOSE 11434 CMD [ollama, serve]模型选用Qwen2-0.5B-int44-bit量化在树莓派5上推理速度达3.2 tokens/s足以支撑日常对话。通过curl http://localhost:11434/api/chat调用请求体包含{ model: qwen2:0.5b, messages: [{role: user, content: 今天天气如何}], stream: false, options: {num_ctx: 2048, num_predict: 128} }num_ctx2048限制上下文长度防止内存溢出num_predict128控制最大生成长度避免长文本阻塞服务。3.4 MCP服务与POLE引擎的实现MCP服务基于FastAPI构建核心代码main.pyfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel import json import requests from neo4j import GraphDatabase app FastAPI() driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) class MCPRequest(BaseModel): method: str params: dict app.post(/mcp) async def handle_mcp(request: MCPRequest): if request.method mcp.tools.list: return {result: [{name: light_control, description: 控制灯光亮度, parameters: {room: string, brightness: int}}]} elif request.method mcp.send: # POLE循环入口 plan generate_plan(request.params[content]) # 调用LLM生成计划 observe_result observe_state(plan) # 查询Neo4j获取当前状态 execute_result execute_plan(plan) # 调用工具插件 learn_from_result(plan, execute_result) # 将结果存入Neo4j return {result: execute_result} else: raise HTTPException(status_code400, detailUnsupported method)generate_plan()函数向Ollama服务发送请求observe_state()通过Neo4j Driver执行Cypher查询def observe_state(plan): with driver.session() as session: result session.run( MATCH (p:Person {name: $person})-[:LAST_CONTROLLED]-(d:Device) WHERE d.type IN $device_types RETURN d.name AS device, d.state AS state, personJeremy, device_types[light, speaker] ) return [record.data() for record in result]execute_plan()根据计划调用对应Python模块如light_control.py通过RPi.GPIO库控制BCM18引脚PWM输出learn_from_result()将执行日志写入图谱CREATE (:Execution {timestamp: datetime(), status: $status, duration: $duration}) -[:CAUSED_BY]-(:PlanStep {tool: $tool, params: $params})3.5 Docker Compose编排与网络隔离docker-compose.yml定义了服务拓扑version: 3.8 services: neo4j: image: jeremy-adams/neo4j-rpi5:5.13 restart: unless-stopped volumes: - /mnt/ssd/neo4j/data:/data - /mnt/ssd/neo4j/logs:/logs environment: - NEO4J_AUTHneo4j/password - NEO4J_dbms_memory_heap_max__size3g ports: - 7474:7474 # 仅对宿主机开放管理端口 networks: - jeremy-net ollama: image: jeremy-adams/ollama-arm64:0.1.42 restart: unless-stopped volumes: - /mnt/ssd/ollama/models:/root/.ollama/models ports: - 11434:11434 networks: - jeremy-net mcp-server: image: jeremy-adams/mcp-server:0.3.1 restart: unless-stopped depends_on: - neo4j - ollama environment: - NEO4J_URIbolt://neo4j:7687 - OLLAMA_URIhttp://ollama:11434 ports: - 8000:8000 # MCP HTTP端点 - 8001:8001 # MCP WebSocket端点 networks: - jeremy-net networks: jeremy-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16关键设计点所有服务共用jeremy-net自定义桥接网络IP段172.20.0.0/16避免与家庭路由器网段冲突neo4j容器不暴露7687端口给外部仅允许mcp-server通过bolt://neo4j:7687访问杜绝图数据库被外部扫描ollama容器通过http://ollama:11434被mcp-server调用而非http://localhost:11434避免容器内DNS解析失败。4. 实操过程与核心环节实现4.1 从零开始的完整部署流程含时间戳记录整个部署耗时17小时23分钟含等待编译、下载、测试分阶段记录如下阶段一硬件准备与系统初始化2h15m00:00–00:25烧录Raspberry Pi OS镜像配置Wi-Fi与SSH密钥00:25–01:10执行基础加固禁用服务、GPU内存设置、风扇脚本01:10–02:15挂载USB3.0 NVMe SSDsudo mkfs.ext4 /dev/sda1→/etc/fstab添加自动挂载。阶段二Neo4j编译与配置5h40m02:15–03:30安装JDK17sudo apt install openjdk-17-jdk验证java -version03:30–05:15下载Neo4j 5.13源码修改pom.xml执行mvn clean package -DskipTestsARM64编译耗时1h45m05:15–06:00解压编译产物配置neo4j.conf启动服务并验证curl -u neo4j:password http://localhost:7474/db/neo4j/label返回20006:00–07:55导入初始数据集10万节点/50万关系执行CALL apoc.periodic.iterate批量创建耗时1h55m。阶段三Ollama与模型部署4h20m07:55–08:30安装Dockercurl -sSL https://get.docker.com | sh添加pi用户到docker组08:30–09:45克隆Ollama源码修改ARM64适配代码make build耗时1h15m09:45–10:30构建jeremy-adams/ollama-arm64镜像推送至本地Registry10:30–12:10下载Qwen2-0.5B-int4 GGUF模型1.2GB验证curl http://localhost:11434/api/tags返回模型列表。阶段四MCP服务开发与联调5h28m12:10–13:20编写FastAPI框架实现mcp.tools.list和mcp.send基础路由13:20–14:50集成Neo4j Driver实现observe_state()函数测试Cypher查询性能14:50–16:30开发light_control.py工具插件控制GPIO18 PWM实测亮度调节精度达±2%16:30–17:23编写POLE循环逻辑启动docker-compose up -d用curl -X POST http://localhost:8000/mcp发送测试指令首次获得完整响应。4.2 关键参数计算与选择依据Neo4j JVM堆内存3GB的确定过程树莓派5总内存8GB系统占用约1.2GB含桌面环境Docker守护进程占用约0.3GBOllama服务占用约1.8GBQwen2-0.5B-int4模型加载推理缓存剩余可用内存≈8 - 1.2 - 0.3 - 1.8 4.7GBNeo4j需预留1GB PageCache故堆内存上限为4.7 - 1 3.7GB但实测3.7GB时GC压力过大jstat -gc显示Young GC每45秒一次逐步下调至3GB后Young GC间隔延长至3.2分钟Full GC消失。Ollama模型量化位数4-bit的选择Qwen2-0.5B原始FP16模型大小1.1GBGGUF 8-bit量化680MB推理速度1.8 t/sGGUF 4-bit量化320MB推理速度3.2 t/s计算公式推理速度 ∝ 1 / (模型大小 × 内存带宽)树莓派5内存带宽为25.6 GB/s4-bit模型在带宽利用率上比8-bit低42%故速度提升显著。且320MB模型可完全载入RAM避免SSD交换进一步提速。MCP WebSocket心跳间隔30秒的设定树莓派5的Wi-Fi模块在空闲时会进入省电模式断开TCP连接测试不同心跳值10秒心跳导致Wi-Fi模块频繁唤醒功耗增加18%60秒心跳在弱信号环境下易断连30秒是平衡功耗与连接稳定性的最优值实测连续72小时无断连。4.3 实操现场记录一次典型交互的完整链路用户语音指令“把书房灯调到50%然后告诉我现在几点。”Step 1语音转文本由手机App完成非树莓派处理App将语音识别为文本通过HTTP POST发送至http://raspberrypi.local:8000/mcp{method: mcp.send, params: {content: 把书房灯调到50%然后告诉我现在几点。}}Step 2MCP服务接收并启动POLE循环generate_plan()向Ollama发送请求LLM返回结构化计划[ {tool: light_control, params: {room: study, brightness: 50}}, {tool: system_time, params: {}} ]observe_state()执行Cypher查询MATCH (p:Person {name: Jeremy})-[:LAST_CONTROLLED]-(d:Device {room: study, type: light}) RETURN d.brightness AS current_brightness返回{current_brightness: 80}确认当前亮度为80%计划可行。Step 3执行与学习light_control.py调用RPi.GPIO.PWM(12, 100).ChangeDutyCycle(50)将GPIO12 PWM占空比设为50%system_time.py执行datetime.now().strftime(%H:%M)返回14:23learn_from_result()写入Neo4jCREATE (:Execution {timestamp: datetime(2024-06-15T14:23:05), status: success, duration: 124}) -[:CAUSED_BY]-(:PlanStep {tool: light_control, params: {room: study, brightness: 50}}) -[:CAUSED_BY]-(:PlanStep {tool: system_time, params: {}})Step 4返回响应MCP服务组装最终响应{ result: { steps: [ {tool: light_control, status: success, output: 书房灯亮度已设为50%}, {tool: system_time, status: success, output: 现在是14:23} ] } }App解析后语音播报“书房灯亮度已设为50%现在是14点23分。”整个链路耗时427ms从HTTP请求到响应其中Neo4j查询12ms、Ollama推理210ms、工具执行185ms、网络传输20ms。5. 常见问题与排查技巧实录5.1 Docker容器间无法通信树莓派特有的网络陷阱现象mcp-server容器内curl http://ollama:11434/api/tags返回Connection refused但curl http://localhost:11434/api/tags在宿主机上正常。根因分析树莓派5的Docker守护进程默认使用iptables管理网络规则而Raspberry Pi OS Bookworm内核的nf_tables模块与Docker的iptables-legacy存在兼容性问题导致容器间DNS解析失败。解决方案强制Docker使用nftables后端echo { iptables: false } | sudo tee /etc/docker/daemon.json sudo systemctl restart docker在docker-compose.yml中为mcp-server服务添加extra_hostsextra_hosts: - ollama:host-gateway - neo4j:host-gateway修改mcp-server代码将Ollama URI硬编码为http://host-gateway:11434。实操心得此问题在x86_64 PC上几乎不会出现是ARM64 Docker生态的特有坑。务必在部署初期就验证容器间连通性否则后续所有调试都将陷入迷雾。5.2 Neo4j启动失败JVM内存参数的致命陷阱现象docker logs neo4j显示Error occurred during initialization of VM Could not reserve enough space for 3145728KB object heap。根因分析树莓派5的Linux内核对大内存页Huge Pages支持不完善-Xmx3g参数要求连续3GB物理内存而系统内存碎片化严重。解决方案改用-XX:UseG1GC -Xms2g -Xmx2gG1垃圾收集器对内存碎片容忍度更高在/etc/sysctl.conf中添加vm.swappiness10 vm.vfs_cache_pressure50降低交换倾向提升VFS缓存效率重启后执行sudo sysctl -p生效。5.3 Ollama推理卡死量化模型的ARM64指令集兼容性现象Ollama服务启动正常但调用/api/chat时CPU占用100%无响应dmesg显示traps: ollama[1234] undefined instruction。根因分析部分GGUF模型在量化时启用了ARM64的dotprod点积指令而树莓派5的Cortex-A76 CPU不支持该指令仅A77支持。解决方案重新量化模型禁用高级指令./llama.cpp/convert.py --outtype f16 --outfile qwen2-0.5b.Q4_K_M.gguf qwen2-0.5b.bin ./llama.cpp/quantize --q_type Q4_K_M --no_dotprod qwen2-0.5b.Q4_K_M.gguf qwen2-0.5b.Q4_K_M.no-dotprod.gguf使用--no_dotprod参数确保生成的GGUF文件仅使用基础ARM64指令集。5.4 MCP协议调用超时树莓派Wi-Fi的MTU问题现象手机App调用MCP接口时小请求1KB正常大请求1.5KB超时。根因分析树莓派5 Wi-Fi模块默认MTU为1500而手机Wi-Fi路由器MTU为1450导致TCP分片丢失。解决方案在树莓派上降低Wi-Fi接口MTUsudo ip link set wlan0 mtu 1450将该命令加入/etc/rc.local确保开机生效。5.5 POLE循环阻塞工具插件的同步I/O陷阱现象执行light_control后整个POLE循环卡住30秒后续指令全部堆积。根因分析light_control.py中使用time.sleep(30)模拟设备响应延迟但这是主线程阻塞导致FastAPI事件循环停滞。解决方案改用异步非阻塞方式import asyncio async def control_light(room: str, brightness: int): # GPIO控制代码 await asyncio.sleep(0.1) # 模拟硬件响应 return f{room}灯亮度设为{brightness}%在POLE循环中用await control_light(...)调用释放事件循环。6. 性能基准与扩展可能性6.1 树莓派5上的实测性能基准测试项配置结果说明Neo4j Cypher查询延迟10万节点/50万关系MATCH (n:Person)-[r]-(m:Device) RETURN count(r)平均12.3ms启用PageCache后性能提升3.5倍Ollama推理吞吐Qwen2-0.5B-int4num_predict1283.2 tokens/s满载CPU温度62℃无降频MCP HTTP请求延迟mcp.send完整POLE循环P50427ms, P95680ms包含Neo4j查询LLM推理工具执行系统功耗空闲状态3.8WUSB3.0 SSD待机功耗0.5W系统功耗满载状态6.9WCPU/GPU全频运行风扇全速这些数据证明树莓派5完全有能力承载一个功能完备的本地AI智能体其性能边界不在算力而在I/O与内存带宽。当模型升级至Qwen2-1.5B-int4时推理速度降至1.1 tokens/s但通过将模型权重分块加载按需从SSD读取可维持P95延迟在1.2秒内——这已满足绝大多数家庭交互场景。6.2 可扩展的进阶方向硬件扩展添加树莓派Camera Module 3IMX708传感器通过libcamera库接入POLE的observe环节实现“视觉感知”——例如指令“检查厨房是否有人”智能体自动拍照并调用本地YOLOv8n模型分析接入USB麦克风阵列如ReSpeaker 4-Mic Array替换手机语音输入实现全本地语音识别Whisper.cpp ARM64量化版。软件扩展将M
阅读完成 · 觉得有帮助？
