NAS买了总吃灰？绿联DXP4800 GT用双万兆四盘的底子+AI管家，把它真正用起来

一、NAS 最大的问题，不是性能不够，是没人使用

把 NAS 理解成“一个可以联网的大硬盘”，不算错，却只说对了一半。

如果只是存文件，移动硬盘、网盘和电脑扩容都能解决一部分问题。NAS 真正特别的，是它能够长期在线：连接手机、电脑、电视和相机，服务家里的每一个人；电脑关机后，它仍能继续备份、下载、索引和运行服务。

普通硬盘是一件工具，NAS 更像一个长期在线的数据节点。

问题也恰恰出在这里：长期在线，不等于长期有用。

很多 NAS 刚买回来时都很热闹：照片备份一轮，电影拷进去一批，Docker 装上十几个。几个月后，手机截图继续堆满相册，下载目录照样没人整理，上一次备份是否成功也无从确认。机器没有坏，只是从“家庭数据中心”变成了书房里那个一直亮着灯的盒子。

所以这次体验绿联 DXP4800 GT，我关心的不只是容量、速度和远程访问。我更想把 Hermes Agent 接入日常流程，看看 NAS 能不能从“等人打开”，变成每天主动处理一点数据。

分工很清楚：NAS 负责一直在线、稳定保存并提供文件入口；Hermes 负责理解任务、调用工具、记住规则，并按计划执行。

如果过去的 NAS 解决的是“数据放在哪里”，那么我这次想回答的是下一步：

数据放进去以后，谁来管？

二、3K档双万兆四盘NAS，为AI管家装备稳定的工作台

如果把 NAS 当作一台长期在线的数据工作台，那么绿联DXP4800 GT就是3K档主打双万兆、四盘位的高性能NAS。它的作用，是为多设备同步、内容管理和AI工作流提供稳定的计算、存储与网络基础。

它搭载 AMD Ryzen Embedded R2514，拥有 4 核 8 线程，最高频率 3.7GHz，并集成 Radeon Vega 8 显卡；两个 DDR4 内存插槽最高支持 64GB。存储部分提供 4 个 SATA 盘位和 2 个 M.2 NVMe 盘位，按官方标注，最高总容量为 4×32TB 加 2×8TB，共 144TB，既能承载照片库和影视库的大容量需求，也能用NVMe承接高频小文件。

容量越大，越需要清晰的分层与管理策略。机械盘适合承载大容量数据，M.2 可以用于高频或高速任务，Docker 负责运行 Agent 和自动化服务，虚拟机则保留完整的系统环境。照片索引、文件同步、影音服务和 Agent 并行运行时，可扩展内存也能为后台任务留出余量。

它还搭载同档少有的双10GbE配置。万兆并不等于任何场景都能“快十倍”，硬盘、阵列、交换机、网线、客户端网卡和文件类型，任何一环都可能先到上限。双万兆更现实的价值，是在多人读写素材、实时同步和索引时，让网络不至于最先成为瓶颈。它支持链路聚合和网络桥接；没有万兆交换机时，也可以根据实际环境让工作电脑与 NAS 直连。

硬件决定它能不能扛住任务，UGOS Pro 决定这些能力能否顺畅进入日常使用。手机、平板、电脑、电视和网页端都可以访问 NAS；UGREENlink 可在不自行配置公网 IP 和端口转发的情况下提供远程连接。系统还支持手机照片自动备份、电脑文件夹同步，以及百度网盘、OneDrive、阿里云盘、115、夸克等服务的转存或同步。分享文件时可以生成外链；多人使用时，管理员还能按用户、用户组、共享文件夹乃至子目录划分权限。

三、NAS 的传统艺能：相册自动备份与家庭影视中心

但是其实对大多数家庭来说，NAS 最先解决的往往不是某个复杂玩法，抗住多严峻的任务，而是两个很朴素的问题：手机照片越来越多，电脑和硬盘里的电影也越来越散。
前者需要稳定备份，后者需要一个真正方便使用的家庭媒体库。

先说相册。绿联相册在这里最实用的能力就是自动备份：在手机端开启照片和视频备份后，新的影像资料可以持续保存到 NAS，不必隔一段时间再接数据线、挑文件夹、手动复制。手机仍然负责拍摄和查看，NAS 则成为长期保存原片的地方。

换手机、清理手机空间，或者需要在电脑、平板上取回一段旧视频时，资料已经集中留在自己的存储里。通过绿联云客户端或网页端，也可以在不同设备上浏览和取用已经备份的照片与视频。

当然，手机自动备份到 NAS 只完成了第一层保护，并不等于万无一失。真正重要的家庭照片仍然应该再配合另一块硬盘、异地设备或云端做第二份副本。自动备份负责让日常习惯不掉链子，多副本才负责应对硬盘故障和意外删除。
当然，它优秀的点远不止备份，它集成本地AI模型，支持人物、事物、回忆、地点四维智能分类，无需云端处理；宝宝相册可按年龄和时间轴自动归类；工具箱提供相似/重复照片筛选和敏感内容识别。最关键的是所有AI处理都在本地进行、可手动关闭，家庭隐私不外泄。

