RSG敏捷嘉年华大会2026上海的主题围绕敏捷方法论与AI应用开发如何结合展开Dify创始人张路宇出席分享让“Dify”和“敏捷流程”这两个关键词出现在同一个讨论场景中。对开发者来说与其猜测嘉宾演讲中的具体内容不如把这次交流变成可以落地的工程问题Dify到底是什么样的平台为什么AI应用开发特别需要小步快跑式的迭代以及本地部署、知识库搭建、工作流编排和故障排查应该按什么顺序处理。这篇文章就围绕这条主线展开先讲清楚Dify的产品定位与敏捷开发的关系再完成一次本地部署随后搭建知识库和对话应用最后给出生产上线前需要补齐的工程约束。1. 从RSG敏捷嘉年华大会看AI应用开发的敏捷选择1.1 Dify是什么一个面向大模型应用的可视化开发平台Dify 是一个开源的大语言模型应用开发平台。通俗地说它把“调用大模型”这件事从代码层面搬到产品界面里模型供应商管理、Prompt 编排、知识库接入、工作流设计、Agent 工具调用、API 发布都可以在同一个平台内完成。从技术定义看Dify 覆盖了大模型应用的完整生命周期。你不需要从零写模型调用链不需要自己维护向量数据库和文本分块逻辑也不需要重复实现 Web 端对话窗口和 API 网关。平台将这些通用能力抽象成可配置的模块开发者只需要关注业务逻辑和效果调优。放在 RSG 大会的语境下Dify 的意义在于它把“AI 应用开发”从少数算法工程师的专属任务变成了产品、运营、开发可以共同参与的协作过程。业务人员可以直接调整 Prompt 和知识库内容开发人员负责模型接入、工作流和发布接口。1.2 为什么 AI 应用比传统 Web 应用更需要敏捷流程传统软件项目的需求相对明确开发前可以做完整设计再按计划交付。但 AI 应用有一个关键差异模型的行为具有不确定性。同样的 Prompt换一个模型、换一批知识文档、甚至换一种提问方式输出都可能有明显变化。这意味着 AI 应用很难“一次设计到位”。你无法在写代码之前准确预测用户的提问方式、知识库的检索命中率、模型回答的语气和格式。更合理的做法是先做一个最小可用的原型让真实用户试用观察输出质量再根据反馈调整 Prompt、知识库分块参数、模型参数和检索策略。这正是敏捷开发里“短迭代、快反馈、持续验证”的核心思路。预测型流程适合需求稳定、变更成本高的项目敏捷型流程适合需求不清晰、验证成本低的项目。AI 应用天然属于后者。Dify 的可视化编排刚好降低了迭代成本改一个 Prompt、换一个模型、调整一个检索参数都不需要重启整个服务改完可以在调试页面立刻看到效果。1.3 Dify 适合什么场景不适合什么场景适合的场景包括企业知识库问答把内部文档、产品手册、制度文件接入知识库让用户用自然语言提问。客服助手结合历史工单和售后文档生成候选回答。数据分析与清洗用工作流调用模型对表格、文本进行格式化和内容抽取。内容抽取与文档理解从长文档中提取关键信息生成摘要或结构化结果。文生图、工具调用类应用通过插件和 MCP 扩展模型能力。不适合的场景也要说清楚。如果业务要求毫秒级响应、需要在模型底层做深度训练、需要完全离线且高度定制核心逻辑Dify 这类平台只能作为辅助或原型工具。它解决的是“快速搭建和持续迭代”的问题不是“从零训练一个模型”的问题。2. 先确认环境再在 Docker 里部署 Dify 社区版2.1 本地跑通的最小环境要求Dify 社区版最常用的部署方式是 Docker Compose。官方仓库的 docker 目录里包含了 api、web、db、redis、向量数据库等服务的编排文件。本地学习环境建议满足以下条件项目最低建议说明Docker Engine20.10 以上不同 Dify 版本对 Docker 版本有要求以官方 release notes 为准Docker Composev2 版本使用docker compose子命令CPU4 核以上本地模型推理会更吃 CPU内存8 GB 以上部署服务本身占 2-3 GBOllama 加载模型另算磁盘20 GB 可用空间镜像、日志、向量数据会持续增长操作系统Linux / Windows WSL2 / macOSWindows 推荐使用 Docker Desktop 搭配 WSL2启动前先确认基础环境docker --version docker compose version如果 Docker 未安装先安装 Docker Engine 或 Docker Desktop再继续下文操作。不要跳过这一步很多部署失败都源于 Docker 版本过旧或 Compose 插件缺失。2.2 下载项目并完成基础配置部署前先获取 Dify 官方仓库并进入 docker 编排目录git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env.env文件是 Dify 环境配置的核心。学习环境至少需要关注两项SECRET_KEY用于敏感数据加密。生产环境必须改成随机长字符串可以用openssl rand -base64 42生成。INIT_PASSWORD初始化管理员密码。如果保留默认值外部人员可能直接登录后台。确认配置后启动服务docker compose up -d首次启动会拉取 api、web、db、redis、sandbox、weaviate 等多个镜像耗时取决于网络。启动完成后检查容器状态docker compose ps正常情况下关键服务的状态应为Up。如果某个容器反复重启先看该容器日志再继续后续配置。2.3 完成管理员初始化和首次登录服务启动后用浏览器访问http://localhost/apps首次访问会进入管理员账号初始化页面设置管理员邮箱和密码。这里要注意初始化页面只出现一次如果没设置完整就不能跳过。初始化完成后进入登录页使用管理员账号登录。登录后建议先进入“设置 - 模型供应商”接入至少一个可用模型。没有模型后面的知识库和对话应用都无法正常工作。这个过程是整个 Dify 学习环境里最容易被忽略的环节很多人部署成功、登录成功却在创建应用时发现模型不存在或调用失败。2.4 接入 Ollama 本地模型和在线模型的差异接模型时有两种常见选择在线模型例如 OpenAI、DeepSeek、通义千问等配置简单只需填写 API Key 和 Base URL适合快速验证效果。本地模型使用 Ollama 部署开源模型数据不出内网适合隐私要求高或需要离线调试的场景。以 Ollama 为例先在宿主机安装并启动 Ollamaollama serve ollama pull qwen2.5:7b然后在 Dify 的模型供应商页面选择 Ollama填写模型名称必须与ollama list显示的名称完全一致。Base URLWindows 和 macOS 的 Docker Desktop 环境填http://host.docker.internal:11434Linux 环境填宿主机局域网 IP。模型类型根据实际模型填写 LLM 或 Embedding。这里有一个关键原因Dify 的 api 服务运行在容器内容器内的localhost指向容器自己访问不到宿主机上的 Ollama。host.docker.internal是 Docker 提供的宿主机访问入口Linux 下需要额外配置或直接使用宿主机局域网 IP。3. 从知识库到对话应用跑通第一个 AI 应用闭环3.1 知识库流水线上传、分块、嵌入、检索Dify 知识库本质上是一条文档处理流水线分为四个阶段阶段作用常见配置上传导入 PDF、TXT、Markdown、Word 等文件文件格式和大小限制分块把长文档切成适合检索的片段分块长度、重叠长度嵌入用 Embedding 模型将文本转成向量选择嵌入模型存储与检索写入向量库用户提问时召回相关片段检索模式、Top K、相似度阈值在 Dify 界面中进入“知识库 - 创建知识库”上传文档选择分块模式和嵌入模型保存后文档会进入“同步中”状态。同步完成后才能被应用检索。学习阶段可以直接使用自动分块先跑通流程。如果你发现回答质量不好再回到自定义分块调整片段长度。分块长度没有绝对标准取决于文档类型和模型上下文窗口。常见经验是 300 到 800 字起步片段太短会丢失上下文太长会降低检索精度。3.2 创建聊天助手并绑定知识库进入“创建空白应用”选择“聊天助手”。在编排页面完成三项配置选择模型选择已经接入的对话模型。编写 Prompt定义角色、任务、输出格式和约束条件。添加知识库把刚建好的知识库关联进来并通过上下文变量把检索结果传给模型。在 Prompt 中知识库内容通常通过context变量注入。示例 Prompt 结构如下你是企业内部文档助手。请严格基于提供的上下文回答问题。 如果上下文没有答案请直接说明无法回答不要编造内容。 上下文内容 {{#context#}}这里要说明为什么context变量很重要模型本身没有你的文档知识只有把知识库检索到的相关内容放到 Prompt 里模型才能基于这些内容生成回答。检索不到相关内容时再强的模型也只能给出泛泛答案。3.3 工作流把多步骤逻辑变成可视化节点当对话应用需要处理“先判断问题类型再决定调用哪个模型或工具”时就要用到工作流。Dify 工作流把处理逻辑画成节点图核心节点包括开始节点定义输入变量。LLM 节点执行一次模型调用。问题分类节点按规则或模型判断类型。条件分支节点按变量值走不同路径。HTTP 请求节点调用外部接口。代码节点执行自定义代码。模板转换节点处理文本格式。结束节点定义最终输出。可以搭建一个最小示例数据清洗助手。开始节点接收原始文本LLM 节点按“去除空行、统一日期格式、输出 Markdown 列表”的指令处理文本结束节点输出清洗结果。这样一个流程能在调试页面里观察每一步的输入输出定位是 Prompt 问题还是数据问题。3.4 调试、发布和版本管理Dify 应用编排页右侧有预览调试区。调试时建议准备多组输入正常输入验证主流程。边界输入超长文本、空文本、不相关提问。敏感输入涉及隐私或违规的内容观察有没有兜底回答。工作流和对话助手在调试通过后可以点击“发布”。发布后应用可以通过 WebApp 链接访问也可以通过 API 提供给外部系统调用。这里有一个敏捷开发上的优势修改 Prompt 或工作流后可以立刻调试调试通过再发布不需要像传统项目那样等待完整发版周期。4. 关键参数、扩展能力和多租户协作4.1 模型调用参数温度、最大 Token 和超时模型调用质量不只看模型本身参数设置同样关键。Dify 中常用的模型参数包括参数作用调小的影响调大的影响推荐场景temperature控制回答随机性更稳定、更保守更多样、更发散抽取任务调低创意任务调高max tokens单次回答最大输出长度可能会截断占用更长推理时间按应用内容长度调整top_p候选词采样范围更确定更丰富与 temperature 配合使用timeout请求超时时间短模型容易误报失败长等待影响体验本地模型建议适当调大在文档抽取、数据清洗这类任务中temperature建议调低比如 0.1 到 0.3减少模型自由发挥。在文案生成、创意类应用中可以调高。注意 Dify 的模型供应商配置里可以设置默认参数单个应用也能覆盖默认值。4.2 知识库分块与检索参数知识库质量直接影响回答质量关键参数有三个分块长度决定知识片段的大小。重叠长度相邻片段之间共享的文本量降低切分截断关键信息的概率。Top K检索返回的片段数量。K 值过小会漏掉相关内容过大则会把无关内容塞进 Prompt干扰模型回答。检索模式也值得理解检索模式原理适用场景向量检索按语义相似度召回问题与文档用词不同但语义相近全文检索按关键词匹配召回文档包含明确专有名词或编号混合检索向量和全文结合后重排大多数生产场景推荐如果发现回答引用了不相关内容优先检查相似度阈值和 Top K。阈值设得太低无关片段也会被召回设得太高相关片段可能被过滤掉。建议从阈值 0.5 到 0.7 开始测试。4.3 通过工具、MCP 和插件扩展应用能力Dify 支持插件体系插件可以为 Agent 或工作流增加外部工具能力。这里重点说一下 MCP即 Model Context Protocol。它是一套让模型应用接入外部工具和数据的开放协议。添加本地 MCP 服务时在插件或工具管理页面选择 MCP填入服务地址例如http://localhost:8000/mcp如果是容器内联调地址需要写成宿主机可达地址不能直接用容器内的localhost。MCP 服务类型不同配置字段也会不同常见的有 SSE 和 HTTP 两类。插件安装失败的场景很常见通常与网络访问插件市场、插件版本和服务端版本不兼容有关。排查时先看插件管理页面和 api 容器日志确认是网络问题还是版本问题。4.4 团队协作与多租户使用学习环境通常只有管理员一个人使用生产场景则要考虑多人和多租户。Dify 社区版在大版本迭代中逐步开放团队协作、成员权限和多租户能力。比如社区版 1.10 系列中多租户成为社区用户讨论较多的方向。落地前要以官方 release notes 和当前源码实际支持的权限模型为准。使用团队协作时至少要注意管理员账号和普通成员账号分离。API Key 由管理员统一管理不要写死在代码仓库。知识库按团队隔离避免不同业务线互相读取文档。对操作行为做审计记录至少保留模型调用和发布的日志。5. 常见问题排查从日志到模型、插件和服务5.1 页面出现“内部服务器错误”现象登录后创建应用、保存知识库或调用模型时页面提示内部服务器错误。可能原因数据库迁移未完成。.env中SECRET_KEY配置异常。模型供应商配置错误。api 容器崩溃或磁盘空间不足。排查顺序docker compose ps docker compose logs api -f --tail200 docker compose logs worker -f --tail200先看容器是否存活再看 api 和 worker 的日志。日志中出现database、migration、connection refused等关键词时优先检查数据库容器和迁移状态。磁盘满也会导致容器无法写入可以执行docker system df查看镜像和卷占用。5.2 Ollama 模型处理超时现象调用本地 Ollama 模型时请求等待很久后报超时。原因通常有三个Base URL 配置成容器内localhost根本没有访问到宿主机 Ollama。模型体积大又没有 GPU推理速度慢。max tokens设置过大生成长文本耗时过长。排查方式ollama list ollama ps先确认模型已拉取并能正常对话。然后从宿主机测试 Ollama 接口curl http://localhost:11434/api/tags再确认 Dify 中填写的 Base URL 能否从容器内访问。如果用的是host.docker.internal在 Linux Docker Engine 中需要在 Compose 文件或 docker 参数中配置对应支持。推荐先用小模型验证链路再切换大模型不要一开始就追求高效果而忽略基础联通性。5.3 报错提示“模型不存在”现象应用中选择了某个模型运行时提示模型不存在或 model not found。原因Dify 模型供应商配置里填写的模型名和实际部署模型名不一致。Ollama 中还没 pull 该模型。在线模型供应商中模型 ID 写错。检查方式ollama list对比 Dify 模型配置里的名称和ollama list输出必须完全一致包括版本号后缀。在线模型则去供应商控制台查看模型 ID。这里最容易踩的坑是复制了教程里的模型名但本地实际拉取的是另一个版本。5.4 插件安装失败与知识库长时间“同步中”插件安装失败时先确认网络能否访问 Dify 插件市场。如果不能可以考虑离线安装方式下载插件包后手动上传。同时检查插件版本和 Dify 服务端版本是否兼容版本跨度太大容易出现接口不匹配。知识库文档一直处于“同步中”状态核心原因通常是嵌入模型不可用文档无法完成向量化。worker 容器没有正常启动。文件本身解析异常。检查 worker 日志docker compose logs worker -f --tail200如果日志中有嵌入模型调用失败回到模型供应商页面修复嵌入模型配置。修复后可以重新同步知识库而不是反复新建知识库。5.5 常见问题速查表问题现象常见原因检查方式处理建议页面内部服务器错误api 崩溃、数据库异常、配置错误docker compose ps、api 日志修复配置或重启 api 容器Ollama 调用超时Base URL 错误、无 GPU、模型过大curl http://localhost:11434/api/tags、ollama list修正地址、换小模型、调大超时模型不存在模型名不一致、未拉取ollama list、供应商控制台统一模型 ID插件安装失败网络不通、版本不兼容插件页日志、api 日志离线安装或升级服务端知识库一直同步中嵌入模型不可用、worker 未启动worker 日志修复嵌入模型后重新同步6. 从学习环境到生产环境敏捷之外还要有工程约束6.1 学习环境与生产环境的差异本地用 Docker Compose 一次起所有服务优点是快缺点是组件都跑在单机容器里不适合直接照搬生产。差异如下维度学习环境生产环境数据库内置 PostgreSQL数据在容器卷中建议使用托管数据库定期备份Redis内置 Redis建议独立 Redis 实例密钥默认或随机生成严格保管使用密钥管理系统HTTPS不配置必须配置域名和证书日志看容器日志接入集中日志平台监控无对 api、worker、模型调用做监控告警部署方式单机 Compose负载均衡、多副本、滚动发布权限管理员单账号多租户、角色隔离、审计生产环境还要规划回滚方案。Dify 应用可以导出 DSL 文件这是很重要的资产。每次发布前导出当前版本 DSL异常时可以快速恢复。6.2 上线前检查清单以下清单适用于把 Dify 应用从开发环境推向生产Dify 版本和 Docker 版本已确认且与官方 release notes 匹配。.env已修改默认SECRET_KEY和初始密码。模型供应商配置完整本地模型和在线模型均已验证。知识库文档已完成同步检索效果经多组测试问题验证。Prompt 中已设置边界回复例如“无法回答时不要编造”。工作流每个分支都有结束节点调试时覆盖正常和异常输入。API Key 已更换为生产 Key未提交到代码仓库。数据库和向量库已配置备份策略。日志和监控已接入模型调用超时和错误率有告警。已导出应用 DSL并记录了版本变更内容。每一条都对应一个具体的失败场景。比如不换默认密码部署到公网后很可能被扫描器直接登录不配备份数据库损坏后应用数据无法恢复不导出 DSL误改配置后无法快速回退。6.3 与其他平台的选型以及二次开发方向除了 Dify市面上还有其他低代码 AI 应用平台。底层逻辑相似都是把模型调用、知识库、工作流、工具调用组合起来差异主要体现在数据归属、可移植性和定制深度上。托管平台适合快速验证和轻量业务但数据在平台侧迁移成本高自托管方案由团队自己维护基础设施灵活度高适合对数据安全和二次开发有要求的团队。Dify 社区版可以二次开发。项目是前后端分离结构前端构建在web目录后端在api目录。二次开发前先确认主分支版本与部署镜像版本一致否则容易出现前后端接口对不上。自己构建镜像时建议在独立分支维护改动避免直接跟随主分支导致升级冲突。最终建议只有一条先让一个最小应用完整跑通从部署、知识库、对话、调试到 API 发布再逐步叠加复杂功能。AI 应用开发的核心不在平台功能多少而在于你是否能够快速验证想法、快速发现问题、快速修正。Dify 只是把这条敏捷链路的产品面补齐了真正决定效果的是你对 Prompt、知识库和模型参数的理解。