企业官网建设流程全解析

不用敲代码也能玩AI？Dify+RAG+Agent 从入门到落地，手把手教你零基础做“三角洲”专属游戏助手

身边不少朋友问我：想做一款能回答游戏攻略、装备数据、地图点位问题的 AI 助手，是不是得先学几个月 Python？社区版的 Dify 能支持多少人用？知识库和 Agent 到底有什么区别？

老实说，两年前我也觉得这类需求很重。直到在项目里用 Dify 社区版把“知识库 + Agent”串起来之后，才发现多数场景根本不需要从零训练模型，也不需要写大量业务代码。你只需要把一个开源平台部署起来，做好知识库分段和检索配置，再通过可视化工作流编排一个 Agent，就能得到一个基本可用的“游戏专属问答助手”。

这篇文章就以“三角洲专属游戏助手”为实战目标，完整拆解 Dify + RAG + Agent 的实现过程。内容覆盖基础概念、环境部署、知识库搭建、Agent 工作流编排、API 接入和常见排错，适合刚开始接触 AI 应用开发的读者，也适合想快速把内部知识变成问答助手的业务同学。文中示例不会依赖具体某个模型厂商，所有关键配置都会说明作用。

1. 为什么要用 Dify+RAG+Agent 做游戏助手？

1.1 零代码做 AI 助手，到底靠什么实现

传统开发一个问答系统，至少需要解决三件事：大模型 API 对接、业务知识存储、对话流程管理。如果是企业级场景，还要考虑多用户隔离、日志审计、权限管理。这些工作量对普通业务团队来说并不小，尤其在没有专职算法工程师的情况下，很容易卡在“模型有了，但不知道怎么把它变成产品”。

Dify 这类 LLMOps 平台做的事情，就是把上面的通用能力提前做好。你只需要在界面上配置模型、上传知识库、拖拽工作流节点，就能生成一个带 Web 界面的 AI 应用。它不要求你精通 Prompt 工程，也不需要写复杂的对话管理代码。社区版可以本地部署，数据自主可控，很适合做内部工具和垂直场景助手。

这套方案的核心组合是：

• Dify：负责应用编排、模型接入、对话管理、日志和权限。
• RAG（检索增强生成）：负责把“游戏攻略”“武器数据”这类私有文档变成模型可以检索的知识。
• Agent：负责拆解用户问题、调用工具、组织最终回复。

这三者配合起来，开发者的工作重心就从“写代码”转移到了“整理知识、设计流程、调优效果”。

1.2 三个概念一次讲清楚

先用大白话解释一下三个关键词：

Dify

Dify 是一个开源的 LLMOps 平台，中文常称为“大模型应用开发平台”。它提供模型管理、Prompt 编排、知识库、工作流、Agent、API 接入等能力。你可以把它理解为“AI 应用的组装车间”，大部分功能通过可视化界面完成。

社区版支持私有化部署，常见方式是基于 Docker 运行。如果你需要接入多个模型供应商，比如 OpenAI、通义千问、DeepSeek、Ollama 本地模型等，Dify 也提供了统一接入层。

RAG

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。

它的核心思路是：让大模型在回答之前，先去外部知识库中检索相关片段，再把检索到的内容作为上下文一起交给模型生成答案。

这样做有几点好处：

• 回答内容更贴近你的私有资料。
• 减少模型幻觉，回答更可解释。
• 不需要微调模型，知识更新只需重新更新知识库。

RAG 是实现“专属助手”最实用的技术路线。

Agent

Agent 可以理解为“具备自主决策能力的对话体”。它不仅仅是“你问我答”，而是能够理解用户意图，规划步骤，调用工具，最后综合信息给出回答。

在 Dify 中，Agent 通常通过工作流或 Agent 节点实现。它可以调用知识库检索、HTTP 请求、代码执行、参数提取等工具。比如用户问“帮我对比一下两把武器的属性”，Agent 可以先拆解为“查询武器A属性”“查询武器B属性”“生成对比结论”三个步骤。

1.3 这套方案能解决什么问题

“三角洲专属游戏助手”是一个典型的垂直场景应用。假设你手里有游戏攻略、枪械数据、地图点位、任务剧情等资料，希望玩家能通过自然语言获得答案。

如果直接用通用大模型，它可能不知道你的私有攻略内容。如果只做知识库，它又只能做简单的检索问答，无法处理“对比、推荐、多轮追问”等复杂请求。