再说影视中心。影片文件直接堆在目录里，只能看到一串文件名；加入影视中心后，可以通过 TMDB 与智能识别匹配影片信息，生成海报、标签和合集，把散落的电影与剧集整理成更接近流媒体平台的海报墙。媒体库还可以按用户分配权限，让家里的不同成员看到各自适合的内容，并在手机、平板、电脑和电视之间同步播放进度。

播放能力也覆盖了家庭影音常见需求：兼容4K、ISO、BDMV 和 HDR等主流格式，并支持外挂字幕、STRM 文件及网盘直连；字幕、音轨等播放参数可以记忆，剧集可设置跳过片头片尾，TV 端还支持 TrueHD、DTS-HD Master Audio 音频直通。再配合下载中心或迅雷，NAS 才真正从“存电影的硬盘”变成集下载、整理、播放和共享于一体的家庭影视中心。

这两项功能没有太多炫技，却最容易让人每天感受到 NAS 的价值：照片会自己回家，电影也不再只是躺在目录里。UGOS Pro 把备份、识别、海报墙、播放和多端访问连成了一条开箱即用的路径；少一些配置，才更有可能长期使用。

除了影视，绿联DXP4800 GT 还能当家里的无损音乐库和孩子的教育资源库：支持直接播放无损音频、自动按专辑归类，不用开会员就能听高音质，轻松搭一个自己的随身音乐库；还能专门给孩子存听力、古诗、儿歌和各类学习音频，做成一个长期积累的家庭学习资源库，孩子随时随地能听。

四、给“NAS AI 管家”配上一套装备——大模型 + Skills + 自动化

除了上面提到的传统功能，要让 NAS 从“等人打开的存储设备”变成每天主动工作的数据节点，我为它配置了三层能力：大模型负责理解意图和处理模糊信息，Skills 把经验封装成可重复执行的步骤，自动化则让任务在固定时间自行启动。

安装 Hermes Agent

承担这套工作的 Hermes，是 Nous Research 开源的 Agent。它可以调用终端和文件工具，通过 Skill 复用具体能力，也能借助 Cron 定时执行任务；长期有效的偏好写入 Memory，稳定的操作流程沉淀为 Skill。部署在 NAS 上以后，它不只负责回答问题，还能在我没有打开对话框时继续检查、整理和记录。

⚠️ Hermes Agent 是 Nous Research 维护、以 MIT 许可证开源的第三方项目，并不是绿联 DXP4800 GT 或 UGOS Pro 的原生功能。截至 2026 年 7 月 22 日，官方仓库最新公开版本为 v0.19.0，项目仍在高频更新；版本号也还处于 0.x 阶段，功能、配置项和部署方式可能继续变化。升级前最好先查看发布说明，并备份配置文件和数据卷。
它的能力越强，权限风险也越真实。Hermes 可以读写挂载目录、执行终端命令、加载 Skills 与 MCP，并通过定时任务在无人值守时持续运行。目录挂载过宽、容器权限过高、第三方 Skill 未经检查，或者把 Dashboard 直接暴露到公网，都可能把一次错误判断放大成文件误删、隐私泄露或服务异常。Hermes 官方安全策略也明确指出：操作审批、命令拦截和敏感信息遮盖只能减少误操作，真正可靠的隔离仍然来自操作系统和容器边界。
所以我的原则仍然是最小权限：只挂载必要的文件夹路径；API 密钥通过配置或密钥管理传入，不写进 Prompt 和 Skill。新装的 Skill、MCP 或 Cron 任务先在小范围、可恢复的数据上试跑，确认日志和结果没有问题，再逐步扩大权限。
不要先问 Agent 能做多少，先决定它最多可以影响哪里。本文中的例子均未配置dashboard的公网可访问性，仅以飞书bot和内网环境下的TUI进行使用。

从 DXP4800 GT应用商店安装

应用商店已经提供 Hermes Agent。对大多数用户来说，这是最省事的安装方式：按向导完成部署，再把需要处理的共享文件夹授权给 Hermes，就可以让它在明确的目录范围内读取和管理文件。如果初次使用AI Agent应用，推荐从应用商店的Hermes Agent进行安装和配置，应用商店一键安装版本已做基础安全隔离，相对手动部署更稳妥，适合普通用户体验；高级权限仍需自行管控。

首次安装时，系统会先准备 Docker 运行环境，再部署 Hermes Agent 服务。安装完成后点击“打开”，即可进入 Hermes 的初始化配置页面：

要完成最基本的使用，只需配置大模型密钥和消息平台。之后就能通过自己习惯的消息工具与 Hermes 对话。

