CarWatch: 基于 Raspberry Pi 5 的车载本地 AI Agent

CarWatch 是一个开源项目，它通过使用 Raspberry Pi 5 将本地大语言模型 (LLM) 集成到车辆中，从而将汽车变成一个功能齐全的聊天室 Agent。通过在本地运行量化后的 Qwen 模型，该系统可以提供免提语音交互、通过 RAG 进行的车主手册检索，以及实时车辆遥测数据，而核心操作无需依赖云端连接。

本地 AI 架构与性能

CarWatch 利用 Raspberry Pi 5 (16 GB RAM) 运行使用 Unsloth UD-Q3_K_S 动态量化的 Qwen3.6-35B-A3B。这种设置允许系统完全离线运行，确保在车库或没有互联网连接的盲区内也能正常工作。

真实硬件上的关键性能指标包括：

生成速度： 每秒 3.5 个 token。
提示词处理： 每秒 25 个以上 token。
散热性能： 持续温度为 65°C（需要主动散热）。
内存占用： 模型占用约 14.3 GB RAM。

核心功能能力

基于事实知识与 RAG

为了防止幻觉并确保技术准确性，CarWatch 使用了词法检索增强生成 (RAG) 系统。系统在 SD 卡中内置了汽车的 745 页车主手册。LLM 被指示严格基于手册提供答案，包括页码引用，并且被设计为拒绝回答手册中未包含的内容。

实时车辆状态监控

该系统与车辆硬件集成，以提供基于事实的自我知识。它可以读取以下实时数据：

硬件状态： CPU 温度、降频状态、风扇转速、内存使用情况以及磁盘/网络状态。
车辆遥测： 通过以太网转 OBD (DoIP/ENET) 线缆，该系统旨在监控 RPM、冷却液温度、车速和电压（目前已针对模拟网关进行了验证）。

免提语音接口

CarWatch 在 Pi 上实现了一个连续监听流水线： Energy VAD → whisper.cpp → Grounded LLM Pipeline → Room Output。这消除了对唤醒词仪式感的需求以及对基于云端的语音转文本 (STT) 的需求，从而使所有音频处理都在本地完成。

连接性与部署策略

CarWatch 采用三层连接模型，以平衡本地实用性与远程增强功能：

始终本地： 语音输入、LLM 答案、RAG 检索以及手机仪表盘（由汽车提供服务）在无信号状态下即可工作。
队列式连接： 聊天室帖子、行车记录仪片段上传以及提及回复会被存储在持久化的磁盘输出队列中，并在建立连接后进行交付。
仅限在线： 通过拨号隧道 (cloudflared) 实现远程可达性、从 GitHub 进行自我更新，以及可选的向云端模型升级。

硬件参考构建方案

对于想要复刻该构建方案的用户，参考硬件包括：

SBC： Raspberry Pi 5, 16 GB RAM，配备主动散热。
音频： 符合 Class-compliant 标准的 USB 麦克风。
行车记录仪： WOLFBOX G900 3-channel camera（通过 WiFi AP 连接以进行事件片段检索）。
OBD 访问： 以太网转 OBD (DoIP/ENET) 线缆或 ELM327 级适配器。
电源： 通过 12V PD 适配器或 230V 插座提供 5V/5A USB-C 供电。

社区洞察与批评

虽然该项目展示了在汽车环境中部署本地 LLM 的可行性，但 Hacker News 上的社区讨论突出了几个技术和实际应用方面的担忧：

准确性与安全性： 一些用户警告说，LLM 经常在处理高度具体的汽车细节（例如特定年份车型的油液规格）时遇到困难，因此建议依靠 LLM 进行机械维护可能存在风险。

Utility 与使用场景： 批评者质疑了语音 Agent 对于调整空调或锁门等任务相比物理按键的实际优势，认为该项目的价值更多在于汽车的“Agentic”特性（例如向聊天室报告到达/离开情况）而非取代现有的汽车控制功能。

集成复杂度： 针对与制造商 API 的对接难度以及通过 Raspberry Pi 创建车辆的“第二把钥匙”所带来的安全隐患提出了疑问。

"汽车在路面上保持着四个手掌大小的接触点，那是它唯一能与现实接触的地方。一个原则：每个轮子一个原则——只断言你所能感知的，只声称你所验证的，大声标注任何中间状态，并平实地报告失败，不带任何粉饰。"

— CarWatch development log