FastGPT 工作流画布与聊天预览 4 个 Bug 修复全解：文件链接变量、数组条件、工具集版本与用户消息渲染

FastGPT 工作流画布与聊天预览 4 个 Bug 修复全解：文件链接变量、数组条件、工具集版本与用户消息渲染

【免费下载链接】FastGPTFastGPT is a knowledge-based platform built on the LLMs, offers a comprehensive suite of out-of-the-box capabilities such as data processing, RAG retrieval, and visual AI workflow orchestration, letting you easily develop and deploy complex question-answering systems without the need for extensive setup or configuration.项目地址: https://gitcode.com/GitHub_Trending/fa/FastGPT

本文基于 FastGPT 仓库内的 Bug 修复分析文档（workflow-and-chat-bug-fixes-analysis.md）整理，覆盖工作流开始节点“文件链接”变量缺失、判断器 array 变量无可选条件、系统工具集卡片误显示版本信息、用户输入被按 Markdown 渲染共 4 个缺陷。读完后你将理解每个 Bug 的根因、涉及的关键判断逻辑与修复方式，以及这类“功能演进后判断分支遗漏”问题的排查方法，可用于指导后续的画布与聊天 UI 开发维护。

0. 背景：四个 Bug 的共同根因

这 4 个 Bug 表面上分布在开始节点配置、判断器、节点卡片、聊天容器四个互不相干的模块，但从源码结构看，它们有同一个模式：

• 新增功能引入了新分支，而分散在各处的旧判断逻辑没有同步更新：
  • Bug 1：文件上传能力新增了 3 个开关（视频、音频、自定义扩展名），但开始节点联动逻辑和 workflow 输入 schema 生成处仍只判断旧的两个开关；
  • Bug 2：变量类型枚举新增了arrayAny（泛数组），但判断器的“类型→条件列表”映射没有把它归入数组分支；
  • Bug 3：工具节点新增了systemToolSet（系统工具集）来源，但节点卡片的版本显示排除条件没有覆盖它；
  • Bug 4：用户消息展示复用了 AI 回复的 Markdown 渲染组件，而用户输入本应原样呈现。

因此，本文按“功能背景 → 问题代码 → 修复代码 → 仓库现状佐证”的结构逐个展开，最后总结一套防回归检查清单。

1. Bug 1：自定义文件扩展类型下，开始节点缺少“文件链接”变量

1.1 功能背景

FastGPT 应用配置中的聊天设置（chatConfig.fileSelectConfig）支持 5 个相互独立的上传开关：

配置项	含义
canSelectFile	允许上传文件
canSelectImg	允许上传图片
canSelectVideo	允许上传视频
canSelectAudio	允许上传音频
canSelectCustomFileExtension	允许自定义文件扩展类型

只要任意一个开关开启，工作流开始节点就应暴露“文件链接”变量（userFiles类输出，schema 模板为Input_Template_File_Link），供下游节点引用上传文件的 URL。

1.2 问题代码

旧实现只识别前两个开关，判断逻辑出现在两处：

1. 开始节点配置表单的联动逻辑（判断是否向开始节点增删userFilesInput输出）；
2. workflow 输入 schema 的生成逻辑（决定是否包含Input_Template_File_Link模板）。

// 表单联动处（旧） const canUploadFiles = e.canSelectFile || e.canSelectImg;

// schema 生成处（旧） ...(chatConfig?.fileSelectConfig?.canSelectFile || chatConfig?.fileSelectConfig?.canSelectImg ? [Input_Template_File_Link] : []),

结果是：用户只勾选“自定义文件扩展类型”（或视频/音频）时，canUploadFiles为false，开始节点不会添加文件链接输出，workflow 输入 schema 也不含该模板变量，后续节点自然无法引用上传文件链接——且这两处不同步修复的话，一个改了对另一个仍无效。

1.3 修复代码

两处判断统一扩展为覆盖全部 5 个开关：

const canUploadFiles = e.canSelectFile || e.canSelectImg || e.canSelectVideo || e.canSelectAudio || e.canSelectCustomFileExtension;

...(chatConfig?.fileSelectConfig?.canSelectFile || chatConfig?.fileSelectConfig?.canSelectImg || chatConfig?.fileSelectConfig?.canSelectVideo || chatConfig?.fileSelectConfig?.canSelectAudio || chatConfig?.fileSelectConfig?.canSelectCustomFileExtension ? [Input_Template_File_Link] : []),

1.4 仓库现状佐证

在修复后的仓库中，schema 生成逻辑位于 packages/global/core/workflow/utils.ts，可以看到 5 个开关的完整判断：

...(chatConfig?.fileSelectConfig?.canSelectFile || chatConfig?.fileSelectConfig?.canSelectImg || chatConfig?.fileSelectConfig?.canSelectVideo || chatConfig?.fileSelectConfig?.canSelectAudio || chatConfig?.fileSelectConfig?.canSelectCustomFileExtension ? [Input_Template_File_Link] : []),

