给 OpenClaw / HermesAgent 集成群晖操作 SKILL：从一句话到可审计的 NAS 自动化

我之前已经整理过两篇偏“命令手册”风格的群晖文章：

1. Synology 群晖 SSH 命令详解
2. 群晖 NAS CLI 管理指南

这两篇文章解决的是“人知道有哪些命令可以用”的问题。本文想解决另一个更实际的问题：如果我已经在使用 OpenClaw / HermesAgent 这类 Agent 工具，能不能把这些群晖命令沉淀成一个操作 SKILL，让我以后用一句话就能让 Agent 帮我检查 NAS、整理状态、生成操作计划，甚至在确认后执行一些维护命令？

我的答案是：可以，但不应该把它做成“Agent 拿到 root 权限以后随便跑”。正确的集成方式应该是：

1. 让群晖 SSH 访问可控、可验证、可撤销。
2. 把常用群晖 CLI 操作写进 SKILL，让 Agent 知道可用命令、风险分级和输出格式。
3. 默认只允许只读诊断命令自动执行。
4. 对重启服务、修改权限、改用户、改网络、删除文件、存储相关操作设置确认门禁。
5. 每次执行后保留命令、输出和结论，方便回看和追责。

如果你只想快速理解整篇文章，看下面这张图就够了。

一、为什么要把群晖操作写成 SKILL

群晖的 DSM 界面已经很好用，为什么还要把它接给 Agent？

原因不是为了“炫技”，而是很多 NAS 运维动作天然适合被 Agent 辅助：

1. 一次检查往往需要看多处信息，例如存储池、卷、共享目录、服务状态、网络状态、系统日志。
2. 群晖 CLI 命令很多，平时不常用时很难记住参数。
3. 真实问题经常不是单条命令能判断，需要把多个命令输出串起来分析。
4. 有些操作需要先做只读检查，再决定是否执行变更。
5. 家庭或小团队环境里，很多人希望“少登录后台，少翻菜单”，但又不想牺牲可控性。

例如你可以对 OpenClaw / HermesAgent 说：

请参考我的群晖 CLI 操作说明，检查 NAS 的存储空间、共享目录、网络状态和最近错误日志。只执行只读命令；如果发现需要修改配置，请先给出操作计划，不要直接执行。

如果 Agent 没有 SKILL，它可能只知道泛泛地说“请登录 DSM 控制面板查看”。如果它有一个明确的群晖操作 SKILL，它就可以知道：

1. 该通过 SSH 连接到哪个目标。
2. 哪些命令是只读检查。
3. 哪些命令属于中高风险，需要先停下来确认。
4. 输出应该如何整理成“发现、证据、建议、下一步”。
5. 遇到权限不足、命令不存在、DSM 版本差异时应该怎么处理。

这就是 SKILL 的价值：不是让 Agent 变成一个不受限制的 shell，而是把“可执行的专业操作流程”打包成一个可复用、可审计、可不断改进的能力单元。

二、先把前提说清楚：群晖必须能被安全地 SSH 管理

在集成 OpenClaw / HermesAgent 之前，必须先解决群晖 SSH 访问的问题。这个步骤不建议省略，因为后面所有 Agent 自动化都建立在这个基础上。

最小前提一般包括四件事。

1. 开启 SSH 访问

在 DSM 中进入“控制面板”里的终端机相关设置，开启 SSH 服务。建议不要直接暴露到公网；如果确实需要远程访问，优先考虑 VPN、跳板机、内网穿透白名单或防火墙限制来源地址。

只要目标是给 Agent 使用，就更应该避免“所有来源都能打到 22 端口”的做法。Agent 只是自动化调用方，不应该因为它方便执行命令，就把 NAS 的入口暴露给整个互联网。

2. 配置 root 能力或可 sudo 的管理账户

很多群晖底层维护命令需要 root 权限。你可以选择 root 登录，也可以选择管理员账户登录后 sudo。哪种方式更合适，取决于你的环境、审计习惯和自动化工具能力。

