无脚本自动化：结合NAS、Docker与AI模型的智能工作流搭建指南

这次我们来看一套不怎么需要写代码、但能把电脑、NAS 和通讯平台真正串起来的 AI 工具环境。标题里的「无脚本桌面实拍」，意思是整个环境的落地和展示都不依赖手写 Python 脚本、不依赖 crontab 定时任务，而是用可视化的工作流把几台设备连成一个闭环。实拍桌面也好，写成文字也好，背后都是同一套架构。

很多人现在的 AI 工具环境是散装的：电脑上跑着几个 AI 客户端，NAS 只当成网盘用，飞书、钉钉、企业微信里的通知靠手动转发，文件靠手动上传下载。遇到「群里发一条指令，NAS 上的模型自动处理一批文件，再把结果推回群里」这种需求，第一反应是写脚本。脚本一旦多起来，依赖环境、路径、变量全都要维护，很快就不想动了。

这套环境的思路是三层分工：电脑负责重计算和桌面端操作，NAS 负责数据存储和 7x24 常驻服务，通讯平台负责触发入口和结果通知，中间用 n8n、Node-RED 这类无脚本工作流引擎把所有事件串起来。下面按架构设计、环境准备、部署步骤、功能验证、接口调用和排错清单的顺序，把整套环境拆开讲清楚。

1. 核心能力速览

先给一张总表，方便快速判断这套环境适不适合自己。

能力项	说明
项目类型	本地 AI 工具环境 / 自动化工作流整合方案
核心组件	电脑（桌面端）、NAS（存储 + 常驻服务）、通讯平台（消息触发与通知）、可视化自动化引擎
无脚本自动化	通过 n8n、Node-RED 等拖拽节点完成事件串联，不依赖手写脚本
本地 AI 能力	在 NAS 上通过 Docker 运行 Ollama 等模型服务，供电脑和工作流统一调用
启动方式	NAS 端以 Docker 容器方式部署，电脑端按工具分别启动
是否支持 API	支持，模型服务和管理接口均通过 HTTP 调用
是否支持批量任务	支持，工作流可设置循环节点、队列和失败重试
推荐硬件	NAS 支持 Docker；电脑根据模型任务决定是否配 GPU
显存占用	取决于 NAS 端模型和电脑端推理任务，以实际模型和参数为准
适合场景	个人知识库、文件自动归档、群机器人、监控告警、定时批量处理

从这张表能看出，这套环境的关键词不是「某个单一软件」，而是「把几个成熟工具接起来」。单个工具都是现成的，难点在事件怎么流转、数据怎么落盘、异常怎么处理。

2. 适用场景与使用边界

2.1 这套环境适合谁

适合以下四类用户：

• 手头有群晖、飞牛（fnOS）等支持 Docker 的 NAS，想让它不只是网盘。
• 电脑上已经用了不少 AI 工具，想给它们加一个统一调度入口。
• 经常要在飞书、钉钉、企业微信群里收发文件和处理任务，希望机器人代替人工转发。
• 不想写脚本、但愿意在可视化界面里拖节点的普通技术爱好者。

2.2 能解决什么问题

• 文件进 NAS 目录后自动触发后续流程，例如 OCR、压缩、重命名、推送通知。
• 群里发一条消息，机器人调用本地模型返回结果，不经过云端 API。
• 监控摄像头录像自动归档，异常告警推送到通讯平台。
• 电脑端 RPA 负责操作没有接口的旧软件，把结果写到 NAS 共享目录，再由工作流继续处理。

2.3 不适合什么场景

• 对并发要求很高的生产级任务队列，建议还是用专业任务系统。
• 需要复杂条件分支和大量自定义逻辑时，无脚本节点反而比代码难维护。
• 没有 Docker 支持的旧款 NAS，扩展能力会受限。

2.4 使用边界与合规提醒

