企业官网建设流程全解析

做 AI 应用定制化，前面好几年我一直处在“要么用别人封装好的 SaaS，要么从零开始写代码调模型”的尴尬状态。直到把 Dify 完整跑通之后，我才觉得这条路终于走顺了。Dify 是一个开源的 LLM 应用开发平台，简单说就是帮我们把“接大模型、管理 Prompt、挂知识库、编排流程、发布 API”这一整套东西，从代码级封装成可视化操作。这篇文章我会从本地部署讲起，一路拆到知识库、工作流、Agent、多租户和 API 发布，把我实际踩过的坑和验证过能用的配置都放出来，适合正准备做企业级 AI 应用落地的开发者和技术负责人参考。

Dify 这个名字在 AI 圈这两年出现频率越来越高，核心原因就一个：它把定制化 AI 应用的门槛从“会写代码”降到了“理解业务逻辑”。你可以用鼠标把大模型、知识库、工具调用串成一条流水线，也可以把现成的 Agent 能力直接嵌进内部系统。这篇文章既包含部署步骤，也包含实战链路设计，我尽量把每一步为什么这么做讲透，而不是扔一堆命令让你复制。

1. 为什么选择Dify：AI应用定制化的核心思路

1.1 Dify在AI应用链路中到底扮演什么角色

我们先想清楚一个问题：做一个企业内部的 AI 问答机器人，到底需要哪些环节？答案是模型接入、Prompt 管理、上下文构建、知识库检索、会话记忆、权限控制、日志跟踪，最后还要有个 API 能对接现有系统。如果这些全从零开始写，光是模型 API 切换这一件事就够折腾半个月。

Dify 的作用是把这条链路整体封装，做成一个可以私有化部署的平台。模型接入层支持国内外主流大模型 API，也支持本地部署的 Ollama、Xinference 等推理服务；应用层提供聊天助手、文本生成、Agent、工作流四种类型；数据层内置了知识库和向量检索；发布层则可以一键生成 API 密钥供外部调用。说白了，它不是替代你写业务代码，而是把 AI 周边能力全部收敛到一个系统里，让你专注业务本身。

我举个例子，我们团队之前做了一个内部合同审查助手，底层用了一个开源模型做文件解析，又用另一个大模型做风险条款分析，中途还接了一套自研的相似案例检索服务。放在过去，这三个系统之间的编排逻辑要写大量胶水代码，但在 Dify 里就是三个节点：HTTP 请求节点、LLM 节点、知识检索节点，拖拽连接即可。

1.2 核心概念与模块速查

很多刚接触 Dify 的人会被导航菜单里的应用、工作流、知识库、工具、Agent 这些词搞晕，我先给一个速查表，后面实战部分会一个一个展开。

1.3 和直接用LangChain相比，Dify赢在哪里

我不否认 LangChain 这类代码框架的灵活性，它也适合深度二次开发。但实际交付项目时，Dify 有几个优势是代码框架很难替代的。

第一是可观测性。Dify 每个应用都有完整的日志，哪一轮用户输入导致模型返回异常、哪一步工作流节点耗时最长，在界面上直接可以看到。这对系统上线后的持续调优太关键了，而用 LangChain 自己搭，日志和链路追踪往往需要额外接一套系统。第二是协作效率。非技术同事也能通过界面维护 Prompt 和知识库，不再每个小改动都要找研发发版。第三是部署友好。Dify 自带 Docker Compose 编排，迁移到客户内网环境时，一套命令就能起来，这对做 To B 项目的人尤其重要。

2. 本地部署与初始配置：跑通第一个Dify实例

2.1 部署前的三层准备

先把部署环境搞清楚。Dify 官方推荐最低配置是 2C4G，但我实际用下来，4C8G 才算跑得舒服，因为除了后端服务，还会容器化启动 PostgreSQL、Redis、Weaviate 等组件。如果要同时跑 Embedding 模型做知识库索引，内存建议直接上 16G，不然知识库文档一多，容器经常被系统杀掉。

