企业官网建设流程全解析

Dify 知识库与 RAG 实战：从零构建企业级 AI 聊天机器人与工作流（Easy-Vibe Stage 2 深度指南）

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

本文是 Easy-Vibe 课程「Dify 知识库集成」一讲的完整技术指南。课程带领读者从上一阶段"单纯对话的 Chatbot"出发，理解为什么需要 AI Agent 与工作流（Workflow）编排，掌握 RAG（检索增强生成）的原理与价值，并基于开源 LLMOps 平台 Dify 亲手完成"创建聊天机器人 → 搭建知识库 → 编排工作流 → 通过 API 暴露给前端"的全链路实践。读完本文，你将能够独立部署 Dify、接入自定义模型、构建私有知识库问答机器人，并把 Agent 以标准 API 形式集成进自己的 Web 前端应用。

1. 从对话到 Agent：为什么"能聊天的机器人"不够用

在上一阶段，我们学会了用 Prompt 让大模型扮演角色、生成文本或编写简单代码。但仔细想一想就会发现一个问题：一个 Chatbot 本身不能"做事"。

• 它可以解释如何查询数据库中的数字，却无法真正去数据库里把数据取出来；
• 它可以描述一份周报应该包含什么，却无法自动汇总项目数据并发送邮件。

这种"只说不做"（say without doing）的局限，使得纯对话式 AI 难以真正嵌入业务流程。要把 AI 从"聊天伙伴"升级为"数字员工"，需要赋予它三项核心能力：

1. 专属知识（Dedicated Knowledge）——让它吸收并理解你的产品文档、客户画像、内部政策；
2. 工具调用（Tools / Plugins）——让它能操作数据库、调用 API；
3. 结构化执行（Structured Execution）——让它按预定义逻辑一步步完成任务，而不是自由发挥。

这三者合起来，就是一个AI Agent（智能体）的雏形：一个拥有目标、知识、工具和执行路径的自动化单元。

说明：业界目前所谓的"简单 Agent"，通常指基于"LLM + 工具 + 知识库"组合的增强应用，而非具备自主规划能力的真正 Agent。这类简单 Agent 虽然没有真正的长程推理与自主规划能力，但已足以覆盖大量企业自动化场景。真正能自主规划与行动的 Agent，将在后续章节详细介绍。

2. 最简单的 Agent：知识库聊天机器人

明确了 Agent 的多项基础能力后，一个自然的问题浮现：能不能只实现其中最简单的一项，就构建出一个真正可用的基础 Agent？答案是肯定的。

在很多真实业务场景中，用户的核心诉求并不是让 AI 自动执行复杂操作（比如调用 API 或跨系统协调任务），而是基于企业自有文档给出准确、可靠的回答——这恰好对应三项核心能力中的第一项：专属知识服务。于是，我们引入最简单也最普及的 Agent 形态：知识库聊天机器人（Knowledge-base Chatbot）。

它虽然还不具备工具调用或自主规划能力，但关键进步在于：大模型的回答不再"凭空生成"，而是建立在可核实的来源之上。实现这一点的核心技术就是RAG（Retrieval-Augmented Generation，检索增强生成）。

2.1 RAG 的核心思想

RAG 的基本思路是：当用户提问时，系统先从企业知识库中检索出与问题语义最相关的文本片段（比如产品手册中的某一段、人事制度中的某一则），再把这些片段作为上下文注入大模型的输入，引导模型基于真实数据生成回答。

这样一来，模型回答不再依赖其训练数据中的通用知识，而是锚定在企业提供的真实信息上。RAG 的目标正是通过这种动态注入外部知识的方式，显著提升回答的真实性、准确性与一致性——甚至可以调整语气风格（例如用客服口吻或技术文档口吻回答）。

在实践中，这项技术尤为重要，因为大模型经常产生"幻觉（Hallucination）"。例如，如果你以财务总监或咨询顾问的身份询问具体数据，模型很可能编造出并不存在的日期和事件。而借助 RAG，回答的可控性与可靠性会大幅提升。

2.2 可以用 RAG 做什么

在本课程的实践部分，我们使用流行的 AI 工作流平台Dify来构建知识库聊天机器人。你可以轻松地把各类专属文档汇成知识库：产品手册、内部政策、项目文档、研究论文、个人笔记……构建完成后，用不同的问题来测试它的能力：

• "我们产品 A 最新版本的主要更新点是什么？"
• "按照员工手册，今年的请假制度是怎么运作的？"
• "在 XX 项目中，我们是如何解决'XXX'技术挑战的？"
• "这篇文章提到的核心研究方法是什么？"

