30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度你有没有过这样的经历想用AI做个智能客服、自动写周报的小工具或者把公司内部文档变成问答机器人结果发现要么得写一堆代码要么得在各种平台间反复切换最后项目还没开始光环境配置和流程设计就耗尽了热情。最近两年AI应用开发的门槛看似降低了但“最后一公里”的障碍依然存在。如何把大模型的能力稳定、可靠、低成本地嵌入到具体业务里依然是个技术活。直到我花了一个周末从零开始用Dify搭建了一个完整的智能问答工作流才意识到Agent开发的核心早已不是写Prompt本身而是如何把一次性的“对话”变成可复用、可监控、可迭代的“工作流”。Dify这个名字你可能听过它常被描述为“可视化AI应用开发平台”。但如果你只把它看作一个拖拽界面的Prompt工具那就错过了它最核心的价值。我花了十几个小时从安装部署到构建一个包含知识库检索、条件判断和外部API调用的企业级Agent原型最大的感触是Dify真正解决的是把AI从“玩具”变成“工具”的工程化问题。它帮你处理了那些繁琐但关键的部分——状态管理、上下文组装、错误重试、日志追踪——让你能专注于业务逻辑本身。这篇文章我会带你完整走一遍这个旅程。我们不只讲“怎么点按钮”更会深入拆解为什么工作流比单次Prompt更可靠企业级项目需要补上哪些关键环节以及从Prompt到可部署应用中间到底有多少隐藏的坑需要填平。1. 为什么说“会写Prompt”和“能开发Agent”是两回事很多人对AI应用开发的想象还停留在“写一段聪明的Prompt调一下API”的阶段。这当然能做出有趣的原型但一旦你想把它放进真实业务流问题就接踵而至。1.1 单次对话的脆弱性一次成功不等于次次成功你肯定遇到过这种情况在ChatGPT里调试好的Prompt复制到自己的代码里前几次运行完美但某一天突然返回了乱码、超时或者完全跑偏的答案。你检查了Prompt没变检查了API Key有效。问题出在哪可能是网络波动、模型服务端的临时负载、输入数据格式的细微差异或者上下文窗口的累积导致关键指令被“淹没”。单次Prompt交互就像手工烹饪一道菜火候、调料全凭当次感觉。而工作流Workflow则是把食谱、原料配比、烹饪时间全部标准化确保每一盘出品稳定。Dify的工作流引擎本质上就是这套标准化和自动化的框架。它允许你定义清晰的步骤先检索知识库再根据结果判断是否调用外部API最后格式化输出。每一步的输入输出、异常处理都有明确的路径这就把脆弱的“一次对话”变成了健壮的“处理流程”。1.2 上下文管理的隐形成本记忆、组装与裁剪让AI基于你的资料回答问题RAG听起来简单把文档切块、向量化、存起来提问时检索最相关的几块连同问题一起发给模型。但魔鬼在细节里上下文长度限制模型有Token限制你检索出的3段文档加上系统指令、用户问题、历史对话很容易就超限了。信息优先级与冲突如果检索出的多段文档信息矛盾模型该信谁历史对话的维护在多轮对话中如何避免无关历史干扰当前问题如何让模型记住关键信息如果自己实现你需要写代码处理文本分块、向量数据库交互、上下文窗口的滑动、提示词模板的组装……这些代码并不复杂但琐碎且容易出错。Dify把这些都做成了可视化配置。在“知识库”节点你可以设置检索策略相似度/关键词/混合、返回数量、以及是否启用“重排序”来提高精度。在“提示词”节点你可以用变量如{{query}},{{context}}动态组装最终发给模型的Prompt系统会自动处理长度裁剪和格式封装。这带来的直接价值是你可以把精力从“如何让技术跑起来”转移到“如何设计更有效的检索策略和提示词逻辑”上。这是从“实现者”到“设计者”的思维转变。1.3 从原型到生产那些必须补上的“工程拼图”一个能在演示中惊艳四座的AI原型和一個能7x24小时稳定运行的生产应用中间差着一整套工程体系可观测性用户问了什么AI答了什么内部流程走了哪条分支耗时多少有没有报错没有日志出了问题就是黑盒。稳定性模型API调用失败怎么办网络超时怎么办是否要自动重试重试几次安全性用户输入是否需要过滤输出是否需要审查知识库的访问权限如何控制成本与性能如何优化提示词以减少Token消耗如何缓存常见问题的答案如何选择性价比最高的模型Dify为企业级项目提供了这些拼图的基础组件完整的运行日志、对话历史管理、简单的错误处理可在工作流中配置“重试”节点、基于角色的权限控制、以及多模型供应商的对接与切换。这意味着你从第一天搭建应用开始就是在一個具备“可运维”潜力的架构上工作而不是在一堆临时脚本上缝缝补补。2. 两小时入门搭建你的第一个Dify智能体工作流理论说了这么多我们动手建一个。目标创建一个“技术文档助手”它能回答关于Dify本身的问题。如果问题超出知识库范围它会礼貌告知并建议去官方社区提问。2.1 环境准备与部署避开第一个坑Dify支持多种部署方式云服务、Docker Compose、Kubernetes等。对于学习和开发Docker Compose是最推荐的方式它把所有依赖数据库、向量数据库、后端、前端打包在一起避免了环境冲突。# 1. 克隆代码选择稳定版本分支如0.6.x git clone -b main https://github.com/langgenius/dify.git cd dify # 2. 编辑配置文件 cp .env.example .env # 使用编辑器打开 .env重点关注以下配置 # - OPENAI_API_KEY (或其他模型API Key如Azure, Anthropic, 国内模型) # - DB_PASSWORD, REDIS_PASSWORD (修改为强密码) # - 如需本地模型配置MODEL_PROVIDERS相关项 # 3. 启动服务 docker-compose up -d关键注意事项网络问题首次启动会拉取多个镜像确保网络通畅。如果拉取慢可以配置Docker镜像加速器。端口冲突默认占用80前端和5001后端端口。如果冲突在docker-compose.yml中修改。硬件资源Dify本身不耗资源但向量计算和模型推理依赖你配置的AI服务。如果使用本地小模型需保证足够内存。API Key安全.env文件包含敏感信息切勿提交到Git等版本控制系统。生产环境应使用更安全的密钥管理方式。启动成功后访问http://你的服务器IP即可进入Dify控制台。2.2 核心概念速览应用、工作流、知识库进入Dify后先理清三个核心概念它们构成了应用的骨架应用 (App)你最终要交付给用户或自己的AI服务。比如“智能客服”、“周报生成器”。一个应用可以由一个简单的对话提示词构成也可以由一个复杂的工作流驱动。工作流 (Workflow)这是Dify的“编程”界面。通过拖拽节点检索、判断、调用、生成等并连接它们来定义AI处理任务的逻辑流程。这是实现复杂Agent能力的核心。知识库 (Knowledge Base)用于存储和管理你的私有文档PDF、Word、TXT等。文档会被解析、分块、向量化以便在工作流中被快速检索和引用。我们的“技术文档助手”将是一个基于工作流的应用并且会接入一个知识库。2.3 第一步创建并填充知识库在侧边栏进入“知识库”点击“创建”。命名例如 “Dify官方文档”。分词与向量化保持默认的“精准”分词即可。向量模型选择与你部署环境匹配的如果使用OpenAI的Embedding则选text-embedding-3-small如果本地部署了bge等模型则需在设置中配置。上传文档将Dify的官方文档Markdown或PDF格式上传。系统会自动进行分块、向量化并存入数据库。这个过程需要一些时间。检查索引上传完成后在知识库详情页可以“搜索”测试一下看能否正确检索到相关内容。经验之谈知识库的效果很大程度上取决于文档质量和分块策略。对于技术文档按章节或主题分块通常效果更好。Dify也支持手动调整分块规则如块大小、重叠区间。2.4 第二步设计工作流逻辑现在进入重头戏创建工作流。点击“工作流”-“创建”。我们的逻辑很简单但体现了工作流的核心价值开始 - 用户提问 - 知识库检索 - [判断是否有相关答案] - 是 - 用检索结果生成回答 - 结束 - 否 - 回复“超出范围” - 结束在画布上你需要拖拽以下节点并连线开始节点工作流的入口。问题节点接收用户输入的问题我们将其变量命名为question。知识库检索节点选择我们刚创建的“Dify官方文档”知识库。将“查询内容”设置为变量{{question}}。配置检索参数返回条数设为3检索模式选“相似度”。该节点的输出会包含检索到的“内容”片段我们将其变量命名为context。条件判断节点 (IF/ELSE)这是实现智能判断的关键。我们需要判断context是否有效。条件可以设置为{{context}}的长度大于某个阈值比如10个字符或者是否包含特定关键词。更简单的做法是检查检索节点返回的“内容”是否为空。这里我们使用一个技巧{{#context}}...{{/context}}模板语法可以判断变量是否存在且非空但在节点条件中我们可以用“变量比较”功能判断context不等于空字符串。LLM节点 (条件为真分支)模型选择比如gpt-4o-mini。提示词配置你是一个专业的Dify技术助手请严格根据以下提供的上下文内容来回答问题。 如果上下文中的信息不足以回答问题请直接说“根据现有资料无法回答该问题”。 上下文 {{context}} 用户问题 {{question}} 请用中文给出专业、清晰的回答系统提示词可以写“你是一个严谨的技术支持助手。”文本回复节点 (条件为假分支)直接回复“您的问题目前超出了我的知识范围仅限Dify官方文档。建议您查阅Dify官方文档或前往GitHub社区提问。”结束节点将两个分支的输出都连接到此节点。连线逻辑从“开始”到“问题”到“知识库检索”到“条件判断”。条件判断节点有两个输出口“真”连接LLM节点“假”连接文本回复节点。最后LLM节点和文本回复节点都连接到“结束”节点。2.5 第三步测试、调试与发布运行测试点击右上角“运行”。在右侧预览区输入问题如“Dify如何部署在Kubernetes上”观察工作流执行路径节点会高亮并检查最终回复是否准确。调试技巧查看节点详情点击每个节点可以查看其详细的输入/输出数据。这是排查问题的利器。比如如果回答不对先看“知识库检索”节点返回的context是否正确。修改提示词如果LLM的回答啰嗦或格式不对调整提示词。可以增加“请用简洁的列表形式回答”或“答案控制在100字以内”等指令。调整检索策略如果总是检索不到尝试在知识库设置中调整分块大小或在检索节点中增加返回条数或尝试“混合检索”模式。发布应用测试无误后回到“应用”页面创建新应用类型选择“工作流”并关联我们刚创建的工作流。这样你就得到了一个可以分享给他人使用的Web应用或API接口。至此一个具备基本逻辑判断和知识检索能力的Agent就完成了。整个过程你没有写一行后端代码但实现的功能却相当于一个简单的RAG系统。3. 从入门到企业级工作流进阶与关键配置上面我们搭建了一个基础工作流。但对于企业级项目这仅仅是起点。下面几个进阶能力决定了你的Agent是“玩具”还是“工具”。3.1 复杂逻辑编排超越线性流程真实业务很少是简单的“是/否”判断。Dify工作流支持更复杂的逻辑例如并行处理使用“并行分支”节点可以同时执行多个任务比如同时检索产品知识库和用户订单数据库然后合并结果生成回答。循环迭代虽然Dify没有显式的循环节点但可以通过“代码节点”编写Python脚本实现复杂循环逻辑例如遍历一个列表对每一项调用AI进行处理。变量与状态管理工作流中每个节点的输出都可以赋值给变量并在后续节点中使用。这是构建复杂状态机的关键。例如你可以将用户首次询问的产品型号存入变量product_model在后续多轮对话中直接引用无需用户重复提供。一个示例场景智能订单查询Agent用户输入订单号或用户名。代码节点调用内部订单API获取订单详情状态、商品、金额存入变量order_info。条件判断如果order_info为空回复“未找到订单”。条件判断如果订单状态为“已发货”则并行执行分支A调用物流API获取物流信息。分支B用LLM节点将order_info总结成用户友好的话术。变量组合节点将物流信息和总结话术合并。LLM节点生成最终回复“您的订单[订单号]已发货物流信息是……商品包括……。” 这个流程涉及外部API调用、条件分支、并行处理、变量组合完全通过可视化编排实现。3.2 外部能力集成连接现实世界AI的“智能”需要与现实世界的数据和系统交互。Dify提供了多种方式HTTP请求节点这是最通用的集成方式。你可以用它调用任何外部RESTful API。认证支持API Key、Bearer Token、Basic Auth等多种方式在节点配置中安全地填写Dify会加密存储。参数处理请求的URL、Header、Body都可以使用工作流中的变量动态构造。响应处理将API返回的JSON数据解析提取所需字段存入变量供后续节点使用。自定义工具函数对于更复杂的集成逻辑你可以在“工具”中编写Python函数。这相当于为工作流创建了可复用的“插件”。例如写一个函数连接公司内部的MySQL数据库执行查询。或者写一个函数调用特定的算法服务。函数写好并发布后会像其他节点一样出现在工作流画布中供拖拽使用。预置工具集Dify社区和生态提供了许多预置工具如天气查询、股票信息、维基百科搜索等可以直接启用。集成关键点外部调用一定要考虑错误处理和超时。在HTTP请求节点中务必配置合理的超时时间并在其下游添加“条件判断”节点检查响应状态码或内容是否有效从而引导工作流走向不同的处理分支如重试或返回友好错误信息。3.3 提示词工程实战从技巧到系统在工作流中提示词Prompt被提升到了系统化设计的层面。上下文变量这是工作流提示词的核心优势。你可以将知识库检索结果、用户信息、API返回数据、历史对话摘要等通过{{variable_name}}的方式动态注入提示词。这确保了每次请求的上下文都是精准、新鲜的。系统提示词与用户提示词分离在LLM节点中可以分别设置“系统提示词”定义AI的角色和长期行为准则和“用户提示词”本次请求的具体指令和内容。这种分离让角色管理更清晰。思维链Chain-of-Thought与少样本Few-Shot你可以在提示词中直接要求模型“逐步思考”或者提供几个输入输出的例子。在工作流中你甚至可以将“思考”和“回答”拆分成两个连续的LLM节点实现更可控的推理过程。输出结构化通过提示词要求模型以JSON、XML或特定Markdown格式输出然后在工作流中使用“代码节点”进行解析可以极大地提升后续自动化处理的可靠性。一个进阶示例带审核的客服工单生成用户描述问题。LLM节点分析员提示词要求模型将用户描述结构化为JSON{问题分类: , 紧急程度: , 关键实体: []}。代码节点解析JSON根据“紧急程度”变量决定路由。条件判断如果为“高紧急”则并行执行分支A调用内部系统创建工单。分支B另一个LLM节点审核员以上一个LLM的结构化输出为输入生成一封给客服经理的预警邮件草稿。结束。这里第一个LLM的结构化输出成为了工作流中关键的状态载体驱动了后续的分支决策和自动化操作。3.4 监控、版本与协作团队开发维度个人开发和生产团队开发是两种模式。Dify也提供了相应支持对话日志与追溯在控制台的“日志与标注”中可以查看每一次对话的完整记录包括用户输入、工作流执行路径、每个节点的输入输出、耗时和最终回复。这是分析问题、优化流程的黄金数据。应用版本管理你可以保存工作流的不同版本。当对生产中的应用进行重大修改时可以先创建一个新版本进行测试稳定后再发布上线实现平滑迭代。团队协作与权限Dify支持多用户和角色所有者、管理员、编辑者、读者。你可以将不同的应用或知识库分配给不同的团队成员管理实现职责分离。API访问每个发布的应用都自动提供API端点方便集成到其他业务系统。你可以管理API密钥并查看API调用统计。4. 避坑指南与长期维护建议基于我的实践以下几个点是新手从入门到进阶最容易忽略也最容易导致项目后期难以维护的关键。4.1 性能与成本优化提示词精简检查LLM节点中的提示词移除不必要的描述和废话。每一个Token都在花钱或消耗本地算力。知识库检索优化分块策略对于技术文档按章节或子标题分块比固定长度分块效果更好。检索后重排序RerankDify支持使用重排序模型对初步检索结果进行二次排序能显著提升Top1结果的准确率但会增加少量延迟和计算成本。根据准确率要求权衡是否开启。元数据过滤在上传文档时可以为不同文档或段落添加元数据标签如“用户手册V2.0”、“API参考”。检索时可以指定标签实现更精准的筛选。模型选择不是所有任务都需要GPT-4。对于简单的信息提取、格式化、路由判断使用更快的gpt-3.5-turbo或成本更低的本地小模型往往性价比更高。Dify支持灵活配置多模型供应商可以在不同节点使用不同模型。4.2 错误处理与健壮性工作流必须假设任何环节都可能出错。外部API调用HTTP节点必须设置超时如30秒并配置失败重试策略如最多3次。下游要有节点检查HTTP状态码是否为200响应体是否包含预期字段。LLM调用异常模型服务可能不稳定。在LLM节点配置中可以设置“失败后重试”。更稳健的做法是在工作流层面将LLM节点放在一个“容错”分支里如果连续失败则降级到使用预定义的静态回复。输入验证与清洗在“开始”节点后可以添加一个“代码节点”对用户输入进行初步检查过滤敏感词、检查长度、修正常见错别字等避免垃圾输入干扰后续流程。默认回复与兜底策略在任何可能失败的分支末端都设置一个友好的默认回复如“服务暂时不可用请稍后再试”而不是将内部错误信息暴露给用户。4.3 知识库的持续运营知识库不是一次性上传就完事的。定期更新业务文档会变。Dify支持知识库文档的增量更新和重新索引。建立文档更新流程确保AI的知识与业务同步。效果评估定期查看知识库检索的日志分析“未命中”或“低相关性”的查询。这可能意味着需要调整分块大小、优化文档内容或添加新的文档。多知识库协同可以创建多个知识库如“产品知识库”、“内部规章库”、“客户案例库”。在工作流中可以根据问题类型动态选择检索哪个知识库或者并行检索多个后合并结果。4.4 安全与权限权限控制利用Dify的角色权限功能严格控制谁可以修改工作流、谁可以管理知识库、谁只能使用应用。输入输出过滤对于面向公众的应用考虑在前后端增加内容安全过滤防止恶意输入或不当输出。API密钥管理用于连接外部服务和AI模型的API密钥务必通过环境变量或Dify的密钥管理功能配置切勿硬编码在工作流或代码中。数据隐私明确哪些数据会经过外部AI服务如OpenAI对于敏感数据应使用本地部署的模型或在提示词中进行脱敏处理。回顾整个过程从写一个Prompt到搭建一个企业级AI工作流最大的转变不是工具的使用而是思维的升级。你不再仅仅是一个“提问者”而是成为了一个“系统设计者”。你需要考虑流程、状态、异常、成本和安全。Dify这样的可视化工具极大地降低了工程实现的门槛让你可以更专注于业务逻辑和AI能力本身的设计。它可能不是所有场景的最优解对于需要极致性能或高度定制化算法的场景你仍然需要从零编码。但对于绝大多数需要快速将AI能力落地到业务流程中的团队和个人来说它提供了一个从“想法”到“可运行、可维护的应用”的最短路径。下次当你再有一个AI应用的想法时不妨先打开Dify用工作流的方式画一画它的逻辑你会发现很多复杂问题就这样被分解和解决了。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
从Prompt到工作流:用Dify构建企业级AI Agent的工程实践
发布时间:2026/7/10 1:49:12
30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度你有没有过这样的经历想用AI做个智能客服、自动写周报的小工具或者把公司内部文档变成问答机器人结果发现要么得写一堆代码要么得在各种平台间反复切换最后项目还没开始光环境配置和流程设计就耗尽了热情。最近两年AI应用开发的门槛看似降低了但“最后一公里”的障碍依然存在。如何把大模型的能力稳定、可靠、低成本地嵌入到具体业务里依然是个技术活。直到我花了一个周末从零开始用Dify搭建了一个完整的智能问答工作流才意识到Agent开发的核心早已不是写Prompt本身而是如何把一次性的“对话”变成可复用、可监控、可迭代的“工作流”。Dify这个名字你可能听过它常被描述为“可视化AI应用开发平台”。但如果你只把它看作一个拖拽界面的Prompt工具那就错过了它最核心的价值。我花了十几个小时从安装部署到构建一个包含知识库检索、条件判断和外部API调用的企业级Agent原型最大的感触是Dify真正解决的是把AI从“玩具”变成“工具”的工程化问题。它帮你处理了那些繁琐但关键的部分——状态管理、上下文组装、错误重试、日志追踪——让你能专注于业务逻辑本身。这篇文章我会带你完整走一遍这个旅程。我们不只讲“怎么点按钮”更会深入拆解为什么工作流比单次Prompt更可靠企业级项目需要补上哪些关键环节以及从Prompt到可部署应用中间到底有多少隐藏的坑需要填平。1. 为什么说“会写Prompt”和“能开发Agent”是两回事很多人对AI应用开发的想象还停留在“写一段聪明的Prompt调一下API”的阶段。这当然能做出有趣的原型但一旦你想把它放进真实业务流问题就接踵而至。1.1 单次对话的脆弱性一次成功不等于次次成功你肯定遇到过这种情况在ChatGPT里调试好的Prompt复制到自己的代码里前几次运行完美但某一天突然返回了乱码、超时或者完全跑偏的答案。你检查了Prompt没变检查了API Key有效。问题出在哪可能是网络波动、模型服务端的临时负载、输入数据格式的细微差异或者上下文窗口的累积导致关键指令被“淹没”。单次Prompt交互就像手工烹饪一道菜火候、调料全凭当次感觉。而工作流Workflow则是把食谱、原料配比、烹饪时间全部标准化确保每一盘出品稳定。Dify的工作流引擎本质上就是这套标准化和自动化的框架。它允许你定义清晰的步骤先检索知识库再根据结果判断是否调用外部API最后格式化输出。每一步的输入输出、异常处理都有明确的路径这就把脆弱的“一次对话”变成了健壮的“处理流程”。1.2 上下文管理的隐形成本记忆、组装与裁剪让AI基于你的资料回答问题RAG听起来简单把文档切块、向量化、存起来提问时检索最相关的几块连同问题一起发给模型。但魔鬼在细节里上下文长度限制模型有Token限制你检索出的3段文档加上系统指令、用户问题、历史对话很容易就超限了。信息优先级与冲突如果检索出的多段文档信息矛盾模型该信谁历史对话的维护在多轮对话中如何避免无关历史干扰当前问题如何让模型记住关键信息如果自己实现你需要写代码处理文本分块、向量数据库交互、上下文窗口的滑动、提示词模板的组装……这些代码并不复杂但琐碎且容易出错。Dify把这些都做成了可视化配置。在“知识库”节点你可以设置检索策略相似度/关键词/混合、返回数量、以及是否启用“重排序”来提高精度。在“提示词”节点你可以用变量如{{query}},{{context}}动态组装最终发给模型的Prompt系统会自动处理长度裁剪和格式封装。这带来的直接价值是你可以把精力从“如何让技术跑起来”转移到“如何设计更有效的检索策略和提示词逻辑”上。这是从“实现者”到“设计者”的思维转变。1.3 从原型到生产那些必须补上的“工程拼图”一个能在演示中惊艳四座的AI原型和一個能7x24小时稳定运行的生产应用中间差着一整套工程体系可观测性用户问了什么AI答了什么内部流程走了哪条分支耗时多少有没有报错没有日志出了问题就是黑盒。稳定性模型API调用失败怎么办网络超时怎么办是否要自动重试重试几次安全性用户输入是否需要过滤输出是否需要审查知识库的访问权限如何控制成本与性能如何优化提示词以减少Token消耗如何缓存常见问题的答案如何选择性价比最高的模型Dify为企业级项目提供了这些拼图的基础组件完整的运行日志、对话历史管理、简单的错误处理可在工作流中配置“重试”节点、基于角色的权限控制、以及多模型供应商的对接与切换。这意味着你从第一天搭建应用开始就是在一個具备“可运维”潜力的架构上工作而不是在一堆临时脚本上缝缝补补。2. 两小时入门搭建你的第一个Dify智能体工作流理论说了这么多我们动手建一个。目标创建一个“技术文档助手”它能回答关于Dify本身的问题。如果问题超出知识库范围它会礼貌告知并建议去官方社区提问。2.1 环境准备与部署避开第一个坑Dify支持多种部署方式云服务、Docker Compose、Kubernetes等。对于学习和开发Docker Compose是最推荐的方式它把所有依赖数据库、向量数据库、后端、前端打包在一起避免了环境冲突。# 1. 克隆代码选择稳定版本分支如0.6.x git clone -b main https://github.com/langgenius/dify.git cd dify # 2. 编辑配置文件 cp .env.example .env # 使用编辑器打开 .env重点关注以下配置 # - OPENAI_API_KEY (或其他模型API Key如Azure, Anthropic, 国内模型) # - DB_PASSWORD, REDIS_PASSWORD (修改为强密码) # - 如需本地模型配置MODEL_PROVIDERS相关项 # 3. 启动服务 docker-compose up -d关键注意事项网络问题首次启动会拉取多个镜像确保网络通畅。如果拉取慢可以配置Docker镜像加速器。端口冲突默认占用80前端和5001后端端口。如果冲突在docker-compose.yml中修改。硬件资源Dify本身不耗资源但向量计算和模型推理依赖你配置的AI服务。如果使用本地小模型需保证足够内存。API Key安全.env文件包含敏感信息切勿提交到Git等版本控制系统。生产环境应使用更安全的密钥管理方式。启动成功后访问http://你的服务器IP即可进入Dify控制台。2.2 核心概念速览应用、工作流、知识库进入Dify后先理清三个核心概念它们构成了应用的骨架应用 (App)你最终要交付给用户或自己的AI服务。比如“智能客服”、“周报生成器”。一个应用可以由一个简单的对话提示词构成也可以由一个复杂的工作流驱动。工作流 (Workflow)这是Dify的“编程”界面。通过拖拽节点检索、判断、调用、生成等并连接它们来定义AI处理任务的逻辑流程。这是实现复杂Agent能力的核心。知识库 (Knowledge Base)用于存储和管理你的私有文档PDF、Word、TXT等。文档会被解析、分块、向量化以便在工作流中被快速检索和引用。我们的“技术文档助手”将是一个基于工作流的应用并且会接入一个知识库。2.3 第一步创建并填充知识库在侧边栏进入“知识库”点击“创建”。命名例如 “Dify官方文档”。分词与向量化保持默认的“精准”分词即可。向量模型选择与你部署环境匹配的如果使用OpenAI的Embedding则选text-embedding-3-small如果本地部署了bge等模型则需在设置中配置。上传文档将Dify的官方文档Markdown或PDF格式上传。系统会自动进行分块、向量化并存入数据库。这个过程需要一些时间。检查索引上传完成后在知识库详情页可以“搜索”测试一下看能否正确检索到相关内容。经验之谈知识库的效果很大程度上取决于文档质量和分块策略。对于技术文档按章节或主题分块通常效果更好。Dify也支持手动调整分块规则如块大小、重叠区间。2.4 第二步设计工作流逻辑现在进入重头戏创建工作流。点击“工作流”-“创建”。我们的逻辑很简单但体现了工作流的核心价值开始 - 用户提问 - 知识库检索 - [判断是否有相关答案] - 是 - 用检索结果生成回答 - 结束 - 否 - 回复“超出范围” - 结束在画布上你需要拖拽以下节点并连线开始节点工作流的入口。问题节点接收用户输入的问题我们将其变量命名为question。知识库检索节点选择我们刚创建的“Dify官方文档”知识库。将“查询内容”设置为变量{{question}}。配置检索参数返回条数设为3检索模式选“相似度”。该节点的输出会包含检索到的“内容”片段我们将其变量命名为context。条件判断节点 (IF/ELSE)这是实现智能判断的关键。我们需要判断context是否有效。条件可以设置为{{context}}的长度大于某个阈值比如10个字符或者是否包含特定关键词。更简单的做法是检查检索节点返回的“内容”是否为空。这里我们使用一个技巧{{#context}}...{{/context}}模板语法可以判断变量是否存在且非空但在节点条件中我们可以用“变量比较”功能判断context不等于空字符串。LLM节点 (条件为真分支)模型选择比如gpt-4o-mini。提示词配置你是一个专业的Dify技术助手请严格根据以下提供的上下文内容来回答问题。 如果上下文中的信息不足以回答问题请直接说“根据现有资料无法回答该问题”。 上下文 {{context}} 用户问题 {{question}} 请用中文给出专业、清晰的回答系统提示词可以写“你是一个严谨的技术支持助手。”文本回复节点 (条件为假分支)直接回复“您的问题目前超出了我的知识范围仅限Dify官方文档。建议您查阅Dify官方文档或前往GitHub社区提问。”结束节点将两个分支的输出都连接到此节点。连线逻辑从“开始”到“问题”到“知识库检索”到“条件判断”。条件判断节点有两个输出口“真”连接LLM节点“假”连接文本回复节点。最后LLM节点和文本回复节点都连接到“结束”节点。2.5 第三步测试、调试与发布运行测试点击右上角“运行”。在右侧预览区输入问题如“Dify如何部署在Kubernetes上”观察工作流执行路径节点会高亮并检查最终回复是否准确。调试技巧查看节点详情点击每个节点可以查看其详细的输入/输出数据。这是排查问题的利器。比如如果回答不对先看“知识库检索”节点返回的context是否正确。修改提示词如果LLM的回答啰嗦或格式不对调整提示词。可以增加“请用简洁的列表形式回答”或“答案控制在100字以内”等指令。调整检索策略如果总是检索不到尝试在知识库设置中调整分块大小或在检索节点中增加返回条数或尝试“混合检索”模式。发布应用测试无误后回到“应用”页面创建新应用类型选择“工作流”并关联我们刚创建的工作流。这样你就得到了一个可以分享给他人使用的Web应用或API接口。至此一个具备基本逻辑判断和知识检索能力的Agent就完成了。整个过程你没有写一行后端代码但实现的功能却相当于一个简单的RAG系统。3. 从入门到企业级工作流进阶与关键配置上面我们搭建了一个基础工作流。但对于企业级项目这仅仅是起点。下面几个进阶能力决定了你的Agent是“玩具”还是“工具”。3.1 复杂逻辑编排超越线性流程真实业务很少是简单的“是/否”判断。Dify工作流支持更复杂的逻辑例如并行处理使用“并行分支”节点可以同时执行多个任务比如同时检索产品知识库和用户订单数据库然后合并结果生成回答。循环迭代虽然Dify没有显式的循环节点但可以通过“代码节点”编写Python脚本实现复杂循环逻辑例如遍历一个列表对每一项调用AI进行处理。变量与状态管理工作流中每个节点的输出都可以赋值给变量并在后续节点中使用。这是构建复杂状态机的关键。例如你可以将用户首次询问的产品型号存入变量product_model在后续多轮对话中直接引用无需用户重复提供。一个示例场景智能订单查询Agent用户输入订单号或用户名。代码节点调用内部订单API获取订单详情状态、商品、金额存入变量order_info。条件判断如果order_info为空回复“未找到订单”。条件判断如果订单状态为“已发货”则并行执行分支A调用物流API获取物流信息。分支B用LLM节点将order_info总结成用户友好的话术。变量组合节点将物流信息和总结话术合并。LLM节点生成最终回复“您的订单[订单号]已发货物流信息是……商品包括……。” 这个流程涉及外部API调用、条件分支、并行处理、变量组合完全通过可视化编排实现。3.2 外部能力集成连接现实世界AI的“智能”需要与现实世界的数据和系统交互。Dify提供了多种方式HTTP请求节点这是最通用的集成方式。你可以用它调用任何外部RESTful API。认证支持API Key、Bearer Token、Basic Auth等多种方式在节点配置中安全地填写Dify会加密存储。参数处理请求的URL、Header、Body都可以使用工作流中的变量动态构造。响应处理将API返回的JSON数据解析提取所需字段存入变量供后续节点使用。自定义工具函数对于更复杂的集成逻辑你可以在“工具”中编写Python函数。这相当于为工作流创建了可复用的“插件”。例如写一个函数连接公司内部的MySQL数据库执行查询。或者写一个函数调用特定的算法服务。函数写好并发布后会像其他节点一样出现在工作流画布中供拖拽使用。预置工具集Dify社区和生态提供了许多预置工具如天气查询、股票信息、维基百科搜索等可以直接启用。集成关键点外部调用一定要考虑错误处理和超时。在HTTP请求节点中务必配置合理的超时时间并在其下游添加“条件判断”节点检查响应状态码或内容是否有效从而引导工作流走向不同的处理分支如重试或返回友好错误信息。3.3 提示词工程实战从技巧到系统在工作流中提示词Prompt被提升到了系统化设计的层面。上下文变量这是工作流提示词的核心优势。你可以将知识库检索结果、用户信息、API返回数据、历史对话摘要等通过{{variable_name}}的方式动态注入提示词。这确保了每次请求的上下文都是精准、新鲜的。系统提示词与用户提示词分离在LLM节点中可以分别设置“系统提示词”定义AI的角色和长期行为准则和“用户提示词”本次请求的具体指令和内容。这种分离让角色管理更清晰。思维链Chain-of-Thought与少样本Few-Shot你可以在提示词中直接要求模型“逐步思考”或者提供几个输入输出的例子。在工作流中你甚至可以将“思考”和“回答”拆分成两个连续的LLM节点实现更可控的推理过程。输出结构化通过提示词要求模型以JSON、XML或特定Markdown格式输出然后在工作流中使用“代码节点”进行解析可以极大地提升后续自动化处理的可靠性。一个进阶示例带审核的客服工单生成用户描述问题。LLM节点分析员提示词要求模型将用户描述结构化为JSON{问题分类: , 紧急程度: , 关键实体: []}。代码节点解析JSON根据“紧急程度”变量决定路由。条件判断如果为“高紧急”则并行执行分支A调用内部系统创建工单。分支B另一个LLM节点审核员以上一个LLM的结构化输出为输入生成一封给客服经理的预警邮件草稿。结束。这里第一个LLM的结构化输出成为了工作流中关键的状态载体驱动了后续的分支决策和自动化操作。3.4 监控、版本与协作团队开发维度个人开发和生产团队开发是两种模式。Dify也提供了相应支持对话日志与追溯在控制台的“日志与标注”中可以查看每一次对话的完整记录包括用户输入、工作流执行路径、每个节点的输入输出、耗时和最终回复。这是分析问题、优化流程的黄金数据。应用版本管理你可以保存工作流的不同版本。当对生产中的应用进行重大修改时可以先创建一个新版本进行测试稳定后再发布上线实现平滑迭代。团队协作与权限Dify支持多用户和角色所有者、管理员、编辑者、读者。你可以将不同的应用或知识库分配给不同的团队成员管理实现职责分离。API访问每个发布的应用都自动提供API端点方便集成到其他业务系统。你可以管理API密钥并查看API调用统计。4. 避坑指南与长期维护建议基于我的实践以下几个点是新手从入门到进阶最容易忽略也最容易导致项目后期难以维护的关键。4.1 性能与成本优化提示词精简检查LLM节点中的提示词移除不必要的描述和废话。每一个Token都在花钱或消耗本地算力。知识库检索优化分块策略对于技术文档按章节或子标题分块比固定长度分块效果更好。检索后重排序RerankDify支持使用重排序模型对初步检索结果进行二次排序能显著提升Top1结果的准确率但会增加少量延迟和计算成本。根据准确率要求权衡是否开启。元数据过滤在上传文档时可以为不同文档或段落添加元数据标签如“用户手册V2.0”、“API参考”。检索时可以指定标签实现更精准的筛选。模型选择不是所有任务都需要GPT-4。对于简单的信息提取、格式化、路由判断使用更快的gpt-3.5-turbo或成本更低的本地小模型往往性价比更高。Dify支持灵活配置多模型供应商可以在不同节点使用不同模型。4.2 错误处理与健壮性工作流必须假设任何环节都可能出错。外部API调用HTTP节点必须设置超时如30秒并配置失败重试策略如最多3次。下游要有节点检查HTTP状态码是否为200响应体是否包含预期字段。LLM调用异常模型服务可能不稳定。在LLM节点配置中可以设置“失败后重试”。更稳健的做法是在工作流层面将LLM节点放在一个“容错”分支里如果连续失败则降级到使用预定义的静态回复。输入验证与清洗在“开始”节点后可以添加一个“代码节点”对用户输入进行初步检查过滤敏感词、检查长度、修正常见错别字等避免垃圾输入干扰后续流程。默认回复与兜底策略在任何可能失败的分支末端都设置一个友好的默认回复如“服务暂时不可用请稍后再试”而不是将内部错误信息暴露给用户。4.3 知识库的持续运营知识库不是一次性上传就完事的。定期更新业务文档会变。Dify支持知识库文档的增量更新和重新索引。建立文档更新流程确保AI的知识与业务同步。效果评估定期查看知识库检索的日志分析“未命中”或“低相关性”的查询。这可能意味着需要调整分块大小、优化文档内容或添加新的文档。多知识库协同可以创建多个知识库如“产品知识库”、“内部规章库”、“客户案例库”。在工作流中可以根据问题类型动态选择检索哪个知识库或者并行检索多个后合并结果。4.4 安全与权限权限控制利用Dify的角色权限功能严格控制谁可以修改工作流、谁可以管理知识库、谁只能使用应用。输入输出过滤对于面向公众的应用考虑在前后端增加内容安全过滤防止恶意输入或不当输出。API密钥管理用于连接外部服务和AI模型的API密钥务必通过环境变量或Dify的密钥管理功能配置切勿硬编码在工作流或代码中。数据隐私明确哪些数据会经过外部AI服务如OpenAI对于敏感数据应使用本地部署的模型或在提示词中进行脱敏处理。回顾整个过程从写一个Prompt到搭建一个企业级AI工作流最大的转变不是工具的使用而是思维的升级。你不再仅仅是一个“提问者”而是成为了一个“系统设计者”。你需要考虑流程、状态、异常、成本和安全。Dify这样的可视化工具极大地降低了工程实现的门槛让你可以更专注于业务逻辑和AI能力本身的设计。它可能不是所有场景的最优解对于需要极致性能或高度定制化算法的场景你仍然需要从零编码。但对于绝大多数需要快速将AI能力落地到业务流程中的团队和个人来说它提供了一个从“想法”到“可运行、可维护的应用”的最短路径。下次当你再有一个AI应用的想法时不妨先打开Dify用工作流的方式画一画它的逻辑你会发现很多复杂问题就这样被分解和解决了。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度