如何优雅地让 AI 助手管理飞牛 NAS,同时保证系统绝对安全不失联?

出门在外查飞牛 NAS，还在手敲 SSH 敲到手抽筋？想让 AI 助手代劳又怕泄露 root 密码删盘？飞牛官方 Skills 现已支持自然语言安全接管。本文交付一套‘监控+官方CLI+MCP+SSH’四层远控架构，附外网独立备用通道搭设，及双授权不互踢的一行解法。

一句话让 AI 汇总飞牛存储池、Docker 容器与下载进度。

而且全程不需要给 AI 你的 NAS 账号密码。

如果你也在玩飞牛 fnOS，日常管理大概率绕不开两个极端：要么掏出手机登录网页端等半天，要么在终端里手敲 df -h、docker ps 敲到头疼。

好不容易有了 AI Agent（飞书机器人、Claude、本地大模型），想让它帮我们打理 NAS，但把 root 密码和底层 SSH 权限直接交给它？万一哪天模型出现幻觉执行了高危指令，谁也承受不起删库的代价。

飞牛官方推出的 Skills 工具包（trim-cli），给出了更现代的解法：用官方受控 API 替代无底线敲终端，无需向 AI 泄露任何密码，就能用自然语言随时查询 NAS 的一切业务状态。

但当你真打算把这套能力搬进日常生产、为了防断网给它搭一条公网备用通道时，一个极其恶心的暗坑就会浮出水面：明明配置了两个独立的 profile，备用通道刚授权成功，主入口立刻报错 invalid refresh token，两边互相顶号踢下线。

这篇文章不讲空洞理论，用真实实测交付三件事：

怎么把远控拆成四层：监控看水位、官方 CLI 查业务、MCP 补定制、SSH 压箱底当维修间；

怎么搭一条独立的备用隧道：主路故障时无感切换，且完全不向公网暴露 NAS 控制端口；

双授权不互踢的关键解法：挖出官方客户端共用设备身份的底层机制，用一行环境变量彻底搞定双向保活。

一、扔掉万能锤子：为什么极客 NAS 必须做四层远控？

以前，遇到“看一下飞牛状态”，很容易直接打开 SSH。

SSH 能干的事确实多。但“能执行任何命令”和“适合每次都用”，不是一回事。

现在我保留四层能力，各自回答不同的问题。

监控层：Komari。 看在线状态、CPU、内存、磁盘水位、负载和趋势。它负责发现异常，不负责替你修机器。遥测有时间戳，过期数据不能当成现在。

业务层：飞牛官方 Skills / trim-cli。 看应用、存储池、文件目录、相册扫描范围、原生下载列表、容器和系统日志。先用飞牛自身的接口，不用 AI 每次拼一串终端命令。

补位层：MCP。 MCP 是让 AI 调用工具的接口规范，不是网络。既有的定制系统工具、专用应用接口继续保留；官方能力重叠时，优先官方。没有必要把同一状态同时查三遍。

救援层：SSH。 应用托管故障、数据库问题、文件系统问题、服务起不来，这些仍然需要底层控制。官方接口失灵时，SSH 才体现价值。

     新分工不是“淘汰 SSH”，而是让 SSH 从日常接待员回到维修间。   

这里还有一个容易混淆的点：工具能力和网络入口是两条独立轴线。

官方 CLI 可以走局域网、已授权的专网，或者独立备用通道。它并不要求你必须使用某一种网络产品。

监控可用也不等于业务可用；网络可达也不等于授权有效。

二、先确认你需要哪些层，别一口气全装

这次实际环境是 fnOS 1.2.0800，官方 Skills 包 0.1.1，应用中心的 Frpc 客户端 0.71.0。中转端既有 frps 为 0.61.2。

这是本次跑通的组合，不是建议所有人照着锁旧版本。新装时按官方版本选择，再验证兼容性。

准备三个对象：

一台已经正常运行的飞牛，管理员可进入桌面。

一台控制电脑或自己的服务器，用来运行官方 CLI。

如果需要独立备用路，再准备一台你有管理权的公网中转服务器。

只在家里使用的人，配置官方 CLI 就能获得主要收益。 如果你没有长期维护中转服务器的意愿，不必为“两条路”增加账单和故障点。