你会亲自体会到，RAG 如何把零散的文档变成一座"聪明且精准"的知识库。

3. 从对话 Agent 到工作流：标准化的力量

然而，即使是拥有知识库和插件调用能力的"增强 Agent"，在面对更复杂的业务流程时依然力不从心。

以用户需求为例："我们最近上线的 SaaS 产品有哪些最新功能更新？能帮我准备一份客户简报吗？"

这个需求看似简单，却需要多个步骤的协同：

1. 先从内部文档或 Notion 知识库中提取最近一个月的发布记录；
2. 筛选出面向客户的关键功能；
3. 调用大模型把技术描述转译成客户友好的语言；
4. 最后把生成的内容通过邮件推送给市场团队，或保存为 Google Docs 模板。

如果只靠单个大模型的自由推理，不仅很难在一次对话中全部完成，还极易漏掉关键信息、混淆内部术语与客户语言，或产出非结构化结果。更重要的是，企业需要的是标准化、可审计、可复用、可监控的执行路径，而不是每次都依赖模型临场发挥——可复现性与可观测性对企业的稳定性与合规要求至关重要。

这就引出了更高级的 AI 应用范式：AI Workflow（AI 工作流）。

3.1 什么是工作流

工作流（Workflow）是指把一个复杂任务拆解为多个有序、可配置、可自动执行的子步骤，并用可视化或代码方式编排它们之间的逻辑关系（条件、循环、并行）。

把 AI 能力"标准化"（即固化为标准作业程序），意味着把"用 AI 完成某类任务"的经验沉淀为可复用的模板。这种模式带来多重好处：

• 非技术人员（产品经理、市场负责人）可以通过拖拽组件快速拼装 AI 应用；
• 开发者可以把 RAG 检索、LLM 调用、API 工具封装为标准节点，在不同业务场景中复用；
• 整个过程可追踪、可调试、可持续优化，满足企业稳定性和合规要求。

用一句话总结：如果说 Agent 让 AI 从"会聊天"进化到"会行动"，那么工作流则让 AI 从"偶尔做成一次任务"进化到"稳定、可靠、规模化地完成一类任务"。

3.2 常见的 Agent / 工作流平台

随着生成式 AI 的快速发展，涌现出一批Low-code / No-code的 Agent 与工作流平台，帮助开发者和业务团队在不陷入复杂编程的情况下快速构建 Agent 与自动化流程。

Low-code（低代码）平台的核心是用可视化配置和拖拽节点拼装，替代手写代码：通过预置的业务逻辑模板与图形化规则配置，把开发者从重复劳动中解放出来，也让掌握业务逻辑的非技术人员能够参与应用构建。其核心价值在于大幅降低 AI 应用开发门槛——过去需要团队协作数周才能完成"需求分析 → 开发 → 测试 → 部署"的工作，如今借助平台的可视化工具几小时即可完成。

当前市场上主要的低代码 AI 工作流平台：

Dify、Coze、n8n 的共同优势在于：

1. 易用性极强：可视化拖拽界面，无需理解底层技术即可上手；
2. 灵活性高：自定义组件与可扩展 API，既适合轻量场景（演示、MVP），也适合中小企业的敏捷迭代需求；
3. 生态成熟：官方文档详尽、响应快速，社区活跃且共享大量模板。

这三类平台都能把构建好的 Agent 以标准 API形式暴露出来，集成到 Web 前端应用、内部 ERP 系统或移动 App 中。

4. Dify 深入：从部署到应用

4.1 Dify 是什么

Dify是一个面向 LLM 应用开发的开源平台，定位为LLMOps 平台：它覆盖从设计、部署到优化的完整生命周期。Dify 提供直观的界面，将Agent 工作流、RAG 流水线、工具能力、模型管理与可观测性集于一身，帮助你快速从原型走向生产。

在 Dify 中构建工作流，就像拼乐高积木或拼图：把"LLM 节点"（理解与生成）、"工具节点"（执行具体动作：查询数据库、发邮件、翻译）和"数据节点"（读取、存储信息）连接起来，它们会按预定义逻辑自动运转，无需重复人工干预。

以电商场景为例，假设你在经营亚马逊或抖音店铺，想做一个 AI 客服，可以设计如下工作流：

1. 触发节点：接收用户问题；
2. 分类节点：用模型对问题进行归类（售后、使用说明等）；
3. 知识检索节点：访问对应知识库；
4. LLM 节点：基于问题与检索到的知识生成友好回答；
5. 条件节点：检查回答是否包含预期信息；
6. 输出节点：把最终回答返回给用户。

4.2 部署你自己的 Dify（可选）

