简介一套基于Dify平台的工作流实操资源包面向希望掌握低代码流程自动化与模型调用集成的开发者、运维及企业数字化人员。内容围绕可视化编排、智能模型调用、API服务对接三大能力展开覆盖从工作流设计到部署运行的常见场景帮助读者将Dify平台能力落地为具体业务应用。资源共107个文件压缩包约78.99MB以Python脚本、YAML编排配置、XML规则文件、文本说明及ini配置为主另有少量模型缓存、编译字节码、环境变量示例与SQL初始化脚本目录结构清晰便于按模块对照学习。已有199人学习下载。通过该资源可掌握Dify工作流的DSL设计与导入导出、多环境配置方式、模型服务调用逻辑以及API集成中的常见排错要点适合需要快速上手Dify或在此平台上搭建自定义自动化流程的人员。 这个项目是我在帮朋友公司做招聘提效时顺手折腾出来的。几十个技术岗的简历哗啦啦堆了一邮箱HR 看不过来初筛质量也不稳定。后来我基于 Dify 平台搭了一套简历筛选工作流把“读简历、贴标签、打分、归档”这套动作全部自动化HR 只需要看最终结果。整个过程走下来我发现 Dify 工作流的门槛其实比想象中低但想把工作流真正用顺、用到生产环境还是有不少门道。这篇文章就把我从设计、部署、搭建到排障的完整实操过程写出来不光是讲界面操作更会解释每个关键步骤背后的“为什么”。如果你是刚接触 Dify、想用它落地具体业务场景或者已经在用但总感觉流程跑不顺这篇内容应该能帮上忙。1. 工作流设计思路先想清楚再动手1.1 为什么是 Dify 而不是别的工作流平台市面上能搭 AI 工作流的平台不少Coze、n8n、Flowable、Dify 各有各的拥趸。我在选型时做过一轮对比核心考量是三点能不能私有化部署、跟 LLM 应用的契合度、以及二次开发的成本。对比维度DifyCozen8nFlowable开源可私有化社区版完全开源部分能力受限开源但企业版收费开源版可用LLM 应用深度集成强RAG/Agent/工作流一体强但倾向绑定自家生态一般偏自动化集成弱偏业务流程数据隐私可控性本地部署完全可控依赖云服务自托管可控自托管可控上手门槛中低低中高高插件与生态插件市场快速增长插件非常丰富节点极多偏企业系统集成我最终选了 Dify核心原因是它在同一个平台里把工作流、知识库、模型管理和 Agent 策略都打通了。对于简历筛选这种需要“既有固定流程、又要调用大模型做理解和判断”的场景Dify 不需要我在多个系统之间来回搬数据一个工作流就能串完整条链路。1.2 工作流和 Agent 模式到底怎么选Dify 里有两套应用模式工作流Workflow和 Agent。很多人刚上手时会纠结其实判断标准很简单这个业务过程的步骤是不是固定的如果步骤固定、每个环节的输入输出明确就用工作流。比如简历筛选流程就是“接收简历 → 抽取信息 → 按评分规则打分 → 输出结构化结果”每一步都是确定的用 Agent 反而浪费。Agent 适合的是“需要动态规划工具调用”的场景比如“帮我查一下最近三个月的销售数据分析异常并生成报告”模型需要自己决定先调哪个工具、按什么顺序调。这种灵活性是有代价的token 消耗不可控、结果不稳定、也不好做精细的权限控制。我见过不少同学一上来就选 Agent结果发现流程经常“飘”。如果你要的是确定性的业务结果老老实实用工作流。简历筛选这件事我要的就是每次输出格式一致、打分逻辑透明所以工作流是唯一正解。1.3 工作流的适用边界Dify 工作流不是万能的我实操下来觉得它最适合的是“有明确规则、但有部分环节需要 AI 判断”的场景。比如工单分类、内容审核初筛、文档信息抽取、客服话术生成这些场景里 AI 负责理解和生成规则引擎负责分支判断两者配合得很舒服。反过来如果流程本身需要大量人工审批、长时间等待、跨系统复杂事务那工作流就不太合适应该交给 BPM 类系统去管。Dify 擅长的是“智能决策链路”不是“业务流程引擎”这个定位想清楚后面很多设计决策就不会跑偏。2. 部署环境把平台跑起来2.1 一次搞定 Docker Compose 部署Dify 的本地部署是我用过的开源项目里最省心的之一官方提供了完整的 Docker Compose 编排。环境要求其实不高2 核 4G 的服务器能跑起来但生产环境我建议至少 4 核 8G因为知识库的 embedding 计算和模型调用都比较吃资源。部署流程分四步。第一步拉取代码仓库git clone https://github.com/langgenius/dify.git cd dify/docker第二步复制环境变量模板cp .env.example .env第三步根据实际情况调整 .env 里的关键配置。我最常改的是这几个EXPOSE_NGINX_PORT决定外部访问端口默认 80 和 443POSTGRES_PASSWORD和REDIS_PASSWORD建议改掉默认值如果服务器在国外MILVUS或QDrant的镜像源可以保持默认国内则建议配上镜像加速。第四步启动并初始化docker compose up -d启动完成后访问http://服务器IP/install设置管理员账号就能进入 Dify 控制台了。注意Dify 依赖 PostgreSQL、Redis、向量数据库默认 Weaviate 或 Qdrant等中间件首次启动拉取镜像需要一点时间。如果中途失败多半是网络问题配置镜像加速后重试即可。2.2 版本选择与升级避坑Dify 的发版节奏比较快新功能经常跟着社区版本一起出。像 1.10 版本开始支持多租户对团队协作来说很实用。但我的建议是不要追最新等一个 patch 版本再升。升级踩坑是我自己亲身经历过的。有一次图省事没备份数据库直接docker compose pull docker compose up -d结果新版本迁移脚本执行到一半报错了。虽然最后恢复了但那会儿冷汗都下来了。安全升级三步走# 第一步备份数据库 docker compose exec db pg_dump -U postgres dify dify_backup_$(date %Y%m%d).sql # 第二步备份 .env 并对比新旧差异 cp .env .env.bak git pull origin main # 第三步拉新镜像并重建服务 docker compose pull docker compose up -d还有一个容易被忽略的点新版发布后工作流 DSL 的 schema 可能变更。如果你在旧版本导出的 DSL 文件拿到新版导入时提示兼容性问题不用慌按提示重新校验一下节点参数就行。团队多人协作时最好统一锁定版本避免有人用新版本导出、有人用旧版本导入导致工作流文件对不上。3. 案例实操搭建简历筛选工作流3.1 需求拆解与节点规划我搭的简历筛选工作流业务需求是这样的HR 把简历文本和岗位要求粘进表单工作流自动抽取候选人信息、按匹配度打分最后输出一份结构化的筛选报告包含“推荐面试 / 待定 / 淘汰”三个结论。在 Dify 里我先把流程拆成六个节点节点类型作用关键输入关键输出开始开始接收用户输入resume_text, jd_textraw_text, jd_text信息抽取LLM从简历中抽取结构化数据raw_textcandidate_infoJSON知识检索知识检索从岗位 JD 库中召回相关要求jd_text 关键词jd_documents匹配评分LLM按 JD 要求对候选人打分candidate_info, jd_documentsscore_result条件分支条件分支按评分归类score_result.score分支结果模板转换模板转换生成最终报告文案各节点输出report这个节点规划的思路是把“抽取”和“判断”分开。抽取环节只做信息识别不做评价匹配评分才调用大模型做综合判断。这样做的优势是后续如果换评分模型或者调整判断规则不需要改动抽取逻辑维护成本低很多。3.2 关键节点配置细节开始节点的配置比较简单定义好输入变量名和类型就行。我定义了两个文本字段resume_text和jd_text都是必填。最有技术含量的是 LLM 节点的 Prompt 设计。信息抽取节点的 Prompt 我这么写的你是一名资深 HR 助理请从简历文本中抽取以下信息并严格以 JSON 格式输出 - name: 候选人姓名 - years_experience: 工作年限数字 - skills: 技能列表数组 - education: 最高学历 - recent_companies: 最近三段工作经历的公司名 - project_experience: 项目经历摘要200字以内 简历文本 {{#node.start.resume_text#}} 注意只输出 JSON不要输出任何解释文字。评分节点的 Prompt 更关键因为直接决定输出质量你是技术团队的技术面试官。请根据岗位要求评估候选人的匹配度。 岗位要求 {{#node.knowledge_retrieval.jd_documents#}} 候选人信息 {{#node.llm.candidate_info#}} 请从技能匹配度、经验年限、项目相关性三个维度分别打分1-10 并计算综合评分加权平均技能匹配度权重50%经验年限权重20%项目相关性权重30%。 最终以 JSON 输出 {skill_score: 0, exp_score: 0, project_score: 0, total_score: 0, comment: 简短评语}这里有个实操心得LLM 节点的输出一定要指定 JSON 格式并且字段名要稳定。我最初没强调格式结果模型时而出 JSON 时而出一段话条件分支那边经常解析失败。后来在 Prompt 里加了“只输出 JSON不要解释”并配上了 Dify 的“参数提取”校验问题就解决了。条件分支节点我按评分结果分了三个出口total_score 7走“推荐面试”4 total_score 7走“待定” 4走“淘汰”。注意这里有个容易踩的坑LLM 输出的字段类型是字符串还是数字取决于你的参数提取设置。如果类型不匹配条件判断永远走不到预期分支。我建议在 LLM 节点后面加一个“代码节点”用 Python 做一次强制类型转换再从转换结果里取total_score。模板转换节点则负责把各节点的结果拼成一段可读的报告文本比如候选人 {{#node.llm.candidate_info.name#}} 的综合评分为 {{#node.code.total_score#}} 分。 技能匹配度{{#node.code.skill_score#}} / 10 经验匹配度{{#node.code.exp_score#}} / 10 项目匹配度{{#node.code.project_score#}} / 10 结论{{#node.ifelse.result#}} 评语{{#node.llm.score_result.comment#}}最终结束节点把 report 输出给调用方整个工作流就闭环了。3.3 测试验证与发布Dify 工作流页面提供了“单次运行”调试功能这是我最常用的调试工具。在开始节点填入一份测试简历和岗位要求运行后能看到每个节点的输入输出哪一步出了问题一目了然。测试用例我建议备三份一份高匹配简历、一份中等匹配、一份完全不匹配。用高匹配简历验证打分逻辑是否合理用中等匹配验证条件分支的边界值用完全不匹配的简历验证是否会被错误地放进“推荐”分支。我实际调试时踩过一个典型的坑第一次跑高匹配简历时评分模型的输出里total_score是8.5条件分支判断 7没问题但当我把阈值改成 7.0后分支就失效了。排查半天发现是参数提取出来的字段类型变成了字符串8.5字符串和数字比较的结果和预期完全不同。所以我在评分节点后面加了一段 Python 代码做转换def main(score_result: str) - dict: import json data json.loads(score_result) if isinstance(score_result, str) else score_result total float(data.get(total_score, 0)) skill float(data.get(skill_score, 0)) exp float(data.get(exp_score, 0)) proj float(data.get(project_score, 0)) return { total_score: total, skill_score: skill, exp_score: exp, project_score: proj }调试通过后点击“发布”按钮生成一个新版本。Dify 支持维护多个版本线上出问题时可以快速回滚到上一个稳定版本这个机制对生产环境很重要。发布之后应用管理后台会生成一个 API 调用地址外部系统可以通过 HTTP 请求调用这个工作流HR 那边我用的是一个简单的表单页面提交后自动调 API 拿结果。4. 知识库接入与问题排查实录4.1 知识库搭建与检索调优简历筛选工作流里知识检索节点是从公司岗位 JD 库里召回相关要求。这一步不是必须的但加上之后效果差异很明显。因为有些岗位要求散落在历史 JD 文档里光靠用户在表单里填的一段jd_text不够完整知识库能补全这些上下文。Dify 的知识库搭建流程不复杂创建知识库、上传文档、选择分段模式、设置 embedding 模型、索引完成后就可以被工作流引用。但有几个细节值得注意。分段长度直接影响检索效果我实测下来 500 字左右一段对 JD 这种半结构化文本比较合适太长会把多个岗位的要求混在一起太短又容易切碎上下文。检索模式上向量检索适合语义匹配全文检索适合关键词匹配混合检索最稳但会稍微增加延迟。对于 JD 库这种场景我用的混合检索TopK 设为 5Score 阈值 0.3召回的内容基本都挺准。另外要提醒一点知识库的 embedding 模型选择要跟工作流里的模型解耦。也就是说知识库的向量化用一套模型工作流的对话模型可以单独配置。如果你后续换模型只需要重新索引知识库不用动工作流本身的逻辑。4.2 高频报错与排查速查整个项目跑下来我遇到的坑不少整理成一张速查表都是新手最容易碰到的现象可能原因解决方案运行时报“请安装缺失的包以使用此工作流”导入的 DSL 引用了未安装的插件或自定义节点到插件市场安装对应插件或者打开 DSL 看 missing nodes 提示变量一直显示为空上游节点输出变量名写错或节点未执行成功在调试面板逐个节点查看输出确认变量路径条件分支走不到预期分支变量类型不匹配字符串和数字比大小加代码节点做类型转换调试面板打印 type 确认知识库显示“同步数据中”文档还没完成分段和 embedding等待索引完成长时间不动就检查 embedding 模型配置模型调用超时模型服务响应慢或 Prompt 过长换响应更快的模型精简 Prompt设置合理的超时时间工作流导入了但模型配置丢失不同环境模型 Provider 不一致导入后检查每个节点的模型配置重新选择对应模型这里我最想强调的还是那个“缺失包”的报错。很多人一看到这个提示就懵了以为是 Python 环境问题。其实在 Dify 里这通常意味着你导入了一个在其他团队/环境里创建的 DSL 文件而当前环境没有安装对应的插件节点。解决办法是去插件市场搜索并安装而不是真的去折腾 Python 包。另外“知识库同步数据中”也是一个容易让人焦虑的提示。尤其是文档较多时embedding 需要排队处理耐心等几分钟就好。如果一直卡住检查一下 API Key 是否有效、模型是否可用这种问题多半出在模型服务异常上。4.3 一个容易被忽略的性能优化工作流跑久了你会发现响应速度的瓶颈往往不在模型本身而在“串行等待”。简历筛选这个场景信息抽取和匹配评分本来有依赖关系必须串行这没办法但我曾经在处理批量简历时把“读取下一条数据”和“调用模型”也写成了串行导致 50 份简历要跑十几分钟。后来我改用 Dify 的“批次处理”思路把数据分片后用多个并发实例跑同一个工作流再汇总结果时间降到了三分钟以内。虽然 Dify 工作流本身不直接提供高并发编排但你可以通过外部程序调用 API 做并发效果很明显。这个优化思路在很多文档处理类的场景里都通用。这次从选型到落地我的体会是Dify 工作流的核心价值不是“把流程画出来”而是“把流程变成可维护、可测试、可解释的智能服务”。简历筛选只是一个起点同样的模式换到工单分类、文档抽取、客服摘要上都成立关键是设计时把抽取、判断、分支这些环节拆干净。最后再分享一个小技巧工作流里的每个 LLM 节点都建议在 Prompt 里带上“输出格式严格要求”这一段并且用参数提取节点做结构化校验。这一个小动作能帮你省掉大量调试时间生产环境跑起来也稳得多。本文还有配套的精品资源点击获取