软件层面主要三件事：Docker 环境、Git、可用的模型 API 或本地推理服务。Windows 10 用户装 Docker Desktop，开启 WSL2 后端即可；Linux 服务器直接装 Docker Engine 和 Docker Compose 插件。注意 Dify 新版安装包默认使用 docker compose 子命令，老版本习惯用 docker-compose，两种命令别混用。镜像拉取如果遇到网络慢的问题，可以给 Docker 配置国内镜像加速地址，这个是基础设施层面能解决的，不影响 Dify 本身功能。

2.2 Windows 10本地部署实操流程

我把 Windows 上部署 Dify 的路径完整走了一遍，照着做基本不会出问题。先去 Dify 的 GitHub Releases 页面下载对应版本的源码包，解压后会看到一个名为 dify-main 的文件夹。注意核心目录不是根目录，而是里面的 docker 文件夹，所有部署文件都在这。

进入 docker 文件夹后，在地址栏输入 cmd 回车，或者直接右键打开终端。首次部署需要创建环境变量文件，在终端里执行：

cp .env.example .env

Windows 的 PowerShell 原生支持 cp 命令，CMD 下可能不识别，建议直接用 PowerShell。执行完这一步，可以用记事本打开 .env 文件检查几个关键变量：EXPOSE_NGINX_PORT 是外部访问端口，默认 80；SECRET_KEY 是后端加密密钥，生产环境务必改长；POSTGRES_PASSWORD 和 REDIS_PASSWORD 建议改成强密码，不要用默认值。这些密码在容器第一次启动时初始化，后面再改很麻烦，所以开局就应该改好。

然后执行：

docker compose up -d

第一次启动会拉取十几个镜像，包括 api、worker、web、db、redis、weaviate、ssrf_proxy 等，需要耐心等一会儿。启动完成后，等 1 到 2 分钟让数据库迁移脚本跑完，打开浏览器访问 http://localhost/install，按提示设置管理员邮箱和密码，就能进入主界面。

2.3 配置模型供应商：本地模型还是云端API

第一次登录 Dify，第一件事不是建应用，而是接模型。进入“设置”->“模型供应商”，可以看到几十种选择。这里我分两条路径讲：如果你有云端 API Key，直接选择对应供应商填入即可；如果在内网环境或者不想把数据发到外部，就用本地推理服务。

本地方案我推荐 Ollama，因为部署最简单。先在宿主机装好 Ollama，拉一个模型，比如：

ollama pull qwen2.5:7b ollama pull bge-m3

回到 Dify 模型供应商页面，找到 Ollama 类型，填入 Base URL 为 http://host.docker.internal:11434，模型名称填 qwen2.5:7b。这里的 host.docker.internal 是 Docker Desktop 提供的宿主机访问地址，部署在 Linux 上则通常是宿主机内网 IP。Embedding 模型同样配置 bge-m3，知识库的向量化就靠它。用本地模型的好处是数据不出内网，适合制度文档、客户资料这类敏感内容。

3. 知识库与RAG实战：把私有数据变成AI能力

3.1 RAG为什么是AI应用定制化的刚需

大模型的知识截止时间和企业内部资料永远存在断层，你不可能为了回答一个制度问题就去微调一个模型，成本太高、更新太慢。RAG 的思路是先检索再生成：用户提问后，系统先从知识库中检索最相关的文档片段，把片段拼进 Prompt，再让模型基于这些片段生成答案。这样既保证了数据实时性，又大幅降低了幻觉概率。

Dify 的知识库本质上就是一套完整的 RAG 流水线，从文档上传、文本分段、向量化、索引存储到检索排序全部内置。相比自己搭向量数据库和 Embedding 服务，Dify 把这些细节都封装好了，而且支持可视化管理，后台运营同学也能维护。我们之前的客户案例里，有单位把几十份制度文件直接传上去，几分钟后就能基于这些制度回答问题，效果比直接问大模型稳得多。

3.2 在Dify创建知识库：从文档清洗到分段

创建知识库时，会先让你选择“分段设置”和“索引方式”。

分段模式我强烈建议选“自定义”，不要用自动分段。自动分段按固定字符数切开，经常把一个完整条款截成两段，检索时候容易遗漏上下文。自定义分段里可以设置最大分段长度和分段重叠长度。以制度文档为例，我一般设最大分段长度 800 到 1000 字符，分段重叠 50 字符。这个组合的好处是既能保证片段语义完整，又不会因为太碎导致检索精度下降。如果文档本身有清晰的章节结构，可以开启“分段标识”功能，让 Dify 按标题层级来切分。

