今年上半年，iStoreOS 社区被三个和 AI 有关的东西撕成了两半。一边是官方密集上新：3 月上线 KAI 智能体，3 月推出 OpenClaw"龙虾"插件，6 月底又开源了 remote-control-skills AI 技能包。另一边是评论区持续泼冷水，高赞的有"大哥别瞎搞了，赶紧完善istoreos吧"。最戏剧性的一幕出现在 AI 技能包视频下面：有人的远程 iStoreOS 路由器出了故障、断了网，急着喊路由器里养的"龙虾"来修，得到的回复只有一句：龙虾，抱歉，远程设备已断开连接。哔哩哔哩 AI 要修路由器，路由器断网却让 AI 先失效，这套东西到底该装、该等还是该别碰，今天一次说清。
一、先搞清楚这三件东西分别是什么
KAI 是酷友社在 iStoreOS 软件中心上架的智能体插件，官方介绍是你可以用 AI 来自动下载，安装软件，备份系统，自动修复路由器的问题。哔哩哔哩 模型需要用户自带 API key，评论区问怎么设置模型，得到的答复是"填自己的，那里不是免费的，得自己找账号"。
OpenClaw 就是网友说的"龙虾"，本质是运行在 OpenWRT/iStoreOS 上的 AI Agent 管理面板（LuCI 插件），可对接 OpenAI、Claude、Qwen、OpenRouter 等大模型接口，教程里特意提醒：建议开启：文件读写、网络访问、定时任务。注意：Shell执行请慎用。知乎 它的部署门槛并不低：只支持 x86_64 与 aarch64 架构、musl 环境，存储要 1.5GB 以上，内存推荐 1GB 起，通过 .run 或 .ipk 安装，系统要求见下图。
第三件 remote-control-skills 和前两者不同：它不装在路由器上，而是装在你电脑上 Codex、OpenCode 这类 AI agent 里，其中 istoreos-ssh-ops 是 SSH 入口 skill，只读识别系统、磁盘、服务、Docker、日志，并按症状转入专项 skill。酷友社 一句话总结：KAI 是"住在路由器里管路由器的 AI"，龙虾是"24 小时常驻在路由器上的 AI agent"，技能包则是"把路由器的遥控器交给电脑上的 AI"。
二、为什么路由厂商突然集体押注 AI
这不是酷友社一家的动作。今年 5 月开始，国内同行几乎同步转向：爱快随 OS v4.0 开放了 CLI 终端命令行工具，官宣可以通过 AI Agent 玩转爱快软路由。哔哩哔哩 铁威马的新 TOS7 系统则直接提出"把NAS交给AI管理"。
畅网微控这样的小团队也花了一年多，做出"完全按AI时代的理念从头设计的AI原生NAS系统"。哔哩哔哩 逻辑不难理解：路由器和 NAS 是家里 24 小时开机、功率低、接在全网上的设备，天然能管到每一台终端。有知乎作者总结，把 OpenClaw 部署进路由器后，“路由器不再只是’上网设备’，而是’家庭AI调度中心’”。知乎 迷你小主机这类设备，也就成了 AI agent 天然的容身之处。
但也正因为它是全网枢纽，一旦玩崩，全家断网。这是对路由器上的 AI 必须比对手机上的 AI 更谨慎的根本原因。
三、翻车清单，装之前先看
KAI 的官方宣传帖里写着：群友真实反馈，99.99%的问题都能解决！酷友社 但看近半年社区的真实反馈，坑集中在四类。
一是版本不稳。KAI 官方视频下的高赞评论直接说：上上个版本不能用，上个版本可以用，这个版本又不能用了。哔哩哔哩 报错最多的是 The KAI service is not running，官方回复多为检查磁盘空间、挂载磁盘或重启；虚拟机上常见的"path 不能为空"，解法是给虚拟的 iStoreOS 分配 10G 以上磁盘并挂载。
二是持续成本。龙虾插件本身免费，安装教程下的高赞评论说得很直白：“这只是龙虾壳，里面的龙虾肉需要token，是收费的”。哔哩哔哩 每一次巡检、修复、定时任务都在消耗 token，自带 key 的用户需要自己算这笔账。
三是安全与稳定。评论区有人问安全性如何，得到的答复是"不是很安全，建议用旁路由测试"。哔哩哔哩 也有用户吐槽"路由器装龙虾，一天断八次网"，OpenClaw 3.22 版还出现过控制界面整个消失的问题，到 3.23 版才修复。
四是开头那个悖论：AI 修复依赖网络在线。路由器断网时，远端 AI 够不着，本机 AI 可能已经随服务一起挂掉，作为修复手段存在先天盲区。
四、三类人，三种建议
有闲置机器、想折腾的人，可以装。这套东西对硬件要求不高，像下图这台闲置的 N5095 迷你主机，4GB 内存、32GB 存储就足够跑起来，玩坏了也不影响全家上网，当成大号玩具正合适。
主路由在用的人，建议等。官方技能包教程自己都要求：安装前 AI 必须先说明下载 URL、期望 sha256、解压目录等信息并等待确认，还明确不要在未校验 checksum 前执行压缩包里的脚本。连官方都认为这件事需要格外谨慎，主路由承载全家的网，没必要拿它给早期功能当试验田。
期待"一键全自动、从此不用操心"的人，先别碰。KAI 不保证每个报错都能修，龙虾跑任务要花 token，技能包面向的也是会用 AI agent 的用户。只想稳定上网的话，先把 SmartDNS、SQM 流控、Docker 这些 iStoreOS 基本功用熟，比追 AI 实在得多。
五、值得继续盯的三个信号
一是官方 quickstart 仓库的 README 里直接写明：QuickStart is under active refactoring and is not stable yet，即项目仍在重构、尚不稳定。GitHub 底座本身还在重构，AI 功能的形态远未定型。二是 KAI 高频报错的修复进度，8 月初仍有用户反馈"KAI插件填入自己的api后无法使用不知道是什么原因？报【object Object】"且未解决。哔哩哔哩 这类报错清零后才值得重新评估。三是 iStoreOS Next 从 3 月起一直处于"争取扩大内测"状态，下一代系统公测后与 AI 的结合方式，大概率决定这波 AI 功能的最终形态。
一句话收尾：这套 AI 三件套值得看、值得在闲机上玩，但主路由先别急着交给 AI。毕竟路由器断网的时候，AI 也救不了它。
