企业官网建设流程全解析

“Dify 创始人张路宇出席 RSG 敏捷嘉年华大会 2026 上海”这条消息，放在两年前我会觉得只是普通活动通稿，但今天再看，它其实是一个值得玩味的行业信号。

Dify 在 AI 应用开发圈子里几乎成了“开源 Agent 平台”的代名词。本地部署、可视化工作流、知识库 RAG、多租户、MCP 插件……大量想做 AI 应用的开发者、产品经理和企业架构师，都围绕这个词组展开讨论。而 RSG 敏捷嘉年华是敏捷开发领域的老牌大会，主题一贯是 Scrum、看板、需求拆分、团队自组织。一边是 AI 工程，一边是软件开发过程管理，看起来一个偏技术工具，一个偏管理方法。但 Dify 创始人出现在敏捷大会会场，说明行业开始认真面对一个问题：AI 应用的交付流程，到底应该怎么组织？

本文不打算写成会议新闻稿。我想从 Dify 的工程能力出发，拆解它和敏捷开发之间的深层关系，并给出一条从本地部署到知识库问答 Agent 的最小实践路径。读完这篇文章，你可以得到三样东西：

1. 理解 Dify 到底解决了什么问题——它不是简单意义上的“低代码 AI 平台”，而是让 AI 应用交付进入短迭代、可验证、可回滚的敏捷轨道。
2. 掌握在 Docker 环境里本地部署 Dify 的完整流程和关键坑点。
3. 跑通一个基于知识库的问答 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”和“业务系统”之间的应用交付层。它把大模型应用开发中大量重复、容易出错的基础工作标准化，让开发者把精力集中在业务逻辑上。

它的核心概念包括：

2.2 传统开发方式与 Dify 方式对比

假设你要做一个“企业内部文档问答助手”。传统方式下，你需要：

1. 写后端服务，对接大模型 API。
2. 处理对话上下文、会话状态。
3. 自己实现文档解析、切片、Embedding、向量检索。
4. 写前端聊天页面。
5. 处理 Prompt 版本管理、模型切换、异常重试。
6. 把服务部署上线，再搭一套日志和监控。

这个流程，一个经验丰富的后端团队可能也要一两周才能跑通。而且 Prompt 稍微一改，整个链路都要重新测试发布。

Dify 方式则是：

1. 上传文档到知识库，自动完成切片和索引。
2. 选择一个模型供应商，配置 API Key。
3. 拖拽一个 Chatflow：开始节点 → 知识检索节点 → LLM 节点 → 回答节点。
4. 在调试界面里直接测试效果，满意后一键发布。
5. 生成 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 搭建一个知识库问答 Agent

5.1 场景选择

知识库问答是 Dify 最经典、也最容易跑通的应用场景。企业内部文档问答、产品使用指南、客服话术查询、合规条款检索都属于这一类。

我们以一个“企业行政制度问答助手”为例子：员工可以问“请假流程怎么申请”“差旅报销标准是什么”，Agent 根据制度文档回答，并标注引用来源。

5.2 创建知识库

登录 Dify 控制台，进入“知识库”页面，点击创建知识库，上传几份 Markdown 或 PDF 文档。

创建时需要关心三个选项：

1. 分段模式：一般选“通用分段”，如果文档结构复杂、章节层级多，可以选“父子分段”让检索结果更精细。
2. 分段长度：默认值适合大多数场景，但如果检索结果不准确，可以调小分段，或者按标题层级分开。
3. Embedding 模型：选择一个你已经配置好的模型。中文场景下建议优先测试百炼、通义、OpenAI 等对中文支持较好的 embedding 模型。

保存后，系统会自动处理文档并建立索引。处理完成后，在“召回测试”里输入一个问题，可以验证知识库能否检索到相关内容。这一步非常关键：如果召回测试都没有结果，后面 Agent 一定答不好。

5.3 创建 Chatflow 工作流

返回“应用”页面，新建一个 Chatflow 类型应用。Chatflow 比简单的聊天助手更适合需要调试的场景，因为可以看到每个节点的输入输出。

一个最小可用的知识库问答工作流包含四个节点：

1. 开始节点：接收用户问题。
2. 知识检索节点：选择知识库，设置 TopK 为 3，Score 阈值设为 0.3 左右。
3. LLM 节点：基于检索结果生成回答。
4. 回答节点：把结果返回给用户。

LLM 节点的提示词模板可以参考：

你是企业行政制度问答助手。 请只根据知识库检索结果回答用户问题，不要编造事实。 回答要求： 1. 如果检索结果与问题无关，明确回答“知识库中暂未找到相关内容”。 2. 引用知识库内容时，在句末用 [来源N] 标注。 3. 回答语言与用户保持一致。 用户问题： {{query}} 知识库检索结果： {{context}}

注意：{{query}}和{{context}}是变量占位符的示意写法。不同 Dify 版本中，工作流节点的变量名可能不同，建议在编辑器的变量选择器里直接引用“知识检索”节点的输出字段。

完成编排后，先点击“预览”测试，输入“请假流程怎么申请”，观察知识检索节点是否返回了相关片段，再看 LLM 节点的回答是否使用了检索内容。

5.4 通过 API 接入业务系统

调试满意后，点击“发布”。发布后，左侧会出现“API 访问”入口，创建一个 API 密钥。

业务系统可以通过标准接口调用这个 Agent：

curl -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 编辑器的预览窗口输入问题，如果一切正常，你会看到类似这样的链路：

1. 知识检索节点返回 3 条相关文档片段，每条带 score。
2. LLM 节点生成的回答中引用了片段内容，并带上来源标注。
3. 回答节点正常输出。

这说明知识库检索、提示词、模型生成三个核心环节都通了。

6.2 API 验证

通过 curl 调用后，预期返回一个 JSON 结构，核心字段类似：

{ "answer": "根据知识库资料，请假流程需要先在 OA 系统提交申请单，由直属负责人审批。", "conversation_id": "abc-123", "message_id": "msg-456" }

判断成功的标准不是“模型能不能说话”，而是三个指标：

1. 回答内容是否有知识库依据。
2. 是否标注了引用来源。
3. 相同问题再次提问时，结果是否稳定。

如果回答内容与知识库无关，或模型开始自由发挥编造答案，优先检查知识检索节点有没有成功返回内容，再看提示词是否约束了“只能根据检索结果回答”。

6.3 失败时第一步先看日志

如果调用失败，第一步看后端日志：

docker compose logs -f api docker compose logs -f worker

日志里通常能看到模型请求超时、知识库检索报错、环境变量缺失等具体原因。不要盲目重启容器，先定位是模型层、知识库层还是服务层的问题。

7. 常见问题与排查思路

排查时建议遵循“由近到远”的顺序：先看 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 应用的工程链路里。