Dify 1.18.0 发布：Agent 输出路由、可移植应用包与嵌套工作流追踪

Dify 于 2026 年 10 月 23 日发布 1.18.0：Agent 可按条件自行选择工作流分支（Output Routes），应用连同内联 Agent 与 Skill 打包为 .ifpkg 可移植包，运行历史支持下钻查看嵌套工作流的每一步，并新增命令行客户端 difyctl 与基于 OpenAPI 的应用管理；Agent Knowledge Base 为 Beta，默认不开启。

这次发布的是什么

Dify（langgenius/dify）于 2026 年 10 月 23 日在 GitHub 官方 Release 发布 1.18.0，官方标题写的是「Smarter Agent Routing, Portable Apps, Deeper Workflow Visibility」。这是该项目今年秋季的一次大版本，四条主线分别是：让 Agent 自己决定走哪条工作流分支（Output Routes）、把应用连同内联 Agent 与 Skill 打成一个可移植包（.ifpkg）、把嵌套工作流的每一步从运行历史里下钻出来，以及新增命令行客户端 difyctl 与基于 OpenAPI 的应用管理能力。

官方同时把 Agent Knowledge Base 标为 Beta —— 一个面向智能体的知识空间，可在其中查看文档处理、元数据、检索轨迹与质量评估；官方标注它将稍后上线 cloud.dify.ai。

需要提醒的是，这次升级不是无感的。官方在发布说明开头就写了「部署前先读升级指南」，并列出多处破坏性变更与数据恢复事项。

可用性与限制

• 形态：2026 年 10 月 23 日随 1.18.0 标签发布，可通过 GitHub Release 页面获取源码与说明。
• 破坏性变更：运行接口只接受 composition v2 并拒绝 v1 请求，直接对接 Agent Backend 的集成需要改请求格式；旧的 Agent AskHuman 工具与延迟恢复路径被移除，共享的 Workflow Human Input 节点仍受支持。
• 环境要求：源码部署要求 Python 3.13、Node.js 24.22.1 及以上的 24.x 版本、pnpm 12.10.1。
• 升级注意：API、worker、Agent Backend 与 Agent runtime 镜像必须一起升级；本地 Agent 沙箱需要配置高熵认证令牌，1.17.1 的运行镜像不支持新的 require-auth-token 参数。
• Agent Knowledge Base 属 Beta 且默认关闭：默认 Compose 安装不启用 KnowledgeFS，需要单独的数据库、迁移与 Dify 签名密钥，官方发布的 KnowledgeFS API 镜像目前仅提供 amd64。
• 授权：Dify 的开源许可与自托管成本以仓库与官网说明为准，本文不列具体金额。

主要功能

• 让 Agent 按条件选择工作流分支
• 把应用与内联 Agent、Skill 打成 .ifpkg 包
• 从运行历史下钻查看嵌套工作流每一步
• 用 difyctl 从命令行创建与管理应用
• 新增 Beta 版 Agent 知识空间
• 统一嵌套执行的暂停、恢复、停止与文件输出

技术原理

据官方发布说明，这次改动集中在 Agent 的编排层，而不是模型层。

Output Routes 的做法是给每个路由配一个选择条件，再把它连到下一个步骤（例如直接处理，或转给某个专员），Agent 通过只读的 switch 输出把选中的路由暴露出来，让工作流图上出现分支。普通的 Agent v2 节点也会在生成过程中流式输出文本，但结构化结果、被路由的结果以及使用默认值错误处理的节点仍保持缓冲。

可移植包方面，应用导出默认改为 .ifpkg，把应用配置和它支持的资源收进一个包里；Workflow 与 Chatflow 的包会带上内联的 Agent、它们的 Skill，以及各节点绑定配置里的文件，导入时在目标工作区重建这些资源并重新映射引用。导入同时接受文件与 URL 两种来源，也接受 YAML，YAML 导出仍然保留。

嵌套追踪的改动在工作流引擎内部：被调用的 Workflow Tool 现在作为子图运行，暂停、恢复、停止与文件输出由父子两侧协同；执行前会先捕获源工作流图，这样重新发布某个工具不会改变已经在跑的调用。官方也提醒，嵌套用量与步骤总数在暂停或停止之后仍可能只是近似值，控制台下钻与外部追踪导出的范围也不相同。

