智能体可以选择下一条分支：Dify 1.18 让工作流程更容易迁移和检查

智能体演示，只需一次成功请求，就可能看起来很有说服力。更困难的问题，会在第二个团队希望复用时出现：它会选择哪条分支，哪些文件会随应用一起迁移，又能在哪里看到嵌套工作流程内部发生了什么？

2026 年 10 月 23 日发布的 Dify 1.18.0，把这些问题放在了一起。更新引入智能体 Output Routes、可迁移的 .ifpkg 应用包，以及更深入的工作流程可见性。这些改变并非主要为了让智能体回答得更惊艳，而是为了让它在应用中的位置足够清楚，从而可以复用。官方版本发布说明。

Dify 是一个通过可视化工作流程、模型、知识和工具构建 AI 应用的平台。团队可以用它，把模型的判断连接到应用步骤，而不是反复将相同提示词复制到聊天窗口里。这次更新有趣的地方，在于它串联了三个实际问题：决定下一步、迁移应用，以及检查执行过程。

工作流程界面图片来自 LangGenius / Dify 文档贡献者，采用 CC BY 4.0 许可。已调整尺寸并转换为 WebP，未经裁剪。画面用于展示可视化构建器，并未展示本次发布的所有新控件。

分支，是一个有去向的决策

在传统工作流程里，条件通常检查已知值：状态是否已批准、字段是否为空，或评分是否越过阈值。基于自然语言的请求则没这么整齐。客户可能在一条消息里混合问题、投诉和例外请求。

Dify 新增的 Output Routes 允许智能体在配置好的路由中选择，让工作流程沿相应分支继续。智能体的理解，变成了流程内部的一项选择；下一步由工作流程明确呈现，而不是完全留在生成的文字中。

这能让应用更容易设计和检查。构建者决定存在哪些目标去向，智能体为某个请求从中选择，工作流程随后执行相连步骤。即使智能体的自然语言解释不是最终产品，路由仍然可以发挥作用。

边界很重要。选择“升级处理”路由，不等于证明某个案例在法律或财务上必须升级处理；选择“起草回复”路由，也不等于获得发送回复的权限。工作流程仍需明确每次选择后允许哪些操作，以及谁负责例外情况。

示例一：一条客户消息，三种可能路径

设想一个客服团队，同时收到产品问题和例外请求。它希望应用区分三条主要路径：根据已批准的帮助材料回答、为人准备回复草稿，或将特殊案例升级处理。

有了明确路由，这些去向就可以直接显示在工作流程中。简单的设置问题可以进入基于知识的回答路径；包含账户特定不确定性的请求可以进入审查路径；要求突破商业条款的请求，则可以交给有权作出决定的团队。

这些是用于说明的应用选择，并不是 Dify 提供的现成客服政策。团队必须定义什么属于各条路由，提供适当示例，并决定输入含糊时如何处理。不能让有说服力的解释抹去授权边界。

好处并不是每条消息都会变得容易分类，而是构建者可以评估一个具体决策。如果智能体把困难消息送进普通回答分支，测试就有明确失败；如果它把所有请求都送给人处理，流程可能安全，却几乎没有提供有价值的自动化。

保留一组棘手消息及其预期去向，包括混合请求、信息缺失，以及类似真实客户流量的语言变体。只能在最整洁示例上成功的工作流程，即使图画得很完整，也仍然只是演示。

配置好的路由，把语言判断转为可见的工作流程去向。每个去向仍需自己的获准操作和审查规则。

可迁移，不只是复制一段提示词

AI 应用可能依赖指令、智能体定义、Skills、文件，以及对工作区资源的引用。只复制最显眼的提示词，会把应用的大部分内容留在原处。

Dify 1.18 引入 .ifpkg 应用包，可以包含内联 Agents、Skills 及其文件。发布说明称，导入时会重新创建这些资源，并重新映射引用。文件和 URL 导入支持 YAML 与应用包格式，同时仍然可以显式导出 YAML。应用包与导入变化。

这对复用是有意义的改变。团队更有机会把解释智能体如何协同工作的组成部分一起迁走，而不是让同事依照一长串手动指令重新构建。

但这不能证明每项外部依赖都会自动迁移。模型访问、凭据、插件可用性、网络权限和知识资源，都可能取决于目标环境。导入的应用可以在结构上完整，却仍然需要配置后才能正确运行。

应把应用包视为有用的应用产物，并配套检查流程。文件可以携带另一个团队没有编写的指令和支持内容。在把它导入具有重要访问权限的工作区之前，先了解来源，以及其中智能体和工具预期执行的行为。

示例二：提案流程迁移到另一个团队

设想一家服务公司构建了准备提案初稿的流程。它收集请求，应用写作 Skill，检查必需章节是否齐全，并把不确定的商业条款路由给人处理。

另一个团队希望以不同的服务目录复用这种方式。只交接提示词是不完整的：可复用写作指令、附加模板和智能体引用，都属于行为的一部分。应用包格式的设计，就是为了帮助把更多相连的组成部分一起迁移。

接收团队仍然有工作要做：替换或确认服务信息，配置允许使用的模型和工具，并验证谁有权批准提案。如果导入流程引用了不属于新工作区的资源，导入成功也不能成为不再审查该引用的理由。

