发布日期：2026 年 10 月 25 日
版本号：1.18.0
Dify 1.18.0 是一次覆盖 Agent、工作流、知识库、应用交付、命令行管理、可观测性、安全性与部署运维的大版本更新。
本次更新最值得关注的核心能力包括：让 Agent 自动决定工作流下一步分支的输出路由能力、可携带资源的一体化应用包、嵌套工作流的运行追踪下钻、处于 Beta 阶段的 Agent Knowledge Base，以及基于 OpenAPI 和 difyctl 的应用构建与运维能力。
与此同时，1.18.0 对 Agent 后端运行协议、本地沙箱认证、密码哈希配置、代理边界、KnowledgeFS 部署方式和源码环境要求都进行了重要调整。因此，对于自部署用户来说，这不仅是一次功能升级，也是一轮必须认真评估的架构升级。
一、Agent 可以自己决定工作流下一步怎么走
在过去，工作流的分支逻辑通常由条件判断节点、变量判断或固定流程控制。Dify 1.18.0 引入 Agent Output Routes 后，Agent 不再只是生成文本或结构化结果，而是可以根据任务处理结果，主动选择下一条工作流分支。
例如，一个客服自动化工作流可以设计两个出口：
当用户提交问题后，Agent 会根据当前请求的复杂程度、是否需要人工介入、是否涉及特定专业领域等条件，选择对应路由。选择结果可以通过只读的 switch 输出查看，方便开发者在后续节点中进行处理、记录和调试。
启用输出路由时，需要至少配置两个分支，并为每一个分支填写对应的选择条件。每条路由都可以连接到不同的后续步骤。例如：
这种能力让 Agent 在工作流中的角色从“单纯执行任务的节点”进一步升级为“具备流程决策能力的节点”。
需要注意的是，输出路由启用后，Agent 节点的行为也会发生变化：
1.18.0 同时改善了普通 Agent v2 节点的流式能力。对于不使用结构化输出、不使用输出路由、也未配置默认值错误处理的普通 Agent v2 节点，模型生成文本时可以边生成边输出，减少用户等待完整回答的时间。
但以下情况仍会保持缓冲模式：
这是因为这些场景需要等待模型完整执行完成，确保结构化内容、路由选择或备用值替换正确生效。
二、应用终于可以“一包带走”：全新 ifpkg 可移植应用包
应用迁移、备份、跨环境交付一直是工作流平台的重要需求。Dify 1.18.0 将应用导出的默认格式升级为 .ifpkg，用于实现更完整、更可靠的应用可移植能力。
此前，很多团队在导出工作流时只获得 YAML 配置，导入到另一个工作空间或环境后，往往还需要手动补齐 Agent、技能、文件、节点资源、图标、站点配置和插件依赖。这不仅耗时，还容易产生资源引用丢失、环境不一致或配置遗漏等问题。
新的 .ifpkg 包可以将应用及其支持资源一起带走。
工作流和聊天流应用包可包含：
在导入 .ifpkg 后，系统会在目标工作空间重新创建对应资源，并自动重新映射资源引用关系。也就是说，原本绑定在节点上的 Agent、技能、文件等资源不再只是简单引用，而是能够被随应用包迁移并在目标环境中重建。
这对于以下场景非常有价值：
在导入方式上，Dify 1.18.0 同时支持：
YAML 导出仍然保留，适合需要查看、审核、版本管理或通过文本方式维护应用配置的开发者。但对于完整迁移和资源携带场景，.ifpkg 将成为默认且更推荐的选择。
导入时，如果包内依赖的资源在目标环境中无法完整恢复，系统会报告缺失资源，避免用户在不知情的情况下导入一个无法正常运行的应用。
此外，Agent 导出现在可以选择已发布版本。Agent 的版本菜单也增加恢复能力。恢复动作会等待当前未完成的草稿保存结束，避免自动保存覆盖刚刚恢复的配置。技能复制和导出时，也会使用最新已保存的草稿内容。
三、嵌套工作流终于可追踪：从父流程一路看到子流程内部执行
工作流工具调用另一个工作流，是构建复杂自动化系统的重要方式。例如，主流程负责接收用户请求和整体编排，子流程分别负责知识检索、订单查询、文档生成、数据分析或人工审批。
但过去，调用工作流工具后，开发者可能只能看到外层调用结果，不容易深入查看子工作流内部的每一个节点是如何运行的。
Dify 1.18.0 对此进行了重要升级：被调用的 Workflow Tool 将作为子图运行，并且可以在运行历史中直接下钻查看内部执行轨迹。
这意味着，在主工作流运行历史中，开发者可以打开某一次工作流工具调用，进入子工作流，查看其中每一个节点的执行状态、输入输出、失败信息和整体链路。
新的嵌套执行机制支持：
更重要的是，子工作流的源图会在执行前被捕获。因此，即使被调用的工具工作流在运行期间被重新发布，当前已经启动的任务仍然会继续使用启动时所捕获的版本，不会被后续发布影响。
这对于生产系统非常关键。它避免了“一个正在运行的任务，因为别人发布了新版本而行为突然变化”的问题。
不过，嵌套调用的权限边界也更加严格。用户想要查看某个被调用工作流的内部详情，必须拥有源应用的访问权限。没有权限时，系统不会返回该源应用的详细信息。
在可观测性方面，嵌套 Agent 日志和用量记录会保留源工作流身份，以及其与外层运行之间的关联关系。
需要注意的是，嵌套运行中的用量统计和步骤总数在某些情况下仍可能是近似值，特别是在发生暂停或停止后。控制台中的运行下钻和外部追踪导出的范围也不完全一致。被调用工作流工具内部节点不会导出到外部追踪系统，因为外部导出没有用于验证源应用访问权限的查看者身份。
同样，位于这些被调用工作流工具内部的 Agent，目前也不会参与新的执行树外部导出。不过，具有权限的用户仍然可以在控制台中完成内部执行下钻。
四、Agent Knowledge Base Beta：为 Agent 构建独立知识空间
Dify 1.18.0 带来了处于 Beta 阶段的 Agent Knowledge Base，也就是面向 Agent 的新一代知识空间体验。
传统知识库仍然可以继续使用，而新的知识库能力建立在独立的 KnowledgeFS 服务之上。它为 Agent、知识检索节点、文档处理、检索记录、质量评估和访问控制提供更统一的底层能力。
在新的知识空间中，用户可以：
新的 Knowledge Retrieval 节点与 Agent 知识绑定共享基于权限范围的 KnowledgeFS 空间。对于已发布的 Explore 运行，系统可以复用已发布的绑定关系，不要求普通查看者重新配置权限。
需要强调的是，KnowledgeFS 是一项需要明确选择启用的独立服务，不是默认 Compose 部署中自动启用的能力。
启用前需要准备：
KnowledgeFS 服务必须通过 /ready 检查，而不只是 /health 检查。
标准 Dify API 镜像并不包含可选引擎工作器配置所需的独立 KnowledgeFS 引擎。当前发布的默认 KnowledgeFS API 镜像仅支持 amd64 架构。因此，计划启用新知识库能力的团队，需要在部署前确认服务器架构和服务拆分方案。
对于传统知识库，1.18.0 也带来了升级改进，包括：
启用新知识服务并不会自动迁移所有传统数据集。已有经典知识库不会因为升级而自动切换为新知识空间。
五、OpenAPI 与 difyctl：从命令行构建、导入、发布和恢复应用
Dify 1.18.0 将应用管理能力进一步开放给自动化脚本、开发工具和智能体。
/openapi/v1 现在提供服务端操作目录。difyctl 不再仅依赖固定命令，而是可以从服务器发现支持的命令、输入字段和后续操作步骤。
新的 difyctl 支持搜索式帮助，并覆盖 Workflow 与 Chatflow 的核心管理能力，包括：
草稿哈希是本次升级中很实用的一项保护机制。它可以防止在导入配置时，错误覆盖其他用户刚刚修改但尚未同步的草稿内容。
difyctl 还内置了一个面向构建 Dify 应用的技能包，可以安装到指定目录，帮助 Agent 更好地理解和操作 Dify 应用构建流程。
需要特别注意，1.18.0 的 difyctl v2 不会复用旧版本的登录状态。升级客户端后，用户需要重新登录。
此外，旧的通用应用运行接口已被按应用模式划分的新操作替代。脚本和集成不应该继续硬编码旧版接口路径，而应基于服务器提供的操作目录发现和调用当前支持的接口。
工作空间所有者还可以创建资源访问令牌，并将令牌限定到指定应用或指定知识库。此类令牌适用于受支持的服务 API 路由和 difyctl 应用操作，但不具备工作空间管理权限。
资源访问令牌设置入口默认关闭，需要通过前端环境变量显式启用。
六、Sandbox 可以直接拉取和推送 Agent 系统提示词
Dify 1.18.0 为 Agent Sandbox 增加了系统提示词读写能力。
开发者可以通过命令拉取当前系统提示词，也可以推送新的系统提示词内容。该能力会原样保留 UTF-8、空白字符和提及标记。
支持的使用场景包括：
该能力仅允许修改当前账户可写的构建草稿。保存后，后续请求将使用新保存的提示词。
七、Agent 执行追踪更深入，监控与外部可观测性能力增强
本次版本新增 Agent 应用和 Workflow Agent v2 节点的执行树导出能力。
Agent、模型和工具执行过程可以通过现有追踪提供方导出。监控模块新增了共享追踪配置、投递状态、重试控制，以及跳转到当前选定执行对应追踪记录的链接。
如果 Agent 被工作流引用，它会继承调用方工作流的追踪策略。
追踪能力需要在 API 和 Agent Backend 两端主动启用。与此同时，系统也支持独立于系统追踪配置的全局 OTLP 轨迹导出器。
需要再次说明，嵌套 Workflow Tool 内部节点以及其内部 Agent 暂时不会进入外部执行树导出范围。原因是外部追踪系统无法持有用于源应用访问校验的查看者身份。此类情况仍然以控制台内的权限化下钻查看为主。
八、OpenShell 与 E2B：Agent 沙箱运行和资源计量能力扩展
Dify 1.18.0 支持将 Agent 执行环境接入自托管 NVIDIA OpenShell 网关。
当运行时后端设置为 OpenShell 后，每个绑定关系将拥有独立沙箱，并具备以下能力：
使用该能力需要满足 OpenShell 网关版本和运行时镜像兼容性要求。
需要注意，OpenShell 的租约释放仅会关闭连接，不会自动停止沙箱。系统没有自动空闲停止机制，也没有沙箱 TTL。运维团队必须自行管理沙箱生命周期和资源消耗。
多租户部署时，不同租户需要分别配置 OpenShell 工作空间和快照卷，以避免数据与运行环境混用。
此外，系统还增加了可选的 E2B 用量采集能力。该功能会通过 Celery Beat 和 ops_trace 队列记录供应商执行时长及资源规格。
该采集能力具有以下特点：
九、云端访问控制、模板体验与日志归档管理
对于支持的云端部署，1.18.0 引入可复用网络访问组。多个应用可以共享 IP 规则，并提供权限检查、有效策略状态和可信客户端 IP 预览。
但这项能力依赖云端策略服务和网关，并不是社区版或企业版自部署环境中的独立防火墙功能。
云端用户现在还可以预览和试用已发布的 Agent 模板，然后再决定是否导入。由于模板数据源属于云端能力，社区版和企业版中会隐藏从模板创建 Agent 的入口。
在云端工作流日志归档方面，工作空间所有者可以永久删除指定月份的归档记录。删除操作会提供确认、进度与重试机制，并清理归档对象和已生成的 ZIP 下载文件。
需要注意，归档删除不影响实时工作流运行记录。若删除任务失败，系统会进入重试策略，而不是错误地显示为成功。
十、性能、体验、国际化与运维改进
在知识库性能方面，1.18.0 优化了数据集列表与索引状态查询，减少批量查询开销。分段导入避免重复位置查询，检索和结果后处理也减少了重复查找。
在加载性能方面，系统进行了多项前端优化：
在导航和无障碍体验方面，更新包括：
浮动菜单、选择器、弹出框和工具提示统一使用 Base UI 定位能力，相关对齐与偏移配置也完成迁移。
日期、时间和图标选择器也获得升级：
国际化方面，新增阿塞拜疆语界面支持，并继续改善翻译质量与从右向左布局体验。
开发工具方面，TypeScript 检查进一步加速，同时新增类型化的 Document 和 CustomizedSnippet 模型，并保持原有构造器和数据库默认值兼容。
运维方面，归档存储支持配置 S3 地址风格。API 镜像已包含 spaCy 模型，启动时无需下载。工作流生成日志也会标识因目录容量限制而被省略的工具。
十一、安全升级：沙箱认证、密码保护、权限边界全面收紧
安全是 Dify 1.18.0 升级中必须重点关注的部分。
本地沙箱认证方面，启用 Local 运行时后，不再允许使用空认证令牌。必须为本地沙箱提供高熵随机密钥。
启用路径隔离时，如果 Landlock 初始化失败，任务会在执行用户代码前终止，并以退出码 125 结束。这样可以避免隔离机制失败后仍继续执行不受保护的用户代码。
密码哈希方面，系统引入可选的 PASSWORD_PEPPER。它是额外加入账户密码哈希的服务端秘密值。
但该项配置必须谨慎处理：
插件权限方面，当没有保存显式策略时，插件安装默认只允许工作空间所有者和管理员进行。已有保存策略不会被自动覆盖。
访问边界方面，本版本还包括：
在启用 RBAC 的部署中，新创建的知识库不再默认自动包含工作空间所有成员。
错误与插件处理方面，API 和 Webhook 失败时会返回固定的公开错误消息，而不再暴露内部异常细节。插件守护进程请求也使用固定的软件包标识。
依赖层面，内置 Weaviate 从 1.39.2 更新到 1.39.13，仍处于 1.39 系列内。如果当前实例仍使用 1.27 系列 Weaviate，则必须先完成此前版本要求的分阶段升级。
Agent 的证书信任包已更新，重新构建 Agent 镜像后才能使用新的信任包。NLTK 也升级到 3.10.4，以改善上游路径处理安全性。
十二、部署升级必须注意的关键事项
升级到 Dify 1.18.0 前，首先必须完成完整备份，至少包括：
建议在维护窗口中完成单栈升级。
Agent API、Worker、Agent Backend 和 Agent Runtime 镜像必须一起升级。新的运行接口接受 composition v2，不再接受 v1 请求。
已有会话快照会在读取时转换为 v2，并以 v2 格式保存。一旦保存为 v2，旧运行时将无法读取。因此，不能让旧版运行时与新版 Agent 后端混合运行。
如果系统存在直接集成 Agent Backend 的外部服务，也必须同步更新请求格式。
旧版 Agent 专用 AskHuman 工具和延迟恢复路径已经移除。历史 Agent 表单将无法继续恢复执行。共享工作流 Human Input 节点仍然支持。
升级时还需要先处理旧版工作流消费者。应等待正在执行的任务完成，然后替换旧 Worker 和旧恢复消费者，避免它们继续从共享队列消费任务，因为旧版本不具备新版取消保护机制。
对于暂停任务，如果有效的调用快照仍存在，可以在现有访问范围内恢复旧任务标识。快照缺失或无效时，需要单独进行恢复处理。
本地沙箱认证令牌需要在重启前配置。应通过共享 Compose 插值来源提供高熵密钥。旧版 1.17.1 运行时镜像不支持新的认证令牌要求，因此必须配套部署 1.18.0 Agent Backend 与 Local Sandbox 镜像。
代理边界同样需要检查。内置 Nginx 会将 X-Forwarded-For 替换为解析后的客户端地址，Compose 也会启用转发头处理。
因此：
十三、Docker Compose、源码部署与命令行升级方式
对于 Docker Compose 部署，在 1.18.0 镜像和标签可用后，应优雅停止旧服务，切换到对应版本，合并必要环境变量，再拉取和启动新服务。
升级过程中应保持数据库迁移开启，或者在启动新 Worker 前通过受控迁移流程完成数据库升级。
如果从仍使用 Weaviate 1.27 的旧版本升级，必须先完成此前要求的 Weaviate 分阶段升级，再进入本次版本升级。
对于源码部署，API 需要使用 Python 3.13，前端需要使用 24.x 系列中符合要求的 Node.js 版本，并使用指定版本的 pnpm。
升级过程需要刷新锁定依赖、执行数据库迁移、重新构建 Web，并从同一版本重新启动 API、Worker、Scheduler 与 Agent 服务。
如果 Agent Backend 采用独立源码部署，也需要刷新其锁定的服务端依赖。
对于 difyctl，需要安装与服务端匹配的 1.18.0 客户端版本，并重新登录。脚本应迁移到服务端发现的当前命令能力，不再依赖硬编码旧接口。
十四、已有数据可能需要人工恢复或重新处理
本次升级并不会自动修复所有历史数据问题，以下内容可能需要后续人工处理。
已发布触发器方面，草稿同步修复只能避免未来继续丢失订阅关系，无法自动修复升级前已经被删除的订阅。对于缺失订阅的工作流，需要重新绑定订阅关系，并按需重新发布。
文档提取方面，已有受影响内容需要重新导入或重新建立索引，才能应用新的提取修复。
内置文档元数据方面，切换内置字段时，只会重写已启用、未归档且索引完成的文档。其他历史记录可能保留旧格式，需要等到满足条件后再重写。本版本没有提供一次性完整回填。
十五、工作流与调度系统修复内容
在协作编辑和导入图结构方面，系统会保留 LLM 提示词和模型修改，并修正导入图同步逻辑。
代码生成能力也得到多项修复，包括：
当将 Chatflow 内容粘贴到 Workflow，或在编辑器中加载保存 Workflow 图时，系统会移除不受支持的聊天流记忆设置。需要注意，已发布版本和仅通过 API 创建的流不会被这个编辑器修复自动重写。
Code 节点方面，删除、增加或重命名输出时，已配置的备用值会得到保留。保存空画布前需要用户确认。运行中的工具文件访问权限也会保留给后续节点使用。
任务所有权和停止意图将被持久化，避免延迟写入或并发恢复操作让一个已经停止的工作流重新被激活。
异步触发器分发失败时，触发器日志会记录为失败。恢复执行后，耗时统计也会保持一致。
定时的即发即弃分发不再为每个任务组创建 Redis 结果后端清理器，从而避免空闲结果连接不断累积。触发器刷新和流水线分发也同步获得该修复。
草稿编辑不再删除已发布触发器订阅。该修复能阻止未来产生新的损坏，但不会重建升级前已经丢失的关系。
调度节点会保存新建时显示的时区，正确处理夏令时转换、下次执行时间计算、时区偏移标签以及跨月边界下的小时级预览。
结语：1.18.0 不只是功能更新，而是 Dify 工程化能力的一次跃升
代码地址：
github.com/langgenius/dify
Dify 1.18.0 的价值，不只在于增加了几个新节点或几个新按钮。
Agent Output Routes 让 Agent 可以参与流程决策，.ifpkg 让应用真正具备可交付和可迁移能力，嵌套工作流下钻让复杂自动化链路不再是黑盒，KnowledgeFS 为下一代 Agent 知识管理提供了新的基础，OpenAPI 与 difyctl 则让 Dify 应用走向更完整的自动化构建与运维体系。
对于普通使用者，这个版本意味着更强的应用构建能力。
对于工作流开发者，这个版本意味着更灵活的 Agent 编排、更清晰的嵌套追踪和更可靠的发布迁移。
对于企业部署和运维团队，这个版本意味着需要更加重视组件协同升级、密码配置继承、代理信任边界、沙箱认证和知识库服务拆分。
如果准备升级到 Dify 1.18.0，最重要的原则是：先备份、再评估、统一升级 Agent 组件、确认配置兼容性、在维护窗口中完成发布，并针对历史触发器、文档与元数据做好后续恢复计划。
·
我们相信人工智能为普通人提供了一种“增强工具”，并致力于分享全方位的AI知识。在这里，您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。
欢迎关注“福大大架构师每日一题”，发消息可获得面试资料，让AI助力您的未来发展。
·
更新时间：2026-10-29
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight All Rights Reserved.
Powered By 61893.com 闽ICP备11008920号
闽公网安备35020302034903号
