客厅如何爽看电影，来折腾NAS吧

最近重新折腾了一下家里的 NAS。起因非常简单：在客厅找一部电影看, 太费时间了，我需要先到次卧，用PC找到资源，存到网盘，然后再到客厅笔记本上打开网盘，投屏显示器。

我只是想在客厅里更方便地找电影、存电影，然后直接看电影。

客厅电视连接着一台闲置笔记本。电视作为显示器，笔记本上插一个无线鼠标，基本就能把鼠标当成简单的“遥控器”。理想中的操作路径很短：

坐在客厅
   ↓
搜索想看的电影 / 电视剧
   ↓
找到合适的网盘资源
   ↓
保存到自己的网盘
   ↓
打开网盘
   ↓
直接播放

相比拿手机搜索、复制链接、转存，再回到电视上操作，我更希望在这台连接电视的电脑上一次完成。最好是鼠标点几下，电影就已经躺在网盘里，接着直接播放。

那能不能在自己的 NAS 上部署一个常驻的影视资源搜索服务？

从这个小需求出发，我一路折腾了 QNAP 的 Linux 环境、Entware、Docker、Container Station、镜像加速、LLM Agent 和 PanSou。最后留下来的，却是最简单的一层。

QNAP 是一台不太标准的 Linux

我的 NAS 运行 QTS 5.2。通过 SSH 登录后，执行 uname -a 能看到大致环境：

Linux 5.10.60-qnap
x86_64
Intel Celeron N5105
QTS 5.2

从底层看，它当然是一台 Linux；但 QTS 不能完全按 Ubuntu 或 Debian 的方式管理。它没有 apt，系统目录和服务也由 QNAP 维护。直接修改 /usr、/etc 或系统启动流程，很容易和 QTS 升级、App Center、Container Station 打架。

考虑了一下，还是划了一条边界：

QTS
├── RAID / Storage Pool
├── Volume / Snapshot
├── SMB / NFS
└── QNAP 系统服务

Entware
├── git / vim / tmux
├── htop / jq / tree
└── 常用 Linux CLI 工具

Container Station / Docker
├── Mediary Scout
├── PanSou
└── 其他自建服务

也就是：QTS 管 NAS，Entware 管 Shell 工具，Docker Compose 管应用。 这条边界确定后，后面的事情顺了很多。

用 Entware 补齐命令行环境

QTS 自带的 Linux userspace 很精简。基本 SSH 操作当然够用，但一旦想把 NAS 当作 Linux Server 管理，很快就会怀念 git、vim、tmux、htop、jq、tree 和 rsync。

于是我安装了 Entware。它是面向 NAS、路由器等嵌入式 Linux 的额外软件包生态，主要在 /opt 维护自己的一套 userspace，并不试图把 QTS 变成 Ubuntu。

安装完成后，QNAP 的 /opt 会指向 Entware：

/opt -> /share/CACHEDEV1_DATA/.qpkg/Entware/

包管理器是 opkg，常用工具可以这样安装：

opkg update
opkg install git vim tmux htop jq tree rsync

opkg update 和 opkg install 会写入 /opt 下的系统目录，应以管理员权限执行；普通用户直接使用已安装的命令即可。对我来说，Entware 的定位只是补齐 SSH 环境，数据库和 Web 服务这类长期应用仍然交给 Docker。

把 QNAP 当成 Docker Host

QNAP 的 Container Station 已经提供了完整的 Docker 环境。我的机器上有 Docker Engine 27.x、containerd 1.7、runc 1.1 和 Docker Compose v2，所以部署服务仍然可以使用熟悉的命令：

docker compose up -d
docker compose ps
docker compose logs -f

我把自建应用统一放在类似这样的目录：

/share/Container/
└── stacks/
    ├── mediary-scout/
    ├── pansou/
    └── ...

这样 QNAP 的系统和我的应用基本分离。以后即使换 NAS，只要迁走 Compose 配置和数据，大部分应用也能继续运行。

