零代码LLM开发平台全景综述——非技术人员也能造AI应用

论文信息

• 论文原标题：Review of Tools for Zero-Code LLM Based Application Development
• 主要作者及研究机构：1 University of Washington, Seattle, USA,
• 收录情况： Accepted in 6th World Conference on Artificial Intelligence: Advances and Applications (WCAIAA 2025)

一段话总结

该论文对零代码LLM（大语言模型）应用开发平台展开全面综述，通过界面风格、LLM后端支持、输出类型、定制化程度四大核心维度，将平台分为专用LLM平台（如OpenAI Custom GPTs、Flowise、Dust.tt）与通用无代码平台（如Bubble、Glide）两类，分析了它们在自主代理、内存管理、工作流编排、API集成等核心功能上的表现，对比了各平台的优劣与适用场景，探讨了与传统/低代码开发在定制化、可扩展性、供应商锁定方面的权衡，并指出多模态界面、端侧LLM、多代理优化编排等未来方向，强调此类平台虽大幅降低AI应用开发门槛，但仍面临灵活性不足、AI输出可靠性低等挑战。

研究背景：为什么需要零代码LLM平台？

想做一个AI客服机器人，却不会写代码？想让Excel表格自动提取发票信息，却搞不懂API调用？这就是过去“AI应用开发”的痛点——技术门槛把大多数人拦在了门外。

之前大家靠“无代码/低代码平台”（比如Mendix、Power Apps）降低开发难度，但这些工具仍有局限：复杂逻辑（比如让AI自主拆分任务、调用工具）还是需要写代码，而且没法充分利用LLM的自然语言理解能力。

直到GPT-4、Claude等大模型出现，情况变了：LLM能读懂人类的文字指令，还能自动生成逻辑、调用工具。于是，“零代码LLM平台”应运而生——它就像“AI应用的积木”，非技术人员只要说清需求（比如“做一个能查天气的聊天机器人”），或者拖拽几个模块，就能快速做出能用的AI应用。

举个例子：营销人员用OpenAI GPTs，上传品牌资料后，5分钟就能做出一个“品牌咨询机器人”；小公司用Glide，把Excel表格导入，再加个“AI提取客户反馈关键词”的功能，就能生成一个客户管理App。这种“不用代码、快速落地”的需求，正是零代码LLM平台爆发的核心原因。

2. 详细总结

1. 引言：零代码LLM平台的崛起背景与研究目标

• 背景：传统无/低代码平台虽降低开发门槛，但复杂逻辑仍需编码；LLM（如GPT-4）通过自然语言解析与代码生成，催生零代码开发模式，让普通用户通过文字描述创建功能原型。
• 研究范围：覆盖两类平台——专用LLM应用构建器（如OpenAI Custom GPTs、Flowise）与集成LLM功能的通用无代码平台（如Bubble、Glide）。
• 研究目标：建立分类体系、分析核心功能、对比平台优劣、探讨权衡问题与未来方向，为实践者与研究者提供参考。

2. 零代码LLM平台的分类法（四大核心维度）

通过Table 1明确两类平台在关键维度的差异，具体分类如下：

维度（Dimension）	专用LLM平台（Dedicated LLM Platforms）	通用无代码平台（General No-Code Platforms）
界面类型	对话式（Chat）、可视化流图	GUI构建器、模板（Templates）
输出类型	AI代理（Agent）、工作流（Workflow）	全应用（Full App）、嵌入式AI（Embedded AI）
LLM后端	模型无关、OpenAI、Anthropic	以OpenAI为主、自动选择（Auto-select）
定制化程度	低代码钩子、SDKs	纯无代码、插件模式（Plugin mode）
代表案例	GPTs、Flowise、Dust.tt	Bubble、Glide

• 平台类别：核心区分在于是否“围绕LLM原生设计”——专用平台聚焦AI驱动任务（如对话代理、文本分析），通用平台聚焦全应用开发（如web/mobile App）并附加AI功能。
• 界面类型：
  • 对话式：用户通过聊天指令创建（如OpenAI GPTs、Bolt.new），门槛最低；
  • 可视化流图：拖拽节点定义逻辑（如Flowise，类似Node-RED），适合需清晰流程的场景；
  • 传统GUI构建器：通用平台的主流方式（如Bubble的组件拖拽），LLM通过插件配置集成。
