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

Dify 1.15.0 版本聚焦企业AI工程化，通过difyctl、增强的HITL表单和慢模型轮询，为自动化、治理和长任务处理补强了基础设施。
核心内容：
1. difyctl将使用入口扩展至终端，推动Dify向企业AI运行时转变
2. HITL表单支持结构化输入，强化了业务流程确认与治理
3. 慢模型轮询机制，使工作流能有效处理异步长耗时任务

大家好，我是独孤风。本文基于 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 工程化，可以阅读原文查看。