而表单联动逻辑已从文档中记录的NodeSystemConfig.tsx重构迁移至 SystemConfigForm.tsx。该处不仅判断 5 个开关，还会通过collectWorkflowStartInputAutoFillPatches收集已有节点对开始节点新输出的自动填充补丁，再以onChangeNode的addOutput/updateInput补丁批量更新画布——也就是说，开启上传开关后，画布会同步补全开始节点输出以及已引用该变量的下游节点配置，关闭开关时则走collectWorkflowStartOutputAutoFillRevertPatches回滚补丁，保证数据层与 UI 层一致。

这一 Bug 的教训在于：“是否可上传”这类判断同时存在于 UI 联动和数据（schema）生成两条链路，任何开关新增都必须两处同步；配套的回归用例记录在 utils.test.ts 中。

2. Bug 2：判断器选择 array 类型变量后没有条件可选

2.1 功能背景

判断器（if-else 节点）的条件编辑项需要根据所选变量的类型动态渲染“条件”下拉：字符串走stringConditionList（包含、等于、正则等），数值走numberConditionList（大于、小于等），布尔走booleanConditionList，各类数组则走arrayConditionList（包含、为空、不为空等数组语义条件）。

2.2 问题代码

映射逻辑通过一连串valueType ===判断归入对应分支。旧实现列出了arrayBoolean、arrayNumber、arrayObject、arrayString四个具体数组类型，但遗漏了WorkflowIOValueTypeEnum.arrayAny（泛数组，元素类型未定的数组）：

if ( valueType === WorkflowIOValueTypeEnum.chatHistory || valueType === WorkflowIOValueTypeEnum.datasetQuote || valueType === WorkflowIOValueTypeEnum.dynamic || valueType === WorkflowIOValueTypeEnum.selectApp || valueType === WorkflowIOValueTypeEnum.arrayBoolean || valueType === WorkflowIOValueTypeEnum.arrayNumber || valueType === WorkflowIOValueTypeEnum.arrayObject || valueType === WorkflowIOValueTypeEnum.arrayString ) return arrayConditionList;

2.3 后果与调用链

从 ListItem.tsx 的当前实现可以还原完整失败链路：

1. getRefData依据所选变量解析出valueType；
2. conditionList的 memo 按类型分派——arrayAny不属于任何分支，最终落到函数末尾的return [];；
3. filterQuiredConditionList基于空数组做后续过滤与 i18n 标签映射；
4. 条件MySelect拿到空list，表现为条件下拉完全为空，无法配置任何数组判断。

2.4 修复代码

在数组分支补上arrayAny：

if ( valueType === WorkflowIOValueTypeEnum.chatHistory || valueType === WorkflowIOValueTypeEnum.datasetQuote || valueType === WorkflowIOValueTypeEnum.dynamic || valueType === WorkflowIOValueTypeEnum.selectApp || valueType === WorkflowIOValueTypeEnum.arrayAny || valueType === WorkflowIOValueTypeEnum.arrayBoolean || valueType === WorkflowIOValueTypeEnum.arrayNumber || valueType === WorkflowIOValueTypeEnum.arrayObject || valueType === WorkflowIOValueTypeEnum.arrayString ) return arrayConditionList;

仓库当前代码已包含该分支（见 ListItem.tsx）。此类“枚举映射遗漏”的隐患在于：类型枚举每新增一个值，所有穷举式===判断点都要复查一遍；这也是第 5 节检查清单中建议优先使用白名单/集合判断的原因。

3. Bug 3：系统工具集不应显示版本信息

3.1 功能背景

工作流中的工具类节点卡片（节点头区域）会按工具来源决定是否展示版本 UI：

• MCP / HTTP 工具与工具集：内容跟随最新工具集，不提供版本选择，卡片不应展示版本；
• 团队应用、系统商业插件：有发布版本概念，应展示版本信息；
• 系统工具集（systemToolSet）：由平台内置提供，同样没有版本选择能力，本不应展示版本 UI。

3.2 问题代码

节点卡片的版本显示条件中，排除isAppNode场景的分支覆盖了mcpToolSet、mcpTool、httpToolSet，却漏掉了systemToolSet，导致系统工具集卡片错误地进入版本渲染逻辑、显示“保持最新版本”之类的 UI：

if ( isAppNode && (node.toolConfig?.mcpToolSet || node.toolConfig?.mcpTool || node?.toolConfig?.httpToolSet) ) return false;

3.3 修复代码

在排除条件中补上systemToolSet：

if ( isAppNode && ( node.toolConfig?.mcpToolSet || node.toolConfig?.mcpTool || node?.toolConfig?.httpToolSet || node?.toolConfig?.systemToolSet ) ) return false;

3.4 仓库现状佐证

