10月6日OpenAI DevDay 2025召开，出乎意料的他推出了一个AgentKit的产品，旨在帮助开发者以更少的时间和精力，完成从原型设计到生产部署的全过程。
简单来说就是OpenAI搞了一套工作流编排工具，其本质是低代码平台。
随后LangChain创始人直接表示可视化工作流构建器，那玩意没用，谁愿意做谁做呗。原因很多：拖拽不利于复杂工程！大白话是门槛太高，程序员看不上，一般人用不习惯，两头不看好...
只不过因为OpenAI巨大的影响力，其“直接竞品n8n”却受到了不少伤害，因为没2天就宣布了其融资1.8亿美金的公告（10月9日融资）。
所以是在n8n融资关键期，AgentKit这个“竞品”横空出世了，他们自己当然认为AgentKit不是自己的对手。
但我觉得n8n依旧被OpenAI搞麻了，毕竟风投可真没那么懂技术，在那个节骨眼n8n必定准备了非常多的说词，最后终于拿下融资，松了一口气。
而后10月13日，受不了的n8n把可能“压箱底”的新功能AI Workflow Builder丢了出来，继续“打脸OpenAI”：
都别卷工作流拖拽了，再也不用梳理工作流了，我们以后直接自然语言生成n8n就好！
所以，现在重点进入了自然语言生成工作流的赛道了？
unsetunset自然语言 → 工作流unsetunset
事实上，AI Workflow Builder 也不是第一个提出自然语言生成工作流的玩家，Zapier 在 10月3日已上线 AI 生成（工作流）大纲；
在 Zapier 控制台用自然语言描述“当 X 发生 → 做 Y → 再做 Z”。系统会产出触发器 + 若干动作的草稿大纲，随后进入编辑器继续细化。
Make 也在公开路线中强调 AI 辅助构建，用目标语句让助手为你搭一个场景（scenario）骨架，并能解释场景如何工作、帮你排错。
离大家近一点的是8月25日，钉钉提出的AI表格助理，其背后目的也是大幅降低搭建工作流的难度。
钉钉 AI 表格助理正式上线后，用户只需自然语言对话描述想法，它就能按要求自动生成 AI 表格、自动化工作流以及数据仪表盘分析，创造出一个个真正可用的 AI 应用，大幅降低 AI 表格的使用门槛，人人都是 AI 应用的创造者：
上述都应该隶属于，在数据积累够了的情况下，比如已经拥有了充足的HR招聘工作流的 提示词/编排数据 后，用Agent的思路来降低KnowHow的成本。
只不过从各方面文章情况来说，整体效果应该还比较初级，然后这里紧接着会有一个问题：为什么会有AI Workflow Builder这种东西存在？
unsetunsetAI Workflow 的意义unsetunset
先说答案，对于一般玩家来说：工作流太难了！n8n这种属于程序员工具了，对产品都不太友好、Coze对于产品经理倒是友好，但是对于更初级的人，比如医生、律师这种非互联网人来说依旧不友好，这里的难点有二：
第一，工具的使用很烦，就我来说，Coze、n8n毫无难度，但也是花了2周的时间熟悉他的各种工具，在工具熟悉之前，不会有事实上的卡点，但真的会很耗时间，比如Coze的循环，我就搞了2小时才玩明白；
第二，梳理SOP极其麻烦，这是真正的难点，只要是工作流类AI应用，其难点一定在工作流的数量，这里又有两个难点，一个是对相关工种业务的基本理解、一个是团队实际沟通会很反复、很费劲，比如这里我们梳理的HR工作流：
到这里开始加速了，大家集中注意力跟我一起推衍，这部分是我AI培训课付费内容，没有一定上下文可能比较费劲，方便大家理解这里以医生为例，只不过律师、教师都是一样的：
unsetunsetAI数字分身的演进逻辑unsetunset
你是一名工作10年的心内科的医生，大学期间的专业是程序员（并且非常专业，这些年偶尔副业），于是乎你具备了医疗的KnowHow与技术工程能力。
你医术高超，一天可以看100个病人，只不过名声在外，你实际的患者数量高达1000+，但其中900+病人的问题都很基础，根本不需要你出手。
于是乎，你拿起了技术的武器，为自己的日常工作搭建了一套工作流AI，并且为其设计了专有的数据结构（或者上下文工程也行），将自己的心内科知识结构化了进去。
这个心内科数字分身上线后广受好评，他很好的解决了你90%的患者，并且你的老婆眼科医生、你的小舅子神经内科医生、你的小情人心理科医生都想用这套系统。
于是乎你开始做抽象，将你的工作流与数据做剥离，只保留基本Agent框架以承载工作流代码（JSON结构）与数据，最终你实现了一个类似于Coze的系统，交给了老婆他们使用。
结果，你的老婆、小舅子、小情人并不买单，他们认为你是傻逼直男，那种复杂的工作流拖拽动作，他们哪有能力去完成？并且还要整理那么多结构化的数据，这不是要他们的命吗？
于是乎，在他们的不停督促下，你不得不对系统进行进一步简化，核心功能是两点：
第一，让普通人可以更加自然语言生成工作流。
但是大模型并没有那么聪明，无奈之下你不得不为每个科室提前生成了数套常见的工作流，以便如你老婆那种小白用户在自然语言叙述的时候，模型能够根据模板尽可能的生成正确的工作流JSON配置；
第二，让普通医生能够上传触手可得的数据，比如医患对话、病例信息，而后自动生成AI需要的专业数据。
要完成这点，你至少又做了两点，首先是想方设法用自己的医患对话数据以及病例数据，生成与你历史沉淀的历史数据相同的内容；然后按照这套逻辑再次为各个科室生成基本的数据集，但是可以让医生做最基本的修改；
要完成这两点花了你大量的精力，最终交付给老婆他们时，终于得到了一个点赞，然后你才发现：他们真的是一点多余的动作都不想有啊！
以上就是AI数字分身的演进逻辑，事实上也是n8n工作流到AI Workflow的演进逻辑，最后来看看n8n的实际情况：
unsetunsetAI Workflow 实测unsetunset
在 n8n Cloud 界面中进入 AI Workflow Builder，对话框提供实时生成进度反馈，并可以追加指令对工作流进行迭代优化。
PS：当前 AI Workflow Builder 处于 Beta 阶段，而且自然语言指令会消耗一定积分
总体感受下来，该功能应该定位在帮助具有一定技术背景但非专业开发人员的用户快速将KnowHow转化为可运行的 n8n 工作流。
这里有个问题是很关键的：n8n生成的工作流是全新的吗？还是说内部通过检索已有工作流模板？
n8n 官方提供了一个庞大的工作流模板库，公开的社区模板超过 6000 个，如此丰富的现成流程，理论上可作为“范例”供 AI 重用。这个问题关系到AI 生成流程的独创性和可靠性。
如果是原创生成，可能更灵活，但也更容易出现错误配置或“幻觉”节点；如果是基于模板复用，输出质量或许更稳定，但可能缺乏创新。
推论实现策略
n8n 的工作流本质上是 JSON 格式定义的，包括节点列表、连接关系、各节点参数等。我们获取了一份由 AI Workflow Builder 生成的示例工作流 JSON，下面只截取关键片段：
{
"name": "AI Generated Workflow",
"nodes": [
{
"id": "1",
"name": "Gmail Trigger",
"type": "n8n-nodes-base.gmailTrigger",
"parameters": { ... }
},
{
"id": "2",
"name": "AI Agent",
"type": "@n8n/nodes-base.openai",
"parameters": { ... }
},
{
"id": "3",
"name": "Slack",
"type": "n8n-nodes-base.slack",
"parameters": { ... }
}
],
"connections": {
"Gmail Trigger": {
"main": [[ { "node": "AI Agent", "type": "main", "index": 0 } ]]
},
"AI Agent": {
"main": [[ { "node": "Slack", "type": "main", "index": 0 } ]]
}
}
}
示例说明：假设用户提示要求“监控Gmail新邮件并用AI总结后发Slack通知”，AI生成了上述含 Gmail触发器→AI总结节点→Slack发送 的流程结构。
接下来就只需要进行多组测试即可，用不同描述相近的自动化需求，让 AI Workflow Builder 分别生成流程，并比对它们的节点构成与结构。结果发现，一些功能类似的工作流确实呈现出高度相似的模式。
并且，来自社区提供的系统提示词片段。第三方开发者构建的 n8nBuilder AI 工具（类似于官方AI Builder的理念）公开了一段用于指导底层LLM的System Prompt。
其中明确要求模型：“将这些范例用作类似用例的模板；复制示例中的节点结构、参数格式和连接模式”。
所以，n8n的AI Builder应该是 模板检索+微调 的工作模式
而这没什么不好的，甚至反而是追求工作流AI项目稳定性更愿意见到的方式。
AI Builder 的意义
如AI数字分身演进部分的描述，AI Builder 的意义依旧在降低门槛这里，只不过我有些认为不是为非专业人员使用的。
只说使用门槛，对于一般人n8n是绝对高于Coze、dify、FastGPT的，所以就算是生成了多数工作流，依旧有很多参数需要设置的部分，如图所示：
你要相信我，这里还是和你老婆和小舅子一样，他们依旧玩不明白，并且多一步路都不想走！
所以，我倒是认为更大的意义在于证明了一个可行性：根据已有成熟的工作流，n8n可以快速生成80%你想要的算法（工作流）框架！
举个例子，我要做一个HR场景的降本增效，但我又想无痛零启动，那么这个时候AI Builder来一套就很爽了！
unsetunsetAI Workflow 与 AI Codeunsetunset
这场由 OpenAI AgentKit 点燃的 工作流拖拽王者 之战，一不留神就被带到了“低代码”与“自然语言生成”两种技术路径的竞争，事实上这不是偶然，从前段时间钉钉发布会的AI表格助理就可见端倪。
这一切背后真正指向的，是一个更根本的问题：我们究竟需要多低的门槛，才能让每一个领域的专家，都成为 AI 应用的生产者？
从拖拽编排到自然语言生成，n8n清晰地勾勒出一条技术普惠的演进路径。它不再是让AI从零开始去“建造”去“猜”，而是转向基于海量模板库的“检索-组装-微调”。
这看似是大模型能力不足的妥协，实则是AI项目实践的心态成熟：AI 不是要生成完美的、具有创意的代码，而是要理解用户的意图，并调用已被验证的的模块，快速组装出稳定可用的解决方案。
只不过，n8n的对手当然不是AgentKit（Coze的话，还可以再努努力），所有工作流类低代码平台实际上应该警惕的是AI Code！
我们不得不重视一个正在发生的事情：AI Code 与 各个Agent平台可能正在完成相同的功能。
虽然，AI Workflow更擅长流程类、集成类的“流水线”工作，而AI代码生成擅长“从无到有”地编写定制逻辑。
只不过，我看这个界限可能会慢慢的被打破，因为GitHub上优质的代码太多了，尤其是前端领域，几乎不存在AI没见过的“页面”（前端代码）！
PS：比如这次Manus1.5发布，其在前端编程一块就特别强力
回归一下，这场自然语言翻译KnowHow直接形成方案的混战，是低代码平台使用AI实现自然语言编程，真无代码了；还是AI Code吊炸天了，其实都还为时尚早，简单来说：
无所谓，谁能稳定把可复用的范式搞明白，我们用谁就好。
而且从实现底层来说，其实AI Workflow 和 AI Code 相似性很高：AI Workflow 是阅读了大量JSON配置从而生成想要的JSON、AI Code 是阅读了大量Code从而生成预期的Code，只不过他们具体执行环境不同罢了，相较而言，AI Code会更底层一些。
进一步，AI Workflow不是要替代工程，而是让工程把精力放在真正需要人的那20%上，只不过他可能需要更加智能。因为，就我研究下来，其实他并不节省我整理SOP的时间，节约的部分是我擅长而不关注的部分。
最后，我们不得不注意一件事：无论是AI Workflow 还是 AI Code，他们想要更加智能，这背后一定需要更多的生产案例被吃进去，那么你的知识安全，是一定得不到保证的...
