这件事几乎没人看。仓库 421 次提交、286 个星标、18 个 fork、2 个 watcher，这是九月初的数据。在 AI 圈的二线项目里，这个数连“边缘案例”都算不上——同时间段随便一个套壳 Agent 项目的星标都能过千，因为人们会为“想法”星标，不会为“这辆车今天没有编造 PID”星标。但 CarWatch 这个仓库做到了在我看来远比星标更硬的一件事：它在一个约 300 欧元的树莓派上，把一台 2021 款奔驰 E 300e 插混做成了一个会说话、有边界、能报数据、拒绝胡说的聊天室智能体，全程本地。AI 圈每天在发布会里喊的“端侧智能”“离线 Agent”“数据主权”，它用一个人的一个仓库跑通了。
这不是要夸它技术多好。它抓住一个被绕开的问题不放：如果 300 欧元和约 14 GB 量化模型就能把一辆车接进来，那这个行业里最贵的钱，到底花到哪去了？
先把这个项目的底数摊清楚，不然后面拆的账都会悬着。参考硬件是树莓派 5 16GB、USB 麦克风、WOLFBOX G900 三通道行车记录仪、约 15 欧元的蓝牙 ELM327 OBD 适配器；作者给的总成本约 300 欧元。核心大脑是 Qwen3.6-35B-A3B，用 Unsloth UD-Q3_K_S 动态量化，README 里写的模型体积约 14.3 GB。实测生成速度约 3.5 token/秒，提示处理约 25 token/秒以上，持续温度 65°C，不依赖云、不依赖互联网、没有订阅。参考模型表里列的默认大脑文件大小约 15.4 GB，实测提示约 9.1 token/秒、生成约 2.9 token/秒。同一个模型在两个出处里生成速度差出约 0.6 token，这本身不是误差，是边缘设备上资源争用导致的波动——这种波动在云端报告里很少出现，在树莓派上却是常态，后面拆语音链路时会再撞一次。
账本摊开之后，第一条要确认的是：选 35B MoE 这件事，本质上是在“能回答 489 页手册问题”和“3.5 token/秒可等”之间找一个平衡。它就是那个平衡点，不是越大越好。参考模型表里还有 Gemma 4 E2B、E4B、Ornith 1.5 9B、Qwen3.6 27B、Ornith 1.5 35B MoE 这些候选。小模型快得多，但在这个任务里不顶用——回答车主手册问题需要读文档、抓上下文、给出页码，9B 的上下文保持和指令跟随在这个具体场景下不够踏实。35B MoE 呢，稀疏性救了它：总参数量 35B，但每个 token 只激活其中一小部分，所以生成速度由激活参数决定，不由 35B 这个吓人的总数决定。这就是为什么 Gemma 4 12B 多模态在树莓派上反而只有约 1.5 token/秒、被认为太慢只能做慢速后台读帧——而 35B MoE 能跑到接近它的两倍。不是 35B 比 12B 快，是稀疏 MoE 的账和稠密模型的账根本不是一种算法。
但 3.5 token/秒对“可不可用”这条线来说，是什么位置？算一笔延迟账。车载语音问答的典型答案是一句话，10 到 20 token。按 3.5 token/秒生成，一个 15 token 的答案需要 4 秒出头，加上提示处理的等待时间（25 token/秒以上的提示速度意味着一个典型问题只要半秒），用户体感是提问后 5 秒左右听到完整回答。对一个免手操作的、从车外扬声器回答的车主手册查询来说，5 秒是可接受的，但也不算从容。这个延迟把它的用况钉死在一类：一次答一句、答案短、语境单一。任何需要多轮来回、或者生成几百 token 补全的任务，3.5 token/秒会直接把耐心耗穿。这个项目的用户边界就藏在这个速度里——它不是一个通用车载助手，是一个边界非常清楚的车主手册问答 + 车况报告器。
再算模型加载的账。从 microSD 卡加载约 14 GB 模型大约需要三分钟，仪表盘显示的是基于模型体积的估算进度，而不是无意义动画。这个细节看起来很小，但它暴露了本地智能体的一个透明性优势：云端模型从来没让用户知道“加载”是什么，你请求它、它回答，背后的冷启动全被隐藏了；本地模型必须把“三分钟”亮出来，于是产品逻辑被迫诚实。三分钟对每次点火就走的通勤用户意味着什么？意味着这辆车在模型装载完成前是一个哑巴。这个问题车载场景下怎么解决？systemd 服务在启动时自动运行模型服务，等于用“车一通电就开始装载”来摊平冷启动。这又是系统层的账，不是模型层的账——一个云端 AI 产品经理根本不需要考虑冷启动，一个本地智能体的作者必须把它当成第一轮的考题。
速度账和加载账摊完之后，这个项目的真正问题就浮出来了：CarWatch 选的不是“在车上跑 AI”这条舒适的路，而是“在一辆真实车辆上维护一个常驻本地智能体”的完整工程栈。前者是模型发布会，后者是 systemd、蓝牙争用、回声消除、离线下发队列、NAT 穿透、自动回滚。前者热闹，后者冷清。仓库 286 星对 421 次提交，就是因为热闹的部分只值星标，冷清的部分才值提交。
拆开管道：真正贵的不是模型，是让模型可靠地活着
这节是全篇最碎、但账最重的一段，因为本地智能体的账本大头根本不在模型——在管道。我把 CarWatch 的管道拆成四条：RAG、语音、系统常驻、模型管理。每条都算一遍“这里为什么不能省”。
先讲 RAG。约 489 页车主手册的本地检索增强生成，答案带页码引用；手册未涵盖的内容会被拒绝回答。这两条单看任何一条都不新鲜，RAG 带着页码、遇到知识范围外就说不知道，这是工程上很标准的设计。不标准的是它们在一个 300 欧元的树莓派上、和一个 35B MoE 一起、在车里跑通。这个 RAG 管道的边界意识，和整个项目其他地方的行为是一套哲学：系统能感知的就说感知，感知不到的明确说无法感知；能引手册的引页码，手册没写的拒绝回答。这套哲学翻译成人话：这辆车是一个拒绝编造数据的聊天室成员，比你手机里大多数所谓“智能助手”的边界感清楚得多。而这个边界感，不是靠 prompt 工程压出来的——我不信一个 API 里加一句“请保持诚实”能换来真正的边界——它靠的是把知识来源硬化成 489 页 PDF、把答案锚定到页码、把不属于这个来源的请求直接拒掉。边界感是结构性的，不是话术性的。
CAN 总线的事得顺带提一句，因为它和 RAG 的“页码引用”在原理上是同一件事的两个不同侧面。仓库已经捕获原始 CAN 总线 2518 帧且无错误，但信号命名仍需要相关行驶数据，目前只有候选信号、未标注。也就是说，OBD 读上来的是一堆帧，不是一堆带名字的语义量；你得靠标注数据去命名信号，否则就是个“读到了但不知道是什么”的困境。这和 RAG 的页码是同一根柱子：一个智能化系统要么把知识锚定到外部硬结构（手册、标注好的信号字典），要么靠大模型猜——CarWatch 这个项目从头到尾选择的都是前者，拒绝让模型的概率推断去补没有结构支撑的缺口。这个选择本身不性感，而且限制能力，但它是账本意义上最便宜的选择：错误可溯源，边界可验证。
语音这条最重。蓝牙 OBD 适配器约每 20 秒轮询一次，与语音回答共用无线电，而语音回答没有设安静窗口，导致回答卡顿。修复提交是 b6904bf。一个边缘设备同时跑 OBD 蓝牙、语音转写、WLAN、模型推理，无线电和 CPU 争用不是偶发，是结构性的日常。云端的语音助手永远不会撞上这件事，因为在那里，音频采集、ASR、LLM、网络都跑在相互隔离的机房里，各有各的带宽和算力预算；但在一台树莓派上，一个蓝牙 OBD 的 20 秒轮询就足以把正在生成的语音回答卡顿。这个问题的本质不是“代码写错”，而是 300 欧元边缘设备上的资源争用是常态，解决它需要的是管道级的留白和时序设计。
另一个更值得停一秒的细节：FAQ 提到车辆曾出现听到自己回答尾部而自我回复的问题。扬声器播放的回答被车里的麦克风收进去，转写后当成新的语音问题触发模型又回答，于是车和自己对话。v0.4 加了一个回声门：麦克风在车内音频结束前保持关闭，同时转写内容如果是自身最后回答的复制就被丢弃。这两件事——回声门和自我复制检测，都是很土、很脏的活。任何做过车载语音或对讲系统的工程师都知道这件事多麻烦，而它和“AI 能力”没有任何关系。它是把“说话”这个动作放到一个有扬声器有麦克风的物理空间里之后，必须解决的基础声学问题。本地智能体的账本里，这类问题占了最大的篇幅，却最没有叙事价值——没有人会为“回音门”写融资 BP，但漏掉它，车会在深夜的地库里自己和自己聊一宿。
系统常驻和运维这条，账最重。仓库在树莓派上用 systemd 服务启动一个五件套的服务栈——模型服务、房间代理、语音监听、手机仪表盘、引擎监控；自动更新每小时从仓库拉取，也可以仪表盘手动触发；通过 dial-out 隧道在 NAT 后保持可达；离线时消息先进磁盘 outbox，恢复连接后再投递，避免丢失。这是把“一个常驻边缘智能体”当成了生产级服务在管，用的是一个单机 Linux 系统最土、最可靠的工具：systemd。这个选择和当下 AI 圈对“Agent 平台”的叙事完全对撞——你听见过哪个 Agent 平台的发布会在讲 systemd 自动重启？没有。他们讲的是自主决策、多步推理、记忆系统。可一辆在车里的智能体，断电重启后能不能自己活过来、离线时会不会丢消息、NAT 后别人能不能找到它，这三件事比多步推理更需要先解决。CarWatch 用 systemd、outbox、dial-out tunnel 解决了，而且核心代码只依赖 Python 标准库，无 pip、无 venv、无额外依赖，AST 扫描验证过。
“标准库”这事得拆透一点。一个本地智能体要想活过所有环境、不依赖云、不依赖订阅，第一道真正的门槛不是模型能力，是“安装即运行”。pip、venv、依赖树，这些在云服务器上不是事，在车主手里的一台树莓派上就是死罪——依赖装不上、版本冲突、缺一个库，整个栈瘫掉。CarWatch 用标准库写核心代码，本质上是把“部署成本”压到了一个人 clone 完仓库跑一下 install.sh 就能起服务栈的程度。这是分发问题，不是技术问题；但本地智能体能不能跨出极客圈的第一道命门，全在这个“不依赖”上。这个选择我一边说一边也清楚它的代价：标准库能解决的问题有限，复杂度都转移到了作者自己的实现里，所以这仓库 421 次提交里，一大部分可能在重造别人用 pip 一行装掉的轮子。这账怎么算都亏，但亏在作者的时间上，省在用户的安装上——对一个想活过十年的系统层探针来说，这是被迫的，也是对的。
模型管理这条相对轻一点。仓库留了两个 API 端点：GET /api/models 看注册表和状态，POST /api/model 执行受保护的模型切换；服务从 EnvironmentFile 读模型配置。切换有几条硬规则：装不进内存的模型拒绝并说明原因；切换不中断正在生成的回答；重启失败回滚到原模型。这套设计读下来像一个很小型的生产级模型网关——保护内存、保护正在进行的推理、保护可用性，三条都有。但它同时暴露了一个本地智能体的死穴：模型切换要求用户自己理解 .gguf 文件、内存大小、速度基准。v0.5 计划从手机侧列出设备上所有 .gguf 并允许切换，仪表盘会用 llama-bench 在本地实测速度。这很透明，也很极客。它要求用户对“模型”这件事有一颗至少半懂的脑袋，而大多数人没有。这个张力在后面判断时会收口：CarWatch 的整个栈给极客用是顺滑的，给“装了就忘”的人用是跨不过去的。
四条管道拆完，一句话可以收口：CarWatch 费了 421 次提交里的绝大部分力气，不是在造一个更聪明的模型，是在造一套让一个 35B 量化模型在一辆真实的车里、在一台真实边缘设备上、在无云端的情况下可靠呼吸的系统。这些管道没有 AI 叙事价值，但它们才是历史对照里能站住脚的硬材料。AI 行业现在恰恰对模型层无限敏感、对系统层无限钝感——这条我一直想说，CarWatch 给了我一个具体得不能再具体的样本。
这笔钱从哪来、流到哪去、卡在谁手里
这件事里有五方。第一方是那个付 300 欧元买硬件的极客车主。第二方是 ThinkOff / Petrus Pennanen，作者本人，2026 年这个仓库、这套接口、这堆文档的唯一维护者和意图卡位者。第三方是树莓派这个硬件生态。第四方是车企——具体是奔驰的云数据服务。第五方是那个被绕开的云端车联网 AI 方案市场。这五方之外还有一个旁观但相关的角色：开源模型厂商 Qwen，它提供的 open weights 是这件事能发生的前提，但它本身在这条本地路线里一毛订阅都不赚。
先讲车主。这 300 欧元换来的是：数据留在车内、模型离线运行、没有订阅、没有云账单、没有推送广告。还要加上车主的车在远程可做的边界：锁门和关窗可以从手表远程执行，但解锁、开门、启动被明确设计为不可实现。这个边界划线很有意思，它透露出作者对安全红线的判断很老练——远程可执行的动作只限于那些“最多造成不便、不产生危险”的，而任何涉及车辆控制权的（解锁、启动）被挡在系统设计之外。一个车主花 300 欧，得到的是数据主权加一块清醒的边界；但前提是他要会装、会配、会维护。装 install.sh、配 ~/.carwatch/config.json、在 config 里填 GroupMind 服务器地址、API 密钥、房间、代理句柄、车辆描述、家庭 Wi-Fi SSID——这些对从来没有碰过 Linux 的人每一条都是劝退。所以这个“车主”是带引号的：他首先是极客，其次才是车主。
其次讲作者，这里是整件事最关键的位置。CarWatch 不做封闭产品，它做的是一个厂商中立的数据层接口：carwatch/cloudcar.py，奔驰是第一个适配器，其他品牌只需要实现三个方法就能接入。这就是 ThinkOff 在卡的位置——不是某一家车企的云，不是某个平台的 API，而是一个品牌无关的、本地优先的、AGPL-3.0 许可的汽车数据接口规范。AGPL 在这里不是随便选的。它意味着任何把这个数据层用起来的衍生服务，如果它自己对外提供网络服务，就得把源码开放出来。对一个意图卡住“厂商中立标准”位置的单人项目来说，AGPL 是一种防守性扩张协议——自己活得不好无所谓，但别让别人把这个位置用闭源方式抢了。星标只有 286 个，但接口设计是行业级的；这是典型的不对称：这个仓库在社区层面没有引力，但在架构层面有卡位意图。
第三方针派生态是沉默的受益者。树莓派 5 16GB 把 35B MoE 的价格门槛拉到 300 欧元量级，这是这个路线能成立的前置条件。如果边缘设备还在 8GB 内存那一代，35B 的 Q3 量化装不进去，这个项目根本不存在于讨论范围里。和作者或车主不同，树莓派没有做任何针对性的动作，它只是按自己的硬件演进节奏走，结果这个演进节奏恰好落到了一个让“边缘大模型”从笑话变成可实测的位置上。这本身是一个被低估的结构性细节：边缘 AI 的很多看似“路线突破”的事件，其实只是通用硬件的能力越过了一条成本/内存线。对判断这个品类的节奏，这条比任何模型发布时间表都更靠得住。
第四方车企最微妙。在 CarWatch 的架构里，OBD 数据是本地直读的，任何支持标准 OBD-II 的车辆都能用，约 15 欧元的 ELM327 适配器即可；但厂商云数据（也就是那套远程状态、电池/充电状态等）还要靠 Home Assistant 来读，首个适配器是奔驰。也就是说，车企的云在这一版里不是被完全绕开，而是被当作一个可选的外部数据源，且要通过 Home Assistant 这一层来桥接；车在外时再通过 Tailscale 打一条私有加密隧道回去。车企对这件事的态度大概率是“没注意到”。但这恰恰是被绕开的一方的典型状态：不是愤怒，而是无感——因为入侵者太小了，小到不值得开会。然而这个“没注意到”对应的，是车引擎数据、混动充电里程碑、故障码正在被一个 300 欧的树莓派实时读走，并在一个车主自己控权的家族聊天室里投递，而车企云在这一过程中没有出现在数据路径上。这笔钱谁买单、谁接刀的账里，车企的云服务是那个最慢意识到自己被绕开的一方。
第五方是云端车联网 AI/助手的方案商。这类公司想把车变成“智能座舱助手”，收费靠订阅或 OEM 授权，数据靠云端聚合。CarWatch 走的路线如果规模化，会直接把这些方案的核心卖点拆掉：车主不需要订阅，也不需要把车辆数据交出去，一样能得到“和车对话”的能力。但规模化的门槛太高，所以目前它们并没有真实感觉到疼。这个“没感到疼”，不是安全，是时间差。参照系是：一旦厂商中立接口和本地推理的体验接近可用阈值，再加上有像 Home Assistant 这样已经活下来的本地生态做底座，这类云端方案的中间位置就会开始松动。松动多大，取决于分发能不能越过极客圈——这是历史对照那一节要算的账。
这一轮的上一轮，是 Home Assistant 和 local-first 那条没走完的路
CarWatch 这个项目，2026 年，一辆车，被做成聊天室里一个会报数据的代理。把它放回上一个周期看，它不是凭空冒出来的——它踩着一根已经活了十几年的本地自动化藤蔓在长。清单里写得很直白：制造商云数据的读取依赖 Home Assistant，车辆在外时建议 Tailscale 回连。Home Assistant 就是那根藤蔓，而且它恰恰是上一轮本地优先 / 自我托管运动里活下来的少数几个。
上一轮 local-first 的账，今天回头看，终点几乎都死在同一个地方：不是技术不行，是分发失败、信任链太长、最终只有极客跑得通。Home Assistant 是那场运动里活下来的例外，而它活下来靠的也不是哪项独门技术——它靠的是十几年里把集成数量堆到令人麻木的程度、把安装体验从“自己编译 YAML”慢慢降到有可市场化的入口（Nabu Casa 的订阅），然后才有了今天的生态引力。Home Assistant 用十年时间解决了两件 local-first 运动没解决的事：一是让普通人能装起来，二是给自己找到一个不用卖数据也能活的分发和服务闭环。CarWatch 现在做的，本质上是把 Home Assistant 那根藤蔓从家里伸到车里：引擎数据、充电里程碑、故障码实时进家庭聊天室；两辆车作为同一账户下的独立代理；房屋代理和汽车代理协作（离家前预热车厢、回家路上开暖气和烧水）。这是 Home Assistant 的叙事延伸，不是另起炉灶。
这次有什么不同？三点。第一，上一轮 local-first 没有模型，所有自动化都得靠用户自己写规则、写自动化脚本，门槛高、天花板也低；这一次的本地设备可以跑一个 35B 稀疏模型，能把半结构化数据（车主手册、OBD 数据）转成自然语言，还知道边界。这降低了“让不写规则的人也能用”的门槛。第二，Home Assistant 已经把家庭自动化这条路走通了分发模型，CarWatch 不需要从零教育市场什么叫本地优先级。第三，硬件底座的性价比变了：树莓派 5 16GB 把 35B MoE 压到 300 欧元上下，这件事在 Home Assistant 崛起的年代根本不在可选范围内。
但有什么没变？这一条更要紧。没变的恰恰是上一轮 local-first 死掉的那个点：分发之外的那根“信任链”问题，从来不是技术问题，是服务问题。 Home Assistant 活下来，是因为它最终没有坚持纯 free、纯 no-subscription 的教条，Nabu Casa 给了它分发的闭环。CarWatch 呢，恰恰走了 Home Assistant 早期最倔的那条路：全部本地、零订阅、AGPL-3.0、不依赖云。这条路能不能绕过分发的大坑？我目前的答案是不能，至少没有证据证明它能。286 星对 421 次提交的配比已经说明：这个仓库付出的工程密度和它收获的社区引力完全不匹配，而这不匹配不是运气问题，是这条路线当前最诚实的定价。
历史再往深拉一层。上一轮更早的 self-hosted 运动（大约七八年前那波），也有一堆“把某个设备从封闭云里解放出来”的项目。那些项目今天大部分都不再维护，不是因为他们做得不够好，而是因为“解放”这个动作本身不产生可持续的经济模型——作者烧掉大量时间，用户省了一点云费，生态没有续命钱。活下来的，要么像 Home Assistant 找到了订阅或商业生态，要么退化成某个协议被更大的平台吸收。CarWatch 现在的情况像前者的早期，但它的作者在仓库里明确写的是 2026 年的版权、AGPL-3.0、以及一个只有 2 个 watcher 的社区。我愿意把这看成诚实：这是一个心甘情愿停在极客圈的项目，不是一个假装要规模化的项目。
这一段我算得有些碎，但历史对照的账不碎算不清。碎完之后的收口是：CarWatch 是 local-first 这棵藤蔓长到汽车上的第一根分支，它吸取的营养是 Home Assistant 用十几年造好的土，但它自己选择的那条“零订阅、全本地”的路，恰恰是上一轮反复验证过最难走通的那条。
视觉和行车记录仪——本该属于它的那条能力线，还没接通
有个断层得停下来拆一下：CarWatch 有行车记录仪硬件，但对它几乎还闭着眼。WOLFBOX G900 的 API 已经探测过，但把事件视频拉到聊天室发布的流水线还没接通；视觉能力明确没实现。项目把 Gemma 4 12B 多模态列为候选，但在树莓派上生成速度约 1.5 token/秒，被认为太慢，只适合慢速后台读帧。这个项目的“感知—行动”闭环里，语音和 OBD 数据这边是通的，视觉那边还是半盲的；它有一双记录仪的眼睛，但还没有大脑去读那些帧，或者更准确地说，有一个能读的候选大脑，但推理速度不足以实时读。
这个断层值得写一笔，是因为它反向确认了 CarWatch 当前的产品边界不是被“理想”限定，而是被“现实带宽”限定。如果有人把这个项目读成一个“全感知车载智能体”，那是把它幻想得太满；实际状态是，它能把手册问答和 OBD / 云数据报告这两个正交线跑通，已经是当前硬件与模型条件下能压出来的极限。视觉一旦强制加入，1.5 token/秒的读帧会把生成链路拖到用户完全不能交互的节奏。这个选择不是功能取舍，是速度天花板下的被迫划分：在 300 欧元硬件上，你不能同时拥有 35B 的语言和 12B 多模态的实时视觉，你只能选一个当前行得通的智能面。任何宣称“端侧能全感知”的说法，碰到这块 300 欧元的树莓派和这份实测表，都会缩回去。
还有一处更隐蔽的“未完成”，在 OBD 的语义层。前面提过 CAN 总线捕获了 2518 帧无错误，但信号命名仍悬着，只有候选信号、没标注。它意味着这辆车虽然能实时读 OBD、能报运行状态（温度、降频、风扇、内存、磁盘、网络、加载的模型），但它对“车此刻究竟发生了什么”的语义理解还只是半解。它能报，但有些帧它还报不出发动机具体工作点、电池具体健康度这类下游语义，因为它没标签。这个状态，和视觉没有实装，二选一地指向同一件事：边缘智能体的真正瓶颈，是“从原始信号到有语义的标签”这条路上，需要针对每辆具体车辆去积累的行驶数据和标注数据。这类活没有捷径，也没有云 API 能代劳，只能一辆车一辆车、一帧一帧地攒。这才是这类项目真正慢的地方——不是模型不够聪明，是没有足够多的人在真实的车上帮它跑出语义。
我的判断摆在这儿：它不是车联网生意，是系统层探针
把前面四拍的账算到这一步，判断已经浮出来了，收口段不再引入新数据，只把已经推到水面的东西钉死。
我的判断摆在这儿：CarWatch 的价值在系统层，不在车。它是一个用一辆真实车辆做底座的“本地智能体系统层探针”，证明了在 300 欧元量级的边缘设备上，35B 稀疏模型、本地 RAG、语音链路、OBD 集成、无云常驻服务可以作为一个整体跑通；但它同时也诚实得近乎冷酷地证明了一件事——这个品类的瓶颈从来不在模型层，而在管道层和分发层。管道层它一个人用 421 次提交趟了出来，分发层它根本没有碰，甚至没有假装要碰。所以它不是一门车联网生意，不能也不需要规模化；它是一个参照设计，会以“被抄走接口和架构”的方式扩散影响力。
这个判断有三个支点，各自都有证伪路径，写死在这。
第一个支点：边缘大模型已经不在“能不能跑”的阶段，而在“跑起来之后靠什么用”的阶段。CarWatch 的 35B MoE 在树莓派上 3.5 token/秒、5 秒级回答延迟、65°C 持续温度，这组数据把“能不能”这个问题从技术争论里拿走了；接下来的真正问题是 token 速度之外的那整套管道，也就是 RAG 的诚实边界、语音链路的脏活、常驻服务的可靠性、模型切换的安全性。证伪条件一：如果未来一年内，同类本地智能体项目普遍在“模型能力”层面出现显著分化——具体说，同样的系统层做得不行却因模型更大更快而显著领先——那说明这个品类的竞争力仍然主要在模型，而不是管道。在这之前，我不改口。
第二个支点：本地智能体的分发跨越极客圈，依赖的不是更好的模型，而是从安装到维护的整个交付闭环化。CarWatch 核心代码只用 Python 标准库、install.sh 配好 systemd 栈、仪表盘可视化模型切换，这些是向分发迈出的必要一步，但离“普通车主装了就忘”还差几十个这种步骤。证伪条件二：如果两年内有可核查的非开发者用户（不需要会写代码、不需要配 Linux 服务、不读 config.json）在真实车辆上跑通 CarWatch 或同等栈并实际使用，或者 Home Assistant 官方层面吸收了这个厂商中立数据层成为一个主流集成——这两件事发生任何一件，我改口说本地智能体的分发槛已经被越过。没发生之前，我认为这条路线仍停在极客圈。
第三个支点：CarWatch 用 AGPL-3.0 和“三个方法”的 cloudcar.py 接口，把自己卡在“厂商中立数据标准”的位置上，而不是做一个品牌专车助手。这个选择对行业有指向性：如果车作为智能体真的只需要三个品牌无关的方法就能接上，那车企做封闭式车机助手的个性化溢价就不成立。但这个位置本身没有生态引力，只有 286 星、18 fork、2 watcher 的数据摆在那里。证伪条件三：如果两年内其他品牌（哪怕一个）的适配器由第三方开发者独立实现并被合并、或者有车企/供应商直接引用这套接口做落地，那它就从“一个人的接口”变成了一个实际的标准起点。若一直只有奔驰一个适配器，我不认为它有资格被叫做标准，只承认是一个漂亮的架构方向。
最后收一句，不带任何升华。把这通拆写下来的唯一原因，是我觉得 CarWatch 是 2026 年九月份这个时间点上，少数能把“本地 AI”从一句口号还原成一本真账的样本——账里有模型速度、有蓝牙争用、有回音门、有三分钟加载、有标准库的执拗、有零订阅的硬气，也有星标数对提交数那种冷冰冰的反差。AI 圈把太多话讲在模型层，而它把账摊在系统层。在这本账被另一个项目用更低的成本、更好的分发推翻之前，我维持这个判断，不改口。