---
name: patrol
title: 巡检
description: 检查站点、下载器、媒体服务器、存储和待处理事项是否正常，一段话说清哪些正常、哪些要处理。用户问「是否正常」「检查一下」「巡检」「体检」时用。
triggers:
  - 巡检
  - 体检
  - 是否正常|正不正常|正常吗|有没有(问题|异常)|健康
  - 检查(一下)?.{0,6}(站点|下载器|媒体服务器|系统|状态|服务)
  - (站点|下载器|媒体服务器|qB|qBittorrent|Jellyfin|Emby).{0,12}(状态|正常|连通|在线|掉线|掉了|挂了|登录|失效)
capabilities:
  - downloader.list
  - site.list
  - site.user_data
  - site.health_check
  - site.refresh_login
  - decision.list
  - subscription.list
  - download.list
  - download.inspect
sessions: [chat, patrol, investigate, child]
---

## 适用意图

- 「检查站点、下载器和媒体服务器是否正常」「巡检一下」「系统有没有问题」。
- 定时巡检（待处理巡检、下载诊断、订阅与站点周报）的目标里带「巡检」时也用它。

## 步骤

1. 先看系统提示里的「当前环境」：哪些接入了、哪些没接入。没接入的直接记一句「还没接入」，不再去查。
2. 下载器和媒体服务器：调用 downloader.list，看每个的连通状态、最近在线时间、进行中 / 失败任务数。
3. 站点：调用 site.list，看每个站点上次检查结果和登录状态。关心做种时再用 site.user_data（做种数、上传量）。
4. 下载器有失败任务时：download.list 只列失败 / 无进展的，记下名称和原因；不逐个 download.inspect，除非用户问原因。
5. 待处理与订阅：decision.list 看未关闭事项；用户问到订阅时再 subscription.list。
6. 用户明确要实时检测某个站点，才调用 site.health_check；站点登录失效时 site.refresh_login。两者都需要批准。

## 需要批准

- site.health_check（实时检测站点）、site.refresh_login（重新登录）。没有授权时会被拒绝：汇报里写一句「没做：实时检测「站点名」，需要你批准」，界面会给批准按钮。
- 需要批准的检查（如检测站点）不要只在汇报里写「需要你批准」：先实际调用一次，让审批卡 /「批准并重试」按钮出现在界面上，再在汇报里写一句「没做：…，需要你批准」。同一个检查只调用一次，被拒绝后不要重复调用。
- 其余都是只读，不需要批准。

## 汇报模板

一段话，最多 8 行，按「下载器 → 媒体服务器 → 站点 → 订阅 / 待处理」的顺序，异常的放最前面：

> 下载器 qBittorrent 正常，24 个在做种、没有在下载的；媒体服务器还没接入。站点憨憨上次检查正常（昨天 16:12），实时检测需要你批准。订阅 5 条都已取消，没有待处理事项。

有异常时：

> 下载器 qBittorrent 连不上（2 小时前最后在线），3 个下载停在 40% 左右。站点憨憨登录已失效，需要重新登录。媒体服务器 Jellyfin 正常；待处理 2 条，都是没识别出作品。

- 时间写相对时间，大小写 GB；对象用名字，不写 ID、adapter、英文状态。
- 巡检会话（定时）只读，最后可以补一句本次建议，不超过 2 条。

## 不要做

- 不要因为 site.list 里没有下载器就说「没有下载器」：下载器只看 downloader.list 和「当前环境」。
- 不要把站点的上传量、做种体积当作下载器健康的证据，也不要写「无证据不等于故障」这类解释。
- 不要向用户要下载任务 ID 或种子 hash：要看哪个下载就先 download.list。
- 不要列 ID、adapter、原始字节数的表格。