Exported app packages don’t include the workflows an app calls as workflow tools

快速结论：该报错出现在把一个调用“workflow tool（工作流工具）”的 Dify 应用导出为 .ifpkg、再导入到另一个工作区后运行应用的场景。导出包只保留了源工作区里工作流工具的 provider ID，没有带上被调用的工作流本体，因此跨工作区导入后运行时找不到对应 provider，优先排查导出包是否缺失被调用工作流及其依赖信息。

适用环境：Issue 已确认涉及 Dify 应用导出/导入（.ifpkg）、工作流/聊天流调用已发布为 workflow tool 的工作流、Agent 节点与 agent-chat 应用；涉及 ToolManager、app_dsl_service.py、provider_ids.py、dependencies_analysis.py 等后端代码路径。Issue 未提供具体版本号、操作系统、Python、CUDA、显卡信息。

最快修复方案：暂无确认的一步修复方案。Issue 讨论指出需要在导出包中携带被调用的工作流，并在依赖分析中区分工作流/API 工具 ID 与插件 ID；这些属于代码层修复，评论中未给出已验证的用户侧操作。

注意事项：仅保留源工作区的工作流 provider UUID 无法生效，因为运行时查找要求 provider ID 与目标工作区的 tenant ID 同时匹配；同一工作区内导入可能不会暴露问题，跨工作区才触发。导入时的告警路径（COMPLETED_WITH_WARNINGS）属于讨论中的建议方向，未被验证为正式方案。

问题场景

用户在 Dify 中把工作流或聊天流应用导出为 .ifpkg 包，而该应用内部通过 workflow tool 调用了另一个已发布为工作流工具的工作流。把包导入到另一个工作区后，导入本身成功，但运行应用时工具仍指向源工作区中才存在的 provider，导致应用运行失败。Agent 节点以及使用 workflow tool 的 agent-chat 应用表现相同。

同一 Issue 还报告了两类相关依赖识别问题：普通 Tool 节点把 provider ID 不加 provider_type 判断就交给插件依赖分析，导致生成形如 langgenius/<uuid> 的虚假插件依赖；旧版 agent-chat DSL 的工具列表中含知识库条目时，解析会在该条目处报错，导致其后的工具依赖全部丢失。

报错原文

workflow provider <id> not found

导出包层面表现为：Exported app packages don’t include the workflows an app calls as workflow tools。

原因分析

最可能的原因是导出逻辑没有把应用通过 workflow tool 调用的工作流一并打包。ToolManager 在运行时按 provider ID 与当前工作区 tenant ID 共同查找 provider，源工作区的 provider UUID 在目标工作区不存在，查找返回空，于是抛出上述错误。因此“保留源 UUID”本身不足以在另一工作区解析到工具。

依赖识别方面，可能原因包括：

普通 Tool 节点在提交插件依赖分析前未检查 provider_type，而 provider 解析器把裸 UUID 当作遗留名称展开为 langgenius/<uuid>/<uuid>，产生虚假插件依赖；Agent 节点的提取逻辑已有非插件类型过滤，两条路径不一致。
旧版 agent-chat 的工具提取把整个循环包在同一个 try 中，遇到缺少 provider_id 的知识库条目时会抛出异常并跳过后续所有工具；在报错条目之前已收集的依赖仍会保留，因此工具顺序会影响结果。

环境排查

确认应用是否在节点（含 Agent 节点）中引用了已发布为 workflow tool 的工作流。
确认导出与导入是否跨工作区进行；同工作区导入可能不触发该问题。
检查导出包中是否包含被调用工作流本身的定义，而不只是其 provider ID。
检查依赖分析结果中是否出现 langgenius/<uuid> 形式的插件依赖。
对于 agent-chat 应用，检查工具列表中知识库条目的位置及是否缺少 provider_id。
Issue 未提供 Dify 版本、Python、CUDA、显卡等环境信息，无法据此限定版本范围。

解决步骤

复现时先记录报错中缺失的 workflow provider ID，并确认它属于源工作区。
检查导出包内容，确认被调用的工作流是否被打包；若未包含，说明命中该 Issue 描述的导出缺陷。
可优先尝试：在目标工作区先重建或导入被调用的工作流，并确保其在目标工作区的 provider ID 与引用一致，以验证是否为导出包缺失导致；此做法为推测性绕过，评论中未验证。
排查虚假插件依赖时，检查普通 Tool 节点的 provider_type 是否被纳入依赖分析判断，以及是否产生 langgenius/<uuid> 条目。
排查旧版 agent-chat 依赖丢失时，调整工具顺序做对比：把知识库条目移到末尾，观察其后的工具依赖是否恢复，以确认是否由单个 try 整体跳过导致。
代码层修复方向（讨论中提出、未验证）：导出时携带被调用的工作流；依赖分析中区分工作流/API 工具 ID 与插件 ID；未解析的工作区工具引用通过 COMPLETED_WITH_WARNINGS 告警路径报告受影响节点/工具与源 provider ID。

验证方法

将修复后的导出包导入一个不包含源工作流的新工作区，运行调用 workflow tool 的应用，不再出现 workflow provider <id> not found；检查依赖分析结果中不再出现 langgenius/<uuid> 形式的虚假插件依赖；对含知识库条目的旧版 agent-chat DSL，确认知识库条目之后的工具依赖也能被完整识别。