为了让文章里的示例简单，下面使用 root@nas.example.lan 作为占位目标。请注意这只是示例地址，不是实际主机名。真实环境里建议使用你自己的内网 DNS 名称或固定主机名，不要在公开文章、脚本仓库或截图里泄露真实公网地址、真实内网拓扑、真实用户名和密钥路径。

3. 生成专用 SSH key

不要把你平时登录所有服务器的主密钥直接交给 Agent。更稳妥的做法是为群晖 Agent 操作生成一个专用密钥，例如：

ssh-keygen -t ed25519 -f ~/.ssh/synology_agent_ed25519 -C "synology-agent"

然后把公钥加入群晖目标用户的 authorized_keys。如果你的环境需要 root 免密登录，请确认 DSM 的 SSH 配置允许对应登录方式，并且权限设置正确。

4. 验证 root 免密 SSH 登录

正式写 SKILL 前，先用最简单的只读命令确认链路可用：

ssh -i ~/.ssh/synology_agent_ed25519 -o BatchMode=yes root@nas.example.lan 'hostname; id; uptime'

这里有几个检查点：

1. BatchMode=yes 可以避免命令卡在交互式密码提示上。
2. hostname 用来确认没有连错设备。
3. id 用来确认当前身份和权限。
4. uptime 用来确认命令可以正常返回。

如果这条命令都不稳定，不要急着接 Agent。先修 SSH、DNS、密钥、权限、防火墙和 DSM 设置。Agent 自动化只能放大已有链路的可靠性，也会放大已有链路的不可靠。

三、风险必须前置：Agent 不是越有权限越好

群晖里有些命令只是查看状态，有些命令会重启服务，有些命令会改用户权限，还有些命令可能影响数据。把这些命令全部放进一个“自动执行”的篮子里，是非常危险的。

我建议至少分成四层。

低风险：只读诊断

这类命令可以默认允许 Agent 执行，例如：

1. 查看主机名、系统运行时间、内核和 DSM 相关信息。
2. 查看磁盘、卷、空间使用情况。
3. 查看服务状态。
4. 查看网络配置。
5. 读取最近日志，但不要长期抓取敏感日志内容。

低风险不等于零风险。日志里可能包含用户名、路径、内网地址、设备名称等信息，所以最终摘要要注意脱敏。

中风险：服务刷新和重启

例如重启某个服务、刷新配置、重新加载网络相关服务等。这类操作通常不会直接删除数据，但可能造成短暂中断，影响文件共享、同步任务、媒体服务、下载任务或容器服务。

建议策略是：Agent 可以提出命令和影响说明，但执行前要确认。

高风险：修改用户、权限、网络、共享目录

例如改用户密码、修改共享目录权限、调整网关和 DNS、变更防火墙、修改 SSH 配置。这类操作如果出错，可能导致你自己也登录不上，或者让数据暴露给不该访问的人。

建议策略是：必须先给出计划、回滚方式和验证命令。没有确认，不执行。

禁止默认自动化：删除、格式化、重建、存储池破坏性操作

涉及删除数据、格式化磁盘、重建存储池、清空目录、批量改权限、覆盖证书私钥等操作，不应该出现在“一句话自动执行”的默认范围内。

就算你未来真的要让 Agent 辅助这类操作，也应该把它放到单独的高危流程里：先备份、再计划、再人工确认、再分步执行、每一步都验证。不要把它混在日常巡检 SKILL 里。

四、一句话集成的目标是什么

这里说的“一句话集成”，不是指真的只靠一句话就完成所有底层安全准备。SSH、root 权限、密钥和目标白名单这些基础设施必须认真做。

一句话集成指的是：当前提准备完成后，你可以用一句自然语言让 OpenClaw / HermesAgent 建立或调用这个群晖 SKILL。

例如：

请创建一个名为 synology-nas-ops 的 OpenClaw / HermesAgent 操作 SKILL。请参考 https://blog.margrop.net/post/synology-ssh-commands/ 和 https://blog.margrop.net/post/synology-diskstation-cli-administration-guide/ 集成群晖的相关 CLI 操作。默认只执行只读检查；任何重启、删除、改权限、改用户、改网络、改存储的动作都必须先列出命令、风险、回滚方式并等待我确认。