所有命令中的 NAS_HOST、NAS_PORT、relay.example.com、用户与密钥都要换成你自己的值。它们是示例变量，不是可以登录的公共服务。

三、把官方 Skills 接上飞牛

1. 从官网取包，不抄过期下载直链

进入飞牛官网下载页，找到“飞牛 Skills”，下载、解压，并按下载页提供的 SHA256 校验。

官方入口：   https://fnnas.com/download

安装与授权说明：   https://help.fnnas.com/articles/v1/settings/authorize

我曾经直接请求包的裸链接，得到 403；走官网正常下载流程后成功。下载签名和 NAS 授权是两回事，不要看到 403 就反复改 NAS 密码。

以 Linux 控制端为例，把解压得到的整个 fnos 目录放到用户目录。不要只搬一个二进制，包装脚本和参考文件也要保留。

mkdir -p "$HOME/fnos-tools"# 把解压后的 fnos 目录放进 fnos-toolschmod u+x "$HOME/fnos-tools/fnos/scripts/trim-cli"chmod u+x "$HOME/fnos-tools/fnos/bin/trim-cli-linux-x64"export CLI="$HOME/fnos-tools/fnos/scripts/trim-cli""$CLI" --help

上例针对 x64 Linux。ARM64、Windows、macOS 使用包内对应入口，不要执行错误架构的文件。

把包内 SKILL.md 和 reference 留给你的 AI 助手读取。不同 Agent 的技能安装目录不同，按各自说明导入；控制端终端可以直接运行 CLI，不依赖某个特定 Agent。

2. 完成本人授权，不把密码交给 AI

在飞牛桌面确认系统版本不低于本次验证基线。记下浏览器中实际使用的主机地址、端口和协议。

下面以你已配置 HTTPS 的入口为例：

export NAS_HOST='nas.example.com'export NAS_PORT='443'"$CLI" --profile home \  --host "$NAS_HOST" --port "$NAS_PORT" \  --scheme https login --no-open

CLI 会打印授权链接。本人打开链接，登录飞牛、确认权限，把一次性授权码粘回正在等待的终端。

不要把授权码写进命令参数，不要贴进群聊，不要让 AI 代填密码。 官方包说明中，授权码有效期为五分钟，而且只能交换一次。需要扩展权限时重新授权，刷新不会扩大权限范围。

若你自己的 NAS 只使用 HTTP，协议必须与实际入口一致；若使用自签 HTTPS，客户端可能报证书验证失败。本次自签入口用了 --tls-insecure，它关闭证书校验，不等于严格验证了服务身份。更推荐配置可信证书；在理解这一边界前，不把该参数加成默认习惯。

3. 用只读业务确认接线成功

"$CLI" --profile home system trim-version"$CLI" --profile home system info"$CLI" --profile home app list"$CLI" --profile home storage pools"$CLI" --profile home download ls"$CLI" --profile home photos folders"$CLI" --profile home docker container ls

查看目录用 file ls-dir，相册目录用 photos folders。不要看见“文件模块”就凭印象编一个命令，具体子命令先查 --help。

本次还验证了 CPU、内存、当前账号、近期日志和飞牛百度网盘的授权状态。这些查询通过，不代表上传、改名、安装应用或下载控制也已通过。

四、监控和 MCP 怎么接，不把教程写成盲目换系统

Komari 的安装以项目文档为准：   https://github.com/komari-monitor/komari

你已经有面板的话，在面板新增飞牛节点，使用该实例生成的 Agent 安装说明；节点凭据只留在自己的系统中。没有面板的读者先按官方文档部署，不复制别人实例的安装串。

本次没有重装 Komari，验证的是已有节点遥测与官方业务接口组合后的日报路线。

我采用的判断是：指标必须在线，且更新时间不超过五分钟。 这是自己的巡检阈值，不是 Komari 官方强制规则。

状态报告应同时注明来源。例如正常时写“Komari + 官方接口”；官方异常、SSH 补齐时写明“降级”，保留原始报错。不要用一个绿色“在线”盖住所有故障。

MCP 也按同样原则处理：

步骤一：已有万能 MCP 服务的，保留原配置与定制插件，不为了接官方 Skills 重装。

步骤二：尚未安装的，在飞牛应用中心搜索“万能MCP服务”，按当前应用说明完成安装和鉴权。

步骤三：AI 客户端添加当前应用提供的 MCP 地址，在受信网络内列出工具，再执行只读查询。

