企业官网建设流程全解析

很多人想用大模型做点实际的东西，比如给自己的游戏做个问答助手，但卡在第一步：不会写 Prompt，不懂向量数据库，甚至不知道 Agent 是什么。如果只是想聊天，直接打开网页就行；但如果想让 AI 回答“三角洲行动里新手用什么枪顺手”这种问题，并且还不能胡编，你就得把资料喂给 AI，还要让 AI 按你设定的流程输出。这件事过去需要前端、后端、数据库、模型部署一整套工程能力，现在用 Dify 可以很快跑通。

这里可以先说一个明确判断：Dify 的价值不是把大模型套了个壳，而是把大模型应用开发中最容易翻车的几个环节——模型接入、知识库检索、Agent 流程——封装成了可视化组件。但 Dify 降低了编码门槛，却没有降低思考门槛。你不写代码，但你必须搞清楚 RAG 和 Agent 分别解决什么问题，否则应用搭出来也只是个玩具。

这篇文章会用零基础视角，从部署 Dify 开始，一步一步做一个“三角洲行动专属游戏助手”。它会基于你上传的游戏攻略资料回答问题，还能调用外部工具帮你查询信息。读完你会理解 Dify、RAG、Agent 三者之间的关系，能独立搭出第一个 AI 应用，也知道遇到问题该从哪里排查。

1. 这篇文章真正要解决的问题

1.1 零基础做 AI 应用，难的不是写代码

很多初学者最大的误区，是以为“会写代码才能做 AI 应用”。实际上，传统 AI 应用开发最难的地方在于：要同时搞定模型 API、上下文管理、向量检索、提示词设计、接口部署，还要处理用户输入的各种边界情况。每一步单独看都不复杂，但串起来就很繁琐。

比如你要做一个游戏问答机器人，至少要处理这些问题：

• 大模型不知道你的私有攻略资料，回答只能靠“猜”；
• 每次对话都要把历史记录和系统提示词拼在一起，容易超出上下文长度；
• 用户问法五花八门，同一个问题换一种说法，AI 就答偏了；
• 你希望 AI 调用某个战绩查询接口，但普通聊天应用没有工具调用能力。

Dify 把这些环节都做成了可视化模块。你不需要写“大模型调用”的代码，只需要在界面上选择模型、创建知识库、拖拽工作流节点，最后生成一个可以分享的应用链接。

1.2 Dify + RAG + Agent 解决的是一整条链路的问题

Dify 解决的是“开发平台”的问题，RAG 解决的是“模型如何获得私有知识”的问题，Agent 解决的是“AI 如何自主完成多步骤任务”的问题。这三个词经常一起出现，但很多人误以为它们是同一个东西。

实际上，它们在项目里负责不同环节：

• Dify 是容器，装下模型、知识库、工作流和对外接口；
• RAG 是外挂记忆，让 AI 在回答问题前先检索你的资料库；
• Agent 是大脑皮层，让 AI 能拆解任务、决定先做什么后做什么，并在需要时调用工具。

做一个合格的游戏助手，这三者缺一不可。

1.3 谁适合读这篇文章

如果你正在做下面这些事，这篇文章很适合你：

• 完全不懂编程，但想用 AI 搭建自己的知识问答机器人；
• 想让 AI 基于自己的文档、攻略、产品手册回答客户问题；
• 想理解 RAG 和 Agent 到底有什么区别，而不是只听过名词；
• 想从零部署 Dify 社区版，并熟悉它的完整操作流程。

如果你已经熟练使用 Dify，可以直接跳到第五章看知识库切块策略和 Agent 工具设计，这两段是容易踩坑的地方。

2. Dify、RAG、Agent 的核心概念与关系

2.1 Dify 到底是什么

Dify 是一个开源的大模型应用开发平台，官方定位是“模型中立”的 LLMOps 工具。它可以连接多种模型供应商，提供知识库管理、Prompt 编排、工作流、Agent、模型微调接入和 API 发布等功能。

通俗理解：Dify 像一套乐高积木。模型是积木包里的一种零件，知识库是另一种零件，Agent 工具又是另一种零件。你不需要自己做积木，只需要按图纸把它们拼起来。

社区版支持本地部署，数据保存在你自己的服务器上。这一点对很多团队很重要，因为游戏攻略、内部资料等数据不一定要全部交给第三方平台。

