2026年7月2日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


我要投稿

Dify 1.15.0解读:difyctl、HITL表单和慢模型轮询,企业AI工程化继续补底座

发布日期:2026-06-26 19:42:59 浏览次数: 1516
作者:大数据流动

微信搜一搜,关注“大数据流动”

推荐语

Dify 1.15.0 版本聚焦企业AI工程化,通过difyctl、增强的HITL表单和慢模型轮询,为自动化、治理和长任务处理补强了基础设施。

核心内容:
1. difyctl将使用入口扩展至终端,推动Dify向企业AI运行时转变
2. HITL表单支持结构化输入,强化了业务流程确认与治理
3. 慢模型轮询机制,使工作流能有效处理异步长耗时任务

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
大家好,我是独孤风。
本文基于 Dify 官方 GitHub 1.15.0 release note(2026 年 6 月 25 日发布)整理,重点从企业 AI 工程化和数据治理视角看这次更新。
版本功能和升级步骤可能继续变化,实际部署和升级请以 Dify 官方 release note 和升级说明为准。
这次更新可以概括成五个关键词:
如果说 1.14.0 更像是在补“协作、HITL、安全边界”,那 1.15.0 就是在补“运行方式、长任务、知识可见性和升级治理”。
difyctl 说明了一件事:Dify 正在从 Web 工具变成运行时
这次最有分量的变化之一,是官方推出了 difyctl
它的意义不只是“多了一个命令行工具”,而是 Dify 的使用入口开始从网页扩展到终端。企业里很多动作本来就不是在后台控制台里完成的,而是在脚本、流水线、批处理和自动化任务里完成的。
difyctl 让这些场景第一次有了更自然的入口:
  • 可以从终端直接运行应用和工作流。
  • 可以被脚本和 CI 流程调用。
  • 可以把 Dify 纳入更标准的工程化链路。
  • 可以把“人工点开网页执行”变成“系统自动触发执行”。
这很关键。因为一旦 Dify 进入终端和流水线,它就不再只是一个低代码搭建器,而是会更像企业 AI 运行时的一部分。
对企业来说,这种变化意味着两个问题必须同步升级:
  • 谁可以从命令行触发哪些工作流。
  • 触发后的日志、权限和审计怎么留。
换句话说,difyctl 把“能不能自动化”这件事做得更顺了,也把“要不要治理”这件事推到了台前。
HITL 表单变强了,但它真正强化的是业务确认
1.15.0 里,HITL 表单不再只是自由文本输入,还支持:
  • 下拉选择。
  • 文件上传。
  • 多文件上传。
这个变化看起来很小,实际上很贴近企业场景。
企业里的人工确认,本来就很少只是“请输入一句话”这么简单,更多时候是:
  • 从固定选项里确认一个处理策略。
  • 上传附件、截图、审批材料。
  • 让不同角色按标准格式补全信息。
如果 HITL 只能收自由文本,它更像一个临时留言框。如果 HITL 能接结构化字段和附件,它才真正接近企业审批、工单和运营流程。
这意味着我们以后评估 HITL,不该只问“能不能暂停给人看”,还要问:
  • 人工介入时能不能收标准化字段。
  • 是否能把附件保留下来。
  • 是否能把人审结果回写到后续流程里。
只有这样,HITL 才不是一个插在流程里的“暂停按钮”,而是企业治理链路的一部分。
慢模型轮询,说明工作流开始认真面对长耗时任务
这次还有一个很实用的更新:工作流可以通过轮询机制处理慢模型,比如图片生成、视频生成这类长耗时任务。
这背后的变化是,Dify 不再默认只服务“几秒钟就能回来的回答”,而是开始面对真正的异步任务。
对企业而言,这很重要,因为很多生产场景本来就不是短问答:
  • 图片生成。
  • 报告生成。
  • 长文本总结。
  • 多步调用后的异步结果回传。
以前这种任务要么容易超时,要么要额外自己封装。现在 Dify 开始把这类慢任务纳入工作流能力本身。
但这里也要留一个判断:慢任务进入工作流,不代表工作流就自动可靠了。相反,它会要求我们更认真地设计:
  • 任务状态。
  • 超时策略。
  • 结果回传。
  • 失败重试。
  • 用户等待体验。