Dify + RAG + Agent 的组合解决了三个层次的问题：

1. 知识供给：通过 RAG 保证回答来源是你的私有文档。
2. 流程编排：通过 Agent 拆解复杂任务，提升交互体验。
3. 应用落地：通过 Dify 快速发布为网页应用或 API 服务。

接下来的内容，我将按真实落地路径一步一步操作。

2. 环境准备：先把 Dify 社区版跑起来

2.1 部署方式选择

Dify 社区版推荐使用 Docker Compose 部署。这种方式依赖少、升级方便，适合本地学习和生产试用。

部署前你需要准备：

• 一台 Linux 服务器或本地主机，建议 4 核 8G 以上。
• 安装 Docker Engine 和 Docker Compose 插件。
• 一个可以访问的模型 API，或本地部署的模型服务。

需要注意：Dify 本身不提供大模型能力，你需要提前确定模型供应商。如果是学习阶段，可以使用各大厂商的在线模型 API；如果对数据安全要求高，可以接入 Ollama、vLLM 等本地模型方案。

本文不绑定具体版本，因为 Dify 迭代速度较快。实际操作时建议使用官方最新的稳定版本镜像，并按官方文档拉取代码。

2.2 编写 docker-compose 配置并启动

Dify 官方仓库提供了完整的 docker-compose.yaml 示例。如果你希望定制端口或挂载目录，可以创建一个项目目录，然后写入自己的配置。

以下是一个可用于启动 Dify 核心服务的最小配置示例，注意替换你本地的路径：

version: '3' services: api: image: langgenius/dify-api:latest restart: always environment: MODE: api SECRET_KEY: your-secret-key DB_USERNAME: postgres DB_PASSWORD: difyai123456 DB_HOST: db DB_PORT: 5432 DB_DATABASE: dify REDIS_HOST: redis REDIS_PORT: 6379 REDIS_PASSWORD: difyai123456 STORAGE_TYPE: local STORAGE_LOCAL_PATH: /app/api/storage volumes: - ./storage:/app/api/storage depends_on: - db - redis worker: image: langgenius/dify-api:latest restart: always environment: MODE: worker SECRET_KEY: your-secret-key DB_USERNAME: postgres DB_PASSWORD: difyai123456 DB_HOST: db DB_PORT: 5432 DB_DATABASE: dify REDIS_HOST: redis REDIS_PORT: 6379 REDIS_PASSWORD: difyai123456 STORAGE_TYPE: local STORAGE_LOCAL_PATH: /app/api/storage volumes: - ./storage:/app/api/storage depends_on: - db - redis web: image: langgenius/dify-web:latest restart: always ports: - "3000:3000" environment: CONSOLE_API_URL: '' APP_API_URL: '' APP_WEB_URL: '' db: image: postgres:15-alpine restart: always environment: POSTGRES_PASSWORD: difyai123456 POSTGRES_DB: dify volumes: - ./db/data:/var/lib/postgresql/data redis: image: redis:7-alpine restart: always command: redis-server --requirepass difyai123456

启动命令：

docker compose up -d

等待容器启动后，访问http://服务器IP:3000即可进入 Dify 控制台。

这里要提醒两点：

1. 上面的配置只是最小示例，生产环境建议通过官方安装脚本或官方仓库的 docker-compose.yaml 启动，避免遗漏中间件。
2. 首次使用需要先设置管理员账号，流程很简单，按页面提示即可。

2.3 接入模型：在 Dify 中配置供应商

进入 Dify 控制台后，点击右上角头像，进入“设置 -> 模型供应商”。

这里可以配置多种模型，常见的有：

• OpenAI：配置 API Key，默认使用 gpt 系列模型。
• Azure OpenAI：适合企业用户。
• 通义千问：配置 DashScope API Key。
• DeepSeek：配置 API Key。
• Ollama：本地模型，适合数据不出内网的场景。

操作方式基本一致：选择供应商，填入 API Key，点击保存。不同模型的模型名称和计费规则不同，需要你根据自己的实际账号调整。

模型配置完成后，还需要设置一个“默认系统推理模型”。在创建应用时，Dify 会优先使用这个模型作为对话模型。

如果你使用的是 Ollama 本地模型，需要确保 Dify 服务可以访问到 Ollama 的服务地址。例如 Ollama 部署在同一台机器上，地址通常为http://host.docker.internal:11434或http://<服务器IP>:11434。

