你有没有过这样的经历想用AI做个能自动处理任务的小助手比如自动整理会议纪要、批量处理文档、或者搭建一个能回答内部知识库问题的智能客服但一上手就发现要么得写一堆代码要么得研究复杂的框架要么好不容易调通了Prompt却不知道怎么把它变成一个稳定、可复用的服务。这其实是一个很典型的困境我们手里有强大的大模型也有清晰的业务需求但中间那条“从想法到落地”的路却布满了技术门槛和工程陷阱。很多人卡在了这里要么停留在手动复制粘贴Prompt的原始阶段要么被复杂的部署和运维劝退。最近一个叫Dify的平台开始被频繁提起。它被描述为一个“开源的LLM应用开发平台”主打“可视化”和“低代码”。听起来很美好但一个零基础的新手真的能在两小时内用它做出一个可用的AI智能体Agent吗更重要的是从一次性的Prompt测试到一个能稳定运行、可以集成到业务里的“企业级项目”这条路到底该怎么走我的判断是Dify的真正价值不在于让你“学会”Agent开发而在于它提供了一套标准化的“工作流”容器让你能把那些零散的、手动的AI交互过程沉淀为可配置、可复用、可监控的自动化流程。它降低的不是AI本身的理解门槛而是工程化和产品化的门槛。这篇文章我们就来彻底拆解这个过程。我不会只告诉你怎么点按钮而是会带你理解如何用Dify的思维从零搭建一个属于你自己的AI工作流。我们会走过从环境准备、Prompt调试到构建复杂Agent逻辑最终考虑生产部署的完整路径。你会发现所谓的“企业级”核心在于对流程、状态和异常的处理而Dify恰好把这些复杂的东西封装成了可视化的模块。1. 重新理解Dify它不是一个“玩具”而是一个“流程引擎”很多人第一次打开Dify会被它类似“绘图”的界面吸引拖拖拽拽就能连出一个AI应用感觉很神奇。但如果只停留在这一步你很可能只会用它做出一些“演示Demo”一旦遇到真实场景就会感觉处处受限。我们需要先跳出来理解Dify到底在解决什么问题。1.1 从“一次对话”到“一个流程”在没有Dify这类工具之前我们怎么用大模型通常是这样打开ChatGPT网页或API调试工具。精心编写一段Prompt提示词。发送请求等待回复。如果结果不满意手动修改Prompt再试一次。如果任务复杂比如需要联网搜索、查数据库、执行计算我们需要自己写代码来串联这些步骤。这个过程是线性的、手动的、状态不连续的。每一次交互都是独立的很难把上一次的结果自动作为下一次的输入更难以处理分支判断、循环和异常。Dify引入的核心概念是“工作流Workflow”。它把一次AI交互拆解成多个可连接的“节点”Node。每个节点负责一个特定任务比如输入节点接收用户问题或外部数据。LLM节点调用大模型执行核心的推理和生成。知识库节点从你上传的文档中检索相关信息。代码节点执行一段Python代码来处理数据。判断节点根据条件决定流程走向。输出节点整理并返回最终结果。通过可视化连接这些节点你实际上是在设计一个处理数据的自动化管道。用户输入从一端进入经过一系列加工、判断、AI调用最终从另一端输出结果。这不再是“一次对话”而是一个可重复执行的程序。1.2 “低代码”背后是标准化的AI能力封装Dify的“低代码”或“无代码”特性容易让人误解为功能弱小。恰恰相反它的强大在于对复杂能力的标准化封装。举个例子你想让AI助手能回答关于公司内部产品文档的问题。传统方式你需要学习向量数据库如Chroma、Milvus的概念和API。写代码把文档切块、转换成向量、存入数据库。写代码实现检索逻辑在用户提问时找到相关片段。写代码把检索结果拼接成Prompt发给大模型。处理可能出现的检索失败、Token超限等问题。在Dify里你只需要在“知识库”模块上传你的文档支持txt、pdf、word、ppt等。在工作流中拖入一个“知识库检索”节点并选择对应的知识库。把这个节点的输出连接到LLM节点的“上下文”输入。Dify后台自动帮你完成了文档处理、向量化、存储、检索和上下文组装的整个技术栈。你无需关心用的是哪种嵌入模型分块策略是什么它提供了一个“开箱即用”的知识问答能力。同样对于联网搜索、文本摘要、关键词提取等常见功能Dify都将其封装成了独立的节点。你的开发工作从“写底层代码”变成了“选择和组装标准化组件”。1.3 为什么是“企业级”的基石企业级应用关注什么稳定性、可维护性、可监控、安全性。稳定性Dify的工作流定义了确定的处理路径避免了人工操作的不确定性。你可以为关键节点设置重试机制。可维护性可视化流程一目了然新同事也能快速理解业务逻辑。修改时只需调整对应节点或连接线无需深入代码海。可监控Dify提供了应用日志、对话历史、Token消耗统计。你可以清晰地看到每一次请求走了哪个分支调用了哪些模型消耗了多少资源。安全性你可以集中管理API密钥控制不同应用的模型访问权限。知识库的文档权限也可以进行配置。因此当我们在Dify中构建一个应用时我们不仅在做一个功能更是在搭建一个符合工程规范的服务雏形。这是它区别于简单Prompt调试工具的核心价值。2. 两小时入门实战从零构建一个“智能会议纪要生成器”理论说了这么多我们动手做一个东西。目标创建一个AI应用它能够接收一段冗长的会议录音转文字稿自动生成结构清晰的会议纪要包括会议主题、参会人、讨论要点、决策事项和待办任务。我们将在Dify Cloud在线版上完成无需安装最快体验核心流程。2.1 第一步环境与准备15分钟注册与登录访问Dify官网使用邮箱或GitHub账号注册。登录后会进入控制台。模型配置这是最关键的一步。在左侧菜单进入“模型供应商”设置。Dify支持众多模型包括OpenAI GPT系列、Anthropic Claude、国内的通义千问、智谱GLM等。对于初学者建议先使用OpenAI的GPT-3.5-Turbo。你需要一个OpenAI API Key在OpenAI平台申请。在Dify中填入API Key并保存。关键理解Dify本身不提供模型它是模型的“调度器”和“增强器”。你配置的模型就是工作流中LLM节点的大脑。创建应用在控制台点击“创建新应用”选择“工作流”类型这是最强大的模式给它起个名字比如“智能会议纪要助手”。2.2 第二步设计工作流骨架30分钟进入工作流画布你会看到一个空的起点Start和终点End。我们的目标是设计这样一个流程[会议文本输入] - [文本预处理可选] - [LLM分析并生成结构化纪要] - [结果输出]但我们可以做得更智能一点比如让AI先判断文本是否真的是会议记录。添加输入节点从左侧面板拖入一个“文本输入”节点连接到Start节点。将其重命名为“用户输入-会议文本”。在节点设置中可以写一段描述如“请输入完整的会议录音转文字内容”。添加第一个LLM节点判断拖入一个“LLM”节点。将其重命名为“判断文本类型”。连接将“用户输入”节点的输出连接到这个LLM节点的“输入”端口。配置Prompt这是核心。在节点的“提示词”框中写入你是一个文本分析助手。请判断用户提供的文本内容是否属于“会议记录”或“会议讨论”的范畴。 文本内容{{input}} !-- 这是一个变量会自动注入上一个节点的输出 -- 请只输出一个单词是 或 否。 如果是请同时用一句话概括会议核心主题。 输出格式 判断结果[是/否] 主题概括[一句话概括若无则写“无”]选择模型在下方选择你配置好的模型如gpt-3.5-turbo。理解变量{{input}}是Dify的模板语法代表上游节点的输出。这实现了数据在流程中的自动传递。添加条件判断节点拖入一个“条件判断”节点。将其重命名为“根据判断分流”。连接将“判断文本类型”节点的输出连接到本节点的输入。配置条件我们需要解析上一个LLM的输出。假设LLM严格按照我们要求的格式输出。我们可以配置条件为分支1是如果{{判断文本类型.output}}包含判断结果是分支2否其他情况技巧这里依赖LLM的稳定输出。在生产环境中可能需要更稳健的解析方式如用代码节点处理JSON但为了快速入门我们相信Prompt的约束力。2.3 第三步构建核心处理流程45分钟现在我们为“是”的分支添加真正的纪要生成逻辑。添加第二个LLM节点生成纪要从“条件判断”节点的“是”分支连接一个新的“LLM”节点重命名为“生成会议纪要”。配置高级Prompt在这个节点的提示词中我们要给出更详细的指令和结构。你是一名专业的会议秘书请根据以下会议讨论文本生成一份格式规范、内容完整的会议纪要。 【会议文本】 {{用户输入-会议文本.output}} 【生成要求】 1. 提取会议主题。 2. 提取参会人员如果文本中有提及。 3. 总结核心讨论要点分条列出。 4. 明确记录达成的决策或结论。 5. 列出明确的待办任务Action Items每项需包含负责人如可推断和截止时间如可推断。 6. 使用Markdown格式输出确保结构清晰。 【输出格式】 # 会议纪要 **会议主题** [主题] **会议时间** [根据文本推断若无则写“待补充”] **参会人员** [人员列表] ## 一、核心讨论要点 - [要点1] - [要点2] ... ## 二、达成决策 - [决策1] - [决策2] ... ## 三、待办任务 | 任务内容 | 负责人 | 截止时间 | 备注 | |---|---|---|---| | [任务1] | [人名] | [时间] | | | [任务2] | [人名] | [时间] | |关键点我们使用了更具体的指令、分步骤的要求和明确的格式Markdown表格。这能极大提升大模型输出的稳定性和质量。处理“否”的分支从“条件判断”节点的“否”分支连接一个“文本”节点。在这个节点里直接写一段固定回复例如“您输入的内容似乎不是会议记录。请提供会议讨论相关的文本以便我为您生成纪要。”汇总输出现在我们有两条路径路径A是“生成会议纪要”节点 - 需要连接到输出。路径B否“文本”节点 - 需要连接到输出。拖入一个“答案”节点重命名为“最终输出”。将“生成会议纪要”节点和“文本”节点的输出都连接到这个“最终输出”节点。注意Dify的工作流引擎足够智能同一时间只有一条活跃路径因此不会冲突。2.4 第四步测试、调试与发布30分钟运行测试点击画布右上角的“预览”按钮。在右侧的调试面板中在“用户输入-会议文本”的测试框里粘贴一段真实的会议文字记录可以从网上找一段样例。点击“运行”。观察流程你会看到流程线依次亮起数据流经每个节点。可以在每个节点上点击查看其输入和输出这是调试的黄金时刻。如果LLM输出格式不符合预期回到节点修改Prompt。迭代优化第一次结果往往不完美。常见的优化点主题概括不准调整第一个判断LLM的Prompt让它更严格。待办任务提取不全在第二个LLM的Prompt中强调“仔细扫描文本中所有带有‘需要’、‘负责’、‘截止’等关键词的句子”。输出格式混乱在Prompt中更加强调“严格使用指定的Markdown格式”。发布应用调试满意后点击右上角“发布”。发布后这个工作流就变成了一个可访问的Web应用。你可以分享链接给同事他们就可以直接使用了。至此一个具备基础逻辑判断能力的AI应用就完成了。两小时内你体验了从模型配置、流程设计、Prompt编写、条件分支到调试发布的全过程。这已经超越了一次性的Chat对话成为了一个可重复使用的工具。3. 从Demo到项目赋予工作流“智能体Agent”能力上面我们构建的是一个“静态”工作流流程固定LLM只被调用一次或两次。而“智能体”Agent的核心特征是自主决策和工具调用。在Dify中我们可以通过集成“工具”和设计更复杂的循环逻辑来模拟Agent行为。让我们升级会议纪要助手让它成为一个真正的“会议秘书Agent”不仅能总结还能在发现待办任务缺少截止时间时主动提问补全。3.1 引入“工具”扩展边界Dify的“工具”功能允许工作流调用外部能力。我们给Agent装上“耳朵”和“手”。知识库工具在“知识库”模块上传公司的《项目管理制度.pdf》。然后在工作流中可以在LLM节点前插入一个“知识库检索”节点。这样LLM在生成纪要或提取待办时就能参考公司制度里关于任务时限的规定使输出更合规。HTTP请求工具假设公司使用Jira进行任务管理。我们可以配置一个HTTP工具节点当纪要生成后自动将提取出的待办任务创建为Jira Issue。这需要你编写API调用逻辑但Dify提供了可视化的配置界面来设置请求头、参数和解析响应。3.2 设计交互式循环让Agent学会追问这是实现Agent“智能”的关键。我们修改流程解析待办任务在“生成会议纪要”节点后不直接输出。而是连接一个“代码”节点Python。在这个节点里编写脚本解析上一步LLM输出的Markdown表格提取出“待办任务”部分并检查每个任务是否包含“截止时间”。将任务列表和缺失时间的任务列表作为输出。条件判断连接一个“条件判断”节点。判断条件是{{代码节点.output.缺失任务列表}}是否为空。追问分支循环如果缺失时间进入追问分支。连接一个“LLM”节点Prompt设计为“用户刚才召开了会议我们提取出以下待办任务但缺少截止时间{{缺失任务列表}}。请你以会议秘书的身份生成一个问题向用户逐一询问这些任务的期望截止时间。问题要友好、清晰。”将这个LLM节点的输出连接回“最终输出”节点但这是一个中间输出。同时我们需要设计一种机制让用户的下一次输入即回答的截止时间能够被流程接收并更新到任务列表中。这涉及到“多轮对话”和“状态保持”。在更复杂的Dify工作流中你可以使用“变量”来存储中间状态如任务列表并在新一轮对话中读取和修改它。这需要更精细的设计超出了入门范围但展示了Agent的交互潜力。完成分支如果没有缺失时间则直接连接“最终输出”节点呈现完整的会议纪要。通过这个设计你的应用从一个“单向处理器”变成了一个“交互式助手”。它能分析结果的完整性发现缺失信息并主动发起追问来补全。这就是Agent思维的体现感知-分析-决策-行动或提问。3.3 复杂工作流的设计原则当节点增多、逻辑变复杂时需要遵循一些原则来保持清晰模块化将大流程拆分成子流程。例如将“提取并分析待办任务”封装成一个可复用的子工作流。命名清晰每个节点都应有描述其功能的名称如“解析MD表格-提取任务”而非“代码节点1”。善用变量在节点间传递复杂数据时使用结构化的变量而不是依赖纯文本解析。日志与调试在关键节点后添加“日志”节点输出中间结果便于排查问题。4. 走向“企业级”部署、集成与运维考量一个在Dify Cloud上跑通的Demo和公司内网一个每天处理几百次请求的稳定服务中间还有很长的路。这就是“企业级项目实战”要解决的问题。4.1 部署方式选择云服务 vs. 本地化Dify Cloud在线版优点免运维开箱即用适合快速原型验证、小型团队或对外公开的服务。缺点数据经过第三方服务器对数据安全有严格要求的内部场景不适用性能、自定义程度和模型支持受平台限制。本地部署优点数据完全自主可控可以部署在内网环境可以自定义所有配置集成内部模型和工具性能取决于自有服务器。缺点需要一定的运维能力Docker、服务器管理。方法Dify提供了完善的Docker Compose部署方案。你需要准备一台Linux服务器安装Docker和Docker Compose然后按照官方文档克隆代码库配置环境变量如数据库密码、API密钥一条命令即可启动所有服务前端、后端、数据库等。4.2 生产环境关键配置如果你选择本地部署以下几项是关键模型管理生产环境通常不会直接使用OpenAI的公有API。你需要部署本地模型集成Ollama、LocalAI、vLLM等框架部署开源模型如Qwen、Llama、GLM。配置模型网关对于商业API或混合云模型Dify支持配置多个供应商和模型并设置优先级、限流和负载均衡。知识库优化生产级知识库面临海量文档。索引性能选择高性能的向量数据库后端如PGVector与PostgreSQL集成或Qdrant。数据处理建立文档更新和同步机制确保知识库内容最新。检索质量调整文本分割策略、向量化模型和检索相似度阈值平衡召回率和精度。安全与权限API密钥管理切勿在前端代码或配置文件中硬编码密钥。使用环境变量或密钥管理服务。访问控制Dify企业版支持更细粒度的团队和角色权限管理。社区版可通过反向代理如Nginx配置基础认证。审计日志确保所有API调用、知识库操作都有记录可查。性能与监控缓存策略对频繁且结果固定的查询如某些知识库问答引入缓存减少LLM调用和Token消耗。监控告警监控服务器资源CPU、内存、Dify服务状态、API调用失败率和Token消耗趋势。设置告警阈值。版本管理对工作流进行版本控制。修改生产环境的工作流前先在测试环境充分验证。4.3 与现有系统集成Dify应用不是孤岛它需要融入企业IT生态。作为API服务Dify发布的每个应用都自动提供标准的API接口。你的业务系统如OA、CRM可以通过HTTP调用这些API将AI能力嵌入现有流程。通过Webhook触发工作流可以配置Webhook输入节点监听外部系统的事件如GitHub提交、表单提交、客服工单创建实现自动化触发。嵌入网站或聊天工具Dify应用可以以Chatbot插件的形式嵌入到公司官网或内部Slack、飞书、钉钉等平台。从Prompt到企业级项目真正的挑战往往不在AI模型本身而在于如何将AI能力工程化、产品化、服务化。Dify通过可视化工作流这个抽象极大地压缩了从想法到可运行服务之间的路径。它让你能聚焦于业务逻辑和Prompt优化而不是陷入基础设施的泥潭。对于初学者我的建议是不要追求一步到位的复杂Agent。从解决一个具体的、微小的问题开始比如我们的会议纪要生成用Dify把它跑通。然后再思考如何为它添加“工具”如查知识库如何让它具备“判断”能力如检查信息完整性最后再考虑如何让它“主动”行动如创建任务。每一步的进阶都对应着你对工作流、节点和AI协作模式更深一层的理解。当你能够熟练地使用Dify将一个个模糊的AI想法变成稳定、可视、可共享的自动化流程时你就已经掌握了这个时代一项极具价值的能力——将智能转化为生产力。
两小时用Dify构建企业级AI工作流：从Prompt到智能体实战
你有没有过这样的经历想用AI做个能自动处理任务的小助手比如自动整理会议纪要、批量处理文档、或者搭建一个能回答内部知识库问题的智能客服但一上手就发现要么得写一堆代码要么得研究复杂的框架要么好不容易调通了Prompt却不知道怎么把它变成一个稳定、可复用的服务。这其实是一个很典型的困境我们手里有强大的大模型也有清晰的业务需求但中间那条“从想法到落地”的路却布满了技术门槛和工程陷阱。很多人卡在了这里要么停留在手动复制粘贴Prompt的原始阶段要么被复杂的部署和运维劝退。最近一个叫Dify的平台开始被频繁提起。它被描述为一个“开源的LLM应用开发平台”主打“可视化”和“低代码”。听起来很美好但一个零基础的新手真的能在两小时内用它做出一个可用的AI智能体Agent吗更重要的是从一次性的Prompt测试到一个能稳定运行、可以集成到业务里的“企业级项目”这条路到底该怎么走我的判断是Dify的真正价值不在于让你“学会”Agent开发而在于它提供了一套标准化的“工作流”容器让你能把那些零散的、手动的AI交互过程沉淀为可配置、可复用、可监控的自动化流程。它降低的不是AI本身的理解门槛而是工程化和产品化的门槛。这篇文章我们就来彻底拆解这个过程。我不会只告诉你怎么点按钮而是会带你理解如何用Dify的思维从零搭建一个属于你自己的AI工作流。我们会走过从环境准备、Prompt调试到构建复杂Agent逻辑最终考虑生产部署的完整路径。你会发现所谓的“企业级”核心在于对流程、状态和异常的处理而Dify恰好把这些复杂的东西封装成了可视化的模块。1. 重新理解Dify它不是一个“玩具”而是一个“流程引擎”很多人第一次打开Dify会被它类似“绘图”的界面吸引拖拖拽拽就能连出一个AI应用感觉很神奇。但如果只停留在这一步你很可能只会用它做出一些“演示Demo”一旦遇到真实场景就会感觉处处受限。我们需要先跳出来理解Dify到底在解决什么问题。1.1 从“一次对话”到“一个流程”在没有Dify这类工具之前我们怎么用大模型通常是这样打开ChatGPT网页或API调试工具。精心编写一段Prompt提示词。发送请求等待回复。如果结果不满意手动修改Prompt再试一次。如果任务复杂比如需要联网搜索、查数据库、执行计算我们需要自己写代码来串联这些步骤。这个过程是线性的、手动的、状态不连续的。每一次交互都是独立的很难把上一次的结果自动作为下一次的输入更难以处理分支判断、循环和异常。Dify引入的核心概念是“工作流Workflow”。它把一次AI交互拆解成多个可连接的“节点”Node。每个节点负责一个特定任务比如输入节点接收用户问题或外部数据。LLM节点调用大模型执行核心的推理和生成。知识库节点从你上传的文档中检索相关信息。代码节点执行一段Python代码来处理数据。判断节点根据条件决定流程走向。输出节点整理并返回最终结果。通过可视化连接这些节点你实际上是在设计一个处理数据的自动化管道。用户输入从一端进入经过一系列加工、判断、AI调用最终从另一端输出结果。这不再是“一次对话”而是一个可重复执行的程序。1.2 “低代码”背后是标准化的AI能力封装Dify的“低代码”或“无代码”特性容易让人误解为功能弱小。恰恰相反它的强大在于对复杂能力的标准化封装。举个例子你想让AI助手能回答关于公司内部产品文档的问题。传统方式你需要学习向量数据库如Chroma、Milvus的概念和API。写代码把文档切块、转换成向量、存入数据库。写代码实现检索逻辑在用户提问时找到相关片段。写代码把检索结果拼接成Prompt发给大模型。处理可能出现的检索失败、Token超限等问题。在Dify里你只需要在“知识库”模块上传你的文档支持txt、pdf、word、ppt等。在工作流中拖入一个“知识库检索”节点并选择对应的知识库。把这个节点的输出连接到LLM节点的“上下文”输入。Dify后台自动帮你完成了文档处理、向量化、存储、检索和上下文组装的整个技术栈。你无需关心用的是哪种嵌入模型分块策略是什么它提供了一个“开箱即用”的知识问答能力。同样对于联网搜索、文本摘要、关键词提取等常见功能Dify都将其封装成了独立的节点。你的开发工作从“写底层代码”变成了“选择和组装标准化组件”。1.3 为什么是“企业级”的基石企业级应用关注什么稳定性、可维护性、可监控、安全性。稳定性Dify的工作流定义了确定的处理路径避免了人工操作的不确定性。你可以为关键节点设置重试机制。可维护性可视化流程一目了然新同事也能快速理解业务逻辑。修改时只需调整对应节点或连接线无需深入代码海。可监控Dify提供了应用日志、对话历史、Token消耗统计。你可以清晰地看到每一次请求走了哪个分支调用了哪些模型消耗了多少资源。安全性你可以集中管理API密钥控制不同应用的模型访问权限。知识库的文档权限也可以进行配置。因此当我们在Dify中构建一个应用时我们不仅在做一个功能更是在搭建一个符合工程规范的服务雏形。这是它区别于简单Prompt调试工具的核心价值。2. 两小时入门实战从零构建一个“智能会议纪要生成器”理论说了这么多我们动手做一个东西。目标创建一个AI应用它能够接收一段冗长的会议录音转文字稿自动生成结构清晰的会议纪要包括会议主题、参会人、讨论要点、决策事项和待办任务。我们将在Dify Cloud在线版上完成无需安装最快体验核心流程。2.1 第一步环境与准备15分钟注册与登录访问Dify官网使用邮箱或GitHub账号注册。登录后会进入控制台。模型配置这是最关键的一步。在左侧菜单进入“模型供应商”设置。Dify支持众多模型包括OpenAI GPT系列、Anthropic Claude、国内的通义千问、智谱GLM等。对于初学者建议先使用OpenAI的GPT-3.5-Turbo。你需要一个OpenAI API Key在OpenAI平台申请。在Dify中填入API Key并保存。关键理解Dify本身不提供模型它是模型的“调度器”和“增强器”。你配置的模型就是工作流中LLM节点的大脑。创建应用在控制台点击“创建新应用”选择“工作流”类型这是最强大的模式给它起个名字比如“智能会议纪要助手”。2.2 第二步设计工作流骨架30分钟进入工作流画布你会看到一个空的起点Start和终点End。我们的目标是设计这样一个流程[会议文本输入] - [文本预处理可选] - [LLM分析并生成结构化纪要] - [结果输出]但我们可以做得更智能一点比如让AI先判断文本是否真的是会议记录。添加输入节点从左侧面板拖入一个“文本输入”节点连接到Start节点。将其重命名为“用户输入-会议文本”。在节点设置中可以写一段描述如“请输入完整的会议录音转文字内容”。添加第一个LLM节点判断拖入一个“LLM”节点。将其重命名为“判断文本类型”。连接将“用户输入”节点的输出连接到这个LLM节点的“输入”端口。配置Prompt这是核心。在节点的“提示词”框中写入你是一个文本分析助手。请判断用户提供的文本内容是否属于“会议记录”或“会议讨论”的范畴。 文本内容{{input}} !-- 这是一个变量会自动注入上一个节点的输出 -- 请只输出一个单词是 或 否。 如果是请同时用一句话概括会议核心主题。 输出格式 判断结果[是/否] 主题概括[一句话概括若无则写“无”]选择模型在下方选择你配置好的模型如gpt-3.5-turbo。理解变量{{input}}是Dify的模板语法代表上游节点的输出。这实现了数据在流程中的自动传递。添加条件判断节点拖入一个“条件判断”节点。将其重命名为“根据判断分流”。连接将“判断文本类型”节点的输出连接到本节点的输入。配置条件我们需要解析上一个LLM的输出。假设LLM严格按照我们要求的格式输出。我们可以配置条件为分支1是如果{{判断文本类型.output}}包含判断结果是分支2否其他情况技巧这里依赖LLM的稳定输出。在生产环境中可能需要更稳健的解析方式如用代码节点处理JSON但为了快速入门我们相信Prompt的约束力。2.3 第三步构建核心处理流程45分钟现在我们为“是”的分支添加真正的纪要生成逻辑。添加第二个LLM节点生成纪要从“条件判断”节点的“是”分支连接一个新的“LLM”节点重命名为“生成会议纪要”。配置高级Prompt在这个节点的提示词中我们要给出更详细的指令和结构。你是一名专业的会议秘书请根据以下会议讨论文本生成一份格式规范、内容完整的会议纪要。 【会议文本】 {{用户输入-会议文本.output}} 【生成要求】 1. 提取会议主题。 2. 提取参会人员如果文本中有提及。 3. 总结核心讨论要点分条列出。 4. 明确记录达成的决策或结论。 5. 列出明确的待办任务Action Items每项需包含负责人如可推断和截止时间如可推断。 6. 使用Markdown格式输出确保结构清晰。 【输出格式】 # 会议纪要 **会议主题** [主题] **会议时间** [根据文本推断若无则写“待补充”] **参会人员** [人员列表] ## 一、核心讨论要点 - [要点1] - [要点2] ... ## 二、达成决策 - [决策1] - [决策2] ... ## 三、待办任务 | 任务内容 | 负责人 | 截止时间 | 备注 | |---|---|---|---| | [任务1] | [人名] | [时间] | | | [任务2] | [人名] | [时间] | |关键点我们使用了更具体的指令、分步骤的要求和明确的格式Markdown表格。这能极大提升大模型输出的稳定性和质量。处理“否”的分支从“条件判断”节点的“否”分支连接一个“文本”节点。在这个节点里直接写一段固定回复例如“您输入的内容似乎不是会议记录。请提供会议讨论相关的文本以便我为您生成纪要。”汇总输出现在我们有两条路径路径A是“生成会议纪要”节点 - 需要连接到输出。路径B否“文本”节点 - 需要连接到输出。拖入一个“答案”节点重命名为“最终输出”。将“生成会议纪要”节点和“文本”节点的输出都连接到这个“最终输出”节点。注意Dify的工作流引擎足够智能同一时间只有一条活跃路径因此不会冲突。2.4 第四步测试、调试与发布30分钟运行测试点击画布右上角的“预览”按钮。在右侧的调试面板中在“用户输入-会议文本”的测试框里粘贴一段真实的会议文字记录可以从网上找一段样例。点击“运行”。观察流程你会看到流程线依次亮起数据流经每个节点。可以在每个节点上点击查看其输入和输出这是调试的黄金时刻。如果LLM输出格式不符合预期回到节点修改Prompt。迭代优化第一次结果往往不完美。常见的优化点主题概括不准调整第一个判断LLM的Prompt让它更严格。待办任务提取不全在第二个LLM的Prompt中强调“仔细扫描文本中所有带有‘需要’、‘负责’、‘截止’等关键词的句子”。输出格式混乱在Prompt中更加强调“严格使用指定的Markdown格式”。发布应用调试满意后点击右上角“发布”。发布后这个工作流就变成了一个可访问的Web应用。你可以分享链接给同事他们就可以直接使用了。至此一个具备基础逻辑判断能力的AI应用就完成了。两小时内你体验了从模型配置、流程设计、Prompt编写、条件分支到调试发布的全过程。这已经超越了一次性的Chat对话成为了一个可重复使用的工具。3. 从Demo到项目赋予工作流“智能体Agent”能力上面我们构建的是一个“静态”工作流流程固定LLM只被调用一次或两次。而“智能体”Agent的核心特征是自主决策和工具调用。在Dify中我们可以通过集成“工具”和设计更复杂的循环逻辑来模拟Agent行为。让我们升级会议纪要助手让它成为一个真正的“会议秘书Agent”不仅能总结还能在发现待办任务缺少截止时间时主动提问补全。3.1 引入“工具”扩展边界Dify的“工具”功能允许工作流调用外部能力。我们给Agent装上“耳朵”和“手”。知识库工具在“知识库”模块上传公司的《项目管理制度.pdf》。然后在工作流中可以在LLM节点前插入一个“知识库检索”节点。这样LLM在生成纪要或提取待办时就能参考公司制度里关于任务时限的规定使输出更合规。HTTP请求工具假设公司使用Jira进行任务管理。我们可以配置一个HTTP工具节点当纪要生成后自动将提取出的待办任务创建为Jira Issue。这需要你编写API调用逻辑但Dify提供了可视化的配置界面来设置请求头、参数和解析响应。3.2 设计交互式循环让Agent学会追问这是实现Agent“智能”的关键。我们修改流程解析待办任务在“生成会议纪要”节点后不直接输出。而是连接一个“代码”节点Python。在这个节点里编写脚本解析上一步LLM输出的Markdown表格提取出“待办任务”部分并检查每个任务是否包含“截止时间”。将任务列表和缺失时间的任务列表作为输出。条件判断连接一个“条件判断”节点。判断条件是{{代码节点.output.缺失任务列表}}是否为空。追问分支循环如果缺失时间进入追问分支。连接一个“LLM”节点Prompt设计为“用户刚才召开了会议我们提取出以下待办任务但缺少截止时间{{缺失任务列表}}。请你以会议秘书的身份生成一个问题向用户逐一询问这些任务的期望截止时间。问题要友好、清晰。”将这个LLM节点的输出连接回“最终输出”节点但这是一个中间输出。同时我们需要设计一种机制让用户的下一次输入即回答的截止时间能够被流程接收并更新到任务列表中。这涉及到“多轮对话”和“状态保持”。在更复杂的Dify工作流中你可以使用“变量”来存储中间状态如任务列表并在新一轮对话中读取和修改它。这需要更精细的设计超出了入门范围但展示了Agent的交互潜力。完成分支如果没有缺失时间则直接连接“最终输出”节点呈现完整的会议纪要。通过这个设计你的应用从一个“单向处理器”变成了一个“交互式助手”。它能分析结果的完整性发现缺失信息并主动发起追问来补全。这就是Agent思维的体现感知-分析-决策-行动或提问。3.3 复杂工作流的设计原则当节点增多、逻辑变复杂时需要遵循一些原则来保持清晰模块化将大流程拆分成子流程。例如将“提取并分析待办任务”封装成一个可复用的子工作流。命名清晰每个节点都应有描述其功能的名称如“解析MD表格-提取任务”而非“代码节点1”。善用变量在节点间传递复杂数据时使用结构化的变量而不是依赖纯文本解析。日志与调试在关键节点后添加“日志”节点输出中间结果便于排查问题。4. 走向“企业级”部署、集成与运维考量一个在Dify Cloud上跑通的Demo和公司内网一个每天处理几百次请求的稳定服务中间还有很长的路。这就是“企业级项目实战”要解决的问题。4.1 部署方式选择云服务 vs. 本地化Dify Cloud在线版优点免运维开箱即用适合快速原型验证、小型团队或对外公开的服务。缺点数据经过第三方服务器对数据安全有严格要求的内部场景不适用性能、自定义程度和模型支持受平台限制。本地部署优点数据完全自主可控可以部署在内网环境可以自定义所有配置集成内部模型和工具性能取决于自有服务器。缺点需要一定的运维能力Docker、服务器管理。方法Dify提供了完善的Docker Compose部署方案。你需要准备一台Linux服务器安装Docker和Docker Compose然后按照官方文档克隆代码库配置环境变量如数据库密码、API密钥一条命令即可启动所有服务前端、后端、数据库等。4.2 生产环境关键配置如果你选择本地部署以下几项是关键模型管理生产环境通常不会直接使用OpenAI的公有API。你需要部署本地模型集成Ollama、LocalAI、vLLM等框架部署开源模型如Qwen、Llama、GLM。配置模型网关对于商业API或混合云模型Dify支持配置多个供应商和模型并设置优先级、限流和负载均衡。知识库优化生产级知识库面临海量文档。索引性能选择高性能的向量数据库后端如PGVector与PostgreSQL集成或Qdrant。数据处理建立文档更新和同步机制确保知识库内容最新。检索质量调整文本分割策略、向量化模型和检索相似度阈值平衡召回率和精度。安全与权限API密钥管理切勿在前端代码或配置文件中硬编码密钥。使用环境变量或密钥管理服务。访问控制Dify企业版支持更细粒度的团队和角色权限管理。社区版可通过反向代理如Nginx配置基础认证。审计日志确保所有API调用、知识库操作都有记录可查。性能与监控缓存策略对频繁且结果固定的查询如某些知识库问答引入缓存减少LLM调用和Token消耗。监控告警监控服务器资源CPU、内存、Dify服务状态、API调用失败率和Token消耗趋势。设置告警阈值。版本管理对工作流进行版本控制。修改生产环境的工作流前先在测试环境充分验证。4.3 与现有系统集成Dify应用不是孤岛它需要融入企业IT生态。作为API服务Dify发布的每个应用都自动提供标准的API接口。你的业务系统如OA、CRM可以通过HTTP调用这些API将AI能力嵌入现有流程。通过Webhook触发工作流可以配置Webhook输入节点监听外部系统的事件如GitHub提交、表单提交、客服工单创建实现自动化触发。嵌入网站或聊天工具Dify应用可以以Chatbot插件的形式嵌入到公司官网或内部Slack、飞书、钉钉等平台。从Prompt到企业级项目真正的挑战往往不在AI模型本身而在于如何将AI能力工程化、产品化、服务化。Dify通过可视化工作流这个抽象极大地压缩了从想法到可运行服务之间的路径。它让你能聚焦于业务逻辑和Prompt优化而不是陷入基础设施的泥潭。对于初学者我的建议是不要追求一步到位的复杂Agent。从解决一个具体的、微小的问题开始比如我们的会议纪要生成用Dify把它跑通。然后再思考如何为它添加“工具”如查知识库如何让它具备“判断”能力如检查信息完整性最后再考虑如何让它“主动”行动如创建任务。每一步的进阶都对应着你对工作流、节点和AI协作模式更深一层的理解。当你能够熟练地使用Dify将一个个模糊的AI想法变成稳定、可视、可共享的自动化流程时你就已经掌握了这个时代一项极具价值的能力——将智能转化为生产力。