2.2 RAG 是什么：让 AI 拥有“外挂记忆”

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。流程可以概括为：当用户提问时，先从知识库中检索与问题最相关的内容片段，再把这些片段和原问题一起交给大模型，让它基于检索结果生成回答。

没有 RAG 时，你问模型“三角洲行动新版本哪把枪收益高”，模型只能靠训练数据里的记忆回答。如果游戏版本更新了，它一定答错。有了 RAG，你上传最新攻略，AI 就会先检索“新版本、枪械”相关段落，再基于这些内容回答，准确率会高很多。

2.3 Agent 是什么：让 AI 学会“做事情”

Agent 是智能体，理解它最简单的方式是：AI 不仅能聊天，还能“行动”。普通对话是用户问一句、AI 答一句；Agent 则可以根据目标自己规划步骤，比如：

• 判断这个问题是否需要查知识库；
• 决定是否需要调用工具；
• 调用工具后，把结果整理成回答。

在 Dify 里，Agent 可以绑定工具。工具可以是计算器、搜索引擎、天气查询，也可以是自定义 API。比如你的游戏助手可以让玩家输入玩家 ID，Agent 自动调用战绩查询接口，再结合知识库里的攻略输出结论。

2.4 三者的协作关系

用一句话概括：Dify 是搭建应用的平台，RAG 给平台里的 AI 提供资料，Agent 给平台里的 AI 赋予行动能力。

它们可以独立用，也可以组合用。一个典型的组合方式是：用 Dify 搭建聊天助手，启动 Agent 功能，同时挂载游戏攻略知识库，并配置一个战绩查询工具。玩家提问后，AI 先做意图判断，遇到攻略问题就检索知识库，遇到查战绩需求就调用工具，最后统一生成回答。

3. 环境准备与本地部署 Dify

3.1 安装 Docker 与 Docker Compose

Dify 社区版推荐用 Docker Compose 方式部署。Docker 能屏蔽环境差异，避免你在依赖库上浪费太多时间。版本请以实际项目要求为准，本文重点演示通用思路。

以 Ubuntu 服务器为例，先安装 Docker：

sudo apt-get update sudo apt-get install -y docker.io docker-compose-v2 sudo systemctl enable --now docker

Windows 用户可以直接安装 Docker Desktop，然后在 PowerShell 或 CMD 中运行 docker 命令。macOS 用户也推荐 Docker Desktop。

安装完成后验证：

docker --version docker compose version

如果命令能正确输出版本号，说明 Docker 环境已经就绪。

3.2 下载 Dify 源码并启动

Dify 官方仓库中带有一套 docker 编排文件。克隆仓库，进入 docker 目录，复制环境变量模板，然后启动：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

首次启动需要拉取多个镜像，耗时取决于你的网络情况。等待一段时间后，执行：

docker compose ps

看到各服务状态为 running，说明容器启动成功。

3.3 初始化与访问

浏览器访问 http://localhost/ 或 http://服务器IP/，第一次打开会进入管理员账号设置页面。

这里要注意：Dify 的管理员账号只在首次初始化时设置，创建之后要保存好账号密码。Dify 默认端口是 80，如果 80 端口被占用，需要修改 .env 中的端口映射，例如把 “80:80” 改成 “8080:80”，然后重新启动。

初始化完成后，你会进入 Dify 控制台。到这里，Dify 本地部署就完成了。

4. 配置模型与创建第一个对话应用

4.1 配置模型供应商

Dify 本身不提供大模型算力，需要接入模型供应商的 API。在控制台右上角头像菜单中点击“设置”，进入“模型供应商”页面，可以看到 OpenAI、Anthropic、通义千问、智谱、Ollama 等多种选项。

选择你实际可用的供应商，填入 API Key。如果使用本地 Ollama，需要额外配置服务地址和模型名称。需要说明的是：不同供应商的 API 地址、模型名、计费方式都不一样，配置前先确认你手上有可用的 Key，以及该模型是否支持对话补全能力。

配置完成后，可以在“模型供应商”页面点击“测试”按钮，验证连通性。如果测试失败，优先检查 API Key 是否复制完整、余额是否充足、网络是否能访问该供应商服务。

4.2 创建聊天助手应用

在 Dify 首页点击“创建空白应用”，选择“聊天助手”类型，给应用取一个名字，比如“三角洲专属游戏助手”。

