在RSG 敏捷嘉年华大会 2026 上海站的分享中Dify 创始人张路宇老师带来了关于 AI 原生应用开发与敏捷方法论深度融合的实践思考。对于很多正在使用 Dify 搭建企业级智能应用的开发者来说这不仅仅是一场技术演讲更是一次对“AI 时代软件研发流程”的重新审视。本文基于这次大会的行业背景结合 Dify 社区版的实际使用场景系统梳理从平台概念、本地部署、工作流搭建到知识库管理的完整实战路径。无论你是刚接触 Dify 的新手还是已经在企业内落地智能体的开发者都能从中找到可以直接上手的配置方案与排错思路。1. 背景与核心概念1.1 Dify 是什么Dify 是一个开源的大语言模型LLM应用开发平台它的定位非常明确让开发者用更少的代码完成 AI 应用的搭建、调试和运营。在过去开发一个带知识库、带工具调用、带多轮对话记忆的 AI 应用往往需要自己处理模型 API 对接、向量数据库选型、Prompt 调优、上下文管理、日志追踪等一系列工程问题。Dify 把这些问题统一抽象成了可视化的工作台开发者只需要在界面上拖拽组件、编排工作流、配置模型参数就能快速产出可用的 LLM 应用。从技术架构上看Dify 的核心能力可以拆成几个部分应用编排支持聊天助手、Agent、文本生成、工作流四种应用形态。知识库内置文档解析、分段清洗、向量化存储流程支持多种检索策略。模型管理统一接入 OpenAI、Azure OpenAI、Anthropic、通义千问、DeepSeek 以及本地部署的 Ollama 等模型服务。工具调用支持内置工具、自定义 API 工具以及 MCPModel Context Protocol服务的接入。可观测性提供完整的日志、标注、监控能力帮助开发者在生产环境持续优化。Dify 社区版是开源项目代码托管在 GitHub遵循 Apache 2.0 协议可以免费用于商业场景。如果团队需要多租户隔离、SSO 登录、更多审计能力可以关注商业版和企业版。1.2 敏捷开发与 AI 应用开发的关系RSG 是 Regional Scrum Gathering 的缩写是全球 Scrum 社区的区域性盛会。敏捷开发Agile Development强调迭代、快速反馈、持续交付和跨职能协作。传统软件工程中的“预测型”计划驱动流程往往在需求明确、变更较少的大型项目中更适用而敏捷型流程则在需求不确定、市场变化快的场景下更具优势。AI 应用开发恰恰是典型的敏捷场景。原因是多方面的模型能力在快速迭代半年前能实现的效果和今天可能完全不同方案必须持续调整。用户需求不确定知识库的覆盖范围、问答效果、Agent 工具链的合理性都需要通过真实用户反馈来修正。评估困难传统的单元测试很难覆盖大模型输出的语义正确性必须依赖灰度发布、A/B 测试和人工反馈。张路宇老师在大会上的分享正是围绕“如何用敏捷的方式做 AI 应用”展开强调 Dify 在其中的作用是降低试错成本一个工作流从修改到上线可能只需要几分钟团队可以把精力聚焦在 Prompt 优化、知识库质量和用户反馈闭环上而不是陷入繁琐的工程编码。1.3 为什么选择本地部署 Dify在实际项目中不少团队会优先选择 Dify 云服务开箱即用。但也有一些场景必须考虑本地部署数据敏感企业内部文档、客户数据不能上传到第三方云平台。合规要求公司有明确的数据出境或数据隔离要求。模型私有化团队已经通过 Ollama、vLLM 等方式部署了本地模型希望内网打通。二次开发需要修改 Dify 源码定制自己的功能模块。本地部署 Dify 社区版并不复杂核心依赖是 Docker 和 Docker Compose。接下来我们完整走一遍从环境准备到服务启动的流程。2. 环境准备与版本说明2.1 部署环境要求Dify 社区版官方推荐使用 Docker Compose 方式部署。这里用一个常见的 Linux 服务器环境作为示例Windows 和 macOS 下的操作思路是类似的。项目推荐配置说明操作系统Ubuntu 20.04 / 22.04其他 Linux 发行版也可以核心是 Docker 支持CPU2 核及以上实际消耗主要来自模型推理和 Embedding内存4GB 以上如果本机还要跑 Ollama 模型建议 16GB 以上磁盘50GB 以上镜像、日志、向量库数据都会占用空间Docker20.10.14 及以上新版本 Dify 对 Docker 版本有要求Docker Composev2 系列建议使用docker compose插件形式如果你使用 Dify 较新版本还需要关注 Docker Compose 的版本兼容问题。文章示例中的地址、端口和目录结构为通用配置实际操作时请以官方文档和你的实际环境为准。2.2 安装 Docker在 Linux 上安装 Docker 可以按下面的命令操作。以 Ubuntu 为例# 更新 apt 软件包索引 sudo apt update # 安装依赖包允许 apt 通过 HTTPS 使用仓库 sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加稳定版仓库 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 再次更新并安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin安装完成后启动 Docker 服务并设置为开机自启sudo systemctl start docker sudo systemctl enable docker验证是否安装成功docker --version docker compose version看到版本号输出就说明 Docker 环境已经就绪。2.3 获取 Dify 代码Dify 的官方仓库地址在 GitHub。部署时通常不建议直接下载代码压缩包而是通过git clone拉取指定版本方便后续升级和查看版本说明。# 克隆 Dify 源码仓库 git clone https://github.com/langgenius/dify.git # 切换到稳定版本分支这里以 1.x 为例 cd dify git checkout 1.10.0如果你不需要查看完整 Git 历史也可以使用--depth 1参数做浅克隆减少下载时间。2.4 Docker Compose 启动Dify 源码根目录下包含docker文件夹里面有完整的docker-compose.yaml和环境变量示例文件。进入该目录后复制环境变量文件cd dify/docker cp .env.example .env然后启动服务docker compose up -d第一次启动会拉取多个镜像包括 API 服务、Worker、Web 前端、PostgreSQL、Redis、Weaviate 或 Qdrant 向量数据库等耗时取决于网络环境通常在几分钟到十几分钟之间。启动完成后查看容器状态docker compose ps当所有容器的状态都是Up时浏览器访问http://服务器IP/即可进入 Dify 初始化界面。需要说明的是不同版本默认使用的向量数据库可能不同Dify 社区版在早期常用 Weaviate新版本也支持 Qdrant、pgvector 等多种存储。.env文件里可以通过环境变量切换向量库类型具体配置项以当前版本源码中的注释为准。2.5 初始化管理员账号首次访问 Dify 页面时系统会要求设置管理员邮箱和密码。这个账号拥有平台最高权限负责后续的用户管理、模型配置和应用发布。初始化完成后第一件事是进入“设置”页面在“模型供应商”中配置你需要的模型服务商。如果使用 Ollama 本地模型需要填写 Ollama 服务的 API 地址比如http://host.docker.internal:11434在 Docker 容器中访问宿主机地址时要注意网络模式。3. 核心功能拆解应用、工作流与知识库在进入实战之前先把 Dify 的几个核心概念搞清楚。很多新手一开始就急着建应用结果在“应用类型”“知识库分段”“工作流节点”之间来回切换反而容易绕晕。3.1 四种应用形态Dify 支持创建四种类型的应用聊天助手Chatbot面向对话场景支持多轮上下文、变量、文件上传是构建客服、助手类应用最常见的选择。文本生成Text Generator面向单轮生成任务比如写摘要、翻译、扩写适合不需要记忆上下文的调用场景。Agent具备“自主决策”能力的聊天应用可以理解用户意图调用工具来完成多步任务比如查天气、查数据库、调用业务 API。工作流Workflow通过编排多个节点来定义一个确定性的处理流程适合对输出稳定性要求较高的场景比如审批流程、表单解析、定时生成报表。从敏捷的角度看工作流适合流程确定的业务Agent 适合边界无法 100% 确定的长尾任务。在真实项目中这两者并不矛盾很多企业先用 Agent 做探索等某个流程足够稳定后再固化成 Workflow。3.2 知识库的工作方式知识库是 Dify 中最常用于企业落地的模块。它解决的问题是让模型能回答私有化、非公开的知识而不需要重新训练模型。知识库的处理链条是文档导入支持 PDF、Word、Markdown、TXT 等格式。分段Chunking按一定规则把长文档切成小块便于检索。清洗去掉页眉页脚、异常字符、重复内容。向量化Embedding把文本块转为高维向量。存储写入向量数据库。检索用户提问时根据问题向量相似度召回相关文本片段。增强生成RAG把召回的文本片段作为上下文拼进 Prompt让模型结合知识库内容回答。理解这条链路非常重要因为很多“回答不准确”的问题根因并不在模型而在于分段策略不合理或检索召回不到有效内容。3.3 工作流的核心节点Dify 工作流采用节点式编排常用节点包括节点类型作用使用场景开始定义工作流入口参数每个工作流都有LLM调用大模型生成文本核心处理节点知识检索从知识库中召回内容RAG 应用必备问题分类根据分类器判断用户意图多路由场景条件分支按条件走向不同分支流程分线代码执行运行 Python/Node.js 代码复杂逻辑处理HTTP 请求调用外部系统 API集成 ERP、CRM模板转换将变量拼接成文本Prompt 预处理参数提取用模型抽取结构化数据表单、工单场景结束定义输出内容每个工作流都有关于节点选择的思路能确定的逻辑用代码节点和条件分支能靠模型理解的内容用 LLM 节点需要外部数据的用 HTTP 节点。不要把整个业务的判断逻辑全部交给模型也不要写出大量“硬核”代码来绕过模型最好的方案是两者结合。4. 实战案例搭建企业制度问答机器人为了让整个过程更具体这里模拟一个真实场景某企业需要把内部规章制度整理成一个问答机器人员工可以随时提问“年假怎么休”“报销流程是什么”机器人基于知识库进行回答。4.1 准备知识文档先将企业制度文档整理为 Markdown 或 PDF 格式。示例文档内容如下# 员工年假管理制度 ## 第一条 适用范围 本制度适用于公司全体正式员工。 ## 第二条 年假天数 员工累计工作满1年不满10年的年休假5天 满10年不满20年的年休假10天 满20年的年休假15天。 ## 第三条 申请流程 员工需提前3个工作日通过 OA 系统提交年假申请 经直属上级审批后生效。这里建议用 Markdown 格式因为 Dify 的分段器对结构化文本的解析效果通常更好。4.2 创建知识库在 Dify 控制台左侧导航中点击“知识库”进入列表页然后点击“创建知识库”。填写知识库名称比如“员工制度库”选择索引方式。索引方式建议使用高质量模式它会调用 Embedding 模型对文本进行向量化检索效果更好。接下来上传刚才准备的文件Dify 会进入分段流程。分段长度和重叠长度是影响检索效果的关键参数分段长度Segment Length每个块的字符数默认值通常适合通用问答。分段重叠Segment Overlap相邻块之间的重叠字符数适当增大可以避免知识点被切断。比如制度文档里的“满1年不满10年”和“满10年不满20年”这些不同档位如果在分段时恰好被不同文本块截开检索时可能漏掉其中一部分导致回答不完整。此时可以把分段重叠设置为 20~50 个字符减少上下文断裂的问题。保存并完成分段后可以点击文档名在分段列表里检查每一段的内容是否完整。如果发现某些段落被不合理切断可以手动调整分段规则后重新处理。4.3 创建聊天助手应用回到“应用”页面点击“创建应用”选择“聊天助手”。在“编排”页面里需要做以下几步第一步选择模型。在右上角选择已经配置好的模型比如 GPT-4o、DeepSeek、Qwen 或本地 Ollama 模型。这里用本地模型时要注意推理速度如果显存不够建议选择较小的量化模型。第二步编写系统提示词System Prompt。一个好的系统提示词是问答质量的基础。示例你叫“小制”是企业内部制度问答助手。 你负责根据知识库内容回答员工关于人事、行政、财务等制度的问题。 回答要求 1. 优先使用知识库内容回答不要编造不存在的制度条款。 2. 如果知识库中没有相关信息明确告知员工“暂时无法从制度文档中找到答案”并建议其咨询 HR。 3. 回答时使用简洁、清晰的中文。第三步添加上下文。在对话框中把“知识库”上下文关联到上一步创建的“员工制度库”并设置召回数量的上限。通常情况下召回 3~5 个文本块即可满足回答要求召回数量过多反而会引入噪音。第四步开启引用和标注功能。开启“引用”后用户能直接看到回答依据了哪些文档片段这在企业内部场景里非常重要既能增加可信度也便于后续审计。4.4 调试与发布在右侧预览窗口中输入“年假怎么申请”观察模型回答是否准确。如果回答不理想可以按以下顺序排查知识库分段是否合理。系统提示词是否把规则说清楚。召回数量是否足够。Embedding 模型是否合适。调试完成后点击“发布”。在“访问 API”菜单中可以拿到应用的 API 密钥和调用地址。后端程序可以通过 Dify 的 Service API 把问答能力集成到企业微信、钉钉、飞书或自研系统中。一个简单的 Python 调用示例import requests # Dify 应用 API 地址和密钥 api_url https://your-dify-domain/v1/chat-messages api_key app-xxxxxxxxxxxxxxxx headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { inputs: {}, query: 年假有几天, response_mode: blocking, user: employee-001, } response requests.post(api_url, jsonpayload, headersheaders, timeout30) print(response.json())这里的chat-messages接口采用流式或阻塞两种响应模式。开发测试时使用blocking更直观生产环境为了用户体验建议使用streaming模式做打字机效果。4.5 知识库的持续维护问答机器人上线只是开始日常维护才是重点。建议运营人员定期查看“日志与标注”把新增的员工高频问题加入知识库把回答错误的记录打上标签持续优化提示词和文档内容。这其实就是张路宇老师在大会中提到的“敏捷反馈闭环”每一次真实问答都是下一次迭代的输入。5. 进阶实战工作流与 MCP 服务集成当企业不满足于单纯的“知识库问答”而是需要让 AI 真正连接业务系统时工作流和工具调用会发挥更大价值。5.1 场景售后服务工单自动分类假设企业有一个售后工单系统客户提交的工单内容杂乱需要先判断工单类型退换货、维修、发票、咨询再提取关键信息订单号、产品型号、问题描述最后把结构化数据写入工单系统。这个场景非常适合用 Dify 工作流实现。流程设计如下开始节点接收原始工单文本。参数提取节点调用模型从文本中提取订单号、产品型号。问题分类节点调用模型判断工单类型。条件分支节点根据分类结果走向不同处理分支。HTTP 请求节点将结构化数据写入工单系统 API。结束节点返回处理结果。在工作流的关键节点中参数提取是一个容易被忽略但极好用的能力。它本质上用模型做了一次“结构化解析”把非结构化文本转换为 JSON。下面是一个参数提取节点的配置示意核心是告诉模型要抽取哪些字段、字段类型是什么。{ 订单号: { type: string, description: 工单中的订单号通常以字母 OR 开头 }, 产品型号: { type: string, description: 产品型号例如 iPhone 15 Pro }, 问题描述: { type: string, description: 用户反馈的问题内容 } }这样后续的 HTTP 请求节点就能直接使用{{节点名.订单号}}这类变量引用避免写复杂的正则表达式去匹配。5.2 MCP 服务集成MCPModel Context Protocol是当前 AI 工具调用领域的重要协议它相当于给 AI 应用提供了一套标准化的“外设接口”。通过 MCPDify Agent 可以方便地连接外部数据源和工具服务而不需要针对每个工具单独写一套自定义接入逻辑。在 Dify 中配置 MCP 服务时需要进入 Agent 应用的“工具”配置页找到 MCP 相关选项填写 MCP 服务的地址和鉴权信息。配置完成后Agent 会在对话中按需调用这些工具。一个常见场景是通过 MCP 接入企业内部的数据查询服务让 AI 助手查询订单状态、库存数量、物流轨迹等实时数据。相比传统 API 集成MCP 的优势在于工具描述标准化模型可以更准确地理解“什么时候调用哪个工具”。具体配置方法会随 Dify 版本变化而有所不同配置前建议先确认当前版本的 MCP 功能入口并将 MCP 服务部署在可控的内网环境中。5.3 Agent 策略与插件在 Dify 中Agent 支持不同的推理策略常见的有 Function Calling 和 ReAct 等。不同的策略适合不同场景Function Calling模型先判断调用哪个函数再生成函数参数适合结构化工具调用。ReAct把推理和行动交错进行适合需要复杂思考的任务但消耗的 Token 更多。实际项目中建议优先使用 Function Calling。如果模型本身不支持 Function Calling再考虑 ReAct 等替代方案。插件的安装和更新是另一个常见需求。Dify 社区有插件 Marketplace可以安装第三方工具和工作流扩展。遇到插件安装失败时通常与网络环境或版本兼容有关可以先查看插件日志定位具体原因。Dify 也支持本地安装插件便于企业内网离线环境使用。6. 常见问题与排查思路Dify 本地部署和使用过程中社区中常见的几类问题如下。问题现象常见原因解决思路启动后页面无法访问Docker 容器未完全启动或端口被占用执行docker compose logs -f查看日志确认 80/443 端口未被占用模型调用超时模型服务地址不通或本地模型推理过慢检查模型供应商连通性Ollama 场景重点排查宿主机地址知识库回答不准确分段策略不合理召回数量偏少调整分段重叠长度增加召回数量检查文档清洗质量应用出现内部服务器错误上游 API 返回异常或配置项冲突查看 API 容器日志定位报错堆栈检查密钥与环境变量插件安装失败网络无法访问插件仓库尝试配置镜像源、离线安装或手动下载插件包知识库同步数据卡住向量数据库写入异常或 Embedding 接口超时查看 Worker 容器日志重启知识库处理任务多租户权限不清晰社区版没有完整多租户能力确认需求规模考虑部署企业版或用独立数据库隔离项目针对最常见的Dify 中的 Ollama 模型处理超时问题这里展开说一下。Ollama 部署在本地后Dify 容器访问宿主机时不能直接用localhost而需要使用 Docker 网桥地址。Linux 下可以执行ip addr show docker0查看宿主机在 Docker 网络中的 IP通常是172.17.0.1。在 Dify 模型供应商配置中填入http://172.17.0.1:11434即可解决。如果使用的是较新 Docker Desktop 版本的 Windows/macOS则可以使用host.docker.internal作为宿主机地址。另外模型推理速度本身也可能成为瓶颈。如果是 7B 或 13B 参数模型建议在普通 CPU 环境或有足够显存的 GPU 上单独部署尽量避免在 Dify 容器所在机器上同时承担高并发推理。再来看Dify 出现内部服务器错误的情况。这个问题需要先区分是 Web 前端报错还是 API 接口报错。可以打开浏览器 F12 开发者工具查看 Network 面板中请求的响应状态码和错误信息然后到部署目录执行docker compose logs api --tail 200查看 API 容器的最近日志。常见的内部错误包括数据库迁移未完成、模型配置缺失、环境变量变更后没有重启容器。遇到这类问题时先检查.env文件是否有语法错误再执行docker compose down docker compose up -d重建容器。7. 最佳实践与工程建议7.1 用敏捷迭代方式管理 AI 应用AI 应用和传统软件的显著区别是它的“代码”不只是业务逻辑还包括模型选择、Prompt、知识库和评估方式。因此我建议团队在 AI 应用开发中采用“小步快跑”的敏捷模式两周一个迭代每次迭代只针对一到两个用户反馈最集中的场景做优化。每次 Prompt 修改都要记录版本可以用 Dify 的版本管理功能或者把 Prompt 保存到 Git 仓库做 diff。建立评估集定期用固定问题集回归测试应用效果避免一个优化导致另一个场景退化。7.2 生产环境部署注意事项如果只是本地学习使用默认配置即可。但进入生产环境必须注意以下几点数据库备份PostgreSQL 和向量数据库中存有应用配置和知识库数据建议每天定期备份。备份前最好先停掉写入操作或使用数据库事务一致性快照。密钥管理Dify 的.env文件包含大量密钥例如向量库密码、模型 API Key。不要把.env文件提交到 Git 仓库仓库中应有.env.example模板实际密钥通过部署系统的环境变量注入。资源限制为 Docker 容器设置内存限制避免某个进程把整个服务器资源耗尽。HTTPS生产环境务必使用 Nginx 反向代理并为域名配置 HTTPS 证书保证 API 调用过程中的数据安全。升级前先做快照Dify 版本更新可能涉及数据库结构变化升级前必须备份数据库并阅读官方升级说明。7.3 知识库的长期维护机制知识库不是“一次导入就结束”。很多企业应用上线后效果越来越差就是因为文档更新了但知识库没有同步知识库更新了但没有重新向量化。推荐做法是建立文档更新流程当源文档变更时通知运营人员重新上传。设置文档责任人每个知识库至少指定一名维护负责人。记录知识库变更日志记录每次新增、删除、更新操作便于回滚。定期清理噪音数据删除过期、重复或内容质量差的文档片段。7.4 敏感信息与权限边界在企业级应用中必须谨慎设计 AI 助手的权限边界。Dify 生态中可以通过应用级密钥来控制不同系统的调用权限在多团队场景下要合理规划空间或项目隔离避免 A 部门的数据被 B 部门调用。同时要注意知识库中如果有员工薪资、身份证号、银行账号等高敏信息最好不要直接加入知识库。如果业务确实需要应通过脱敏、掩码或单独的应用权限管理来控制访问范围。任何情况下向用户展示回答时都应提供出处引用方便追溯和审计。8. 总结与学习路线通过 RSG 敏捷嘉年华大会 2026 上海站这个背景我们回顾了 Dify 创始人张路宇老师在 AI 应用开发与敏捷实践结合上的分享方向并系统完成了从概念到实战的梳理。本文重点内容包括Dify 平台的核心能力与本地部署流程。知识库问答应用的完整搭建过程。工作流编排、参数提取与 MCP 服务集成的进阶思路。常见报错现象的排查方法。生产环境落地的工程最佳实践。如果你想继续深入建议按下面的顺序学习先熟练使用 Dify 可视化界面创建“聊天助手”理解 Prompt、上下文、知识库三者的配合。再到“工作流”中复现一个小型业务场景比如工单分类、内容摘要、数据清洗。然后学习 Agent 和工具调用尝试接入现有业务 API。最后学习 Docker Compose 部署细节、数据库备份和监控告警把应用正式发布到测试环境。一套可用的 Dify 项目并不复杂难的是在真实场景中持续优化。它能帮你把“模型能力”快速变成“业务能力”而你和团队的快速迭代能力才是把 AI 落地的核心竞争力。如果这篇文章对你有帮助欢迎收藏备用。也欢迎在评论区聊聊你在部署 Dify、构建知识库或调试工作流时遇到的问题一起交流解决思路。