3. 先理解 RAG：知识库才是助手的“大脑”

3.1 知识库的完整工作流程

RAG 不是一个单独的文件，而是一条处理链路。在 Dify 中，知识库的构建分为两个阶段：

1. 离线索引阶段：把文档拆分成片段，调用 Embedding 模型生成向量，并存入向量数据库。
2. 在线检索阶段：把用户问题转换为向量，在向量库中查找相似片段，返回给大模型作为上下文。

Dify 默认使用向量检索，也支持全文检索和混合检索。理解这条链路，有助于你调试效果，而不是盲目上传文档。

3.2 文本分段与索引策略

在 Dify 中创建知识库时，需要选择“分段设置”。常见模式有：

• 自动分段：平台根据文档标题、段落边界自动拆分。
• 自定义分段：手动设置分隔符、最大分段长度、重叠长度。

分段长度对检索效果影响很大。如果分段太长，模型可能被无关信息干扰；如果太短，语义信息不完整。一般建议先按段落自动分段，再根据实际检索质量微调。

重叠长度也很关键。它可以保留相邻片段的上下文，避免一句话被切到两个片段时丢失语义。例如设置最大长度 500 字符、重叠 50 字符，相邻片段会共享 50 个字符的内容。

索引方式上，Dify 提供了“高质量”和“经济”两种模式：

• 高质量：使用 Embedding 模型生成向量，检索效果更好，但会产生模型调用费用。
• 经济：使用关键词索引，适合文档量很小或对效果要求不高的场景。

对于游戏助手这种需要准确回答“武器数值”“地图点位”的场景，建议选择高质量模式。

3.3 召回模式与检索参数

在应用编排中，你可以设置知识库的召回模式。Dify 支持两种方式：

• 单路召回：只走向量检索或全文检索。
• 多路召回：向量检索 + 全文检索同时进行，再综合排序，召回率更高。

对于游戏攻略类文档，用户问题的表达方式非常多，比如“AKM 用啥子弹”和“AKM 的弹药类型”表达不同但语义接近。混合召回模式能提升这部分问题的命中率。

召回数量（Top-K）和相关性阈值也需要按场景调整：

• Top-K：返回给模型的知识片段数量，默认 3 左右。
• 相关性阈值：低于该分数的片段会被过滤掉。

Top-K 设置过大，模型可能被不相关内容干扰；设置过小，可能漏掉有效信息。建议从 3 开始，根据测试结果逐步调整。

4. 搭建“三角洲专属游戏助手”知识库

4.1 明确知识范围和素材准备

在创建知识库之前，先想清楚一个问题：你的助手需要回答哪几类问题？

以“三角洲行动”游戏助手为例，可以整理成以下分类：

你可以把素材整理成 Markdown、TXT、Word 或 PDF 文件，尽量做到内容结构清晰，比如每个章节有明确标题。

不建议直接上传一堆未整理的聊天记录，那样检索效果会很差。

4.2 创建空知识库与分段设置

在 Dify 控制台点击“知识库 -> 创建知识库”，填写名称和描述。例如：

• 名称：三角洲行动攻略库
• 描述：包含枪械数据、地图点位、任务攻略等内容

随后进入“分段设置”页面。如果你没有特殊要求，可以先选用自动分段，后续再根据效果手动调整。

如果要手动配置，可以参考如下参数：

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

这里需要注意的是，分隔符和长度需要根据你的文档格式设计。如果是结构化明细表，建议把每行作为一个独立段落，避免多行合并后语义混乱。

4.3 上传文档与检索测试

分段设置完成后，进入上传文件页面，把准备好的攻略文档拖拽进去。Dify 会按所选模式进行索引。索引完成后，你可以在“文档”列表中看到分段数量和索引状态。

接下来做一次检索测试。点击“召回测试”，输入一个典型问题，例如：

三角洲行动的武器配件怎么选？

观察返回的片段是否与问题相关。如果返回结果偏离主题，可以从几个方向调整：

• 检查文档是否被正确分段。
• 检查 Embedding 模型是否配置正确。
• 调整分段长度和重叠长度。
• 检查是否设置了过高的相关性阈值。

检索测试很重要，因为“知识库里有没有”和“模型回答好不好”是两个独立的问题。如果你发现模型答非所问，不要只调 Prompt，先确认检索出来的片段是否准确。

5. Agent 工作流：让助手学会“自动处理”

