Dify 1.18 上线：Agent 路由工作流与可移植应用包

Dify 1.18 这版的主题很集中：让 Agent 不再是一条线跑到底，而是能自己决定下一步走哪，同时把"一个应用"变成"一个能带走的包"。对正在用 Dify 搭 Agent 工作流的团队来说，这版的几个能力是有实质用处的，但有一个功能要掂量清楚再开。

这次更新的主线

1.18 相对 1.17.1 有 132 个 commit，四条主线：Agent 输出路由、可移植应用包、嵌套工作流可见性，以及一个可选的 Agent Knowledge Base（Beta）。前三个是工作流能力本身的增强，最后一个是需要单独部署服务才能用的新体验。

Agent 输出路由

这是本版最值得关注的能力，官方叫 Agent Output Routes。之前 Agent 节点跑完只有一个出口，接死到下一个节点；现在可以让 Agent 根据执行结果选择走哪条分支——比如直接解决请求，或者把请求转给某个"专员"工作流。

启用后，每个路由要设选择条件，连接到一个只读的 switch 输出，Agent 完成任务时用它来暴露自己选了哪条路。这是把"路由决策"从人身上挪给了 Agent 自己。代价是：启用路由后，节点级的默认值错误处理不可用，出错要么停要么走失败分支。对流程复杂、分支多的场景有用，简单流程用不上。

可移植应用包

应用的导出格式变了，默认从 YAML 变成 .ifpkg 单文件包。这个包会内联带上 Agents、Skills 以及它们的文件，导入到另一个工作区时自动重建这些资源并重新映射引用。文件和 URL 两种导入方式都支持，显式导出 YAML 也还留着。

对做交付的人，这意味着一个应用连同它依赖的 Agent 和技能可以整体搬走，不用再手工对齐各个散件。缺失的资源在导入时会明确报出来，比之前静默丢东西强。

嵌套工作流可见性

之前一个 Workflow Tool 被调用，里面发生了什么在外面看不见。现在嵌套工具作为子图运行，从运行历史里点开某个 Workflow Tool 调用，就能下钻看子工作流的每一步，还带了协调的暂停、恢复、停止能力。源应用的信息有访问检查保护，不是谁都能看。

一个已知限制要记着：嵌套的用量和步骤总数可能是近似值，尤其在暂停或停止之后。

Knowledge Base 的代价

Agent Knowledge Base 是个 Beta 功能，让 Agent 有自己的知识空间。但它是个可选集成，需要独立的服务和数据库，还要单独配置 embedding、reasoning、rerank 模型，服务要过 /ready 而不是只过 /health。默认的 Compose 部署里它是关闭的，标准 Dify API 镜像也不带这个引擎（需要单独的 engine-worker profile）。

换句话说，这不是"开个开关就能用"的功能，是要额外扛一套服务的。除非团队确实需要 Agent 级别的知识空间，否则不建议为了尝鲜去部署它。

升级前要看的几处

升级命令本身不长，Docker Compose 部署的话：

cd dify/docker
docker compose stop -t -1
git fetch --tags
git checkout 1.18.0
docker compose pull
docker compose up -d

但有四处是硬性的，漏一个都可能起不来或丢数据：

配套的 CLI difyctl 这版也能从服务端自动发现命令，用来创建应用、导入导出 DSL、发布和版本恢复：

difyctl login --server https://your-dify.example.com
difyctl help

注意 difyctl 的 v2 实现不复用 v1 的登录状态，升级后要重新登录。

值不值得升

如果团队已经在用 Agent 工作流、或者有把应用在多个环境之间迁移的需求，这版值得升，Agent 输出路由和 .ifpkg 都是实打实的生产力。如果只是搭简单 RAG 问答、工作流是几条直线，那 1.18 的可观收益有限，反而升级动作本身（尤其是 Agent Backend 协议和沙箱令牌两处）需要认真走一遍。我的建议是：用得上路由和打包的升，用不上的可以先观望一个补丁版本，等 Knowledge Base 脱离 Beta 再评估要不要加那套独立服务。