如果你已经完成了 Dify 的本地部署或正在使用其云服务登录后面对一个全新的界面是不是感觉有点无从下手左边是“应用”右边是“工作流”中间还有“知识库”和“工具”每个菜单下又有一堆子选项。很多开发者朋友在兴奋地搭建好环境后往往就卡在了这一步这个强大的 AI 应用构建平台到底应该从哪里开始用起这恰恰是学习任何新工具时最关键的“破冰”环节。界面导览不是简单的功能罗列它决定了你能否快速理解 Dify 的设计哲学从而高效地将你的 AI 想法转化为实际应用。如果一开始就点错了地方可能会在后续开发中走很多弯路比如试图用“对话型应用”去实现一个需要多步骤决策的复杂流程或者把本应放在“知识库”里管理的文档硬塞进提示词里。本文将带你完成从“注册/登录”到“全局掌控”的完整旅程。我们不会平铺直叙地介绍每个按钮而是会围绕一个核心问题展开如何通过理解 Dify 的界面布局快速定位到你实现 AI 想法所需的核心功能模块我们将把官方文档的骨架填充上真实的使用场景和操作逻辑让你在 10 分钟内不仅“看到”界面更能“看懂”其背后的设计意图为后续构建智能体、工作流或 RAG 应用打下坚实基础。1. 这篇文章真正要解决的问题很多技术教程会跳过“入门”这一步直接进入“如何构建一个 RAG 问答机器人”或“创建一个复杂的工作流”。但对于一个像 Dify 这样功能集成的平台跳过对控制台的整体认知就像不看地图就闯进一座功能复杂的大楼你可能会找到厕所但永远找不到那个藏着关键工具的“307会议室”。本文要解决的核心问题是帮助开发者和 AI 应用构建者在成功部署或登录 Dify 后快速建立对平台功能架构的全局认知并明确后续不同开发任务的正确入口。具体来说我们将拆解三个层次路径选择云服务与本地部署登录后看到的第一屏有何不同如何完成初始账号设置模块解析控制台首页的“应用”、“工作流”、“知识库”、“工具”等核心模块分别对应解决哪类问题它们之间的关系是什么场景映射当我想实现一个“智能客服”、“自动报告生成器”或“私有知识库助手”时我应该从哪个模块开始后续可能需要联动哪些模块通过解决这些问题你将摆脱对界面的陌生感能够自主规划在 Dify 上实现任何 AI 应用的路径图。2. Dify 核心模块全景解读不止是菜单更是产品哲学在深入点击之前我们需要理解 Dify 界面布局背后的逻辑。Dify 将自己定位为“生产就绪的智能体工作流构建平台”这意味着它的设计是围绕“构建可发布的 AI 应用”这个核心目标展开的。其界面可以大致分为四个核心功能层理解了这几层关系你就读懂了 Dify。2.1 核心功能层一构建层Build这是你花费最多时间的地方直接对应着控制台左侧导航栏最上方的几个核心菜单。应用这是 Dify 的“应用”单元。你在这里创建和管理一个个独立的 AI 应用实例。每个应用都有独立的配置、访问地址和对话历史。它更像是一个“项目”或“产品”的容器。工作流这是 Dify 的“引擎”单元。工作流采用可视化拖拽的方式将大型语言模型、代码执行、条件判断、API 调用等节点连接起来形成复杂的、多步骤的 AI 处理流水线。一个“应用”可以包含一个或多个“工作流”。知识库这是 Dify 的“记忆”单元。用于上传、处理和管理你的私有文档如 TXT, PDF, Word, Markdown并通过向量化技术构建可供 LLM 检索的智能知识库。工作流或对话应用可以调用知识库实现基于私有数据的问答RAG。工具这是 Dify 的“扩展”单元。你可以在这里配置和管理外部 API、函数或插件比如天气查询、数据库连接、图像处理等。配置好的工具可以被工作流或智能体调用极大地扩展了 AI 应用的能力边界。它们的关系是你通常先创建一个“应用”然后为这个应用设计“工作流”逻辑。在工作流中你可以插入“知识库检索”节点来获取私有信息也可以调用配置好的“工具”来执行外部操作。2.2 核心功能层二配置层Configure这一层为构建层提供“燃料”和“规则”。模型供应商这是 Dify 的“大脑”供应商列表。你需要在这里配置 OpenAI、Azure OpenAI、Anthropic、Ollama本地模型、通义千问等各类 LLM 服务的 API 密钥和端点。只有配置了模型你的应用和工作流才有“智能”可以调用。插件市场这是“工具”的扩展来源。你可以从这里发现和安装社区或官方提供的预制插件快速获得新能力而无需从零开始编写 API 集成代码。2.3 核心功能层三运营层Operate应用构建完成后你需要观察和管理它。日志与标注在这里查看应用的所有请求和响应记录对回答进行人工标注和修正这些数据可以用于后续的模型微调或提示词优化。数据集有时与知识库关联管理用于模型微调或评估的文本数据集。2.4 核心功能层四管理层Manage这部分主要涉及团队协作和系统设置。成员在团队版或企业版中管理可以访问该工作空间的成员及其权限如开发者、运营者、只读成员。设置包含工作空间设置、模型权限管理、审计日志等高级功能。理解了这个四层架构再看 Dify 的界面你就不会觉得它是一堆杂乱的功能堆砌而是一个有明确分工和协作关系的生产流水线。3. 第一步开通账号与登录根据你选择的使用方式第一步的操作略有不同。3.1 使用 Dify Cloud云服务这是最快捷的入门方式适合快速体验和原型验证。访问官网打开 Dify 官方网站。注册账号点击“Get Started”或“开始使用”通常可以使用邮箱、GitHub 或 Google 账号进行注册。初始设置首次登录后系统可能会引导你创建工作空间为你的项目或团队创建一个独立的环境。配置模型这是最关键的一步。系统会提示你添加第一个模型供应商例如 OpenAI。你需要输入有效的 API Key。# 这是一个概念示例实际是在网页表单中填写 # 供应商OpenAI # 模型名称GPT-4o # API Keysk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx选择模板Dify 可能会提供一些应用模板如客服机器人、内容生成器你可以选择跳过或基于模板创建。3.2 访问本地部署的 Dify如果你在本地服务器或自有云主机上部署了 Dify流程更简单。获取访问地址根据你的部署方式Docker Compose, Kubernetes 等通过服务器 IP 和端口访问 Dify Web UI。例如http://your-server-ip:3000。首次登录如果是全新安装首次访问会进入初始化设置页面。你需要设置一个管理员账号邮箱和密码。随后同样需要进入“模型供应商”配置你的 LLM。后续登录之后每次访问该地址直接使用设置的管理员账号或已添加的成员账号登录即可。关键区别云服务版帮你管理了服务器、网络和更新开箱即用本地部署版让你拥有全部数据和控制的自主权但需要自行维护。对于企业级应用或对数据隐私要求极高的场景本地部署是必选项。4. 控制台首页导览你的 AI 应用指挥中心成功登录后你会看到 Dify 的控制台首页。我们以最新版本的典型布局为例进行解析。4.1 顶部导航栏位于页面最上方通常包含工作空间切换器如果你有多个工作空间如“个人项目”、“公司团队”可以在这里快速切换。不同工作空间的应用、知识库完全隔离。快捷创建按钮“创建应用”/“新建工作流”最显眼的行动号召按钮从这里开始你的构建之旅。用户头像/菜单点击可查看账户信息、切换主题深色/浅色、查看文档、退出登录等。4.2 左侧主导航栏这是核心功能区我们逐一拆解应用我的应用列出你创建的所有 AI 应用。每个应用卡片会显示名称、类型对话/工作流、最近修改时间。创建应用点击后你需要做出第一个重要选择——应用类型。对话型应用类似于 ChatGPT 的交互模式。用户输入问题AI 直接给出回答。适合简单的问答、聊天、基于提示词的文本生成。其底层是一个预设的、简化的工作流。工作流应用进入强大的可视化工作流编辑器。你可以通过拖拽节点来设计复杂的、多步骤的 AI 业务流程。这是 Dify 最核心的竞争力所在。提示词编排部分版本对于对话型应用这里可以精细地调试和优化系统提示词Prompt。工作流工作流列表这里管理所有你创建的、可复用的工作流蓝图。你可以把工作流理解为一个“函数”或“流程模板”它可以被多个“应用”调用。工作流编辑器点击进入后你会看到一个画布。左侧是节点库中间是编排区右侧是节点参数配置区。这是你施展创造力的主战场。知识库知识库列表管理所有你创建的知识库。每个知识库可以包含多个文档。创建知识库为知识库命名并选择嵌入模型和向量数据库。Dify 通常内置了默认选项如text-embedding-ada-002和内置向量库对于入门完全够用。文档管理进入知识库后可以上传文档、查看处理状态分段、向量化、进行检索测试。工具自定义工具这里可以创建两种工具API 工具通过配置 HTTP 请求URL、Method、Headers、Parameters来封装一个外部 API。函数工具通过编写 Python 代码来创建一个工具函数。工具列表查看和管理所有已创建的工具。创建好的工具会出现在工作流编辑器的节点库中供你拖拽使用。模型供应商供应商列表查看已配置的所有 LLM 服务商。添加供应商点击“添加模型供应商”选择提供商如 OpenAI、Azure、Ollama填写配置信息。这是能让你的 Dify “活”起来的前提。# 以配置 Ollama本地运行大模型为例在表单中你需要填写 # 供应商: Ollama # 模型名称: 自定义如 llama3.2 # 基础URL: http://host.docker.internal:11434/v1 (如果 Dify 和 Ollama 都运行在本地 Docker) # API密钥: 留空Ollama 通常无需密钥插件市场浏览和安装社区贡献的插件一键扩展平台能力。日志与标注日志按应用查看详细的请求/响应记录包括使用的模型、Token 消耗、耗时。是调试和成本分析的重要依据。标注在日志中可以对 AI 的回答进行“好评/差评”标注或直接编辑修正回答。这些数据对于优化提示词至关重要。成员团队功能邀请团队成员并分配角色权限管理员、开发者、运营者。设置工作空间设置修改工作空间名称、图标等。权限管理更细粒度的权限控制。审计日志记录所有关键操作满足企业合规要求。4.3 中心内容区首页的中心区域通常会显示快捷操作卡片如“创建第一个应用”、“查看文档”。数据概览显示应用数量、知识库数量、近期对话量或 Token 消耗情况云服务版更常见。最近访问快速跳转到你最近编辑的应用或工作流。5. 核心流程实战从零创建一个“智能天气查询助手”现在让我们把上述知识串联起来通过一个简单的实战案例走通 Dify 的核心使用流程。我们的目标是创建一个应用用户输入城市名AI 助手返回该城市的当前天气。5.1 第一步配置模型供应商在构建任何应用前必须确保有可用的“大脑”。点击左侧导航栏【模型供应商】-【添加模型供应商】。选择OpenAI或其他你已拥有 API Key 的供应商。填写配置信息保存。重点如果你使用 Azure OpenAI需要选择Azure OpenAI供应商并填写API Base、API Key和Deployment Name。5.2 第二步创建一个 API 工具获取天气为了让 AI 能获取真实天气我们需要一个工具。点击左侧导航栏【工具】-【创建工具】。选择【API 工具】。填写工具信息工具名称Get City Weather工具描述根据城市名称查询当前天气情况。在请求配置部分我们以一个免费的模拟天气 API 为例实际可使用 OpenWeatherMap 等{ 请求方法: GET, URL: https://api.weatherapi.com/v1/current.json, Headers: { Key: 你的WeatherAPI密钥 }, Parameters: [ { 名称: q, 类型: string, 是否必填: true, 输入方式: 入参, 默认值: , 描述: 城市名称如Beijing } ] }在响应处理部分我们可以编写一段 Python 代码来解析返回的 JSON并提取我们想要的信息# 工具响应处理代码示例 def main(response): # response 是 API 返回的原始响应对象 if response.status_code 200: data response.json() # 提取关键信息 city data[location][name] country data[location][country] temp_c data[current][temp_c] condition data[current][condition][text] # 格式化输出 result f{city}, {country} 的当前天气{condition}温度 {temp_c}°C。 return result else: return f查询失败状态码{response.status_code}点击【创建】。现在这个Get City Weather工具就出现在你的工具列表里了。5.3 第三步创建工作流应用这是核心的编排环节。点击左侧导航栏【应用】-【创建应用】。选择【工作流应用】输入应用名称如智能天气助手。进入工作流编辑器。你会看到一个空的画布左侧是节点库。拖拽节点构建流程从左侧节点库的【输入输出】分类中拖拽一个【对话开场白】节点到画布。在右侧配置区输入欢迎语如“请输入您想查询天气的城市名称”。从【输入输出】分类中拖拽一个【问题】节点。这代表用户输入。从【工具】分类中拖拽我们刚刚创建的【Get City Weather】节点。从【LLM】分类中拖拽一个【LLM】节点。从【输入输出】分类中拖拽一个【回答】节点。连接节点用连线将【对话开场白】连接到【问题】。将【问题】连接到【Get City Weather】节点。连接时需要将【问题】节点的输出变量如query映射到工具的q参数。将【Get City Weather】节点的输出连接到【LLM】节点。这样LLM 就能接收到工具返回的天气文本。将【LLM】节点连接到【回答】节点。在【LLM】节点的系统提示词中可以写“你是一个天气助手请根据工具查询到的天气信息友好地回复用户。”配置 LLM 节点在右侧面板选择你在第一步中配置好的模型供应商和具体模型如gpt-4o-mini。保存工作流。5.4 第四步测试与发布点击画布右上角的【预览】按钮。在右侧弹出的预览窗格中系统会先显示开场白。你输入城市名如“北京”。观察工作流的执行它会依次触发问题节点 - 工具节点调用外部API- LLM节点 - 回答节点。最终你将看到 AI 生成的、包含真实天气信息的友好回复。测试无误后点击顶部的【发布】按钮。发布后这个应用就拥有了一个独立的访问链接URL你可以将其分享给他人使用或嵌入到其他系统中。通过这个简单的例子你实践了“配置模型 - 创建工具 - 编排工作流 - 测试发布”的完整 Dify 应用开发闭环。这远比直接调用 ChatGPT API 复杂但也强大得多因为你将一次性的提示词工程变成了一个可复用、可扩展、可视化的自动化流程。6. 不同场景的快速入口指南面对一个具体需求你应该点击哪里下面是一些常见场景的快速路径你想实现的功能首选入口关键操作后续可能联动做一个类似 ChatGPT 的聊天网页应用 - 创建应用 - 对话型应用配置提示词、选择模型、设置开场白可后续关联知识库使其能回答私有领域问题设计一个多步骤的 AI 流程如分析数据-生成报告-发送邮件应用 - 创建应用 - 工作流应用在工作流编辑器中拖拽节点LLM、代码、条件判断、工具等并连接需要先在工具中配置邮件发送 API或在知识库中上传数据文件让 AI 能回答我公司内部文档的问题知识库 - 创建知识库上传文档PDF/Word/TXT等待处理完成在对话型应用或工作流中添加“知识库检索”节点连接一个外部系统如数据库、CRM工具 - 创建工具根据外部 API 文档配置 HTTP 请求或编写 Python 函数在工作流中调用此工具节点切换或测试不同的大模型GPT/Claude/本地模型模型供应商添加新的供应商配置如 Ollama在应用或工作流的 LLM 节点参数中选择新配置的模型查看我的应用被如何使用优化回答质量日志与标注查看请求记录对不满意的回答进行“编辑”和“标注”根据标注数据返回修改应用的提示词或工作流逻辑与团队成员协作开发同一个 AI 应用成员邀请成员并分配“开发者”角色成员登录后可在同一工作空间内看到并编辑应用7. 常见问题与排查思路初次使用 Dify你可能会遇到以下典型问题问题现象可能原因排查方式解决方案应用/工作流测试时一直显示“正在思考”或报错“模型调用失败”。1. 模型供应商未配置或配置错误API Key 无效、余额不足。2. 网络问题无法访问模型 API 端点。1. 检查【模型供应商】列表确认状态正常。2. 在模型供应商配置页面尝试“测试连接”。3. 查看【日志】中的错误详情。1. 填写正确的 API Key 和 Base URL。2. 对于本地模型如 Ollama确保其服务已启动且网络可通Docker 部署时注意容器网络。3. 检查账户余额或配额。知识库上传文档后检索不到内容或回答不相关。1. 文档未处理完成分词、向量化。2. 检索参数如 Top K设置不当。3. 嵌入模型不适合该语种或领域。1. 进入知识库查看文档处理状态是否为“已完成”。2. 在知识库页面使用“测试”功能输入关键词看返回的文本片段是否相关。3. 检查检索节点中的“相似度阈值”和“返回数量”。1. 等待处理完成大文档需要时间。2. 调整检索参数或优化文档如拆分更小的段落。3. 考虑更换或微调嵌入模型高级功能。自定义 API 工具调用失败。1. API 请求配置错误URL、方法、参数。2. 身份验证Headers/Params缺失或错误。3. 网络策略限制如跨域、防火墙。1. 在工具配置页面使用“测试”功能查看原始请求和响应。2. 核对 API 文档确保每个参数名和值都正确。3. 检查响应处理代码是否有语法错误或逻辑错误。1. 使用 Postman 等工具先验证 API 本身可用。2. 仔细对照 API 文档修正配置。3. 对于复杂的响应编写更健壮的 Python 处理代码。工作流运行到某个节点后卡住或逻辑错误。1. 节点间变量传递错误变量名不匹配。2. 条件判断节点IF/ELSE逻辑有误。3. 循环节点陷入死循环。1. 在预览模式下运行观察每个节点的输入/输出数据。2. 检查连线上的变量映射关系。3. 简化工作流分段测试。1. 使用 Debug 模式逐步执行。2. 确保上游节点的输出变量名与下游节点的输入参数名正确绑定。3. 为循环节点设置明确的终止条件。本地部署后无法访问 Web UI。1. 端口映射错误或防火墙未开放。2. Docker 容器未成功启动。3. 资源内存/磁盘不足。1. 使用docker ps查看容器状态。2. 使用docker logs container_name查看启动日志。3. 检查宿主机端口如 3000是否被占用。1. 确保docker-compose.yml中端口映射正确如3000:3000。2. 根据日志错误解决依赖问题如数据库连接失败。3. 增加系统资源或检查.env配置文件。8. 最佳实践与工程建议掌握了基本操作后遵循一些最佳实践能让你的 Dify 之旅更顺畅。从简单开始迭代复杂不要一开始就设计包含十几个节点的庞大工作流。先构建一个最小可行流程如用户输入 - LLM 回复测试通后再逐步添加工具调用、条件分支、知识库检索等复杂功能。善用变量与上下文工作流中节点的输出可以赋值给变量供下游节点使用。给变量起一个清晰的名字如user_question,weather_result,final_answer并在连接节点时仔细检查映射关系这是保证流程正确的关键。提示词工程仍在工作流中至关重要即使在可视化工作流中LLM 节点的“系统提示词”和“用户提示词”依然是控制 AI 行为的核心。编写清晰、具体、带有示例的提示词能极大提升效果。测试驱动开发充分利用工作流的【预览】功能。对于关键分支设计不同的测试输入确保每个逻辑路径都能按预期执行。预览时的节点执行详情是强大的调试工具。版本管理与发布Dify 支持应用版本管理。在做出重大修改前可以先发布一个版本然后再进行修改。这样如果新版本有问题可以快速回滚到稳定版本。关注成本与性能在【日志】中密切关注每次调用的 Token 消耗和耗时。对于高频应用优化提示词、选择性价比更高的模型、缓存知识库检索结果都是控制成本、提升响应速度的有效手段。安全与权限API 密钥管理不要在代码或配置文件中硬编码 API Key。Dify 在模型供应商配置中集中管理相对安全。对于团队严格控制“管理员”权限。工具权限谨慎开放自定义工具的执行权限特别是涉及数据写入或删除的操作。知识库数据上传敏感文档到知识库时注意访问权限设置如果平台支持。本地部署的维护定期备份数据库特别是 PostgreSQL 容器关注 GitHub 上的版本更新和安全公告及时升级。9. 总结与后续学习方向至此你已经完成了对 Dify 平台从账号开通到界面核心功能的全景式导览。我们不仅认识了每个按钮的位置更重要的是理解了它们背后的逻辑Dify 通过“应用”作为产品外壳“工作流”作为逻辑引擎“知识库”作为记忆体“工具”作为扩展手脚辅以模型、插件、日志等支持系统构建了一个完整的低代码 AI 应用开发与运维环境。你的学习路径已经清晰第一步本文“认路”。熟悉控制台知道什么功能在哪里。第二步后续“深挖单点”。选择你最感兴趣的方向深入如果你想做智能客服/知识库问答下一步应深入研究【知识库】的文档处理、分段策略、检索优化以及如何在对话应用中高效集成检索。如果你想做自动化流程/智能体下一步应精学【工作流】编辑器掌握条件判断、循环、变量赋值、并行处理等高级节点的用法并学习如何设计稳健的 Agent 决策逻辑。如果你想做业务系统集成下一步应钻研【工具】开发学习如何通过 API 或代码封装复杂的业务逻辑并处理好认证、错误重试等问题。第三步“综合实践”。尝试复现一个完整的业务场景例如“用户上传产品手册PDF - 自动提取摘要并生成营销文案 - 调用工具发送到社交媒体草稿箱”。这将串联起知识库、工作流和工具多个模块。Dify 的强大之处在于它将 AI 应用开发中繁琐的工程部分服务部署、API 编排、上下文管理、日志监控封装起来让你能专注于创意和逻辑本身。现在控制台的大门已经为你打开从创建一个简单的问候应用开始逐步将你的 AI 想法变为现实吧。建议收藏本文在后续实践中如遇界面迷茫可随时返回查阅这张“功能地图”。
Dify 平台界面导览：从零到一掌握 AI 应用构建核心模块
如果你已经完成了 Dify 的本地部署或正在使用其云服务登录后面对一个全新的界面是不是感觉有点无从下手左边是“应用”右边是“工作流”中间还有“知识库”和“工具”每个菜单下又有一堆子选项。很多开发者朋友在兴奋地搭建好环境后往往就卡在了这一步这个强大的 AI 应用构建平台到底应该从哪里开始用起这恰恰是学习任何新工具时最关键的“破冰”环节。界面导览不是简单的功能罗列它决定了你能否快速理解 Dify 的设计哲学从而高效地将你的 AI 想法转化为实际应用。如果一开始就点错了地方可能会在后续开发中走很多弯路比如试图用“对话型应用”去实现一个需要多步骤决策的复杂流程或者把本应放在“知识库”里管理的文档硬塞进提示词里。本文将带你完成从“注册/登录”到“全局掌控”的完整旅程。我们不会平铺直叙地介绍每个按钮而是会围绕一个核心问题展开如何通过理解 Dify 的界面布局快速定位到你实现 AI 想法所需的核心功能模块我们将把官方文档的骨架填充上真实的使用场景和操作逻辑让你在 10 分钟内不仅“看到”界面更能“看懂”其背后的设计意图为后续构建智能体、工作流或 RAG 应用打下坚实基础。1. 这篇文章真正要解决的问题很多技术教程会跳过“入门”这一步直接进入“如何构建一个 RAG 问答机器人”或“创建一个复杂的工作流”。但对于一个像 Dify 这样功能集成的平台跳过对控制台的整体认知就像不看地图就闯进一座功能复杂的大楼你可能会找到厕所但永远找不到那个藏着关键工具的“307会议室”。本文要解决的核心问题是帮助开发者和 AI 应用构建者在成功部署或登录 Dify 后快速建立对平台功能架构的全局认知并明确后续不同开发任务的正确入口。具体来说我们将拆解三个层次路径选择云服务与本地部署登录后看到的第一屏有何不同如何完成初始账号设置模块解析控制台首页的“应用”、“工作流”、“知识库”、“工具”等核心模块分别对应解决哪类问题它们之间的关系是什么场景映射当我想实现一个“智能客服”、“自动报告生成器”或“私有知识库助手”时我应该从哪个模块开始后续可能需要联动哪些模块通过解决这些问题你将摆脱对界面的陌生感能够自主规划在 Dify 上实现任何 AI 应用的路径图。2. Dify 核心模块全景解读不止是菜单更是产品哲学在深入点击之前我们需要理解 Dify 界面布局背后的逻辑。Dify 将自己定位为“生产就绪的智能体工作流构建平台”这意味着它的设计是围绕“构建可发布的 AI 应用”这个核心目标展开的。其界面可以大致分为四个核心功能层理解了这几层关系你就读懂了 Dify。2.1 核心功能层一构建层Build这是你花费最多时间的地方直接对应着控制台左侧导航栏最上方的几个核心菜单。应用这是 Dify 的“应用”单元。你在这里创建和管理一个个独立的 AI 应用实例。每个应用都有独立的配置、访问地址和对话历史。它更像是一个“项目”或“产品”的容器。工作流这是 Dify 的“引擎”单元。工作流采用可视化拖拽的方式将大型语言模型、代码执行、条件判断、API 调用等节点连接起来形成复杂的、多步骤的 AI 处理流水线。一个“应用”可以包含一个或多个“工作流”。知识库这是 Dify 的“记忆”单元。用于上传、处理和管理你的私有文档如 TXT, PDF, Word, Markdown并通过向量化技术构建可供 LLM 检索的智能知识库。工作流或对话应用可以调用知识库实现基于私有数据的问答RAG。工具这是 Dify 的“扩展”单元。你可以在这里配置和管理外部 API、函数或插件比如天气查询、数据库连接、图像处理等。配置好的工具可以被工作流或智能体调用极大地扩展了 AI 应用的能力边界。它们的关系是你通常先创建一个“应用”然后为这个应用设计“工作流”逻辑。在工作流中你可以插入“知识库检索”节点来获取私有信息也可以调用配置好的“工具”来执行外部操作。2.2 核心功能层二配置层Configure这一层为构建层提供“燃料”和“规则”。模型供应商这是 Dify 的“大脑”供应商列表。你需要在这里配置 OpenAI、Azure OpenAI、Anthropic、Ollama本地模型、通义千问等各类 LLM 服务的 API 密钥和端点。只有配置了模型你的应用和工作流才有“智能”可以调用。插件市场这是“工具”的扩展来源。你可以从这里发现和安装社区或官方提供的预制插件快速获得新能力而无需从零开始编写 API 集成代码。2.3 核心功能层三运营层Operate应用构建完成后你需要观察和管理它。日志与标注在这里查看应用的所有请求和响应记录对回答进行人工标注和修正这些数据可以用于后续的模型微调或提示词优化。数据集有时与知识库关联管理用于模型微调或评估的文本数据集。2.4 核心功能层四管理层Manage这部分主要涉及团队协作和系统设置。成员在团队版或企业版中管理可以访问该工作空间的成员及其权限如开发者、运营者、只读成员。设置包含工作空间设置、模型权限管理、审计日志等高级功能。理解了这个四层架构再看 Dify 的界面你就不会觉得它是一堆杂乱的功能堆砌而是一个有明确分工和协作关系的生产流水线。3. 第一步开通账号与登录根据你选择的使用方式第一步的操作略有不同。3.1 使用 Dify Cloud云服务这是最快捷的入门方式适合快速体验和原型验证。访问官网打开 Dify 官方网站。注册账号点击“Get Started”或“开始使用”通常可以使用邮箱、GitHub 或 Google 账号进行注册。初始设置首次登录后系统可能会引导你创建工作空间为你的项目或团队创建一个独立的环境。配置模型这是最关键的一步。系统会提示你添加第一个模型供应商例如 OpenAI。你需要输入有效的 API Key。# 这是一个概念示例实际是在网页表单中填写 # 供应商OpenAI # 模型名称GPT-4o # API Keysk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx选择模板Dify 可能会提供一些应用模板如客服机器人、内容生成器你可以选择跳过或基于模板创建。3.2 访问本地部署的 Dify如果你在本地服务器或自有云主机上部署了 Dify流程更简单。获取访问地址根据你的部署方式Docker Compose, Kubernetes 等通过服务器 IP 和端口访问 Dify Web UI。例如http://your-server-ip:3000。首次登录如果是全新安装首次访问会进入初始化设置页面。你需要设置一个管理员账号邮箱和密码。随后同样需要进入“模型供应商”配置你的 LLM。后续登录之后每次访问该地址直接使用设置的管理员账号或已添加的成员账号登录即可。关键区别云服务版帮你管理了服务器、网络和更新开箱即用本地部署版让你拥有全部数据和控制的自主权但需要自行维护。对于企业级应用或对数据隐私要求极高的场景本地部署是必选项。4. 控制台首页导览你的 AI 应用指挥中心成功登录后你会看到 Dify 的控制台首页。我们以最新版本的典型布局为例进行解析。4.1 顶部导航栏位于页面最上方通常包含工作空间切换器如果你有多个工作空间如“个人项目”、“公司团队”可以在这里快速切换。不同工作空间的应用、知识库完全隔离。快捷创建按钮“创建应用”/“新建工作流”最显眼的行动号召按钮从这里开始你的构建之旅。用户头像/菜单点击可查看账户信息、切换主题深色/浅色、查看文档、退出登录等。4.2 左侧主导航栏这是核心功能区我们逐一拆解应用我的应用列出你创建的所有 AI 应用。每个应用卡片会显示名称、类型对话/工作流、最近修改时间。创建应用点击后你需要做出第一个重要选择——应用类型。对话型应用类似于 ChatGPT 的交互模式。用户输入问题AI 直接给出回答。适合简单的问答、聊天、基于提示词的文本生成。其底层是一个预设的、简化的工作流。工作流应用进入强大的可视化工作流编辑器。你可以通过拖拽节点来设计复杂的、多步骤的 AI 业务流程。这是 Dify 最核心的竞争力所在。提示词编排部分版本对于对话型应用这里可以精细地调试和优化系统提示词Prompt。工作流工作流列表这里管理所有你创建的、可复用的工作流蓝图。你可以把工作流理解为一个“函数”或“流程模板”它可以被多个“应用”调用。工作流编辑器点击进入后你会看到一个画布。左侧是节点库中间是编排区右侧是节点参数配置区。这是你施展创造力的主战场。知识库知识库列表管理所有你创建的知识库。每个知识库可以包含多个文档。创建知识库为知识库命名并选择嵌入模型和向量数据库。Dify 通常内置了默认选项如text-embedding-ada-002和内置向量库对于入门完全够用。文档管理进入知识库后可以上传文档、查看处理状态分段、向量化、进行检索测试。工具自定义工具这里可以创建两种工具API 工具通过配置 HTTP 请求URL、Method、Headers、Parameters来封装一个外部 API。函数工具通过编写 Python 代码来创建一个工具函数。工具列表查看和管理所有已创建的工具。创建好的工具会出现在工作流编辑器的节点库中供你拖拽使用。模型供应商供应商列表查看已配置的所有 LLM 服务商。添加供应商点击“添加模型供应商”选择提供商如 OpenAI、Azure、Ollama填写配置信息。这是能让你的 Dify “活”起来的前提。# 以配置 Ollama本地运行大模型为例在表单中你需要填写 # 供应商: Ollama # 模型名称: 自定义如 llama3.2 # 基础URL: http://host.docker.internal:11434/v1 (如果 Dify 和 Ollama 都运行在本地 Docker) # API密钥: 留空Ollama 通常无需密钥插件市场浏览和安装社区贡献的插件一键扩展平台能力。日志与标注日志按应用查看详细的请求/响应记录包括使用的模型、Token 消耗、耗时。是调试和成本分析的重要依据。标注在日志中可以对 AI 的回答进行“好评/差评”标注或直接编辑修正回答。这些数据对于优化提示词至关重要。成员团队功能邀请团队成员并分配角色权限管理员、开发者、运营者。设置工作空间设置修改工作空间名称、图标等。权限管理更细粒度的权限控制。审计日志记录所有关键操作满足企业合规要求。4.3 中心内容区首页的中心区域通常会显示快捷操作卡片如“创建第一个应用”、“查看文档”。数据概览显示应用数量、知识库数量、近期对话量或 Token 消耗情况云服务版更常见。最近访问快速跳转到你最近编辑的应用或工作流。5. 核心流程实战从零创建一个“智能天气查询助手”现在让我们把上述知识串联起来通过一个简单的实战案例走通 Dify 的核心使用流程。我们的目标是创建一个应用用户输入城市名AI 助手返回该城市的当前天气。5.1 第一步配置模型供应商在构建任何应用前必须确保有可用的“大脑”。点击左侧导航栏【模型供应商】-【添加模型供应商】。选择OpenAI或其他你已拥有 API Key 的供应商。填写配置信息保存。重点如果你使用 Azure OpenAI需要选择Azure OpenAI供应商并填写API Base、API Key和Deployment Name。5.2 第二步创建一个 API 工具获取天气为了让 AI 能获取真实天气我们需要一个工具。点击左侧导航栏【工具】-【创建工具】。选择【API 工具】。填写工具信息工具名称Get City Weather工具描述根据城市名称查询当前天气情况。在请求配置部分我们以一个免费的模拟天气 API 为例实际可使用 OpenWeatherMap 等{ 请求方法: GET, URL: https://api.weatherapi.com/v1/current.json, Headers: { Key: 你的WeatherAPI密钥 }, Parameters: [ { 名称: q, 类型: string, 是否必填: true, 输入方式: 入参, 默认值: , 描述: 城市名称如Beijing } ] }在响应处理部分我们可以编写一段 Python 代码来解析返回的 JSON并提取我们想要的信息# 工具响应处理代码示例 def main(response): # response 是 API 返回的原始响应对象 if response.status_code 200: data response.json() # 提取关键信息 city data[location][name] country data[location][country] temp_c data[current][temp_c] condition data[current][condition][text] # 格式化输出 result f{city}, {country} 的当前天气{condition}温度 {temp_c}°C。 return result else: return f查询失败状态码{response.status_code}点击【创建】。现在这个Get City Weather工具就出现在你的工具列表里了。5.3 第三步创建工作流应用这是核心的编排环节。点击左侧导航栏【应用】-【创建应用】。选择【工作流应用】输入应用名称如智能天气助手。进入工作流编辑器。你会看到一个空的画布左侧是节点库。拖拽节点构建流程从左侧节点库的【输入输出】分类中拖拽一个【对话开场白】节点到画布。在右侧配置区输入欢迎语如“请输入您想查询天气的城市名称”。从【输入输出】分类中拖拽一个【问题】节点。这代表用户输入。从【工具】分类中拖拽我们刚刚创建的【Get City Weather】节点。从【LLM】分类中拖拽一个【LLM】节点。从【输入输出】分类中拖拽一个【回答】节点。连接节点用连线将【对话开场白】连接到【问题】。将【问题】连接到【Get City Weather】节点。连接时需要将【问题】节点的输出变量如query映射到工具的q参数。将【Get City Weather】节点的输出连接到【LLM】节点。这样LLM 就能接收到工具返回的天气文本。将【LLM】节点连接到【回答】节点。在【LLM】节点的系统提示词中可以写“你是一个天气助手请根据工具查询到的天气信息友好地回复用户。”配置 LLM 节点在右侧面板选择你在第一步中配置好的模型供应商和具体模型如gpt-4o-mini。保存工作流。5.4 第四步测试与发布点击画布右上角的【预览】按钮。在右侧弹出的预览窗格中系统会先显示开场白。你输入城市名如“北京”。观察工作流的执行它会依次触发问题节点 - 工具节点调用外部API- LLM节点 - 回答节点。最终你将看到 AI 生成的、包含真实天气信息的友好回复。测试无误后点击顶部的【发布】按钮。发布后这个应用就拥有了一个独立的访问链接URL你可以将其分享给他人使用或嵌入到其他系统中。通过这个简单的例子你实践了“配置模型 - 创建工具 - 编排工作流 - 测试发布”的完整 Dify 应用开发闭环。这远比直接调用 ChatGPT API 复杂但也强大得多因为你将一次性的提示词工程变成了一个可复用、可扩展、可视化的自动化流程。6. 不同场景的快速入口指南面对一个具体需求你应该点击哪里下面是一些常见场景的快速路径你想实现的功能首选入口关键操作后续可能联动做一个类似 ChatGPT 的聊天网页应用 - 创建应用 - 对话型应用配置提示词、选择模型、设置开场白可后续关联知识库使其能回答私有领域问题设计一个多步骤的 AI 流程如分析数据-生成报告-发送邮件应用 - 创建应用 - 工作流应用在工作流编辑器中拖拽节点LLM、代码、条件判断、工具等并连接需要先在工具中配置邮件发送 API或在知识库中上传数据文件让 AI 能回答我公司内部文档的问题知识库 - 创建知识库上传文档PDF/Word/TXT等待处理完成在对话型应用或工作流中添加“知识库检索”节点连接一个外部系统如数据库、CRM工具 - 创建工具根据外部 API 文档配置 HTTP 请求或编写 Python 函数在工作流中调用此工具节点切换或测试不同的大模型GPT/Claude/本地模型模型供应商添加新的供应商配置如 Ollama在应用或工作流的 LLM 节点参数中选择新配置的模型查看我的应用被如何使用优化回答质量日志与标注查看请求记录对不满意的回答进行“编辑”和“标注”根据标注数据返回修改应用的提示词或工作流逻辑与团队成员协作开发同一个 AI 应用成员邀请成员并分配“开发者”角色成员登录后可在同一工作空间内看到并编辑应用7. 常见问题与排查思路初次使用 Dify你可能会遇到以下典型问题问题现象可能原因排查方式解决方案应用/工作流测试时一直显示“正在思考”或报错“模型调用失败”。1. 模型供应商未配置或配置错误API Key 无效、余额不足。2. 网络问题无法访问模型 API 端点。1. 检查【模型供应商】列表确认状态正常。2. 在模型供应商配置页面尝试“测试连接”。3. 查看【日志】中的错误详情。1. 填写正确的 API Key 和 Base URL。2. 对于本地模型如 Ollama确保其服务已启动且网络可通Docker 部署时注意容器网络。3. 检查账户余额或配额。知识库上传文档后检索不到内容或回答不相关。1. 文档未处理完成分词、向量化。2. 检索参数如 Top K设置不当。3. 嵌入模型不适合该语种或领域。1. 进入知识库查看文档处理状态是否为“已完成”。2. 在知识库页面使用“测试”功能输入关键词看返回的文本片段是否相关。3. 检查检索节点中的“相似度阈值”和“返回数量”。1. 等待处理完成大文档需要时间。2. 调整检索参数或优化文档如拆分更小的段落。3. 考虑更换或微调嵌入模型高级功能。自定义 API 工具调用失败。1. API 请求配置错误URL、方法、参数。2. 身份验证Headers/Params缺失或错误。3. 网络策略限制如跨域、防火墙。1. 在工具配置页面使用“测试”功能查看原始请求和响应。2. 核对 API 文档确保每个参数名和值都正确。3. 检查响应处理代码是否有语法错误或逻辑错误。1. 使用 Postman 等工具先验证 API 本身可用。2. 仔细对照 API 文档修正配置。3. 对于复杂的响应编写更健壮的 Python 处理代码。工作流运行到某个节点后卡住或逻辑错误。1. 节点间变量传递错误变量名不匹配。2. 条件判断节点IF/ELSE逻辑有误。3. 循环节点陷入死循环。1. 在预览模式下运行观察每个节点的输入/输出数据。2. 检查连线上的变量映射关系。3. 简化工作流分段测试。1. 使用 Debug 模式逐步执行。2. 确保上游节点的输出变量名与下游节点的输入参数名正确绑定。3. 为循环节点设置明确的终止条件。本地部署后无法访问 Web UI。1. 端口映射错误或防火墙未开放。2. Docker 容器未成功启动。3. 资源内存/磁盘不足。1. 使用docker ps查看容器状态。2. 使用docker logs container_name查看启动日志。3. 检查宿主机端口如 3000是否被占用。1. 确保docker-compose.yml中端口映射正确如3000:3000。2. 根据日志错误解决依赖问题如数据库连接失败。3. 增加系统资源或检查.env配置文件。8. 最佳实践与工程建议掌握了基本操作后遵循一些最佳实践能让你的 Dify 之旅更顺畅。从简单开始迭代复杂不要一开始就设计包含十几个节点的庞大工作流。先构建一个最小可行流程如用户输入 - LLM 回复测试通后再逐步添加工具调用、条件分支、知识库检索等复杂功能。善用变量与上下文工作流中节点的输出可以赋值给变量供下游节点使用。给变量起一个清晰的名字如user_question,weather_result,final_answer并在连接节点时仔细检查映射关系这是保证流程正确的关键。提示词工程仍在工作流中至关重要即使在可视化工作流中LLM 节点的“系统提示词”和“用户提示词”依然是控制 AI 行为的核心。编写清晰、具体、带有示例的提示词能极大提升效果。测试驱动开发充分利用工作流的【预览】功能。对于关键分支设计不同的测试输入确保每个逻辑路径都能按预期执行。预览时的节点执行详情是强大的调试工具。版本管理与发布Dify 支持应用版本管理。在做出重大修改前可以先发布一个版本然后再进行修改。这样如果新版本有问题可以快速回滚到稳定版本。关注成本与性能在【日志】中密切关注每次调用的 Token 消耗和耗时。对于高频应用优化提示词、选择性价比更高的模型、缓存知识库检索结果都是控制成本、提升响应速度的有效手段。安全与权限API 密钥管理不要在代码或配置文件中硬编码 API Key。Dify 在模型供应商配置中集中管理相对安全。对于团队严格控制“管理员”权限。工具权限谨慎开放自定义工具的执行权限特别是涉及数据写入或删除的操作。知识库数据上传敏感文档到知识库时注意访问权限设置如果平台支持。本地部署的维护定期备份数据库特别是 PostgreSQL 容器关注 GitHub 上的版本更新和安全公告及时升级。9. 总结与后续学习方向至此你已经完成了对 Dify 平台从账号开通到界面核心功能的全景式导览。我们不仅认识了每个按钮的位置更重要的是理解了它们背后的逻辑Dify 通过“应用”作为产品外壳“工作流”作为逻辑引擎“知识库”作为记忆体“工具”作为扩展手脚辅以模型、插件、日志等支持系统构建了一个完整的低代码 AI 应用开发与运维环境。你的学习路径已经清晰第一步本文“认路”。熟悉控制台知道什么功能在哪里。第二步后续“深挖单点”。选择你最感兴趣的方向深入如果你想做智能客服/知识库问答下一步应深入研究【知识库】的文档处理、分段策略、检索优化以及如何在对话应用中高效集成检索。如果你想做自动化流程/智能体下一步应精学【工作流】编辑器掌握条件判断、循环、变量赋值、并行处理等高级节点的用法并学习如何设计稳健的 Agent 决策逻辑。如果你想做业务系统集成下一步应钻研【工具】开发学习如何通过 API 或代码封装复杂的业务逻辑并处理好认证、错误重试等问题。第三步“综合实践”。尝试复现一个完整的业务场景例如“用户上传产品手册PDF - 自动提取摘要并生成营销文案 - 调用工具发送到社交媒体草稿箱”。这将串联起知识库、工作流和工具多个模块。Dify 的强大之处在于它将 AI 应用开发中繁琐的工程部分服务部署、API 编排、上下文管理、日志监控封装起来让你能专注于创意和逻辑本身。现在控制台的大门已经为你打开从创建一个简单的问候应用开始逐步将你的 AI 想法变为现实吧。建议收藏本文在后续实践中如遇界面迷茫可随时返回查阅这张“功能地图”。