该判断逻辑位于 NodeCard.tsx 的showVersion计算中。需要注意：修复合入后该函数又经历过一轮重构，当前代码已将排除粒度细化为——先按pluginId拆出的工具来源排除mcp/http来源（source === AppToolSourceEnum.mcp || source === AppToolSourceEnum.http直接返回false），再在toolConfig层面排除mcpToolSet、mcpTool、httpToolSet、httpTool；随后仅对团队应用（有pluginId）与systemTool展示版本。也就是说，文档记录的是“补上systemToolSet”这一增量修复，而当前仓库体现了更完整的来源判定链路，但“系统工具集不暴露版本”的语义保持不变。

4. Bug 4：用户输入中的*被按 Markdown 强调语法渲染

4.1 问题概述

在运行预览及相关聊天场景中，用户输入1*1=1, 2*2=4后，消息不按要求原样显示：成对的*会被解析为强调语法。原因是用户（人类）消息的展示层直接复用了 Markdown 渲染组件，受影响的有两处：

• 主聊天容器（ChatContainer/ChatBox）中的人类消息项；
• HelperBot（应用助手）中的人类消息项。

问题代码形如：

{text && <Markdown source={text} />}

Markdown 渲染对 AI 回复是必要的（需要展示代码块、列表、公式等富文本），但用户输入本质是原始文本，其中的*、#、反引号等字符都会触发解析（强调、标题、行内代码），造成显示走样，也不利于用户回看自己输入的确切内容。

4.2 修复代码

将人类消息改为纯文本渲染，用whiteSpace: 'pre-wrap'保留换行、wordBreak: 'break-word'允许长文本折行：

{text && ( <Box fontSize={'inherit'} color={'inherit'} whiteSpace={'pre-wrap'} wordBreak={'break-word'}> {text} </Box> )}

{text && <Box whiteSpace={'pre-wrap'} wordBreak={'break-word'}>{text}</Box>}

4.3 仓库现状佐证

文档记录的ChatItem.tsx与HelperBot/HumanItem.tsx两处，在当前仓库中已经过组件结构重构：主聊天容器的人类消息渲染集中在 HumanChatBubble/Content.tsx（其中可见whiteSpace={'pre-wrap'}的纯文本渲染方式），其余如 ChatInput.tsx、ChatRecordsList.tsx 等用户输入展示位同样采用pre-wrap纯文本方案。

这一修复确立了一条展示层原则：Markdown 只用于 AI 输出，用户输入一律原样呈现，避免任何转义遗漏带来的展示歧义。

5. 总结：功能演进下的判断分支同步与防回归清单

5.1 四类遗漏模式归纳

Bug	遗漏点	遗漏模式
文件链接变量	canUploadFiles判断、Input_Template_File_Link条件	开关组合（布尔 OR 链）
array 无条件可选	arrayAny未进arrayConditionList分支	枚举类型穷举映射
系统工具集版本 UI	systemToolSet未进排除条件	布尔 OR 排除链
*被 Markdown 渲染	用户消息复用 AI 渲染组件	渲染组件作用域

可以看到，前三个本质是“穷举判断少列了一项”，第四个是“组件复用范围过宽”。

5.2 排查与回归清单

结合本文涉及的仓库代码位置，后续修改同类功能时建议按以下清单逐项核对：

1. 枚举/类型映射完整性：新增WorkflowIOValueTypeEnum、工具来源等枚举值后，全局搜索所有valueType ===/source ===穷举点（参考 ListItem.tsx 的条件分派、NodeCard.tsx 的showVersion计算），必要时改用“白名单集合包含判断”降低遗漏概率；
2. UI 联动与数据层同步：像“是否可上传”这类条件，UI 联动（SystemConfigForm.tsx）与 schema 生成（utils.ts）必须成对修改，并确认addOutput/回滚补丁两条路径都覆盖新分支；
3. 渲染组件作用域：区分 AI 输出（富文本/Markdown）与用户输入（pre-wrap纯文本），新增展示位时不要直接复制 AI 侧渲染组件；
4. 补充用例：为每个修复点补充或更新对应单测（如 utils.test.ts），把“新开关组合”“新枚举值”写进断言，防止回潮。

5.3 适用前提

• 本文基于 FastGPT 仓库当前代码状态，其中开始节点联动逻辑（原NodeSystemConfig.tsx）、用户消息组件（原ChatItem.tsx、HumanItem.tsx）与节点卡片版本逻辑均已发生过后续重构，文档记录的路径与行号仅供追溯，实际阅读请以文中给出的当前路径为准；
• 四个 Bug 均为前端展示/配置联动层缺陷，不改变工作流执行引擎的数据结构；
• 完整的问题代码与修改代码对照，可查阅仓库内的分析文档 workflow-and-chat-bug-fixes-analysis.md。

【免费下载链接】FastGPTFastGPT is a knowledge-based platform built on the LLMs, offers a comprehensive suite of out-of-the-box capabilities such as data processing, RAG retrieval, and visual AI workflow orchestration, letting you easily develop and deploy complex question-answering systems without the need for extensive setup or configuration.项目地址: https://gitcode.com/GitHub_Trending/fa/FastGPT