这次我们来看一个能让你在本地搭建 AI 知识库和智能体的开源平台Dify。它不是某个单一的模型而是一个开箱即用的 AI 应用开发框架。简单来说你可以用它快速构建一个具备专属知识库的问答机器人或者通过拖拽组件的方式组装一个能执行复杂任务的 AI 智能体整个过程几乎不需要写代码。对于开发者、产品经理或任何想快速验证 AI 应用想法的人来说Dify 的核心价值在于大幅降低了 AI 应用开发的门槛。它把 RAG检索增强生成、工作流编排、模型调度这些复杂概念封装成了可视化的操作界面。你只需要关心业务逻辑和数据而不必深陷于向量数据库选型、API 调用封装等底层细节。本文将带你完成一次从零开始的实战在本地部署 Dify并利用它搭建一个关于“三角洲游戏”的 RAG 知识库最终创建一个能回答游戏攻略、角色技能等问题的 AI 游戏助手。我们会重点关注部署过程是否顺畅、资源占用是否友好、以及最终构建的智能体是否真的能用。如果你关心如何将私有数据与 AI 能力结合或者想体验无代码开发 AI 智能体这篇文章会提供一条清晰的路径。1. 核心能力速览在深入部署细节前我们先通过一个表格快速了解 Dify 能做什么以及这次实战涉及的核心组件。能力项说明与本次实战重点项目类型开源 AI 应用开发平台后端 前端核心功能1.RAG 知识库上传文档TXT, PDF, Word, PPT, Excel自动切片、向量化构建可检索的私有知识库。2.AI 智能体Agent通过可视化拖拽工作流编排 LLM、工具搜索、代码执行等、条件判断构建复杂 AI 应用。3.模型支持支持 OpenAI API、Azure、以及众多开源模型通过 Ollama、OpenAI-Compatible API 接入。4.应用发布构建的聊天助手或工作流可发布为 Web App 或 API 端点。部署方式支持 Docker Compose 一键部署推荐也支持源码部署。硬件门槛轻量。核心服务可在 CPU 环境下运行。如果使用本地嵌入模型进行向量化或运行本地大模型则需要 GPU 资源。本次演示以 CPU 为主。显存/内存占用基础服务Web、API、数据库内存占用约 2-4 GB。若启用本地嵌入模型如bge-small-zh或本地 LLM则根据模型大小额外占用内存/显存。是否支持 API是。所有功能知识库管理、对话、工作流运行均提供完整的 RESTful API。是否支持批量任务是。知识库支持批量文档上传与处理。工作流可通过 API 触发批量执行。适合场景1. 企业内部知识库问答机器人。2. 基于私有数据的客服、导购、教学助手。3. 自动化流程智能体如数据分析、报告生成。4. AI 应用原型快速验证。2. 适用场景与使用边界Dify 是一个强大的平台但明确其适用边界能帮助你更好地决策。它非常适合快速原型验证当你有一个AI应用的想法比如一个游戏攻略助手用Dify可以在几小时内搭建出可交互的Demo无需从零搭建后端和前端。私有数据问答企业拥有大量的内部文档、产品手册、规章制度。通过Dify的RAG知识库可以快速构建一个安全、准确的内部问答系统。流程自动化智能体需要结合大模型推理、网络搜索、代码执行等多步骤的任务。例如一个智能体可以获取用户需求 - 搜索最新信息 - 分析数据 - 生成报告 - 通过邮件发送。非开发者构建AI工具产品、运营、业务人员可以通过拖拽界面组合已有的AI能力创建满足特定业务需求的小工具。它可能不适合超大规模、高并发生产环境社区版更适合中小规模使用。对于千万级文档、每秒数千请求的场景需要对数据库、向量引擎、缓存等进行深度定制和优化。需要完全定制算法如果你需要修改RAG的召回策略、重排序算法或者嵌入模型的微调Dify提供了插件点但深度定制仍需开发能力。极度追求部署轻量化Dify是一套完整的服务栈数据库、Redis、向量数据库、后端、前端。如果只想嵌入一个简单的问答功能到现有App直接调用向量数据库和LLM的API可能更轻量。安全与合规边界数据隐私本地部署是Dify的最大优势之一你的所有知识库文档和对话数据都留在自己的服务器上。模型责任Dify本身是平台生成内容的责任在于你所接入的大语言模型LLM。请确保你使用的模型符合相关法律法规并对生成内容进行审核。版权与授权构建知识库时请确保你拥有所上传文档的合法使用权。AI生成的答案应视为参考不应用于替代专业法律、医疗等建议。3. 环境准备与前置条件为了让本地部署过程顺畅请先检查你的环境是否满足以下要求。1. 操作系统推荐Linux (Ubuntu 20.04/22.04, CentOS 7) macOS Windows 10/11 (WSL2 环境)。说明Dify 官方推荐使用 Docker 部署而 Docker 在以上系统均有良好支持。本文演示将在Windows 11 WSL2 (Ubuntu 22.04)环境下进行命令同样适用于纯 Linux 环境。2. 软件依赖Docker 与 Docker Compose这是最关键的依赖。确保已安装最新稳定版。检查命令docker --version和docker compose version注意是docker compose作为一个插件。Git用于拉取部署配置文件。CPU 与内存建议至少 4 核 CPU8 GB 以上内存。运行基础服务组会占用约 2-4 GB 内存。磁盘空间至少预留 10 GB 空间用于存放 Docker 镜像、数据库和知识库文档。3. 网络与端口网络部署过程中需要从 Docker Hub 和 GitHub 拉取镜像和代码请确保网络通畅。端口Dify 默认会占用几个端口请确保它们未被占用80Nginx 反向代理端口Web 访问。8080Dify 后端 API 服务端口。3000Dify 前端服务端口开发模式。6379Redis 端口。5432PostgreSQL 端口。9001Weaviate 向量数据库端口如果选用。4. 模型准备可选但重要Dify 本身不包含模型它需要接入模型才能工作。你有两个主要选择云端 API如 OpenAI GPT-4/3.5 Azure OpenAI Anthropic Claude 等。需要准备相应的 API Key。本地模型通过Ollama或LocalAI等工具在本地运行开源模型如 Qwen, Llama, ChatGLM等。这需要额外的 GPU/CPU 资源。本次实战为了完全本地化我们将使用Ollama来运行一个较小的开源模型并搭配一个本地嵌入模型。4. 安装部署与启动方式我们将采用官方推荐的Docker Compose方式部署这是最快捷、依赖问题最少的方法。步骤 1获取部署文件打开终端WSL2 或 Linux 终端选择一个工作目录克隆部署仓库。# 创建并进入一个工作目录 mkdir dify-local cd dify-local # 克隆 Dify 的 Docker 部署仓库 git clone https://github.com/langgenius/dify.git # 进入 docker 部署目录 cd dify/docker步骤 2配置环境变量Dify 通过.env文件配置。目录下通常有一个.env.example模板文件我们复制一份并进行修改。# 复制环境变量模板 cp .env.example .env现在用文本编辑器如vim或nano打开.env文件。我们需要关注几个关键配置# 编辑 .env 文件 nano .env找到并修改以下配置根据你的实际情况# 1. 数据库密码建议修改为强密码 POSTGRES_PASSWORDdifyai123456 REDIS_PASSWORDdifyai123456 # 2. 外部访问地址如果你是本地测试可以设置为 localhost 或你的服务器IP APP_WEB_URLhttp://localhost # 3. 模型供应商配置 - 这里我们配置为使用 Ollama # 将默认的 OpenAI 配置注释掉或修改为以下内容 # LLM 提供商我们使用 Ollama它兼容 OpenAI API MODEL_PROVIDERopenai OPENAI_API_KEYollama # Ollama 不需要真实的 key但需要填一个非空值 OPENAI_API_BASEhttp://host.docker.internal:11434/v1 # 关键指向主机上的 Ollama 服务 # 4. 嵌入模型配置 - 使用一个本地运行的轻量级模型 # 取消注释并修改 TEXT_ENCODER_PROVIDER TEXT_ENCODER_PROVIDERopenai TEXT_ENCODING_MODELBAAI/bge-small-zh-v1.5 # 一个优秀的中文嵌入模型 OPENAI_API_KEY_FOR_EMBEDDING_MODELollama OPENAI_API_BASE_FOR_EMBEDDING_MODELhttp://host.docker.internal:11434/v1重要说明host.docker.internal是 Docker 容器访问宿主机服务的特殊域名。这要求 Ollama 必须运行在宿主机上即你的电脑或服务器。如果你在纯 Linux 服务器部署且 Docker 容器使用host网络模式可以将地址改为http://127.0.0.1:11434/v1。保存并退出编辑器。步骤 3启动 Ollama 服务在宿主机在启动 Dify 之前我们需要先在宿主机上运行 Ollama 并拉取模型。打开一个新的终端窗口宿主机终端。# 1. 安装并启动 Ollama (请参考 Ollama 官网 https://ollama.com/) # 对于 Linux/WSL2: curl -fsSL https://ollama.com/install.sh | sh ollama serve # 后台运行服务 # 2. 拉取一个轻量级 LLM 模型例如 Qwen2.5-7B-Instruct或更小的 ollama pull qwen2.5:7b-instruct # 3. 拉取我们配置的嵌入模型需要先拉取对应的模型Ollama 才能提供嵌入服务 # 注意Ollama 本身主要运行生成式模型对于嵌入模型我们需要一个特殊的“兼容层”。 # 一个方法是使用 nomic-embed-text 模型它通过 Ollama 提供了 OpenAI 兼容的嵌入接口。 ollama pull nomic-embed-textnomic-embed-text是一个通过 Ollama 提供 OpenAI 兼容嵌入 API 的模型虽然它不是bge-small-zh但可以作为一个可用的替代品。如果你坚持要用bge-small-zh可能需要单独部署其 API 服务配置会更复杂。本次演示以能跑通为先。步骤 4启动 Dify 服务回到之前dify/docker目录的终端使用 Docker Compose 启动所有服务。# 确保在 dify/docker 目录下 pwd # 应输出 /your/path/dify-local/dify/docker # 使用 docker compose 启动服务-d 表示后台运行 docker compose up -d这个命令会拉取 PostgreSQL, Redis, Weaviate (向量数据库) Nginx, 以及 Dify 后端和前端镜像并启动所有容器。第一次运行需要下载多个镜像耗时几分钟请耐心等待。步骤 5检查服务状态与访问启动完成后检查容器是否全部正常运行docker compose ps你应该看到所有服务db,redis,weaviate,api,worker,web-server,nginx的状态都是Up。现在打开你的浏览器访问http://localhost。如果一切顺利你将看到 Dify 的初始化设置页面。5. 功能测试与效果验证搭建三角洲游戏助手服务启动后我们进入实战环节创建一个名为“三角洲游戏助手”的 AI 应用。它将包含一个 RAG 知识库和一个基于此知识库的对话智能体。5.1 初始化设置与模型配置首次访问http://localhost会进入初始化流程。创建管理员账户输入邮箱、用户名和密码。命名你的团队例如 “DeltaForce Team”。模型供应商设置这是关键一步。在“模型供应商”页面选择OpenAI。API Base填写http://host.docker.internal:11434/v1与.env配置一致。API Key填写ollama或其他任意非空字符串。点击“验证”如果 Ollama 服务正常应该会显示“验证成功”并列出你通过 Ollama 拉取的模型如qwen2.5:7b-instruct。同样地在“嵌入模型”部分选择 OpenAI填写相同的 API Base 和 Key模型名称填写nomic-embed-text完成验证。完成设置进入 Dify 主控制台。5.2 构建 RAG 知识库知识库是智能体准确回答问题的基石。步骤 1创建知识库在左侧菜单栏点击“知识库”。点击“创建知识库”命名为“三角洲行动游戏攻略”并添加描述。点击进入该知识库。步骤 2上传与处理文档点击“上传文件”。我们需要准备一些关于“三角洲行动”Delta Force游戏的文档。你可以从游戏官网、Wiki如 Fandom、或自己整理一份简单的 QA 文档。示例文档内容 (delta_force_qa.txt)问三角洲行动是什么类型的游戏 答三角洲行动是一款第一人称射击游戏。 问游戏中有哪些经典武器 答包括M4A1卡宾枪、AK-47突击步枪、AWP狙击步枪等。 问如何完成“黑鹰坠落”关卡 答该关卡需要玩家在摩加迪沙街道中作战建议利用掩体逐步推进并优先消灭屋顶的火箭筒手。 问游戏支持哪些模式 答支持单人战役、多人对战和合作模式。将准备好的 TXT、PDF 或 Word 文档上传。Dify 支持批量上传。上传后文件会进入“处理中”状态。Dify 会自动进行文本提取从文件中提取文字。分段Chunking根据规则将长文本切分成语义片段。向量化Embedding调用我们配置的嵌入模型将文本片段转换为向量。索引存储将向量存入 Weaviate 向量数据库。处理完成后状态变为“已索引”。你可以点击“段”标签页查看文本被切分和向量化的具体结果。5.3 创建 AI 智能体应用知识库就绪后我们来创建智能体。步骤 1创建应用点击左侧“应用”然后点击“创建应用”。选择“对话型应用”命名为“三角洲游戏助手”。在应用创建页面我们进入核心配置。步骤 2配置智能体与工具提示词编排在“提示词编排”页面系统已经提供了一个默认的对话开场白。我们可以修改系统提示词让助手角色更明确。系统提示词示例你是一个专业的“三角洲行动”游戏助手精通游戏的所有关卡、武器、战术和技巧。你的回答应基于提供的知识库内容确保准确性和实用性。如果知识库中没有相关信息请如实告知用户你不知道不要编造信息。回答风格应简洁、直接专注于解决玩家的实际问题。关联知识库这是实现 RAG 的关键。在页面右侧的“工具”区域找到“知识库”点击“添加”。选择我们刚才创建的“三角洲行动游戏攻略”知识库。可以配置检索参数如“相似度阈值”、“返回数量”等暂时用默认值。模型选择在页面下方的“模型”区域选择我们之前验证通过的qwen2.5:7b-instruct模型。可以调整温度Temperature等参数。步骤 3测试对话配置完成后点击右上角的“发布”。然后在应用概览页你会看到一个对话窗口。 现在进行测试输入“三角洲行动是什么类型的游戏”预期助手应该能准确回答“第一人称射击游戏”并且这个答案来源于我们上传的知识库文档。输入“请给我一些‘黑鹰坠落’关卡的攻略。”预期助手应能检索到相关知识库片段并组织成连贯的回答。观察 RAG 过程在对话测试时点击右下角的“工作流详情”或“跟踪”按钮你可以看到每次问答的详细过程问题被向量化 - 从知识库检索相关片段 - 将片段和问题一起送入 LLM 生成答案。这正是 RAG 的工作流程。5.4 进阶使用工作流构建复杂智能体对话应用是基础而“工作流”才是 Dify 的威力所在。我们可以构建一个更复杂的智能体例如“根据玩家选择的武器推荐适合的关卡和战术”。在“应用”页面选择“创建应用” - “工作流”。进入可视化编排器。你可以从左侧拖拽节点开始节点接收用户输入例如“我喜欢用狙击枪”。知识库检索节点连接到我们的游戏知识库检索与“狙击枪”相关的信息。LLM 节点编写提示词让 LLM 根据检索结果和用户输入生成个性化的关卡推荐和战术建议。结束节点输出最终结果。连接各个节点配置每个节点的输入输出。点击“运行测试”输入“我喜欢用狙击枪”查看工作流执行过程和最终输出。通过拖拽和连接你无需编写代码就构建了一个具备逻辑判断和知识检索能力的智能体。6. 接口 API 与批量任务Dify 不仅提供 Web 界面所有功能都可通过 API 调用便于集成到其他系统或实现自动化。6.1 API 调用示例在应用发布后你可以在应用设置中找到“API 访问”选项并获取 API Key。使用 Python 调用对话 APIimport requests import json # 配置参数 api_key 你的应用API密钥 app_id 你的应用ID # 在应用URL或设置中能找到 endpoint http://localhost/v1/chat-messages # Dify API 端点 headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { inputs: {}, query: 三角洲行动有哪些游戏模式, # 用户问题 response_mode: blocking, # 同步响应 conversation_id: , # 首次对话留空后续用于多轮对话 user: test_user_001 } response requests.post(endpoint, headersheaders, jsonpayload, timeout60) if response.status_code 200: result response.json() print(回答, result.get(answer)) print(完整响应, json.dumps(result, indent2, ensure_asciiFalse)) else: print(f请求失败状态码{response.status_code}) print(response.text)调用工作流 API工作流发布后同样会提供一个 API 端点。调用方式类似但payload中的response_mode可能需要设为streaming或blocking并传递工作流所需的输入变量。6.2 批量任务处理知识库文档批量上传 Dify 的 Web 界面本身就支持多文件上传。通过 API你可以编写脚本批量上传一个目录下的所有文档。批量问答测试 你可以准备一个 CSV 文件包含一系列测试问题然后写一个循环脚本依次调用上面提到的对话 API将问题和答案记录到文件或数据库中用于评估智能体的准确率。import csv import requests import time api_key your-api-key endpoint http://localhost/v1/chat-messages headers {Authorization: fBearer {api_key}, Content-Type: application/json} with open(test_questions.csv, r, encodingutf-8) as f, open(results.csv, w, newline, encodingutf-8) as out_f: reader csv.reader(f) writer csv.writer(out_f) writer.writerow([Question, Answer, Time]) for row in reader: question row[0] payload {inputs: {}, query: question, response_mode: blocking, user: batch_test} try: start time.time() resp requests.post(endpoint, headersheaders, jsonpayload, timeout30) elapsed time.time() - start if resp.status_code 200: answer resp.json().get(answer, No answer) writer.writerow([question, answer, f{elapsed:.2f}s]) print(fQ: {question[:50]}... - OK) else: writer.writerow([question, fERROR: {resp.status_code}, ]) print(fQ: {question[:50]}... - FAILED) except Exception as e: writer.writerow([question, fEXCEPTION: {e}, ]) time.sleep(1) # 避免请求过快7. 资源占用与性能观察本地部署时资源占用是需要关注的重点。我们可以通过 Docker 命令和系统工具来观察。1. 查看容器资源占用docker stats --no-stream这个命令会列出所有运行中容器的 CPU、内存、网络 I/O 使用情况。重点关注dify-api、dify-worker和weaviate容器。在仅运行基础服务、未进行大量知识库处理或复杂对话时内存总占用通常在 2-4 GB 之间。2. 知识库处理性能影响因素文档大小、分段规则、嵌入模型速度。观察上传一个 PDF 文件后在“知识库”页面查看处理进度。处理时间主要花费在“向量化”阶段。使用本地nomic-embed-text模型通过 Ollama会比调用云端 API如 OpenAI慢但数据隐私有保障。优化如果处理速度过慢可以考虑升级 CPU/GPU或者换用更轻量的嵌入模型如text-embedding-ada-002的本地替代品。3. 对话响应速度影响因素LLM 生成速度、知识库检索速度、网络延迟如果 LLM 在远端。观察在 Web 界面进行问答感受响应时间。使用本地 7B 模型如 Qwen2.5在 CPU 上推理可能需要 10-30 秒生成一个回答如果有 GPU 加速会快很多。优化为 Ollama 配置 GPU 加速。调整知识库检索的“返回数量”减少送入 LLM 的上下文长度。对于简单问题可以在提示词中要求模型生成更简短的答案。4. 存储空间向量数据库Weaviate 数据默认存储在 Docker 卷中。随着知识库文档增多向量索引会占用显著空间。定期清理无用的知识库。日志与文件Dify 的日志和上传的原始文件也会占用空间。通过 Docker 卷管理或定期清理来释放空间。8. 常见问题与排查方法在部署和使用过程中你可能会遇到以下问题。这里提供排查思路。问题现象可能原因排查方式解决方案访问http://localhost失败1. 端口被占用。2. 容器未成功启动。3. Nginx 配置错误。1.docker compose ps查看容器状态。2.docker compose logs nginx查看 Nginx 日志。3.netstat -tuln | grep :80检查端口占用。1. 修改.env中的NGINX_HTTP_PORT并重启服务。2. 根据日志修复配置重新docker compose up -d。模型验证失败1. Ollama 服务未运行或地址错误。2. 模型未成功拉取。3..env配置错误。1. 在宿主机执行curl http://localhost:11434/api/tags检查 Ollama。2. 检查.env中OPENAI_API_BASE是否正确指向 Ollama。3. 查看dify-api容器日志docker compose logs api | grep -i error。1. 确保 Ollama 服务运行 (ollama serve)。2. 确认OPENAI_API_BASE是http://host.docker.internal:11434/v1Docker 容器内访问宿主机。3. 重新拉取模型ollama pull qwen2.5:7b-instruct。知识库文档处理失败/卡住1. 嵌入模型服务不可用。2. 文档格式不支持或损坏。3. 向量数据库连接问题。1. 在“知识库”页面查看具体文档的处理错误信息。2. 查看dify-worker容器日志docker compose logs worker。3. 尝试上传一个简单的 TXT 文件测试。1. 检查嵌入模型配置并验证。2. 将文档转换为纯文本 TXT 格式再上传。3. 重启 Weaviate 容器docker compose restart weaviate。对话回答“未找到相关知识”1. 知识库未成功关联到应用。2. 检索相似度阈值设置过高。3. 知识库内容与问题不相关。1. 检查应用“提示词编排”中是否已添加知识库工具。2. 在知识库工具配置中调低“相似度阈值”。3. 查看对话的“工作流详情”确认检索环节是否返回了片段。1. 正确关联知识库。2. 调整阈值如从 0.8 调到 0.5。3. 优化知识库文档内容使其更贴近用户可能问的问题。Ollama 模型响应极慢1. 模型在 CPU 上运行。2. 系统内存不足。3. 提示词过长。1. 检查 Ollama 是否使用了 GPU (ollama run qwen2.5:7b-instruct观察输出)。2. 使用htop或任务管理器查看内存使用。3. 在 Dify 中减少上下文长度或检索返回数量。1. 为 Ollama 配置 GPU 支持需安装 CUDA 版。2. 关闭不必要的程序或增加虚拟内存。3. 使用更小的模型如 3B 参数版本。Docker 容器启动报错1. 端口冲突。2. 镜像拉取失败。3..env文件格式错误。1.docker compose logs查看具体错误。2.docker images检查镜像是否存在。3. 检查.env文件是否有语法错误如缺少引号。1. 修改冲突端口或关闭占用端口的程序。2. 尝试docker compose pull重新拉取镜像。3. 使用cat -A .env检查文件或重新复制.env.example。9. 最佳实践与使用建议基于本次实战总结几条能让你的 Dify 项目更稳定、高效的建议。从最小可行原型开始不要一开始就上传海量文档。先用一个小的、结构清晰的 TXT 文件构建知识库测试问答流程是否跑通。验证通过后再逐步增加文档。精心准备知识库文档RAG 的效果严重依赖原始文档质量。尽量使用纯文本、结构清晰如 Markdown、信息密度高的文档。避免扫描版 PDFOCR 效果差、图片过多的 PPT。分段Chunking策略调优Dify 提供了分段规则设置如按字符数、段落。对于技术文档按章节或段落分段效果更好。可以创建不同分段规则的知识库进行对比测试。模型选型平衡在效果、速度和成本间权衡。对于内部知识库7B-14B 参数量的中英文开源模型如 Qwen, Llama, ChatGLM通常足够。嵌入模型可以选择bge-small-zh或nomic-embed-text的量化版以节省资源。善用工作流调试在构建复杂智能体时充分利用工作流编排器的“运行测试”和“跟踪”功能。逐步添加节点并测试确保每个环节的输入输出符合预期。API 集成与监控将 Dify 应用集成到自有系统时做好 API 调用的错误处理、超时重试和日志记录。监控 API 的响应时间和错误率。数据安全与备份定期备份 PostgreSQL 和 Weaviate 的数据卷。Dify 的 Docker Compose 文件通常配置了数据卷持久化但仍建议定期执行数据库备份。版本更新关注 Dify 的 GitHub 发布页。更新前务必在测试环境进行并备份数据。更新命令通常为git pull拉取最新代码然后docker compose down和docker compose up -d重启服务。10. 总结与下一步通过这次从零开始的实战我们完成了 Dify 的本地部署并成功构建了一个具备 RAG 知识库的“三角洲游戏助手”。整个过程验证了 Dify 的核心价值将复杂的 AI 应用开发简化为配置和拖拽操作。你无需关心向量索引如何构建、API 如何调度只需专注于业务逻辑和数据。这个项目最值得尝试的点在于其“开箱即用”和“可视化编排”能力。对于想快速验证 AI 想法、构建内部知识库系统或自动化流程的团队和个人Dify 提供了一个极佳的起点。最先应该验证的功能无疑是RAG 知识库问答。上传你的专业领域文档看看 AI 助手能否准确回答基于文档内容的问题。这是检验平台基础能力最直接的方式。最容易踩的坑主要集中在模型服务连接和知识库处理上。确保 Ollama 等服务运行正常、网络可达以及知识库文档格式友好能解决大部分初期问题。下一步你可以沿着这几个方向深入探索更复杂的智能体利用工作流结合“代码执行”、“HTTP 请求”等工具节点构建能自动查询天气、执行数据分析脚本的智能体。优化检索效果尝试不同的嵌入模型、分段策略和重排序方法提升知识库检索的准确率。接入更多模型除了 Ollama尝试接入通义千问、DeepSeek 等国内云的 API或者部署更强大的本地模型如 Qwen-32B。研究多模态Dify 已支持图像理解通过 GPT-4V 等模型可以尝试构建能分析游戏截图并给出建议的智能体。本地部署的 Dify 就像在你的电脑里安装了一个 AI 应用工厂从知识库到智能体所有流程皆可掌控。建议收藏本文在部署和调试时作为参考手册。