difyctl 则是新增的命令行入口。官方说明它从服务端的操作目录里发现命令，支持 Workflow 与 Chatflow 的创建、DSL 导入导出、设置、环境变量、发布与版本恢复，脚本的草稿哈希用于防止并发编辑互相覆盖。

实际体验

本文未做实测，以下是官方说明里可以逐条核对的几点。

其一，升级前后的状态是分开的两套。官方要求先备份数据库、向量库数据、上传文件、Agent 快照与工作区存储以及全部部署密钥与环境变量文件，再把 API、worker、Agent Backend 与 Agent runtime 镜像一起升级。旧的会话快照会在读取时转换成 v2，但旧运行时读不了新写入的 v2 快照。

其二，PASSWORD_PEPPER 的处理方式容易踩坑：原本没配过的实例应保持为空；升级过程中新设 pepper 不是透明迁移，需要配套明确的密码重置方案，所有实例应使用同一个值并与数据库一起恢复。

其三，difyctl 是全新的客户端，它的 v2 实现不复用 v1 的登录状态，装好后需要重新登录一次；旧的、不区分模式的应用运行接口被按模式的接口取代，脚本应改为使用服务端的命令目录，而不是硬编码 v1 路由。

其四，官方在「已有数据可能需要恢复」一节列了几项：升级前已被移除的订阅不会被草稿同步修复，需要重新绑定并重新发布受影响的工作流；文档抽取的修复不会自动作用到已有文档，需要重新导入或重建索引；内置文档元数据的改写只覆盖已开启、未归档且索引完成的数据，这一版不包含全量回填。

项目地址与获取方式

• 官方 Release：https://github.com/langgenius/dify/releases/tag/1.18.0
• 项目仓库：https://github.com/langgenius/dify
• 官方文档：https://docs.dify.ai/
• 请从官方仓库获取源码与镜像，避免使用被二次打包的版本；升级前务必按 Release 中的升级指南操作。

适合谁用

• 已经在自建 Dify 的团队：Agent 分支路由与可移植包能直接减少重复搭工作流的工作量
• 需要把应用连同 Agent 与 Skill 一起迁到另一个工作区的团队：.ifpkg 解决了「导出了配置但资源没带走」的老问题
• 想用命令行管理 Dify 应用的运维与工程团队：difyctl 让持续集成里的操作不必再走界面或自造脚本
• 不必用：只调用 Dify 云端应用、且不打算自建工作流的普通用户 —— 这次几乎全是自托管侧的能力，云端上线节奏以官方公告为准

常见问题

1.18.0 能直接覆盖安装吗？

不建议原地覆盖。官方给出了完整升级流程：先停旧栈、把配置文件里的必要改动合并进来、再拉取并启动新栈，并要求把 API、worker、Agent Backend 与 Agent runtime 一起升级。源码部署则需要用 Python 3.13、Node.js 24.22.1 及以上、pnpm 12.10.1 重新同步依赖并执行数据库迁移。

导出的应用怎么才能在另一个环境里跑起来？

用默认的 .ifpkg 格式。Workflow 与 Chatflow 的包会带上内联的 Agent、它们的 Skill 和节点绑定配置里的文件，导入时在目标工作区重建并重新映射引用。导入时缺失的资源会被报出来，YAML 导入导出仍然保留。

Agent Knowledge Base 现在能用吗？

能用，但是 Beta 且默认不开启。默认的 Compose 安装不启用 KnowledgeFS，需要单独配数据库与迁移、Dify 签名密钥、模型配置，并且要通过 /ready 检查而不只是 /health。官方标注它将稍后上线 cloud.dify.ai。

升级后老的会话还能恢复吗？

会话快照会在读取时转换成 v2，但旧运行时读不了新写入的 v2 快照。另外官方移除了旧的 Agent AskHuman 工具与延迟恢复路径，历史 Agent 表单不会恢复执行，共享的 Workflow Human Input 节点仍然可用。

相关工具与内容

• Dify 工具页
• Dify 深度评测
• AI 智能体
• AI 编程
• Coze 工具页
• OpenAI 前沿模型训练不再接入实时互联网