迁移前后，运行同一小组示例请求。比较路由选择、必需章节、工具访问和审查行为。可迁移应用应当保留预期流程，同时允许对目标环境专属信息作出有意识的变更。

这时，打包就成为一项运行层面的功能。它可以减少重建工作，但有用的结果，是另一团队能够理解并测试的可重复交接。导入少点了几次鼠标，只是结果的一部分。

看见工作流程内部，会改变团队的调试方式

更新还强调了更深入的工作流程可见性，包括嵌套执行。这很重要，因为应用发生故障的位置，可能距离用户察觉问题的位置相隔好几步。

一份糟糕的最终草稿，可能源于路由错误、知识来源缺失、工具结果不完整，或嵌套流程内部的指令。如果团队只能检查最终答案，就可能不断重写并不是问题原因的提示词。

更可见的执行过程，可以帮助团队提出更精确的问题：这一步收到了什么输入，产生了什么结果，下一步又如何使用这个结果？答案能够支持更精准的修复，而不是同时修改应用的好几个部分。

可见性并不等于完整解释模型内部推理。执行信息可以展示应用事件和数据流，却不能说明为何每个词元或每条路由被选中，也不会自动决定哪些跟踪内容适合让每位查看者看到。

利用可用的可见性，去理解工作流程可观察到的行为。另行决定跟踪记录保留多久、其中可能出现哪些敏感材料，以及谁应该有访问权。处理机密请求的应用，不应把调试方便变成对请求内容的无限制访问。

版本发布与实际升级，是两个问题

GitHub 官方版本是一次有明确日期的软件发布。它本身不能证明所有托管 Dify 工作区都在同一时刻启用了同样的功能。使用托管服务的读者，应先检查自己的工作区和产品文档，再围绕某个具体控件作计划。

自托管安装承担另一种责任。Dify 1.18 的发布说明，描述了 API、工作进程、Agent Backend 和运行时镜像的协同变更，其中包括智能体运行时协议变化。当一个版本改变多个组件之间的通信时，只更新一个显眼组件，并不是可靠的采用方式。

说明还指出了本地智能体沙箱和工具的配置及迁移细节。这些细节应纳入根据实际安装情况制定的升级计划，不应被简化成从产品概览中复制的一条通用命令。

升级前，保留当前配置和应用产物，确认受支持的组件版本，并在适当环境中测试迁移。不要因为示例配置出现一个看起来很新的值，就替换持久化身份验证或加密相关设置。应严格遵循该版本的迁移指南。

如果团队当前只是想评估路由或应用包，先用单独的测试应用可能更合理。这样可以了解新行为，而不用把首次实验变成最重要工作流程的一次迁移。

一次有用的评估，一页纸就能说明

不需要几十个智能体，才能了解这些功能是否有帮助。一个具有真实决策的应用，加上用于导入测试的第二个环境，就足以揭示几个重要属性。

1. 选择范围明确的任务。 选择输入和结果都容易识别的流程，例如准备供审查的客服回复。明确由谁负责例外情况。
2. 定义少量路由。 为每条路由赋予实际运行含义，规定其后的操作。为无法安全归类的请求预留一条路径。
3. 收集代表性案例。 使用普通请求、混合意图消息，以及信息缺失案例。运行前先记录预期路由。
4. 检查执行过程，而不只看最终答案。 跟随相关嵌套步骤，找出意外值或选择最早出现的位置。
5. 导出并导入应用。 审查包内资源，并检查目标环境中的引用、工具、模型和密钥。不要假设缺失的访问权应该被自动授予。
6. 迁移后重复同样的案例。 比较路由和输出，再记录接收团队配置中任何有意保留的差异。

有用的指标很具体：请求有多大比例到达预期去向，交接需要多少配置，以及审查者能否在不重建整次运行的情况下找到失败位置。这些指标，都不需要把生成的文字当成证明其自身正确的证据。

应用包可以迁移应用结构。目标环境仍需进行自己的访问检查，并重新运行定义成功行为的案例。

什么更值得期待，什么仍需谨慎

值得期待的方向，是一种更容易复用的应用单元。工作流程可以包含明确去向，携带更多支撑它的智能体资源，并在发生问题时呈现更多执行细节。对于已经超越单独提示词、又不想让每个应用都成为定制集成项目的团队，这种组合很有用。

相应的担忧是，可迁移性能够像传播好模式一样高效地传播错误。含糊的路由定义或权限过大的工具，并不会因为装进一个整齐的包就变得适当。要审查导入的行为，而不只是检查文件能否成功打开。

对于 Dify，下一项有意义的测试，是团队能否在变化中维护这些应用：更换模型、新增 Skill、修改业务政策，或迁移到另一工作区。首次导入成功令人鼓舞；受控更新后仍能保留预期行为，才是更强的成熟信号。

Dify 1.18 将智能体决策与可见的工作流程结构连接起来，让这个实验更值得尝试。从小流程开始，让路由易于理解，让交接可以重复。一个有前景的演示，正是这样逐步变成另一团队可以负责任地使用的东西。

来源

• Dify 1.18.0 发布说明，发布于 2026 年 10 月 23 日 06:33 UTC。
• Dify 官方文档，用于产品背景；功能发布范围应在实际工作区中核查。

想为工作流程笔记、请求示例和版本修改背后的决定保留可搜索的空间吗？在 Telli.sh 收集参考材料，让交接保持清楚。