Dify 1.18.0 发布：Agent 学会了自己「选路」，应用终于能「一包带走」

Agent 输出路由：让 Agent 从「执行者」变成「决策者」

过去工作流分支只能靠「条件判断节点」写死，需求一复杂就变成难维护的蜘蛛网，判断逻辑是死的、无法理解语义。

1.18.0 引入 Agent 输出路由（Output Routes）：给 Agent 节点开启路由，配至少两个分支，每个分支写一个选择条件，再接到不同后续节点。Agent 会按请求复杂度、是否需要人工介入、是否涉及特定领域，主动选择对应路由，选择结果通过只读 switch 输出暴露。

注意：启用路由后结果走缓冲模式，不即时流式输出；且不支持节点级默认值错误处理。同一版本里，普通 Agent v2 节点文本可边生成边流式输出。

.ifpkg 可移植应用包：迁移不再手动补资源

以前导出只有一份 YAML，导入后 Agent、技能、文件、图标、插件依赖全要手动补齐，耗时还容易丢引用。

1.18.0 默认导出格式升级为 .ifpkg，把应用与依赖资源一起打包：应用配置、工作流图、内联 Agent、技能、关联文件、资源快照、图标、站点配置、插件依赖、引用关系。导入时在目标工作空间重建资源并自动重映射引用；缺资源会主动报告。

典型场景：开发→测试→生产迁移、团队模板分发、离线备份、客户交付、私有化实例间迁移。

嵌套工作流下钻：从父流程看到子流程内部

工作流调工作流（Workflow Tool）是标配，但过去只能看到外层结果，子流程内部每个节点怎么跑、在哪挂了，完全看不见，排障靠猜。

被调用的 Workflow Tool 作为「子图」运行，支持在运行历史中直接下钻查看节点级执行轨迹（状态、输入输出、失败信息、整体链路）。

最实用的一点：版本快照。子工作流源图在执行前捕获，运行期间重新发布不影响已启动任务，避免「跑一半因别人发新版而行为突变」。

注意：下钻受源应用访问权限保护；嵌套用量统计在暂停/停止后可能仍是近似值。

Agent Knowledge Base（Beta）：给 Agent 建独立知识空间

传统知识库与 Agent 割裂，检索、文档处理、质量评估、权限控制分散各处。

1.18.0 带来面向 Agent 的新一代知识空间，建立在独立 KnowledgeFS 服务之上，统一知识检索、文档处理、检索记录、质量评估与访问控制。

部署要点（Beta，非默认开启）：KnowledgeFS 是独立服务+独立数据库，需显式启用；服务必须过 /ready 检查；默认镜像仅支持 amd64；启用后不会自动迁移传统数据集。

OpenAPI + difyctl：命令行管理应用

1.18.0 把 /openapi/v1 升级为服务端操作目录，difyctl 动态发现可用命令，覆盖 Workflow/Chatflow 的创建、DSL 导入导出、设置、环境变量、发布、版本恢复，并内置 草稿哈希 防并发覆盖，以及「构建 Dify 应用」技能包（difyctl install skills）。

注意：difyctl v2 不复用旧登录态，升级后要重新登录；旧通用运行接口已被新模式操作替代，脚本别硬编码旧路径。

其他更新与自部署升级避坑清单

· Sandbox 系统提示词读写（拉取/推送，保留 UTF-8、空白、提及标记）
 · Agent 执行树导出到追踪系统，监控新增共享追踪配置、投递状态、重试控制
 · 自托管 NVIDIA OpenShell 网关 + 可选 E2B 用量采集（默认关闭）
 · 云端：可复用网络访问组、Agent 模板预览试用、日志归档永久删除

1.18.0 是破坏性升级，升级前确认这 5 点：
1. 组件一起升级：API、worker、Agent Backend、Agent runtime 镜像必须同步。
2. 先备份：数据库、向量库、上传文件、Agent 快照、密钥与 env 文件。
3. Python 3.13：源码部署需 Python 3.13；/runs 现接受 composition v2、拒绝 v1。
4. 沙箱 token：本地沙箱要求非空认证 token，1.17.1 runtime 不支持新参数，升级顺序要理清。
5. PASSWORD_PEPPER 别丢：旧 Agent 专属 AskHuman 工具与延迟恢复路径已移除。

建议用维护窗口做单栈升级，先让 in-flight 任务跑完，再换新 worker。