索引方式有“高质量”和“经济”两种。高质量模式会用 Embedding 模型做语义向量索引，适合需要理解语义的场景；经济模式走的是倒排索引，速度快但效果差一些。知识库问答场景无论如何都用高质量模式，这是底线。上传文档支持 PDF、Word、Markdown、TXT 等常见格式，扫描版 PDF 需要先做 OCR 处理再上传，Dify 本身不带 OCR。

3.3 检索参数调优：召回数量与得分阈值

建完知识库后，在应用里接入知识库时会有两个关键参数：召回数量和 Score 阈值。召回数量默认是 3，意思是每次都取与问题最相关的 3 段内容。如果知识库文档比较长、答案分布在多个段落，建议调到 5 到 8。但也不是越多越好，召回太多会把不相关的内容塞进 Prompt，模型容易答非所问。

Score 阈值更关键，它代表相似度得分低于某个值的片段不会被召回。我建议先在“召回测试”页面逐条试问题，观察真实得分分布，再定阈值。如果发现模型经常引用无关内容，把阈值往上调；如果该回答的问题反而答不上来，往下降。这个值没有统一标准，跟你的 Embedding 模型、文档领域都有关系，必须实测。

在应用的知识库设置里，还可以选择检索方式，我通常选“混合检索”，它结合了语义检索和全文关键词检索，兼顾意图理解和精确匹配。比如用户问“请假流程”这种词，语义检索能找到“休假申请”相关片段，全文检索则能精确匹配“请假”关键词，两者融合效果明显好于单一模式。

3.4 实战案例：企业内部制度问答助手

我以一个实际交付过的企业内部制度问答助手为例，走一遍完整链路。客户提供了员工手册、差旅报销制度、考勤管理办法、信息安全规范四份文档，目标是让员工用自然语言提问，系统给出带原文引用的答复。

第一步，创建知识库“企业制度库”，分段模式选自定义，最大分段 800，重叠 50，索引方式为高质量。上传四份文档，等待解析和向量化完成。第二步，在“召回测试”里测试几个典型问题，比如“差旅住宿标准是多少”“年假可以拆分休吗”，观察召回片段是否准确，顺手调整 Score 阈值。第三步，创建聊天助手应用，在“上下文”中关联知识库，然后在 Prompt 里写清楚回答规范：只基于知识库内容回答，引用内容要标注来源章节，知识库没有的信息要明确说明未知，不得编造。

我在 Prompt 中的最后一句加了一行强约束：“如果用户问题与知识库内容无关，请礼貌告知暂不支持，不要尝试推理。”这一行对抑制幻觉非常有效。最终测试时，员工问“我入职半年能休几天年假”，系统会检索到考勤管理办法里关于年假天数的条款，并标注出自哪份制度，效果很理想。

4. 工作流实战：把“提示词”升级成可视化业务流

4.1 什么时候用工作流，什么时候用Agent

很多新手分不清工作流和 Agent 的边界。我的判断标准很简单：流程是否确定。如果业务逻辑是固定的，比如“先查知识库，再判断类型，再分流到不同模板”，用工作流；如果流程本身需要模型根据上下文动态决定调用什么工具、走哪条分支，用 Agent。

生产环境我优先推荐工作流，因为每个节点都是确定的，出问题可以精确定位到某个环节。Agent 更适合探索性场景，或者工具较多、组合方式不固定的业务。等团队对模型能力摸透之后，再逐步把高频路径固化成工作流，这也是一种稳健的演进策略。

4.2 工作流核心节点解析

Dify 工作流编辑器的核心是节点和连线，每个节点处理一个独立任务。我最常用到的节点有这几个：

