Dify Workflow 模板怎么设计：智能家居与 IoT 自动化的可复用模式

Dify Workflow 用在智能家居和 IoT 自动化里，最有价值的不是“把所有设备接进 AI”，而是把重复的自动化逻辑沉淀成可复用模板：事件进来后先分类，再补上下文，必要时让人确认，最后只调用受控的业务接口或设备命令服务。

本文的核心结论是：Dify Workflow 适合承担 AI 判断、上下文整理、内容生成、分支编排和人工确认，不适合直接成为设备状态主账本或高风险设备命令执行器。 如果动作只影响通知、摘要、工单或建议，Dify 可以直接完成；如果动作会改变门锁、空调、照明、安防、能源设备或工业执行器状态，就应该把 Dify 放在“决策辅助与审批层”，把最终执行交给 IoT command service。

决策块

当工作流输出的是“建议、摘要、通知、工单、低风险配置”时，可以把 Dify Workflow 作为主编排器；当工作流输出的是“设备状态改变、批量控制、安全相关动作、计费相关动作”时，Dify 只能发起请求或收集确认，不能绕过设备命令层的幂等、权限、限流、确认和审计。

1. 先把模板拆成五个稳定对象

很多 Dify Workflow 示例不好复用，是因为它们直接从“用户说一句话”跳到“调用工具”。在智能家居和 IoT 场景里，更稳的模板应该先拆成五个对象：

这个拆法的好处是模板可以迁移。今天触发源可能是智能门锁离线，明天可能是温控设备超温；只要模板边界稳定，Trigger 和 Context 可以换，Decision 和 Fallback 不需要每次重写。

2. 模板一：事件摘要与通知模板

适用场景： 设备事件量大，但单个事件不一定需要立即处理，例如门磁频繁开合、传感器状态变化、普通离线上线、环境数据越界预警。

这个模板的目标不是“自动控制设备”，而是把事件变成运营人员看得懂的摘要。

典型流程：

1. Trigger：接收设备事件或告警消息。
2. Context：查询设备名称、房间、客户、最近 10 条事件和当前状态。
3. Decision：判断事件是否需要通知、是否合并成摘要、是否升级成告警。
4. Action：发送企业微信、Slack、邮件或创建轻量记录。
5. Fallback：如果上下文查询失败，发送“信息不完整”的人工处理通知。

这个模板适合从旧的规则告警升级到 AI 摘要。比如同一个房间连续出现温度波动、门磁变化和摄像头离线，单条规则只能发三条消息，Dify Workflow 可以把它们整理成“疑似现场断电或网络抖动，需要先检查网关和供电”的摘要。

边界也要清楚：摘要不是事实来源。设备最终状态仍然应来自设备平台、状态投影或数据库，不能因为 LLM 总结了一句“设备已恢复”就改写主账本。

3. 模板二：告警分级与工单模板

适用场景： 智能门店、冷链、办公室、社区或轻工业场景里，告警需要按严重程度进入不同处理路径。

这个模板要回答的问题是：哪些事件只通知，哪些事件创建工单，哪些事件必须升级到人工确认。

推荐分层：

Dify 的优势在于把上下文整理成工单语言：设备在哪里、影响谁、最近发生了什么、可能原因是什么、推荐第一步检查什么。这样比“温度超过阈值”更接近真实运营。

但是，告警分级模板不能只靠 LLM 自由判断。高风险等级必须有规则底座，例如温度越界时长、设备离线时长、门锁状态、时间窗口、客户等级和现场安全策略。LLM 可以负责解释和摘要，不应该单独决定“是否执行设备动作”。

4. 模板三：人工确认命令模板

适用场景： 用户或 AI 助手提出“关闭设备、调整阈值、重启网关、切换模式、批量下发配置”等动作，但这些动作不能自动执行。

Dify 官方的 Human Input 节点支持在关键步骤暂停工作流，向人展示上下文，并根据用户选择走不同分支。这个能力很适合 IoT 自动化里的 human-in-the-loop。

推荐模板如下：

flowchart LR
  A("User / Event<br/>Requests Action"):::trigger --> B("Context Builder<br/>Device + Policy + Recent Events"):::context
  B --> C("Risk Classifier<br/>Low / Medium / High"):::decision
  C --> D{"Needs Human<br/>Confirmation?"}:::decision
  D -- "No" --> E("Low-Risk API<br/>Notification / Record"):::action
  D -- "Yes" --> F("Human Input<br/>Approve / Edit / Reject"):::human
  F -- "Approve" --> G("Command Service<br/>Idempotency + Audit"):::command
  F -- "Reject / Timeout" --> H("Fallback<br/>Ticket / Escalation"):::fallback
  G --> I("Result Summary<br/>Operator + Log"):::output
  H --> I

  classDef trigger fill:#E8F3FF,stroke:#2F6FED,color:#123B6D,rx:10,ry:10;
  classDef context fill:#EAF7F0,stroke:#2F9E66,color:#174B32,rx:10,ry:10;
  classDef decision fill:#FFF7E6,stroke:#D28A00,color:#5A3A00,rx:10,ry:10;
  classDef human fill:#F3ECFF,stroke:#7B61D1,color:#38266B,rx:10,ry:10;
  classDef action fill:#F6F8FA,stroke:#8A96A3,color:#2B3440,rx:10,ry:10;
  classDef command fill:#FFECEC,stroke:#D64545,color:#6B1F1F,rx:10,ry:10;
  classDef fallback fill:#FFF1E6,stroke:#D97706,color:#6B3B00,rx:10,ry:10;
  classDef output fill:#EEF7FF,stroke:#4B8BBE,color:#24496B,rx:10,ry:10;