Dify 是开源项目，你可以自行部署。最简单的路径之一是使用Zeabur这类 PaaS 平台：Zeabur 内置 Dify 服务模板，选择模板、命名项目后即可获得临时域名，等待多个服务组件全部启动（Dify 由多个协作运行的程序组成），即可访问 Dify 的登录界面。完整步骤可参考本课程配套的 Zeabur 部署教程。

提示：Zeabur 默认每月提供约 5 美元的免费额度，服务运行时会持续消耗额度。建议在 Zeabur 控制台 的 Settings 中通过 "Suspend All Services" 及时暂停不用的服务，避免超额。Zeabur 只识别监听8080 端口的应用，若部署自定义 Web 服务（如 React 应用默认监听 3000），需要先把端口改为 8080。

4.3 创建你的第一个 Dify Chatbot 应用

1. 访问 https://cloud.dify.ai/apps（或你自部署的 Dify 地址），注册登录后进入Studio；
2. 在 "CREATE APP" 区域点击Create from Blank；
3. 应用类型选择Chatbot，填写名称与描述后创建。

创建完成后你会看到编排界面：

• INSTRUCTIONS 区域：内置指令，即默认系统 Prompt；
• Knowledge 区域：知识库挂载区（在下方）；
• 右侧面板：调试窗口，用于实时测试回答效果。

4.4 配置自定义模型提供商

Dify 支持配置三类模型：LLM（大语言模型）、Embedding（向量嵌入）、Rerank（重排序）。安装OpenAI-API-compatible与SiliconFlow两个插件，即可接入市面上大多数模型：

• LLM：负责对话生成与推理，是应用的核心计算单元；
• Embedding：把文档与查询转换为向量，用于知识库的向量检索——向量检索是知识库"语义相关"检索的基础；
• Rerank：对检索结果进行二次重排，进一步提升召回精度。

安装插件后，在模型提供商设置中填入各模型的 API Key 与模型名称即可生效。

4.5 创建你的第一个 Dify 知识库

1. 点击顶部菜单的Knowledge进入知识库页面；
2. 点击Create Knowledge；
3. 上传文件（支持PDF、TXT等多种格式），即可开始构建知识库。

上传后，Dify 会使用 Embedding 模型对文档进行分块（Chunking）与向量化，建立向量索引。之后在 Chatbot 应用的 Knowledge 区域挂载该知识库，聊天时即会自动触发 RAG 检索流程：先向量检索相关片段，再注入 LLM 生成回答。你可以用第 2.2 节的示例问题来验证知识库问答效果。

4.6 其他常用操作：DSL 导入导出与社区探索

• 导入 / 导出工作流（DSL）：Dify 支持以DSL（JSON）格式导入和导出工作流，便于模板分享与版本管理。本仓库的 Log in.yml 与 Love Loop.yml 就是两套可直接导入 Dify 的 DSL 工作流示例，对应下文练习中的"登录挑战"与"Love loop 挑战"；
• Explore：点击 Explora 可以浏览其他用户构建的工作流模板。

从 DSL 文件结构可以看到 Dify 工作流的底层描述方式：app.mode（如advanced-chat）、workflow.graph.nodes/edges（节点与连线）、workflow.conversation_variables（会话变量，如登录挑战中的LOGIN密码变量、Love Loop 中的words/WORDS变量），以及dependencies中声明的插件依赖（如langgenius/gitee_ai）。理解这一结构，有助于你读懂任意导入的工作流模板。

4.7 创建你的第一个 Workflow 应用

根据需求是"持续对话"还是"一次性自动化处理"，选择Chatflow或Workflow：

• Chatflow：面向对话场景设计，带记忆与上下文；
• Workflow：面向自动化场景，一次性处理 输入 → 输出。

常用节点

LLM 与推理节点：

• LLM：主计算单元，调用大模型；
• Knowledge Retrieval：在知识库中检索；
• Answer：输出结果；
• Agent：带工具的高级决策；
• Question Classifier：按类型对问题进行分类。

逻辑与流程控制节点：

• Condition（IF/ELSE）：逻辑分支；
• Iteration：无状态批量并行处理；
• Loop：有状态的递归迭代。

数据处理与集成节点：

• Code：自定义代码逻辑；
• Template：基于模板生成内容；
• Variable Aggregator：变量聚合；
• Doc Extractor：从文档中提取；
• HTTP Request：调用外部系统；
• List Operator：对列表/数组操作。

常用工具

Dify 中的工具可以直接作为节点放到画布上：