• LLM后端：
  • 绑定型：仅支持特定模型（如OpenAI GPTs仅用GPT系列）；
  • 灵活型：支持多模型/开源模型（如Flowise兼容LangChain、LlamaIndex，100+集成）；
  • 新兴方向：端侧LLM（如Llama 2变体），满足隐私与离线需求。
• 输出类型：从“纯AI交互”到“全功能应用”，包括聊天机器人（GPTs）、全栈App（Bolt.new）、后端工作流（Dust.tt）、混合应用（Glide的带AI组件App）。
• 定制化&可扩展性：
  • 纯无代码：无编码需求（如Cognosys），灵活度最低；
  • 低代码钩子：支持自定义插件/脚本（如Flowise）；
  • 代码导出：Bolt.new可导出生成的代码，支持离线优化；
  • 外部集成：Dust.tt支持“无上限数据连接”，Bubble通过插件对接任意API。

3. 核心功能与能力（关键特征对比）

零代码LLM平台的核心竞争力体现在以下5点，Table 2、3进一步细化各平台表现：

表2：核心功能对比（Part 1）

平台（Platform）	界面风格（Interface Style）	代理/工具使用（Agent/Tool Use）	内存（Memory）
OpenAI GPTs	对话式（Chat）	有限工具支持	会话记忆+配置知识
Bolt.new	对话+代码预览	全API+工具调用	会话+指令记忆
Dust.tt	模板+流图	完整代理工具包	RAG+数据集成
Flowise	可视化图（Visual Graph）	自定义代理/工具	向量数据库（LangChain）
Cognosys	对话+代理UI	自主代理循环	部分记忆（搜索/Q&A）
Bubble	可视化构建器	无代理（需API调用）	数据库+插件记忆
Glide	可视化构建器	无代理（嵌入聊天）	AI字段级记忆

表3：核心功能对比（Part 2）

平台（Platform）	工作流逻辑（Workflow Logic）	LLM后端（LLM Backend）	可扩展性（Extensibility）
OpenAI GPTs	无（对话驱动）	GPT-only	封闭（纯无代码）
Bolt.new	聊天引导	Claude	可导出代码
Dust.tt	链式+条件逻辑	多模型	API+低代码
Flowise	节点分支/循环	任意（含开源）	完全可扩展
Cognosys	代理自主决策	基于GPT（推测）	封闭SaaS
Bubble	经典工作流引擎	任意（需API）	插件+JS
Glide	事件驱动逻辑	OpenAI	公式+有限代码

• 代理支持：专用平台（如Cognosys、Dust.tt）支持自主任务拆分与工具调用，通用平台（如Bubble）需手动配置API实现类似功能。
• 内存与知识集成：
  • 短期记忆：依赖会话历史（如GPTs）；
  • 长期知识：通过RAG连接数据库/文档（如Dust.tt、Flowise）；
  • 自定义指令：GPTs支持一次性配置，增强模型专用性。
• 工作流逻辑：Flowise、Dust.tt支持可视化分支/循环，GPTs依赖LLM内部推理（易不可控），Bubble需通过“解析AI输出关键词”实现条件触发。
• API集成：Flowise（100+集成）、Dust.tt（无上限连接）、Bubble（插件市场）支持丰富外部工具，Cognosys仅支持预设集成（如Google Drive）。
• 多模态能力：Dust.tt、Cognosys支持图像分析，Glide支持OCR（如收据数据提取）与音频转录，Bubble通过插件扩展多模态。

4. 代表性平台详细对比

通过Table 4聚焦5个核心平台的关键差异，同时补充核心特点：

表4：零代码平台特征支持对比

特征（Feature）	GPTs	Cognosys	Flowise	Zapier AI	Dust.tt
LLM灵活性	中等	高	高	低	中等
工作流逻辑	中等	高	高	高	中等
API集成	中等	低	高	高	中等
UI生成	低	中等	低	无	中等
代理支持	中等	高	中等	低	中等
开源性	否	否	是	否	部分

• OpenAI Custom GPTs：2023年底推出，无代码配置聊天机器人，支持上传知识库与基础工具（如网页浏览），适合简单任务（如旅行规划），但逻辑复杂度低、不可扩展。
• Bolt.new：基于Anthropic Claude，通过聊天指令生成React/Node全栈代码，支持预览与Netlify部署，适合有基础编码知识的用户，但调试依赖指令清晰度。
• Flowise：开源可视化构建器（基于LangChain），拖拽节点定义AI工作流，支持自托管与向量数据库集成，适合开发者快速原型，但非技术用户易困惑。
• Dust.tt：企业级平台，支持代理/工作流构建，强调数据连接（如Slack、Notion）与监控，提供SDK与API，平衡易用性与灵活性。
• Cognosys：AutoGPT风格，非技术用户通过“定义目标”触发自主任务循环，支持Google生态集成，易用性高但封闭源码、定制化低。
• Bubble：通用无代码平台，通过插件集成OpenAI，支持多页App构建与AI辅助开发（如AI生成页面），适合嵌入式AI功能的全应用。
• Glide：表格转App工具，AI功能聚焦数据提取（如文本/图像转结构化数据），优化内部工具场景，缺乏复杂聊天机器人支持。

