必须用make作为中枢胶水串联dify多层嵌套工作流，因其原生不支持跨系统联动、定时调度和错误重试；需先在dify发布工作流为工具并验证api地址，再在make中配置http请求、动态上下文校验、三层响应处理链及google calendar事件驱动与失败降级机制。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让Dify里搭好的多层嵌套工作流——比如带条件分支的批量会议纪要生成+风险评分+自动归档+异常告警——真正跑进你的日常业务，但Dify原生不支持跨系统联动、定时调度和错误重试机制，这时必须用Make作为中枢胶水把整个链路串起来。
获取Dify工作流的可调用API地址
进入Dify控制台 → 工作流管理 → 找到目标工作流（例如“multi_layer_meeting_analyze”）→ 点击右侧“发布” → 选择“发布为工具” → 填写工具名称（必须全小写、无空格、含下划线）→ 保存。发布成功后页面显示的路径如【/api/tools/multi_layer_meeting_analyze】只是端点，【完整调用地址必须拼上你的Dify部署域名，否则Make会返回404】。
这一步不能跳过校验：打开浏览器新标签页，手动访问 https://your-dify-domain.com/api/tools/multi_layer_meeting_analyze，若返回{"error":"Unauthorized"}说明发布成功且域名正确；若返回404，立即检查域名拼写或是否漏填协议头。
在Make中配置HTTP请求并注入动态上下文
新建Make场景 → 添加“HTTP”应用 → 选择“Make a request”操作 → 方法选POST → URL填入完整地址，例如https://dify.yourcompany.com/api/tools/multi_layer_meeting_analyze → Headers里添加两行：
Authorization: Bearer sk-xxx（你的Dify API Key）
Content-Type: application/json
Body选JSON格式，输入结构必须严格匹配Dify工作流定义的输入schema。例如该工作流要求输入包含event_id、raw_transcript、risk_threshold三个字段，就绝不能少传risk_threshold，否则Dify会直接报400错误中断流程。
这一步最容易踩坑：Make默认把空字符串当有效值传给Dify，而Dify某些节点对空字符串敏感，会导致条件判断失效。务必在Body里加一层校验逻辑，例如用“Set variable”模块先判断raw_transcript是否为空，为空则终止流程或抛出自定义错误。
构建三层嵌套响应处理链
第一步：解析Dify返回的JSON主体
Make会自动将response.body解析为对象。如果Dify工作流输出是{"summary":"xxx","risk_score":0.72,"actions":[{"type":"archive","target":"airtable"}]}，你就能直接引用{{response.body.summary}}、{{response.body.risk_score}}、{{response.body.actions.0.type}}。
第二步：基于risk_score触发分支路由
添加“Router”模块 → 设置规则：若{{response.body.risk_score}} >= 0.6 → 走高风险路径；若=0.3 → 走中风险路径；否则走低风险路径。注意：Router必须放在HTTP模块之后、所有下游操作之前，否则无法读取response数据。
第三步：按分支执行差异化动作
高风险路径连接“Slack”应用 → 发送告警消息，内容模板为“⚠️ 高风险会议检测：{{response.body.summary}}（评分{{response.body.risk_score}}），请负责人立即介入”。中风险路径连接“Airtable”应用 → 创建新记录，字段映射时注意：Dify返回的actions数组需用Make的“Iterate”模块逐条写入，不能直接绑定整个数组。
用Google Calendar事件动态驱动Dify工作流
方法一：基础事件捕获
添加“Google Calendar”应用 → 选择“New event matching search query” → 日历ID填your-team@group.calendar.google.com → 关键词填“战略复盘|QBR|OKR Review”（用竖线分隔多个关键词）→ 勾选“Include description” → 这样event.description字段就会被完整传入后续流程。
方法二：增强型上下文提取
在Calendar模块后加一个“Code”模块（JavaScript）→ 输入代码片段：
const desc = input.event.description || '';
const meetingType = desc.match(/【类型】(.+?)\n/)?.[1] || 'default';
return { meetingType, cleanDesc: desc.replace(/【.+?】[\s\S]*?\n/g, '') };
这一步能从会议描述中精准抽取出结构化字段，比如【类型】产品评审 → 提取meetingType为“产品评审”，cleanDesc为剔除元信息后的纯文本，再把这两个值作为input传给Dify工作流，大幅提升Dify内部条件节点的判断准确率。
方法三：失败自动降级与重试
在HTTP模块后添加“Error handler” → 设置“Retry on error”为3次 → 间隔时间设为指数退避（1s → 2s → 4s）→ 若三次都失败，则触发“Email”模块向运维邮箱发送告警，附带原始event数据和错误堆栈。这一步不可省略：【Dify服务临时不可用时，没有重试机制会导致整条链路静默中断，业务数据永久丢失】。