LLM 节点负责大模型推理，你可以为每个 LLM 节点配置不同的模型和 Prompt，比如分类节点用一个响应快的模型，生成节点用一个效果好的模型。知识检索节点负责从知识库取相关片段，输出给后续 LLM 节点作为上下文。条件分支节点类似编程里的 if-else，根据某个变量的值决定后续走向。代码节点支持 Python 和 Node.js，可以用它做数据清洗、格式校验、调第三方 SDK，大大扩展了工作流的能力边界。HTTP 请求节点用于调用外部系统 API，可以把工作流和内部业务系统打通。模板转换节点则是把变量拼接成指定格式的文本，比如生成一段固定格式的 JSON。

变量是工作流里的数据通道。上游节点的输出会映射到系统变量里，下游节点通过 {{变量名}} 引用。理解这一点后，编排工作流就变成了选节点、配参数、连变量，本质和数据管道有点像。

4.3 完整案例：售后工单分类与自动回复

我做一个售后工单分类与自动回复的工作流，这个场景非常适合验证工作流能力。

流程设计：用户输入工单描述后，第一步用 LLM 节点做意图分类，输出结果为“退货退款”“物流咨询”“技术故障”“其他”之一。第二步接条件分支节点，根据分类结果走不同分支。每个分支各有一个 LLM 节点，用一个专门针对该场景的 Prompt 生成回复。物流咨询分支还可以额外接一个 HTTP 请求节点，调用物流系统的查询接口，把真实物流信息带进回复。最终所有分支汇合到“直接回复”节点，把结果返回给用户侧。

这里有个关键细节：意图分类的 LLM 节点不要用复杂模型，我用的是一个 7B 小模型，响应快、成本低，效果完全够用;真正生成回复的节点才用强模型。这样整个流程的响应延迟和成本都能压下来。测试时可以直接在“运行”面板输入模拟工单，查看每个节点的输入输出是否符合预期。调试没问题后，点击“发布”即可生成 API 供外部工单系统调用。

后续这个工作流我扩展了会话变量，让用户可以在多轮对话中持续追问物流进度，而不需要每次重复输入订单号。工作流的可扩展性在这里体现得很明显。

5. Agent应用与多租户：团队协作与对外输出

5.1 Agent：让模型自己决定调用什么工具

如果说工作流是“人把流程画好”，那 Agent 就是“模型自己画流程”。Dify 的 Agent 应用基于 Function Calling 机制，模型根据用户意图生成一个工具调用的结构化指令，平台去执行工具并把结果返回给模型，模型再基于返回结果组织最终回答。

在 Dify 里创建 Agent 应用后，可以给它挂工具。内置工具里有维基百科、计算器等，但这些在多数业务场景中用不上。更常用的是自定义工具，通过 OpenAPI Schema 或直接配置 HTTP 请求方式接入。比如你有一个内部订单查询接口，只需要在工具配置里定义好请求 URL、请求方法和参数 JSON Schema，Agent 就能在用户问“订单到哪了”时自动带上订单号去调用这个接口。

5.2 用Agent实现订单查询助手

我以一个订单查询助手为例说明 Agent 的落地路径。工具定义为一个订单查询 HTTP 接口，参数包含订单号和用户手机号。Agent 的 Prompt 里写了三条规则：必须同时拿到订单号和手机号才查询；查询失败时重试一次；结果要按时间倒序列出物流轨迹。然后将 Agent 应用发布为 API，前端聊天窗口接入后，用户只要说“帮我查一下订单 12345”，Agent 就会自动追问手机号，拿到后调用接口，再把结果整理成口语化表达返回。

这条链路跑通之后，你就能理解 Agent 与普通聊天助手的本质差异：聊天助手只能做文本生成，Agent 能做“感知-决策-执行-反馈”的闭环。如果后续还要对接查发票、申请售后等更多接口，只需要在 Agent 里继续挂工具，模型会根据上下文自动选择合适的工具组合，这是工作流模式难以做到的。

5.3 多租户与团队权限管理

当 Dify 从小规模试用走向团队级落地，多租户就成了刚需。社区版 1.10 开始支持多租户能力，管理员可以在后台创建多个工作空间，每个空间有独立的成员、应用、知识库和模型配置，空间之间的数据完全隔离。这个特性对服务商尤其有用：一个平台实例可以同时服务多个客户项目，每个客户在独立空间里维护自己的应用。

