企业官网建设流程全解析

一、引言

这两年大模型发展非常快。

从最开始的：

“调用一下 GPT，让它帮我生成一段文本。”

逐渐发展到：

“让 AI 读取公司内部知识库，根据业务规则进行分析，然后调用接口完成任务。”

这时候问题就来了。

如果只是调用一次 LLM API，其实非常简单：

constresponse=awaitfetch('/api/chat',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({model:'xxx',messages:[{role:'user',content:'帮我分析一下这份需求'}]})})constresult=awaitresponse.json()console.log(result)

但真正的 AI 应用通常远比这个复杂。

例如一个企业内部的“智能知识助手”，可能需要：

用户问题 ↓ 意图识别 ↓ 查询知识库 ↓ 召回相关文档 ↓ 构造 Prompt ↓ 调用大模型 ↓ 判断是否需要调用工具 ↓ 调用业务 API ↓ 整理结果 ↓ 返回给用户

如果全部自己开发，需要处理：

• LLM API 接入
• Prompt 管理
• 多模型适配
• RAG
• 向量数据库
• Workflow
• Agent
• Tool Calling
• 上下文管理
• 日志
• 调试
• 监控
• 权限
• API 封装

对于一个前端工程师来说，光是把这些基础设施搭起来，就已经是一项不小的工作。

这也是 Dify 出现的意义。

Dify 官方将其定位为一个用于开发 LLM 应用的平台，将 Workflow、RAG、Agent、模型管理、可观测性以及 API 能力整合在一起。([GitHub][1])

所以我更愿意把 Dify 理解成：

一个面向 AI 应用的可视化编排层。

它并不是“大模型本身”。

它更像是：

┌──────────────┐ │ 用户 / 前端 │ └──────┬───────┘ ↓ ┌──────────────┐ │ Dify │ │ AI 应用编排层 │ └──────┬───────┘ ↓ ┌─────────────┼─────────────┐ ↓ ↓ ↓ LLM RAG Agent ↓ ↓ ↓ GPT/国产模型 知识库 Tools/API

二、需求背景：为什么需要 Dify？

2.1 直接调用大模型其实只是第一步

假设我们正在开发一个企业内部 AI 助手。

最简单的需求可能是：

用户输入问题 → AI 返回答案。

代码可能只有几十行。

但是产品很快就会开始增加需求。

比如：

第一阶段：普通 Chat

用户 ↓ LLM ↓ 答案

第二阶段：加入企业知识库

用户 ↓ 知识库检索 ↓ 相关文档 ↓ LLM ↓ 答案

第三阶段：加入业务系统

用户 ↓ AI ↓ 判断用户意图 ↓ 调用业务 API ↓ 返回结果

第四阶段：Agent

用户 ↓ Agent ↓ 思考 ↓ 选择工具 ↓ 调用工具 ↓ 观察结果 ↓ 继续思考 ↓ 最终回答

这时候，系统已经不是简单的 Chat API 了。

它实际上变成了一套AI Application Runtime。

三、Dify 到底是什么？

一句话：

Dify 是一个帮助开发者构建、编排、部署和管理 LLM 应用的平台。

它把很多原本需要自己写代码实现的能力进行了平台化封装。

目前 Dify 的核心能力主要包括：

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){constintent=awaitclassifyIntent(question)constdocuments=awaitsearchKnowledgeBase(question)constprompt=buildPrompt({question,intent,documents})constanswer=awaitcallLLM(prompt)returnanswer}

而 Dify 做的事情，是把这些步骤变成可视化节点。

最终你看到的可能是：

┌────────┐ │ Start │ └───┬────┘ ↓ ┌────────────┐ │ 意图识别 │ └─────┬──────┘ ↓ ┌────────────┐ │ 知识库检索 │ └─────┬──────┘ ↓ ┌────────────┐ │ LLM │ └─────┬──────┘ ↓ ┌────────────┐ │ End │ └────────────┘

这对于业务人员、产品经理以及非 AI 专业开发人员来说非常友好。

六、RAG：为什么企业 AI 几乎绕不开知识库？

大模型有一个天然问题：

它知道很多东西，但它并不知道你公司的内部数据。

例如：

“我们公司的 LIS 系统中，检验报告审核规则是什么？”

通用大模型显然无法直接知道。

这时候就需要 RAG

RAG：Retrieval-Augmented Generation (检索增强生成)

它的基本流程是：

用户问题 ↓ 问题向量化 ↓ 向量检索 ↓ 找到相关文档 ↓ 文档 + 用户问题 ↓ Prompt ↓ LLM ↓ 答案

例如：

用户： “标本签收之后下一步是什么？” ↓ 知识库检索 ↓ 《LIS 标本处理流程》 《标本签收规范》 《检验工作站操作手册》 ↓ 提取相关内容 ↓ LLM ↓ 生成答案

