跨环境导入工作流后，即使插件名称一致也需手工重新编排

[somunslotus1]

问题摘要

在 相同 Astron Agent 版本 的两套独立环境中，从环境 A 导出工作流（YAML）并导入到环境 B 后，即使环境 B 已存在同名插件，导入后的工作流仍无法直接调试/发布使用，必须手工重新选择插件并重新编排。

期望行为

当目标环境存在可匹配资源（如同名插件）时，导入应：

1. 自动将节点引用映射到目标环境对应的资源 ID
2. 导入后可直接调试、保存、发布，无需手工重连
3. 若无法自动映射，应明确提示哪些节点失败，而不是静默失效

实际行为

1. 从环境 A 导出工作流 YAML
2. 在环境 B 创建同名插件（名称相同，ID 不同）
3. 将 YAML 导入环境 B
4. 插件节点绑定丢失，输入/输出常被清空
5. 必须手工重新选择插件并重新编排后才能使用

复现步骤

前置条件

• 两套独立部署（不同业务库 / 不同资源 ID），Astron 版本相同
• 两端均可创建插件与工作流
• 不能共用同一业务库，否则 pluginId 可能相同，无法体现问题

步骤

1. 环境 A：创建插件，名称固定为 demo-cross-env-plugin，记录其 toolId 为 A_TOOL_ID
2. 环境 A：新建工作流，节点至少包含：开始 → 插件（demo-cross-env-plugin）→ 结束；调试通过后导出 YAML
3. 环境 B：创建同名插件 demo-cross-env-plugin，记录 B_TOOL_ID（确认 A_TOOL_ID ≠ B_TOOL_ID）
4. 环境 B：导入上述 YAML
5. 打开导入后的工作流，不要重新选择插件，检查插件节点状态
6. 直接点击调试/试运行，记录失败现象
7. 再手工重选同名插件，确认重编排后可恢复

现象对照

检查项	期望	实际
插件绑定	自动绑定环境 B 同名插件	绑定丢失 / 需重选
节点输入输出	保留	常被清空
直接调试/发布	可用	失败，需手工重编排

初步原因分析

导入清洗逻辑位于 WorkflowExportService.cleanNodesForImport / cleanPluginNode：

• 仅按 pluginId（toolId） 校验插件是否存在及权限
• 目标环境找不到相同 ID（或无权访问）时：移除 pluginId，并清空 inputs / outputs
• 没有按插件名称做回退映射

因此「名称一致、ID 不同」的跨环境场景下，绑定必然丢失。

同类仅按 ID 清洗的逻辑也可能影响：

• 大模型节点（llmId）
• 知识库节点（repoId / repoIds）
• 子工作流节点（flowId）
• 数据库节点（dbId）

建议方案

1. 短期：导入时先按 ID 匹配；ID 不存在时，按名称在目标环境唯一匹配并回写新 ID
2. 中期：导出增加稳定迁移字段（如 pluginName / 业务 key），优先按稳定标识映射
3. 体验：导入完成后给出报告：已自动映射 N 个节点 / 需手工处理 M 个节点

环境信息

• Astron Agent 版本：v1.1.0
• 两端是否同版本：是
• 是否同名插件、不同 ID：是
• 主要涉及节点：插件节点（模型/知识库等可能同类问题）

优先级

高：跨环境迁移（开发 → 测试 → 生产 / 私有化交付）是高频场景；当前只能手工重编排，成本高且易出错。

[whyiug]

我把导入链路过了一遍，问题确实出在这里只认源环境的 toolId。这个我来处理，先把插件节点这一块做完整：原 ID 仍然优先；跨环境时，只在当前个人/空间范围内做唯一且结构兼容的同名匹配。重名、版本或参数结构不一致时不会自动绑定，并会把需要手动处理的节点提示出来。这样可以先把最常见的迁移场景跑通，也避免误绑到别的插件。测试会覆盖导出→导入、权限隔离、重名冲突和旧 DSL 兼容。

[lyj715824]

这个问题已完成修复，并已合入 bugfix/superteam。

实现结果

• 保留“原资源 ID 优先”的行为，源 ID 在目标环境仍可用时不会发生替换。
• 当源插件 ID 不可用时，仅在调用者当前个人/团队权限范围内，按以下条件做唯一兼容匹配：
  • 插件名称一致
  • operation 一致
  • version 一致
  • 输入/输出 schema 兼容
• 只有唯一兼容候选才会自动回写目标环境的新插件 ID。
• 重名、无权限、版本或结构不兼容、资源缺失时不会猜测绑定，而是标记为 unresolved。
• 导入完成后会展示依赖报告，包括映射状态、匹配策略、原因、源/目标 ID、operation 和 version。
• unresolved 工作流允许作为草稿保存，便于后续修复；但单节点调试、整体调试、发布及审批执行均会 fail-closed，避免带着错误绑定运行。

实际环境验收

已使用两套 fixture 完成部署后的浏览器 E2E：

1. 跨 ID 唯一兼容映射：

   • tool@issue1603-source-a → tool@a3c86933e821000
   • 报告显示 MAPPED / COMPATIBLE_NAME / UNIQUE_COMPATIBLE_NAME_MATCHED
   • operation、V1.0 和 schema 保持兼容
   • 导入后无需重新选择插件，单节点调试实际执行成功

2. 目标插件缺失：

   • 报告显示 MISSING / NONE / TOOL_MISSING
   • unresolved 草稿可自动保存并重新打开
   • 单节点调试、整体调试和发布均在执行前被明确阻断

关联变更

• 主功能修复：#1615
• CI 质量门禁重构：#1618、#1619、#1620

最终远端 Java、TypeScript、Go、Python 四类质量检查及完整测试矩阵均已通过。