MaxKB 版本
1.3.0
请描述您的需求或者改进建议
nginx配置： proxy_cache off; # 关闭缓存 proxy_buffering off; # 关闭代理缓冲 chunked_transfer_encoding on; # 开启分块传输编码 tcp_nopush on; # 开启TCP NOPUSH选项，禁止Nagle算法 tcp_nodelay on; # 开启TCP NODELAY选项，禁止延迟ACK算法 keepalive_timeout 300; # 设定keep-alive超时时间为65秒
采用的上面的配置，从逻辑上观察应该是代码设计的原因，下面我具体说明下：
如果走的工作流为①和③，工作流①会直接返回，工作流③会按照流式返回内容；
但是如果走的工作流为②，由于工作流②多了逻辑判断，且最后输出不是AI对话组件的输出，那么会等AI对话组件处理完后再进入到下一个判断组件，判断组件再进入到AI对话2组件，最后输出结果，由于显示的结果只是最后组件的结果，那么在组件AI对话组件耗时的时候前段就会卡在回答中等到流程进入到AI对话2组件才会有显示结果返回。工作流2的后续补充图如下：
如题，我期望的方式是可以选择要在前段页面显示的内容而不仅仅只有最后的输出结果，例如AI对话组件工作的时候把其回复的流也显示在前段页面上，经过AI对话组件2提炼用户可能或者想要问的下一个问题，然后也输出到前段页面，这样在处理AI对话组件的耗时也可以直观反映在前段，不会导致用户认为AI思考过程太长（说的直白一点就是可以把工作流的运行可选择式地反馈给用户）
如下图中的
内容先流式加载到前段页面，然后在进入逻辑判断把后续的输出也显示出来，从使用体验开看就是判断器1和指定回复1组件是需要AI对话组件完成的情况下才会执行，而且由于前段只支持最后的输出结果，那么造成的现象就是处理指定回复1前面的所有组件耗时的过程，前段页面都会卡在“回答中”的阶段，直到走到指定回复1组件才会在前端输出最终结果。
期望的形式是"AI对话组件"处理后返回的信息先加载到前段页面，这样避免了该段时间前段页面等待最终结果一直不动作；然后扩展到使用场景就是希望能增加有时序性质（可以采取流式阻塞等待的方式）的工作流任意组件输出内容同步到前端页面。
请描述你建议的实现方案
No response
附加信息
No response
MaxKB 版本
1.3.0
请描述您的需求或者改进建议
nginx配置： proxy_cache off; # 关闭缓存 proxy_buffering off; # 关闭代理缓冲 chunked_transfer_encoding on; # 开启分块传输编码 tcp_nopush on; # 开启TCP NOPUSH选项，禁止Nagle算法 tcp_nodelay on; # 开启TCP NODELAY选项，禁止延迟ACK算法 keepalive_timeout 300; # 设定keep-alive超时时间为65秒
采用的上面的配置，从逻辑上观察应该是代码设计的原因，下面我具体说明下：
如果走的工作流为①和③，工作流①会直接返回，工作流③会按照流式返回内容；
但是如果走的工作流为②，由于工作流②多了逻辑判断，且最后输出不是AI对话组件的输出，那么会等AI对话组件处理完后再进入到下一个判断组件，判断组件再进入到AI对话2组件，最后输出结果，由于显示的结果只是最后组件的结果，那么在组件AI对话组件耗时的时候前段就会卡在回答中等到流程进入到AI对话2组件才会有显示结果返回。工作流2的后续补充图如下：
如题，我期望的方式是可以选择要在前段页面显示的内容而不仅仅只有最后的输出结果，例如AI对话组件工作的时候把其回复的流也显示在前段页面上，经过AI对话组件2提炼用户可能或者想要问的下一个问题，然后也输出到前段页面，这样在处理AI对话组件的耗时也可以直观反映在前段，不会导致用户认为AI思考过程太长（说的直白一点就是可以把工作流的运行可选择式地反馈给用户）
如下图中的
内容先流式加载到前段页面，然后在进入逻辑判断把后续的输出也显示出来，从使用体验开看就是判断器1和指定回复1组件是需要AI对话组件完成的情况下才会执行，而且由于前段只支持最后的输出结果，那么造成的现象就是处理指定回复1前面的所有组件耗时的过程，前段页面都会卡在“回答中”的阶段，直到走到指定回复1组件才会在前端输出最终结果。
期望的形式是"AI对话组件"处理后返回的信息先加载到前段页面，这样避免了该段时间前段页面等待最终结果一直不动作；然后扩展到使用场景就是希望能增加有时序性质（可以采取流式阻塞等待的方式）的工作流任意组件输出内容同步到前端页面。
请描述你建议的实现方案
No response
附加信息
No response