NAS 里存放影视、文档、监控录像时，要注意版权和个人信息保护，不要传播未授权内容。摄像头接入 EasyNVR 这类服务时，视频流默认不要暴露到公网，尽量限制在局域网内访问。通讯平台机器人可能接触到群消息，采集个人敏感信息前必须获得授权。为 AI 服务提供 API 时，要限制访问来源 IP，避免被外部扫描到。

3. 整体架构设计：电脑、NAS、通讯平台各管什么

3.1 三层职责划分

这套环境可以拆成四个部分：

组成部分	职责	典型工具
电脑（桌面端）	重计算、GUI 操作、桌面自动化	影刀 RPA、ComfyUI、各类 AI 客户端
NAS	存储、常驻服务、模型推理	群晖 / 飞牛 fnOS、Docker、Ollama、rclone
通讯平台	触发入口、结果通知、人工审批	飞书、钉钉、企业微信、Telegram Bot
自动化引擎	事件串联、数据流转、调度重试	n8n、Node-RED、Dify

数据流向通常是：通讯平台消息或 NAS 目录变化先触发自动化引擎，引擎调用 NAS 上的 AI 服务完成处理，再通过 Webhook 把结果推回通讯平台，最终落盘到 NAS 存储目录。整个过程没有一行调度脚本，全是可视化节点。

3.2 一个典型的目录监听流程

以「NAS 新文件进来 -> AI 生成摘要 -> 推送到企业微信群」为例：

1. NAS 共享目录出现新文件。
2. 自动化引擎的文件监听节点捕获事件。
3. 引擎调用 Ollama 模型服务读取文件内容并生成摘要。
4. 引擎通过群机器人 Webhook 发送摘要。
5. 原文件按规则归档到已完成目录。

这个流程在 n8n 里就是五个节点，节点之间用连线拖出来即可。

4. 环境准备与前置条件

4.1 NAS 端要求

• NAS 必须支持 Docker。群晖的 Container Manager、飞牛 fnOS 的 Docker 应用都可以。
• 给 NAS 设置固定 IP，或者在路由器里做 DHCP 绑定。避免重启后 IP 变化导致工作流 Webhook 和 API 地址全部失效。
• 预留磁盘空间。模型文件、容器镜像、日志、监控录像都会占空间，建议单独建一个 Docker 数据目录。

推荐目录规划：

/volume1/docker/portainer/ # Docker 管理面板数据 /volume1/docker/n8n/ # n8n 工作流数据 /volume1/docker/ollama/ # 模型文件 /volume1/docker/nodered/ # Node-RED 流数据 /volume1/media/input/ # 自动化处理输入目录 /volume1/media/output/ # 自动化处理输出目录

飞牛 fnOS 和群晖的路径前缀可能不同，实际路径以你的 NAS 存储池为准。

4.2 电脑端要求

电脑端主要跑桌面操作和重计算任务：

• 操作系统建议 Windows 10/11，部分 RPA 工具对 Windows 支持最好。
• 如果要在电脑上跑图像生成或大模型推理，需要 N 卡并安装对应显卡驱动。没有独显也可以先跑 CPU 推理，速度会慢。
• 安装 Docker Desktop 不是必须的，NAS 已经承担了容器职责，电脑端保持轻量。

4.3 网络与端口规划

同一局域网内，建议把端口固定下来，避免容器重启后端口漂移。

服务	默认端口	说明
n8n	5678	工作流引擎 Web 界面
Node-RED	1880	备用流引擎
Ollama	11434	模型服务 API
Portainer	9000	Docker 管理面板
EasyNVR	10800	摄像头接入服务

端口只是常见默认值，部署时如果冲突，可以在容器映射时改掉。

5. NAS 端部署：Docker 装自动化与 AI 服务

NAS 端全部通过 Docker Compose 管理。这里给的是通用模板，镜像名称、路径、端口都要按实际环境替换。

5.1 部署 n8n 工作流引擎

n8n 是这套环境的调度中枢。创建一个目录n8n，写入docker-compose.yml：