新建的应用默认是一个最简单的聊天助手。你可以在“编排”页面看到提示词编辑框、上下文设置区和模型选择区。这些已经比直接从零写代码简单得多，但离“可用”还有几步。

4.3 第一个对话测试

在右侧调试预览区输入问题，比如“你好，介绍一下你自己”。模型会返回基础回答。

此时应用还没接入知识库，也没有 Agent 能力，所以它只是一个普通聊天机器人。接下来就是本文的核心：把 RAG 和 Agent 加进来。

5. RAG 知识库搭建：让 AI 懂三角洲行动

5.1 为什么要给 AI 外挂知识库

大模型的知识来源于训练数据，训练截止日期之后的信息它完全不知道。游戏版本更新、枪械数值调整、地图点位变化，这些信息时效性很强，模型大概率没有学过。

知识库的作用，就是把这些高频变化的内容变成模型可以检索的外部资料。你上传文档到 Dify，系统会先对文档进行分段，再把每个分段做向量化处理。用户提问时，Dify 把问题向量化，在知识库中找到最相关的若干分段，拼接到 Prompt 中交给模型。

这个过程不需要重新训练模型，成本低、更新快，适合游戏攻略、产品说明书、企业制度这类文档型知识。

5.2 准备攻略文档并创建数据集

准备一份“三角洲行动攻略”文档，可以包含枪械排行、地图点位、物资分布、任务流程等内容。格式支持 Markdown、TXT、PDF、DOCX 等。

在 Dify 左侧菜单点击“知识库”，进入“创建知识库”页面：

第一步，选择数据集类型为“导入已有知识”； 第二步，上传你的攻略文档； 第三步，进入分段设置页面。

5.3 分段与索引策略（切块策略）

分段是影响 RAG 效果最关键的一步，也是新手最容易忽略的步骤。“切块策略”决定了文档被切成多大的段落、相邻段落之间是否保留重叠。

如果分段太长，检索结果会混入大量无关内容，模型容易被带偏；如果分段太短，语义不完整，检索召回率反而下降。常见做法是：

分段标识符: "\n\n" 最大分段长度: 500 分段重叠: 50

这是 Dify 界面里的可视化配置，不用写代码。上面的设置表示：以空行作为段落边界，每段最多 500 个字符，保留 50 个字符的重叠。

为什么需要重叠？因为一段文档的语义往往跨越边界，保留少量重叠可以避免检索时把关键句子拦腰截断。

索引方式一般使用“高质量”模式，也就是向量检索。向量检索能理解语义，比如“新手推荐枪”和“适合萌新的武器”会检索到相似内容。如果为了节省资源，也可以选择“经济”模式，但效果会下降。

5.4 上传文档并检索测试

创建数据集后，上传刚才的攻略文档。等待系统完成分段和索引，然后点击“召回测试”按钮，输入一个问题：

三角洲行动新手适合用什么枪？

系统会展示命中了哪些分段。如果返回的结果和问题相关，说明知识库可用；如果返回为空或毫不相关，需要检查分段长度、索引方式以及文档是否被正确解析。

这里要提醒一个常见问题：扫描版 PDF 或图片型 PDF，Dify 无法直接识别文字内容，必须先用 OCR 工具转换成可复制文本，否则知识库会变成“空盒”。

5.5 把知识库接入聊天助手

回到“三角洲专属游戏助手”应用编排页面，在“上下文”设置中选择刚创建的知识库。然后修改系统提示词，明确要求模型只基于知识库内容回答，不要使用记忆中的信息。

提示词示例：

你是一个三角洲行动专属游戏助手。 请优先基于“三角洲攻略”知识库中的内容回答问题。 如果知识库中没有相关信息，请如实回答“根据目前资料暂时无法确认”，不要编造。 回答需要简洁，并尽量给出出处。

这样配置后，同一个应用就具备了 RAG 能力。玩家在对话框提问，AI 会先检索知识库，再生成回答。

6. Agent 配置：让助手会调用工具

6.1 Agent 与知识库的区别

很多人做完知识库后就开始困惑：既然知识库已经能回答问题，为什么还需要 Agent？

答案是：知识库是“查资料”，Agent 是“办事”。