• Web 搜索：Tavily Search，做面向 AI 优化的搜索；
• 数据处理：JSON Process，做 JSON 高级操作；
• 格式化：Markdown Exporter，按指定格式导出。

实战：意图分类工作流

以餐厅场景为例，构建一个能把用户意图分为四类——下单（buy_food）、投诉（complain）、闲聊（chitchat）、其他（other）——的意图分类工作流：

1. 从起始节点开始，连接Question Classifier节点；
2. 配置四类意图及其对应的分类描述与示例语句；
3. 用Condition节点按分类结果做分支；
4. 各分支连接不同的 LLM 节点与 Answer 节点，输出对应回复。

在右侧调试窗口输入真实用户语句测试分类效果，观察各节点的输入输出与运行日志，可快速定位并修正分类不准的问题。

4.8 运行官方 DeepResearch 工作流模板

在 Explore 中导入 Dify 官方DeepResearch工作流模板，按报错提示逐步修复（例如模型未配置、节点变量未赋值、工具未授权等），即可完整体验"多步研究型 Agent 工作流"的运行过程。这个练习能帮助你理解工作流的依赖关系与调试方法——Dify 的节点级日志与运行轨迹（Trace）是排查问题的主要手段。

5. 把 Dify 作为 API 提供商：搭建前端聊天应用

Dify 构建的应用（Agent / 工作流）都可以发布为标准化 API，集成到任意前端。

5.1 发布与获取 API 文档

1. 先**发布（Publish）**已创建并测试完成的 Agent 应用；
2. 在应用详情页进入API 访问页面，查看 API 文档；
3. 获取应用的API Secret Key（调用凭证）与 API 端点（典型端点为/v1/chat-messages，即聊天消息接口）。

5.2 用 Trae IDE 生成前端代码

打开 Trae Builder，把以下三样东西交给 AI：

• 你的API Key；
• API 文档中的请求示例（JSON 格式，包含inputs、query、response_mode等字段）；
• 响应示例（用于明确前端如何解析流式/非流式回答）。

让 Trae 据此生成一个前端聊天页面：通常包括消息输入框、消息列表渲染、调用 Dify API 发送请求、展示回答（支持 SSE 流式输出效果更佳）。生成后在浏览器本地打开测试，即可完成"从后端 Agent 到前端应用"的完整闭环。

6. 更多业务工作流参考

你可以用"Dify workflow examples"等关键词在互联网上搜索，或在 GitHub 上寻找分享 Dify 工作流的仓库。以下是由大模型生成的一些工作流创意，供你参考其复杂程度分级：

社交平台类：

1. 一键多平台分发（复杂）
2. 热点话题与草稿生成器（中等）
3. 评论分类与自动回复助手（复杂）
4. 视频脚本与分镜生成器（复杂）
5. 直播互动实时摘要（中等）

职场办公类：

1. 智能会议纪要 + 任务自动指派（复杂）
2. 简历自动筛选与评估（中等）
3. 多语言邮件翻译与回复（简单）
4. 周报/月报自动汇总（复杂）
5. 合同/文档智能审阅（中等）

学习与生活类：

1. 学术论文深度解析 + 笔记生成（复杂）
2. 个性化旅行规划师（中等）
3. 交互式语言陪练伙伴（简单）
4. 个人知识库问答系统（复杂）
5. 健身/营养顾问与跟踪（中等）

7. 工作流平台的局限性与理性认知

工作流（低代码）平台并非万能药。虽然它对业务人员友好、降低了编码门槛，但"低代码"也意味着它有自己的学习成本——用户必须理解平台的概念、规则与运行逻辑。

你可能会合理地反问：很多简单工作流不过是大模型函数调用的串联，前一个输出作为后一个输入，几行代码就能解决，为什么要搭建这么复杂的工作流基础设施？

这个质疑是成立的。随着Vibe Coding（氛围编程）的快速发展和 AI 代码生成能力的提升，直接阅读甚至生成代码有时反而更高效。理想状态下，我们应该能用自然语言直接驱动应用逻辑——那才称得上是真正的现代软件平台。但当前的工作流平台尚未达到这一步，于是在"用户意图"与"最终实现"之间形成了一个自然的"中间层"。

尽管如此，掌握这些平台正在成为一项基础技能——它类似于微软 Office 办公工具，在企业中非常普及且实用。

8. 综合练习

8.1 掌握 Dify 基础操作

1. 在一个全新场景中创建意图分类工作流（例如：电商客服、旅游咨询）；
2. "登录"工作流挑战：找到正确密码、修改密码、加入第二次尝试机会——可导入本仓库的 Log in.yml 模板，观察其conversation_variables（LOGIN密码变量）、IF/ELSE 分支与变量赋值节点（Assigner）的配合方式；
3. "Love loop"工作流挑战：修复工作流使其输出符合预期——对应 Love Loop.yml 模板，重点体会 Loop 节点（有状态递归迭代）与 LLM 节点在循环中的协作。