如果希望使用 Hermes 官方最新版本，或者需要更细致地控制目录挂载、读写权限和容器参数，也可以通过 Docker 从零部署。相比应用商店版本，这种方式更灵活，但安装、升级和安全配置也需要自己维护。

使用 Docker 从零安装 Hermes

先在 UGOS Pro 应用商店安装 Docker，并确认 Docker Compose 可用，再通过 SSH 登录 NAS。如果系统缺少 Git 或 curl，可在 UGOS Pro 的 Debian 环境中补装。下面的流程直接使用 Hermes 官方开源仓库，不依赖 Nous Portal，也不使用云端托管版本。

开启SSH配置

在系统配置中需要先开启终端的SSH功能，才能进行后续的操作。SSH能拿到的执行权限很大，执行命令前务必确认命令是符合你的运行预期的再进行执行，避免因此误执行命令导致的目录越权、文件泄露、容器异常等情况。

ssh -t 用户名@NAS_IP

docker --version
docker compose version
git --version
curl --version

# 只有提示命令不存在时才执行
sudo apt-get update && sudo apt-get install -y git curl ca-certificates

接下来创建独立的部署目录并拉取官方代码。为避免停留在开发分支或误装预发布版本，命令会读取 GitHub 最新正式 Release 的标签并检出对应版本；最后一条命令用于确认实际安装的版本号。

git clone --filter=blob:none https://github.com/NousResearch/hermes-agent.git ~/hermes-docker
cd ~/hermes-docker

