Dify、RAG、Agent 这三个词放在一起很容易让人以为这是一套需要写大量代码的 AI 工程模板。实际上如果只是做一个游戏问答助手而不是做一个完整的企业级平台用 Dify 社区版配合 RAG 和 Agent大部分流程可以靠界面配置完成代码量可以压到很少。我最近就把三角洲游戏的攻略资料、枪械配件说明、地图点位和版本更新公告整理成一个知识库再通过 Dify 搭了一个专属问答助手。跑通之后最大的感受是门槛比想象中低但“不用敲代码”不等于“不用动脑子”。下面按我实际操作的顺序从部署到知识库再到 Agent 应用和排查思路完整拆一遍。1. 先拆清楚Dify、RAG、Agent 在这个项目里各自干什么Dify、RAG、Agent 这三个概念在游戏助手里分别承担不同角色。先把分工搞清楚后面配置时才不会被界面选项绕晕。1.1 三个概念的分工Dify 是一个 LLM 应用开发平台可以理解为 AI 应用的“工作台”。它不是模型本身而是负责把模型、知识库、工具和流程串起来的地方。你不用自己写前端页面也不用自己搭后端服务在 Web 界面里完成大部分配置。RAG 是检索增强生成。标准大模型只会根据训练数据里的信息回答遇到私有资料、最新攻略、未公开的更新内容时很容易答不上来或乱编。RAG 的思路是先准备一个知识库把资料切块、向量化、存进向量数据库用户提问时先检索出与问题相关的片段再把这些片段和问题一起交给模型让模型基于资料生成答案。Agent 在 Dify 里更多是让应用具备“自动规划和调用工具”的能力。游戏助手里Agent 可以决定什么时候联网查最新公告、什么时候调用计算器算配装数值、什么时候直接查知识库。它不是必须有但能让助手处理更复杂的问题。为了更直观可以这样看概念本项目的角色缺了它会怎样Dify应用底座、可视化配置需要自己写前后端和 APIRAG让助手参考知识库回答模型不了解你的游戏资料容易乱编Agent让助手调用工具、拆解任务只能处理单轮检索问答1.2 “不用敲代码”的真实边界标题里的“不用敲代码”说的是应用层。在 Dify 里创建应用、上传知识库、配置提示词、编排工作流确实不需要你从零写 Python 工程。但完全不接触代码不太现实。比如你后面要接搜索工具、想把 API 暴露给小程序仍然要理解接口概念有时还要改一点 JSON 配置。做游戏助手时我通常把预期分成两层。第一层纯知识库问答完全可以在界面里完成第二层带工具调用、多知识库、自定义逻辑的复杂应用至少要看懂错误日志和接口返回。清楚这个边界就不会因为“一开始没写代码”而期待过高也不会因为“碰了一点代码”就放弃。1.3 游戏助手具体要解决什么问题以三角洲问答助手为例我会把问题分成三类。攻略类比如新手用什么枪、哪张地图适合练枪数据类比如某把枪怎么配装、某个技能的具体数值版本类比如当前版本改了什么、新增了什么内容。第一类靠知识库里的攻略资料第二类靠结构化数据表第三类靠知识库持续更新或者接一个搜索工具。这个分类很重要因为不同问题对应的技术手段不同。只有攻略类问题适合用 RAG 解决版本类问题如果知识库没跟上模型就只能瞎猜。我建议动手前先列一个“助手会回答什么”的清单再决定资料怎么准备。2. 本地部署 Dify先把平台跑起来再谈 RAG很多人第一步就卡在部署。其实 Dify 本地部署不复杂但环境判断要先做对。2.1 部署前先判断机器条件Dify 社区版通常采用 Docker Compose 方式部署。部署前先看四件事操作系统Windows、macOS、Linux 都行。Windows 建议提前装好 Docker Desktop 或 WSL2内存至少预留 8GB如果同时跑多个容器16GB 更舒服磁盘镜像、依赖服务、日志、知识库文件都会占空间预留 20GB 以上更稳GPU如果模型和 Embedding 都用在线 APIGPU 不是必选项只有跑本地大模型才需要重点看显存。先确认这些不是为了追求高配而是避免辛苦装到一半因为内存不足或磁盘满导致启动失败。2.2 用 Docker Compose 启动Dify 官方仓库里提供了完整的 Docker 编排文件。部署前一定要先看清官方文档因为不同版本的目录结构可能有差异。大致流程如下git clone Dify官方仓库地址 cd dify/docker cp .env.example .env docker compose up -d如果你之前没装过 Docker 容器第一次会拉取很多镜像耗时较长。启动后不要急着配置应用先确认容器状态docker compose ps看到核心服务都是运行状态再继续进行。我最初部署时直接用了默认环境变量Web 界面能打开但模型供应商没配置对话时一直报错。这时候不是 Dify 本身出了问题而是还没把模型接入。注意第一次先把默认配置跑通不要一上来就调并发、调切块、调一堆高级参数。先让链路完整地走一遍。2.3 启动后先检查什么Web 界面能打开只代表前端正常。真正要看的是三件事模型是否连通。在设置里填好模型供应商的 API Key或者配置本地模型地址然后发一条测试消息容器是否健康。反复重启、端口冲突、磁盘写满都会让应用看起来正常但实际上不能用日志是否可读。第一次排查报错时日志里会直接提示是 API 无法连接还是数据库连接失败。建议先把最小链路跑通平台能访问、模型能回复、日志没有致命报错。确认这三件事再进入知识库搭建。不要一上来就调一堆和部署无关的参数。3. 给助手做“记忆”搭建三角洲游戏知识库部署好平台之后最关键的步骤是知识库。RAG 效果好不好七成取决于知识库本身。3.1 资料准备先想清楚放什么进知识库游戏助手的知识库本质是“你希望助手掌握的资料”。我一般整理成三种攻略文章新手入坑、武器评测、地图打法数据表格枪械配件、角色技能、材料掉落更新公告版本改动、活动说明。最开始不要贪多。先放质量最高、最常被问的 10 到 20 份资料跑通流程后再扩充。资料格式尽量统一Markdown 和 TXT 最好处理复杂 PDF 和扫描件要先转成文本否则检索时经常断章取义。文件名也要有规律比如按类别命名方便后面排查。3.2 分段和切块策略RAG 里的“检索”是面向片段进行的而不是面向整个文件。因此分段非常重要。切块太长的后果是一段里混入多个问题检索到这段后模型分不清该用哪部分信息。切块太短的后果是一个关键信息被截成两半模型拿到不完整的上下文只能靠猜。我习惯用这样的方式调先按知识库默认参数上传查看分段预览如果一段里有好几个无关话题把最大分块长度调小如果一个问题横跨两段把重叠长度调大一点表格类内容尽量整段保留不要强行切开。单个知识库里不同文件的理想分段可能不同。资料主题越单一分段越容易调好。比如“配装数据”一个文件、“玩法攻略”一个文件分段策略可以分开设置。不要迷信某个固定数字。游戏攻略这种短条目居多的资料分段控制在 200 到 500 字左右通常比较合适但最终要以你的实际资料为准。3.3 向量化与召回验证上传资料后选择 Embedding 模型。Embedding 负责把文本变成向量让系统能算相似度。在线 API 部署最省事本地模型部署需要关注显存和响应速度。个人项目不需要在向量数据库选型上花太多时间先用 Dify 默认方案即可。上传完成不是结束。真正的验证方式是“召回测试”输入一个问题看系统先从知识库里捡回哪些片段。判断标准很简单返回片段与问题主题一致关键信息完整没有明显无关片段混进来。如果召回结果不对优先调切块、换资料格式或检查是否选错知识库。不要先改大模型提示词。召回不对改提示词也没用。4. 把知识库接进 Agent创建第一个游戏问答助手平台跑通、知识库建好接下来就是创建一个真正能对话的应用。4.1 创建聊天助手选择模型Dify 里可以直接创建“聊天助手”类型的应用。模型选择上如果只是个人测试用在线 API 最省事如果你后续想完全离线再考虑本地模型。模型负责的是“生成回答”不是“理解你的资料”。它只能根据知识库检索出来的片段生成文字。所以不要指望换一个更强的模型就能解决知识库没建好的问题。先让模型会引用资料再谈模型能力。4.2 关联知识库与提示词设计创建应用后把知识库关联进去。接下来是提示词设计。我一般会给助手定四条规则身份定义你是三角洲游戏问答助手资料约束只能根据知识库内容回答兜底约束知识库没有答案时直接说没找到不能编造引用约束涉及具体数值和配置时先说明来源片段。一个示例提示词可以这样写你是三角洲游戏问答助手。回答问题时只基于提供的知识库内容。 如果知识库中找不到明确信息请直接回复“资料库中没有找到相关信息”不要推测或编造。 涉及枪械数据、数值和配装建议时尽量引用知识库中的原文。提示词不需要很长但边界要清楚。RAG 应用最常见的尴尬是模型拿到了资料却不好好用而是按自己的理解自由发挥。提示词里的“只基于知识库”就负责压住这个问题。提示词不是越长越好关键是给模型划清语言行为的边界。4.3 Agent 模式加工具什么时候需要加如果你想做标题里说的 Agent可以在应用里启用 Agent 模式并添加工具。但我更建议按需添加。纯攻略问答普通聊天助手加知识库就够了只有出现以下需求才考虑工具需要查最新公告加一个搜索工具需要计算配装数值加一个计算器工具需要记录玩家偏好加一个笔记或会话记忆工具。工具不是越多越好。Agent 每多一个工具模型就要多一次判断工具返回格式复杂时回答稳定性会下降。第一次做先不加工具等 RAG 问答稳定了再逐步加。先用单条任务测试工具能不能被正确调用再放到正式流程里。4.4 用样例问题验证效果用一组真实问题测试比如“M4A1 怎么配装”“新手优先练哪个角色”“哪个地图适合刷资源”“最近版本有什么更新”逐条发送看回答是否稳定。重点看回答里有没有知识库中的具体内容有没有出现模型自己编的细节是不是每次都能稳定命中同类问题。如果回答很泛先打开调试信息看检索到了什么。很多时候模型答错是因为根本没检索到正确片段而不是不会说话。这一步的验证方式直接决定下一步是改知识库还是改提示词。5. 从单条测试到批量落地工作流、发布与稳定运行单个问题测试通过后离“能用”还差几步。这个阶段会明显拉开新手和老手的差距。5.1 先跑通单条再做批量评估不要只看一两个问题就急着发布。我一般会准备 20 到 50 条问题覆盖攻略、数据、版本、闲聊四类然后逐条跑。跑完逐条记录回答合格的打勾不合格的看原因。一段时间后你会发现失败问题集中在某几类版本类问题全挂说明知识库没有对应新资料数据类问题答偏说明表格分段有问题闲聊问题不稳定提示词里没有规定边界。批量评估的意义不是追求每条都满分而是找到共性失败点。找到之后再针对性调整效率会高很多。5.2 用工作流把多步流程串起来当项目从单轮问答走向稳定就可以用 Dify 工作流把流程固定下来。常见流程是用户提问 - 意图判断 - 知识库检索 - 大模型生成 - 相关性检查 - 输出或兜底。为什么要这样串因为单纯靠聊天助手自由发挥有些问题可能会走到错误分支。工作流可以自动处理问题改写长问题先改写再检索多路召回同时查多个知识库合并最相关片段兜底分支检索结果相关性不够时不硬答而是提示用户换一种问法。第一次做不建议从工作流起步。先跑通默认聊天助手再逐步搬进工作流这样出问题时更容易定位。工作流越多步骤调试成本越高不要一开始就设计得很复杂。5.3 发布为 Web 应用和 APIDify 可以把应用发布成网页版也可以生成 API。网页版适合自己用也可以复制链接给朋友测试API 适合接入网站、小程序或机器人。个人项目初期直接开一个公开链接测试就行不需要先搞复杂的前端。如果你准备接 API要注意API Key 不能写到前端公开代码里对外发布前设置合理的访问控制或限流记录调用日志方便排查问题。从“自己能用”到“别人能用”中间隔着一个稳定性和安全性问题不能跳过。低配置机器能跑通 Demo不代表能支撑多人同时访问。发布前先想清楚访问量大概是多少。5.4 知识库更新频率游戏版本会更新知识库也必须跟着更新。每次版本公告或攻略资料更新后把旧内容替换掉并重新同步索引。如果新旧资料混在同一知识库里模型可能会拿旧版本数值回答新版本问题这也是很多“助手突然不准”的隐藏原因。我的做法是每次新版本节奏开始时主动删掉过时公告再把新公告传上去跑一轮召回测试确认最新内容能命中。这个动作成本不高但能避免大量低质量回答。6. 常见问题排查不是报错才叫问题答得不对更要查最后一部分直接放排查思路。6.1 先看现象再动参数遇到问题时先记录现象不要乱改参数。常见现象有Web 界面打不开容器反复重启对话时一直在转圈没有返回回答速度很慢回答与问题不相关回答在编造细节Agent 反复调用同一个工具停不下来。现象不一样排查起点就不同。先确定是“环境问题”“数据问题”还是“逻辑问题”再看日志。6.2 按输入、环境、参数、工具的顺序排查我一般按照这个顺序输入知识库文件是否上传成功内容是否干净分段是否合理环境容器是否健康内存和磁盘是否够用API Key 是否有效参数检索 topK 是否太小温度是否过高模型是否选错工具Agent 工具描述是否清楚返回结果是否被模型正确解析。现象优先检查常见原因启动失败容器状态、端口、磁盘镜像不完整、端口冲突、内存不足回答不相关知识库召回结果切块太大或太小、资料不匹配回答乱编提示词和知识库模型没引用资料或资料没被召回回答很慢模型 API 和知识库规模API 响应慢、检索内容过多Agent 反复调用工具工具描述和迭代上限工具返回结构复杂、描述不清晰这个排查顺序能解决大部分问题。看起来像模型能力不足的往往在前面几步就出错了。6.3 这些边界别期待过高最后说几个容易误判的边界。本地部署不等于免费。Dify 平台本身开源但模型调用一般还是按量计费。支持 RAG 不等于所有格式都稳定。扫描版 PDF、复杂表格、图片型资料的识别效果经常不如纯文本。如果你的资料里有大量扫描件先转成文本再上传。低配置能跑不等于能支撑多人并发访问。几个朋友测试没问题不代表几百人同时用也能保持响应。Agent 不等于全自动。工具越多调用链越长越需要把边界和迭代上限写清楚。把预期放到正常范围很多“翻车”其实只是用错了场景。整套流程跑下来最值得投入精力的不是界面配置而是资料整理、切块策略、提示词边界这三件事。第一次做的时候我建议先把 RAG 问答做到“答得准、不乱编”再慢慢加 Agent 工具和工作流。很多看起来像模型能力不够的问题其实都是知识库没准备好。按这个思路做零基础也能把一个游戏问答助手从 idea 推到能用的版本。