以后使用时，你可以继续用一句话：

使用 synology-nas-ops 检查 NAS 的存储空间、共享目录、网络状态和最近系统错误。请只读检查，并把结果按“现象、证据、建议、下一步”整理。

或者：

使用 synology-nas-ops 帮我判断为什么 SMB 访问变慢。先做只读诊断，不要重启服务；如果你认为需要重启或修改配置，先给我计划。

这样设计的好处是，用户入口很简单，但底层不是“随便跑命令”。SKILL 会把 Agent 的行为框住：它知道参考资料在哪里、命令如何分类、哪些动作要停下来问、输出如何组织。

五、一个可复制的 SKILL 模板

下面是一个偏通用的 SKILL.md 模板。你可以把它放到 OpenClaw / HermesAgent 支持的 skills 目录中，或让 Agent 根据这个模板创建一个名为 synology-nas-ops 的技能。

模板里刻意使用占位符，不写真实 IP、真实用户名、真实密钥路径。请在自己的私有配置里填入真实值，不要把它们提交到公开仓库。

---
name: synology-nas-ops
description: Use this skill when the user asks OpenClaw / HermesAgent to inspect, diagnose, or plan operations for a Synology DSM NAS through SSH and Synology CLI commands.
---

# Synology NAS Operations Skill

## Purpose

This skill helps inspect and operate a Synology DSM NAS through SSH. It should prefer read-only diagnostics, summarize evidence, and require explicit user approval before any disruptive or destructive command.

## Connection

- Target alias: `nas.example.lan`
- SSH user: `root` or a sudo-capable administrator
- SSH key: use a dedicated private key configured outside this file
- Never print private keys, passwords, tokens, or full internal topology in the final answer.

Example connection command:

```bash
ssh -i ~/.ssh/synology_agent_ed25519 -o BatchMode=yes root@nas.example.lan '<command>'
```

## References

When command details are needed, refer to:

- https://blog.margrop.net/post/synology-ssh-commands/
- https://blog.margrop.net/post/synology-diskstation-cli-administration-guide/

## Default Rules

1. Start with read-only commands.
2. Before running commands, briefly state the diagnostic goal.
3. Do not run commands that delete data, format disks, rebuild storage pools, rewrite certificates, change passwords, modify network settings, modify SSH settings, or change share permissions without explicit user approval.
4. For any medium-risk or high-risk operation, first provide:
   - exact command
   - expected impact
   - rollback or recovery path
   - verification command
5. If the command output includes private hostnames, internal IPs, usernames, share names, serial numbers, or tokens, redact them in summaries unless the user explicitly asks to inspect raw output.

## Read-Only Diagnostic Commands

Use these for initial inspection when relevant:

```bash
hostname
id
uptime
df -h
mount
synoservice --status
synonet --show
synonet --get_hostname
synopartition --list
```

For logs, prefer narrow reads:

```bash
tail -n 120 /var/log/messages
```

Do not dump large logs unless the user asks for raw evidence.

## Output Format

Respond with:

1. Summary
2. Commands executed
3. Findings and evidence
4. Risk assessment
5. Recommended next steps

If no write action was taken, say so explicitly.

这个模板不是为了覆盖所有群晖命令，而是为了建立一个安全骨架。真正有价值的是这些规则：

1. 连接目标固定。
2. 默认只读。
3. 命令来源可追溯。
4. 风险动作先确认。
5. 输出要带证据。
6. 敏感信息默认脱敏。

有了这个骨架，再逐步补充你常用的命令，比一开始就把所有 syno* 命令塞进去更稳。

六、把已有 CLI 文章变成 Agent 的“参考手册”

前面提到的两篇文章可以承担不同角色。

Synology 群晖 SSH 命令详解 更像速查表，适合让 Agent 在“我大概知道要查什么，但忘了命令名”的时候参考。例如工作组、主机名、网关、共享目录、加密共享目录、用户、通知、存储、升级等方向。