version: "3.8" services: n8n: image: n8nio/n8n:latest container_name: n8n restart: unless-stopped ports: - "5678:5678" environment: - N8N_HOST=192.168.1.100 - N8N_PORT=5678 - N8N_PROTOCOL=http - GENERIC_TIMEZONE=Asia/Shanghai volumes: - /volume1/docker/n8n:/home/node/.n8n

注意替换N8N_HOST为你的 NAS 实际 IP。启动命令：

docker compose up -d

启动后浏览器访问http://NAS_IP:5678，注册管理员账号即可进入可视化编辑界面。

5.2 部署 Ollama 模型服务

Ollama 负责提供本地模型推理能力。同样用 Compose 部署：

version: "3.8" services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - /volume1/docker/ollama:/root/.ollama

启动后拉取模型。在 NAS 的终端里执行：

docker exec -it ollama ollama pull qwen2.5:7b

模型文件较大，拉取时间取决于 NAS 性能和网络条件。拉取完成后，可以用一条命令验证服务是否正常：

curl http://localhost:11434/api/tags

返回 JSON 列表即表示服务正常。注意，NAS 的 CPU 和内存条件直接决定模型能不能跑，建议先从 3B、7B 这类中小规模量化模型开始试，确定能接受再往上加。

5.3 部署 Portainer（可选）

如果不想在 NAS 命令行里敲 Docker 命令，可以先装 Portainer：

version: "3.8" services: portainer: image: portainer/portainer-ce:latest container_name: portainer restart: unless-stopped ports: - "9000:9000" volumes: - /var/run/docker.sock:/var/run/docker.sock - /volume1/docker/portainer:/data

Web 界面能直接查看容器状态、日志、CPU 和内存占用，排查问题比命令行直观很多。

5.4 挂载外部存储：rclone 配合 WebDAV

如果电脑、NAS、云盘之间的文件需要打通，可以用 rclone 把 WebDAV 挂载到本地目录。这种用法在很多 NAS 社区里很常见，尤其是群晖、飞牛这类系统。

先配置远程存储：

rclone config

配置完成后测试挂载：

mkdir -p /mnt/webdav rclone mount remote:/ /mnt/webdav --daemon

挂载路径可以在 n8n 工作流里直接作为输入目录使用。注意 rclone 挂载占一定内存，长时间不用建议卸载，避免资源浪费。

5.5 可选：EasyNVR 接入摄像头监控

如果环境里有萤石等品牌摄像头，想录像集中存到 NAS，可以部署 EasyNVR 容器，把 RTSP 流接入后统一管理。这一类服务的部署要点是：

• 摄像头和 NAS 必须在同一网段。
• 记得配置录像存储路径到 NAS 大容量目录。
• 视频流和 Web 管理页不要直接暴露到公网。

接入监控的唯一目的是本地化管理自己的合法设备，不要用于未授权区域采集。

6. 无脚本工作流搭建与验证

部署完成后，进入 n8n 界面，开始做功能验证。建议从最小流程开始，不要一上来搭复杂分支。

6.1 场景一：目录监听 + AI 摘要 + 群消息通知

目标：监听 NAS 输入目录，新文件出现后调用 Ollama 生成摘要并推送群通知。

n8n 节点编排如下：

1. Watch Folder节点监听/volume1/media/input。
2. Execute Command节点读取文件内容，调用 Ollama API。
3. HTTP Request节点请求 Ollama 生成摘要。
4. 用Function节点把摘要拼成消息文本。
5. HTTP Request节点把消息 POST 到群机器人 Webhook。

验证步骤：

• 在输入目录放一个文本文件。
• 观察 n8n 执行记录，确认四个节点都显示成功。
• 到群里看是否收到摘要消息。
• 查看 NAS 输出目录，确认原文件被归档。

判断标准：文件放进去后，30 秒内群里出现摘要，且执行记录没有红色报错节点。

6.2 场景二：通讯平台机器人触发 AI 问答