git fetch --tags
LATEST_TAG="$(curl -fsSL https://api.github.com/repos/NousResearch/hermes-agent/releases/latest | sed -n 's/.*"tag_name": *"\([^"]*\)".*/\1/p' | head -n 1)"
test -n "$LATEST_TAG"
git checkout "$LATEST_TAG"
git describe --tags --always

在部署目录中创建下面两个文件：compose.yaml 用于定义 Gateway、Dashboard 和数据卷，.env.dashboard 用于保存本地登录凭据。请替换其中三个 CHANGE_ME_* 占位符，并保留具名数据卷 hermes-data，这样升级或重建容器时不会丢失配置。

compose.yaml（脱敏示例）

services:
  gateway:
    build:
      context: .
    image: hermes-agent:local
    container_name: hermes
    restart: unless-stopped
    network_mode: host
    volumes:
      - hermes-data:/opt/data
    environment:
      HERMES_UID: "${HERMES_UID:-1000}"
      HERMES_GID: "${HERMES_GID:-1000}"
    command: ["gateway", "run"]

  dashboard:
    image: hermes-agent:local
    container_name: hermes-dashboard
    restart: unless-stopped
    network_mode: host
    depends_on:
      - gateway
    volumes:
      - hermes-data:/opt/data
    env_file:
      - .env.dashboard
    environment:
      HERMES_UID: "${HERMES_UID:-1000}"
      HERMES_GID: "${HERMES_GID:-1000}"
    command: ["dashboard", "--host", "0.0.0.0", "--port", "9119", "--no-open"]

volumes:
  hermes-data:
    name: hermes-data

.env.dashboard（脱敏示例）

HERMES_DASHBOARD_BASIC_AUTH_USERNAME=CHANGE_ME_USERNAME
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=CHANGE_ME_STRONG_PASSWORD
HERMES_DASHBOARD_BASIC_AUTH_SECRET=CHANGE_ME_RANDOM_SESSION_SECRET

用户名和密码请替换为自己的值。先运行 openssl rand -hex 32 生成随机签名密钥，再把输出填入 HERMES_DASHBOARD_BASIC_AUTH_SECRET。环境文件应限制为仅当前用户可读，真实凭据不要提交到 Git，也不要发布到文章中。

cd ~/hermes-docker

# 将输出填入 .env.dashboard 的 HERMES_DASHBOARD_BASIC_AUTH_SECRET
openssl rand -hex 32
chmod 600 .env.dashboard

export HERMES_UID=$(id -u)
export HERMES_GID=$(id -g)

docker compose -f compose.yaml config
docker compose -f compose.yaml build --pull
docker compose -f compose.yaml up -d
docker compose -f compose.yaml ps

首次构建需要下载基础镜像和依赖，耗时取决于 NAS 性能与网络。执行 docker compose -f compose.yaml ps，确认 Gateway 和 Dashboard 均处于运行状态后，再继续配置消息渠道。浏览器可通过 http://NAS_IP:9119 打开本地 Dashboard；从局域网访问时也必须启用认证。

通过 Docker 完成渠道配置。容器启动后，通过 SSH 登录 NAS 并进入保存 compose.yaml 的部署目录。Dashboard 和 Gateway 共用同一个数据卷，因此在 Gateway 容器中完成的渠道配置会自动被整套服务读取。

⚠️ 风险提示：SSH 会直接操作 NAS 底层系统，操作前请注意以下几点，避免目录越权、文件泄露与容器异常：
· 权限最小化：用具备最小必要权限的账号登录，不要直接用 root；
· 限定操作范围：仅在 compose.yaml 所在的部署目录内操作，不要改动其他系统目录，防止目录越权；
· 保护敏感信息：compose.yaml 及数据卷中可能含密钥/令牌等敏感内容，注意不要外泄、不要提交到公开仓库；
· 先校验再重启：改完配置先用 docker compose config 校验语法，再重启服务，避免误配置导致容器异常或服务中断；
· 操作前备份：建议先备份 compose.yaml 与数据卷，出问题可快速回滚。

ssh -t 用户名@NAS_IP
cd ~/hermes-docker
docker compose -f compose.yaml ps

用扫码方式配置飞书

除了在 Dashboard 中手动填写字段，Hermes 还提供扫码创建飞书机器人的快速注册流程。直接在 Gateway 容器中启动配置向导：

docker compose -f compose.yaml exec gateway hermes gateway setup

在向导中选择 Feishu / Lark，再选择推荐的 Scan QR code to create a new bot automatically。使用飞书客户端扫描终端显示的二维码并确认授权后，Hermes 会自动创建机器人应用，获取并保存 App ID、App Secret 和飞书域名，并默认使用 WebSocket 长连接。

https://open.feishu.cn/page/launcher?user_code=D9AN-924T&from=hermes&tp=hermes (二维码自动识别)

WebSocket 模式不需要公网回调地址，也无须额外填写 Webhook、Encrypt Key 或 Verification Token。扫码完成后，向导仍会询问几项访问策略：私聊建议启用 DM pairing approval；群聊建议仅在机器人被 @ 时回复；Home Chat ID 只用于定时任务和主动通知，不需要时可以留空。这些是 Hermes 自身的访问控制，不能由飞书授权代替。

完成向导后重启容器，并通过状态和日志确认飞书连接已经建立：

docker compose -f compose.yaml restart
docker compose -f compose.yaml ps
docker compose -f compose.yaml logs --tail 100 gateway

配置会保存在共享的 hermes-data 数据卷中，后续重新构建或替换容器也不会丢失。不要执行 docker compose down -v，否则会连同数据卷一起删除。

技能配置

Skill 不是另一个大模型，也不是装完就会自动运行的插件。它更像一份写给 Agent 的标准作业指导书：说明什么情况下使用、先检查什么、可以调用哪些工具、执行后如何验证，以及遇到危险操作时在哪里停下来。复杂一些的 Skill 还会附带脚本和模板，把一次成功的做法变成可重复执行的流程。

目前这台 NAS 的 Skills 页面显示 73 个 Skill 和 25 个 Toolset。开关控制 Skill 是否参与当前 Agent 的任务匹配；Browse hub 用于查找和安装新 Skill；Edit 则可以直接查看或修改对应的 SKILL.md。

选择 Skill 时，我先看来源，再看内容，最后看权限。官方内置或官方 Hub 的 Skill 优先；社区 Skill 要继续核对仓库、文件清单和安全扫描结果。安全扫描出现 dangerous 并不一定等于恶意，但说明其中包含网络访问、密钥读取、命令执行或高权限操作，必须逐条判断是否符合用途。

点击 Edit 可以直接查看 Skill 的说明文件。一个值得长期使用的 Skill，至少应该写清触发条件、执行步骤、风险边界和验证方法；只有一句“帮我整理文件”的提示词，还称不上可靠流程。

File Organizer 你的文件整理助手

应对场景：你的Downloads文件夹是不是也堆积了大量的文件？各种原因堆积下载的文件混在一起？这个File Organizer就是应对这样的场景的最佳助手skill。以这个场景为例：准备 NAS 使用资料时，PDF 规格书、项目 README、照片、CSV 数据和源码压缩包混在同一个下载目录里，让 Hermes 从公开网络下载 5 份真实资源，再完成分类、重命名、留痕和完整性核对，并进行示例：

实际输入：东芝 N300 官方 PDF、Hermes Agent README、公开风景照片、航空客流 CSV，以及 Hermes Agent 源码 ZIP。任务目录限定为 /opt/data/skill-cases/real-inbox；允许在该目录内移动和规范化命名，但禁止删除、覆盖或改写下载内容。

请使用 file-organizer Skill 完成一个真实的“资料收件箱整理”任务。工作目录限定为 /opt/data/skill-cases/real-inbox，只允许在这里创建和移动文件，不删除任何文件。
先创建 Inbox，并从公开网站下载这些真实资料：
东芝 N300 官方规格 PDF：https://www.toshiba-storage.com/wp/wp-content/uploads/2024/11/TOSHIBA-Datasheet-2026-N300-barrierfree-EN_180526.pdf
Hermes Agent README：https://raw.githubusercontent.com/NousResearch/hermes-agent/main/README.md
一张公开示例照片：https://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Fronalpstock_big.jpg/1280px-Fronalpstock_big.jpg
CSV 示例数据：https://people.sc.fsu.edu/~jburkardt/data/csv/airtravel.csv
Hermes Agent 源码压缩包：https://github.com/NousResearch/hermes-agent/archive/refs/heads/main.zip
下载完成后，根据文件真实类型和内容，把 Inbox 整理为 Documents、Images、Data、Archives、Need-Review。可以移动和规范化文件名，但不能删除、覆盖或改写下载内容。生成 manifest.md，记录来源 URL、原文件名、目标路径、大小和 SHA-256。最后用 tree/find 展示整理前后的目录，并用哈希确认移动前后内容未变化。

执行结果：Hermes 实际下载并整理了 5 个文件：PDF 和 Markdown 进入 Documents，JPEG 进入 Images，CSV 进入 Data，73 MB 源码包进入 Archives，Inbox 最终清空。原 Wikimedia 图片源超时后，它改用 Picsum 的公开图片源，并在 manifest 中记录了来源变更，没有把失败伪装成成功。

得到的产物：manifest.md 保存了每个文件的来源、原名、目标、大小和 SHA-256；5/5 文件移动前后哈希完全一致，Need-Review 为空。这个结果可以直接作为以后批量整理下载资料的模板。

OCR and Documents 你的文档阅读助手

应对场景：面对几十页的产品手册、合同或扫描资料，你是不是经常只想快速找到几个关键参数，却不得不从头翻到尾？OCR and Documents 可以读取 PDF、图片和常见办公文档，提取结构化信息并保留页码，方便回到原文核对。这里接着上一个案例，直接读取刚下载的东芝 N300 官方规格书，让 Hermes 为 NAS 采购整理一份中文速查表。

实际输入：文件为 /opt/data/skill-cases/real-inbox/Documents/toshiba-n300-datasheet.pdf。本次重点核对容量、转速、缓存、持续传输速度、工作负载、MTTF、质保、功耗和噪声；不同容量或 SKU 的参数不能混在一起，所有结论都要保留原始页码。

使用 ocr-and-documents Skill 完成一项真实的采购资料整理工作。读取 /opt/data/skill-cases/real-inbox/Documents/toshiba-n300-datasheet.pdf，提取并核对 N300 系列的容量范围、转速、缓存、持续传输速度、工作负载、MTTF、质保、功耗和噪声。将结果整理成适合 NAS 用户阅读的中文采购速查表，标注数据所在页码；如果同一字段随容量不同，请明确分组，不要猜测。把最终文件保存到 /opt/data/skill-cases/real-ocr/n300-purchase-brief.md，并在对话中展示核心表格和文件路径。

执行结果：Hermes 从官方 PDF 中提取并核对了 11 个容量型号，生成一份 135 行的中文采购简报。表格覆盖 4 TB 至 22 TB 型号，逐项列出缓存、传输速度、运行功耗、噪声、MTTF、盘位建议、URE 和对应页码（P.2—P.22）。

得到的产物：/opt/data/skill-cases/real-ocr/n300-purchase-brief.md。报告不仅汇总参数，还发现 12 TB 存在不同硬件版本，零售盒装与 Bulk 型号也可能采用不同 SKU，并提醒采购时核对完整型号。这样得到的不是一份泛泛的 PDF 摘要，而是一张可以直接辅助购买决策的速查表。

Watchers 你的软件更新雷达

应对场景：本地部署的软件需要及时升级，但你不可能每天打开每个项目的 GitHub 页面查看新版本。Watchers 可以持续观察 GitHub Releases、RSS 或 JSON API，记住已经看过的内容，只在出现新条目时继续处理。这里让 Hermes 为自身的 GitHub 仓库建立版本观察任务，并先生成一份当前版本简报。

实际输入：监控对象为 NousResearch/hermes-agent 的 GitHub Releases。第一次读取最新 3 个版本并整理与本地部署有关的变化，同时保存 Release ID 状态；紧接着再检查一次，用真实结果确认同一批历史版本不会被重复报告。

使用 watchers Skill 为这台 NAS 建立一个真实的软件更新观察任务：检查 NousResearch/hermes-agent 的 GitHub Releases，找出最新 3 个版本，提取版本号、发布日期、链接和与本地部署相关的重点变化，生成中文更新简报 /opt/data/skill-cases/real-watchers/hermes-release-brief.md，同时保存可供下次增量检查的状态。然后立即再检查一次，说明第二次是否发现新版本；不要发送外部通知。

执行结果：Hermes 真实访问 GitHub Releases API，整理出 v0.18.2、v0.18.1 和 v0.18.0 三个版本，并把 Docker 构建修复、Gateway 调整和安全加固等内容转换成与本地部署直接相关的说明。

得到的产物：/opt/data/skill-cases/real-watchers/hermes-release-brief.md，以及记录 21 个已知 Release ID 的状态文件。立即执行的第二次检查退出码为 0、stdout 为空，说明没有新版本，也没有重复输出历史记录。以后只需把同一条检查任务放进 Cron，就能把手动刷新页面变成增量观察。

Docker Management 你的容器巡检助手

应对场景：准备升级容器前，你通常需要先确认当前版本、数据卷、端口、重启策略和健康状态。Docker Management 可以把这些信息整理成一份升级前盘点，同时把“读不到”和“运行正常”明确区分开。这里让 Hermes 检查自身容器，但只允许读取和诊断，不允许它为了拿到结果而改变系统状态。

实际输入：对象是当前运行 Hermes 的容器环境。任务要求先判断 Docker daemon 是否可访问，再尽可能收集镜像、状态、端口、挂载、重启策略、健康状态、容器内版本和数据目录；任何启动、停止、删除、重建或配置修改都被明确禁止。

使用 docker-management Skill 做一次真实的 Hermes 升级前只读盘点。请检查当前环境是否能访问 Docker daemon，并尽可能收集 Hermes 容器的镜像、运行状态、端口、挂载、重启策略和健康状态；同时检查当前容器内可见的版本与数据目录。严禁启动、停止、删除或重建容器，严禁修改配置。如果宿主 Docker socket 未挂载，不要假装成功，也不要绕过权限；请明确列出已确认的信息、无法确认的信息，以及为了让只读盘点可用所需的最小权限方案。把报告保存到 /opt/data/skill-cases/real-docker/hermes-preupgrade-audit.md。

执行结果：Hermes 确认当前容器版本为 v0.18.2（build 9de9c25f），识别出 hermes-data 到 /opt/data 的数据卷、unless-stopped 重启策略和 Dashboard 使用的 9119 端口，并将结果写入 /opt/data/skill-cases/real-docker/hermes-preupgrade-audit.md。

得到的产物：一份区分“已确认”和“无法确认”的升级前审计报告。由于 /var/run/docker.sock 没有挂载，Hermes 无法读取宿主 Docker daemon，因此没有虚构镜像 ID、宿主上的其他容器或完整健康状态，也没有尝试绕过权限。报告进一步给出三种补充盘点方案，其中“在宿主机直接运行只读审计脚本”所需权限最小。

nas-butler：按自己的 NAS 规则创建专属 Skill

为什么要自己创建 Skill：现成的文件整理、Docker 和监控 Skill 只提供通用能力，却不知道这台 NAS 哪些目录只能读、哪些目录允许写、容量达到多少时只告警，以及哪些动作必须停下来等人工确认。nas-butler 的作用，就是把这些只属于本机的约定写成 Hermes 每次都能重复遵守的操作手册。

创建方法：打开 Dashboard 的 Skills 页面，点击 New skill。这里需要填写名称、分类和完整的 SKILL.md。如果不知道怎样写，可以先在 Chat 中让 hermes-agent-skill-authoring 根据需求生成，再把结果粘贴到 New skill 窗口。本例使用名称 nas-butler，分类为 productivity。

从需求生成 Skill 的完整 Prompt：这段话的重点不是要求 Hermes 立即整理文件，而是让它先生成一份以后反复使用的规则。

请使用 hermes-agent-skill-authoring，为这台家庭 NAS 创建一个名为 nas-butler 的自定义 Skill，分类为 productivity，并生成完整可用的 SKILL.md。

这个 Skill 用于日常 NAS 管理，包括文件盘点与整理、容量检查、重复文件候选报告、Docker 异常诊断和执行日志。请把下面这些本机规则固化进去：

1. /data/Photos-Backup 和 /data/Library 只能读取；/data/Automation 和 /data/Need-Review 可以读写。未明确加入白名单的其他挂载点禁止访问。
2. 每次移动或重命名前，必须先输出 dry-run，列出源路径、目标路径、判断依据和同名冲突状态，并等待人工批准。
3. 永远禁止删除和覆盖；发现同名文件就停止，把项目加入 Need-Review。
4. 容量超过 80% 时只告警和诊断，不自动清理。
5. 容器异常时只读取状态和日志，不自动 restart、stop、rm、prune 或执行 docker compose down -v。
6. 重复文件必须使用 SHA-256 确认，但只生成候选清单，不删除。
7. 每次执行把时间、输入、计划、结果和异常写入 /data/Automation/logs/。
8. 完成获批操作后，对比执行前后的文件数量、相关哈希、磁盘占用和日志，并明确报告无法验证的项目。

请让 description 清楚说明这个 Skill 在什么场景触发；正文使用 Allowed paths、Workflow、Safety gates、Verification 四个部分。只生成必要的 Skill 文件，不创建额外 README。

怎样改成自己的版本：复制这段 Prompt 时，最重要的是替换四类信息：真实挂载路径、读写权限、告警阈值和必须人工批准的动作。比如照片目录通常只读，自动化输出目录才允许写；如果你的容量告警线是 85%，就直接把 80% 改成 85%。规则越具体，Hermes 越不容易在模糊指令下做出超出预期的操作。

生成后的 Skill 是什么样：Hermes 最终在 /opt/data/skills/productivity/nas-butler/SKILL.md 创建了下面这份文件。最上面的 description 是触发说明；正文依次定义目录白名单、执行顺序、安全门和验收方法。

---
name: nas-butler
description: Safely inspect and organize approved NAS folders, generate reports, and diagnose capacity or container issues with dry-run and human approval gates.
version: 1.0.0
platforms: [linux]
metadata:
  hermes:
    category: productivity
    tags: [nas, files, backup, reporting, docker, safety]
    requires_toolsets: [terminal]
---

# NAS Butler

Use this skill for recurring NAS housekeeping only when the requested path is explicitly approved.

## Allowed paths

- Read-only: `/data/Photos-Backup`, `/data/Library`
- Read/write: `/data/Automation`, `/data/Need-Review`
- Never access other mounts unless the user explicitly adds them.

## Workflow

1. Inspect the requested path and report scope, counts, sizes, and risks.
2. Produce a dry-run plan with source, destination, reason, and conflict status.
3. Stop for approval before any move, rename, restart, cleanup, or permission change.
4. Never delete or overwrite files. On name conflict, stop and add the item to Need-Review.
5. Prefer deterministic commands for names, dates, extensions, hashes, disk usage, and container state.
6. Use a model only for ambiguous classification or explanation.
7. Write an execution log to `/data/Automation/logs/` with time, input, plan, result, and errors.

## Safety gates

- Capacity above 80%: alert and diagnose only; do not clean automatically.
- Container failure: inspect status and logs only; do not restart automatically.
- Duplicate candidates: verify with SHA-256 and report; do not delete.
- Original photos and documents remain read-only.
- Commands containing `rm`, `prune`, `down -v`, destructive permission changes, or filesystem formatting are prohibited.

## Verification

After an approved action, compare before/after file counts, hashes where relevant, disk usage, and logs. Report anything that could not be verified.

创建完成后如何使用：保存后，nas-butler 会出现在 Skills 列表中并默认启用。以后不必重新解释全部规则，只需要描述当天的具体任务。下面用它汇总前四个案例，生成一次真实的 NAS 日常收尾。

使用 nas-butler Skill 完成一次真实的 NAS 日常收尾。只在 /opt/data/skill-cases 范围内工作：汇总今天生成的 real-inbox、real-ocr、real-watchers、real-docker 四个案例产物，统计每类文件数量与总大小，列出最大文件、manifest 完整性、已经生成的报告及其路径，并给出明天最值得做的 3 个后续动作。不要删除或移动任何文件，不要读取工作目录之外的内容。把结果写入 /opt/data/skill-cases/nas-butler/daily-receipt.md，并在对话中展示一页式摘要。

执行结果：Hermes 汇总出 9 个产物、总计约 75 MB；其中最大的文件是 73 MB 的 Hermes 源码 ZIP，占总量约 97%。它确认 manifest 中的 SHA-256 校验全部通过，并找到采购简报、版本简报和升级前审计等 4 份已经生成的报告。

得到的产物：/opt/data/skill-cases/nas-butler/daily-receipt.md。一页式摘要把第二天的工作按优先级排好：先处理 Dashboard 端口暴露，再确认源码 ZIP 是否需要长期保留，最后补齐 Docker HEALTHCHECK。自定义 Skill 的价值就在这里：把只适用于这台 NAS 的规则，变成每天可以重复执行的固定流程。

这 5 个案例分别完成了整理、理解、监控、诊断和收尾，而且彼此使用真实产物串联：第一个案例下载资料，第二个读取其中的 PDF，第五个再汇总前四项的结果。判断一个 Skill 是否值得保留，不看它能否跑出“成功”二字，而看它能否在明确权限边界内持续产出可复核、可复用的结果。

五、东芝 N300：擦灰之前，地板得稳

照片持续备份、影视中心读取大码率影片，Hermes 又在后台批量整理、索引和生成报告：这些任务叠在一起，NAS 面对的就不再是偶尔拷一个文件。双万兆把网络上限抬高以后，硬盘和阵列能否持续供数，反而更容易成为整条链路的落点。也正因为如此，我想看看这台绿联 DXP4800 GT 里两块东芝 N300 8TB，在真实使用环境下能交出怎样的结果。

我把两块 N300 组成了 RAID1，阵列状态为 2/2 在线 [UU]，上层依次是 LVM 和 ext4。这样选择不是为了追求跑分，而是因为这个存储池里放着照片和项目素材：两块盘相互镜像，即使其中一块发生故障，数据仍有机会从另一块继续读取。代价也很明确——两块 8TB 硬盘只能获得约一块盘的可用容量，写入性能也不能代表 RAID0 或单盘在理想条件下的峰值。

如果存放的是可以重新下载的影视资源，更看重连续读写和容量利用率，RAID0 确实可以把两块盘的容量与性能叠加起来；但它没有任何数据冗余，任意一块硬盘损坏，都可能让整个阵列的数据无法恢复。RAID1 同样不能代替备份：误删除、勒索软件和阵列故障仍可能同时影响两份镜像。因此，重要照片和项目文件除了 RAID1，仍然要保留另一份独立副本。

为了看清它在 NAS 里的真实表现，我没有拿规格表代替实测，也没有继续在 Hermes 容器里跑脚本，而是通过 SSH 直接在 UGOS Pro 宿主机调用 fio 3.33。系统检测不到虚拟化环境，测试使用 libaio 和 direct=1，只在数据卷的临时目录创建测试文件；不直写物理盘，也不修改 RAID、缓存和文件系统参数。下面的数据反映的是“两块 N300 + RAID1 + LVM + ext4”这条完整存储链路。

先看最常见的连续读写：QD1 顺序写约 189.5 MB/s，高队列顺序读达到 217.3 MB/s。用来承接手机照片备份、影音库和大文件归档，这套 RAID1 已经足够从容。队列加深后，吞吐有所提升，但平均延迟和尾部延迟也同步增加——速度更高，并不代表每一次请求都更快。

再看机械盘不擅长的场景：四路并发顺序写降到 140.5 MB/s，4 KiB QD1 随机读约为 160 IOPS。多个文件流会让磁头频繁寻道，大量零碎文件也会迅速放大延迟。N300 的强项是长期在线和持续吞吐；数据库、容器元数据等高随机 I/O，更适合交给 NVMe 卷。

这些数字也不是单盘跑分。测试时数据卷已经使用约 70%，UGOS Pro 和 Docker 服务仍有后台 I/O，md1 在多项测试中接近 96%—100% 忙碌。因此，它更接近日常使用中的整机表现，不能直接与规格表里的单盘峰值画等号；但可以确认，虚拟化并不是这次性能差异的来源。

随机写约 500 IOPS 这一项还要谨慎看待。当前 ext4 使用了 nobarrier，普通 SSH 用户又无法确认硬盘写缓存和断电保护状态；同时随机写 P99 延迟达到 84—296 ms。换句话说，这更像是系统与设备缓存共同参与后的响应速度，不能直接当成每个 4 KiB 写入都已安全落盘的耐久指标。
从使用体验看，两块N300在这套RAID1里运行相当静音，寻道声很小，日常几乎察觉不到盘片活动。

结论并不复杂：这套 N300 RAID1 不是为了追求极端随机性能，而是为了稳定承接照片、视频和大文件。把高频小文件交给 NVMe，把重要数据交给多副本，才是更合适的分工。如果 Hermes 是每天来整理房间的管家，DXP4800 GT 是工作台，那么 N300 就是脚下那块不抢镜、却必须稳住的地板。

六、结论：让 NAS 从存储设备变成每天工作的数据节点

整段体验下来，DXP4800 GT、N300 和 Hermes 各自解决了不同问题：NAS 提供长期在线的底座，硬盘稳稳承接数据，Agent 则让备份、整理、检查和提醒持续发生。三者接在一起，NAS 才从“保存文件的地方”变成“管理数据的节点”。

它当然不是零配置。目录怎么划分、Hermes 能看到什么、哪些操作需要确认，仍然要由人决定；API、通知渠道和定时任务也要先接好。恰恰是这些清楚的边界，才让 AI 管家能够长期工作，而不只是完成一次漂亮的演示。

如果你有多台设备，照片和项目素材还在持续增长，希望数据留在自己掌控的设备里，又愿意把备份、整理和共享变成长期流程，那么 NAS 的意义就不只是“多几块硬盘”。

以前评价 NAS，我会看容量、性能、远程访问、相册、影音、Docker 和虚拟机。现在还可以多问一句：它能不能成为 Agent 工作流里的常驻节点？

在这套系统里，DXP4800 GT 提供计算、网络、盘位和 UGOS Pro，N300 负责长期在线的存储，Hermes 则负责每天看一眼、整理一点、记住规则，并在异常时叫我。硬件、数据和工作流各司其职，才组成了一个真正能长期运转的系统。

结果并不神秘：备份有记录，文件有人分，周报按时生成，容量异常也能带着原因来提醒。模型负责理解，Skill 负责沉淀经验，NAS 负责让文件、状态和上下文不会在下一次对话开始时消失。

书房里那个一直亮着灯的盒子，如今每天都在替我完成一点具体的工作。对我来说，这才是让 NAS 一直开着的理由。