大家好，
我一直在尝试使用 Dify 构建一个用于游戏性能数据的实时监控助手，但在平台处理来自外部源的快速数据注入方面遇到了一个严重的瓶颈。我正在尝试设置一个工作流，从本地环境中拉取遥测数据，但每当请求频率超过某个阈值时，Dify 的“HTTP 请求”节点似乎就会挂起或返回 429 错误。
在我寻找优化脚本处理使其更轻量级的方法时，我偶然发现了一篇关于这个网站的博客文章，其中讨论了一些简化执行的有趣方法。我实际上开始思考，这里是否有人成功使用过 blox fruit scripts 或类似的高活动自动化工具作为构建 Dify DSL 工作流的参考？我特别好奇是否有办法使用“变量赋值”节点来缓冲这些传入的脚本调用，然后再将它们发送到 LLM 节点，或者我是否应该考虑使用更强大的队列系统，例如 RabbitMQ，来放置在我的本地脚本和 Dify API 之间。
我还遇到了一个相关问题，即如果外部脚本在超时后尝试重新连接，“会话 ID”会变得无效。有没有人注意到 Dify 云版本对这类自动化后台执行的速率限制比自托管 Docker 实例更严格？我正在尝试决定是否应该将我的整个堆栈迁移到本地服务器以避免这些延迟峰值，或者是否有特定的“条件”节点逻辑可以帮助沙盒化这些外部触发器，从而防止它们淹没主工作流。任何关于如何在不导致 UI 崩溃的情况下保持数据流稳定的建议都将大有帮助！