5. 权衡与局限

零代码LLM平台的核心矛盾的“易用性”与“控制力”的平衡，具体局限包括：

• 定制化不足：纯无代码平台（如GPTs、Cognosys）无法实现复杂逻辑，需低代码钩子（如Flowise）或代码导出（如Bolt.new）补充。
• 可扩展性与性能：多LLM调用（如10次循环）会导致 latency升高与API成本激增，通用平台（Bubble、Glide）依赖自有云基建，高并发场景需迁移至代码实现。
• 供应商锁定：专有平台（如GPTs、Cognosys）的逻辑与数据无法导出，开源平台（Flowise）可规避此风险；数据隐私方面，云LLM API可能泄露敏感信息。
• AI输出可靠性：LLM易生成错误内容（如Glide提取日期失败），且缺乏传统软件的测试框架，关键场景需人工 oversight。
• 提示工程需求：虽标注“无代码”，但用户需设计精准指令（如“作为税务顾问提取收据总额”），非技术用户存在学习曲线。
• 浅层学习：团队依赖零代码工具时，可能缺乏LLM/API/架构的深层理解，未来迁移至定制方案时面临能力缺口。

6. 与传统/低代码开发的对比

• vs传统编码：
  • 传统编码：灵活性最大化（可实现任意功能），但耗时（如Slack bot需数天）、需专业技能；
  • 零代码LLM：原型速度快（相同bot仅需数小时），但控制弱（无法微调嵌入逻辑）、缺乏版本管理/调试工具。
• vs低代码（无LLM）：
  • 低代码：依赖确定性可视化流图（如Mendix），复杂逻辑需编码；
  • 零代码LLM：用自然语言替代逻辑块，支持原低代码无法实现的场景，但输出具有概率性（相同输入可能不同结果），测试难度高。
• 共存模式：非技术用户（如营销团队）用零代码构建原型，工程师优化性能/可靠性并迁移至生产环境，实现“快速迭代+专业落地”。
• 适用场景划分：
  • 传统编码：性能关键、大规模、高定制化应用（如电商平台）；
  • 低代码：结构化、中等定制化应用（如企业表单系统）；
  • 零代码LLM：原型、内部工具、领域特定自动化（如社交媒体助手）。

7. 未来方向

• 多模态输入输出：突破文本局限，支持语音指令、图像分析、视频生成（如Dust.tt扩展可视化，Glide增强OCR），实现“语音+视觉+文本”全流程无代码构建。
• 端侧与私有LLM：依托小模型（如Llama 2变体），支持本地部署（解决隐私问题）与离线使用；提供无代码微调界面（如MonsterAPI、H2O.ai），适配领域数据。
• 优化编排与工具：
  • 多代理协作：用户拖拽不同角色代理（研究、写作、审核）并定义交互规则；
  • 调试工具：可视化推理流、AI自动纠错（如Flowise增强节点监控）；
  • 安全功能：权限管控、自动重试逻辑，对标传统软件工程标准（CI/CD、监控）。
• 协作与社区共享：建立模板库（如OpenAI GPT商店、Dust.tt模板市场），用户可复用prompt策略、模型配置与集成方案，降低入门门槛。
• 与传统IDE融合：实现双向编辑——VS Code等IDE添加LLM流图可视化插件，零代码工具暴露源码编辑界面，支持混合团队协作（非技术者用可视化，开发者改代码）。
• LLM自身改进赋能：减少幻觉、延长上下文窗口（降低知识 chunking需求）、增强推理能力，让零代码平台更可靠，减少提示工程需求。

---

4. 关键问题与答案

问题1：零代码LLM平台的两大核心类别是什么？它们在“界面类型”“输出类型”“LLM后端”三个关键维度上存在哪些本质差异？

答案：零代码LLM平台分为专用LLM平台与通用无代码平台两大类，核心差异如下：

