👁 159 次阅读

MaxKB 高级智能体工作流节点为何收不到上游数据

来源：https://github.com/1Panel-dev/MaxKB/issues/6681

现象描述

报告者的环境是纯内网，硬件为华为昇腾 910B，模型服务为 MindIE，其上部署 qwen3 与 DeepSeek r1 两个模型。在 MaxKB 中可以正常对接这两个模型，简易智能体在关联两个模型后也能正常使用；但一切换到工作流编排场景，两个模型都会直接报错，界面显示「0 输入」。报告者给出了 MaxKB 版本 2.10.5，并在回复中说明这是 2.10.5 LTS 专业版、已导入临时 license，环境为纯内网。issue 正文附带三张截图用于说明界面表现，正文的 Related log output 段落为空。

背景原因

issue 全部 6 条评论中没有出现任何官方给出的根因分析。可确认的事实只有两点：其一，MaxKB 官方在 2026-08-17 回复表示当前没有条件获取到这样的模型环境，暂时无法复现问题，并询问报告者是否愿意提供环境。其二，报告者在同一条回复中提出可以通过视频的方式测试；官方在 2026-08-18 回复称视频方式也没有办法调试。官方没有解释「0 输入」从何产生，也没有指出问题出在工作流的数据传递、变量引用还是 MindIE 的请求组装环节。讨论中没有任何日志、栈信息或字段级别的定位信息，因此无法在此给出原因结论。另一条来自社区侧的对照信息：报告者表示同样的环境下用 dify 可以正常对接这两个模型，并通过工作流跑通。这一对照只能说明 MindIE 与模型服务侧具备支撑工作流的能力，至于它对应 MaxKB 侧的哪个环节，讨论中没有进一步说明。

排查或量化方法

该 issue 的讨论里没有给出命令行排查步骤、日志字段、请求体样例或接口调用示例，报告者的 Related log output 段落为空。可确认的定位信息仅限于：

同一组模型在简易智能体场景可用，在工作流编排场景报错；
报错表现为界面显示「0 输入」；
官方侧没有同类模型环境，无法自行复现；
官方明确说明视频方式无法用于调试，因此界面录像不足以替代环境或数据访问。

除上述几点外，讨论中未提供其他可用于收窄问题范围的信息。

当前处理路径与局限

讨论中实际走通的处理路径只有一条，即官方根据报错信息改了一个版本并提供临时镜像：

官方基于报错信息改动了一版代码，制作成临时镜像；
官方通过邮件把镜像地址以及替换、测试的方法与流程发给报告者；
报告者在自己的内网环境中替换镜像后进行验证；
issue 于 2026-09-04 关闭，关闭原因为 completed。

局限如下：

该镜像面向单一环境定向验证，issue 正文与评论中没有披露镜像版本号、镜像地址或具体改动内容。
报告者在评论区并未回帖确认验证结果，因此「报告者确认临时镜像有效」这一点在讨论中没有出现，只能确认官方关闭了该 issue。
讨论中没有 PR 号或合并记录，因此不能声称代码已进主干或已随某版本发布。
关闭原因为 completed 不等于已有公开可复用的修复；对该场景的使用者来说，可走的路径仍是向官方提供报错信息并配合镜像替换验证。

关键信息对比

项目	内容
MaxKB 版本	2.10.5 LTS 专业版，已导入临时 license
硬件环境	华为昇腾 910B，纯内网
模型服务	MindIE，部署 qwen3 与 DeepSeek r1
简易智能体	两个模型可正常关联使用
工作流编排	两个模型均报错，显示 0 输入
对照信息	报告者称同样环境下 dify 可正常对接并通过工作流跑通
官方可复现性	官方表示没有同类模型环境，暂时无法复现
视频调试	报告者提出可用视频测试，官方回复视频方式无法调试
日志信息	正文 Related log output 段落为空，讨论中无日志
处置方式	官方据报错信息改一版，提供临时镜像，由报告者替换验证
最终状态	closed，关闭原因 completed，关闭时间 2026-09-04
验证结果	报告者未在评论区回帖确认，讨论中未见验证结论

常见错误排查

工作流 AI 节点显示「0 输入」：报错仅说明该节点的输入为空，不等于模型服务或硬件故障。报告者的对照情况是同一组模型在简易智能体下可用。
简易智能体正常但工作流报错：两个场景由报告者在同一环境中验证，简易智能体的可用性只覆盖了模型对接环节，能否延伸到工作流编排讨论中没有结论。
MindIE 可以被 MaxKB 正常对接：报告者已验证连通性成立，因此把问题直接归结为模型服务配置不足与讨论事实不符。
用 dify 跑通就能替代：两者实现不同，dify 的结果只是模型与硬件侧的旁证，不能作为 MaxKB 侧无问题的结论。
纯内网环境给远程复现带来限制：官方明确说明既无同类环境、视频方式也无法调试，用户侧的界面录像不足以替代镜像替换验证。

实践建议

遇到工作流输入为空时，保留的是讨论中已经被证明有用的东西——报错信息。本次处置路径的起点就是官方「根据报错信息」改出一版临时镜像，而不是截图。界面截图在本次讨论里没有促成任何定位进展。对纯内网环境，提前准备一套可替换镜像的流程，包括镜像导入、服务替换、数据备份与回滚步骤，可以在官方提出定向验证时快速响应。报告者在本次讨论中主动要求补充替换与测试流程，是很实际的做法。反馈时把对照信息一并给出。报告者说明「同样的环境下用 dify 可以正常对接两个模型，通过工作流跑通」，这一对照把讨论焦点从「模型能否被调用」推向了「MaxKB 工作流环节」，比单独提交报错更有信息量。

FAQ

这个 issue 最终修好了吗？ issue 于 2026-09-04 关闭，关闭原因为 completed。据 issue 讨论，官方根据报错信息改了一个版本，并以临时镜像形式发给报告者验证，随后关闭。官方未在评论中公开修复版本号，也未公开具体改动内容，报告者也没有在评论区回帖确认验证结果。 为什么官方无法直接复现？ 官方在评论中说明当前没有办法获取到这样的模型环境，因此暂时无法复现问题，并明确回复视频方式也没有办法调试。 报告者尝试过哪些对照？ 报告者表示同样的环境下使用 dify 可以正常对接两个模型，并通过工作流跑通。讨论中没有进一步讨论这一对照所指向的具体环节。 验证用的镜像从哪里获取？ 官方通过邮件把临时镜像地址以及替换、测试的方法与流程发给报告者。该镜像未在 issue 评论区公开，只面向该环境定向提供。 遇到类似「0 输入」问题该怎么处理？ 参照该 issue 的实际路径：向官方提供报错信息，配合镜像替换验证。本 issue 讨论中没有出现任何可复用的补丁、配置片段或通用排查命令，官方也未公开具体改动内容，因此无法给出通用解决方案。