Dify 的 RAG 能力覆盖文档导入、文本提取和检索等流程，并支持常见文档类型。([GitHub][1])

七、Agent：Dify 真正有意思的地方

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){constresponse=awaitfetch('/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 中：

constresult=awaitchatWithDify('请帮我分析一下这个检验结果')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){constresponse=awaitfetch('/api/ai/chat',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({query})})returnresponse.json()}

后端再调用 Dify：

asyncfunctioncallDify(query){constresponse=awaitfetch(`${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 用户身份 业务参数 审计 限流

都放到自己的后端进行控制。

十一、Streaming：AI 对话为什么经常需要流式输出？

如果直接使用：

response_mode:'blocking'

那么用户需要等待整个结果生成完成。

体验类似：

用户提问 ↓ 等待 5 秒 ↓ 一次性显示完整答案

而 AI 产品通常希望：

用户提问 ↓ AI 正在思考... ↓ 正在生成... ↓ 一点一点显示内容

这就是 Streaming。

前端可以通过 SSE 等方式接收增量内容。

例如：

constresponse=awaitfetch('/api/ai/chat',{method:'POST',body:JSON.stringify({query:'介绍一下 RAG'})})constreader=response.body.getReader()constdecoder=newTextDecoder()while(true){const{done,value}=awaitreader.read()if(done){break}constchunk=decoder.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

甚至企业内部：

私有化部署模型

如果业务代码直接绑定模型：

constmodel='xxx-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 10？

Dify 把这些能力进行平台化封装，让开发者可以更快速地验证 RAG 应用。

十七、解决 AI 应用调试困难

传统 AI 应用有一个很头疼的问题：

为什么模型这次回答错了？

你可能需要自己记录：

用户输入 Prompt 模型 Temperature Context 检索结果 Tool Call 模型输出 Token 耗时 错误

Dify 提供了应用运行和可观测相关能力，可以帮助开发者观察 AI 应用执行过程。官方仓库也将 LLMOps / observability 作为核心能力之一。([GitHub][4])

对于 AI 应用来说，这一点非常重要。

因为：

传统系统主要 Debug Code，AI 系统还需要 Debug Context。

十八、Dify 和传统后端有什么区别？

可以简单理解：

传统后端

Controller ↓ Service ↓ Repository ↓ Database

AI 应用

Input ↓ Prompt ↓ Context ↓ LLM ↓ Tool ↓ Workflow ↓ Output

Dify 实际上是在 AI 应用领域提供了一层类似：

Application Runtime + Orchestration

的能力。

十九、Dify 和 LangChain 有什么区别？

这是很多开发者非常容易混淆的问题。

简单来说：

所以它们并不是简单的“谁替代谁”。

可以理解成：

LangChain 更像： AI 开发 SDK / Framework Dify 更像： AI Application Platform

如果你想：

“我需要高度控制 Agent 的代码逻辑。”

LangChain 这类框架会更自然。

如果你想：

“我希望快速搭建一个 AI 应用，然后通过 API 集成到现有系统。”

Dify 的思路会更直接。

二十、Dify 和 Flowise

Flowise 同样属于可视化 AI 应用开发方向。

两者都有：

Workflow RAG Agent LLM Tool Visual Builder

但是整体思路有所区别。

可以简单理解：

Dify → 更偏 AI 应用平台 Flowise → 更偏可视化 LLM Flow Builder

Dify 官方生态强调 Workflow、RAG、Agent、模型管理、LLMOps 和 API 等完整链路。([GitHub][2])

如果企业希望最终把 AI 应用作为业务系统的一部分进行管理，那么需要重点关注：

API 权限 日志 模型管理 知识库 Agent 部署方式

而不只是看“节点拖起来是否方便”。

二十一、Dify 和直接调用 LLM API

这个其实最容易理解。

直接调用

前端 ↓ 后端 ↓ LLM API

优点：

• 简单
• 灵活
• 控制权高

缺点：

• 很多基础能力需要自己开发

Dify

前端 ↓ 业务后端 ↓ Dify ├── Workflow ├── RAG ├── Agent ├── Tool ├── Model └── Observability ↓ LLM

Dify 的核心价值不是“让你少写几十行代码”。

而是：

把 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 API

Dify 负责：

Prompt ↓ Workflow ↓ RAG ↓ Agent ↓ 模型

这样职责会比较清晰。

二十四、Dify 最适合什么场景？

我认为下面这些场景非常适合：

1. 企业知识库

公司制度 产品文档 技术文档 操作手册 FAQ

↓

RAG

2. 智能客服

用户问题 ↓ 意图识别 ↓ 知识库 ↓ 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 ↓ Database

AI 应用：

UI ↓ API ↓ AI Application ↓ ├── Prompt ├── Workflow ├── RAG ├── Agent ├── Tool └── LLM

Dify 做的，就是帮助我们管理下面这一层。

二十六、总结

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日