5.1 创建聊天助手应用

在 Dify 控制台点击“应用 -> 创建应用”，选“聊天助手”。

填写应用名称，例如“三角洲专属游戏助手”，选择模型。

在“提示词编排”页面，你可以设置系统提示词，也就是给助手设定角色和行为规则。

下面是一个可以参考的提示词写法：

你是一位熟悉三角洲行动游戏的资深玩家兼攻略助手。 你的任务是根据知识库中的资料，回答玩家关于游戏玩法、武器配装、地图策略和任务流程的问题。 回答要求： 1. 优先引用知识库中的内容，不要编造不存在的数据。 2. 如果知识库中没有答案，明确说明“当前知识库中没有找到相关信息”。 3. 回答尽量简洁、准确，必要时分点说明。

这个提示词并不复杂，但它决定了助手的行为边界。建议先写清楚“能做什么、不能做什么、回答风格是什么”。

5.2 添加知识库和召回参数

在聊天助手编排页面，找到“上下文”区域，把刚才创建的知识库添加进来。

添加后，可以设置召回参数：

召回模式：多路召回 Top-K：3 相关性阈值：0.5

这些参数的含义在前面已经介绍过。不同业务场景需要做不同程度的尝试。游戏攻略类问题通常比较直接，可以先从多路召回开始。

这里需要特别说明：上下文不一定越多越好。有些场景下，用户问题比较明确，只需要 2~3 个片段就能回答；如果塞入过多片段，模型反而可能提取到错误信息。

5.3 使用 Agent 节点编排复杂逻辑

如果只回答问题，聊天助手已经够用。但“助手”和“Agent”的区别在于能否主动决策。

在 Dify 工作流编排中，你可以创建一个“Agent 节点”，它可以支持以下能力：

• 知识检索工具。
• HTTP 请求工具。
• 代码执行工具。
• 参数提取工具。

比如用户问：

我想知道三角洲行动里哪个机枪扫射稳一点，推荐一下。

普通的单轮知识库问答也能回答，但它可能只是把知识片段重新组织一遍。如果你希望得到更个性化的推荐，Agent 可以拆解为：

1. 从知识库中检索机枪列表和武器属性。
2. 提取扫射稳定性相关的数值。
3. 按数值排序并给出推荐理由。

Dify 的工作流可视化编辑界面中，你可以用简单的拖拽操作完成这个编排，完全不需要写传统后端代码。

5.4 发布应用与调试

应用编排完成后，点击右上角“发布”。

Dify 会生成两个入口：

1. Web 应用页面：可以直接在浏览器中体验。
2. API 访问：提供对话接口，供外部系统调用。

在发布之前，建议先在“调试预览”面板多轮测试。例如：

你：三角洲行动里哪个模式适合新手？ 助手：根据知识库中的玩法说明，推荐先从标准模式开始……

如果你发现回答质量不理想，优先排查：

• 提示词是否限制了回答范围。
• 知识库检索结果是否相关。
• 模型选择是否合适。
• 是否需要多轮对话记忆。

6. 进阶：用代码调用助手接口

很多场景下，你希望把助手集成到自己的网站、公众号或第三方系统中。Dify 提供了 API 接口，我们可以通过 HTTP 调用它。

6.1 获取 API Key

在应用详情页，找到“API 访问”区域，创建一个 API Key。

同时，你需要知道两个地址：

• 对话接口地址：/v1/chat-messages
• 应用 ID：应用访问路径中的一部分

调用方式遵循 OpenAI 兼容规范，但 Dify 的请求体略有不同。

6.2 Python 调用示例

下面是一个简单的 Python 调用示例，演示如何向 Dify 应用发送消息并获取回复。请将YOUR_APP_API_KEY和YOUR_APP_ID替换为实际值。

import requests url = "http://localhost:3000/v1/chat-messages" api_key = "YOUR_APP_API_KEY" payload = { "inputs": {}, "query": "三角洲行动里 AKM 推荐用什么配件？", "response_mode": "blocking", "conversation_id": "", "user": "test-user", "files": [] } headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } response = requests.post(url, json=payload, headers=headers) print(response.json())

预期返回结果中会包含answer字段，这是助手的回复内容。如果设置了response_mode为streaming，则返回的是流式数据，适合实现打字机效果。

如果你希望开启多轮对话，需要把上一轮返回的conversation_id传到下一次请求中，这样 Dify 才能保持对话上下文。

