在实际 AI 应用开发中构建一个能够理解复杂指令、调用多种工具并协同工作的智能体Agent系统正从概念走向工程实践。许多开发者尝试过 Coze 这类低代码平台它们提供了直观的拖拽式工作流能快速搭建简单的 AI 应用。然而当需求深入到需要结合私有知识库RAG、多步骤推理、以及多个具备不同能力的 Agent 协作时平台的封闭性和灵活性限制就显现出来了。例如你想打造一个专属的“三角洲游戏助手”它不仅要能回答游戏攻略还要能分析战局、推荐装备组合甚至模拟不同战术的胜率这背后涉及知识检索、逻辑判断、工具调用等多个环节的协同单一 Agent 或简单工作流往往难以胜任。这正是 Dify 结合 RAG 与多 Agent 协作架构的价值所在。Dify 作为一个开源 LLM 应用开发框架将 RAG 知识库、工作流编排和 Agent 能力作为核心组件开放出来。你可以基于它像组建一个开发团队一样设计不同的“专家”Agent让它们各司其职又相互配合。本文将带你从零开始完成一次深度实战我们将以构建一个“三角洲专属游戏助手”为目标演示如何利用 Dify 搭建一个包含“知识检索专家”、“战术分析专家”和“装备推荐专家”的多 Agent 协作系统。你会了解到如何将 Coze 上的设计思路迁移到更灵活的 Dify 工作流中并最终部署一个具备专业深度和复杂协作能力的 AI 应用。1. 理解核心概念RAG、Agent 与 Dify 工作流在开始动手之前我们需要厘清几个关键概念以及它们在 Dify 框架中的具体形态。这有助于理解我们为什么要选择这样的架构而不是一个单一的提示词工程。1.1 RAG为模型注入专属知识库RAGRetrieval-Augmented Generation检索增强生成解决的核心问题是模型的知识截止性和领域专有知识缺失。一个通用大模型可能不知道“三角洲行动”游戏里最新版本中某把枪的隐藏后坐力模式。RAG 的流程通常分为三步索引将你的专属文档如游戏 Wiki、更新日志、玩家攻略进行切片、向量化存入向量数据库。检索当用户提问时将问题向量化并从向量数据库中找出最相关的文本片段。增强生成将检索到的相关片段作为上下文连同用户问题一起提交给大模型要求其基于此上下文生成答案。在 Dify 中RAG 功能被封装为“知识库”。你只需上传文档Dify 会负责后续的预处理、嵌入和检索过程。在后续的多 Agent 协作中“知识检索专家”Agent 的核心能力就是调用这个知识库。1.2 Agent具备感知、规划和执行能力的智能体一个 Agent 不仅仅是调用一次 API。一个典型的 Agent 应该具备以下循环感知接收用户输入或来自其他 Agent 的请求。规划分析目标决定需要执行哪些步骤或调用哪些工具。执行调用工具如搜索、计算、查询数据库或使用内部能力如推理来执行步骤。观察评估执行结果判断目标是否达成。若未达成则重新规划。在 Dify 中你可以通过“工作流”来构建 Agent。工作流中的每个节点可以是一个 LLM 调用、一个工具Tool调用、一个知识库检索或者一个条件判断。通过编排这些节点你就定义了这个 Agent 的“大脑”运行逻辑。1.3 多 Agent 协作像团队一样分工单一 Agent 处理复杂任务容易“力不从心”或产生“幻觉”。多 Agent 协作系统将一个复杂任务分解为多个子任务由不同专长的 Agent 并行或串行处理。在我们的游戏助手场景中路由 Agent首先分析用户问题判断属于“知识问答”、“战术分析”还是“装备推荐”类别。知识检索 Agent如果问题涉及游戏背景、角色技能、地图信息等事实性知识则由该 Agent 调用 RAG 知识库获取信息并生成答案。战术分析 Agent如果用户提供了战局描述如“我方三人突击敌方有狙击手”该 Agent 可以调用规则引擎或分析模型给出阵型建议和胜率评估。装备推荐 Agent如果用户询问特定场景下的装备搭配该 Agent 可以基于游戏数据如武器属性表进行筛选、排序和组合推荐。这些 Agent 通过 Dify 的工作流进行连接可以传递数据和状态共同完成一个用户查询。1.4 Dify 工作流 vs. Coze 工作流Coze 的工作流设计直观适合快速原型验证。Dify 的工作流则更偏向开发者提供了更细粒度的控制节点类型更丰富除了 LLM 和基础工具Dify 支持代码执行、变量赋值、循环、条件分支等编程结构能构建更复杂的逻辑。数据流显式定义你需要手动连接节点的输入输出端口对数据在 Agent 间的流动有完全的控制权。更强的集成能力可以更方便地接入自定义 API、数据库便于将 AI 能力嵌入现有业务系统。 从 Coze 迁移到 Dify意味着从“配置”走向“开发”获得更高的自由度和系统集成能力。2. 环境准备与 Dify 部署我们将采用 Dify 的 Docker 部署方式这是最推荐且易于管理的方法。请确保你的开发环境满足以下要求。2.1 基础环境要求组件最低要求推荐配置说明操作系统Linux, macOS, Windows (WSL2)Linux (Ubuntu 20.04)生产环境建议使用 Linux。Windows 请务必使用 WSL2。Docker20.1024.0确保 Docker 守护进程正在运行。Docker Compose2.02.20用于编排多容器服务。CPU2 核4 核以上用于运行应用服务和向量数据库。内存4 GB8 GB 以上内存不足会导致向量检索或模型服务异常。磁盘20 GB50 GB 以上用于存储镜像、向量数据和知识库文档。首先通过以下命令检查 Docker 和 Docker Compose 版本docker --version docker-compose --version2.2 部署 DifyDify 官方提供了集成的docker-compose.yml文件一键启动所有服务包括前端、后端、数据库和向量数据库。下载部署文件 创建一个项目目录并进入然后下载官方编排文件。mkdir dify-game-assistant cd dify-game-assistant curl -o docker-compose.yml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yml启动服务 使用 Docker Compose 在后台启动所有服务。docker-compose up -d这个命令会拉取 PostgreSQL、Redis、Weaviate向量数据库和 Dify 自身的镜像并启动容器。首次启动可能需要几分钟时间下载镜像。验证部署 等待片刻后检查容器状态是否全部为Up。docker-compose ps你应该看到类似下面的输出Name Command State Ports --------------------------------------------------------------------------------------- dify-game-assistant-dify-api-1 /bin/bash /entrypoint.sh Up 5001/tcp dify-game-assistant-dify-web-1 /bin/bash /entrypoint.sh Up 0.0.0.0:80-3000/tcp dify-game-assistant-postgres-1 docker-entrypoint.sh postgres Up 5432/tcp dify-game-assistant-redis-1 docker-entrypoint.sh redis-server Up 6379/tcp dify-game-assistant-weaviate-1 /bin/weaviate --hos ... Up 8080/tcp访问并初始化 打开浏览器访问http://localhost如果 80 端口被占用请检查docker-compose.yml中 Web 服务的端口映射。按照页面提示完成管理员账号的初始化设置。2.3 配置大模型与嵌入模型Dify 本身不提供大模型需要你配置 API Key 或部署本地模型。为了实战的通用性我们以 OpenAI 的 GPT 系列和 OpenAI 的嵌入模型为例。你需要在 Dify 控制台进行配置。登录 Dify使用上一步创建的管理员账号登录。进入模型配置在左侧导航栏找到“设置” - “模型供应商”。添加 OpenAI点击“添加模型供应商”选择“OpenAI”。供应商名称自定义如OpenAI。API Key填入你的 OpenAI API Key。API Base URL如果你使用官方接口留空即可如果使用第三方代理填入对应地址。配置模型在“模型设置”页面需要配置两类模型语言模型用于对话和推理。点击“添加模型”选择供应商OpenAI模型选择gpt-4o-mini或gpt-4-turbo。为其命名如GPT-4o-Mini。嵌入模型用于将文本转换为向量。点击“添加模型”供应商同样选择OpenAI模型选择text-embedding-3-small。为其命名如OpenAI-Embedding。注意如果你没有 OpenAI API也可以配置其他支持的模型如 Anthropic Claude、通义千问、DeepSeek 等或者通过 OpenAI 兼容的 API如 LM Studio、Ollama 提供的本地模型进行连接。配置逻辑类似关键是确保“语言模型”和“嵌入模型”可用。3. 构建基石创建游戏知识库RAG我们的多 Agent 系统需要一个可靠的知识来源。首先我们为“三角洲专属游戏助手”创建一个 RAG 知识库。3.1 准备知识文档收集或创建关于“三角洲行动”游戏的文本资料格式可以是.txt,.md,.pdf,.docx等。例如weapons.md: 包含所有武器的名称、类型、伤害、射速、后坐力等属性。maps.md: 包含各地图的结构、关键点位、战术要点。characters.md: 包含各角色的技能、定位、升级路线。patch_notes_v1.5.md: 版本 1.5 的更新日志。将这些文档放在本地一个文件夹中如./game_docs。3.2 在 Dify 中创建并配置知识库创建知识库在 Dify 左侧导航栏点击“知识库” - “创建知识库”。名称三角洲游戏知识库描述三角洲行动游戏的武器、地图、角色与版本信息。点击“创建”。配置索引方法创建后进入知识库详情页点击“处理设置”。分词方式对于中文游戏文档选择“混合”或“精准”模式通常效果更好。文本分割根据文档结构调整“块大小”和“块重叠”。对于表格密集的武器数据块可以小一些如 300 tokens对于连贯的攻略文本块可以大一些如 500 tokens。重叠部分有助于保持上下文连贯。向量化模型选择之前配置的OpenAI-Embedding模型。保存设置。上传文档并索引在知识库详情页点击“上传文件”。将./game_docs下的文件全部上传。上传后Dify 会自动开始“索引”过程即将文档分块、向量化并存入 Weaviate。你可以在“文件列表”中查看每个文件的状态显示“已索引”即表示完成。3.3 测试知识库检索在投入 Agent 使用前先手动测试知识库是否工作正常。在知识库详情页找到“测试”区域。在输入框提问“破晓’这把突击步枪的射速是多少”点击“测试”。Dify 会展示检索到的相关文本片段Recall以及基于这些片段生成的答案Answer。如果答案准确说明知识库构建成功。如果检索不相关可能需要回到“处理设置”调整分词或块大小。4. 设计并实现多 Agent 协作工作流这是本文的核心。我们将创建一个主工作流内含一个路由节点和三个专家 Agent 节点。4.1 创建工作流并设计蓝图创建工作流在左侧导航栏点击“工作流” - “创建工作流”。命名为三角洲游戏助手多Agent协作。理解节点类型在工作流编辑器中从右侧面板拖拽节点到画布。关键节点类型开始节点工作流入口接收用户问题。LLM 节点调用大模型用于推理、判断、生成文本。知识库检索节点连接我们创建的知识库执行检索。代码节点执行 Python 代码可用于数据处理、调用外部 API。判断节点根据条件如变量值决定流程分支。变量赋值器设置或修改变量的值。结束节点工作流出口返回最终结果。我们的设计蓝图如下用户提问 | v [开始节点] - [路由判断 Agent] (LLM节点分析问题类型) | |-- (类型知识问答) - [知识检索 Agent] - [组装答案] - [结束] |-- (类型战术分析) - [战术分析 Agent] - [组装答案] - [结束] -- (类型装备推荐) - [装备推荐 Agent] - [组装答案] - [结束]每个“专家 Agent”本身也可以是一个包含多个步骤的子工作流或复杂节点。4.2 实现路由判断 Agent这个 Agent 负责对用户问题进行意图分类。拖入一个 LLM 节点命名为路由判断。配置该节点模型选择GPT-4o-Mini。系统提示词编写清晰的指令。你是一个游戏助手路由员。请严格根据用户问题判断其属于以下哪种类型 1. “知识问答”问题涉及游戏事实、背景、武器属性、角色技能、地图信息等。例如“M4A1的伤害是多少”“医疗兵有什么技能” 2. “战术分析”问题涉及对战策略、阵容搭配、局势判断、胜率评估等。例如“沙漠地图进攻方怎么打”“我方有狙击手和两个突击怎么推进” 3. “装备推荐”问题涉及武器、配件、道具的选择和搭配。例如“新手用什么枪好”“打狙击配什么副武器” 只输出一个类型关键词“知识问答”、“战术分析”或“装备推荐”。不要输出任何其他解释。用户输入连接开始节点的query变量。拖入一个判断节点命名为根据类型分流。配置判断条件将路由判断节点的输出变量如text连接到判断节点。设置三个分支条件{{#eq text “知识问答”}}- 连接到知识检索 Agent。{{#eq text “战术分析”}}- 连接到战术分析 Agent。{{#eq text “装备推荐”}}- 连接到装备推荐 Agent。4.3 实现知识检索 Agent这是最直接的 Agent主要调用 RAG 知识库。拖入一个知识库检索节点命名为知识检索。配置该节点知识库选择之前创建的三角洲游戏知识库。查询内容连接开始节点的query变量。检索模式选择“向量检索”并设置返回 Top K 为 3。拖入一个 LLM 节点命名为生成知识答案连接到知识检索节点之后。配置该节点模型GPT-4o-Mini。系统提示词你是一个专业的三角洲游戏助手。请基于提供的游戏资料准确、简洁地回答用户的问题。 如果资料中有明确数据请引用。如果资料中没有相关信息请如实告知“根据现有资料未找到相关信息”。 答案要友好并可以适当给出游戏内的小提示。上下文将知识检索节点的输出变量如result作为上下文填入。用户输入连接开始节点的query变量。此节点的输出将作为该分支的最终答案连接到结束节点。4.4 实现战术分析 Agent这个 Agent 更复杂需要结合规则或简单模型。我们用代码节点模拟一个简单的胜率分析。拖入一个 LLM 节点命名为解析战局。配置该节点模型GPT-4o-Mini。系统提示词请从用户描述中提取以下结构化信息 1. 地图名称。 2. 我方阵容角色和数量。 3. 敌方已知信息角色和数量。 4. 当前目标如“进攻A点”、“防守”。 请以 JSON 格式输出包含 map, ally, enemy, objective 四个字段。用户输入连接开始节点的query变量。拖入一个代码节点命名为胜率分析与建议。配置该节点语言选择 Python# 输入上一步 LLM 输出的 JSON 字符串 import json def main(input_json: str) - dict: try: data json.loads(input_json) map_name data.get(map, 未知) ally data.get(ally, []) enemy data.get(enemy, []) objective data.get(objective, ) # 这是一个非常简化的模拟分析逻辑 # 实际项目中这里可以接入更复杂的规则引擎或预测模型 base_win_rate 50.0 suggestion [] if 狙击手 in ally and 突击兵 in ally: base_win_rate 10 suggestion.append(狙击手与突击兵搭配良好建议狙击手占据高地掩护突击兵分路推进。) if 医疗兵 not in ally: base_win_rate - 5 suggestion.append(阵容缺乏治疗建议保持队伍集结避免单人深入。) if 爆破专家 in ally and 进攻 in objective: base_win_rate 8 suggestion.append(爆破专家对进攻目标有优势可快速破点。) # 确保胜率在合理范围 win_rate max(30.0, min(95.0, base_win_rate)) output { analysis: f基于当前阵容和目标的初步分析, estimated_win_rate: f{win_rate:.1f}%, tactical_suggestions: suggestion if suggestion else [阵容均衡保持沟通灵活应对。] } return output except Exception as e: return {error: f解析失败: {str(e)}}将解析战局节点的输出变量连接到这个代码节点的输入。拖入一个 LLM 节点命名为生成战术报告。配置该节点模型GPT-4o-Mini。系统提示词你是一个资深战术指挥官。请将以下分析结果组织成一段对玩家友好、鼓舞士气且具有操作性的战术报告。 报告结构1. 局势简述。2. 优势与劣势分析。3. 具体战术建议分点列出。4. 鼓励性结语。上下文将胜率分析与建议节点的输出作为上下文。用户输入连接开始节点的query变量。此节点的输出连接到结束节点。4.5 实现装备推荐 Agent这个 Agent 需要查询“武器属性表”我们可以结合知识库检索和代码逻辑。拖入一个 LLM 节点命名为解析装备需求。配置该节点模型GPT-4o-Mini。系统提示词请从用户问题中提取装备推荐的关键要素 1. 适用场景如“近战”、“远距离”、“新手”、“高机动”。 2. 武器类型偏好如“步枪”、“狙击枪”、“不限”。 3. 特殊要求如“低后坐力”、“高伤害”。 请以 JSON 格式输出包含 scenario, weapon_type, requirements 字段。拖入一个知识库检索节点命名为检索武器库。知识库三角洲游戏知识库。查询内容这里我们可以用动态查询。例如连接一个变量或者直接使用{{解析装备需求.output}}中的weapon_type字段来构造查询如{{weapon_type}} 武器属性。更复杂的做法是在代码节点中构造查询语句。拖入一个代码节点命名为过滤与排序装备。编写 Python 代码模拟从检索结果中解析武器数据并根据scenario和requirements进行过滤和排序。例如给“新手”推荐稳定性高的武器给“近战”推荐射速快的武器。拖入一个 LLM 节点命名为生成推荐理由。将过滤后的装备列表和用户原始问题作为输入让 LLM 生成自然语言的推荐理由和搭配建议。4.6 连接工作流并设置输出将三个专家 Agent 分支的最终输出节点生成知识答案、生成战术报告、生成推荐理由都连接到同一个结束节点。在结束节点的配置中需要设置工作流的最终输出变量。由于三个分支都会输出一个text变量LLM节点的默认输出我们可以直接配置结束节点输出{{text}}。Dify 的工作流引擎会自动传递当前激活分支的输出。5. 测试、调试与部署应用5.1 在工作流编辑器中测试点击工作流编辑器右上角的“预览”或“运行”按钮。在测试面板的输入框输入不同类别的问题进行测试知识类“医疗兵的生命恢复技能冷却时间是多长”战术类“我们在‘沙漠废墟’地图防守有两个突击兵和一个狙击手该怎么布防”装备类“我喜欢冲锋有什么适合近战的高射速武器推荐”观察工作流的运行过程。Dify 会高亮显示正在执行的节点并展示每个节点的输入和输出数据。这是调试多 Agent 协作逻辑的利器。5.2 发布为可访问的 AI 应用工作流测试无误后可以将其发布为一个独立的 AI 应用供最终用户通过 Web 界面或 API 调用。保存并发布工作流在工作流编辑器点击“发布”。创建应用在左侧导航栏点击“应用”选择“通过工作流创建”。选择工作流选择我们刚刚发布的三角洲游戏助手多Agent协作工作流。配置应用设置应用名称、图标和描述。在“提示词编排”页面你可以配置开场白、用户输入建议等但核心逻辑已由工作流定义。在“外部访问”页面可以获取到该应用的 API 地址和密钥。访问与分享应用创建后你会获得一个独立的 Web 聊天界面 URL可以分享给其他玩家测试。5.3 通过 API 集成对于想将助手集成到自己游戏社区或工具中的开发者可以使用 API。在应用设置中找到“API 访问”信息。使用以下格式的 cURL 命令进行测试curl --location https://your-dify-domain/v1/chat-messages \ --header Authorization: Bearer your-app-api-key \ --header Content-Type: application/json \ --data { inputs: {}, query: 破晓这把枪适合新手吗, response_mode: streaming, conversation_id: , user: test_user_001 }Dify 会以流式或非流式根据response_mode返回多 Agent 协作处理后的结果。6. 常见问题排查与优化在构建和运行此类多 Agent RAG 系统时你可能会遇到以下典型问题。6.1 知识库检索不准确问题现象可能原因检查与解决方式答案与问题无关1. 文档分割块过大或过小。2. 嵌入模型不适合领域文本。3. 查询词与文档术语不匹配。1. 调整知识库的“文本分割”设置尝试不同的块大小和重叠。2. 尝试不同的嵌入模型如text-embedding-3-large或专门的多语言模型。3. 在查询前让一个 LLM 节点对用户问题进行“查询重写”使其更贴近文档表述。检索不到任何内容1. 知识库未成功索引。2. 向量数据库连接异常。3. 查询语言与文档语言不一致。1. 在 Dify 知识库文件列表检查文件状态是否为“已索引”。2. 检查 Docker 容器weaviate是否运行正常日志有无报错。3. 确保查询语言与文档主要语言一致。答案包含幻觉RAG 检索到了部分相关文档但 LLM 在生成时超出了上下文范围。1. 在调用 LLM 的节点中强化系统提示词“严格依据提供的上下文回答问题如果上下文没有就说不知道。”2. 增加检索的 Top K 值提供更全面的上下文。3. 使用“引用”功能让 LLM 标明答案出自哪段文档。6.2 多 Agent 工作流逻辑错误问题现象可能原因检查与解决方式路由判断错误问题被分发给错误的 Agent。1. 路由 Agent 的提示词定义不清。2. 用户问题意图模糊。1. 细化路由提示词中的类型定义和例子让 LLM 更容易区分。2. 在路由前增加一个“意图澄清”节点当 LLM 判断置信度低时反问用户。某个 Agent 节点无输出流程中断。1. 节点输入变量连接错误。2. 代码节点存在运行时异常。3. LLM 节点因内容策略未返回结果。1. 在工作流测试中逐步运行检查每个节点的输入数据是否符合预期。2. 查看代码节点的错误日志增加异常捕获和日志输出。3. 检查 LLM 节点的输出是否为空或被过滤调整提示词。最终答案格式混乱。不同 Agent 分支的输出格式不一致。在最终汇聚到“结束节点”前增加一个“答案格式化”节点LLM或代码统一所有分支输出的格式。6.3 性能与成本优化减少不必要的 LLM 调用路由判断可以使用更小、更快的模型如gpt-3.5-turbo。在知识检索 Agent 中如果检索到的文档片段已经能直接回答问题如纯数据表格可以考虑不经过 LLM直接返回片段。使用本地模型对于嵌入和部分推理任务可以考虑部署开源模型如通过 Ollama 部署nomic-embed-text和qwen2.5:7b以降低 API 成本和提升数据隐私性。在 Dify 模型供应商中配置本地模型的 API 端点即可。实现 Agent 结果缓存对于常见、答案固定的知识类问题可以在工作流开始时加入缓存查询如查询 Redis。如果命中缓存则直接返回跳过后续所有 Agent 流程。异步与并行化如果多个专家 Agent 的任务相互独立可以考虑让它们并行执行最后再汇总结果。Dify 工作流目前更偏向串行但可以通过设计多个开始分支来模拟并行然后用“聚合”节点收集结果。7. 生产环境最佳实践将这样一个多 Agent 系统用于真实玩家社区需要考虑更多工程因素。配置管理外置不要将 API Key、模型名称、知识库 ID 等硬编码在工作流中。使用 Dify 的“变量”功能或环境变量来管理这些配置便于不同环境开发、测试、生产的切换。完善的日志与监控为工作流中的关键节点尤其是代码节点和 LLM 调用添加日志记录记录输入、输出和耗时。监控 API 的调用量、响应时间和错误率。Dify 企业版提供了更完善的可观测性功能。设置速率限制与熔断在应用配置或通过网关如 Nginx为你的 AI 助手 API 设置速率限制防止恶意调用或流量过载。对于依赖的外部模型 API要有熔断机制避免一个服务宕机导致整个助手不可用。数据安全与隐私如果知识库包含未公开的游戏数据确保 Dify 部署在内网或配置了严格的访问控制。审查用户与助手的对话日志避免敏感信息泄露。持续迭代与评估建立反馈机制收集用户对助手回答的满意度如“点赞/点踩”。定期用一批标准问题测试助手评估其准确率和响应时间根据结果迭代优化提示词、工作流逻辑或知识库文档。从 Coze 这样的可视化平台起步理解 AI 工作流和 Agent 的基本概念再深入到 Dify 这样的开发框架进行更自由、更深入的多 Agent 系统构建是一条可行的 AI 应用开发路径。本次实战搭建的“三角洲游戏助手”只是一个起点你可以在此基础上引入更复杂的工具调用如实时查询游戏数据库、更高级的规划逻辑如让 Agent 进行多轮思考甚至让 Agent 之间进行辩论和协商从而创造出真正智能、专属于你的新一代 AI 应用团队。
在实际 AI 应用开发中构建一个能够理解复杂指令、调用多种工具并协同工作的智能体Agent系统正从概念走向工程实践。许多开发者尝试过 Coze 这类低代码平台它们提供了直观的拖拽式工作流能快速搭建简单的 AI 应用。然而当需求深入到需要结合私有知识库RAG、多步骤推理、以及多个具备不同能力的 Agent 协作时平台的封闭性和灵活性限制就显现出来了。例如你想打造一个专属的“三角洲游戏助手”它不仅要能回答游戏攻略还要能分析战局、推荐装备组合甚至模拟不同战术的胜率这背后涉及知识检索、逻辑判断、工具调用等多个环节的协同单一 Agent 或简单工作流往往难以胜任。这正是 Dify 结合 RAG 与多 Agent 协作架构的价值所在。Dify 作为一个开源 LLM 应用开发框架将 RAG 知识库、工作流编排和 Agent 能力作为核心组件开放出来。你可以基于它像组建一个开发团队一样设计不同的“专家”Agent让它们各司其职又相互配合。本文将带你从零开始完成一次深度实战我们将以构建一个“三角洲专属游戏助手”为目标演示如何利用 Dify 搭建一个包含“知识检索专家”、“战术分析专家”和“装备推荐专家”的多 Agent 协作系统。你会了解到如何将 Coze 上的设计思路迁移到更灵活的 Dify 工作流中并最终部署一个具备专业深度和复杂协作能力的 AI 应用。1. 理解核心概念RAG、Agent 与 Dify 工作流在开始动手之前我们需要厘清几个关键概念以及它们在 Dify 框架中的具体形态。这有助于理解我们为什么要选择这样的架构而不是一个单一的提示词工程。1.1 RAG为模型注入专属知识库RAGRetrieval-Augmented Generation检索增强生成解决的核心问题是模型的知识截止性和领域专有知识缺失。一个通用大模型可能不知道“三角洲行动”游戏里最新版本中某把枪的隐藏后坐力模式。RAG 的流程通常分为三步索引将你的专属文档如游戏 Wiki、更新日志、玩家攻略进行切片、向量化存入向量数据库。检索当用户提问时将问题向量化并从向量数据库中找出最相关的文本片段。增强生成将检索到的相关片段作为上下文连同用户问题一起提交给大模型要求其基于此上下文生成答案。在 Dify 中RAG 功能被封装为“知识库”。你只需上传文档Dify 会负责后续的预处理、嵌入和检索过程。在后续的多 Agent 协作中“知识检索专家”Agent 的核心能力就是调用这个知识库。1.2 Agent具备感知、规划和执行能力的智能体一个 Agent 不仅仅是调用一次 API。一个典型的 Agent 应该具备以下循环感知接收用户输入或来自其他 Agent 的请求。规划分析目标决定需要执行哪些步骤或调用哪些工具。执行调用工具如搜索、计算、查询数据库或使用内部能力如推理来执行步骤。观察评估执行结果判断目标是否达成。若未达成则重新规划。在 Dify 中你可以通过“工作流”来构建 Agent。工作流中的每个节点可以是一个 LLM 调用、一个工具Tool调用、一个知识库检索或者一个条件判断。通过编排这些节点你就定义了这个 Agent 的“大脑”运行逻辑。1.3 多 Agent 协作像团队一样分工单一 Agent 处理复杂任务容易“力不从心”或产生“幻觉”。多 Agent 协作系统将一个复杂任务分解为多个子任务由不同专长的 Agent 并行或串行处理。在我们的游戏助手场景中路由 Agent首先分析用户问题判断属于“知识问答”、“战术分析”还是“装备推荐”类别。知识检索 Agent如果问题涉及游戏背景、角色技能、地图信息等事实性知识则由该 Agent 调用 RAG 知识库获取信息并生成答案。战术分析 Agent如果用户提供了战局描述如“我方三人突击敌方有狙击手”该 Agent 可以调用规则引擎或分析模型给出阵型建议和胜率评估。装备推荐 Agent如果用户询问特定场景下的装备搭配该 Agent 可以基于游戏数据如武器属性表进行筛选、排序和组合推荐。这些 Agent 通过 Dify 的工作流进行连接可以传递数据和状态共同完成一个用户查询。1.4 Dify 工作流 vs. Coze 工作流Coze 的工作流设计直观适合快速原型验证。Dify 的工作流则更偏向开发者提供了更细粒度的控制节点类型更丰富除了 LLM 和基础工具Dify 支持代码执行、变量赋值、循环、条件分支等编程结构能构建更复杂的逻辑。数据流显式定义你需要手动连接节点的输入输出端口对数据在 Agent 间的流动有完全的控制权。更强的集成能力可以更方便地接入自定义 API、数据库便于将 AI 能力嵌入现有业务系统。 从 Coze 迁移到 Dify意味着从“配置”走向“开发”获得更高的自由度和系统集成能力。2. 环境准备与 Dify 部署我们将采用 Dify 的 Docker 部署方式这是最推荐且易于管理的方法。请确保你的开发环境满足以下要求。2.1 基础环境要求组件最低要求推荐配置说明操作系统Linux, macOS, Windows (WSL2)Linux (Ubuntu 20.04)生产环境建议使用 Linux。Windows 请务必使用 WSL2。Docker20.1024.0确保 Docker 守护进程正在运行。Docker Compose2.02.20用于编排多容器服务。CPU2 核4 核以上用于运行应用服务和向量数据库。内存4 GB8 GB 以上内存不足会导致向量检索或模型服务异常。磁盘20 GB50 GB 以上用于存储镜像、向量数据和知识库文档。首先通过以下命令检查 Docker 和 Docker Compose 版本docker --version docker-compose --version2.2 部署 DifyDify 官方提供了集成的docker-compose.yml文件一键启动所有服务包括前端、后端、数据库和向量数据库。下载部署文件 创建一个项目目录并进入然后下载官方编排文件。mkdir dify-game-assistant cd dify-game-assistant curl -o docker-compose.yml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yml启动服务 使用 Docker Compose 在后台启动所有服务。docker-compose up -d这个命令会拉取 PostgreSQL、Redis、Weaviate向量数据库和 Dify 自身的镜像并启动容器。首次启动可能需要几分钟时间下载镜像。验证部署 等待片刻后检查容器状态是否全部为Up。docker-compose ps你应该看到类似下面的输出Name Command State Ports --------------------------------------------------------------------------------------- dify-game-assistant-dify-api-1 /bin/bash /entrypoint.sh Up 5001/tcp dify-game-assistant-dify-web-1 /bin/bash /entrypoint.sh Up 0.0.0.0:80-3000/tcp dify-game-assistant-postgres-1 docker-entrypoint.sh postgres Up 5432/tcp dify-game-assistant-redis-1 docker-entrypoint.sh redis-server Up 6379/tcp dify-game-assistant-weaviate-1 /bin/weaviate --hos ... Up 8080/tcp访问并初始化 打开浏览器访问http://localhost如果 80 端口被占用请检查docker-compose.yml中 Web 服务的端口映射。按照页面提示完成管理员账号的初始化设置。2.3 配置大模型与嵌入模型Dify 本身不提供大模型需要你配置 API Key 或部署本地模型。为了实战的通用性我们以 OpenAI 的 GPT 系列和 OpenAI 的嵌入模型为例。你需要在 Dify 控制台进行配置。登录 Dify使用上一步创建的管理员账号登录。进入模型配置在左侧导航栏找到“设置” - “模型供应商”。添加 OpenAI点击“添加模型供应商”选择“OpenAI”。供应商名称自定义如OpenAI。API Key填入你的 OpenAI API Key。API Base URL如果你使用官方接口留空即可如果使用第三方代理填入对应地址。配置模型在“模型设置”页面需要配置两类模型语言模型用于对话和推理。点击“添加模型”选择供应商OpenAI模型选择gpt-4o-mini或gpt-4-turbo。为其命名如GPT-4o-Mini。嵌入模型用于将文本转换为向量。点击“添加模型”供应商同样选择OpenAI模型选择text-embedding-3-small。为其命名如OpenAI-Embedding。注意如果你没有 OpenAI API也可以配置其他支持的模型如 Anthropic Claude、通义千问、DeepSeek 等或者通过 OpenAI 兼容的 API如 LM Studio、Ollama 提供的本地模型进行连接。配置逻辑类似关键是确保“语言模型”和“嵌入模型”可用。3. 构建基石创建游戏知识库RAG我们的多 Agent 系统需要一个可靠的知识来源。首先我们为“三角洲专属游戏助手”创建一个 RAG 知识库。3.1 准备知识文档收集或创建关于“三角洲行动”游戏的文本资料格式可以是.txt,.md,.pdf,.docx等。例如weapons.md: 包含所有武器的名称、类型、伤害、射速、后坐力等属性。maps.md: 包含各地图的结构、关键点位、战术要点。characters.md: 包含各角色的技能、定位、升级路线。patch_notes_v1.5.md: 版本 1.5 的更新日志。将这些文档放在本地一个文件夹中如./game_docs。3.2 在 Dify 中创建并配置知识库创建知识库在 Dify 左侧导航栏点击“知识库” - “创建知识库”。名称三角洲游戏知识库描述三角洲行动游戏的武器、地图、角色与版本信息。点击“创建”。配置索引方法创建后进入知识库详情页点击“处理设置”。分词方式对于中文游戏文档选择“混合”或“精准”模式通常效果更好。文本分割根据文档结构调整“块大小”和“块重叠”。对于表格密集的武器数据块可以小一些如 300 tokens对于连贯的攻略文本块可以大一些如 500 tokens。重叠部分有助于保持上下文连贯。向量化模型选择之前配置的OpenAI-Embedding模型。保存设置。上传文档并索引在知识库详情页点击“上传文件”。将./game_docs下的文件全部上传。上传后Dify 会自动开始“索引”过程即将文档分块、向量化并存入 Weaviate。你可以在“文件列表”中查看每个文件的状态显示“已索引”即表示完成。3.3 测试知识库检索在投入 Agent 使用前先手动测试知识库是否工作正常。在知识库详情页找到“测试”区域。在输入框提问“破晓’这把突击步枪的射速是多少”点击“测试”。Dify 会展示检索到的相关文本片段Recall以及基于这些片段生成的答案Answer。如果答案准确说明知识库构建成功。如果检索不相关可能需要回到“处理设置”调整分词或块大小。4. 设计并实现多 Agent 协作工作流这是本文的核心。我们将创建一个主工作流内含一个路由节点和三个专家 Agent 节点。4.1 创建工作流并设计蓝图创建工作流在左侧导航栏点击“工作流” - “创建工作流”。命名为三角洲游戏助手多Agent协作。理解节点类型在工作流编辑器中从右侧面板拖拽节点到画布。关键节点类型开始节点工作流入口接收用户问题。LLM 节点调用大模型用于推理、判断、生成文本。知识库检索节点连接我们创建的知识库执行检索。代码节点执行 Python 代码可用于数据处理、调用外部 API。判断节点根据条件如变量值决定流程分支。变量赋值器设置或修改变量的值。结束节点工作流出口返回最终结果。我们的设计蓝图如下用户提问 | v [开始节点] - [路由判断 Agent] (LLM节点分析问题类型) | |-- (类型知识问答) - [知识检索 Agent] - [组装答案] - [结束] |-- (类型战术分析) - [战术分析 Agent] - [组装答案] - [结束] -- (类型装备推荐) - [装备推荐 Agent] - [组装答案] - [结束]每个“专家 Agent”本身也可以是一个包含多个步骤的子工作流或复杂节点。4.2 实现路由判断 Agent这个 Agent 负责对用户问题进行意图分类。拖入一个 LLM 节点命名为路由判断。配置该节点模型选择GPT-4o-Mini。系统提示词编写清晰的指令。你是一个游戏助手路由员。请严格根据用户问题判断其属于以下哪种类型 1. “知识问答”问题涉及游戏事实、背景、武器属性、角色技能、地图信息等。例如“M4A1的伤害是多少”“医疗兵有什么技能” 2. “战术分析”问题涉及对战策略、阵容搭配、局势判断、胜率评估等。例如“沙漠地图进攻方怎么打”“我方有狙击手和两个突击怎么推进” 3. “装备推荐”问题涉及武器、配件、道具的选择和搭配。例如“新手用什么枪好”“打狙击配什么副武器” 只输出一个类型关键词“知识问答”、“战术分析”或“装备推荐”。不要输出任何其他解释。用户输入连接开始节点的query变量。拖入一个判断节点命名为根据类型分流。配置判断条件将路由判断节点的输出变量如text连接到判断节点。设置三个分支条件{{#eq text “知识问答”}}- 连接到知识检索 Agent。{{#eq text “战术分析”}}- 连接到战术分析 Agent。{{#eq text “装备推荐”}}- 连接到装备推荐 Agent。4.3 实现知识检索 Agent这是最直接的 Agent主要调用 RAG 知识库。拖入一个知识库检索节点命名为知识检索。配置该节点知识库选择之前创建的三角洲游戏知识库。查询内容连接开始节点的query变量。检索模式选择“向量检索”并设置返回 Top K 为 3。拖入一个 LLM 节点命名为生成知识答案连接到知识检索节点之后。配置该节点模型GPT-4o-Mini。系统提示词你是一个专业的三角洲游戏助手。请基于提供的游戏资料准确、简洁地回答用户的问题。 如果资料中有明确数据请引用。如果资料中没有相关信息请如实告知“根据现有资料未找到相关信息”。 答案要友好并可以适当给出游戏内的小提示。上下文将知识检索节点的输出变量如result作为上下文填入。用户输入连接开始节点的query变量。此节点的输出将作为该分支的最终答案连接到结束节点。4.4 实现战术分析 Agent这个 Agent 更复杂需要结合规则或简单模型。我们用代码节点模拟一个简单的胜率分析。拖入一个 LLM 节点命名为解析战局。配置该节点模型GPT-4o-Mini。系统提示词请从用户描述中提取以下结构化信息 1. 地图名称。 2. 我方阵容角色和数量。 3. 敌方已知信息角色和数量。 4. 当前目标如“进攻A点”、“防守”。 请以 JSON 格式输出包含 map, ally, enemy, objective 四个字段。用户输入连接开始节点的query变量。拖入一个代码节点命名为胜率分析与建议。配置该节点语言选择 Python# 输入上一步 LLM 输出的 JSON 字符串 import json def main(input_json: str) - dict: try: data json.loads(input_json) map_name data.get(map, 未知) ally data.get(ally, []) enemy data.get(enemy, []) objective data.get(objective, ) # 这是一个非常简化的模拟分析逻辑 # 实际项目中这里可以接入更复杂的规则引擎或预测模型 base_win_rate 50.0 suggestion [] if 狙击手 in ally and 突击兵 in ally: base_win_rate 10 suggestion.append(狙击手与突击兵搭配良好建议狙击手占据高地掩护突击兵分路推进。) if 医疗兵 not in ally: base_win_rate - 5 suggestion.append(阵容缺乏治疗建议保持队伍集结避免单人深入。) if 爆破专家 in ally and 进攻 in objective: base_win_rate 8 suggestion.append(爆破专家对进攻目标有优势可快速破点。) # 确保胜率在合理范围 win_rate max(30.0, min(95.0, base_win_rate)) output { analysis: f基于当前阵容和目标的初步分析, estimated_win_rate: f{win_rate:.1f}%, tactical_suggestions: suggestion if suggestion else [阵容均衡保持沟通灵活应对。] } return output except Exception as e: return {error: f解析失败: {str(e)}}将解析战局节点的输出变量连接到这个代码节点的输入。拖入一个 LLM 节点命名为生成战术报告。配置该节点模型GPT-4o-Mini。系统提示词你是一个资深战术指挥官。请将以下分析结果组织成一段对玩家友好、鼓舞士气且具有操作性的战术报告。 报告结构1. 局势简述。2. 优势与劣势分析。3. 具体战术建议分点列出。4. 鼓励性结语。上下文将胜率分析与建议节点的输出作为上下文。用户输入连接开始节点的query变量。此节点的输出连接到结束节点。4.5 实现装备推荐 Agent这个 Agent 需要查询“武器属性表”我们可以结合知识库检索和代码逻辑。拖入一个 LLM 节点命名为解析装备需求。配置该节点模型GPT-4o-Mini。系统提示词请从用户问题中提取装备推荐的关键要素 1. 适用场景如“近战”、“远距离”、“新手”、“高机动”。 2. 武器类型偏好如“步枪”、“狙击枪”、“不限”。 3. 特殊要求如“低后坐力”、“高伤害”。 请以 JSON 格式输出包含 scenario, weapon_type, requirements 字段。拖入一个知识库检索节点命名为检索武器库。知识库三角洲游戏知识库。查询内容这里我们可以用动态查询。例如连接一个变量或者直接使用{{解析装备需求.output}}中的weapon_type字段来构造查询如{{weapon_type}} 武器属性。更复杂的做法是在代码节点中构造查询语句。拖入一个代码节点命名为过滤与排序装备。编写 Python 代码模拟从检索结果中解析武器数据并根据scenario和requirements进行过滤和排序。例如给“新手”推荐稳定性高的武器给“近战”推荐射速快的武器。拖入一个 LLM 节点命名为生成推荐理由。将过滤后的装备列表和用户原始问题作为输入让 LLM 生成自然语言的推荐理由和搭配建议。4.6 连接工作流并设置输出将三个专家 Agent 分支的最终输出节点生成知识答案、生成战术报告、生成推荐理由都连接到同一个结束节点。在结束节点的配置中需要设置工作流的最终输出变量。由于三个分支都会输出一个text变量LLM节点的默认输出我们可以直接配置结束节点输出{{text}}。Dify 的工作流引擎会自动传递当前激活分支的输出。5. 测试、调试与部署应用5.1 在工作流编辑器中测试点击工作流编辑器右上角的“预览”或“运行”按钮。在测试面板的输入框输入不同类别的问题进行测试知识类“医疗兵的生命恢复技能冷却时间是多长”战术类“我们在‘沙漠废墟’地图防守有两个突击兵和一个狙击手该怎么布防”装备类“我喜欢冲锋有什么适合近战的高射速武器推荐”观察工作流的运行过程。Dify 会高亮显示正在执行的节点并展示每个节点的输入和输出数据。这是调试多 Agent 协作逻辑的利器。5.2 发布为可访问的 AI 应用工作流测试无误后可以将其发布为一个独立的 AI 应用供最终用户通过 Web 界面或 API 调用。保存并发布工作流在工作流编辑器点击“发布”。创建应用在左侧导航栏点击“应用”选择“通过工作流创建”。选择工作流选择我们刚刚发布的三角洲游戏助手多Agent协作工作流。配置应用设置应用名称、图标和描述。在“提示词编排”页面你可以配置开场白、用户输入建议等但核心逻辑已由工作流定义。在“外部访问”页面可以获取到该应用的 API 地址和密钥。访问与分享应用创建后你会获得一个独立的 Web 聊天界面 URL可以分享给其他玩家测试。5.3 通过 API 集成对于想将助手集成到自己游戏社区或工具中的开发者可以使用 API。在应用设置中找到“API 访问”信息。使用以下格式的 cURL 命令进行测试curl --location https://your-dify-domain/v1/chat-messages \ --header Authorization: Bearer your-app-api-key \ --header Content-Type: application/json \ --data { inputs: {}, query: 破晓这把枪适合新手吗, response_mode: streaming, conversation_id: , user: test_user_001 }Dify 会以流式或非流式根据response_mode返回多 Agent 协作处理后的结果。6. 常见问题排查与优化在构建和运行此类多 Agent RAG 系统时你可能会遇到以下典型问题。6.1 知识库检索不准确问题现象可能原因检查与解决方式答案与问题无关1. 文档分割块过大或过小。2. 嵌入模型不适合领域文本。3. 查询词与文档术语不匹配。1. 调整知识库的“文本分割”设置尝试不同的块大小和重叠。2. 尝试不同的嵌入模型如text-embedding-3-large或专门的多语言模型。3. 在查询前让一个 LLM 节点对用户问题进行“查询重写”使其更贴近文档表述。检索不到任何内容1. 知识库未成功索引。2. 向量数据库连接异常。3. 查询语言与文档语言不一致。1. 在 Dify 知识库文件列表检查文件状态是否为“已索引”。2. 检查 Docker 容器weaviate是否运行正常日志有无报错。3. 确保查询语言与文档主要语言一致。答案包含幻觉RAG 检索到了部分相关文档但 LLM 在生成时超出了上下文范围。1. 在调用 LLM 的节点中强化系统提示词“严格依据提供的上下文回答问题如果上下文没有就说不知道。”2. 增加检索的 Top K 值提供更全面的上下文。3. 使用“引用”功能让 LLM 标明答案出自哪段文档。6.2 多 Agent 工作流逻辑错误问题现象可能原因检查与解决方式路由判断错误问题被分发给错误的 Agent。1. 路由 Agent 的提示词定义不清。2. 用户问题意图模糊。1. 细化路由提示词中的类型定义和例子让 LLM 更容易区分。2. 在路由前增加一个“意图澄清”节点当 LLM 判断置信度低时反问用户。某个 Agent 节点无输出流程中断。1. 节点输入变量连接错误。2. 代码节点存在运行时异常。3. LLM 节点因内容策略未返回结果。1. 在工作流测试中逐步运行检查每个节点的输入数据是否符合预期。2. 查看代码节点的错误日志增加异常捕获和日志输出。3. 检查 LLM 节点的输出是否为空或被过滤调整提示词。最终答案格式混乱。不同 Agent 分支的输出格式不一致。在最终汇聚到“结束节点”前增加一个“答案格式化”节点LLM或代码统一所有分支输出的格式。6.3 性能与成本优化减少不必要的 LLM 调用路由判断可以使用更小、更快的模型如gpt-3.5-turbo。在知识检索 Agent 中如果检索到的文档片段已经能直接回答问题如纯数据表格可以考虑不经过 LLM直接返回片段。使用本地模型对于嵌入和部分推理任务可以考虑部署开源模型如通过 Ollama 部署nomic-embed-text和qwen2.5:7b以降低 API 成本和提升数据隐私性。在 Dify 模型供应商中配置本地模型的 API 端点即可。实现 Agent 结果缓存对于常见、答案固定的知识类问题可以在工作流开始时加入缓存查询如查询 Redis。如果命中缓存则直接返回跳过后续所有 Agent 流程。异步与并行化如果多个专家 Agent 的任务相互独立可以考虑让它们并行执行最后再汇总结果。Dify 工作流目前更偏向串行但可以通过设计多个开始分支来模拟并行然后用“聚合”节点收集结果。7. 生产环境最佳实践将这样一个多 Agent 系统用于真实玩家社区需要考虑更多工程因素。配置管理外置不要将 API Key、模型名称、知识库 ID 等硬编码在工作流中。使用 Dify 的“变量”功能或环境变量来管理这些配置便于不同环境开发、测试、生产的切换。完善的日志与监控为工作流中的关键节点尤其是代码节点和 LLM 调用添加日志记录记录输入、输出和耗时。监控 API 的调用量、响应时间和错误率。Dify 企业版提供了更完善的可观测性功能。设置速率限制与熔断在应用配置或通过网关如 Nginx为你的 AI 助手 API 设置速率限制防止恶意调用或流量过载。对于依赖的外部模型 API要有熔断机制避免一个服务宕机导致整个助手不可用。数据安全与隐私如果知识库包含未公开的游戏数据确保 Dify 部署在内网或配置了严格的访问控制。审查用户与助手的对话日志避免敏感信息泄露。持续迭代与评估建立反馈机制收集用户对助手回答的满意度如“点赞/点踩”。定期用一批标准问题测试助手评估其准确率和响应时间根据结果迭代优化提示词、工作流逻辑或知识库文档。从 Coze 这样的可视化平台起步理解 AI 工作流和 Agent 的基本概念再深入到 Dify 这样的开发框架进行更自由、更深入的多 Agent 系统构建是一条可行的 AI 应用开发路径。本次实战搭建的“三角洲游戏助手”只是一个起点你可以在此基础上引入更复杂的工具调用如实时查询游戏数据库、更高级的规划逻辑如让 Agent 进行多轮思考甚至让 Agent 之间进行辩论和协商从而创造出真正智能、专属于你的新一代 AI 应用团队。
