“Dify 创始人张路宇出席 RSG 敏捷嘉年华大会 2026 上海”这条消息放在两年前我会觉得只是普通活动通稿但今天再看它其实是一个值得玩味的行业信号。Dify 在 AI 应用开发圈子里几乎成了“开源 Agent 平台”的代名词。本地部署、可视化工作流、知识库 RAG、多租户、MCP 插件……大量想做 AI 应用的开发者、产品经理和企业架构师都围绕这个词组展开讨论。而 RSG 敏捷嘉年华是敏捷开发领域的老牌大会主题一贯是 Scrum、看板、需求拆分、团队自组织。一边是 AI 工程一边是软件开发过程管理看起来一个偏技术工具一个偏管理方法。但 Dify 创始人出现在敏捷大会会场说明行业开始认真面对一个问题AI 应用的交付流程到底应该怎么组织本文不打算写成会议新闻稿。我想从 Dify 的工程能力出发拆解它和敏捷开发之间的深层关系并给出一条从本地部署到知识库问答 Agent 的最小实践路径。读完这篇文章你可以得到三样东西理解 Dify 到底解决了什么问题——它不是简单意义上的“低代码 AI 平台”而是让 AI 应用交付进入短迭代、可验证、可回滚的敏捷轨道。掌握在 Docker 环境里本地部署 Dify 的完整流程和关键坑点。跑通一个基于知识库的问答 Agent并知道如何通过 API 接入现有业务系统。1. 从 RSG 敏捷嘉年华说起Dify 与敏捷为什么会同台RSG 是 Regional Scrum Gathering 的缩写是全球敏捷社区在各大城市定期举办的技术盛会。2026 年落地上海Dify 创始人张路宇出席分享这件事从公开信息看有几个明确指向第一AI 应用开发的工程化问题正在从“有没有工具”进入“怎么协作、怎么迭代”的阶段。早期大家关心的是“模型能不能回答”后来关心“怎么把 Prompt 写得更准”现在越来越多人关心的是一个 Agent 应用从想法到上线团队里谁来编排流程、谁来维护知识库、谁来验证效果、出了问题怎么回滚。第二敏捷社区开始把 AI 应用当成一种新的交付对象。过去敏捷讲的是需求拆解、迭代冲刺、持续反馈。但 AI 应用有一个传统软件没有的变量模型的输出是不确定的。同一个 Prompt换一个模型、调一个参数、改一段上下文效果可能完全不同。这种不确定性恰恰是敏捷方法最擅长处理的场景。第三Dify 团队需要更多的“企业级交付案例”来反推产品方向。Dify 社区版从单机部署到多租户、从知识库到工作流编排、从插件系统到 MCP 支持每一步变化都来自真实落地场景。而 RSG 敏捷嘉年华的参会者大多是团队负责人和架构师正是企业级 AI 应用落地的决策者。所以这场分享不是一次简单的站台而是把“AI 应用开发该如何敏捷迭代”这个话题正式摆到了软件工程社区面前。2. Dify 是什么一个 AI 应用交付平台的完整拆解2.1 核心概念先纠正一个常见误解很多人把 Dify 直接理解为“低代码聊天机器人平台”。这个说法不准确Dify 覆盖的能力比“聊天机器人”宽得多。从开发视角看Dify 是一个位于“模型 API”和“业务系统”之间的应用交付层。它把大模型应用开发中大量重复、容易出错的基础工作标准化让开发者把精力集中在业务逻辑上。它的核心概念包括概念通俗解释没有它时需要做什么Agent能自主拆解任务、调用工具的智能体自己写循环、维护上下文、处理工具调用Workflow可视化的节点编排把 Prompt、模型、工具、分支组合成可运行流水线用代码硬编码流程改一次要发一次版知识库通过 RAG 方式给模型补充私有知识自己实现文档切片、向量化、检索、重排模型管理统一接入 OpenAI、Ollama、Azure、vLLM 等模型服务每个模型一套 SDK切换成本高插件体系标准化的工具接入机制支持 MCP 等协议为每个新工具写胶水代码可观测性日志、追踪、标注、评测自己埋点开发和调试效率低2.2 传统开发方式与 Dify 方式对比假设你要做一个“企业内部文档问答助手”。传统方式下你需要写后端服务对接大模型 API。处理对话上下文、会话状态。自己实现文档解析、切片、Embedding、向量检索。写前端聊天页面。处理 Prompt 版本管理、模型切换、异常重试。把服务部署上线再搭一套日志和监控。这个流程一个经验丰富的后端团队可能也要一两周才能跑通。而且 Prompt 稍微一改整个链路都要重新测试发布。Dify 方式则是上传文档到知识库自动完成切片和索引。选择一个模型供应商配置 API Key。拖拽一个 Chatflow开始节点 → 知识检索节点 → LLM 节点 → 回答节点。在调试界面里直接测试效果满意后一键发布。生成 API 密钥业务系统通过标准 API 接入。从一周缩短到一小时这是数量级的变化。但这里的核心判断是Dify 并不是让开发者变懒而是把重复劳动从“写代码”变成“配置和编排”把不确定性集中在“效果验证”上。这也是它能和敏捷方法产生化学反应的根本原因。3. 为什么 AI 应用开发天然需要敏捷方法3.1 预测型与敏捷型的差异软件开发方法论里有一组经典对比预测型和敏捷型。预测型流程假设需求在项目开始时可以定义得足够清楚然后按照“需求 → 设计 → 开发 → 测试 → 交付”的顺序推进。这种方式适合需求稳定、技术路径明确的场景比如建设一个 CRM 系统、改造一套订单流程。敏捷型流程则承认需求会变化甚至承认我们一开始无法把需求定义完整。它用短迭代、可交付增量、持续反馈来对抗不确定性。AI 应用开发更像哪一种答案是敏捷型。原因很直接你无法准确预测一个 Prompt 写出来后的效果。你无法保证一个模型在某个特定业务域的表现。你无法在需求阶段就告诉团队“这个 Agent 最终会长什么样”。知识库内容会变模型版本会变业务问题也会变。这意味着AI 应用开发必须采用短周期的“假设 → 实现 → 验证 → 调整”循环。一次 Prompt 调整、一次知识库更新、一次模型切换都需要快速验证并决定保留还是回滚。3.2 Dify 如何支撑敏捷迭代Dify 的很多设计本质上都是为这个循环服务的可视化工作流让产品经理、业务分析师也能参与编排跨职能协作门槛降低。以前一个流程改动要等开发排期现在在编辑器里拖拽一个节点就能试。一键发布和多版本能力让“发布-回滚”变得轻量。改坏了 Prompt可以快速回到上一个可用版本。知识库支持增量更新和重建索引。文档内容变化后不需要重新开发只需要重新处理相关文件。完整的调试和日志追踪让反馈闭环变短。每一次用户对话、每一个工作流节点执行记录都可以用来判断问题出在检索、提示词还是模型推理。插件体系把工具接入标准化。新增一个 HTTP API、一个数据库查询、一个 MCP 服务不需要动核心代码。所以我的判断是Dify 本质上是一套面向 LLM 应用的敏捷交付基础设施。它不直接教你什么是 Scrum但它把“快速试错、持续交付、及时回滚”的能力做进了工具本身。4. 环境准备与 Dify 本地部署4.1 环境依赖Dify 官方推荐用 Docker Compose 方式部署这是最稳妥、升级路径最清晰的方式。前置条件一台 Linux 服务器或安装了 Docker Desktop 的 Windows / macOS 电脑。Docker 和 Docker Compose 环境Docker 版本建议不低于 20.10具体以官方 release 要求为准。内存建议至少 8GB如果还要本地跑 Ollama 模型建议 16GB 以上。一个可用的模型服务OpenAI 兼容 API、Ollama 本地模型、Azure OpenAI、vLLM 等均可。本地开发测试时最省事的方式是先用 Ollama 拉一个小模型例如 qwen2.5:7b 或 llama3.1:8b先把链路跑通再切换到更强大的模型。4.2 Docker Compose 部署步骤首先克隆代码并进入 docker 目录git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d等待容器启动完成后检查状态docker compose ps看到 api、worker、web、db、redis、sandbox 等容器处于 running 状态就说明基础服务正常。然后访问http://localhost本地或http://服务器IP远程进入 Dify 初始化界面。首次使用需要设置管理员账号。如果要接入 Ollama 本地模型需要确保容器能访问宿主机。在 Linux 上通常通过host.docker.internal或宿主局域网 IP在 Docker Desktop 上一般直接用host.docker.internal。4.3 版本升级与回滚Dify 版本迭代很快社区版 1.10 以后还加入了多租户能力升级时要格外谨慎。建议流程docker compose down git pull origin main docker compose pull docker compose up -d升级前必须备份数据库和.env文件。Dify 的数据主要存在 docker volume 中可以直接备份 volume 目录也可以在升级前把关键业务数据导出。生产环境更新前建议先在测试环境完整验证一轮再对生产环境执行更新。这里真正容易踩的坑是直接删掉 volume 重启。docker compose down -v会把数据库、向量索引全部清掉一旦误操作很难恢复。如果只是想重启服务使用docker compose restart就够了。5. 用 Dify 搭建一个知识库问答 Agent5.1 场景选择知识库问答是 Dify 最经典、也最容易跑通的应用场景。企业内部文档问答、产品使用指南、客服话术查询、合规条款检索都属于这一类。我们以一个“企业行政制度问答助手”为例子员工可以问“请假流程怎么申请”“差旅报销标准是什么”Agent 根据制度文档回答并标注引用来源。5.2 创建知识库登录 Dify 控制台进入“知识库”页面点击创建知识库上传几份 Markdown 或 PDF 文档。创建时需要关心三个选项分段模式一般选“通用分段”如果文档结构复杂、章节层级多可以选“父子分段”让检索结果更精细。分段长度默认值适合大多数场景但如果检索结果不准确可以调小分段或者按标题层级分开。Embedding 模型选择一个你已经配置好的模型。中文场景下建议优先测试百炼、通义、OpenAI 等对中文支持较好的 embedding 模型。保存后系统会自动处理文档并建立索引。处理完成后在“召回测试”里输入一个问题可以验证知识库能否检索到相关内容。这一步非常关键如果召回测试都没有结果后面 Agent 一定答不好。5.3 创建 Chatflow 工作流返回“应用”页面新建一个 Chatflow 类型应用。Chatflow 比简单的聊天助手更适合需要调试的场景因为可以看到每个节点的输入输出。一个最小可用的知识库问答工作流包含四个节点开始节点接收用户问题。知识检索节点选择知识库设置 TopK 为 3Score 阈值设为 0.3 左右。LLM 节点基于检索结果生成回答。回答节点把结果返回给用户。LLM 节点的提示词模板可以参考你是企业行政制度问答助手。 请只根据知识库检索结果回答用户问题不要编造事实。 回答要求 1. 如果检索结果与问题无关明确回答“知识库中暂未找到相关内容”。 2. 引用知识库内容时在句末用 [来源N] 标注。 3. 回答语言与用户保持一致。 用户问题 {{query}} 知识库检索结果 {{context}}注意{{query}}和{{context}}是变量占位符的示意写法。不同 Dify 版本中工作流节点的变量名可能不同建议在编辑器的变量选择器里直接引用“知识检索”节点的输出字段。完成编排后先点击“预览”测试输入“请假流程怎么申请”观察知识检索节点是否返回了相关片段再看 LLM 节点的回答是否使用了检索内容。5.4 通过 API 接入业务系统调试满意后点击“发布”。发布后左侧会出现“API 访问”入口创建一个 API 密钥。业务系统可以通过标准接口调用这个 Agentcurl -X POST http://your-server/v1/chat-messages \ -H Authorization: Bearer app-XXXXXXXX \ -H Content-Type: application/json \ -d { inputs: {}, query: 请假流程怎么申请, response_mode: blocking, conversation_id: }app-XXXXXXXX换成你在 Dify 后台生成的密钥your-server换成你的服务地址。返回结果会包含answer字段和conversation_id后续对话带着同一个conversation_id就可以保持上下文。6. 运行结果与效果验证6.1 调试界面验证在 Chatflow 编辑器的预览窗口输入问题如果一切正常你会看到类似这样的链路知识检索节点返回 3 条相关文档片段每条带 score。LLM 节点生成的回答中引用了片段内容并带上来源标注。回答节点正常输出。这说明知识库检索、提示词、模型生成三个核心环节都通了。6.2 API 验证通过 curl 调用后预期返回一个 JSON 结构核心字段类似{ answer: 根据知识库资料请假流程需要先在 OA 系统提交申请单由直属负责人审批。, conversation_id: abc-123, message_id: msg-456 }判断成功的标准不是“模型能不能说话”而是三个指标回答内容是否有知识库依据。是否标注了引用来源。相同问题再次提问时结果是否稳定。如果回答内容与知识库无关或模型开始自由发挥编造答案优先检查知识检索节点有没有成功返回内容再看提示词是否约束了“只能根据检索结果回答”。6.3 失败时第一步先看日志如果调用失败第一步看后端日志docker compose logs -f api docker compose logs -f worker日志里通常能看到模型请求超时、知识库检索报错、环境变量缺失等具体原因。不要盲目重启容器先定位是模型层、知识库层还是服务层的问题。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型不存在或提示 model not found模型供应商未配置或模型名称填错控制台→设置→模型供应商检查已配置模型重新配置模型确认模型 ID 与供应商一致Ollama 模型处理超时本地推理速度慢或容器无法访问宿主机 Ollama查看 api/worker 日志检查 host.docker.internal 连通性换小模型关闭其他任务调大请求超时时间上传文档解析失败文件格式不支持、文件过大、扫描版 PDF 无文字层检查文件类型和大小确认文档可复制文字转成 PDF/Markdown/TXT拆分超大文件知识库检索不到内容文档尚未完成索引或分段/阈值设置不合理在知识库召回测试里输入相同问题看是否有召回结果重建索引调大 TopK降低 Score 阈值Dify 出现内部服务器错误依赖服务异常、磁盘空间不足、网络波动查看 api/worker 容器日志重启容器清理磁盘检查 DNS 和网络Windows 下 Docker 部署失败Docker Desktop 未完全启动WSL2 后端未启用执行 docker version、docker compose version开启 WSL2 后端重启 Docker Desktop插件安装失败网络受限、插件版本与平台版本不兼容查看插件市场日志检查版本使用离线包安装或更换兼容版本MCP 服务连接失败MCP 服务地址不可达、协议配置错误测试本地地址连通性确认服务端监听端口改为可访问的 HTTP 接口地址检查防火墙排查时建议遵循“由近到远”的顺序先看 Dify 服务是否正常再看模型服务是否连通最后看具体业务配置。很多问题其实都出在“模型服务没配置好”而不是 Dify 本身。8. 最佳实践与工程建议从敏捷交付的视角看Dify 不是搭完就结束的工具它需要一套工程规范来配套。8.1 先用最小 Agent 跑通再逐步加复杂节点第一次使用不要一上来就设计几十个节点的复杂工作流。建议先做一个“开始 → LLM → 回答”的最小应用验证模型连通性然后再加入知识检索、条件分支、HTTP 请求等节点。每加一个节点就测试一次保持系统始终处于可运行状态。8.2 Prompt 要像代码一样管理Dify 的提示词可以直接在应用内编辑但团队协作时建议把关键 Prompt 沉淀到统一的文档或代码仓库里说明版本、改动原因和效果变化。Dify 支持 App DSL 导出可以把应用配置导出为 YAML 文件纳入版本管理。这样每次改动都有迹可循出问题可以快速回滚。8.3 建立回归评测集这是最容易被忽略的一步。AI 应用改一个 Prompt 或换一个模型后很难立刻判断是变好还是变坏。建议整理一批覆盖典型业务场景的测试问题每次改动后跑一遍记录回答质量。不求自动化哪怕用表格人工记录也行。没有评测集的 Agent 项目迭代越快越容易失控。8.4 知识库要按业务域拆分不要把所有文档塞进一个超大知识库。建议按业务域拆分成多个知识库例如“行政制度”“产品文档”“技术支持”然后根据不同的应用场景关联不同的知识库。超大知识库会明显拉低召回精度不同领域的内容互相干扰容易让模型答非所问。8.5 模型分层控制成本不是所有请求都需要最强模型。简单的意图判断、关键词分类可以用小模型复杂的逻辑推理、长文档总结再用大模型。Dify 支持在不同工作流节点上指定不同模型这能显著降低成本同时提升响应速度。8.6 权限、多租户与安全边界从公开资料看Dify 社区版 1.10 开始支持多租户能力适合交付多个项目的团队。生产环境里建议让不同业务项目使用独立的知识库和应用空间避免数据互相可见。同时最小化工具权限Agent 能调用的 HTTP API、数据库查询、MCP 工具都要按最小权限原则配置。涉及敏感操作的系统不要让 Agent 直接执行写操作。8.7 二次开发要注意上游同步很多团队会对 Dify 做二次开发比如修改前端界面、扩展后端 API。做之前要想清楚维护成本越深度的定制越难跟着上游版本升级。建议通过官方插件机制扩展能力较少改动核心代码。如果必须 fork要把改动集中在少量模块并建立与上游版本同步的流程。9. 总结AI 时代的敏捷交付回到开头的判断。张路宇出现在 RSG 敏捷嘉年华大会 2026 上海本质上释放了一个信号AI 应用开发正在从“模型能力竞赛”进入“交付效率竞赛”。Dify 这类平台真正改变的不是让会写代码的人失业而是压缩了“表达需求 → 验证效果 → 交付能力”的反馈回路。过去一个 AI 功能从想法到上线可能需要跨多个团队、经历复杂的代码开发流程现在一个人用可视化工作流加知识库几个小时就能跑通一个具备真实价值的 Agent 应用。但工具只是底座真正的竞争力来自团队对“快速验证”的理解。AI 应用开发没有标准答案只有不断测试、持续调整、及时回滚。你得有自己的评测集得维护好知识库得管理好 Prompt 版本得在成本和效果之间做权衡。下一步的实践建议很直接用 Docker 部署一个 Dify 社区版选一个小模型上传一份你熟悉领域的文档搭建一个知识库问答 Agent然后试着每天改动一个变量观察效果变化。把这条路跑通之后再去看工作流编排、插件扩展、MCP 集成、多租户落地你会比只停留在概念阶段的人理解得更深。Agile 的核心不是仪式而是快速反馈。Dify 做的正是把这种反馈能力下沉到了 AI 应用的工程链路里。
Dify与敏捷开发：AI应用交付的工程化新范式
“Dify 创始人张路宇出席 RSG 敏捷嘉年华大会 2026 上海”这条消息放在两年前我会觉得只是普通活动通稿但今天再看它其实是一个值得玩味的行业信号。Dify 在 AI 应用开发圈子里几乎成了“开源 Agent 平台”的代名词。本地部署、可视化工作流、知识库 RAG、多租户、MCP 插件……大量想做 AI 应用的开发者、产品经理和企业架构师都围绕这个词组展开讨论。而 RSG 敏捷嘉年华是敏捷开发领域的老牌大会主题一贯是 Scrum、看板、需求拆分、团队自组织。一边是 AI 工程一边是软件开发过程管理看起来一个偏技术工具一个偏管理方法。但 Dify 创始人出现在敏捷大会会场说明行业开始认真面对一个问题AI 应用的交付流程到底应该怎么组织本文不打算写成会议新闻稿。我想从 Dify 的工程能力出发拆解它和敏捷开发之间的深层关系并给出一条从本地部署到知识库问答 Agent 的最小实践路径。读完这篇文章你可以得到三样东西理解 Dify 到底解决了什么问题——它不是简单意义上的“低代码 AI 平台”而是让 AI 应用交付进入短迭代、可验证、可回滚的敏捷轨道。掌握在 Docker 环境里本地部署 Dify 的完整流程和关键坑点。跑通一个基于知识库的问答 Agent并知道如何通过 API 接入现有业务系统。1. 从 RSG 敏捷嘉年华说起Dify 与敏捷为什么会同台RSG 是 Regional Scrum Gathering 的缩写是全球敏捷社区在各大城市定期举办的技术盛会。2026 年落地上海Dify 创始人张路宇出席分享这件事从公开信息看有几个明确指向第一AI 应用开发的工程化问题正在从“有没有工具”进入“怎么协作、怎么迭代”的阶段。早期大家关心的是“模型能不能回答”后来关心“怎么把 Prompt 写得更准”现在越来越多人关心的是一个 Agent 应用从想法到上线团队里谁来编排流程、谁来维护知识库、谁来验证效果、出了问题怎么回滚。第二敏捷社区开始把 AI 应用当成一种新的交付对象。过去敏捷讲的是需求拆解、迭代冲刺、持续反馈。但 AI 应用有一个传统软件没有的变量模型的输出是不确定的。同一个 Prompt换一个模型、调一个参数、改一段上下文效果可能完全不同。这种不确定性恰恰是敏捷方法最擅长处理的场景。第三Dify 团队需要更多的“企业级交付案例”来反推产品方向。Dify 社区版从单机部署到多租户、从知识库到工作流编排、从插件系统到 MCP 支持每一步变化都来自真实落地场景。而 RSG 敏捷嘉年华的参会者大多是团队负责人和架构师正是企业级 AI 应用落地的决策者。所以这场分享不是一次简单的站台而是把“AI 应用开发该如何敏捷迭代”这个话题正式摆到了软件工程社区面前。2. Dify 是什么一个 AI 应用交付平台的完整拆解2.1 核心概念先纠正一个常见误解很多人把 Dify 直接理解为“低代码聊天机器人平台”。这个说法不准确Dify 覆盖的能力比“聊天机器人”宽得多。从开发视角看Dify 是一个位于“模型 API”和“业务系统”之间的应用交付层。它把大模型应用开发中大量重复、容易出错的基础工作标准化让开发者把精力集中在业务逻辑上。它的核心概念包括概念通俗解释没有它时需要做什么Agent能自主拆解任务、调用工具的智能体自己写循环、维护上下文、处理工具调用Workflow可视化的节点编排把 Prompt、模型、工具、分支组合成可运行流水线用代码硬编码流程改一次要发一次版知识库通过 RAG 方式给模型补充私有知识自己实现文档切片、向量化、检索、重排模型管理统一接入 OpenAI、Ollama、Azure、vLLM 等模型服务每个模型一套 SDK切换成本高插件体系标准化的工具接入机制支持 MCP 等协议为每个新工具写胶水代码可观测性日志、追踪、标注、评测自己埋点开发和调试效率低2.2 传统开发方式与 Dify 方式对比假设你要做一个“企业内部文档问答助手”。传统方式下你需要写后端服务对接大模型 API。处理对话上下文、会话状态。自己实现文档解析、切片、Embedding、向量检索。写前端聊天页面。处理 Prompt 版本管理、模型切换、异常重试。把服务部署上线再搭一套日志和监控。这个流程一个经验丰富的后端团队可能也要一两周才能跑通。而且 Prompt 稍微一改整个链路都要重新测试发布。Dify 方式则是上传文档到知识库自动完成切片和索引。选择一个模型供应商配置 API Key。拖拽一个 Chatflow开始节点 → 知识检索节点 → LLM 节点 → 回答节点。在调试界面里直接测试效果满意后一键发布。生成 API 密钥业务系统通过标准 API 接入。从一周缩短到一小时这是数量级的变化。但这里的核心判断是Dify 并不是让开发者变懒而是把重复劳动从“写代码”变成“配置和编排”把不确定性集中在“效果验证”上。这也是它能和敏捷方法产生化学反应的根本原因。3. 为什么 AI 应用开发天然需要敏捷方法3.1 预测型与敏捷型的差异软件开发方法论里有一组经典对比预测型和敏捷型。预测型流程假设需求在项目开始时可以定义得足够清楚然后按照“需求 → 设计 → 开发 → 测试 → 交付”的顺序推进。这种方式适合需求稳定、技术路径明确的场景比如建设一个 CRM 系统、改造一套订单流程。敏捷型流程则承认需求会变化甚至承认我们一开始无法把需求定义完整。它用短迭代、可交付增量、持续反馈来对抗不确定性。AI 应用开发更像哪一种答案是敏捷型。原因很直接你无法准确预测一个 Prompt 写出来后的效果。你无法保证一个模型在某个特定业务域的表现。你无法在需求阶段就告诉团队“这个 Agent 最终会长什么样”。知识库内容会变模型版本会变业务问题也会变。这意味着AI 应用开发必须采用短周期的“假设 → 实现 → 验证 → 调整”循环。一次 Prompt 调整、一次知识库更新、一次模型切换都需要快速验证并决定保留还是回滚。3.2 Dify 如何支撑敏捷迭代Dify 的很多设计本质上都是为这个循环服务的可视化工作流让产品经理、业务分析师也能参与编排跨职能协作门槛降低。以前一个流程改动要等开发排期现在在编辑器里拖拽一个节点就能试。一键发布和多版本能力让“发布-回滚”变得轻量。改坏了 Prompt可以快速回到上一个可用版本。知识库支持增量更新和重建索引。文档内容变化后不需要重新开发只需要重新处理相关文件。完整的调试和日志追踪让反馈闭环变短。每一次用户对话、每一个工作流节点执行记录都可以用来判断问题出在检索、提示词还是模型推理。插件体系把工具接入标准化。新增一个 HTTP API、一个数据库查询、一个 MCP 服务不需要动核心代码。所以我的判断是Dify 本质上是一套面向 LLM 应用的敏捷交付基础设施。它不直接教你什么是 Scrum但它把“快速试错、持续交付、及时回滚”的能力做进了工具本身。4. 环境准备与 Dify 本地部署4.1 环境依赖Dify 官方推荐用 Docker Compose 方式部署这是最稳妥、升级路径最清晰的方式。前置条件一台 Linux 服务器或安装了 Docker Desktop 的 Windows / macOS 电脑。Docker 和 Docker Compose 环境Docker 版本建议不低于 20.10具体以官方 release 要求为准。内存建议至少 8GB如果还要本地跑 Ollama 模型建议 16GB 以上。一个可用的模型服务OpenAI 兼容 API、Ollama 本地模型、Azure OpenAI、vLLM 等均可。本地开发测试时最省事的方式是先用 Ollama 拉一个小模型例如 qwen2.5:7b 或 llama3.1:8b先把链路跑通再切换到更强大的模型。4.2 Docker Compose 部署步骤首先克隆代码并进入 docker 目录git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d等待容器启动完成后检查状态docker compose ps看到 api、worker、web、db、redis、sandbox 等容器处于 running 状态就说明基础服务正常。然后访问http://localhost本地或http://服务器IP远程进入 Dify 初始化界面。首次使用需要设置管理员账号。如果要接入 Ollama 本地模型需要确保容器能访问宿主机。在 Linux 上通常通过host.docker.internal或宿主局域网 IP在 Docker Desktop 上一般直接用host.docker.internal。4.3 版本升级与回滚Dify 版本迭代很快社区版 1.10 以后还加入了多租户能力升级时要格外谨慎。建议流程docker compose down git pull origin main docker compose pull docker compose up -d升级前必须备份数据库和.env文件。Dify 的数据主要存在 docker volume 中可以直接备份 volume 目录也可以在升级前把关键业务数据导出。生产环境更新前建议先在测试环境完整验证一轮再对生产环境执行更新。这里真正容易踩的坑是直接删掉 volume 重启。docker compose down -v会把数据库、向量索引全部清掉一旦误操作很难恢复。如果只是想重启服务使用docker compose restart就够了。5. 用 Dify 搭建一个知识库问答 Agent5.1 场景选择知识库问答是 Dify 最经典、也最容易跑通的应用场景。企业内部文档问答、产品使用指南、客服话术查询、合规条款检索都属于这一类。我们以一个“企业行政制度问答助手”为例子员工可以问“请假流程怎么申请”“差旅报销标准是什么”Agent 根据制度文档回答并标注引用来源。5.2 创建知识库登录 Dify 控制台进入“知识库”页面点击创建知识库上传几份 Markdown 或 PDF 文档。创建时需要关心三个选项分段模式一般选“通用分段”如果文档结构复杂、章节层级多可以选“父子分段”让检索结果更精细。分段长度默认值适合大多数场景但如果检索结果不准确可以调小分段或者按标题层级分开。Embedding 模型选择一个你已经配置好的模型。中文场景下建议优先测试百炼、通义、OpenAI 等对中文支持较好的 embedding 模型。保存后系统会自动处理文档并建立索引。处理完成后在“召回测试”里输入一个问题可以验证知识库能否检索到相关内容。这一步非常关键如果召回测试都没有结果后面 Agent 一定答不好。5.3 创建 Chatflow 工作流返回“应用”页面新建一个 Chatflow 类型应用。Chatflow 比简单的聊天助手更适合需要调试的场景因为可以看到每个节点的输入输出。一个最小可用的知识库问答工作流包含四个节点开始节点接收用户问题。知识检索节点选择知识库设置 TopK 为 3Score 阈值设为 0.3 左右。LLM 节点基于检索结果生成回答。回答节点把结果返回给用户。LLM 节点的提示词模板可以参考你是企业行政制度问答助手。 请只根据知识库检索结果回答用户问题不要编造事实。 回答要求 1. 如果检索结果与问题无关明确回答“知识库中暂未找到相关内容”。 2. 引用知识库内容时在句末用 [来源N] 标注。 3. 回答语言与用户保持一致。 用户问题 {{query}} 知识库检索结果 {{context}}注意{{query}}和{{context}}是变量占位符的示意写法。不同 Dify 版本中工作流节点的变量名可能不同建议在编辑器的变量选择器里直接引用“知识检索”节点的输出字段。完成编排后先点击“预览”测试输入“请假流程怎么申请”观察知识检索节点是否返回了相关片段再看 LLM 节点的回答是否使用了检索内容。5.4 通过 API 接入业务系统调试满意后点击“发布”。发布后左侧会出现“API 访问”入口创建一个 API 密钥。业务系统可以通过标准接口调用这个 Agentcurl -X POST http://your-server/v1/chat-messages \ -H Authorization: Bearer app-XXXXXXXX \ -H Content-Type: application/json \ -d { inputs: {}, query: 请假流程怎么申请, response_mode: blocking, conversation_id: }app-XXXXXXXX换成你在 Dify 后台生成的密钥your-server换成你的服务地址。返回结果会包含answer字段和conversation_id后续对话带着同一个conversation_id就可以保持上下文。6. 运行结果与效果验证6.1 调试界面验证在 Chatflow 编辑器的预览窗口输入问题如果一切正常你会看到类似这样的链路知识检索节点返回 3 条相关文档片段每条带 score。LLM 节点生成的回答中引用了片段内容并带上来源标注。回答节点正常输出。这说明知识库检索、提示词、模型生成三个核心环节都通了。6.2 API 验证通过 curl 调用后预期返回一个 JSON 结构核心字段类似{ answer: 根据知识库资料请假流程需要先在 OA 系统提交申请单由直属负责人审批。, conversation_id: abc-123, message_id: msg-456 }判断成功的标准不是“模型能不能说话”而是三个指标回答内容是否有知识库依据。是否标注了引用来源。相同问题再次提问时结果是否稳定。如果回答内容与知识库无关或模型开始自由发挥编造答案优先检查知识检索节点有没有成功返回内容再看提示词是否约束了“只能根据检索结果回答”。6.3 失败时第一步先看日志如果调用失败第一步看后端日志docker compose logs -f api docker compose logs -f worker日志里通常能看到模型请求超时、知识库检索报错、环境变量缺失等具体原因。不要盲目重启容器先定位是模型层、知识库层还是服务层的问题。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型不存在或提示 model not found模型供应商未配置或模型名称填错控制台→设置→模型供应商检查已配置模型重新配置模型确认模型 ID 与供应商一致Ollama 模型处理超时本地推理速度慢或容器无法访问宿主机 Ollama查看 api/worker 日志检查 host.docker.internal 连通性换小模型关闭其他任务调大请求超时时间上传文档解析失败文件格式不支持、文件过大、扫描版 PDF 无文字层检查文件类型和大小确认文档可复制文字转成 PDF/Markdown/TXT拆分超大文件知识库检索不到内容文档尚未完成索引或分段/阈值设置不合理在知识库召回测试里输入相同问题看是否有召回结果重建索引调大 TopK降低 Score 阈值Dify 出现内部服务器错误依赖服务异常、磁盘空间不足、网络波动查看 api/worker 容器日志重启容器清理磁盘检查 DNS 和网络Windows 下 Docker 部署失败Docker Desktop 未完全启动WSL2 后端未启用执行 docker version、docker compose version开启 WSL2 后端重启 Docker Desktop插件安装失败网络受限、插件版本与平台版本不兼容查看插件市场日志检查版本使用离线包安装或更换兼容版本MCP 服务连接失败MCP 服务地址不可达、协议配置错误测试本地地址连通性确认服务端监听端口改为可访问的 HTTP 接口地址检查防火墙排查时建议遵循“由近到远”的顺序先看 Dify 服务是否正常再看模型服务是否连通最后看具体业务配置。很多问题其实都出在“模型服务没配置好”而不是 Dify 本身。8. 最佳实践与工程建议从敏捷交付的视角看Dify 不是搭完就结束的工具它需要一套工程规范来配套。8.1 先用最小 Agent 跑通再逐步加复杂节点第一次使用不要一上来就设计几十个节点的复杂工作流。建议先做一个“开始 → LLM → 回答”的最小应用验证模型连通性然后再加入知识检索、条件分支、HTTP 请求等节点。每加一个节点就测试一次保持系统始终处于可运行状态。8.2 Prompt 要像代码一样管理Dify 的提示词可以直接在应用内编辑但团队协作时建议把关键 Prompt 沉淀到统一的文档或代码仓库里说明版本、改动原因和效果变化。Dify 支持 App DSL 导出可以把应用配置导出为 YAML 文件纳入版本管理。这样每次改动都有迹可循出问题可以快速回滚。8.3 建立回归评测集这是最容易被忽略的一步。AI 应用改一个 Prompt 或换一个模型后很难立刻判断是变好还是变坏。建议整理一批覆盖典型业务场景的测试问题每次改动后跑一遍记录回答质量。不求自动化哪怕用表格人工记录也行。没有评测集的 Agent 项目迭代越快越容易失控。8.4 知识库要按业务域拆分不要把所有文档塞进一个超大知识库。建议按业务域拆分成多个知识库例如“行政制度”“产品文档”“技术支持”然后根据不同的应用场景关联不同的知识库。超大知识库会明显拉低召回精度不同领域的内容互相干扰容易让模型答非所问。8.5 模型分层控制成本不是所有请求都需要最强模型。简单的意图判断、关键词分类可以用小模型复杂的逻辑推理、长文档总结再用大模型。Dify 支持在不同工作流节点上指定不同模型这能显著降低成本同时提升响应速度。8.6 权限、多租户与安全边界从公开资料看Dify 社区版 1.10 开始支持多租户能力适合交付多个项目的团队。生产环境里建议让不同业务项目使用独立的知识库和应用空间避免数据互相可见。同时最小化工具权限Agent 能调用的 HTTP API、数据库查询、MCP 工具都要按最小权限原则配置。涉及敏感操作的系统不要让 Agent 直接执行写操作。8.7 二次开发要注意上游同步很多团队会对 Dify 做二次开发比如修改前端界面、扩展后端 API。做之前要想清楚维护成本越深度的定制越难跟着上游版本升级。建议通过官方插件机制扩展能力较少改动核心代码。如果必须 fork要把改动集中在少量模块并建立与上游版本同步的流程。9. 总结AI 时代的敏捷交付回到开头的判断。张路宇出现在 RSG 敏捷嘉年华大会 2026 上海本质上释放了一个信号AI 应用开发正在从“模型能力竞赛”进入“交付效率竞赛”。Dify 这类平台真正改变的不是让会写代码的人失业而是压缩了“表达需求 → 验证效果 → 交付能力”的反馈回路。过去一个 AI 功能从想法到上线可能需要跨多个团队、经历复杂的代码开发流程现在一个人用可视化工作流加知识库几个小时就能跑通一个具备真实价值的 Agent 应用。但工具只是底座真正的竞争力来自团队对“快速验证”的理解。AI 应用开发没有标准答案只有不断测试、持续调整、及时回滚。你得有自己的评测集得维护好知识库得管理好 Prompt 版本得在成本和效果之间做权衡。下一步的实践建议很直接用 Docker 部署一个 Dify 社区版选一个小模型上传一份你熟悉领域的文档搭建一个知识库问答 Agent然后试着每天改动一个变量观察效果变化。把这条路跑通之后再去看工作流编排、插件扩展、MCP 集成、多租户落地你会比只停留在概念阶段的人理解得更深。Agile 的核心不是仪式而是快速反馈。Dify 做的正是把这种反馈能力下沉到了 AI 应用的工程链路里。