我 NAS 上跑媒体自动化那套东西（Sonarr 管剧集、Radarr 管电影、Seerr 管请求、Bazarr 管字幕），四个服务一套容器编排，加起来内存占用不算大，但每次想新加一个源、改一个规则就得进四个 Web UI 翻一遍。前几天在 GitHub 上刷到一个项目 Scryer，定位写得很简单粗暴——「Sonarr + Radarr + Seerr + Bazarr，外加几个其他 *arr 工具的零碎，全压进一个 Rust 二进制」。
这就是它装好之后的样子，主界面是 Web UI，所有功能在一个浏览器标签页里跑——电影海报墙、顶部搜索、左侧分类导航（Catalog / Series / Anime / Discover / Request / Calendar / Activity / Subtitles / Custom Rules / Post-Processing / Indexers / Download Clients），这是它跟传统 ARR 栈最直观的差别：
一个二进制代替一整套 ARR
Scryer 是 scryer-media 组织下的开源项目，Rust 写的单二进制 + 嵌入式 Web UI + GraphQL API + SQLite 状态库（也支持 Postgres）+ 插件化运行时（索引器/下载客户端/字幕源/通知都可插拔）。GitHub 上 225 stars、1,801 commits、v0.19.11（9/4 发布），GPL-3.0，单一作者主导。
README 一开头就写「Not affiliated with the Servarr tools」——意思是从零写、不 fork、不是把 *arr 几个项目的源码拼起来，是按它对媒体管理这件事的理解重新造了一遍。
我先以一个观察者身份在本地 Docker 起了一下，没替换我现在跑的栈。下面聊聊它跟传统 ARR 全家桶的几个差异点。
架构上它做对的一件事
看架构图就明白，Scryer 把传统 ARR 栈里散在四个进程里的功能集中成一个进程内的六个模块：
- Catalog & Monitoring — 库与监控（对应 Sonarr/Radarr 的核心）
- Discovery & Release Scoring — 发现 + 评分（这层 *arr 几乎没有原生提供）
- Acquisition Coordination — 下发到下载客户端
- Subtitles, Rules & Notifications — 字幕/规则/通知（对应 Bazarr + 部分规则引擎）
- Import, Rename & Organize — 导入、重命名、归类
- Users, Permissions & Library Access — 用户/权限/库访问（对应 Seerr 的请求流）
状态全部存一个 SQLite（README 提了也支持 Postgres），库本身还在 /media/Movies、/media/Series、/media/Anime 这种目录上——Scryer 不动媒体文件，它管的是 metadata 和配置。
这种「单进程 + 多模块」的好处是部署简单、内存稳定（没有四五个 .NET runtime 各起一遍）、状态一致（不用关心 Sonarr 数据库跟 Radarr 数据库之间出现的不一致）。代价也很明显：单点故障、模块边界模糊、对单一作者的依赖度拉满。
Anime 这块比 *arr 强
Scryer 文档里特别强调了对 Anime 的支持，这块我之前用 ARR 栈时踩过坑——Sonarr 对 Anime 的季度编号、集偏移、剧场版 vs OVA 区分很别扭，ANiDB/AL/MAL 多数据源也没有。
Scryer 把这些用多个 anime datasource（anidb、anilist、MAL）联合处理，能识别 anime season 编号、能处理 episode pack 和 multiseason pack、甚至能识别单集是不是 filler/canon（虽然我觉得这条对一般追番的人意义不大，但对追番严格的群体是加分项）。
剧集和电影部分跟 Sonarr/Radarr 该有的功能基本对得上：监控库、索引器搜源、按规则评分、下发给 BT/NZB 下载客户端、对接 Jellyfin/Plex/Emby 三个媒体服务器。
我的实际体验
我现在的 ARR 栈跑了一年多，几百部剧集订阅、Seerr 上家人提了几十条请求、各服务之间数据库是分开的（Sonarr 一个、Radarr 一个、Seerr 一个、Bazarr 一个）。所以没真在生产库上换，只在本地一台空 Docker 里跑了一遍 Scryer。具体感受几个点：
对接下载器还得照旧。Scryer 不下载东西，需要你配好 BT/NZB 下载客户端作为后端。我把我自己的索引器和下载器配置复制一份进去，能搜到资源、能下单到下载器、能回传完成状态。这部分逻辑跟 *arr 几乎一样。
迁移成本不算低。虽然 Scryer 是单一二进制、配置比 ARR 简单，但没有 import existing Sonarr/Radarr library 的工具——从 ARR 栈切过来，得手动重新订阅剧集/电影、重新跑监控、字幕规则也得重写一遍。225 stars 的项目，作者显然也没精力做迁移工具。
0.x 版本每周小碎步。从 v0.19.7 到 v0.19.11 五天里发了 5 个 release，节奏飞快。release notes 头部直接写「AI generated release notes」——意味着作者在用 AI 辅助迭代。这对早期项目是好消息（进展快），但也意味着破坏性变更可能随时来，要做好不随便升级的准备。
适合谁、谁等等再看
如果你是 NAS 上媒体栈刚开始搭建、还没在 ARR 上投很多沉没成本的人，Scryer 是一个值得认真看的方案。一个 Rust 二进制代替四五个服务，部署简单、内存省、状态一致。但前提是你能接受它还年轻（225 stars、0.x、单一作者、AI 辅助迭代）这一组信号。
如果你已经在 ARR 栈里跑了一年多、几百部剧集订阅、几千部电影、Seerr 上家人提了上百个请求——我不建议你为了「四个服务变一个」的简洁性现在就迁。迁移工具不成熟、新生态没经历过大版本验证，把稳跑的栈换成 225 stars 的项目，性价比不一定高。
我自己打算再观察两到三个月，看它 v0.19 → v0.20 → v1.0 的路线图怎么走。如果到了稳定主线、社区也跟上来，再考虑在新机器上试点。生产库不动。
项目地址：github.com/scryer-media/scryer，文档在 scryer.media。Docker 一行起：
docker run -d --name scryer -p 8080:8080
-v /path/config:/config -v /path/media:/media
ghcr.io/scryer-media/scryer:latest