8.2 实现 Dify API 调用

1. 部署 Dify 并创建一个简单的知识库；
2. 使用 Trae IDE 构建一个通过 Dify API 交互的对话前端；
3. 测试多轮对话（注意 Dify 的conversation_id参数用于维持多轮会话上下文）。

8.3 尝试第三方工作流或自建工作流

在 GitHub、微信、Reddit 或 Twitter 上找一个 Dify 工作流，导入并成功运行它——这一步能帮你建立"读懂陌生工作流 → 修复运行错误"的实战能力。

9. 疑难解答：HTTP 请求错误（Proxy 代理方案）

如果你遇到"HTTP 请求错误"问题，可参考本节；否则可跳过。

问题根因：Dify 部署在仅支持 HTTP（无 HTTPS）的服务器上时，前端页面发起的 API 请求会被浏览器拦截（HTTPS 是带 SSL/TLS 加密的安全版本 HTTP，现代浏览器对"HTTPS 页面调用 HTTP 接口"这类混合内容默认拒绝）。

常规解决方案：

• 使用带证书的反向代理（如 nginx）；
• 绑定域名并申请证书。

本课程采用的方案：用 Zeabur 作为网络网关做 HTTPS 转发：

• 原地址：http://{DIFY_API_URL}/v1/chat-messages
• 新地址：https://{DIFY_NEW_API_URL}.zeabur.app/v1/chat-messages

在 Zeabur 上选择Python环境部署一个代理服务，使用以下代码（将TARGET_BASE_URL替换为你的 Dify API 地址）：

from flask import Flask, request, Response import requests app = Flask(__name__) TARGET_BASE_URL = "{DIFY_API_URL}" LISTEN_PORT = 8080 @app.route('/', defaults={'path': ''}, methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS', 'HEAD']) @app.route('/<path:path>', methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS', 'HEAD']) def proxy_request(path): target_url = f"{TARGET_BASE_URL}/{path}" if request.query_string: target_url += f"?{request.query_string.decode('utf-8')}" headers = {key: value for key, value in request.headers if key.lower() not in ['host', 'connection', 'content-length', 'accept-encoding']} try: resp = requests.request( method=request.method, url=target_url, headers=headers, data=request.get_data(), cookies=request.cookies, allow_redirects=False, timeout=30 ) excluded_headers = ['content-encoding', 'content-length', 'transfer-encoding', 'connection'] response_headers = [(name, value) for name, value in resp.raw.headers.items() if name.lower() not in excluded_headers] return Response(resp.content, resp.status_code, response_headers) except requests.exceptions.RequestException as e: print(f"Error forwarding request to {target_url}: {e}") return Response(f"Proxy Error: Could not reach target server or invalid response: {e}", status=502) except Exception as e: print(f"An unexpected error occurred: {e}") return Response(f"Internal Proxy Error: {e}", status=500) if __name__ == '__main__': app.run(host='0.0.0.0', port=LISTEN_PORT, debug=True)

代码要点说明：该代理用 Flask 捕获所有 HTTP 方法（GET/POST/PUT/DELETE 等）与任意路径，透传请求头（剔除Host、Connection、Content-Length、Accept-Encoding四个头，避免代理层干扰）、请求体与 Cookie，再转发到 Dify 目标地址，并把响应内容、状态码与头信息原样返回；转发失败时返回 502，内部异常返回 500。Zeabur 会为该服务自动分配 HTTPS 域名，前端把请求地址指向新的https://...zeabur.app即可解决混合内容拦截问题。

总结

从"只会聊天的 Chatbot"到"拥有知识库的 Agent"，再到"可编排、可复用、可监控的 AI 工作流"，这条进阶路径正是企业级 AI 应用落地的关键。通过本讲你将掌握：

• RAG 的原理与价值：用动态外部知识注入对抗大模型幻觉，让回答有据可依；
• Dify 的完整使用链路：部署 → 配置 LLM/Embedding/Rerank 模型 → 创建 Chatbot → 搭建知识库 → 编排工作流 → 导入导出 DSL → 发布 API；
• 前后端打通能力：通过 Dify API + Trae IDE 快速生成交互式聊天前端，并解决 HTTP/HTTPS 混合内容等真实部署问题。

相关扩展阅读：Dify 课程首页｜Zeabur 部署教程｜Stage 2 课程总览。

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe