写代码搭 AI 应用是一种方式,但不是每个场景都值得从头写。特别是一些标准化的需求——客服问答、文档总结、数据提取——用可视化工具拖拖拽拽可能更高效。
Dify 就是这样一个平台。它提供了可视化的工作流编辑器,让你不写一行代码就能搭建 AI 应用。关键是它支持对接自定义模型,我们可以把本地的 Hermes 接进去。
Dify 是什么
Dify(Do It For You)是一个开源的 LLM 应用开发平台。你可以理解为它是 AI 应用的低代码工具。核心功能:
- 可视化工作流编辑器:拖拽式搭建 AI 处理流程
- 知识库管理:上传文档,自动做 RAG
- 多模型支持:接入各种 LLM 和嵌入模型
- API 发布:搭好的应用一键发布成 API
- 内置应用模板:聊天助手、文本生成、Agent 等
跟直接用 LangChain 写代码比,Dify 的优势是快,劣势是灵活性受限。简单需求用 Dify,复杂需求用代码,这是比较合理的分工。
部署 Dify
Docker Compose 部署
Dify 官方推荐用 Docker Compose:
1 | # 克隆仓库 |
Dify 会启动好几个服务:Web 前端、API 后端、Worker、数据库、Redis、向量数据库等。完整启动后大概需要 4-6GB 内存。
启动完成后访问 http://localhost/install,按照向导完成初始设置。
检查服务状态
1 | docker compose ps |
所有服务都是 Up 状态就没问题。
对接 Hermes 模型
方式一:通过 Ollama 对接
这是最简单的方式。确保 Ollama 跑着 Hermes:
1 | ollama list # 确认有 hermes3:8b |
在 Dify 中配置:
- 登录 Dify 后台
- 进入 “设置” -> “模型供应商”
- 找到 “Ollama”
- 点击添加模型
- 填写配置:
- 模型名称:
hermes3:8b - 基础 URL:
http://host.docker.internal:11434(Docker 环境)或http://localhost:11434(本地环境) - 模型类型:LLM
- 上下文长度:8192
- 模型名称:
如果 Dify 和 Ollama 都在 Docker 里但不在同一个 compose 网络中,需要处理网络互通问题:
1 | # 方案1:用宿主机网络 |
方式二:通过 OpenAI 兼容 API 对接
如果你的 Hermes 是通过 vLLM 部署的:
- 在模型供应商里找到 “OpenAI-API-compatible”
- 配置:
- API Key:随便填一个
- API Base URL:
http://your-vllm-server:8000/v1 - 模型名称:
NousResearch/Hermes-3-Llama-3.1-8B
配置嵌入模型
做知识库问答还需要一个嵌入模型。同样通过 Ollama:
- 先在 Ollama 上拉取嵌入模型:
1 | ollama pull nomic-embed-text |
- 在 Dify 模型配置里添加:
- 模型名称:
nomic-embed-text - 模型类型:Text Embedding
- 基础 URL:同上
- 模型名称:
创建第一个聊天助手应用
基础配置
- 在 Dify 首页点击 “创建应用”
- 选择 “聊天助手” 模板
- 命名你的应用,比如 “Hermes 技术助手”
- 在应用配置页面:
- 选择模型为
hermes3:8b - 设置系统提示词
- 选择模型为
系统提示词示例:
1 | 你是一个专业的技术助手,专注于帮助开发者解决编程和架构问题。 |
调整参数:
- Temperature:0.5(技术场景偏低)
- Max Tokens:2048
- Top P:0.9
点击 “发布”
发布后你会得到一个可以分享的聊天链接,也可以通过 API 调用。
搭建知识库问答应用
这是 Dify 最有价值的功能之一。
创建知识库
- 在左侧菜单找到 “知识库”
- 点击 “创建知识库”
- 上传文档(支持 PDF、TXT、Markdown、DOCX、CSV 等)
配置索引参数
上传文档后,Dify 会自动处理:
切分设置:
- 块大小:推荐 500-1000
- 块重叠:推荐 50-100
- 分隔符:默认按段落和句号切分
索引模式:
- 高质量模式:用嵌入模型做向量索引(推荐)
- 经济模式:用关键词索引(不需要嵌入模型但效果差些)
嵌入模型:选择之前配好的 nomic-embed-text
点击 “保存并处理”,等文档处理完成。
创建知识库问答应用
回到应用列表,创建新的聊天助手
在应用配置里启用 “上下文” 功能
关联你刚创建的知识库
配置检索参数:
- Top K:5(检索最相关的5个文档块)
- Score 阈值:0.5(低于这个相关性的不要)
- 检索模式:混合检索(向量 + 关键词)
设置带 RAG 的系统提示词:
1 | 你是一个文档问答助手。基于提供的上下文信息回答用户的问题。 |
搭建 AI 工作流
工作流是 Dify 的核心特色功能。它允许你把多个 AI 处理步骤串联起来。
示例:文章摘要 + 翻译工作流
需求:输入一篇英文文章 URL,自动提取内容、生成中文摘要、提取关键词。
创建应用时选择 “工作流” 类型
在工作流编辑器中添加节点:
节点1:开始
- 输入变量:
article_url(字符串类型)
节点2:HTTP 请求
- 方法:GET
- URL:
{{article_url}} - 输出:
raw_content
节点3:LLM - 内容提取
- 模型:hermes3:8b
- 提示词:
1 | 从以下 HTML 内容中提取文章正文,去掉导航栏、广告等无关内容。只返回纯文本正文。 |
- 输出:
article_text
节点4:LLM - 生成摘要
- 模型:hermes3:8b
- 提示词:
1 | 请为以下文章生成一段200字左右的中文摘要。摘要需要包含文章的核心观点和关键信息。 |
- 输出:
summary
节点5:LLM - 提取关键词
- 模型:hermes3:8b
- 提示词:
1 | 从以下文章中提取5-8个关键词,用中文,以逗号分隔返回。 |
- 输出:
keywords
节点6:结束
- 输出变量:
summary,keywords
- 连接各节点,发布工作流
示例:客服自动分类 + 路由
更复杂一点的工作流:
需求:用户提问进来后,先判断问题类型,然后路由到不同的处理逻辑。
节点1:开始
- 输入:
user_question
节点2:LLM - 问题分类
- 模型:hermes3:8b
- 提示词:
1 | 将以下用户问题分类为以下类别之一: |
节点3:条件判断
- 如果分类结果包含 “technical” -> 走技术处理分支
- 如果分类结果包含 “billing” -> 走账单处理分支
- 其他 -> 走通用处理分支
技术分支节点:LLM
- 关联技术文档知识库
- 用 RAG 模式回答技术问题
账单分支节点:LLM
- 关联账单 FAQ 知识库
- 生成标准回复
这种工作流在 cocoloop 社区里有人分享过更完善的版本,包含了人工介入的分支,感兴趣可以去看看。
API 调用
每个 Dify 应用发布后都有 API 端点。
获取 API Key
在应用设置 -> “访问 API” 里获取 API Key 和端点地址。
调用示例
1 | import requests |
流式响应版本:
1 | import requests |
调用工作流
1 | response = requests.post( |
生产环境配置
性能优化
如果用 Dify + Ollama 的组合,瓶颈通常在模型推理速度。几个优化方向:
- 用 vLLM 替代 Ollama:高并发场景下 vLLM 的吞吐量大很多
- 调整 Worker 数量:在
.env里设置CELERY_WORKER_CONCURRENCY=4 - Redis 缓存:Dify 自带 Redis,确保给够内存
安全加固
1 | # .env 文件里设置 |
备份
1 | # 备份数据库和向量存储 |
局限性
Dify 不是万能的,有些场景它搞不定:
- 复杂的代码逻辑:工作流的条件判断和数据处理能力有限
- 实时性要求高的场景:每个节点调用 LLM 都有延迟,节点多了就会很慢
- 高度定制的 UI:Dify 的前端界面定制程度有限
如果你的需求超出了 Dify 的能力范围,考虑用 LangChain 或者 AutoGen 这种更灵活的框架。
Dify 的定位很明确:让不写代码的人也能搭 AI 应用,让写代码的人在简单需求上能更快交付。搭配 Hermes 模型,你可以在完全不依赖任何外部 API 的情况下,快速搭出各种 AI 应用的原型甚至生产版本。数据安全、成本可控,这在很多企业场景下是刚需。