步骤四：官方有完整等价能力时优先官方，官方缺失的专用能力再使用 MCP。

这次日报实际接线是 Komari + 官方 CLI，失败才 SSH 兜底，尚没有 MCP 中间降级。 专项 MCP 巡检仍独立存在。设计上的优先级，不能写成所有脚本已经实现的功能。

五、给官方接口增加一条独立备用路

这部分适合已有公网中转和远程维护需求的人。

结构很简单：飞牛应用中心的 Frpc 客户端连接你的中转服务器，控制端也运行 frpc 的访问端。只有持有同一共享密钥的访问端，才能取得本地入口。

控制端入口只监听回环地址，不把飞牛管理页面直接开放到公网。 STCP 的官方示例：   https://gofrp.org/en/docs/examples/stcp/

1. 准备中转端

已经有 frps 就复用。新建时，从官方 release 下载与你服务器架构匹配的 frps：   https://github.com/fatedier/frp/releases

按当前官方说明安装。最小服务端示例是：

bindPort = 7000

让自己的防火墙或云安全组允许所需客户端访问这个控制端口，运行并托管 frps。上面的最小配置没有全局令牌认证；公网部署应按当前官方认证说明补齐，并在两个客户端配置一致的认证项。不要用演示最小文件替换你已有服务端配置。

安装说明与配置参考：   https://gofrp.org/en/docs/setup/

本次复用既有服务端，没有为这条业务路修改全局参数或重启它。

2. 飞牛端复用应用中心 Frpc 客户端

打开应用中心，搜索并安装“Frpc客户端”。它是应用中心提供的第三方应用，不是飞牛官方 CLI 本体。

在应用提供的管理界面新建独立实例，例如 nas-api。本次应用具有多实例管理；不同应用版本界面可能变化，以当前界面为准。

不要覆盖已经运行的旧实例。先备份旧配置，再填入新配置。

飞牛端配置示例

serverAddr = "relay.example.com"serverPort = 7000transport.tls.enable = true[[proxies]]name = "nas-api"type = "stcp"secretKey = "<shared-secret>"localIP = "127.0.0.1"localPort = 443

localPort 必须改成飞牛在 NAS 本机实际监听的 HTTPS 端口，443只是示例，不能把外部浏览器入口的映射端口不加区分地填进去。

共享密钥可在自己的终端运行 openssl rand -hex 32 生成。它要在两端一致，不发到聊天、不进公开仓库。已有 frps 认证设置的，追加其要求的认证字段。

启用新实例后，从应用界面查看连接日志与状态。本次看到的是登录成功、业务通道启动成功，应用中心状态为 running，应用自身健康检查也返回成功。

3. 控制端建立回环入口

在控制端安装与飞牛客户端版本兼容的 frpc。下面保存成 visitor.toml：

控制端访问配置示例

serverAddr = "relay.example.com"serverPort = 7000transport.tls.enable = true[[visitors]]name = "nas-api-visitor"type = "stcp"serverName = "nas-api"secretKey = "<shared-secret>"bindAddr = "127.0.0.1"bindPort = 8080

这里的8080是教学示例端口，不是本次实例端口。先确认没被占用。

chmod 600 visitor.tomlfrpc verify -c visitor.tomlfrpc -c visitor.toml

在另一个终端检查：

ss -lnt | grep ':8080'curl -I https://127.0.0.1:8080/

监听必须是回环地址。自签证书时 curl 可能拒绝，不能把证书失败当成网络不通；临时诊断可在了解风险后使用 curl 的证书忽略选项。

正式使用时再按控制端系统的服务管理方式托管这个访问进程。飞牛端仍交给应用中心，不额外造一个抢进程的 NAS 服务。

     两条独立路径，只独立于原来的网络入口。它们仍共用同一台 NAS、家庭供电和宽带，不是全面灾备。   

六、最关键的坑：两个 profile 不等于两个设备

我最初用两个 profile 保存两份授权。

备用授权后，主通道报：

access token rejectedrefresh failed: invalid refresh token

检查配置发现：profile 会话各自保存，但设备身份文件放在配置根目录。两个 profile 共用同一身份。

后来验证到官方客户端支持 TRIM_CLI_CONFIG_DIR。备用设置独立目录后，生成了不同的设备身份。