这段代码只是演示基本调用方式，生产环境建议加上超时重试和异常处理。

7. 常见问题与排查思路

在实际搭建过程中，大家最容易踩的坑往往是部署细节和参数设置。下面整理一张常见问题表，供你快速定位。

这里列出的问题都是实际使用中最常见的。如果你遇到其他报错，建议先看 Dify 的容器日志，大多数错误会直接打印在日志中。

查看日志的命令：

docker compose logs -f api

8. 最佳实践与工程建议

8.1 知识库要持续维护

AI 助手的知识库不是一次建设就能长期使用的。游戏版本更新、武器调整、地图改动后，旧文档可能产生错误答案。

建议建立一套更新机制：

• 每次文档有变更，及时在 Dify 中重新同步或上传新版本。
• 定期清理过期文档。
• 对高价值文档做版本标记。

Dify 知识库支持文档更新和删除，你可以根据实际业务频率安排维护周期。

8.2 模型选择要有取舍

不同模型在知识问答任务上的表现差异很大。如果你的用户主要使用中文提问，建议优先测试中文能力较好的模型。

同时也需要考虑模型调用成本。在“高质量”检索模式下，不仅对话会产生模型调用，文档索引时也会调用 Embedding 模型。如果文档量很大，可以先抽样测试效果，再决定是否全量索引。

8.3 提示词和上下文分离

在 Dify 应用中，系统提示词和知识库上下文是两套体系。不要把所有业务规则都塞进提示词中。提示词只负责定义角色边界和回答风格，具体事实内容交给知识库。

这样做的好处是：知识更新不需要频繁改提示词，提示词优化也不会影响知识库索引结果。

8.4 明确数据与权限边界

如果这个助手要对真实的玩家群体开放，请关注以下几点：

• 不要上传包含个人隐私的文档。
• 不要在知识库中放入未公开的敏感信息。
• 如果涉及内部数据，建议在内网环境部署，并限制 API Key 的访问范围。
• 对玩家的提问内容做好日志保留和审计。

Dify 社区版默认提供的是基础权限能力。如果有多租户、精细权限管控需求，可以考虑使用商业版或基于社区版做二次开发。

8.5 留存对话日志评估效果

上线不是终点。建议定期分析玩家提问记录，找出高频但回答质量不佳的问题。

你可以分两步做：

1. 从 Dify 的日志中导出对话数据。
2. 把高频问题整理成测试集，每次调整知识库或提示词后，跑一遍回归测试。

这套方法比“感觉回答变好了”更可靠。

8.6 版本升级要注意

Dify 社区版更新频率较快。升级前一定要先备份数据库和存储目录。

Dify 使用的是 PostgreSQL 和 Redis，升级前可以用以下思路制定备份计划：

• 停掉服务。
• 备份容器卷目录（或执行数据库导出）。
• 拉取新版本镜像并启动。
• 验证核心功能是否正常。

不要在没有备份的情况下直接升级，尤其是知识库和用户数据比较多的环境。

9. 总结与下一步学习路线

到这里，我们已经完整走了一遍“Dify 部署 -> 知识库搭建 -> Agent 编排 -> API 接入”的流程。你会发现，整个过程中真正需要写的代码非常少，核心工作变成了“整理知识、配置参数、调试效果”。

如果你准备继续深入研究，可以从这几个方向入手：

1. 深入掌握 RAG：研究分块策略、Embedding 模型选型、混合检索排序等底层原理。
2. 学习工作流编排：在 Dify 中尝试更复杂的条件分支、循环节点、HTTP 工具等能力。
3. 掌握 Prompt 工程：学习如何设计高质量的系统提示词，让 Agent 的行为更可控。
4. 了解 Agent 框架：如果 Dify 的可视化已经不能满足需求，可以研究 LangChain、Dify SDK 等更底层的开发方式。
5. 关注生产运维：包括模型 API 的成本控制、知识库更新机制、日志监控和安全审计。

“不做代码就能玩 AI”并不是一句口号，而是 Dify 这类平台带来的真实开发方式转变。但需要清醒的是：平台降低了编码门槛，却没有降低对业务理解、知识整理和效果评估的要求。

希望这篇文章能帮你迈出第一步。如果过程中遇到其他问题，欢迎在评论区一起交流。收藏备用，动手跑通一次，你会对 RAG 和 Agent 的理解上一个台阶。