所以这次更新不是单纯“支持了慢模型”,而是在提醒我们:企业 AI 工作流正在从同步交互,走向异步编排。
知识和可观测性开始补“看得见”
1.15.0 在知识库和观测层面也补了几块很实用的能力。
Excel 里的图片不会再轻易丢失
官方这次修复了知识导入时对 Excel 嵌入图片的提取。
这对企业知识治理很实际,因为很多表格并不只是纯数据,还会带:
  • 流程图。
  • 截图。
  • 架构图。
  • 标注说明。
如果图片丢了,很多上下文也就丢了。对 RAG 来说,这不是小问题,而是会直接影响检索质量和回答完整度。
Trace 开始更贴近真实会话
这次还支持为 Phoenix 设置自己的 trace session id,同时能在 trace 里跟踪文档检索步骤。
这意味着排查问题时,不再只是看“模型最后回答了什么”,而是可以看:
  • 这次会话对应哪一个 trace。
  • 检索走了什么路径。
  • 哪些文档被拿出来了。
  • 最终答案是怎么拼出来的。
这类能力对数据治理团队尤其重要。因为只要 RAG 进入生产,真正需要解释的不只是“答得对不对”,还有“为什么这样答”。
生产环境补的是细节,不是口号
从这次 release note 看,Dify 1.15.0 在生产环境上做了不少细节加固。
安全和权限
官方修复了 plugin-daemon forwarding 的路径穿越漏洞(CVE-2026-41948),同时也加强了出站 HTTP 的超时边界和 SSRF 相关防护。
这类更新很适合提醒我们:企业 AI 平台一旦连上插件、外部服务、知识库和内部数据源,安全就不是附属项,而是主线。
另外,这次还强化了 RBAC、OpenAPI、插件权限和模板可见性等能力。这个方向非常明确:平台越往生产走,权限颗粒度就越不能粗。
升级治理
1.15.0 带来了新的数据库迁移,而且插件自动升级策略改成了按分类管理。官方明确要求在 flask db upgrade 之后再执行 flask backfill-plugin-auto-upgrade,否则旧租户的插件自动升级设置可能不会按预期生效。
这类升级要求看起来偏工程细节,但它其实就是企业最常见的坑:版本升级不只是拉代码,还要回填配置、校正数据、重跑迁移。
运维和稳定性
这次还补了很多让生产更稳的点,比如:
  • 更清晰的错误提示。
  • 更稳定的工作流执行。
  • 更快的停止和启动响应。
  • 更完整的通知展示。
  • 更顺手的工作流编辑体验。
这些不是最“显眼”的功能,但它们决定一个平台能不能长期用。
企业升级建议
如果你已经在用 Dify,1.15.0 值得重点看这几件事:
  1. 先在测试环境验证升级链路,尤其是数据库迁移和插件回填。
  2. 检查 .env 和 docker-compose 是否需要同步更新。
  3. 看看有没有工作流会用到 HITL、文件上传和结构化输入。
  4. 检查哪些流程会调用慢模型,提前设计轮询、超时和失败回退。
  5. 复查 RBAC、OpenAPI 和插件权限配置,不要因为版本更新就默认放宽权限。
  6. 如果你在做 RAG,拿一份带图的 Excel 或混合文档重新测一遍,确认导入和检索链路没丢上下文。
风险提醒
  • 不要把 difyctl 理解成“可以绕过治理直接自动化”。
  • 不要把 HITL 表单理解成“有人工按钮就够了”,结构化字段和审计也很重要。
  • 不要把慢模型轮询理解成“不会超时了”,异步任务一样需要状态管理。
  • 不要把知识导入改进理解成“知识库天然可信”,来源、版本和权限仍然要管。
  • 不要跳过升级后的迁移和回填步骤,尤其是插件自动升级策略。
一句话总结
Dify 1.15.0 的核心信号是:Dify 正在从一个网页里的工作流搭建器,继续走向一个可以进入终端、支持长任务、强调可追溯和重视权限治理的企业 AI 运行底座。
我正在持续整理《AI时代数据治理实战库》。
它会围绕两条主线展开:
  • Data for AI:数据如何支撑 AI。
  • AI for Data:AI 如何反过来改造数据治理。
前者是基础,后者是新机会。
如果你关心 AI 时代的数据治理、企业 AI 数据底座、RAG、Agent、元数据、血缘、质量、标准、知识图谱、本体论和企业 AI Agent 工程化,可以阅读原文查看。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询