先说我为什么想写这篇。最近帮一个做内部系统的团队搭AI问答工具发现大家卡住的点根本不是模型效果而是从零开始写RAG、接API、调Prompt、做Agent编排这套流程太磨人。后来我直接用 Dify 这类大模型应用开发平台把模型底座换成 DeepSeek差不多一个下午就跑通了第一个可用原型。这个组合我用了快半年期间踩过不少坑也总结了一些比较顺手的操作路径所以整理成一篇完整攻略从安装部署到真实项目落地全都有适合正在评估技术选型、或者准备自建AI应用的开发者和产品同学。如果你还不熟悉这两个东西一句话概括Dify 负责应用层的“编排管理”DeepSeek 负责底层的“理解生成”。Dify 把模型接入、提示词管理、知识库、工作流、日志监控都封装成可视化模块DeepSeek 则提供便宜、中文效果好、推理能力不弱的模型API。两者配合等于把你从大量重复代码里解放出来只要关心业务逻辑本身。1. Dify和DeepSeek是什么关系这套组合解决了谁的痛点1.1 一个应用编排平台一个模型底座先把这个关系讲清楚。很多人一开始会误以为 Dify 是类似ChatGPT的成品工具其实它不是。Dify 是一个开源的大模型应用开发平台你可以把它理解成“集成了模型管理的低代码后端”。它解决的是应用层的事情连接各种大模型API统一管理模型供应商可视化设计聊天助手、Agent、工作流而不是手写调度代码内置知识库管道可以上传文档、自动分段、做向量检索自带日志、标注、API发布能力方便接入现有系统。DeepSeek 在这里的角色就纯粹得多。它是一个模型服务方提供 deepseek-chat 和 deepseek-reasoner 这类模型接口。它不关心你的业务流程只负责根据输入生成输出。真正把文档切片、向量存储、检索召回、上下文拼接这些脏活累活扛下来的是 Dify。1.2 为什么这两者搭配特别顺我最早是自己写代码调 DeepSeek API 的也能跑通但很快发现一个问题业务一旦复杂你要维护的东西指数级增加。比如要给文档加知识库得先选向量数据库、写切片逻辑、管理 Embedding、设计检索策略要给用户提供多轮对话得自己处理历史消息要加缓存和并发控制又要额外开发。Dify 把这些问题全部前置解决了。你只需要专注在“这个应用要完成什么任务、需要哪些步骤、如何设计提示词”上。对于中小团队和独立开发者来说这是效率上质的提升。这套组合适合谁也适合说清楚想快速做产品原型验证的人不需要一上来就写全套后端团队内部需要部署知识库问答、报表生成、流程助手的企业想学习RAG和Agent原理但不想被工程细节劝退的开发新手。不适合的场景也有如果你需要完全离线的私有化推理、要求高度定制的底层链路、或者有极其复杂的多租户权限体系那还是得自己搭。Dify 适合的是“大部分标准需求”不是所有需求。1.3 和自研代码对比到底省在哪里维度自己写代码DifyDeepSeek模型接入要处理接口鉴权、重试、超时界面点几下完成知识库自己集成向量库、Embedding内置pipeline提示词版本管理自己设计配置表可视化编辑历史记录工作流手写状态机或队列拖拽式节点编排日志追踪自己埋点自带应用日志我这么说不是否定自己写代码的价值。恰恰相反如果你想深入研究大模型应用亲手写一遍链路绝对有好处。但如果是业务压力在即、需要快速交付那我强烈建议先用 Dify 这类平台跑通业务再回来看底层实现。2. 部署环节我推荐的最小化安装路径与实际配置细节2.1 部署方式和硬件预期Dify 官方推荐 Docker Compose 方式部署这也是我试过最省心的路。它会把 API 服务、Worker、Web 前端、PostgreSQL、Redis、Nginx 等组件一次性编排起来。你不需要手动安装数据库和缓存docker compose 会统一处理。硬件上我的建议是内存至少 8GB实际生产建议 16GB。因为除了 Dify 自身服务你大概率还会跑本地 Embedding 模型后面细讲磁盘建议留 20GB 以上镜像和日志会持续占空间服务器系统我用的是 Ubuntu 22.04Docker 和 Docker Compose V2 都是必要组件。这里有个容易忽略的点如果你打算本地部署 Ollama 做 Embedding服务器的内存规划要把这部分也算进去。我一开始给一台 4GB 的机器硬跑结果 Dify 起来了Embedding 模型一加载就 OOM很尴尬。2.2 从拉取代码到启动的完整步骤整体过程分三步。首先准备好 docker 目录一般是通过官方仓库下载或者直接复制生产环境部署目录。然后进入目录执行命令docker compose up -d第一次启动会拉取不少镜像耗时取决于网络环境。启动完成后先查看容器状态docker compose ps看到所有服务状态是 running 或 healthy再继续下一步。如果发现某个容器反复重启用日志排查docker compose logs -f api正常跑起来后浏览器访问http://你的服务器IP/install这个页面会要求设置管理员邮箱和密码。设置完成后进入登录页用刚创建的管理员账号进去就看到 Dify 的主界面了。2.3 环境变量中值得提前改的参数很多人部署完就不管环境变量了其实这里藏着不少后续问题的答案。Dify 的 docker 目录里有.env配置文件至少这几个建议提前看一下SECRET_KEY影响会话加密和敏感数据保护不要使用默认值用命令生成一个随机串填进去openssl rand -base64 42NGINX_PORT默认监听 80 端口。如果你的服务器上已经有 Nginx 或其他 Web 服务占用 80一定要先改掉不然启动会直接失败。POSTGRES_PASSWORD、REDIS_PASSWORD这类数据库密码生产环境建议改成强密码虽然只在容器内网使用但多一层防护没坏处。还有一个小经验Dify 升级比较频繁如果之后要升级建议先把整个 docker 目录和 volumes 备份一份。容器可以重建数据丢了是真的找不回来。3. 让Dify认识DeepSeek模型接入的完整操作与隐藏参数3.1 先理解Dify里的模型层级Dify 的模型管理涉及供应商、模型类型、模型实例三层概念。供应商就是模型来源方DeepSeek 是一个供应商模型类型包括 LLM、Text Embedding、Rerank、语音转文字等。同一个供应商可以提供多种类型比如 OpenAI 既有 LLM 也有 Embedding。理解这个层级非常重要因为后面配置知识库时你会碰到的第一个坑就是DeepSeek 只提供 LLM 类型不提供 Embedding 类型。知识库要做向量检索必须有 Embedding 模型把文本转成向量。如果你只接入了 DeepSeek创建知识库时就会提示没有可用的 Embedding 模型。这个问题我再三强调因为它会卡住一半以上的人。3.2 获取API Key与额度管理在 DeepSeek 开放平台注册后进入密钥管理页面创建 API Key。API Key 创建时一般只会完整显示一次之后无法再查看所以要立刻保存到安全的地方。注意不要把密钥提交到 Git 仓库、贴在聊天群里、或者写在前端代码里。自建的 Dify 系统如果部署在公网一定要在 Dify 后台环境变量或密钥管理里妥善保存。虽然 Dify 后端会统一调用但泄露密钥的风险依然存在。DeepSeek 的 API 兼容 OpenAI 格式Base URL 是固定的 OpenAI 风格地址。如果你以后想在代码里直接调用也可以参考这个地址格式。不过在 Dify 里不需要手动填 Base URL系统已经内置了 DeepSeek 供应商模板。3.3 在Dify中配置DeepSeek的操作路径登录 Dify 后进入“设置” - “模型供应商”在列表里找到 DeepSeek点击“添加模型”或“配置”填写 API Key确认模型名称最常用的是 deepseek-chat点击保存系统会自动拉取可用模型列表在“系统模型设置”里把默认推理模型选为 deepseek-chat或者 deepseek-reasoner。这里有隐藏参数值得注意Dify 里同一个 LLM 模型也会有 Temperature、Top P、Max Tokens 等参数你在应用配置里可以覆盖默认值。DeepSeek 的 reasoner 模型比较特殊它带有思维链输出会先输出一段思考过程再输出答案。如果这个思维过程对你业务没有价值反而会浪费输出 Token所以普通对话场景我默认选 deepseek-chat复杂推理场景再切 reasoner。3.4 没有Embedding模型时怎么办这是我最想写清楚的一节。因为 DeepSeek 官方暂时没有提供 Embedding 接口所以 Dify 知识库流程里需要一个额外的 Embedding 模型来源。方案有三条路使用本地的 Ollama 部署 Embedding 模型比如 bge-m3使用兼容 OpenAI Embedding 规范的第三方服务使用其他云厂商带 Embedding 模型的供应商。我推荐本地 Ollama bge-m3 的方案数据不出服务器免费且可控。部署好 Ollama 后在 Dify 的模型供应商里找到 Ollama添加 Text Embedding 模型模型名称填 bge-m3访问地址根据容器网络填宿主机地址。在 Dify 容器环境里宿主机地址一般需要用类似http://host.docker.internal:11434的形式。如果你不是 Docker 部署而是 Kubernetes地址规则又会不一样。这个细节很容易因为网络配置不同而踩坑所以我在配好第一个知识库后顺手把当时的地址和端口记在了文档里。配置完成后建议先建一个测试知识库上传一篇文章跑一次索引任务确认状态变成“可用”再继续做应用。否则等到应用调试时才发现 Embedding 有问题排查链路会绕一大圈。4. 第一个实战搭建可用的知识库问答机器人4.1 创建应用聊天助手还是ChatflowDify 的应用类型里最常见的是“聊天助手”和“Chatflow工作流”。如果只是做“基于知识库的问答”聊天助手就够用了配置简单、维护成本低。如果你有多个环节、需要调用外部API、做条件判断再选 Chatflow。我先带大家做聊天助手版本。创建应用时填一个名字比如“内部知识问答”模型选已配置的 deepseek-chat。在提示词区域我先放一个基础模板你是某团队的内部知识库助手。请根据提供的知识库片段回答用户问题。 回答要求 1. 只依据上下文内容回答不要编造知识库中不存在的信息 2. 如果上下文不足以回答问题请直接说你不知道 3. 回答尽量简洁并标注引用的文档来源。这个提示词看着简单实际效果却很重要。如果没有“不要编造”的约束大模型在知识库召回不足时会一本正经地给出错误答案。4.2 知识库上传与分段设置在应用侧面进入“知识库”模块新建知识库上传 Markdown、PDF、TXT 等格式的文档。Dify 会自动做分段但我建议手工检查分段长度我常用 500 到 800 个 token太短会让上下文碎片化太长会稀释检索相关度分段重叠建议 50 到 100避免关键句被切到边界导致检索不到索引方式有高质量和经济两种问答场景选高质量也就是使用 Embedding。上传完成后进入“召回测试”页面输入几个真实的问题看看能召回到哪些片段。这一步很多人都忽略直接进应用调试结果上下文明明传了模型却答非所问。问题根源不在模型而在召回。4.3 检索参数调优TopK与Score阈值知识库关联到应用后你可以设置检索参数TopK召回几个片段我建议先设 3 到 5Score 阈值低于这个分数的片段会被过滤建议从 0.3 开始调检索模式可选择向量检索、全文检索、混合检索。中文场景混合检索通常更好因为中文分词的差异会影响向量召回。调参时不要只看单次结果。我会准备一组典型的测试问题包含“文档里有明确答案的”“文档里没有的”“需要跨多段拼接的”三类然后逐一测试。比如文档里没有答案的问题如果模型硬答了多半是阈值太低或提示词约束不够需要压阈值或加强提示词。4.4 效果验证和引用来源最后在预览页面测试完整对话。我之前遇到比较典型的场景用户问“离职流程怎么走”系统召回了考勤制度片段答非所问。后来发现是分段太粗把“离职流程”和“考勤制度”切到了同一块通过调整分段规则并增加自定义关键词才解决。Dify 的答案里可以带上引用来源打开这个开关后用户在界面上能看到对应文档片段。这是企业内部落地很实用的功能一方面增加可信度另一方面也方便人工快速核查回答是否正确。5. 第二个实战工作流编排一个自动周报助手5.1 为什么需要工作流聊天助手能解决“问答”类需求但企业里有很多流程不是简单一问一答。比如周报生成需要先获取任务数据、再按固定模板生成文档、最后推送到某个系统。这类任务用普通提示词很难稳定实现因为顺序和分支逻辑是固定的最容易的方式是编排成工作流。Dify 的 Chatflow 提供了可视化的节点编辑你可以把它想成一个低代码流程引擎。每个节点做一件事前一步的输出变成后一步的输入中途还能写条件分支、调用外部接口。5.2 一个周报助手的最小节点设计我设计的周报工作流包含五个节点开始节点接收用户的“本周工作概述”LLM节点根据工作概述生成周报正文输出 Markdown代码节点把周报里的任务清单提取为 JSON方便下一步处理HTTP请求节点把 JSON 推送到内部管理系统 API结束节点把 Markdown 返回给用户界面。这里最关键的技巧是不要让第一个 LLM 节点把所有事干完而是把“生成文本”和“结构化解析”分开。大模型很擅长生成流畅文本但让它同时输出格式规范又稳定的 JSON效果并不好。先用 LLM 生成周报文字再用代码节点做清洗每一步职责清晰故障也好定位。一个简单的 LLM 节点提示词示例如下你是周报生成助手。根据用户提供的工作内容生成一份结构化周报格式为 ## 本周完成 - 事项列表 ## 本周数据 - 关键指标说明 ## 下周计划 - 计划列表 不要添加额外解释。5.3 节点之间如何传参变量引用的实际写法在 Dify 工作流里每个节点都有自己的输出变量后续节点通过变量选择器引用本质上是模板字符串。例如你在 LLM 节点里把输出变量命名为output后面的 HTTP 请求节点需要引用它就通过编辑器里的变量插入完成。如果你的工作流需要把多个变量拼接起来可以用模板节点。我踩过一个坑直接在 LLM 节点的系统提示词里强行拼很长的上下文导致提示词超长、每次请求的 token 消耗猛增。正确做法是在开始节点收集原始输入尽量缩短提示词模板把大段数据放到上下文字段里。5.4 调试工作流的常用思路Dify 的 Chatflow 编辑界面右侧有调试面板能看到每个节点的输入输出。我的习惯是“每加一个节点就立刻测试一次”确认前一步输出符合预期后再往后接。特别是 HTTP 请求节点很可能因为鉴权参数没对导致整条链路失败。先用固定的假数据跑通再换成真正的变量。如果跑出来的周报格式时好时坏别急着改提示词先看是不是上游数据本身格式乱比如用户输入有换行、有特殊字符。可以在代码节点里做一次strip()和正则清理这样下游收到的就是相对规范的数据。6. 上线前收尾并发、缓存、日志与成本估算6.1 并发配置调整容器服务而不是盲目加机器Dify 官方编排里包含多个服务其中api和worker承担的职责不同。当用户请求量上来后如果你希望提高处理能力可能需要调整 worker 的服务副本数量。在 docker compose 的部署方式里最直接的做法是修改部署服务副本数然后重新启动。但这不代表你可以在 4GB 内存的小机器上无限扩容。模型 API 的响应时间才是最大的瓶颈本地服务扩容只能提升自身处理并发请求的速度最终模型接口能承受多少并发取决于 DeepSeek 侧的限流。我一般会做简单的压测用脚本模拟 10 个并发请求观察响应时间和服务日志有没有超时。如果大量超时优先检查模型供应商侧的配额和限流而不是盲目加副本。6.2 应用如何减少重复计算缓存思路在实际内部使用场景里用户问的问题有大量重复比如“怎么请假”“报销流程是什么”。对这类高频问题每次都走完整知识库检索加模型生成既浪费 token 又影响响应速度。我建议在应用层面前面加一层缓存策略。最简单的做法是对用户输入做归一化处理比如去掉空格、转小写然后用 Dify 外加的 Redis 接口按问题摘要缓存结果。如果命中缓存就直接返回历史答案如果没命中再走模型链路。这个方案对“答案相对稳定”的知识问答场景特别有效。当然如果问题本身带有明显个性化信息比如“我的工资单”绝对不能做全局缓存必须走完整流程。6.3 Token消耗怎么估算成本控制这件事做 AI 应用的人都绕不开。DeepSeek 的定价在同类模型里比较亲民但如果使用不当成本依然会悄悄涨上去。我一般按这个公式估算单次对话成本单次成本 输入tokens * 输入单价 输出tokens * 输出单价知识库问答的输入 tokens 往往占比很高因为你每问一次系统都会把召回的多个片段拼进上下文一起发给模型。如果 TopK 设成 5、每个片段 800 token那么单次输入可能就是 4000 到 5000 token 甚至更高。优化方法有几个把 TopK 从 5 降到 3优先保证召回精度精简系统提示词不要放一堆用不上的要求开启知识库的引用原文限制避免模型把大段原文原样复制设置合理的最大输出 token防止模型为了凑字数输出超长内容。我用实际数据举个例子假设内部 100 个人每人每天 20 次问答每次平均输入 3000 token、输出 400 token。如果单次成本很低日成本也在可接受范围。但如果人人都频繁触发长文档检索成本就会非线性上升。所以给应用设置用户配额和 API Key 配额是很有必要的。6.4 日志和监控的基本项Dify 自带应用日志能看到每轮对话用了多少 token、耗时多久、模型返回什么。上线后我至少每天检查一次日志重点关注有没有大量超时错误有没有输入内容触发了异常长度限制用户的提问类型是否和预期一致知识库召回的命中率是否稳定。如果服务跑在 Docker 里系统级日志用docker compose logs查看。要做更完整的监控也可以接入外部可观测平台不过内部使用阶段没必要一开始就搞太重。7. 真实使用中踩过的坑与我的最终建议7.1 部署和网络环境相关先说说 Docker 版本。旧版本的 docker-compose 是独立命令新版本是docker compose子命令两者命令格式有差异。如果执行docker compose up -d报错先检查 Docker 和 Compose 插件版本。另外80 端口被占用的问题很常见不只是 Nginx有些应用默认会监听 80。启动前先ss -lntp看一眼免得容器起不来排查半天。还有一次我部署完成后页面一直显示 502。原因不是 Dify 出了问题而是初始化任务还没结束数据库迁移没跑完。多等几分钟再看日志不要一看到 502 就立刻重启容器反而会把迁移打断。7.2 模型和知识库相关最大的坑还是前面反复说的 Embedding 模型。有人会觉得“我已经接了 DeepSeek知识库为什么不能用”模型类型确实是不同维度DeepSeek 再强也替代不了 Embedding。只要知识库用到向量检索就必须把 Embedding 模型配齐。第二个常见问题是大模型的上下文长度限制。很多错误信息会显示上下文长度超出模型限制听着很吓人实际解决方案很简单调低知识库召回片段数量、缩短分段长度、或者换上下文窗口更大的模型。不要一上来就改代码硬拆先看 HTTP 请求里的 prompt 到底有多长。第三个问题是中文场景的检索质量。直接做向量检索时经常出现“关键词对不上但语义相近”的情况结果反而把真正匹配的内容漏了。我后来把检索模式调成混合检索并加了 Rerank 模型效果提升明显。如果你的环境和时间允许Rerank 值得上。7.3 我的最终建议如果让我重新搭一遍这套系统我会按这样的顺序推进先部署 Dify再接入 DeepSeek同时把本地 Embedding 模型准备好然后用一个最小知识库跑通端到端链路最后才扩展工作流和复杂应用。不要一上来就直接复刻复杂业务那样容易把问题混在一起难以定位。提示词不必追求一次写好先给一个初版上线后根据真实用户反馈迭代。日志里能看到的错误、卡顿、无效回答都是最好的优化方向。还有一点Dify 更新速度很快不要停留在某个旧版本太久但也不要一升级就无脑覆盖。升级前备份数据升级后在测试环境跑一遍核心流程确认没有回归再切生产。最后分享一个习惯。我现在面对新的 AI 应用需求先问自己这个需求能不能拆成“稳定的工作流”和“模型自由发挥”两个部分稳定的流程交给工作流节点需要理解和生成的交给 DeepSeek不要指望一个大模型提示词包打天下。这套 Dify DeepSeek 的组合最值钱的地方不在于省了写代码的时间而在于让我把“应用架构”和“模型能力”的边界想得足够清楚。如果你正准备从零搭一个 AI 应用照着这个路线走30 分钟内跑通原型不是问题。真正花时间的永远是理解业务和打磨细节那部分。 
长河君 · 2026/10/17 4:40:50 · 阅读 1.2k Dify+DeepSeek实操指南：从零搭建知识库问答与工作流应用
先说我为什么想写这篇。最近帮一个做内部系统的团队搭AI问答工具发现大家卡住的点根本不是模型效果而是从零开始写RAG、接API、调Prompt、做Agent编排这套流程太磨人。后来我直接用 Dify 这类大模型应用开发平台把模型底座换成 DeepSeek差不多一个下午就跑通了第一个可用原型。这个组合我用了快半年期间踩过不少坑也总结了一些比较顺手的操作路径所以整理成一篇完整攻略从安装部署到真实项目落地全都有适合正在评估技术选型、或者准备自建AI应用的开发者和产品同学。如果你还不熟悉这两个东西一句话概括Dify 负责应用层的“编排管理”DeepSeek 负责底层的“理解生成”。Dify 把模型接入、提示词管理、知识库、工作流、日志监控都封装成可视化模块DeepSeek 则提供便宜、中文效果好、推理能力不弱的模型API。两者配合等于把你从大量重复代码里解放出来只要关心业务逻辑本身。1. Dify和DeepSeek是什么关系这套组合解决了谁的痛点1.1 一个应用编排平台一个模型底座先把这个关系讲清楚。很多人一开始会误以为 Dify 是类似ChatGPT的成品工具其实它不是。Dify 是一个开源的大模型应用开发平台你可以把它理解成“集成了模型管理的低代码后端”。它解决的是应用层的事情连接各种大模型API统一管理模型供应商可视化设计聊天助手、Agent、工作流而不是手写调度代码内置知识库管道可以上传文档、自动分段、做向量检索自带日志、标注、API发布能力方便接入现有系统。DeepSeek 在这里的角色就纯粹得多。它是一个模型服务方提供 deepseek-chat 和 deepseek-reasoner 这类模型接口。它不关心你的业务流程只负责根据输入生成输出。真正把文档切片、向量存储、检索召回、上下文拼接这些脏活累活扛下来的是 Dify。1.2 为什么这两者搭配特别顺我最早是自己写代码调 DeepSeek API 的也能跑通但很快发现一个问题业务一旦复杂你要维护的东西指数级增加。比如要给文档加知识库得先选向量数据库、写切片逻辑、管理 Embedding、设计检索策略要给用户提供多轮对话得自己处理历史消息要加缓存和并发控制又要额外开发。Dify 把这些问题全部前置解决了。你只需要专注在“这个应用要完成什么任务、需要哪些步骤、如何设计提示词”上。对于中小团队和独立开发者来说这是效率上质的提升。这套组合适合谁也适合说清楚想快速做产品原型验证的人不需要一上来就写全套后端团队内部需要部署知识库问答、报表生成、流程助手的企业想学习RAG和Agent原理但不想被工程细节劝退的开发新手。不适合的场景也有如果你需要完全离线的私有化推理、要求高度定制的底层链路、或者有极其复杂的多租户权限体系那还是得自己搭。Dify 适合的是“大部分标准需求”不是所有需求。1.3 和自研代码对比到底省在哪里维度自己写代码DifyDeepSeek模型接入要处理接口鉴权、重试、超时界面点几下完成知识库自己集成向量库、Embedding内置pipeline提示词版本管理自己设计配置表可视化编辑历史记录工作流手写状态机或队列拖拽式节点编排日志追踪自己埋点自带应用日志我这么说不是否定自己写代码的价值。恰恰相反如果你想深入研究大模型应用亲手写一遍链路绝对有好处。但如果是业务压力在即、需要快速交付那我强烈建议先用 Dify 这类平台跑通业务再回来看底层实现。2. 部署环节我推荐的最小化安装路径与实际配置细节2.1 部署方式和硬件预期Dify 官方推荐 Docker Compose 方式部署这也是我试过最省心的路。它会把 API 服务、Worker、Web 前端、PostgreSQL、Redis、Nginx 等组件一次性编排起来。你不需要手动安装数据库和缓存docker compose 会统一处理。硬件上我的建议是内存至少 8GB实际生产建议 16GB。因为除了 Dify 自身服务你大概率还会跑本地 Embedding 模型后面细讲磁盘建议留 20GB 以上镜像和日志会持续占空间服务器系统我用的是 Ubuntu 22.04Docker 和 Docker Compose V2 都是必要组件。这里有个容易忽略的点如果你打算本地部署 Ollama 做 Embedding服务器的内存规划要把这部分也算进去。我一开始给一台 4GB 的机器硬跑结果 Dify 起来了Embedding 模型一加载就 OOM很尴尬。2.2 从拉取代码到启动的完整步骤整体过程分三步。首先准备好 docker 目录一般是通过官方仓库下载或者直接复制生产环境部署目录。然后进入目录执行命令docker compose up -d第一次启动会拉取不少镜像耗时取决于网络环境。启动完成后先查看容器状态docker compose ps看到所有服务状态是 running 或 healthy再继续下一步。如果发现某个容器反复重启用日志排查docker compose logs -f api正常跑起来后浏览器访问http://你的服务器IP/install这个页面会要求设置管理员邮箱和密码。设置完成后进入登录页用刚创建的管理员账号进去就看到 Dify 的主界面了。2.3 环境变量中值得提前改的参数很多人部署完就不管环境变量了其实这里藏着不少后续问题的答案。Dify 的 docker 目录里有.env配置文件至少这几个建议提前看一下SECRET_KEY影响会话加密和敏感数据保护不要使用默认值用命令生成一个随机串填进去openssl rand -base64 42NGINX_PORT默认监听 80 端口。如果你的服务器上已经有 Nginx 或其他 Web 服务占用 80一定要先改掉不然启动会直接失败。POSTGRES_PASSWORD、REDIS_PASSWORD这类数据库密码生产环境建议改成强密码虽然只在容器内网使用但多一层防护没坏处。还有一个小经验Dify 升级比较频繁如果之后要升级建议先把整个 docker 目录和 volumes 备份一份。容器可以重建数据丢了是真的找不回来。3. 让Dify认识DeepSeek模型接入的完整操作与隐藏参数3.1 先理解Dify里的模型层级Dify 的模型管理涉及供应商、模型类型、模型实例三层概念。供应商就是模型来源方DeepSeek 是一个供应商模型类型包括 LLM、Text Embedding、Rerank、语音转文字等。同一个供应商可以提供多种类型比如 OpenAI 既有 LLM 也有 Embedding。理解这个层级非常重要因为后面配置知识库时你会碰到的第一个坑就是DeepSeek 只提供 LLM 类型不提供 Embedding 类型。知识库要做向量检索必须有 Embedding 模型把文本转成向量。如果你只接入了 DeepSeek创建知识库时就会提示没有可用的 Embedding 模型。这个问题我再三强调因为它会卡住一半以上的人。3.2 获取API Key与额度管理在 DeepSeek 开放平台注册后进入密钥管理页面创建 API Key。API Key 创建时一般只会完整显示一次之后无法再查看所以要立刻保存到安全的地方。注意不要把密钥提交到 Git 仓库、贴在聊天群里、或者写在前端代码里。自建的 Dify 系统如果部署在公网一定要在 Dify 后台环境变量或密钥管理里妥善保存。虽然 Dify 后端会统一调用但泄露密钥的风险依然存在。DeepSeek 的 API 兼容 OpenAI 格式Base URL 是固定的 OpenAI 风格地址。如果你以后想在代码里直接调用也可以参考这个地址格式。不过在 Dify 里不需要手动填 Base URL系统已经内置了 DeepSeek 供应商模板。3.3 在Dify中配置DeepSeek的操作路径登录 Dify 后进入“设置” - “模型供应商”在列表里找到 DeepSeek点击“添加模型”或“配置”填写 API Key确认模型名称最常用的是 deepseek-chat点击保存系统会自动拉取可用模型列表在“系统模型设置”里把默认推理模型选为 deepseek-chat或者 deepseek-reasoner。这里有隐藏参数值得注意Dify 里同一个 LLM 模型也会有 Temperature、Top P、Max Tokens 等参数你在应用配置里可以覆盖默认值。DeepSeek 的 reasoner 模型比较特殊它带有思维链输出会先输出一段思考过程再输出答案。如果这个思维过程对你业务没有价值反而会浪费输出 Token所以普通对话场景我默认选 deepseek-chat复杂推理场景再切 reasoner。3.4 没有Embedding模型时怎么办这是我最想写清楚的一节。因为 DeepSeek 官方暂时没有提供 Embedding 接口所以 Dify 知识库流程里需要一个额外的 Embedding 模型来源。方案有三条路使用本地的 Ollama 部署 Embedding 模型比如 bge-m3使用兼容 OpenAI Embedding 规范的第三方服务使用其他云厂商带 Embedding 模型的供应商。我推荐本地 Ollama bge-m3 的方案数据不出服务器免费且可控。部署好 Ollama 后在 Dify 的模型供应商里找到 Ollama添加 Text Embedding 模型模型名称填 bge-m3访问地址根据容器网络填宿主机地址。在 Dify 容器环境里宿主机地址一般需要用类似http://host.docker.internal:11434的形式。如果你不是 Docker 部署而是 Kubernetes地址规则又会不一样。这个细节很容易因为网络配置不同而踩坑所以我在配好第一个知识库后顺手把当时的地址和端口记在了文档里。配置完成后建议先建一个测试知识库上传一篇文章跑一次索引任务确认状态变成“可用”再继续做应用。否则等到应用调试时才发现 Embedding 有问题排查链路会绕一大圈。4. 第一个实战搭建可用的知识库问答机器人4.1 创建应用聊天助手还是ChatflowDify 的应用类型里最常见的是“聊天助手”和“Chatflow工作流”。如果只是做“基于知识库的问答”聊天助手就够用了配置简单、维护成本低。如果你有多个环节、需要调用外部API、做条件判断再选 Chatflow。我先带大家做聊天助手版本。创建应用时填一个名字比如“内部知识问答”模型选已配置的 deepseek-chat。在提示词区域我先放一个基础模板你是某团队的内部知识库助手。请根据提供的知识库片段回答用户问题。 回答要求 1. 只依据上下文内容回答不要编造知识库中不存在的信息 2. 如果上下文不足以回答问题请直接说你不知道 3. 回答尽量简洁并标注引用的文档来源。这个提示词看着简单实际效果却很重要。如果没有“不要编造”的约束大模型在知识库召回不足时会一本正经地给出错误答案。4.2 知识库上传与分段设置在应用侧面进入“知识库”模块新建知识库上传 Markdown、PDF、TXT 等格式的文档。Dify 会自动做分段但我建议手工检查分段长度我常用 500 到 800 个 token太短会让上下文碎片化太长会稀释检索相关度分段重叠建议 50 到 100避免关键句被切到边界导致检索不到索引方式有高质量和经济两种问答场景选高质量也就是使用 Embedding。上传完成后进入“召回测试”页面输入几个真实的问题看看能召回到哪些片段。这一步很多人都忽略直接进应用调试结果上下文明明传了模型却答非所问。问题根源不在模型而在召回。4.3 检索参数调优TopK与Score阈值知识库关联到应用后你可以设置检索参数TopK召回几个片段我建议先设 3 到 5Score 阈值低于这个分数的片段会被过滤建议从 0.3 开始调检索模式可选择向量检索、全文检索、混合检索。中文场景混合检索通常更好因为中文分词的差异会影响向量召回。调参时不要只看单次结果。我会准备一组典型的测试问题包含“文档里有明确答案的”“文档里没有的”“需要跨多段拼接的”三类然后逐一测试。比如文档里没有答案的问题如果模型硬答了多半是阈值太低或提示词约束不够需要压阈值或加强提示词。4.4 效果验证和引用来源最后在预览页面测试完整对话。我之前遇到比较典型的场景用户问“离职流程怎么走”系统召回了考勤制度片段答非所问。后来发现是分段太粗把“离职流程”和“考勤制度”切到了同一块通过调整分段规则并增加自定义关键词才解决。Dify 的答案里可以带上引用来源打开这个开关后用户在界面上能看到对应文档片段。这是企业内部落地很实用的功能一方面增加可信度另一方面也方便人工快速核查回答是否正确。5. 第二个实战工作流编排一个自动周报助手5.1 为什么需要工作流聊天助手能解决“问答”类需求但企业里有很多流程不是简单一问一答。比如周报生成需要先获取任务数据、再按固定模板生成文档、最后推送到某个系统。这类任务用普通提示词很难稳定实现因为顺序和分支逻辑是固定的最容易的方式是编排成工作流。Dify 的 Chatflow 提供了可视化的节点编辑你可以把它想成一个低代码流程引擎。每个节点做一件事前一步的输出变成后一步的输入中途还能写条件分支、调用外部接口。5.2 一个周报助手的最小节点设计我设计的周报工作流包含五个节点开始节点接收用户的“本周工作概述”LLM节点根据工作概述生成周报正文输出 Markdown代码节点把周报里的任务清单提取为 JSON方便下一步处理HTTP请求节点把 JSON 推送到内部管理系统 API结束节点把 Markdown 返回给用户界面。这里最关键的技巧是不要让第一个 LLM 节点把所有事干完而是把“生成文本”和“结构化解析”分开。大模型很擅长生成流畅文本但让它同时输出格式规范又稳定的 JSON效果并不好。先用 LLM 生成周报文字再用代码节点做清洗每一步职责清晰故障也好定位。一个简单的 LLM 节点提示词示例如下你是周报生成助手。根据用户提供的工作内容生成一份结构化周报格式为 ## 本周完成 - 事项列表 ## 本周数据 - 关键指标说明 ## 下周计划 - 计划列表 不要添加额外解释。5.3 节点之间如何传参变量引用的实际写法在 Dify 工作流里每个节点都有自己的输出变量后续节点通过变量选择器引用本质上是模板字符串。例如你在 LLM 节点里把输出变量命名为output后面的 HTTP 请求节点需要引用它就通过编辑器里的变量插入完成。如果你的工作流需要把多个变量拼接起来可以用模板节点。我踩过一个坑直接在 LLM 节点的系统提示词里强行拼很长的上下文导致提示词超长、每次请求的 token 消耗猛增。正确做法是在开始节点收集原始输入尽量缩短提示词模板把大段数据放到上下文字段里。5.4 调试工作流的常用思路Dify 的 Chatflow 编辑界面右侧有调试面板能看到每个节点的输入输出。我的习惯是“每加一个节点就立刻测试一次”确认前一步输出符合预期后再往后接。特别是 HTTP 请求节点很可能因为鉴权参数没对导致整条链路失败。先用固定的假数据跑通再换成真正的变量。如果跑出来的周报格式时好时坏别急着改提示词先看是不是上游数据本身格式乱比如用户输入有换行、有特殊字符。可以在代码节点里做一次strip()和正则清理这样下游收到的就是相对规范的数据。6. 上线前收尾并发、缓存、日志与成本估算6.1 并发配置调整容器服务而不是盲目加机器Dify 官方编排里包含多个服务其中api和worker承担的职责不同。当用户请求量上来后如果你希望提高处理能力可能需要调整 worker 的服务副本数量。在 docker compose 的部署方式里最直接的做法是修改部署服务副本数然后重新启动。但这不代表你可以在 4GB 内存的小机器上无限扩容。模型 API 的响应时间才是最大的瓶颈本地服务扩容只能提升自身处理并发请求的速度最终模型接口能承受多少并发取决于 DeepSeek 侧的限流。我一般会做简单的压测用脚本模拟 10 个并发请求观察响应时间和服务日志有没有超时。如果大量超时优先检查模型供应商侧的配额和限流而不是盲目加副本。6.2 应用如何减少重复计算缓存思路在实际内部使用场景里用户问的问题有大量重复比如“怎么请假”“报销流程是什么”。对这类高频问题每次都走完整知识库检索加模型生成既浪费 token 又影响响应速度。我建议在应用层面前面加一层缓存策略。最简单的做法是对用户输入做归一化处理比如去掉空格、转小写然后用 Dify 外加的 Redis 接口按问题摘要缓存结果。如果命中缓存就直接返回历史答案如果没命中再走模型链路。这个方案对“答案相对稳定”的知识问答场景特别有效。当然如果问题本身带有明显个性化信息比如“我的工资单”绝对不能做全局缓存必须走完整流程。6.3 Token消耗怎么估算成本控制这件事做 AI 应用的人都绕不开。DeepSeek 的定价在同类模型里比较亲民但如果使用不当成本依然会悄悄涨上去。我一般按这个公式估算单次对话成本单次成本 输入tokens * 输入单价 输出tokens * 输出单价知识库问答的输入 tokens 往往占比很高因为你每问一次系统都会把召回的多个片段拼进上下文一起发给模型。如果 TopK 设成 5、每个片段 800 token那么单次输入可能就是 4000 到 5000 token 甚至更高。优化方法有几个把 TopK 从 5 降到 3优先保证召回精度精简系统提示词不要放一堆用不上的要求开启知识库的引用原文限制避免模型把大段原文原样复制设置合理的最大输出 token防止模型为了凑字数输出超长内容。我用实际数据举个例子假设内部 100 个人每人每天 20 次问答每次平均输入 3000 token、输出 400 token。如果单次成本很低日成本也在可接受范围。但如果人人都频繁触发长文档检索成本就会非线性上升。所以给应用设置用户配额和 API Key 配额是很有必要的。6.4 日志和监控的基本项Dify 自带应用日志能看到每轮对话用了多少 token、耗时多久、模型返回什么。上线后我至少每天检查一次日志重点关注有没有大量超时错误有没有输入内容触发了异常长度限制用户的提问类型是否和预期一致知识库召回的命中率是否稳定。如果服务跑在 Docker 里系统级日志用docker compose logs查看。要做更完整的监控也可以接入外部可观测平台不过内部使用阶段没必要一开始就搞太重。7. 真实使用中踩过的坑与我的最终建议7.1 部署和网络环境相关先说说 Docker 版本。旧版本的 docker-compose 是独立命令新版本是docker compose子命令两者命令格式有差异。如果执行docker compose up -d报错先检查 Docker 和 Compose 插件版本。另外80 端口被占用的问题很常见不只是 Nginx有些应用默认会监听 80。启动前先ss -lntp看一眼免得容器起不来排查半天。还有一次我部署完成后页面一直显示 502。原因不是 Dify 出了问题而是初始化任务还没结束数据库迁移没跑完。多等几分钟再看日志不要一看到 502 就立刻重启容器反而会把迁移打断。7.2 模型和知识库相关最大的坑还是前面反复说的 Embedding 模型。有人会觉得“我已经接了 DeepSeek知识库为什么不能用”模型类型确实是不同维度DeepSeek 再强也替代不了 Embedding。只要知识库用到向量检索就必须把 Embedding 模型配齐。第二个常见问题是大模型的上下文长度限制。很多错误信息会显示上下文长度超出模型限制听着很吓人实际解决方案很简单调低知识库召回片段数量、缩短分段长度、或者换上下文窗口更大的模型。不要一上来就改代码硬拆先看 HTTP 请求里的 prompt 到底有多长。第三个问题是中文场景的检索质量。直接做向量检索时经常出现“关键词对不上但语义相近”的情况结果反而把真正匹配的内容漏了。我后来把检索模式调成混合检索并加了 Rerank 模型效果提升明显。如果你的环境和时间允许Rerank 值得上。7.3 我的最终建议如果让我重新搭一遍这套系统我会按这样的顺序推进先部署 Dify再接入 DeepSeek同时把本地 Embedding 模型准备好然后用一个最小知识库跑通端到端链路最后才扩展工作流和复杂应用。不要一上来就直接复刻复杂业务那样容易把问题混在一起难以定位。提示词不必追求一次写好先给一个初版上线后根据真实用户反馈迭代。日志里能看到的错误、卡顿、无效回答都是最好的优化方向。还有一点Dify 更新速度很快不要停留在某个旧版本太久但也不要一升级就无脑覆盖。升级前备份数据升级后在测试环境跑一遍核心流程确认没有回归再切生产。最后分享一个习惯。我现在面对新的 AI 应用需求先问自己这个需求能不能拆成“稳定的工作流”和“模型自由发挥”两个部分稳定的流程交给工作流节点需要理解和生成的交给 DeepSeek不要指望一个大模型提示词包打天下。这套 Dify DeepSeek 的组合最值钱的地方不在于省了写代码的时间而在于让我把“应用架构”和“模型能力”的边界想得足够清楚。如果你正准备从零搭一个 AI 应用照着这个路线走30 分钟内跑通原型不是问题。真正花时间的永远是理解业务和打磨细节那部分。