OpenAI Agent Builder 曝光：拖拽建 AI 应用，n8n 的"低代码护城河"还守得住吗

OpenAI DevDay 的泄露信息显示，一款名为 Agent Builder 的新品正在路上——"拖拽即可构建 AI 应用"。这个说法之所以让工作流自动化圈层坐立不安，是因为它精准踩在了 n8n 这类平台的主战场：把"连节点、配参数、接模型、挂工具"这件事，从工程师的专业活变成普通用户的鼠标操作。更微妙的是，n8n 官方 README 的自我定位已经变成了 "The Platform for AI Agents and Workflow Automation"——它早就在往 AI Agent 编排上迁移，而不是守着传统 iPaaS 的饭碗。

这意味着冲突不是"平台方降维打击工具方"这么简单，而是两条技术路线在同一个交互范式上的正面碰撞。本文基于 n8n 仓库源码（主线索 2.43.0）逐层拆解：重叠区到底有多大、差异点真实在哪里、以及自托管工作流平台在模型厂商亲自下场后的三种活法。

一、Agent Builder 曝光了什么：与 n8n 的功能重叠区

先给情报定个位。目前可查证的信息主要来自 DevDay 曝光报道（华尔街见闻等媒体转载），核心卖点就一句话：在 OpenAI 平台上用拖拽方式构建 AI 应用。细节尚属泄露级别，本文不替官方背书任何具体功能清单，但方向是明确的——模型厂商要亲自吃掉"应用编排层"，让 ChatGPT 的模型、工具、沙箱和分发渠道在自家画布上闭环。

把 n8n 仓库摊开看，重叠区比表面看起来大得多：

1. 可视化拖拽画布：n8n 的本行。 仓库的 packages/frontend/editor-ui（约 3700 个文件，Vue3 实现）就是那个节点式画布编辑器，拖拽连线是它的原生交互，比 OpenAI 曝光的"拖拽建应用"早了七年。

2. 1500+ 集成：编排的弹药库。 README 明确写着 "connect to 1500+ integrations"，其中仅 packages/nodes-base/nodes 一个目录就有 308 个第一方节点包（Slack、Telegram、Webhook、HttpRequest、Airtable、SAP 系等），再加上 Community Nodes 生态。拖拽式 Agent Builder 的真正价值不在"画布"，而在画布上能拖什么——这是 n8n 目前最厚的家底。

3. 最关键的一点：n8n 自己已经在做"自然语言拖出工作流"。 很多人对 n8n 的认知还停在手动连线，但仓库里的 packages/@n8n/ai-workflow-builder.ee 包（企业版 AI 工作流构建器）已经把"用对话生成工作流"做成了工程化产品。它本质上是一个基于 LangGraph 的多 Agent 系统，每个阶段可独立配置模型（workflow-builder-agent.ts 中的 StageLLMs）：

export interface StageLLMs {
	supervisor: BaseChatModel;
	responder: BaseChatModel;
	discovery: BaseChatModel;
	builder: BaseChatModel;
	parameterUpdater: BaseChatModel;
	planner: BaseChatModel;
}

它给这个 Agent 配备了一整套"施工工具"（src/tools/ 目录）：add-node.tool.ts、connect-nodes.tool.ts、update-node-parameters.tool.ts、node-search.tool.ts、validate-structure.tool.ts、get-node-examples.tool.ts，甚至带 SSRF 防护的 web-fetch.tool.ts。构建过程中把工作流转成 Mermaid 流程图喂给 LLM（比 JSON 省 token），还配套了独立的评估体系（evaluations/ 目录 + LangSmith 对比评测）。

所以重叠区的准确画像是：OpenAI Agent Builder 想做的事，n8n 的企业版已经在做，且做在了更开放的底座上。 真正的区别在于谁掌握模型分发渠道、谁掌握应用数据。

二、源码里的差异点：平台级"降维"打不中的三处

差异一：模型自由 vs 模型锁定。 上面 StageLLMs 的定义本身就是一张声明——六个阶段全是 BaseChatModel 接口，OpenAI、Anthropic、Google 或开源模型随便换，README 把这写成卖点："Model Flexibility, No Lock-In... switch providers without changing your architecture"。模型厂商的 Builder 画布上跑的是自家模型，而 n8n 的编排层是模型中立的：今天用 GPT 做规划，明天降本换开源模型跑执行，架构不动。对多模型混用的生产系统来说，这不是小差异，是选型层面的差异。

