SuggestArr：把观看记录变成 Seer 请求的自动化工具
Effortlessly request recommended movies, TV shows and anime to Jellyseer/Overseer based on your recently watched content on Jellyfin, Plex or Emby—let SuggestArr handle it all automatically, keeping your library fresh with new and exciting content!
秒懂
- 它是什么？
- SuggestArr 读取 Jellyfin、Plex、Emby 的最近观看记录，用 TMDb 相似推荐或 OpenAI 兼容的 LLM 生成候选，再把请求推给 Seer。本文说明它的数据流、Docker 部署方式、审批与清理机制，以及哪些场景下它并不合适。
- 适合谁用？
- 如果你已经跑着 Jellyfin、Plex 或 Emby，并且用 Seer 管理请求，同时希望请求队列能自己长出来而不是靠人手动填，SuggestArr 的定位正好对得上：它把最近观看记录当作种子，用 TMDb 或 LLM 生成候选，再交给 Seer。反过来，如果你的 Seer 请求队列本来就积压，或者你无法接受自动化脚本替你决定要下载什么，那么先别开自动发送，把 Advanced 里的 Approve requests before sending them to Seer 打开，让结果停在 Requests 页面人工过一遍。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是请求队列没人填的问题
自建媒体服务器的常见状态是：库建好了，Seer 也装好了，但请求列表长期空着。原因不是用户不想看新内容，而是从「我刚看完这部」到「我去 Seer 里搜一部类似的」之间隔了好几步操作。SuggestArr 把这几步压成一条后台任务：读取媒体服务器上的最近观看记录，据此找出相似标题，再自动向 Seer 发起请求。
目标用户很明确，是同时运行媒体服务器和 Seer 的自托管用户，尤其是给家庭成员或小圈子共享账号的管理员。README 里提到的用户选择功能允许指定哪些用户参与触发请求，并且可以按媒体服务器账号过滤请求可见性，管理员还能把普通用户限制为只能看到与自己 Plex、Jellyfin 或 Emby 账号绑定的请求。这说明它考虑的是多人共用一套 Seer 的场景，而不是单人自用。
需要说清楚的是，它不负责下载，也不负责媒体库刮削。它只做一件事：把观看行为翻译成 Seer 能接受的请求。
数据流：观看记录到 TMDb 再到 Seer
README 描述的主链路有三段。第一段是采集，从 Jellyfin、Plex 或 Emby 拉取最近观看内容。第二段是扩展，把这些标题作为种子提交给 TMDb API，搜索相似的电影和剧集。第三段是投递，把结果作为下载请求发送给 Seer。整个流程由 cron 调度驱动，调度表达式可以在 Web 界面里直接改，不需要进容器改文件。
v2.14.0 的发布说明里提到，新任务会遵循 Advanced 下的全局设置 Approve requests before sending them to Seer，该选项默认关闭。每个任务可以继承这个设置，也可以单独覆盖为始终批准或始终自动发送。被拦下的结果会出现在 Requests 页面，任务所有者或管理员可以在那里发送到 Seer、拒绝，或者加入全局黑名单。这个设计把「自动」拆成了两级：候选生成是自动的，投递是否自动由策略决定。
除了 TMDb 这条默认路径，项目还提供了两个 beta 功能。AI-Powered Recommendations 使用任意 OpenAI 兼容的 LLM（README 列举了 OpenAI、Ollama、Gemini、LiteLLM）基于观看历史生成推荐，并为每个推荐附上理由。AI Search 则允许用自然语言描述想看什么，由模型结合观看历史找出匹配标题，并支持一键请求到 Seer。Trakt 集成是另一条独立的数据源：每个用户可以在自己的资料页绑定 Trakt 账号，最近观看可以充当推荐种子，已完整观看的条目会进入跳过集合。管理员只需要配置共享的 Trakt 应用凭据。
用 Docker Compose 跑起来
README 给出的部署方式是 Docker Compose，镜像同时发布在 Docker Hub 的 ciuse99/suggestarr 和 GitHub Container Registry 的 ghcr.io/giuseppe99barchetta/suggestarr。Compose 文件里服务名是 suggestarr，容器名是 SuggestArr，restart 策略为 always，端口映射使用 SUGGESTARR_PORT 环境变量，默认 5000。卷挂载只有一处：./config_files 映射到容器内的 /app/config/config_files。
环境变量有两个。LOG_LEVEL 默认 info，README 注明只有在出问题需要深入排查时才需要调整。SUGGESTARR_PORT 用于改端口，不设置时回落到 5000。启动命令是 docker-compose up。容器起来后访问 http://localhost:5000，或者访问你自定义的端口。
配置主要发生在 Web 界面里，包括选择媒体服务、填写 API 凭据、管理 cron 调度。README 提到配置阶段会自动校验 API key 和 URL，也就是 Configuration Pre-testing 这个特性。前置条件列了四项：Python 3.x 或 Docker、TMDb API Key、已配置好的 Jellyfin/Plex/Emby、已配置好的 Seer。外部数据库是可选项，支持 PostgreSQL 和 MySQL，默认使用 SQLite。
如果要使用特定 Seer 用户发起请求，需要在界面里勾选用户选择选项，从下拉列表选用户，再输入该用户的密码。README 明确注明目前只支持 Seer 本地用户。Trakt 的启用路径是：先在 trakt.tv 创建 OAuth 应用，然后在 SuggestArr 的 Services -> Trakt 里填入 Client ID 和 Client Secret 并保存，最后每个用户到 Profile -> Trakt Account 点击 Link Trakt 完成授权。
暂停与清理：几个容易被忽略的刹车
自动化工具最怕的是失控，SuggestArr 在这方面的设计值得单独看。README 列出了几个暂停条件，它们的作用各不相同。
Pending-Request Job Pause 会在 Seer 里仍有请求等待批准或拒绝时，跳过计划任务和手动任务。这个逻辑针对的是请求堆积：如果前面提交的东西还没人处理，继续生成新候选只会让队列更长。
Unwatched-Suggestion Pause 的条件更严格：当某个用户在可配置的天数内没有观看任何由 SuggestArr 发起的请求时，暂停该用户的计划推荐任务，但手动运行仍然可用。这条规则实际上是在用观看行为给推荐质量投票，如果推的东西没人看，系统就自己停下来。
Request Workflow 的全局设置还提供了另一种暂停方式：当某个任务的建议等待审核时暂停该任务，并且可以自动拒绝挂起超过指定天数的建议。这个暂停行为可以按任务覆盖。
Cleanup Automation 是反向操作：当用户从未在 Plex、Jellyfin 或 Emby 中收藏某个由 SuggestArr 发起的请求时，可以选择性地清理旧的请求和文件。这个功能默认状态在 README 中没有明确说明，启用前需要自己确认。它涉及删除文件，属于风险较高的开关，建议先只开启请求清理，观察一段时间再决定是否处理文件。
它不适合谁：几个明确的边界
第一类不适合的情况是 Seer 请求队列已经有积压。SuggestArr 的核心行为是持续产生新请求，Pending-Request Job Pause 只能缓解，不能解决审批能力不足的问题。如果没有人定期处理 Seer 里的待批请求，这个工具只会让积压更快增长。
第二类是对推荐结果有明确预期的人。TMDb 的相似推荐基于元数据和用户行为信号，README 没有给出任何关于命中率或满意度的数据，也没有说明相似度算法。换句话说，推荐质量的波动是这个方案的固有属性，而不是可以调优的参数。LLM 路线是 beta，同样没有质量承诺。
第三类是不愿意让脚本代替自己决定下载内容的人。虽然 Approve requests before sending them to Seer 可以拦住投递，但候选生成仍然在后台跑，Requests 页面仍然会积累条目。如果连审核这一步都不想承担，那么任何自动化推荐工具都不合适。
还有一个技术边界：使用特定 Seer 用户发请求时，README 注明目前只支持本地用户。如果你的 Seer 接的是 Plex 或 Jellyfin 账号登录，这条路走不通。
另外，清理功能会删除文件，这是不可逆操作。项目文档没有详细说明判定「从未收藏」的时间窗口和具体删除范围，README 只说了「旧的 SuggestArr 发起的请求和文件」。在这一点上文档偏薄，需要自己在测试环境验证后再决定是否在生产库上开启。
和同类方案的区别：Jellyseerr 自带发现 vs 观看历史驱动
最直接的对照是 Seer 本身以及 Jellyfin、Plex 自带的发现页面。Jellyseerr 这类请求管理工具提供的是搜索和浏览入口，用户主动去找内容，然后提交请求。Plex 和 Jellyfin 的首页推荐则基于平台自己的算法和元数据，通常是全站或全服务器的通用推荐，不针对单个用户的观看历史做个性化，也不会自动转化成 Seer 请求。
SuggestArr 的差异在于它把触发点放在「最近观看」这个事件上，并且输出的是 Seer 请求而不是展示位。它不提供浏览界面，也不打算替代 Seer 的搜索功能，它是一个后台任务调度器，夹在媒体服务器和 Seer 之间。
另一类对照是直接用 TMDb API 写脚本。自己写的好处是完全可控，坏处是要自己处理多用户、多服务器类型、凭据校验、cron 调度、请求去重、审批流和清理逻辑。SuggestArr 把这些做成了 Web 界面加配置预检，代价是引入了一个额外的常驻服务和一个需要维护的依赖。
LLM 推荐这条路线和纯 TMDb 相似推荐的区别在于信号来源：TMDb 用的是条目之间的相似关系，LLM 用的是观看历史文本加上模型自身的知识。README 把 LLM 功能标为 beta，并且强调每个推荐会附带理由，这至少让用户能判断推荐是否离谱。
维护成本与许可证
项目使用 MIT 许可证。这意味着你可以自由使用、修改和分发，包括商用，前提是保留版权声明和许可声明。这里不做法律建议，涉及再分发或修改后发布时，建议自己阅读完整的 LICENSE 文本。
维护成本主要来自三块。第一是依赖的外部服务：TMDb API、Seer、媒体服务器，以及可选的 Trakt 和 LLM 提供方。任何一个的 API 变更或凭据过期都会让任务失败，README 提到的配置预检只能覆盖初始化阶段，运行期的失效需要看日志。第二是数据持久化：Compose 示例只挂载了 config_files，如果使用默认的 SQLite，数据库文件的位置需要确认是否也在挂载范围内，否则容器重建可能丢失请求记录。第三是版本节奏，从发布记录看 v2.12.0 到 v2.14.0 大约每月一个小版本，升级前建议查看对应版本的发布说明，尤其是涉及审批流程和清理逻辑的改动。
外部数据库支持 PostgreSQL 和 MySQL，README 把它描述为提升可扩展性和性能的选项。对于用户量不大的家庭部署，SQLite 足够；只有在任务并发或历史记录量明显增长时，迁移到外部数据库才有意义。
编辑结论
如果你已经跑着 Jellyfin、Plex 或 Emby，并且用 Seer 管理请求，同时希望请求队列能自己长出来而不是靠人手动填，SuggestArr 的定位正好对得上：它把最近观看记录当作种子，用 TMDb 或 LLM 生成候选，再交给 Seer。反过来，如果你的 Seer 请求队列本来就积压，或者你无法接受自动化脚本替你决定要下载什么，那么先别开自动发送，把 Advanced 里的 Approve requests before sending them to Seer 打开，让结果停在 Requests 页面人工过一遍。上线前需要确认三件事：TMDb API Key 是否可用、Seer 的地址与凭据是否通过配置预检、以及 config_files 目录是否已经挂载到宿主机，否则容器重建后配置会丢。
社区笔记