如果你只需要问答，RAG 就够了。但如果玩家问“帮我查一下这个玩家的近期战绩”，你不可能把每个玩家的战绩都写进知识库——这是实时数据，需要调用 API。Agent 就是干这件事的。

6.2 开启 Agent 并添加工具

在 Dify 应用编排页面，找到“Agent”设置开关，将其打开。然后进入“工具”列表，可以看到系统自带的一组工具，比如计算器、天气查询、Web 搜索等。

对游戏助手来说，比较实用的三类工具是：

• 计算器：用于计算物资成本、伤害数值等。
• HTTP 请求工具：调用自定义战绩查询接口。
• 搜索工具：实时搜索最新活动公告。

如果系统工具满足不了需求，可以添加自定义工具。Dify 支持 OpenAPI Schema 方式导入，你只需要提供一个符合 OpenAPI 规范的 JSON 或 YAML 描述文件。

6.3 自定义工具示例：战绩查询接口

假设你有一个战绩查询接口，可以根据玩家 ID 返回最近胜率。自定义工具的 OpenAPI Schema 可以这样写：

openapi: 3.1.0 info: title: 战绩查询工具 description: 根据玩家ID查询三角洲行动近期战绩 version: 1.0.0 servers: - url: https://api.example.com paths: /stats/{player_id}: get: operationId: getPlayerStats summary: 查询玩家战绩 parameters: - name: player_id in: path required: true schema: type: string description: 玩家 ID responses: '200': description: 查询成功

在 Dify 工具页面选择“自定义工具”，粘贴这段 Schema，再配置真实的 API 地址和鉴权方式。配置完成后，Agent 在执行对话时，如果发现用户输入了玩家 ID，就会自动调用这个工具。

这里要强调的是：自定义工具需要你自己保证接口的安全性。在生产环境，必须做合法的身份校验、请求限流和敏感信息过滤，不要直接暴露内部接口。

6.4 Agent 提示词设计

Agent 提示词决定了 AI 如何判断“什么时候调用工具”。推荐在系统提示词中增加工具使用规范：

当用户询问战绩、胜率、排位信息时，请使用“战绩查询工具”获取实时数据。 当用户询问攻略、枪械、地图信息时，请优先检索知识库。 如果无法从知识库和工具中获得答案，请直接说明，不要猜测。

Agent 和多工具配合后，游戏助手才真正更像一个“助手”，而不是只回答问题的 FAQ 机器人。

7. 用工作流把流程固化：游戏助手完整示例

7.1 什么时候用 Agent，什么时候用工作流

这里可以给出一个比较直接的判断标准：Agent 适合任务路径不固定、需要模型自主决策的场景；工作流适合业务路径固定、每一步输入输出都很明确的场景。

比如“查战绩”这个动作，路径很固定：接收玩家 ID → 调接口 → 格式化结果。这件事放工作流里更稳。而“综合回答游戏问题”这种开放场景，路径不固定，放 Agent 里更灵活。

Dify 的成熟用法是“工作流 + Agent 混合”：用工作流控制主干节点，用 Agent 节点承担需要大模型判断的子任务。

7.2 整体流程设计

三角洲游戏助手的工作流可以这样设计：

1. 开始节点：接收用户输入。
2. 意图分类节点：用大模型判断用户是想查攻略、查战绩，还是闲聊。
3. 知识库检索节点：如果判断为查攻略，检索“三角洲攻略”知识库。
4. Agent 节点：如果判断为查战绩，调用战绩查询工具。
5. 回复节点：把检索结果或工具结果组装成最终回答。

这个流程可以在 Dify 的“工作流”编排画布中通过拖拽完成，不需要手写代码。

7.3 各节点配置说明

意图分类节点可以使用 LLM 节点，提示词写：

判断用户的意图，只输出一个词：strategy、stats 或 chat。 strategy：询问攻略、枪械、地图、物资等。 stats：询问战绩、排位、胜率、玩家数据等。 chat：其他情况。

知识库检索节点选择“三角洲攻略”数据集，设置返回条数为 3。建议设置相似度阈值，比如 0.5 以下的结果默认不采用，避免无关内容干扰回答。

Agent 节点选择“战绩查询工具”，并设置输入参数为玩家 ID。为了让 LLM 能正确提取参数，可以在系统提示词中说明输入格式。