成员权限分管理员和普通成员。管理员可以管理系统配置、查看全局日志；普通成员默认只能访问所属空间的应用和知识库。实际操作中，我给每个项目组建一个空间，把对应客户的数据和模型供应商配置都隔离进去。这样做的好处不仅在于安全，还在于项目的资源配额可以分别控制，不会因为一个空间跑量太大拖垮整个平台。

5.4 将应用打包成API对外服务

应用调试完成后，对外提供服务最标准的方式是发布为 API。聊天助手、Agent、工作流发布后都会生成独立的 API 端点和密钥。调用方式支持同步返回和流式返回，后者适合前端打字机效果。

一个简单的流式调用示例：

curl -X POST 'http://localhost/v1/chat-messages' \ -H 'Authorization: Bearer app-xxxxxx' \ -H 'Content-Type: application/json' \ -d '{ "inputs": {}, "query": "请查一下订单12345的物流状态", "response_mode": "streaming", "user": "user-123" }'

返回内容会以 SSE 格式逐段推送，前端用 EventSource 或 fetch 读取流即可。这里提醒一点：API 密钥在代码和前端都不要硬编码，生产环境应该由后端转发请求，前端拿到的是临时会话凭证，否则密钥会直接暴露给终端用户，随时可能被刷爆额度。

6. 常见问题与排查技巧实录

6.1 部署与启动类问题速查

Dify 部署阶段的问题比较集中，我把高频的几个整理成表。

6.2 模型调用与知识库效果类问题

模型相关的问题更隐蔽，需要从日志入手。

如果应用报“模型调用失败”，先到“设置”->“模型供应商”测试对应模型是否连通，排除 API Key 过期、额度不足、模型名称错误等基础问题。如果是本地 Ollama，确认模型是否已经拉取到本地，执行 ollama list 查看。

知识库检索不到内容，最常见的三个原因：一是文档还在解析中，去知识库详情页确认“已完成”状态；二是 Embedding 模型没配置对，检索之前先跑一条“召回测试”；三是 Score 阈值设置过高，把相关片段全过滤掉了，调整阈值再试。

对于“答非所问”的情况，优先检查知识库召回的内容是否正确。可以在应用日志里查看每条用户消息实际检索到哪些片段、模型输入是什么。如果检索到的片段本来就不相关，问题在知识库侧，需要优化文档分段；如果片段相关但回答跑偏，问题在 Prompt 侧，需要加强约束。

还有一种情况值得注意：多个知识库应用共用同一个向量模型，但某些知识与问题的语义相似度天然偏低。这时候靠调阈值不如靠优化分段，把每个知识点切得更独立、表述更清晰，或者干脆把大文档拆成多个知识库，让应用按场景指定检索范围。

6.3 升级与备份

内部系统一旦跑起来，升级就成了需要谨慎操作的事。每次升级前，一定要先备份，再升级。Dify 的数据都在 Docker Volume 里，备份可以直接打包相关卷。

我常用的备份方式是把数据库单独导出：

docker compose exec db pg_dump -U postgres dify > dify_backup_$(date +%Y%m%d).sql

升级步骤不复杂：先 docker compose down 停止服务，再备份，然后更新源码到新版本，重新执行 docker compose pull 拉取新镜像，最后 docker compose up -d 启动。启动后观察日志，如果是跨大版本升级，Dify 会自动执行数据库迁移，期间不要关停服务。我踩过一次坑，跨多个版本连续升级导致数据库迁移脚本冲突，后来养成了“小步快跑”的习惯，每次只升一个版本，确认稳定后再继续，再没有出过问题。

写在最后的一点经验

从我自己的实操体会来说，Dify 这类平台最大的价值不是省掉了写代码的时间，而是把 AI 应用开发的思考方式从“怎么调接口”转变成了“怎么设计业务流程”。建议刚开始接触的朋友，先不要急着追求复杂的 Agent 和工作流，把一个聊天助手应用从建知识库到发 API 完整跑通一遍，再逐步叠加节点和工具。这个最小闭环建立起来之后，后面所有进阶玩法都会顺很多。最后再分享一个小技巧：每个应用上线前，花点时间在“日志”里把不同类型的提问都点开看一遍，错误的回答往往能暴露 Prompt 或知识库的隐藏问题，这是所有调试工具都比不上的排查手段。