目标：在群里 @ 机器人，机器人调用 NAS 上的模型返回答案。

n8n 节点编排如下：

1. Webhook节点接收群机器人转发的消息。
2. Ollama节点（或 HTTP Request 节点）把消息文本发给本地模型。
3. 把模型返回结果作为消息回复到群。

验证步骤：

• 在群里 @ 机器人发一条问题。
• 看机器人是否在合理时间内回复。
• 回复内容断连时，检查 Webhook 地址是否填对。

6.3 场景三：电脑 RPA 联动 NAS 归档

电脑端用 RPA 工具录制操作步骤，例如导出某系统报表、截图、重命名文件，做完后把文件保存到 NAS 共享目录。NAS 上的 n8n 目录监听节点会自动接手后续处理。

这种做法的价值在于：老旧桌面软件没有 API，但 RPA 可以模拟人工点击；RPA 只负责操作电脑，不负责业务逻辑，业务逻辑全部放在 NAS 工作流里，维护边界清晰。

6.4 通用验证清单

检查项	预期结果
目录监听节点是否响应	新文件出现后自动触发
Ollama 调用是否成功	返回非空文本，无超时
Webhook 推送是否到达	群里收到对应消息
文件是否归档	原文件移动到输出目录
执行记录是否全绿	无失败节点

7. 通讯平台接入与 API 调用示例

7.1 群机器人 Webhook 接入

飞书、钉钉、企业微信都支持在群设置里添加自定义机器人，拿到一个 Webhook 地址。以飞书机器人为例，发送文本消息的常见格式：

curl -X POST 'https://open.feishu.cn/open-apis/bot/v2/hook/你的Webhook地址' \ -H 'Content-Type: application/json' \ -d '{"msg_type":"text","content":{"text":"NAS 任务已完成"}}'

钉钉和企业微信的 JSON 字段不同，但思路一致，先去对应开放平台文档确认参数。Webhook 地址本身包含权限，泄露后别人可以往你的群里发消息，注意保密。

7.2 调用 Ollama 模型服务

Ollama 提供标准 HTTP 接口，可以直接用 curl 测试：

curl http://192.168.1.100:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用三句话总结这段文本", "stream": false }'

返回结果里的response字段就是模型输出。stream: false表示一次性返回完整结果，适合工作流调用；改成true会流式返回，适合对话场景。

7.3 Python 调用示例

如果后续想从电脑端脚本调用 NAS 上的模型，下面是一个通用模板：

import requests url = "http://192.168.1.100:11434/api/generate" payload = { "model": "qwen2.5:7b", "prompt": "给这段文字写一个标题", "stream": False } resp = requests.post(url, json=payload, timeout=300) data = resp.json() print(data["response"])

IP、模型名、超时时间按实际环境调整。这个接口本质上是 HTTP，任何编程语言都能调用，因此可以很方便地接进 n8n 的 HTTP Request 节点，也可以接进自己的小工具。

7.4 在 n8n 工作流里调用 API

n8n 里不需要写完整程序，直接用 HTTP Request 节点：

• Method 选 POST。
• URL 填 Ollama 地址。
• Body 填 JSON 参数。
• 响应解析节点从返回值里取response字段。

整个过程都是表单化配置，这就是无脚本的核心：节点连线 + 参数填写，逻辑可视化，出问题能顺着连线一步步查。

8. 资源占用与性能观察

8.1 观察方法

NAS 端最直接的观察方式是：

docker stats

这个命令会实时显示每个容器的 CPU、内存、网络占用。Portainer 面板也能看，但没有docker stats实时。

电脑端如果跑模型，用系统自带任务管理器或者在推理时观察显存占用曲线即可。

8.2 资源占用特点