差异二：自托管 = 数据不出门。 docker/get-n8n.sh 是 n8n 自托管部署的一行式入口（curl -fsSL https://get.n8n.io | sh），脚本内置版本解析、健康检查、升级逻辑（当前脚本 1.43.0 时代，回退版本 2.32.0，还带沙箱服务组件）。配合 PostgreSQL/SQLite 双后端（docs/generated/postgres-schema 下 160+ 张表的 schema 文档可以见其生产级程度），数据主权完全在用户自己手里。OpenAI 的 Agent Builder 必然是云端闭环：你的业务数据、用户对话、工具调用要过它的管道。对金融、医疗、政企和任何有合规要求的团队，"数据出不出内网"是一票否决项——这正是自托管平台的结构性护城河，平台方越是大，这个差异越刺眼。

差异三：Agent 基础设施的纵深。 n8n 不只是"会画 Agent 的画布"，它已经往下扎了三层：

• packages/@n8n/agents：自研 Agent SDK，fluent builder 风格 API，内置 MCP 客户端、记忆（memory）、guardrails、eval、沙箱化 Workspace（AGENTS.md 描述了完整包结构，运行时基于 AI SDK）；
• 数据库层：agents、agent_execution、agent_checkpoints、agents_memory_entries、agent_budget_spend 等一整套表，说明 Agent 执行是带检查点、带预算控制的长期运行系统，而不是玩具；
• packages/modules/mcp + packages/@n8n/nodes-langchain/nodes 下的 mcp、agents、tools、vector_store、Guardrails 节点目录，覆盖 MCP 接入与向量检索的全链路。

换句话说，OpenAI 在卖"建应用的画布"，n8n 在补"跑应用的底座"。画布谁都能画，底座需要数年积累。

三、预判：n8n 们的三种活法

情报里还有一条值得注意的信号：媒体在报道 Coze 3.0 时用的标题是"AI 编程冲击下，低代码编排平台如何生存"——"低代码编排平台如何生存"已经是整个品类的公开议题，OpenAI Agent Builder 只是把它推到了最尖锐的位置。结合 n8n 仓库的实际布局，我认为这类平台的活法有三条：

活法一：守住 B2B 长尾与集成纵深，不跟模型厂商拼 C 端体验。 OpenAI 的画布再好看，也复制不了 308 个第一方节点包 + Community Nodes 生态背后对 SAP、Salesforce、各种本土 SaaS 的脏活累活集成。C 端"搭个 AI 客服玩玩"会被截流，但"把 ERP 和三家邮件系统、内部知识库接起来"这类需求的决策逻辑是数据主权 + 集成覆盖度，恰恰是自托管平台的领地。

活法二：从"工作流编排"升级为"AI Agent 运营平台"。 @n8n/agents SDK、Agent 执行/记忆/预算/检查点的数据模型、ai-workflow-builder.ee 的生成器加评估闭环，指向同一个方向：n8n 想成为 Agent 的运行时和运营层——生产、部署、观测、评估、预算控制。模型厂商的 Builder 解决"怎么造"，n8n 解决"造出来之后怎么在生产环境里安全地跑"。这条路上，模型厂商反而是互补方而非对手。

活法三：用 fair-code 商业模式避开开源红海。 注意 n8n 的许可是 Sustainable Use License + 企业许可（LICENSE.md、LICENSE_EE.md），不是 OSI 意义的开源，而是"源码可见 + 可自托管 + 禁止 SaaS 转售"的 fair-code。它允许团队自由自托管（保住技术心智），同时保留企业特性收费权（RBAC、审计、SAML 等），不会被"开源必须免费"的社区预期绑架。在媒体已经报道 SAP 等大型企业将 n8n 接入其 AI Studio 生态的背景下，这条 To B 商业化路径是有真实客户的。

结语：护城河不是画布，是底座与数据主权

回到标题的问题：n8n 的低代码护城河守不守得住？答案是分层回答的——画布这一层守不住也不值得守，OpenAI 拿着模型分发渠道入场，C 端拖拽体验的战争它会赢；但集成生态、自托管数据主权、Agent 生产底座这三层，是平台级玩家结构性够不到的地方。从源码看，n8n 押注的正是后三层：模型中立的编排接口、一行命令的自托管部署、以及从执行到记忆到预算的 Agent 运行时。

对从业者的启示很直接：如果你的自动化需求数据敏感、集成异构、要长期运维，n8n 类平台的相对价值在 Agent Builder 曝光后反而上升了；如果你只是要一个快速上线、托管在别人云上的轻量 Agent，模型厂商的画布确实是更短的路径。品类会分裂，但不会消失——低代码编排平台的终局不是被降维，而是让位到它真正擅长的位置：模型厂商们不想碰、也碰不了的那部分脏、重、敏感的生产现场。