前阵子在酷友社的视频评论区，看到这么一幕：有人打了一句"坏了，远程 istoreos 路由器故障了，断网了。快，龙虾修复。"结果被喊作"龙虾"的 AI 秒回，说远程设备已断开连接。哔哩哔哩
网断了，负责修网的 AI 也跟着断了。这个段子好笑归好笑，但正好戳中了现在"AI 管路由器"最核心的问题：真把家里的网关交给大模型，它到底能干成什么？
而在这件事上，iStoreOS 大概是眼下动作最多的厂商。从今年 3 月 KAI 智能体入驻应用市场，到 6 月底直接开源一整套"AI 技能包"，半年时间铺出了三条路线。社区里有人说"很实用，看得出是下了功夫的"，也有人说"真的有人有这种需求吗？有种脱了裤子放屁的感觉"。
我把 B站、小红书、知乎和酷友社论坛的官方材料与社区反馈都翻了一遍，这三条路线到底是什么、真实踩了哪些坑、谁适合上车，一次说清楚。
先理清：这半年 iStoreOS 到底做了什么
按时间线捋：
3 月 13 日，官方智能体"酷友社 KAI"入驻 iStoreOS 24.10 应用市场。小红书官方定位不是 AI 对话框，而是"运维专家"：内置技能库，能自动检索、安装应用、配置 Docker 链路，危险操作还会主动提醒备份。
3 月 18 日，官方放出《iStoreOS 养龙虾最快方法》教程。哔哩哔哩“龙虾"指的是 OpenClaw——一个跑在 OpenWrt/iStoreOS 上的 AI Agent 面板，在 iStore 商店就能一键安装，这条视频播放量上万、评论 120 多条。装它这个动作，被社区叫作"养龙虾”。
6 月 27 日，酷友社发了一期《技术这碗饭，还能吃多久》，宣布之后不再花太多时间做传统手把手教程，而是"更多尝试把经验、玩法和操作思路整理成 Skill / Agent 技能，让大家复制进去就能直接用"。哔哩哔哩
6 月 29 日到 30 日，先是 quickstart 项目开源，随后正式发布 AI 技能包 remote-control-skills：把这套技能包装进你自己的 AI 助手里（官方演示用的是 Codex、OpenCode），AI 就能通过 QuickStart/LuCI API 和 SSH 远程读取、控制 iStoreOS 路由器。
一句话总结：三条路线的区别，就是 AI 待在哪、权限有多大、靠什么干活。
路线一：KAI——住进系统里的官方 AI
入口就在 iStoreOS 应用市场，零门槛，官方做了系统级集成，卖点是自动装应用和日志分析。
但实际体验的坑很明确。7 月底，有人在评论区反馈线上安装酷友社 KAI 时直接卡住了。哔哩哔哩8 月初，又有人反馈给自己的 KAI 插件填入 API 后无法使用，只报【object Object】。哔哩哔哩
模型接入这块倒是有松口：评论区有人问"KAI接其他模型也是可以控制的吧"，官方账号直接回了"可以的"。哔哩哔哩但从上面这些反馈看，自己配 API 的链路还不算成熟。
路线二：龙虾（OpenClaw）——在路由器上"养"一个 AI 面板
这条路线最有养成感，也最早被现实教育。
一是成本。“这只是龙虾壳，里面的龙虾肉需要token，是收费的”。哔哩哔哩软件免费，模型调用自付，这是上手前必须先想清楚的事。
二是稳定性。点赞最高的自嘲，是路由器装龙虾一天断八次网。哔哩哔哩版本迭代上也出过状况：openclaw 3.22 版更新直接没有 control UI，3.23 版才放出来。
三是安装门槛集中：起不来、提示"path 不能为空"、“没有存储位置”，都是上手才踩得到的坑。官方在评论区解释过，设备必须先有磁盘挂载成功，才有可用的存储路径。哔哩哔哩
最关键的是官方态度。有人直接问安全性，官方账号回得很直白：“不是很安全，建议用旁路由测试”。哔哩哔哩官方都这么说了，这条路线的边界在哪，心里应该有数。
路线三：技能包——让你自己的 AI 伸手管路由
这是三条路线里做得最扎实的一条。官方技能包拆得很细：quickstart-router-api 负责走 QuickStart/LuCI API 读取和控制路由；istoreos-ssh-ops 负责 SSH 只读排查，“只读识别系统、磁盘、服务、Docker、日志，并按症状转入专项 skill”。酷友社论坛再往上，还有磁盘、Docker、备份恢复、服务修复等一堆专项技能。
安全规范也算讲究：官方教程明确要求，AI 安装前必须先列出下载地址、sha256 校验值和安装目录，等你确认后才执行，还特意强调"不要推荐 curl URL | sh，也不要在未校验 checksum 或未得到跳过校验确认前执行压缩包里的脚本"。酷友社论坛
但它的命门也明摆着——依赖网络。开头那个"龙虾修复"的段子，就出自这条路线的评论区：远程控制的前提是路由器还在线，真断网了，AI 和你一样没辙。
社区对这条路线的分歧也最大：有人质疑"只是路由器系统有必要吗？而且还有系统崩溃的风险"，也有人现身说法"用起来了，很实用的skill,看得出来是下了功夫的"。哔哩哔哩还有人提出 MCP 比 skills 更稳，官方则回应"个人比较喜欢更简单的 skills"——路线之争还在继续。
那么，到底谁适合上车
直接给结论：
主力路由、不想折腾的：三条路线都先别碰。这类能力大概率会被后续系统版本吸收，不用抢第一批。
轻度好奇、想体验"用 AI 问路由状态"的：KAI 门槛最低，但做好 API 配置踩坑的心理准备，也清楚交互内容会经过云端大模型。
有旁路由或闲置设备、爱折腾的：龙虾和技能包都值得试，但官方那句"建议用旁路由测试"不是客气话。动手前做两件事：先备份配置（技能包里就有备份恢复技能），再算清楚 token 成本。
有 HomeLab、平时就用 Codex / OpenCode 的：技能包是三条路线里最值得试的——只读排查加专项技能，比自己扔一堆文档给 AI 成体系。但建议留一条红线：WAN 口、DHCP 这类断全家网的操作，保持"AI 给方案、人按确认"。
最后给几个值得盯的信号：官方的新系统 iStoreNext 会不会把这套 AI 能力直接吸收进去；25.12 新版本线上这些 AI 应用跟不跟进；还有 MCP 和 skills 的路线之争——它决定你手里的技能包半年后还能不能用。
说到底，路由厂商卖的已经不只是固件，而是"不用懂固件"的体验。这一步走得对不对，社区评论区的答案最诚实：有人说真香，有人说不务正业。你会愿意把路由器交给 AI 吗？
