★ FEATURED ARTICLE 一、引言这两年大模型发展非常快。从最开始的“调用一下 GPT让它帮我生成一段文本。”逐渐发展到“让 AI 读取公司内部知识库根据业务规则进行分析然后调用接口完成任务。”这时候问题就来了。如果只是调用一次 LLM API其实非常简单constresponseawaitfetch(/api/chat,{method:POST,headers:{Content-Type:application/json},body:JSON.stringify({model:xxx,messages:[{role:user,content:帮我分析一下这份需求}]})})constresultawaitresponse.json()console.log(result)但真正的 AI 应用通常远比这个复杂。例如一个企业内部的“智能知识助手”可能需要用户问题 ↓ 意图识别 ↓ 查询知识库 ↓ 召回相关文档 ↓ 构造 Prompt ↓ 调用大模型 ↓ 判断是否需要调用工具 ↓ 调用业务 API ↓ 整理结果 ↓ 返回给用户如果全部自己开发需要处理LLM API 接入Prompt 管理多模型适配RAG向量数据库WorkflowAgentTool Calling上下文管理日志调试监控权限API 封装对于一个前端工程师来说光是把这些基础设施搭起来就已经是一项不小的工作。这也是 Dify 出现的意义。Dify 官方将其定位为一个用于开发 LLM 应用的平台将 Workflow、RAG、Agent、模型管理、可观测性以及 API 能力整合在一起。([GitHub][1])所以我更愿意把 Dify 理解成一个面向 AI 应用的可视化编排层。它并不是“大模型本身”。它更像是┌──────────────┐ │ 用户 / 前端 │ └──────┬───────┘ ↓ ┌──────────────┐ │ Dify │ │ AI 应用编排层 │ └──────┬───────┘ ↓ ┌─────────────┼─────────────┐ ↓ ↓ ↓ LLM RAG Agent ↓ ↓ ↓ GPT/国产模型 知识库 Tools/API二、需求背景为什么需要 Dify2.1 直接调用大模型其实只是第一步假设我们正在开发一个企业内部 AI 助手。最简单的需求可能是用户输入问题 → AI 返回答案。代码可能只有几十行。但是产品很快就会开始增加需求。比如第一阶段普通 Chat用户 ↓ LLM ↓ 答案第二阶段加入企业知识库用户 ↓ 知识库检索 ↓ 相关文档 ↓ LLM ↓ 答案第三阶段加入业务系统用户 ↓ AI ↓ 判断用户意图 ↓ 调用业务 API ↓ 返回结果第四阶段Agent用户 ↓ Agent ↓ 思考 ↓ 选择工具 ↓ 调用工具 ↓ 观察结果 ↓ 继续思考 ↓ 最终回答这时候系统已经不是简单的 Chat API 了。它实际上变成了一套AI Application Runtime。三、Dify 到底是什么一句话Dify 是一个帮助开发者构建、编排、部署和管理 LLM 应用的平台。它把很多原本需要自己写代码实现的能力进行了平台化封装。目前 Dify 的核心能力主要包括能力作用Model管理不同大模型Prompt管理提示词Workflow可视化编排 AI 流程RAG企业知识库检索Agent让模型自主选择工具Tool给 AI 提供外部能力API将 AI 应用暴露给业务系统Observability查看调用过程和运行情况Dify 官方仓库也将 Workflow、RAG Pipeline、Agent、模型管理、LLMOps 和 API 能力作为核心组成部分。([GitHub][2])四、Dify 的核心工作原理如果从工程师角度来看可以把 Dify 理解成下面这个架构用户 │ ▼ ┌───────────┐ │ 前端应用 │ └─────┬─────┘ │ HTTP API ▼ ┌───────────┐ │ Dify │ └─────┬─────┘ │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ Workflow Agent Chat │ │ │ ├──────► Tool │ │ ▼ ▼ RAG LLM │ │ ▼ ▼ Knowledge Model Base Provider其中最重要的是三个概念Workflow、RAG、Agent五、Workflow把 AI 应用变成一条流水线Workflow 是 Dify 非常重要的能力。如果你熟悉前端可以把 Workflow 理解成一种可视化的函数调用链。例如开始 ↓ 获取用户问题 ↓ 意图分类 ↓ 知识库检索 ↓ Prompt Template ↓ LLM ↓ 输出如果自己使用 JavaScript 实现大概是asyncfunctionexecuteWorkflow(question){constintentawaitclassifyIntent(question)constdocumentsawaitsearchKnowledgeBase(question)constpromptbuildPrompt({question,intent,documents})constanswerawaitcallLLM(prompt)returnanswer}而 Dify 做的事情是把这些步骤变成可视化节点。最终你看到的可能是┌────────┐ │ Start │ └───┬────┘ ↓ ┌────────────┐ │ 意图识别 │ └─────┬──────┘ ↓ ┌────────────┐ │ 知识库检索 │ └─────┬──────┘ ↓ ┌────────────┐ │ LLM │ └─────┬──────┘ ↓ ┌────────────┐ │ End │ └────────────┘这对于业务人员、产品经理以及非 AI 专业开发人员来说非常友好。六、RAG为什么企业 AI 几乎绕不开知识库大模型有一个天然问题它知道很多东西但它并不知道你公司的内部数据。例如“我们公司的 LIS 系统中检验报告审核规则是什么”通用大模型显然无法直接知道。这时候就需要 RAGRAGRetrieval-Augmented Generation (检索增强生成)它的基本流程是用户问题 ↓ 问题向量化 ↓ 向量检索 ↓ 找到相关文档 ↓ 文档 用户问题 ↓ Prompt ↓ LLM ↓ 答案例如用户 “标本签收之后下一步是什么” ↓ 知识库检索 ↓ 《LIS 标本处理流程》 《标本签收规范》 《检验工作站操作手册》 ↓ 提取相关内容 ↓ LLM ↓ 生成答案Dify 的 RAG 能力覆盖文档导入、文本提取和检索等流程并支持常见文档类型。([GitHub][1])七、AgentDify 真正有意思的地方Workflow 是我提前定义好流程让 AI 按流程执行。Agent 则是我给 AI 一组工具让 AI 根据任务决定下一步做什么。这是两个完全不同的思路。例如我们给 Agent 三个工具searchKnowledge() getPatientInfo() createReport()用户说“帮我查询一下张三最近一次的检验结果。”Agent 可能执行用户问题 ↓ Agent ↓ 判断需要查询患者信息 ↓ getPatientInfo() ↓ 获取患者 ID ↓ 判断需要查询检验结果 ↓ getLabResult() ↓ 整理结果 ↓ 返回用户这就是 Agent 的核心。八、Agent 的核心Tool Calling从开发者角度理解 Agent其实没有那么玄学。本质上还是LLM Tools Context Decision Loop例如consttools[{name:getUserInfo,description:根据用户 ID 查询用户信息},{name:getOrderInfo,description:根据订单 ID 查询订单信息}]然后模型根据用户的问题判断用户 “帮我查询订单 10001 的状态” ↓ LLM ↓ 选择 getOrderInfo ↓ 调用 API ↓ 得到 { orderId: 10001, status: 已发货 } ↓ LLM ↓ “订单 10001 当前已经发货。”所以从工程实现角度来说Agent 并不是一个神秘的“会思考的人”。它本质上是LLM 工具 上下文 循环执行机制。Dify 支持基于 Function Calling 或 ReAct 思路构建 Agent并允许配置工具。([GitHub][1])九、代码实现前端如何调用 Dify对于前端开发者来说最重要的一点其实是Dify 不需要替代你的前端应用。完全可以把 Dify 当成一个 AI Backend。架构Vue / React │ │ HTTP ▼ Dify API │ ├── Workflow ├── RAG ├── Agent └── LLM例如前端封装一个 Dify 请求asyncfunctionchatWithDify(query){constresponseawaitfetch(/api/dify/chat-messages,{method:POST,headers:{Content-Type:application/json,Authorization:Bearer${import.meta.env.VITE_DIFY_API_KEY}},body:JSON.stringify({inputs:{},query,response_mode:blocking,user:frontend-user})})if(!response.ok){thrownewError(Dify 请求失败)}returnresponse.json()}然后在 Vue 中constresultawaitchatWithDify(请帮我分析一下这个检验结果)console.log(result)这样前端实际上完全不需要关心使用 GPT 还是其他模型Prompt 怎么写RAG 怎么检索Agent 怎么调用工具Workflow 怎么编排前端只需要输入 ↓ API ↓ 输出这就是 Dify 非常适合企业应用的原因之一。十、不要把 Dify API Key 直接暴露给浏览器这里有一个非常重要的工程问题。不要这样fetch(https://your-dify-server/v1/chat-messages,{headers:{Authorization:Bearer app-xxxxxxxx}})因为浏览器端的 API Key 最终都可能暴露。更合理的架构是Vue ↓ 业务后端 ↓ Dify ↓ LLM例如asyncfunctionchat(query){constresponseawaitfetch(/api/ai/chat,{method:POST,headers:{Content-Type:application/json},body:JSON.stringify({query})})returnresponse.json()}后端再调用 DifyasyncfunctioncallDify(query){constresponseawaitfetch(${process.env.DIFY_URL}/v1/chat-messages,{method:POST,headers:{Content-Type:application/json,Authorization:Bearer${process.env.DIFY_API_KEY}},body:JSON.stringify({inputs:{},query,response_mode:blocking,user:system-user})})returnresponse.json()}这样可以把权限 API Key 用户身份 业务参数 审计 限流都放到自己的后端进行控制。十一、StreamingAI 对话为什么经常需要流式输出如果直接使用response_mode:blocking那么用户需要等待整个结果生成完成。体验类似用户提问 ↓ 等待 5 秒 ↓ 一次性显示完整答案而 AI 产品通常希望用户提问 ↓ AI 正在思考... ↓ 正在生成... ↓ 一点一点显示内容这就是 Streaming。前端可以通过 SSE 等方式接收增量内容。例如constresponseawaitfetch(/api/ai/chat,{method:POST,body:JSON.stringify({query:介绍一下 RAG})})constreaderresponse.body.getReader()constdecodernewTextDecoder()while(true){const{done,value}awaitreader.read()if(done){break}constchunkdecoder.decode(value)console.log(chunk)}实际项目中还需要处理SSE 数据分片JSON 解析Markdown 渲染网络断开AbortController重试错误状态会话 ID所以 AI Chat 看起来简单真正做到生产级体验还是有不少工程细节。十二、Dify Agent 的一个完整案例假设我们做一个企业内部智能 IT 助手用户输入“帮我查询一下服务器 192.168.1.100 最近的 CPU 使用情况如果超过 80%告诉我原因。”我们可以设计用户 │ ▼ Agent │ ┌─────────┼─────────┐ │ │ │ ▼ ▼ ▼ 查询服务器 查询监控 查询知识库 │ │ │ └─────────┼─────────┘ ▼ LLM分析 │ ▼ 返回结果工具定义consttools[{name:getServerInfo,description:查询服务器基础信息},{name:getCpuUsage,description:查询服务器 CPU 使用率},{name:searchKnowledge,description:查询服务器故障处理知识库}]Agent 根据情况执行getServerInfo() ↓ getCpuUsage() ↓ CPU 92% ↓ searchKnowledge() ↓ 发现可能原因 - JVM GC - 数据库慢查询 - 高并发请求 ↓ LLM 综合分析 ↓ 返回用户这时候 AI 就不再只是“回答问题。”而是在完成任务。这也是 Agent 应用和普通 Chat 应用之间非常重要的区别。十三、Dify 解决了什么痛点13.1 降低 AI 应用开发门槛传统模式开发者 ↓ LLM SDK ↓ Prompt ↓ 向量数据库 ↓ RAG ↓ Agent ↓ Tool ↓ 日志 ↓ 监控Dify开发者 ↓ Dify ↓ 配置应用当然这并不意味着完全不需要开发。而是把大量通用基础设施从业务代码中抽离出来。十四、解决 Prompt 管理问题很多项目刚开始时Prompt 可能直接写在代码里constprompt你是一名专业的客服助手。 请根据用户的问题进行回答。 如果不知道答案请明确说明。项目一大Prompt 会越来越难管理。Dify 把 Prompt 从业务代码中解耦出来。于是可以变成业务代码 │ ▼ Dify API │ ▼ Prompt │ ▼ LLM这样产品、AI 工程师甚至业务人员可以直接调整 Prompt而不一定需要修改前端代码。十五、解决模型切换问题企业项目很少会永远只使用一个模型。可能今天GPT明天DeepSeek后天Qwen甚至企业内部私有化部署模型如果业务代码直接绑定模型constmodelxxx-model后续切换成本会比较高。而 Dify 提供模型管理层可以把业务应用 ↓ Dify ↓ 模型 Provider ├── OpenAI ├── Anthropic ├── 国产模型 └── OpenAI Compatible业务系统不需要直接感知底层模型。官方项目也强调了对多种模型提供商以及 OpenAI-compatible 模型的支持。([GitHub][3])十六、解决 RAG 开发复杂度如果自己做 RAG需要考虑文件上传 ↓ 文本解析 ↓ 文本切片 ↓ Embedding ↓ 向量数据库 ↓ 相似度搜索 ↓ 召回 ↓ Rerank ↓ Prompt ↓ LLM每一步都有坑。例如文档应该怎么切500 字 1000 字 2000 字又比如Top K 应该设置多少Top 3 Top 5 Top 10Dify 把这些能力进行平台化封装让开发者可以更快速地验证 RAG 应用。十七、解决 AI 应用调试困难传统 AI 应用有一个很头疼的问题为什么模型这次回答错了你可能需要自己记录用户输入 Prompt 模型 Temperature Context 检索结果 Tool Call 模型输出 Token 耗时 错误Dify 提供了应用运行和可观测相关能力可以帮助开发者观察 AI 应用执行过程。官方仓库也将 LLMOps / observability 作为核心能力之一。([GitHub][4])对于 AI 应用来说这一点非常重要。因为传统系统主要 Debug CodeAI 系统还需要 Debug Context。十八、Dify 和传统后端有什么区别可以简单理解传统后端Controller ↓ Service ↓ Repository ↓ DatabaseAI 应用Input ↓ Prompt ↓ Context ↓ LLM ↓ Tool ↓ Workflow ↓ OutputDify 实际上是在 AI 应用领域提供了一层类似Application Runtime Orchestration的能力。十九、Dify 和 LangChain 有什么区别这是很多开发者非常容易混淆的问题。简单来说对比项DifyLangChain定位AI 应用开发平台AI 开发框架开发方式可视化 API代码Workflow强强RAG支持支持Agent支持支持灵活性较高很高上手成本较低较高可视化强相对弱业务系统集成API需要自行实现适合快速原型很适合适合底层控制相对有限更强所以它们并不是简单的“谁替代谁”。可以理解成LangChain 更像 AI 开发 SDK / Framework Dify 更像 AI Application Platform如果你想“我需要高度控制 Agent 的代码逻辑。”LangChain 这类框架会更自然。如果你想“我希望快速搭建一个 AI 应用然后通过 API 集成到现有系统。”Dify 的思路会更直接。二十、Dify 和 FlowiseFlowise 同样属于可视化 AI 应用开发方向。两者都有Workflow RAG Agent LLM Tool Visual Builder但是整体思路有所区别。可以简单理解Dify → 更偏 AI 应用平台 Flowise → 更偏可视化 LLM Flow BuilderDify 官方生态强调 Workflow、RAG、Agent、模型管理、LLMOps 和 API 等完整链路。([GitHub][2])如果企业希望最终把 AI 应用作为业务系统的一部分进行管理那么需要重点关注API 权限 日志 模型管理 知识库 Agent 部署方式而不只是看“节点拖起来是否方便”。二十一、Dify 和直接调用 LLM API这个其实最容易理解。直接调用前端 ↓ 后端 ↓ LLM API优点简单灵活控制权高缺点很多基础能力需要自己开发Dify前端 ↓ 业务后端 ↓ Dify ├── Workflow ├── RAG ├── Agent ├── Tool ├── Model └── Observability ↓ LLMDify 的核心价值不是“让你少写几十行代码”。而是把 AI 应用开发过程中大量重复的基础设施统一起来。二十二、Dify 的局限性当然Dify 也不是万能的。22.1 复杂业务仍然需要代码如果你的业务逻辑非常复杂订单 ↓ 库存 ↓ 支付 ↓ 优惠券 ↓ 事务 ↓ 消息队列这种核心业务逻辑还是应该放在传统后端。不要把所有东西都塞进 Agent。比较合理的是传统业务系统 │ ▼ API │ ▼ Dify │ ▼ AI能力22.2 Agent 并不意味着完全自动化Agent 最大的问题之一就是LLM 输出具有概率性。例如同一个问题第一次 调用 Tool A 第二次 调用 Tool B 第三次 直接回答所以生产环境中的 Agent 需要考虑最大执行次数Tool 权限超时重试数据校验人工确认敏感操作拦截特别是涉及删除 修改 支付 审批 发布这类操作时不应该简单地LLM → 直接执行更合理的是LLM ↓ 生成操作建议 ↓ 权限校验 ↓ 人工确认 ↓ 执行二十三、如果我是前端开发者我会怎么使用 Dify如果你本身是 Vue / React 开发者我比较推荐把 Dify 放在企业业务系统 │ ┌────────┴────────┐ │ │ Vue/React Backend │ │ └────────┬────────┘ ↓ Dify │ ┌─────────┼─────────┐ ↓ ↓ ↓ RAG Agent Workflow │ │ │ └─────────┼─────────┘ ↓ LLM前端主要负责UI ↓ 用户交互 ↓ 会话 ↓ Streaming ↓ Markdown ↓ 文件上传后端负责权限 ↓ 用户身份 ↓ 业务 API ↓ Dify APIDify 负责Prompt ↓ Workflow ↓ RAG ↓ Agent ↓ 模型这样职责会比较清晰。二十四、Dify 最适合什么场景我认为下面这些场景非常适合1. 企业知识库公司制度 产品文档 技术文档 操作手册 FAQ↓RAG2. 智能客服用户问题 ↓ 意图识别 ↓ 知识库 ↓ AI回答3. AI 数据分析用户问题 ↓ Agent ↓ 查询数据库 ↓ 分析数据 ↓ 生成结论4. AI 工作流输入 ↓ 分类 ↓ AI ↓ 调用接口 ↓ 再次判断 ↓ 输出5. 企业内部 AI 助手例如LIS AI 助手 HIS AI 助手 CRM AI 助手 ERP AI 助手 研发 AI 助手 运维 AI 助手这类场景都可以考虑 Dify。二十五、一个前端开发者应该如何理解 Dify如果让我用一句话总结不要把 Dify 理解成一个“拖拉拽 AI 工具”而应该把它理解成一个 AI 应用编排和运行平台。传统应用UI ↓ API ↓ Service ↓ DatabaseAI 应用UI ↓ API ↓ AI Application ↓ ├── Prompt ├── Workflow ├── RAG ├── Agent ├── Tool └── LLMDify 做的就是帮助我们管理下面这一层。二十六、总结AI 应用开发正在经历一个明显的变化。以前会调用 LLM API就可以做一个 AI Demo。现在LLM RAG Workflow Agent Tool 业务系统 Observability才逐渐构成一个真正可用的 AI 应用。Dify 的价值就在这里。它没有试图替代Vue React Node.js Java Python Spring Boot而是在这些技术之上增加了一层AI Application Layer最终形成┌─────────────────────────────┐ │ 前端应用 │ │ Vue / React │ └──────────────┬──────────────┘ │ ▼ ┌─────────────────────────────┐ │ 业务后端 │ │ Java / Node.js │ └──────────────┬──────────────┘ │ ▼ ┌─────────────────────────────┐ │ Dify │ │ │ │ Workflow / RAG / Agent │ │ Prompt / Tool / API │ └──────────────┬──────────────┘ │ ▼ ┌─────────────────────────────┐ │ LLM / Model │ │ GPT / Qwen / DeepSeek / ... │ └─────────────────────────────┘对于前端开发者来说我认为真正值得学习的并不是“Dify 的某一个按钮在哪里。”而是理解整个 AI 应用的技术链路Prompt ↓ Context ↓ RAG ↓ Workflow ↓ Agent ↓ Tool Calling ↓ LLM ↓ Business API当你真正理解这条链路之后Dify、LangChain、Flowise 甚至未来出现的其他 AI 开发平台本质上都只是不同的工程实现方式。AI 应用开发的核心也正在从“调用一个大模型”逐渐转向“设计一套能够让模型参与业务流程的系统”。作者: 王新焱博客: https://blog.csdn.net/qq_34402069时间: 2026年9月22日
阅读完成 · 觉得有帮助？
