基于Dify与RAG构建多智能体协作AI应用实战

在构建企业级AI应用时单点智能体往往难以应对复杂、多步骤的业务流程。你是否遇到过这样的困境一个智能体既要理解用户意图又要查询知识库还要调用外部API最后生成格式化的报告导致其逻辑臃肿、响应缓慢且难以维护这正是多智能体协作架构要解决的核心问题。本文将带你深入实战基于Dify平台结合RAG技术构建一个由多个Agent分工协作的“三角洲专属游戏助手”。我们将从Coze工作流的设计思路迁移到Dify完整拆解从环境搭建、知识库构建、智能体编排到团队协作的全流程为你呈现新一代AI应用开发的工程化实践。1. 背景与核心概念为什么需要多Agent协作在传统的AI应用开发中无论是使用Coze、Dify还是直接调用大模型API我们常常设计一个“全能型”智能体。这个智能体需要处理从对话理解、知识检索、逻辑推理到工具调用的所有任务。随着业务逻辑复杂化这种单体架构会暴露出诸多问题提示词Prompt变得极其冗长且难以优化不同能力模块相互干扰导致输出不稳定任何功能迭代都可能引发全局性风险。多Agent协作架构正是为了解决这些问题而生。其核心思想是“专业的人做专业的事”将复杂的任务拆解为多个子任务由不同的、功能专一的智能体Agent分别处理并通过一个协调者Orchestrator或工作流来管理它们之间的交互与数据流转。Dify一个开源的LLM应用开发平台它提供了可视化的编排界面支持构建基于工作流的复杂应用尤其擅长将多个AI节点如LLM调用、知识库检索、代码执行连接起来是实现多Agent系统的理想底座。RAG检索增强生成。它通过从外部知识库如向量数据库中检索相关信息并将其作为上下文提供给大模型从而让模型生成更准确、更专业的回答有效缓解“幻觉”问题。在多Agent系统中可以有一个或多个专司RAG检索的Agent。Agent在此上下文中指的是一个具有特定角色、能力和目标的AI驱动模块。它可以是一个简单的提示词模板也可以是一个集成了工具调用和记忆能力的复杂程序。从Coze到DifyCoze平台以其强大的工作流和插件生态著称其“工作流”思维与Dify的“工作流”设计理念高度相通。本实战将借鉴Coze中智能体分工协作的思想在更注重开发流程与工程集成的Dify平台上进行实现构建一个可私有化部署、深度定制的企业级解决方案。我们的目标项目——“三角洲专属游戏助手”就是一个典型的多Agent应用场景。它需要处理游戏攻略查询、装备搭配推荐、战局实时分析、社区梗百科等多样化需求单一智能体难以胜任。接下来我们将通过这个案例一步步搭建起我们的AI应用团队。2. 环境准备与版本说明在开始编码之前我们需要准备好开发与运行环境。Dify支持多种部署方式为了获得最大的灵活性和控制权我们选择使用Docker-Compose进行本地部署。基础环境要求操作系统Ubuntu 20.04/22.04 LTS, CentOS 7, macOS, 或 Windows (通过WSL2)。本文以Ubuntu 22.04为例。Docker版本20.10及以上。Docker Compose版本v2.0及以上。硬件建议至少4核CPU8GB内存20GB可用磁盘空间。运行大模型和向量数据库需要更多资源。关键组件版本Dify我们将使用其官方Docker镜像。截至本文撰写时稳定版本为0.6.x系列。建议始终使用官方仓库的最新稳定版。向量数据库Dify默认集成并推荐使用Weaviate。我们将使用其内置的Weaviate服务。你也可以选择连接外部的Chroma、Qdrant或PGVector。大模型Dify支持多种模型。为方便演示我们将使用OpenAI兼容的API如OpenAI官方API、Ollama本地模型、或国内通义千问、DeepSeek等提供的兼容API。生产环境请根据实际情况选择。部署步骤克隆仓库与配置# 克隆 dify 仓库 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量配置文件 cp .env.example .env编辑环境变量使用vim或nano编辑.env文件最关键的是配置大模型API。# 使用 vim 编辑 .env 文件 vim .env找到并修改以下关键配置以使用OpenAI API为例# 设置你的 OpenAI API 密钥 OPENAI_API_KEYsk-your-openai-api-key-here # 指定使用的模型如 gpt-4o-mini OPENAI_API_MODELgpt-4o-mini # 确保使用正确的 API 基址如果你用的是第三方兼容服务需要修改此处 OPENAI_API_BASEhttps://api.openai.com/v1 # 修改外部访问地址如果是本地可以是 http://localhost CONSOLE_API_URLhttp://localhost CONSOLE_WEB_URLhttp://localhost注意如果你使用Ollama在本地运行模型如Llama 3.1则需要将OPENAI_API_BASE改为http://host.docker.internal:11434/v1并将OPENAI_API_KEY设为任意非空字符串如ollama同时OPENAI_API_MODEL改为你的本地模型名如llama3.1。启动Dify服务# 在 docker 目录下使用 docker-compose 启动所有服务 docker-compose up -d这个命令会拉取镜像并启动包括Dify API服务、前端界面、Weaviate向量数据库、PostgreSQL关系数据库、Redis缓存等在内的所有容器。验证部署等待几分钟让服务完全启动。你可以通过docker-compose logs -f查看日志。在浏览器中访问http://localhost如果你修改了端口请访问对应地址。首次访问会进入初始化页面按照提示创建管理员账户。登录后进入Dify控制台即表示环境部署成功。至此你的Dify平台已经就绪接下来我们将在此平台上构建我们的多Agent游戏助手。3. 核心架构与Dify工作流设计在编写具体代码和配置之前我们必须先进行架构设计。清晰的架构是成功实现多Agent协作的关键。“三角洲专属游戏助手”业务场景分解用户意图识别判断用户是想查攻略、配装备、看战报还是玩梗。知识检索针对攻略、装备数据从知识库中精准查找信息。专业分析对战报数据进行统计、对比生成洞察。内容生成与润色将检索和分析结果组织成用户友好的语言并融入社区文化。工具调用可能需要调用游戏API查询实时数据如当前在线地图。对应的多Agent团队设计调度员Agent负责接收用户原始问题进行意图识别和任务拆解。它是工作流的入口。检索专家Agent专司RAG。接收调度员分发的查询请求从对应的知识库攻略库、装备库中检索相关片段。数据分析师Agent负责处理需要计算、对比、总结的任务如战报分析。文案编辑Agent负责汇总各Agent的产出生成最终回复并确保语言风格符合游戏社区特色如加入特定梗或表情包建议。在Dify中我们将使用“工作流”功能来可视化地编排这个团队。工作流中的每个节点可以视为一个Agent或一个处理步骤。Dify工作流设计图逻辑视图[用户输入] | v [调度员Agent] (LLM节点 提示词) | |--(意图: 查询)-- [检索专家Agent] -- [知识库节点] -- [结果] |--(意图: 分析)-- [数据分析师Agent] -- [代码执行节点?] -- [结果] |--(意图: 闲聊)-- [直接至文案编辑Agent] | v [结果聚合节点] (变量组装) | v [文案编辑Agent] (LLM节点 提示词) | v [最终输出]这个设计将复杂的逻辑分解到不同的节点中每个节点职责单一便于独立调试和优化。接下来我们开始实施。4. 完整实战构建多Agent游戏助手4.1 第一步创建与配置知识库RAG基石多Agent协作中检索专家Agent的能力依赖于高质量的知识库。我们为游戏助手创建两个知识库“游戏攻略库”和“武器装备库”。进入知识库管理在Dify控制台侧边栏点击“知识库” - “创建知识库”。创建攻略库名称三角洲行动-攻略库分词方式选择适合中文的jieba或LLM分词。点击“创建”。上传知识文件进入刚创建的知识库点击“上传文件”。你可以上传游戏官方Wiki的PDF、整理好的Markdown文档或TXT文件。例如上传一个basic_tactics.md文件。# 地图货运码头 进攻方攻略 - **第一阶段破门**推荐使用烟雾弹封锁右侧狙击点小队应从左侧集装箱快速接近。 - **关键武器**此阶段近距离交战多SMG和霰弹枪优势明显。 - **职业搭配**至少需要一名突击兵破门一名支援兵提供弹药。Dify会自动将文档进行分块、向量化并存入Weaviate。创建装备库重复上述过程创建三角洲行动-装备库并上传武器数据文件。配置检索参数在知识库设置中可以调整“分段处理”规则如分段长度、重叠度和“检索设置”如Top K数量、相似度阈值。初期可使用默认值。4.2 第二步构建调度员Agent工作流入口调度员Agent是一个LLM节点其核心是一个精心设计的提示词Prompt用于意图识别。创建工作流在Dify控制台点击“工作流” - “创建空白工作流”命名为三角洲游戏助手核心工作流。添加开始节点从左侧节点库拖拽“开始”节点到画布。添加调度员LLM节点拖拽“LLM”节点到画布连接到“开始”节点之后。节点名称调度员_意图识别。选择模型选择你配置好的模型如gpt-4o-mini。编写系统提示词这是Agent的“角色定义”和“能力说明书”。你是一个《三角洲行动》游戏助手团队的调度员。你的任务是根据用户的问题分析其意图并将任务分派给不同的专家。 请严格从以下可选意图中选择一项并直接输出意图标签不要输出任何其他解释 - query_guide: 当用户询问地图攻略、通关方法、战术技巧时。 - query_equipment: 当用户询问武器性能、装备搭配、配件推荐时。 - analyze_report: 当用户提交了一段战报文字要求进行分析、总结或对比时。 - casual_chat: 当用户进行闲聊、玩梗、询问游戏背景故事时。 用户问题{{input}}配置变量在提示词的{{input}}处点击并选择关联到“开始”节点的query变量。这样用户输入就会传入提示词。输出解析由于我们要求LLM只输出意图标签我们可以添加一个“代码”节点来解析但更简单的方式是在LLM节点的“回复模式”中期望其返回纯净文本。我们将在后续分支中利用这个输出。4.3 第三步构建检索专家AgentRAG查询这个Agent专门负责从知识库中查找信息。我们使用Dify的“知识库检索”节点来实现。添加分支节点由于调度员识别出不同意图后需要走不同的处理分支我们使用“条件判断”节点。拖拽“条件判断”节点连接到调度员LLM节点之后。配置分支逻辑在条件判断节点我们需要根据调度员的输出即意图标签来路由。点击“添加条件”变量选择调度员节点的输出变量如调度员_意图识别.answer。设置条件规则规则1等于query_guide- 连接到“攻略检索”节点。规则2等于query_equipment- 连接到“装备检索”节点。规则3等于analyze_report- 连接到“数据分析”节点。规则4等于casual_chat- 连接到“直接生成”节点。注意Dify的条件判断节点可能要求变量是字符串LLM的输出需确保是纯净的标签。构建攻略检索分支拖拽“知识库检索”节点连接到query_guide条件分支。节点名称检索专家_攻略查询。选择知识库选择之前创建的三角洲行动-攻略库。查询文本这里不能直接用用户原始输入因为可能包含非关键信息。更好的做法是让调度员在输出意图的同时也输出一个“精炼查询词”。我们可以修改调度员的提示词让其输出意图|精炼查询的格式然后用“代码”节点拆分。为简化本例直接使用{{input}}关联用户原始问题。配置检索参数设置“最大召回数量”为3 “相似度阈值”为0.7可根据效果调整。构建装备检索分支同理添加另一个“知识库检索”节点连接到query_equipment分支并选择三角洲行动-装备库。4.4 第四步构建数据分析师Agent与文案编辑Agent数据分析师Agent可能需要更复杂的逻辑例如从战报文本中提取结构化数据。我们可以结合“LLM”节点和“代码执行”节点Python来实现。构建数据分析分支拖拽一个“LLM”节点到analyze_report分支命名为数据分析师_提取。提示词示例你是一名专业的游戏数据分析师。请从以下战报中提取关键信息并以JSON格式输出。 需要提取的字段地图名, 阵营, 击杀数, 死亡数, 得分, 使用的主要武器, 亮点操作简短描述。 战报内容{{input}} 只输出JSON对象不要有任何额外说明。这个LLM节点的输出将是一个JSON字符串。可选代码执行节点如果你需要对提取的数据进行复杂计算如K/D比、得分效率可以再接一个“代码执行”节点编写Python脚本处理上一步的JSON输出。构建文案编辑Agent聚合与生成现在我们有多个分支可能产生结果攻略检索结果、装备检索结果、数据分析结果、以及闲聊的直接路径。我们需要将它们汇聚起来交给最终的文案编辑Agent生成回复。使用“变量分配器”节点来聚合变量。但Dify工作流更常见的模式是每个分支处理完后都连接到一个共同的“聚合LLM”节点。拖拽一个“LLM”节点作为最终输出节点命名为文案编辑_最终回复。将攻略检索节点、装备检索节点、数据分析节点的输出都连接到这个最终LLM节点。Dify工作流允许一个节点有多个输入它会等待所有上游节点执行完毕。编写聚合提示词你是一名《三角洲行动》社区资深玩家兼助手语言风格要轻松、专业且带有一定的游戏梗文化。 请根据以下上下文信息生成对用户问题的最终回复。 【用户原问题】 {{input}} 【检索到的攻略信息】如果相关 {{检索专家_攻略查询.content}} 【检索到的装备信息】如果相关 {{检索专家_装备查询.content}} 【数据分析结果】如果相关 {{数据分析师_提取.answer}} 【注意】 1. 如果提供了相关信息请优先基于这些信息进行回答确保准确性。 2. 如果信息不足或用户问题是闲聊请发挥你的知识给出有趣、有帮助的回复。 3. 回复最后可以加一句“特战干员还有什么需要支援的吗”来体现人设。 4. 使用中文回复。在这个提示词中我们通过{{node_name.output_var}}的格式引用了上游各个节点的输出。Dify会自动将这些变量替换为实际内容。4.5 第五步连接与测试工作流连接所有节点确保你的工作流画布看起来像一个有向无环图从“开始”到“调度员”经“条件判断”分叉最后各分支汇聚到“文案编辑_最终回复”。配置未处理分支对于casual_chat分支可以直接用一条线连接到最终文案编辑节点因为不需要中间处理。保存并发布工作流点击右上角“保存”然后点击“发布”。发布后工作流会生成一个唯一的API端点。在聊天应用中进行测试在Dify控制台进入“应用”页面创建一个新的“对话型”应用。在应用配置的“提示词编排”阶段不要编写复杂提示词而是直接选择“工作流”。选择我们刚刚创建并发布的三角洲游戏助手核心工作流。保存应用进入预览界面。测试用例1输入“货运码头怎么打” 预期触发query_guide检索攻略库并生成回答。测试用例2输入“P90这把枪怎么样” 预期触发query_equipment检索装备库并生成回答。测试用例3输入“我刚打了一局拿了15杀5死地图是雪地。” 预期触发analyze_report进行数据提取并生成鼓励性分析。测试用例4输入“今天天气真好”。 预期触发casual_chat直接由文案编辑Agent进行友好闲聊。通过测试你可以观察工作流的运行轨迹查看每个节点的输入输出从而调试提示词、检索参数和分支逻辑。5. 常见问题与排查思路在构建和运行多Agent工作流时你可能会遇到以下典型问题问题现象可能原因排查与解决思路工作流发布失败节点配置错误存在循环依赖或必填参数为空。1. 检查画布确保没有形成闭环。2. 逐一检查每个节点特别是LLM和知识库节点的配置确保所有带红色星号的必填项都已填写。3. 查看Dify后台日志 (docker-compose logs -f api) 获取具体错误信息。知识库检索结果不相关1. 文档分块策略不合理。2. 查询词与文档语义不匹配。3. 相似度阈值设置不当。1. 调整知识库的“分段处理”设置尝试不同的分段长度和重叠度。2. 优化查询词在检索节点前添加一个“LLM”节点将用户问题重写为更利于检索的简短关键词。3. 调整“检索设置”中的“相似度阈值”和“最大召回数量”。调度员意图识别错误提示词定义不清晰或LLM未遵循指令。1. 在系统提示词中强调“严格从以下可选意图中选择”和“直接输出意图标签”。2. 使用更强大的模型如GPT-4进行意图识别。3. 在提示词中提供更丰富的例子Few-shot Learning。4. 在后置的“代码”节点中添加校验逻辑对非法意图进行兜底处理。多分支汇聚时变量为空某些分支未执行导致最终LLM节点引用的变量不存在。1. 确保最终聚合节点如文案编辑的提示词中对所有上游变量引用使用安全的模板语法。Dify通常能处理不存在的变量将其视为空字符串。2. 可以使用“变量分配器”节点为可能为空的变量设置默认值。工作流响应速度慢1. 串行节点过多。2. LLM API调用延迟高。3. 知识库检索耗时。1. 审视工作流对于没有依赖关系的节点考虑能否并行执行Dify工作流引擎会自动优化需确认版本支持。2. 为不要求极高实时性的分支考虑使用速度更快、成本更低的模型。3. 优化知识库索引或考虑使用更高效的向量数据库。最终回复风格不符合预期文案编辑Agent的提示词角色设定不明确。1. 在系统提示词中更详细地定义角色、语气和风格。2. 在提示词中提供1-2个期望回复风格的示例。3. 在提示词中明确禁止某些类型的回复如“作为AI模型…”。6. 最佳实践与工程建议将多Agent系统投入生产环境需要遵循以下工程实践以确保其稳定性、可维护性和安全性提示词工程化版本管理将每个Agent的提示词保存在独立的文本文件或配置管理中如Git进行版本控制。Dify提供了版本历史功能务必善用。模块化与复用将通用的提示词片段如角色定义、输出格式要求抽象为模板在不同Agent间复用。A/B测试对于关键Agent如调度员可以创建不同版本的提示词通过Dify的“测试”功能或外部监控来评估其效果。知识库管理数据质量确保上传到知识库的文档是准确、结构清晰、无噪音的。劣质数据会导致RAG效果大打折扣。增量更新建立知识库文档的更新流程。Dify支持文档的增量上传和索引更新避免每次全量重建。多索引策略对于不同类型、不同来源的知识可以创建多个知识库让检索专家Agent根据上下文选择查询哪个库提高精度。工作流设计与监控日志与追踪确保Dify的日志收集功能开启。对于生产环境考虑将日志接入ELK或类似系统以便追踪每个用户请求流经了哪些节点耗时多少方便性能分析和故障排查。错误处理与兜底在工作流的关键节点后添加“条件判断”节点检查上游输出是否有效。如果无效可以跳转到一个“兜底回复”节点告知用户“服务暂时不可用”或转向人工客服而不是抛出技术性错误。性能优化对于实时性要求高的场景可以将知识库检索结果进行缓存Dify本身或外部Redis对相同或相似的查询直接返回缓存结果。安全与权限输入输出过滤在“开始”节点后或最终输出前可以添加“代码”节点对用户输入和模型输出进行安全检查过滤敏感词、防止Prompt注入攻击。权限控制Dify支持多租户和团队协作。合理分配角色和权限确保只有授权人员可以修改生产环境的工作流和知识库。API访问限制为应用生成的API密钥设置调用频率限制和总量限制防止滥用。迭代与评估建立评估集准备一批覆盖各种意图和边界的测试用例定期运行以评估整个工作流的准确性和用户体验。数据驱动优化收集用户与助手的真实对话数据脱敏后分析其中识别错误、检索失败、回复不满意的案例有针对性地优化对应Agent的提示词或知识库内容。从Coze到Dify不仅仅是平台的迁移更是开发范式向工程化、可运维的进阶。通过本次实战我们不仅搭建了一个功能性的游戏助手更掌握了一套构建复杂、可靠、可扩展的多智能体AI应用的方法论。这套以工作流为核心融合RAG与多Agent协作的架构能够广泛应用于智能客服、内容创作、数据分析、代码生成等众多领域。