一个 QNAP 特有的小坑：Docker 配置文件

在常规 Linux 上，Docker daemon 通常读取 /etc/docker/daemon.json。但 Container Station 并不是由普通的 systemd docker.service 启动。

通过下面的命令检查实际进程：

ps aux | grep '[d]ockerd'

我发现 dockerd 启动参数中指定了：

--config-file /share/CACHEDEV1_DATA/.qpkg/container-station/etc/docker.json

QNAP 还运行了两个 dockerd：普通 Docker 使用 /var/run/docker.sock，QNAP system docker 使用 /var/run/system-docker.sock。因此不能完全照搬 Ubuntu 上的 Docker 教程。

例如，国内拉取 Docker Hub 镜像较慢时，我给实际使用的 daemon 配置了 registry mirror：

{
  "registry-mirrors": [
    "https://docker.1ms.run"
  ]
}

之后仍然正常使用 docker pull postgres:17，不需要改写为镜像加速地址前缀；registry-mirrors 会透明地处理 Docker Hub 镜像。

第一版方案：Mediary Scout

NAS 环境准备好后，我最先部署的是 Mediary Scout。它很接近我最初想要的体验：

输入影视名称
    ↓
Agent 搜索资源
    ↓
判断哪个资源更合适
    ↓
自动转存到网盘
    ↓
回读验证
    ↓
完成

它可以通过 PanSou / Prowlarr 搜索资源，再由 Agent 根据画质、字幕、已有内容等信息选择并转存。产品体验上，它比单纯的搜索工具多走了一步：我只负责说想看什么，剩下的交给 Agent。

这个界面刚打开时相当有感觉：热门影片排得整整齐齐，输入片名之后，它会自己去搜索、判断、转存和验证。对“我只想看片，不想研究资源”的场景来说，确实很有吸引力。

于是我把 Mediary Scout 部署到 QNAP，并开通了 DeepSeek API。

两次尝试，58 万 Tokens

随后发生了一件很有意思的事。我只测试了两次资源获取，打开 DeepSeek 后台时，整个人都有点儿沉默了：

API 请求次数：33
Tokens：585,195
消费金额：约 ¥0.23

倒不是说 ¥0.23 有多贵。问题是，我原本只是想找两部片子，没想到背后已经跑了 33 次 API 调用、吞掉了接近 60 万 token。按照这次测试做很粗略的线性估算：

2 次搜索 ≈ ¥0.23
100 次 ≈ ¥11.5
500 次 ≈ ¥57.5
1000 次 ≈ ¥115

实际成本会受缓存命中、搜索复杂度和 Agent 重试等影响，这个估算不代表固定价格。但它让我开始思考一个更根本的问题：我真的需要一个 LLM Agent 来完成这件事吗？

Mediary Scout 并非只调用一次模型。一次任务可能经历搜索、分析结果、工具调用、转存、验证等多轮 LLM 调用；两次实际操作最终就产生了 33 次 API 请求。

这类 Agent workflow 对复杂任务很有价值。但我的实际需求是：

搜索电影
 ↓
看一眼结果
 ↓
挑一个
 ↓
存网盘

“挑哪个资源”这一步，我花几秒就能完成。为了省下这几秒，让 Agent 在后台跑十几轮模型调用，对这个使用频率而言有些本末倒置。

同样的钱，我更愿意攒着给网盘扩容。对客厅观影来说，更大的容量、更多已经存好的片子，带来的幸福感明显更直接；至于“帮我从十条结果里挑一条”，目前还是我自己来得又快又便宜。

最终方案：直接部署 PanSou

继续看 Mediary Scout 的架构后，我发现其资源搜索后端本身就使用了 PanSou。PanSou 是网盘资源搜索 API 服务，支持 Telegram 搜索、自定义插件、并发搜索、结果排序和缓存。

原来的链路是：

Mediary Scout UI → LLM Agent → PanSou → 搜索结果 → LLM Agent → 网盘