• n8n、Node-RED 这类引擎本身很轻，主要消耗在节点执行时的临时数据上。
• Ollama 是资源大头。加载模型后，模型参数要常驻内存，模型越大占用越高。量化模型和原版模型的内存占用差距明显，NAS 内存不足时优先选择量化版本。
• 摄像头录像写入对磁盘占用大，需要单独规划存储空间和保留周期。
• 批量任务并发执行时，多个节点同时跑，内存占用会叠加，建议设置执行并发限制。

8.3 降低占用的措施

• 不在 NAS 上跑超过硬件承受能力的模型，先从 3B 开始验证。
• 长任务放在凌晨执行，避开白天使用高峰。
• n8n 里设置执行历史保留天数，避免执行日志无限增长。
• 监控录像按周覆盖，或者用对象存储做冷备。

显存和内存的具体数字，一定要以你自己设备的实际模型和推理参数为准，不同设备差异很大。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
容器启动后页面打不开	端口被占用或容器未正常运行	查看 docker ps 和容器日志	换端口重启，或检查端口映射
NAS 重启后容器没自启	Compose 里没设置 restart 策略	检查 restart 字段	改为restart: unless-stopped
Ollama 拉取模型失败	网络问题或磁盘空间不足	查看磁盘剩余空间和下载日志	扩容目录或换一个模型
模型推理速度很慢	NAS CPU/内存不够	用 docker stats 看占用	换小模型，或改到电脑端推理
群里收不到 Webhook 消息	Webhook 地址错误或内容格式不对	用 curl 单独测试 Webhook	对照开放平台文档修正消息格式
目录监听不触发	路径映射错误或权限不足	检查容器内路径和共享目录权限	重新映射 volume，赋予读写权限
批量任务卡住	某个节点超时或 API 无响应	打开执行详情，定位红色节点	增大超时时间，加失败重试节点
输出内容不稳定	模型参数或提示词设置问题	检查提示词和 temperature 参数	固定提示词模板，降低随机性
rclone 挂载掉线	网络波动或内存不足	查看 rclone 日志	加--vfs-cache-mode full或设置自动重挂

排查问题的核心方法是看两处：容器日志和 n8n 的执行详情。容器日志解决服务本身是否正常，执行详情解决工作流哪一步断了。

10. 最佳实践与使用建议

10.1 从最小闭环开始

第一次搭建，不要想着把所有服务一次配齐。先做一个小闭环：NAS 放一个目录，n8n 监听这个目录，发现文件就推送一条消息到群里。这个闭环跑通了，再逐步加 Ollama、加批量处理、加 RPA。最小闭环验证的是基础设施是否可靠，后面所有复杂流程都建立在它上面。

10.2 目录和文件命名规范

输入目录、输出目录、临时目录分开建，文件命名加上日期前缀。批量任务处理完毕就把原始文件归档到独立目录，避免工作流重复处理同一批文件。建议输出结果统一用 JSON 或 Markdown 格式，方便后续接知识库。

10.3 给批量任务加日志和重试

n8n 的每个节点都能单独设置重试次数。批量处理一定要开重试，网络抖动和模型超时是常态。另外，给每个任务生成一个任务 ID，用这个 ID 命名输出文件，出了问题能直接定位到对应输入文件。

10.4 安全边界

• 通讯平台机器人的 Webhook 不要泄露。
• Ollama API 默认监听所有网卡，建议在 Compose 里限制绑定局域网 IP。
• NAS 的 SSH、Docker 管理面板不要暴露公网。
• 摄像头视频流仅限内网访问。
• 涉及他人肖像、声音、版权素材的功能，必须确认授权后再使用。

10.5 下一步可以扩展的方向

这套环境跑顺之后，可以继续接入中间件：比如给 NAS 加一个向量数据库做成个人知识库，电脑端的下载目录接入自动整理流程，通讯平台机器人增加多轮对话能力，把常用目录用 rclone 挂成 WebDAV 让其他设备直接访问。每一步的验证方式都类似：触发一个事件，看工作流是否按预期流转，结果是否落盘，通知是否到达。先把最小闭环跑通，再一步步加节点，这套环境的扩展空间比想象中大。