5年前我构建了自己的工作流编程环境，以自动化各种安全流程。从这次经验中我学到的是，工作流工具真的很糟糕。它们本质上是相当糟糕的脚本语言——对于高层次的组合来说尚可，但在实现简单算法时几乎毫无用处。但我想这可能只是我从各种编程环境中的经验得出的个人观点。有很多用户发现这种编程方式对于完成任务至关重要。但对我来说，我更喜欢直接编写代码。我认为这类工作流工具最终会被AI代理取代。
源讨论展示HN：我构建了一个可视化工作流自动化平台——FlowRipple原帖 65 条评论 · 导入时统计FlowRipple旨在轻松地简化和自动化业务流程。无论您是开发者、企业主还是营销人员，我们的平台都可让您构建自定义的工作流程，这些流程可由您应用程序的事件、网络钩子或定时触发。我们刚刚上线，并正在提供一个独家的早期访问计划，有一些令人难以置信的优惠，帮助您开始。
完整原文把你的经验，加入这段讨论。
我认为最后一点很关键。这些工具也被那些不会编程、被学习门槛吓到，或者被困在禁止用户脚本的SaaS/安全生态系统中的人使用。这三种情况都可以通过LLM在沙盒环境中组合脚本来解决。
完整原文最近我了解了企业调度解决方案。特别是IBM/HCL的工作负载自动化——这家公司正在积极寻找替代方案，但似乎除了中国支持的开源方案外，其他都没有接近的（而且这对管理层来说可能是一个过于激进的步骤...）。 脚本的一个缺点是你会错过一个良好的工作流引擎，它本质上提供了一个简单且定义明确的层，允许你耦合许多并发进程并提供资源管理。有趣的是，所有开源的工作流工具默认也是如此——就像你说的，人们（Airflow有池，但之后...）基本上构建了非常奇怪的DSL来实现高层次的组合，而你确实可以很容易地自己编写代码。我认为这些公司起源的工具可能有其他部分的集成，而其他人则用一些半吊子的方案来做假的弹性扩展。…
完整原文这类产品的主要限制是图/工作流本身在数据流选项方面表达能力不够。最终你需要map、reduce和状态机，以及相应的并发和持久执行。很难有一个高层次的声明式工具，同时又能暴露强大的编程原语；在某些时候，技术上的必要知识会跨越那个点，你可能干脆让用户自己写代码。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。