而我真正需要的，其实只是：

PanSou Web → 搜索结果 → 我自己选 → 保存网盘

PanSou 官方提供了前后端集成的 Docker 镜像，并推荐 Docker Compose 部署。在 QNAP 上建立目录后：

mkdir -p /share/Container/stacks/pansou
cd /share/Container/stacks/pansou

curl -o docker-compose.yml \
  https://raw.githubusercontent.com/fish2018/pansou-web/refs/heads/main/docker-compose.yml

docker compose up -d
docker compose ps
docker compose logs -f

这样 NAS 上就常驻了一个自己的影视资源搜索页面。需要找片时，只要在客厅电视连接的旧笔记本上打开 PanSou，搜索、选择资源、保存到网盘，然后在网盘中播放即可。

我喜欢它的地方是朴素：搜“蜘蛛侠”，几秒钟就能看到结果、来源和网盘类型。它不替我做最后的判断，但把最费事的“到处翻”和“来回切应用”收拢到一个页面里；剩下那一下点击，我自己完成就好。

最后留下来的架构

折腾一圈后，家里的结构反而很简单：

                         Home Network
                              │
             ┌────────────────┴────────────────┐
             │                                 │
          QNAP NAS                         客厅电视
             │                                 │
        QTS / Storage                       旧笔记本
             │                                 │
      Container Station                    无线鼠标
             │                                 │
          Docker                             Browser
             │                                 │
          PanSou  ◀────────────────────────────┘
             │
             ▼
       搜索影视资源 → 网盘链接 → 手动保存 → 网盘播放

NAS 负责让搜索服务 24 小时在线；旧笔记本负责 UI；无线鼠标充当遥控器；网盘负责存储和播放；PanSou 只负责它最擅长的事：搜索。

自动化不是越多越好

这次原本只是想解决“怎么在客厅方便找电影”，结果一路经过了：

QNAP / QTS → SSH → Entware / opkg → Container Station
→ Docker / Compose → 镜像加速 → Mediary Scout
→ DeepSeek API → LLM Agent token cost → PanSou

但最终留下来的方案，反而比最开始简单。这让我重新意识到一个朴素的工程原则：自动化不是越多越好。

如果一个步骤机器做起来很昂贵，而人只需要几秒钟就能判断，保留一点人工操作未必是坏事。Mediary Scout 的 Agent 化方案很有意思，也让我实际体验了 LLM Agent 在真实应用里的工作方式和 token 消耗；但对这个具体的家庭场景，PanSou 加手动转存的平衡更好：搜索足够快，NAS 24 小时在线，没有持续的 LLM API 成本，操作路径很短，而且整套服务都掌握在自己手里。

最后，原本闲置的 NAS、旧笔记本和无线鼠标，也终于拼成了一套顺手的“客厅影视搜索终端”。

接下来还想继续折腾什么

这套方案现在已经能用，但离“像电视应用一样顺手”还有一点距离。接下来我想慢慢补两块：

• 让客厅操作再少一点。 给旧笔记本设置开机自动进入浏览器和 PanSou 页面，再配一个更适合客厅的无线键盘或带触控板的遥控器。这样就不用每次先找窗口、输网址，真正做到坐下就能搜。
• 让 NAS 里的片库慢慢长出来。 现在网盘更像临时播放入口。以后想把经常重看的电影、剧集和纪录片逐步整理进 NAS，按类型、年代和观看状态归档；有余力再接一个本地媒体库和播放器，让“已经收藏的内容”也能像流媒体首页一样浏览。

参考资料

• Entware Wiki：嵌入式 Linux 环境下的 opkg 软件包生态与安装说明。
• QNAP Container Station：QNAP 的容器管理应用。
• Docker Compose documentation：Compose 配置与命令参考。
• Mediary Scout：本文最初尝试的多网盘媒体 Agent。
• PanSou：网盘资源搜索服务。
• PanSou Web：PanSou 的 Web 前端与 Docker Compose 部署配置。