这个模板的关键不是“加一个审批按钮”，而是把审批前后的责任拆开：

• Dify 负责生成审批说明：动作是什么、为什么建议执行、风险是什么、不执行会怎样。
• Human Input 负责收集批准、修改或拒绝。
• Command service 负责真正执行设备命令，并记录幂等键、操作者、设备、参数、结果和失败原因。
• Fallback 负责处理拒绝、超时和命令失败。

如果没有 command service，Dify 直接调用设备 API 也能跑通 demo，但生产环境会缺少限流、权限、状态确认和审计链路。

5. 模板四：状态对账与异常解释模板

适用场景： 用户看到 App 状态、设备实际状态、平台状态不一致，需要系统解释“为什么看起来不对”。

这类问题在智能家居和 IoT 系统里很常见：设备离线但 App 仍显示在线，命令发送成功但设备没动作，传感器数值长时间不变，或者告警已经恢复但通知还没关闭。

模板流程：

1. Trigger：用户提问或定时对账任务发现异常。
2. Context：读取最新状态、最后上报时间、最近命令、事件日志和设备连接状态。
3. Decision：判断是延迟、离线、命令失败、状态投影滞后还是数据缺失。
4. Action：生成解释、建议排查步骤或创建工单。
5. Fallback：证据不足时，明确告诉用户“当前无法判断”，并列出缺失数据。

这个模板的价值在于减少“AI 编造原因”。Dify Workflow 应该把可用证据先整理好，再让 LLM 生成解释。没有事件日志、命令回执或最后上报时间时，工作流应该输出“不足以判断”，而不是推测设备坏了。

6. 模板五：知识检索增强的排障模板

适用场景： 用户问“为什么这个设备连不上”“某个自动化为什么没执行”“怎么设置这个传感器阈值”，答案依赖设备文档、内部 SOP 或历史案例。

这个模板通常需要知识库检索、上下文变量和输出节点配合：

• 先识别设备型号、场景和问题类型。
• 再检索安装手册、FAQ、历史工单或内部 SOP。
• 然后把检索结果和实时设备状态一起交给 LLM。
• 最后输出排障步骤、风险提示和下一步动作。

如果有多个分支，例如“网络问题”“权限问题”“设备硬件问题”“自动化规则问题”，可以用变量聚合器把互斥分支的同类型输出汇聚成统一变量，再交给下游节点生成最终回复。Dify 文档也强调变量聚合器适合每次只有一条路径执行的互斥分支，不适合合并并行分支结果。

这个边界很重要。知识检索增强模板解决的是“回答更准”，不是“自动修复一切”。当排障建议涉及设备重启、配置修改或安全策略变更时，仍然要回到人工确认命令模板。

7. 什么时候不适合用 Dify Workflow 直接做 IoT 自动化

Dify Workflow 很适合做 AI 应用编排，但下面几类场景不建议让它直接成为执行核心：

• 毫秒级或秒级硬实时控制，例如灯光同步、门锁联动、工业联锁。
• 高风险设备动作，例如安防解除、门锁开关、电源切换、能源设备控制。
• 大规模批量命令，例如上万设备固件、配置或模式批量下发。
• 需要严格状态一致性的设备主账本，例如租户隔离、计费、审计、故障追责。
• 长周期补偿流程，例如离线设备恢复后的命令重放、跨天对账和批量重试。

这些场景不是不能接入 Dify，而是不能让 Dify 绕过底层平台。正确做法是：Dify 负责解释、建议、确认和编排；IoT 平台负责状态、权限、命令、审计和补偿。

8. 最小可复用模板清单

如果要从一套模板开始，建议先做这 5 个：

这 5 个模板覆盖了智能家居和 IoT 自动化最常见的路径：看见事件、理解事件、决定是否升级、让人确认动作、解释异常原因。

9. 结论

Dify Workflow 的正确价值，不是把智能家居和 IoT 系统变成“让 AI 直接控制设备”，而是把事件、上下文、判断、人工确认和输出动作组织成可复用模板。

对低风险自动化，Dify 可以直接完成摘要、通知、内容生成和工单创建。对会改变设备状态的动作，Dify 应该只负责提出建议和收集确认，最终命令必须经过 IoT command service。这样设计后，工作流既能复用 AI 的理解能力，又不会牺牲设备控制系统最重要的权限、确认、审计和故障补偿。

参考资料：

• Dify Workflow Orchestration Logic
• Dify Human Input node
• Dify Variable Aggregator node
• Dify Output node