• 界面类型：专用平台以“对话式（如OpenAI GPTs的聊天配置）、可视化流图（如Flowise的节点拖拽）”为主，门槛低且聚焦AI逻辑；通用平台以“传统GUI构建器、模板”为主（如Bubble的组件拖拽、Glide的表格模板），需适配全应用开发流程。
• 输出类型：专用平台输出以“AI代理、工作流”为核心（如Dust.tt的后端自动化流程、Cognosys的自主任务执行）；通用平台输出是“全功能应用（web/移动）+嵌入式AI”（如Bubble的多页App带聊天机器人组件、Glide的表格转App带OCR功能）。
• LLM后端：专用平台支持“模型无关或多模型”（如Flowise兼容LangChain、100+集成，Dust.tt可切换OpenAI/Anthropic），灵活性高；通用平台多“以OpenAI为主或自动选择模型”（如Glide默认OpenAI、Bubble需通过插件配置模型），LLM适配性较弱。

问题2：零代码LLM平台在实际落地中，最影响其“从原型到生产”迁移的核心挑战是什么？这些挑战分别对哪些应用场景构成限制？

答案：最核心的挑战及场景限制如下：

1. 可扩展性与性能瓶颈：多LLM调用（如10次循环/用户）会导致 latency升高与API成本激增，通用平台（如Bubble）的云基建虽支持自动扩缩容，但无法优化LLM本身的调用效率。此挑战限制高并发场景（如面向百万用户的AI客服）与高频交互场景（如实时数据分析工具）。
2. 供应商锁定与数据隐私：专有平台（如OpenAI GPTs、Cognosys）的逻辑与数据无法导出，迁移时需重构；云LLM API处理敏感数据（如企业财务文档）存在泄露风险。此挑战限制企业级核心应用（如内部财务自动化系统）与数据敏感场景（如医疗AI助手）。
3. AI输出可靠性与测试缺失：LLM易生成错误内容（如Glide提取日期偏差），且零代码平台缺乏传统软件的单元测试、回归测试工具，无法保障输出一致性。此挑战限制关键决策场景（如AI驱动的供应链调度）与高精度需求场景（如法律文档生成）。

问题3：未来零代码LLM平台的发展趋势中，“端侧LLM”与“多代理编排”两大方向，为何能有效突破当前平台的核心局限？具体解决路径是什么？

答案：两大方向突破局限的逻辑与路径如下：

1. 端侧LLM：
   • 突破的局限：当前平台依赖云LLM API导致的“数据隐私风险”“离线不可用”“调用成本高”问题。
   • 解决路径：依托小尺寸高效模型（如Llama 2变体、Mistral），零代码平台提供“一键本地部署”功能——用户无需配置环境，即可将LLM部署在终端设备（如手机、企业私有云）；同时集成无代码微调界面（如H2O.ai的可视化调参），让用户用领域数据（如企业文档）优化模型，兼顾隐私与效果。
2. 多代理编排：
   • 突破的局限：当前平台“单代理能力有限”“复杂任务难以拆分”的问题（如单代理无法同时完成“市场调研→报告写作→合规审核”）。
   • 解决路径：平台提供“代理市场”与“可视化交互编辑器”——用户可选择预构建的专业代理（如调研代理、写作代理、审核代理），通过拖拽节点定义代理间的协作规则（如“调研代理输出→写作代理输入→审核代理反馈→写作代理修改”）；同时配套“推理流可视化工具”与“错误回溯功能”，让用户清晰掌控任务进度，提升复杂任务的完成质量与可控性。

思维导图

创新点：这篇论文的独特价值在哪？

1. 首个系统性分类框架：之前没人清晰区分“零代码LLM平台”的类型，论文首次用“界面风格、LLM后端、输出类型、定制化程度”四大维度，把混乱的工具分成“专用LLM平台”和“通用无代码平台”，让用户能快速对号入座。
2. 7大平台深度实测：不是只列功能清单，而是实际体验OpenAI GPTs、Flowise、Bubble等7个主流工具，甚至测试“多LLM调用的 latency”“API集成数量”等细节，对比结果更真实可用。
3. 权衡关系分析：没有一味吹零代码的好，而是客观指出“易用性”和“控制力”的矛盾——比如GPTs简单但没法自定义复杂逻辑，Flowise灵活但需要懂点节点配置，帮读者避免“踩坑”。

研究方法和思路：论文是怎么研究的？

论文的研究思路很清晰，分4步拆解复杂问题，普通人也能看懂：