群晖 NAS CLI 管理指南 更像详细说明，适合让 Agent 在需要理解参数、限制、返回码、用户和共享目录语义时参考。

在 SKILL 里写“请参考这两篇文章”，比把所有命令复制到提示词里更好，原因有三点：

1. SKILL 本身保持短小，不容易过期。
2. 命令细节集中维护在文章里，后续补充更方便。
3. Agent 使用时可以根据任务只读取相关部分，而不是每次都吞下整本手册。

不过要注意，文章是参考，不是授权。即使文章里有删除共享目录、修改用户、改网络等命令，也不代表 Agent 可以自动执行。授权边界必须写在 SKILL 的规则里。

七、一次真实使用流程应该长什么样

一个比较健康的执行链路应该像这样：

用户输入：

使用 synology-nas-ops 检查 NAS 最近是否有磁盘或服务异常。只读检查。

Agent 应该先解释它要做什么：

我会通过 SSH 运行只读命令，检查主机身份、运行时间、磁盘空间、服务状态和最近系统日志。不会执行重启、删除、修改权限或修改网络配置。

然后执行类似命令：

ssh -i ~/.ssh/synology_agent_ed25519 -o BatchMode=yes root@nas.example.lan 'hostname; uptime; df -h; synoservice --status; tail -n 80 /var/log/messages'

最后输出应该类似：

摘要：
- NAS 可连接，当前身份为 root，命令均为只读。
- 存储空间没有发现明显耗尽风险。
- 某个服务最近出现重复重启记录，需要继续观察。

证据：
- df -h 显示主要卷仍有充足空间。
- synoservice --status 中某服务状态异常。
- /var/log/messages 最近 80 行出现相关错误。

建议：
- 先只读查看该服务更详细日志。
- 如果确认服务卡死，再考虑重启该服务；重启前需用户确认。

如果用户接着说：

那你帮我重启这个服务。

Agent 不应该立刻执行，而应该停下来：

这是中风险操作，可能短暂影响对应功能。我计划执行以下命令：

<具体命令>

影响：
- 相关服务会短暂中断。

回滚：
- 如果服务未恢复，检查日志并恢复配置；必要时通过 DSM 控制面板处理。

验证：
- 重启后再次查询服务状态和最近日志。

请确认是否执行。

这就是“简单入口”和“安全边界”的平衡。

八、常见任务怎么写成一句话

下面给几个我认为比较实用的提示词写法。

1. 健康巡检

使用 synology-nas-ops 做一次 NAS 健康巡检：检查存储空间、服务状态、网络状态和最近系统错误。只读检查，输出按“摘要、证据、风险、建议”整理。

2. SMB 访问变慢诊断

使用 synology-nas-ops 帮我诊断 SMB 访问变慢。先检查系统负载、网络状态、相关服务状态和最近日志。不要重启服务，不要修改配置；如需变更，先给计划。

3. 共享目录权限核对

使用 synology-nas-ops 核对指定共享目录的权限状态。只读取权限和共享配置，不要修改用户、用户组或共享目录权限。

4. 网络配置确认

使用 synology-nas-ops 检查 NAS 当前主机名、网关、DNS 和网络接口状态。只读检查，并说明是否存在明显配置风险。

5. 变更前计划

使用 synology-nas-ops 为“重启某个异常服务”生成操作计划。请列出命令、影响、回滚方式和验证步骤，但不要执行。

这些提示词都有一个共同点：把“只读”或“先计划不执行”说清楚。不要只说“帮我修一下 NAS”。这类模糊指令很容易让 Agent 在不该行动的时候行动，或者在应该收集证据时直接给出猜测。

九、推荐的 SKILL 目录结构

如果你的 OpenClaw / HermesAgent 环境支持把技能保存为目录，可以使用类似结构：

synology-nas-ops/
  SKILL.md
  commands/
    readonly.md
    risky.md
  examples/
    health-check.md
    smb-slow-diagnosis.md

其中：

1. SKILL.md 写总规则、连接方式、风险边界和输出格式。
2. commands/readonly.md 放只读命令清单。
3. commands/risky.md 放需要确认的命令类型和禁止默认执行的动作。
4. examples/ 放常见任务的输入和期望输出。

