Dify 应用上架门户:分享页每次回答都挂着内部流程节点?一个字段关掉
1. 业务场景
把 Dify 应用做成对外 demo,是交付环节的常规动作:做一个 AI 应用,打开「分享」开关,拿到一个链接,发给客户体验,或者嵌进自己的官网门户。
我们上架了三个应用做门户 demo:一个企业 AI 助理、一个故障诊断助手、一个验收工具。每个都打开了分享链接,放在官网首页的产品卡片里,客户点进去就能试。
2. 场景痛点
客户 demo 的时候,有人提了一个问题:「为什么每次回答,下面都挂着一段『工作流过程』?」
我们一看——分享页里,每次回答的下方都显示:
Workflow Process
开始
意图分类
检索产品服务知识库
知识问答生成
回复知识问答
对开发者来说,这是「工作流过程展示」,挺酷的功能。但对客户来说,这段东西的问题很大:
暴露内部结构:应用内部有哪些节点、路由怎么走、叫什么名字,全部摊开给客户看
像半成品:客户看到的是「开始→分类→检索→生成」这种内部流水线,而不是一个干净的产品
专业感受损:成熟产品的对话界面,不会在回答下面挂一段内部执行过程
更要命的是:这不是个别应用的问题——三个应用全部中招。我们当时一度以为是哪个应用配置错了,逐个排查才发现,这是一个平台默认值的坑。
3. 方案:一个字段的事
查 Dify
源码后定位:分享页展示工作流过程,由一个字段控制——show_workflow_steps(是否展示工作流详情)。而这个字段在数据库里的默认值是
true。
也就是说:只要是通过 API 导入创建的应用,site(分享页)配置里没有显式写这个字段,分享页就会默认展示内部工作流过程。UI 上创建的应用可能会走 UI 默认(关闭),但 API 导入的不会自动带这个字段——默认开启,裸奔展示。
修复方法很简单:把分享页配置里的 show_workflow_steps
显式设为 false。
4. 整体架构:分享页配置链路
关键点:字段没写 = 用数据库默认值 = true。不是「没配置就关闭」,而是「没配置就开启」——这正是它坑的地方。
5. 关键配置
5.1 关闭分享页工作流过程展示
调用 Dify Console API 更新应用的 site 配置:
# 读取当前 site 配置(GET /apps/{app_id} 的 site 字段)
# show_workflow_steps 当前值:true
# 更新 site 配置:关闭工作流过程展示
POST /console/api/apps/{app_id}/site
Content-Type: application/json
{
"show_workflow_steps": false
}注意:site 配置更新端点接受 POST 方法(GET/PUT 会返回 405),请求体只需要带要改的字段。
5.2 修改后必须回读验证
改完一定要回读确认,不能只看请求返回 200:
GET /console/api/apps/{app_id}
# 响应 site.show_workflow_steps 应变为 false我们三个应用逐个改、逐个回读,全部从 true 变为 false。
5.3 顺带:嵌入网页的两个路径
Dify 分享页提供「嵌入到网站中」功能,有三种形态:简单聊天窗、浮动气泡、全屏样式。生成的 iframe 代码里有一个容易混淆的点:
| 路径 | 用途 |
|---|---|
/chat/<token> |
独立分享页(单独打开) |
/chatbot/<token> |
嵌入网页专用(iframe 直嵌) |
嵌进官网门户时用 /chatbot/<token> 的
iframe,不要用独立页路径。
6. 运行验证
修复后,三个应用(企业 AI 助理 / 故障诊断助手 / 静态验收中心)的分享页全部不再展示工作流过程:
回答区域干净了,只显示对话内容和回答
客户 demo 时不再看到内部节点名
对话功能本身不受影响——只是隐藏了过程展示
注意:分享页有浏览器缓存,修改后验证记得用无痕窗口或关闭旧标签重开,否则可能看到旧页面误以为没生效。
7. 实战坑表
| 坑 | 现象 | 修复 |
|---|---|---|
| API 导入的应用分享页展示工作流过程 | 每次回答下方挂着「开始→意图分类→检索→生成」内部节点名 | show_workflow_steps 字段 DB
默认值是 true,显式设 false |
| 以为「没配置就是关闭」 | 查配置发现字段根本不存在,但功能是开启的 | 没配置 = 用默认值 = 开启;必须显式写 false |
| 只改一个应用 | 修好一个,另外两个还裸奔 | 上架的所有应用逐个核对 site 配置,批量修改 + 回读验证 |
| 改完刷新还是旧的 | 浏览器缓存了旧页面 | 无痕窗口 / 关闭标签重开验证 |
8. 总结与适用边界
核心结论:API 导入的 Dify 应用,上架分享页前必须显式设置
show_workflow_steps: false——这个字段的默认值是
true,不写就是展示内部工作流过程。 对外 demo
的每一处细节都代表产品完成度,内部节点名出现在客户面前,和代码注释没删干净是一个性质的问题。
适用场景:
任何要对外展示的 Dify 应用(分享链接、官网 demo、客户体验)
门户嵌入 iframe 时配合
/chatbot/<token>路径使用
不适用/需注意:
如果是内部团队使用的应用,展示工作流过程反而是调试友好功能,不用关
这个开关只影响分享页展示,不影响应用本身的功能与数据
本文基于真实项目交付经验撰写(Dify 1.16.x 环境)。文中数据均来自我们自己的实测记录(三个应用的 site 配置核对、修改与回读验证),不构成任何平台的官方结论。
- Dify Agent 应用实战:Beta 版「真 Agent」的能力边界实测
- dify workflow的确定性与Hermes agent skill的"确定性"对比
- Dify 意图分类节点总翻车?从 33% 失败率到兜底不崩——可靠性与韧性的三层加固
- Dify 标注回复实战:让智能客服记住人工答案的纠错闭环
- Dify 知识库元数据过滤实战:检索噪声 75% 降到 0 的确定性闸门
- 数据库里的结构化数据,怎么建立 RAG 知识库?两条路线与选型判断
- Dify 应用上架门户:分享页每次回答都挂着内部流程节点?一个字段关掉
- RAG 知识库建库前,数据到底该怎么清洗?一条可复用的清洗管线实测
- 我们的门户机器人,为什么用 Dify 答、不把 skill 搬上云端 Hermes?
- DeepSeek 思考模式什么情况下可以关?一次空输出事故的排查实录
- Dify 定时触发(trigger-schedule)实测:工作流到点自动跑,和三个必须知道的坑
- Dify 知识库三种分段模式实测:通用、父子、Q&A 到底怎么选?
- Dify 知识库接入 Notion/网页:先搞清三件事,再谈清洗
- 知识库数据清洗后,怎么知道洗得干不干净?一套三层质量门禁实测
- Dify 实战:供应商报价单格式五花八门,AI 怎么知道哪列是单价?