第一步：确定研究范围

先明确“零代码LLM平台”的定义——必须满足两个条件：1. 不用写代码（或极少代码）；2. 核心功能依赖LLM驱动。然后筛选出两类平台：

• 专用LLM平台：专门做AI相关功能（如聊天机器人、工作流），比如OpenAI GPTs、Flowise；
• 通用无代码平台：能做全功能App（如web/mobile应用），但支持LLM集成，比如Bubble、Glide。

第二步：提炼分类维度

从用户实际使用场景出发，总结出4个关键维度，用来区分不同平台：

1. 界面风格：是用聊天对话（如GPTs），还是拖拽节点（如Flowise），或是传统的组件搭建（如Bubble）？
2. LLM后端：支持固定模型（如GPT-only），还是多模型（如Flowise兼容Llama、GPT）？
3. 输出类型：能做出聊天机器人，还是全功能App，或是自动化工作流？
4. 定制化程度：能不能加自定义插件，能不能导出代码？

第三步：平台实测与数据收集

对7个主流平台进行“上手测试”，重点记录3类信息：

• 核心功能：能不能做AI代理（自主任务拆分）、能不能连外部工具（如Slack、Notion）、有没有记忆功能（比如记住之前的对话）；
• 易用性：非技术人员多久能做出第一个应用，有没有学习曲线；
• 性能与成本：多轮LLM调用要等多久，API费用高不高。

第四步：对比分析与结论

把收集到的数据整理成表格（比如对比7大平台的“LLM灵活性”“API集成数量”），然后总结：

• 哪类平台适合谁：专用平台适合做AI工具，通用平台适合做嵌入式AI的App；
• 现存问题：比如供应商锁定（GPTs的数据没法导出）、AI输出不可靠（偶尔会出错）；
• 未来方向：多模态（语音/图像驱动）、端侧LLM（本地部署更安全）。

主要成果和贡献：这篇论文有什么用？

论文的核心成果能用“一张表+两大贡献”说清，不管是选工具还是做研究都能直接用。

核心成果：7大平台关键能力对比表

平台	适合人群	核心优势	核心局限	适用场景
OpenAI GPTs	非技术人员	5分钟上手，操作最简单	没法自定义复杂逻辑	简单聊天机器人（如旅行咨询）
Flowise	开发者/技术人员	开源灵活，支持多模型	非技术人员易困惑	复杂AI工作流（如数据处理）
Dust.tt	企业用户	数据集成强，支持监控	收费较高	企业级AI工具（如客户分析）
Cognosys	纯小白用户	自主任务循环，不用管细节	封闭源码，没法定制	自动执行任务（如查资料）
Bubble	全场景用户	能做全功能App+AI集成	LLM功能需手动配置	带AI的App（如电商客服）
Glide	办公用户	表格转App快，AI提数方便	没法做复杂聊天机器人	内部工具（如发票管理）
Bolt.new	半技术用户	能导出代码，支持二次开发	调试依赖指令清晰度	原型开发（如React App）

两大核心贡献

1. 理论贡献：给研究搭框架

之前零代码LLM平台的研究很零散，论文首次提出“四大分类维度”和“两类平台对比框架”，后续研究者可以基于这个框架深入分析，不用再从零开始。

2. 实践贡献：帮用户避坑

• 非技术人员：看表格就知道“想做简单机器人用GPTs，想做内部工具用Glide”；
• 企业用户：了解到“担心数据隐私可选开源的Flowise，需要监控选Dust.tt”；
• 开发者：知道“原型用Bolt.new导出代码，生产环境再优化”能提高效率。

开源资源

论文中提到的Flowise是开源平台，代码地址：https://github.com/FlowiseAI/Flowise（可直接部署使用，支持自定义LLM模型和工作流）。

总结

这篇论文是零代码LLM开发领域的“入门指南”，它没有堆砌复杂术语，而是用“分类框架+实测数据+对比表格”把混乱的工具市场理得清清楚楚。一方面，它让非技术人员能快速找到适合自己的工具，不用再在众多平台中“瞎试”；另一方面，它为研究者提供了清晰的分析框架，推动这个领域的进一步发展。

当然，论文也指出了零代码LLM平台的短板——供应商锁定、AI输出不可靠、性能瓶颈等，这些问题还需要行业共同解决。但不可否认，零代码LLM平台已经让“人人都能做AI应用”的目标更近了一步，未来随着多模态、端侧LLM等技术的落地，它的应用场景会更广泛。