n8n_agent
用自然语言描述让 AI 直接生成完整 n8n 工作流 JSON 的 CLI 工具集,支持向量语义搜索
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
用自然语言描述让 AI 直接生成完整 n8n 工作流 JSON 的 CLI 工具集,支持向量语义搜索
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
agent: 表示 AI Agent 工作流、workflow: 表示普通工作流、tool: 表示工具类工作流- 名称(Name):从文件名中解析出可读的工作流名称- 描述(Description):分析节点类型和服务依赖,生成自然语言描述- 标签(Tags):提取节点类型和外部服务(如 Gmail、Slack、OpenAI)作为标签- 复杂度(Complexity):根据节点数量、连接数量和节点类型多样性计算复杂度评分这段解析逻辑的质量直接影响最终生成工作流的质量。一个典型的工作流文件可能包含 15-25 个节点,涉及多种节点类型的交互。### 2. 向量数据库集成(QDRANT + OpenAI Embeddings)项目将解析后的工作流转换为向量嵌入(text-embedding-3-small),存储到 QDRANT 向量数据库中。这使得用户可以用自然语言语义搜索相似工作流——例如搜索"处理邮件回复",系统会找到所有相关的工作流,而不仅仅是标题匹配。向量搜索的关键优势在于:当用户想创建一个"类似的,但针对不同场景"的工作流时,不需要重新描述所有细节,只需找到最接近的现有工作流作为模板,让 AI 在此基础上修改即可。这大大降低了提示工程的难度。### 3. 图数据库(Neo4j)—— 关系图谱构建Neo4j 集成用于构建工作流之间的关系图谱。每个工作流是一个节点,节点之间的关系("相似于"、"衍生自"、"依赖")以图的边来表达。这种知识图谱可以揭示:- 哪些工作流被多次复用(高连接度节点)- 工作流的演化路径- 不同业务场景下工作流的典型结构模式### 4. 关系型数据库(Supabase)—— 结构化元数据存储Supabase 用于存储工作流的结构化元数据,包括用户评分、使用频率、分类层级等。相比向量数据库,Supabase 更适合需要精确查询和聚合分析的场景。## 核心功能详解:从提示词到可运行工作流### 工作流导入与验证n8n_agent 提供了完整的 n8n MCP(Model Context Protocol)客户端,可以直接与 n8n 实例通信。用户可以:- 将生成的工作流直接导入 n8n 实例- 验证工作流是否符合 n8n 最佳实践规范- 在导入前检查节点 ID 唯一性、JSON 语法正确性、凭据配置完整性内置的工作流验证器(n8n-workflow-validator.js)从五个维度检查工作流质量:| 维度 | 检查内容 ||------|---------|| 命名规范 | 节点和工作流是否有描述性名称 || 错误处理 | 是否包含错误处理节点和降级逻辑 || 安全性 | 凭据使用是否规范,是否暴露敏感信息 || 性能 | 是否有潜在的无限循环或性能瓶颈 || 文档 | 是否有注释说明工作流用途 |### 多数据库导出支持一个工作流经过解析后,可以同时输出到四种数据库:工作流 JSON 文件 ├─ workflow-parser.js ─→ processed-workflows/ (本地增强元数据) ├─ vectorize-with-mcp.js ─→ QDRANT (语义搜索) ├─ neo4j-loader.js ─→ Neo4j (关系图谱) └─ supabase-vector-loader.js ─→ Supabase (结构化存储)这种"一次解析,多处复用"的设计使得工作流知识可以被不同工具以不同方式访问。## 上手体验:门槛有多高?### CLI 工具包(适合开发者)作为 Node.js CLI 工具,n8n_agent 的部署非常简单:bashgit clone https://github.com/kingler/n8n_agentcd n8n_agent && npm installcp .env.example .env # 配置 API key 和数据库连接npm run parse # 解析现有工作流运行的前提是:你已经有了一个 n8n 实例(可以是自托管或 n8n Cloud),以及必要的 API keys(OpenAI API key 是必须的,QDRANT/Neo4j/Supabase 可选)。对于有 n8n 使用经验的开发者来说,10 分钟内可以跑起来。### Web UI?不存在的n8n_agent 没有独立的 Web 界面,所有交互都通过命令行完成。对于不熟悉终端的普通用户,这个工具并不友好。但这对于目标用户(懂技术的自动化工程师、AI 开发者)来说反而是优势——他们更习惯在代码环境中工作。### AI 能力的上限工作流生成质量完全取决于底层 LLM 的能力。当前 GPT-4o 和 Claude 3.5 Sonnet 在处理中等复杂度工作流(10-20 个节点)时表现良好,但对于涉及大量外部服务认证、复杂错误处理分支的"企业级"工作流,生成结果仍需要人工审核和调整。## 争议与局限:理想与现实的落差### 1. n8n 版本兼容性问题n8n 的节点类型和参数规范在版本迭代中有变化。项目维护者的最后一次提交停留在 2025 年 5 月,项目中使用的 LangChain n8n 节点(@n8n/n8n-nodes-langchain)在更新的 n8n 版本中接口可能有差异。用户在实际使用时,需要确认自己 n8n 实例的版本与工具生成的工作流兼容。### 2. 无法替代复杂业务逻辑设计n8n_agent 擅长生成结构正确的工作流,但不擅长理解深层业务逻辑。一个真正可靠的生产级自动化流程需要考虑:数据一致性、幂等性、异常通知、人工审批节点等。这些需要业务经验的细节,当前版本无法自动处理。### 3. 知识库需要持续维护QDRANT/Neo4j/Supabase 的价值取决于工作流样本库的丰富程度。如果用户的工作流数量不足或质量不高,向量搜索和图谱分析的价值会大打折扣。这意味着 n8n_agent 更适合有大量工作流积累的组织使用。## 行业意义:工作流自动化的"Copilot 时刻"n8n_agent 代表的趋势是工作流自动化领域的 AI Copilot。类比软件工程中的 GitHub Copilot 让程序员写代码更高效,n8n_agent 正在让 n8n 工作流的设计变得更高效。从数据来看,n8n 社区在 2025-2026 年涌现了大量 AI 工作流生成工具,包括 n8n 官方的 AI Agent 节点、Chrome 扩展市场的 n8n AI Assistant,以及各类模板市场。但大多数方案都是模板匹配或规则转换,真正利用 LLM 理解和生成结构化工作流的项目凤毛麟角。n8n_agent 的创新之处在于:它不是教你用 n8n,而是帮你构建一个 n8n 工作流知识体系——解析、分类、存储、搜索、生成五个环节形成闭环。这使得 AI 不仅能生成新工作流,还能从现有工作流库中学习模式、发现规律,最终产出更符合实际需求的自动化方案。随着 LLM 在代码生成和结构化理解能力上的持续提升,这类"AI 工作流生成+知识管理"工具的价值会越来越显著。对于已经在使用 n8n 的团队来说,n8n_agent 提供了一个低成本切入 AI 辅助自动化的路径;对于 n8n 的潜在用户来说,它也降低了一点"学 n8n 很难"的心理门槛。