目录可以很简单，不必一开始就工程化。关键是把“Agent 可以做什么”和“Agent 不能直接做什么”写清楚。

十、隐私和安全：不要把 NAS 细节写进公开材料

写 SKILL 时，很容易不小心泄露信息。例如：

1. 真实内网 IP。
2. 真实公网域名。
3. 真实用户名。
4. 真实共享目录名。
5. SSH 私钥路径和文件名。
6. 日志里的设备序列号。
7. 备份目录结构。
8. 业务文件夹名称。

这些信息单独看可能不算密码，但组合起来就是攻击面。所以建议：

1. SKILL.md 里只写别名和占位符。
2. 真实连接配置放在本机私有配置或环境变量里。
3. 最终回复默认脱敏。
4. 需要贴日志时先裁剪范围。
5. 不把 Agent 原始执行日志直接发布到公开文章或公开仓库。

尤其是家庭 NAS，很多路径名、共享名、用户名都带有个人信息。Agent 在总结时要主动把它们泛化成“某共享目录”“某用户”“某内网地址”，除非你明确要求保留原文。

十一、操作风险：哪些事情最好不要交给一句话执行

我不建议把下面这些动作放进日常群晖 SKILL 的自动执行范围：

1. 删除共享目录。
2. 批量删除文件。
3. 批量修改权限。
4. 格式化磁盘。
5. 重建存储池。
6. 修改默认网关或 DNS。
7. 修改 SSH 配置并立即重启 SSH。
8. 覆盖证书私钥。
9. 修改 root 密码。
10. 在没有备份验证的情况下执行升级。

这些动作不是永远不能自动化，而是不应该用“一句话自动化”来处理。它们需要更严格的流程：备份检查、计划生成、影响评估、人工确认、执行窗口、回滚路径、执行后验证。

Agent 最擅长的是把复杂检查流程变短，把命令输出变成结构化结论，把操作计划写清楚。它不应该替代你承担数据安全责任。

十二、我推荐的最终落地方式

如果从零开始，我建议按下面顺序落地：

1. 先只做 SSH 连接验证，不接 Agent。
2. 写最小 SKILL，只包含连接说明、两篇参考文章、只读命令和风险规则。
3. 用健康巡检类任务测试 3 到 5 次。
4. 检查 Agent 是否会误执行中高风险动作。
5. 再补充 SMB、共享目录、网络、日志、服务等专题命令。
6. 对每个专题增加一两个示例任务。
7. 把“需要确认”的动作单独列出来。
8. 定期回顾执行日志，删除不常用或危险的命令。

最小可用版本可以非常短：

请创建 synology-nas-ops SKILL：通过 SSH 管理群晖 NAS；请参考我的两篇群晖 CLI 文章集成命令；默认只读检查；重启、删除、改权限、改用户、改网络、改存储必须先计划并等待确认；输出包含执行命令、证据、风险和建议；回复默认脱敏。

这句话背后真正重要的是几个词：默认只读、先计划、等待确认、证据、脱敏。

十三、总结

给 OpenClaw / HermesAgent 集成群晖操作 SKILL，核心不是“让 AI 控制 NAS”，而是把你已经认可的群晖 CLI 操作方法，整理成一套更容易调用、更容易审计、更不容易误操作的流程。

好的群晖 SKILL 应该做到：

1. 用户入口足够简单，一句话就能发起巡检或诊断。
2. 命令来源足够清楚，可以回到已有文章和模板查证。
3. 默认行为足够保守，只读优先。
4. 风险动作足够克制，先计划、再确认、再执行。
5. 输出足够结构化，能看见命令、证据、判断和下一步。
6. 隐私处理足够主动，不把真实环境细节泄露到公开材料里。

当这些边界都设置好以后，Agent 才真正从“会运行命令的聊天窗口”变成“能协助你管理 NAS 的操作助手”。这也是我认为 OpenClaw / HermesAgent 和群晖结合时最值得追求的方向：不是权限最大，而是路径最短、证据最清楚、风险最可控。