我开始构建一个开源 n8n 仓库,但现在我觉得它已不再是我最初设想的东西了。
摘要
作者反思了构建一个开源 n8n 工作流仓库的经历,该仓库已演变成一项社区驱动的努力,旨在记录 AI 工作流背后的工程原理,包括各种权衡和设计决策。
当我开始这个项目时,我以为我只是在收集可重用的工作流。但和越多的工程师交流,我就越不这么认为。没人真正关心 n8n 本身。也没人在意导出的 JSON。讨论总是不断转向相同的工程问题:工作流契约、重放语义、权限、状态管理、审批、可移植性,以及 AI 系统应该如何真正组合。不知怎的,工作流本身不再是有趣的部分——它变成了证据,工程变成了讨论。这完全改变了我对这个仓库的看法。也许它不再只是工作流的集合,而是逐渐成为一个记录现代 AI 工作流如何工程化的地方——不仅记录工作流做什么,还记录为什么这样设计,背后的权衡,以及其他工程师如何质疑、改进和适应这些想法。最棒的是,这个方向并非我一人之功。它来自数十位工程师,他们用完全不同的语言独立指出了同一缺失的抽象。这种集体讨论对这个项目的塑造,远超任何我独立撰写的路线图。我仍在摸索它的走向。正因如此,我选择公开构建。如果它最终不再只是一个 n8n 仓库,我更希望这种演变由公开讨论驱动,而不是由我独自决定。
相似文章
构建 n8n AI 支持工作流是容易的部分。以下是我为生产环境测试时学到的经验。
一位开发者分享了构建生产级 n8n AI 支持工作流的经验,强调分类优于生成、基于规则的过滤器以降低成本,以及将响应基于知识库以避免幻觉答案。
Zapier 和 n8n 从根本上就不适合 AI 时代。所以,我正在构建一个“AI 原生”的替代方案。需要你的残酷反馈!🚀
作者批评 Zapier、n8n 等传统工作流工具不适合 AI 时代,并推介了一个新的 AI 原生自动化平台,其功能包括对话式构建画布、自愈管道、动态智能体集群、WhatsApp 人在回路以及白标发布。
我重建了我的私有“AI开发团队”——它实际上只是一个硬编码的工作流——将其作为一个基底,使得编排从指令中涌现。以下是我的经验教训(以及它在哪里发生死锁)。
作者将其私有AI开发团队重建为一个开源的基底,包含可寻址的代理、可靠的消息传递、专长发现、记忆和隔离的运行时,使得团队行为能够从自然语言指令中涌现。他们分享了关于死锁和自我修复等协调挑战的见解,并提出了代理团队如何通过自然语言指令进行协作的问题。
我开始构建一个开源工作流集合。Reddit 让我相信我解决错了问题。
作者描述了将他们的开源工作流共享项目转向 Scyvera 的过程。Scyvera 是一个为智能体工作流定义契约的工具,用以建立边界、权限和治理。作者邀请社区对此抽象提出反馈。
我的开源 n8n 风格 MCP 工作流应用现在正通过自身、由自身、利用自身进行改进(你也可以将其用于你自己的项目……我将展示如何操作)。
一个开源 MCP 工作流应用,能够利用自身能力进行自我改进,并附有将其用于你自己项目的说明。