最后，回复节点拼接两部分内容：如果处理的是攻略问题，回复“根据知识库检索结果：xxx，你可以参考以下建议……”；如果处理的是战绩问题，回复“该玩家最近战绩：xxx”。

7.4 发布与访问

配置完成后，点击右上角“发布”按钮。Dify 会生成一个可访问的 Web App 地址，也可以生成嵌入网页的 iframe 代码。

如果你想把游戏助手接入自己的网站或社交平台，可以在“访问 API”页面获取 API 密钥和调用地址。Dify 提供了标准 HTTP API，支持对话消息接口。

8. 运行验证与效果测试

8.1 测试用例设计

应用发布后，不要直接用玩家视角乱问，而是设计一组覆盖核心场景的测试用例。下面这组用例可以验证基本功能：

8.2 如何判断成功与失败

每个用例都看三点：

• 回答是否相关；
• 回答是否基于知识库或工具结果，而不是模型胡编；
• 回答是否格式清晰，没有混乱字符。

“回答不相关”通常集中出现在 RAG 召回质量不高的位置。此时应该回到知识库做召回测试，而不是盲目修改提示词。

8.3 失败时的第一排查方向

如果应用回答错误，建议按下面顺序排查：

1. 知识库召回测试是否命中正确段落。
2. 模型是否真的看到了检索内容，这一点可以在“编排”页面的调试输出中查看完整 Prompt。
3. 如果 Aget 没有调用工具，检查 Agent 是否开启以及工具是否绑定在正确节点。
4. 如果工具返回错误，用 Postman 或 curl 单独测试接口连通性。

9. 常见问题与排查方法

10. 最佳实践与工程建议

10.1 知识库要“小步快跑”，不要一次性堆大量文档

游戏攻略更新速度很快。建议按主题拆分成多个数据集，比如“枪械攻略”“地图点位”“活动任务”。每个数据集保持独立，更新时可以只替换对应数据，不用重建整个知识库。同时，把过期文档及时清理干净，否则知识库里的旧版本信息会导致回答自相矛盾。

10.2 分段参数要实测，不要照抄

切块策略不是固定的，取决于你文档的类型。策略文档适合 200 到 500 字符串，表格类内容建议拆得更细。上线前可以准备 10 来个高频问题，在 Dify 的召回测试里反复调参，直到每个问题都能命中正确段落。

10.3 Agent 工具要限定最小权限和使用边界

自定义工具接口必须做身份认证，只暴露必要字段。如果你的战绩接口只需要玩家 ID，就不要让工具返回真实姓名等敏感字段。生产环境建议加一个审批或开关机制，防止 Agent 在无人值守时连续调用外部接口产生高额费用。

10.4 成本控制与日志记录

模型调用按 token 计费，知识库召回条数和上下文拼接会直接影响费用。最佳实践是：只返回最相关的 2 到 3 个分段，不要无脑拉取 10 个段落。同时对线上请求做日志记录，统计高频问题和异常失败，定期通过日志优化提示词和知识库。

10.5 重视版本升级与备份

Dify 社区版更新较快，升级前必须备份数据库和配置文件。官方 docker 编排目录中包含 .env 和持久化卷，先停止服务，备份数据目录，再拉取新版本镜像启动。不要在没有任何回滚方案的情况下直接升级生产环境。

11. 总结与后续学习方向

这篇文章从一个“不用敲代码”的诉求出发，梳理了 Dify、RAG、Agent 三者的关系，并完整演示了如何从零部署 Dify，搭建一个带知识库和工具调用能力的三角洲行动专属游戏助手。你不需要真写多少代码，但一定要理解：Dify 解决的是工程化平台问题，RAG 解决的是模型知识来源问题，Agent 解决的是模型行动能力问题。

建议你先跑通最小闭环：部署 Dify → 上传一份攻略 → 挂载知识库 → 发布应用。然后再逐步加入 Agent 工具和工作流。每加一个功能，就换一批测试问题验证，不要等所有节点堆在一起再调试，那样出了问题很难定位。

接下来可以继续学习的几个方向：Dify 工作流节点的深度配置、知识库召回相关的相似度算法调优、如何在生产环境接入更多自有系统 API、以及怎样用日志分析持续优化提示词。如果你已经把游戏助手跑到 80 分，再去研究 Agent 的复杂编排，会发现之前积累的经验都在给你打底。

只输出最终文章