随着大模型逐步进入文件处理、知识检索、设备联动和运维告警等场景，越来越多团队希望在不上传敏感数据的前提下构建 AI 自动化流程。Ollama 负责在本地运行模型，Node-RED 负责连接接口、业务系统与触发条件，两者结合后，可以用可视化方式快速搭建一套可审计、可扩展的本地 AI 工作流。🤖
一、整体架构与适用场景
典型架构可以分为四层：数据源、Node-RED 流程编排、Ollama 推理服务和结果输出。数据源可能来自 HTTP 请求、MQTT 消息、数据库、文件目录或定时任务；Node-RED 负责清洗输入、拼接提示词、调用模型并判断结果；Ollama 在本机或内网服务器完成推理；最终结果可写入数据库、推送到通知系统，或触发后续设备动作。
这种组合适合内部文档摘要、工单分类、日志解释、离线知识问答、家庭自动化和边缘设备分析。它的主要价值不是单纯“本地聊天”，而是把模型能力嵌入已有业务链路，同时减少原始数据离开本地环境的机会。需要注意的是，本地部署并不等于天然安全，接口暴露、节点权限和流程发布仍需单独治理。
二、准备 Ollama 本地推理服务
完成 Ollama 安装后，可先拉取与硬件资源匹配的模型，再通过命令行验证模型能否正常响应。模型越大，通常需要越多内存或显存，因此实践中应先使用较小模型跑通流程，再根据准确率、响应时间和并发需求进行调整。
Ollama 提供本地 HTTP API，Node-RED 可以使用 HTTP Request 节点直接调用。例如向“/api/generate”发送 POST 请求，请求体至少包含 model 和 prompt 字段；需要一次性获得完整结果时，可以设置 stream 为 false。接口能力和参数应以 Ollama API 官方文档 为准。
建议：不要为了方便而直接把 Ollama 端口映射到公网。Node-RED 与 Ollama 最好部署在同一主机、同一容器网络或受控内网中，并通过防火墙限制可访问来源。🔐
三、在 Node-RED 中搭建调用流程
一个基础流程可以由 Inject、Function、HTTP Request、JSON、Switch 和 Debug 节点组成。Inject 节点提供测试文本；Function 节点生成 Ollama 请求体；HTTP Request 节点调用本地接口；JSON 节点解析响应；Switch 节点依据结果进行分流；Debug 节点用于检查开发阶段的输出。
- 在 Function 节点中读取 msg.payload，并对输入做长度、类型和空值检查。
- 把请求地址设置为 Ollama 服务地址，并采用 POST 方法发送 JSON 数据。
- 在请求体中明确模型名称、提示词和 stream 设置，避免节点收到连续分片后难以处理。
- 从返回对象中提取 response 字段，再交给邮件、数据库、MQTT 或 HTTP Response 节点。
- 增加 Catch 和 Status 节点，统一处理超时、模型未加载及接口不可达等异常。
提示词不要完全由外部输入决定。更稳妥的做法是在 Function 节点中固定任务目标、输出格式和禁止事项，只把经过过滤的用户内容插入指定位置。例如要求模型仅返回分类标签或结构化 JSON，再由 Switch 节点根据白名单值执行后续操作。这样可以减少模型输出不稳定对自动化流程的影响。
四、落实节点与编辑器权限管控
Node-RED 默认编辑器在未配置安全措施时可能被同一网络中的访问者打开，因此生产环境应配置 adminAuth。管理员账户可以保留完整权限，观察或审计账户则仅授予只读权限。密码应使用 Node-RED 支持的哈希方式保存，不要把明文密码直接写入 settings.js。具体配置方式可参考 Node-RED 安全指南。
Node-RED 的编辑器权限主要控制用户能否查看或修改流程，但细粒度的“单个节点使用权”还需要通过架构隔离实现。对高风险功能，可以拆分为独立实例或子流程服务，将文件写入、系统命令、数据库管理和设备控制节点放入受限实例，仅向普通流程开放经过验证的 HTTP 或消息队列接口。
- 限制调色板：只安装经过评估的节点包，关闭不必要的在线安装能力，并定期检查依赖来源。
- 隔离凭据：API 密钥和数据库密码使用凭据配置或环境变量，不写入 Function 节点和导出的流程 JSON。
- 约束文件权限：运行 Node-RED 的系统账户只访问指定目录，避免对整个磁盘具有读写权限。
- 控制网络出口：只允许流程访问 Ollama 和必要业务服务，降低恶意节点向外发送数据的风险。
- 保护 HTTP 节点：为对外接口增加认证、HTTPS、请求大小限制、频率限制和参数校验。
五、避免模型直接控制关键动作
模型输出具有概率性，不应直接作为删除文件、执行命令、转账审批或设备停机的唯一依据。推荐采用“模型建议、规则复核、人工确认”的三级链路：模型先生成结构化建议，Switch 或 Function 节点验证字段、范围和白名单，高风险操作再通过人工审批节点确认。⚠️
例如在智能家居场景中，模型可以把自然语言转换为“设备、动作、参数”三项内容，但真正发送 MQTT 指令前，应验证设备编号是否存在、动作是否允许、温度或亮度是否处于安全范围。模型只能提出意图，最终执行权仍由确定性规则掌握。
六、日志、审计与运行维护
上线后应记录请求时间、流程编号、模型名称、耗时、执行结果和错误类型，但不宜默认保存完整提示词及模型回复，以免日志再次形成敏感数据副本。确需留存时，应进行脱敏、设置访问权限，并明确保留周期。
模型升级也应纳入变更管理。切换模型或参数前，可准备一组不含敏感信息的固定测试样例，对分类结果、JSON 合法性、响应延迟和异常处理进行回归检查。Node-RED 流程则建议使用项目功能或版本控制保存修改记录，发布前导出备份，发生问题时能够快速回滚。
总结
Ollama 与 Node-RED 的组合能够把本地模型转化为可复用的自动化能力：Ollama 提供推理接口，Node-RED 完成事件触发、数据处理和系统联动。真正可靠的实践重点不只是“成功调用模型”，还包括编辑器认证、运行环境隔离、节点最小权限、凭据保护、确定性规则复核和全过程审计。只有把 AI 输出视为需要验证的建议，而不是天然可信的指令，才能构建兼顾效率、隐私与可控性的本地 AI 自动化流程。✅