这是本次排雷最值得抄的一行。

下面在控制端另开终端，使用独立目录授权备用入口：

export TRIM_CLI_CONFIG_DIR="$HOME/.config/fnos-backup""$CLI" --profile backup \  --host 127.0.0.1 --port 8080 \  --scheme https login --no-open

自签证书的处理与前文相同。CLI 的授权 URL 开头是回环地址，浏览器如果不在控制端本机，就不能直接打开。

在家庭局域网浏览器授权时，把链接开头的协议、主机、端口改成你实际可访问的飞牛地址，后面的 /signin?... 参数完整保留。授权码仍粘回等待中的 CLI。本次已按这个方式完成授权。

如果人不在家、也没有可进入飞牛授权页面的受信入口，就先解决本人登录路径，不把管理页面临时敞开公网。

主通道继续用默认配置目录；备用每次调用都注入独立目录。别登录时分开了，查询时又回到默认目录。

unset TRIM_CLI_CONFIG_DIR"$CLI" --profile home system trim-versionTRIM_CLI_CONFIG_DIR="$HOME/.config/fnos-backup" \  "$CLI" --profile backup system trim-version

本次修复效果支持“身份共用是故障原因”的判断，但没有服务端日志证明具体会话互替机制。更准确的结论是：独立目录这条解法，在本次客户端和系统组合中通过了验收。

七、效果不是口号，给你看验收结果

这次测试日期是2026年10月14日。

双授权共存：

主通道查询：成功，1.2.0800备用查询：成功，1.2.0800主授权刷新：成功备用授权刷新：成功主通道再次查询：成功，1.2.0800备用再次查询：成功，1.2.0800

业务快照：官方接口返回28个应用；另一次容器查询返回19个容器，返回的19个均为 running。存储池查询成功，相册扫描目录和下载列表查询成功。

不能把“返回19个”说成“枚举所有停止和运行容器”；不能把“28个应用”当成任何读者都应出现的数量。这只是我的取样结果。

容灾效果：在测试中让主连接返回 connection refused，备用仍请求真实 NAS，返回28个应用。

这是“故障注入 + 真实备用查询”，不是我真的断掉主网络。物理断网、长期并发刷新、机器重启后的存活和完整回滚，本次没有演练。

日报效果：正常路径显示“Komari + 官方接口”，在禁止建立 SSH 的测试钩子下通过。五项路由回归覆盖正常、遥测过期、业务失败、全失败和部分可用，全部通过。

独立配置完成后的两边版本查询，在文章写作前再次读取成功。

还留了一条明确规则：仅网络故障才自动切备用，而且只允许验收过的只读查询。

如果报错是授权失效、权限不足或业务失败，原样提示。文件改名、删除、安装应用等写操作不跨通道盲目重试，因为“请求超时”不证明第一次没执行。

八、这套方案能做什么，不能做什么

现在可以用一句话让 AI 汇总飞牛资源水位、查看应用状态、读取存储池容量、列出下载任务和相册索引范围。

但我不会把官方包列出的命令全部标成“已经实现”。

AI相册搜索就是反例：就绪接口HTTP200，业务码却是 20701，消息是 model not found。HTTP200不是业务成功。 没有安装或验证模型前，不能承诺自然语言搜图可用。

文件上传、分享、改名、应用安装与启停、下载控制，属于后续具体任务逐项验证的能力。影视管理也不能因为“都是飞牛”就并入官方 Skills。

我建议这样选：

只想让AI查看飞牛业务，先做官方CLI授权。

已有多台主机要看趋势，再复用监控面板。

有专用工具和插件，再保留MCP。

确实需要在主网络入口失效时继续维护，才增加独立备用路。

底层救援需求存在，就保留经过认证的SSH入口，不为了“全自动”删掉退路。

回退前保留旧配置和日报脚本备份；新通道单独命名，出问题时单独停用新实例、恢复相关路由，不覆盖旧实例，不撤销所有授权。这是恢复办法，不是已经演练成功的恢复承诺。

真正值得保留的，不是四种工具的名字。

是你问“飞牛怎么了”时，系统知道该看哪一层；哪一层失败，就把哪一层的事实说清楚，而不是假装所有东西都还在线。

     「每天帮你踩一个 AI 的坑，省下一小时。」   

你现在的飞牛远控，卡在网络还是授权？