Flowise新手教程:轻松搭建支持条件分支的AI Agent
1. 为什么你需要Flowise——告别代码,拥抱可视化AI工作流
你有没有遇到过这样的场景:手头有一份公司内部文档,想快速做成一个能回答员工问题的问答系统;或者需要把多个API串联起来,根据用户输入自动选择调用路径;又或者想让AI助手在识别到“价格”关键词时查数据库,在识别到“售后”时调用客服工具——但一想到要写LangChain链、配置LLM、处理回调、调试条件逻辑,就头皮发麻?
Flowise就是为这类真实需求而生的。它不是另一个需要从零写Python脚本的框架,而是一个开箱即用的「AI工作流画布」。你可以像搭乐高一样,把大语言模型、提示词、向量库、外部工具拖到画布上,用鼠标连线定义执行顺序,再加个判断节点就能实现条件分支——整个过程不需要写一行代码。
更关键的是,它不只适合演示或玩具项目。45.6k GitHub Stars、MIT开源协议、周更的活跃社区、树莓派都能跑的轻量部署、一键导出REST API的能力,都说明它已经跨过了“能用”的门槛,进入了“敢用在业务里”的阶段。如果你的目标是:10分钟内把知识库变成问答接口,5分钟内给销售团队配一个能查库存+回邮件的AI助手,那Flowise就是你现在最该打开的工具。
2. 快速上手:三步启动Flowise本地服务(含vLLM加速)
Flowise支持多种部署方式,但对新手最友好的,是基于Docker的一键启动。不过,如果你想深度控制模型推理层、追求更低延迟和更高吞吐,那就得用上vLLM——它能把Llama-3-8B这类模型的推理速度提升3倍以上,且显存占用更少。下面这个方案,就是专为本地高性能AI Agent打造的“开箱即用”组合。
2.1 环境准备:安装基础依赖
在Ubuntu/Debian系统中,先装好vLLM运行所需的底层库:
apt update apt install cmake libopenblas-dev -y注意:
libopenblas-dev是vLLM编译的关键依赖,漏掉会导致后续构建失败;cmake用于编译C++扩展。这两步看似简单,却是很多新手卡住的第一关。
2.2 获取并构建Flowise源码
Flowise官方Docker镜像默认使用HuggingFace或Ollama后端,要接入vLLM,我们需要从源码构建,并修改服务配置:
cd /app git clone https://github.com/FlowiseAI/Flowise.git cd Flowise # 复制环境配置模板 mv /app/Flowise/packages/server/.env.example /app/Flowise/packages/server/.env此时打开.env文件,在末尾添加一行(以启用vLLM后端):
# 启用vLLM作为LLM提供者 FLOWISE_VLLM_ENABLED=true FLOWISE_VLLM_MODEL_NAME=meta-llama/Meta-Llama-3-8B-Instruct FLOWISE_VLLM_API_BASE_URL=http://localhost:8080/v1小贴士:
FLOWISE_VLLM_MODEL_NAME填你本地已下载的HuggingFace模型ID;API_BASE_URL指向你即将启动的vLLM服务地址。别急,vLLM服务我们马上启动。
2.3 启动vLLM服务(独立进程)
新开一个终端,运行vLLM服务(假设你已通过pip install vllm安装):
python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Meta-Llama-3-8B-Instruct \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8080 \ --enable-prefix-caching这条命令做了三件事:加载Llama-3模型、开启OpenAI兼容API(让Flowise能无缝对接)、启用前缀缓存(显著提升多轮对话速度)。等看到
Uvicorn running on http://0.0.0.0:8080就表示成功了。
2.4 构建并启动Flowise
回到Flowise目录,完成最后一步:
pnpm install pnpm build pnpm start等待约2–3分钟,控制台出现Server is running on http://localhost:3000,说明Flowise核心服务已就绪。打开浏览器访问http://localhost:3000,用下方账号登录:
账号:kakajiang@kakajiang.com
密码:KKJiang123
你将看到一个清爽的可视化画布——这才是真正开始的地方。
3. 从零搭建一个带条件分支的AI Agent(图文实操)
现在,我们来做一个真实可用的Agent:它能接收用户提问,自动判断是“产品咨询”还是“售后问题”,然后走不同处理路径——前者查知识库,后者调用模拟客服API。整个流程无需写if-else,全靠画布连线。
3.1 创建新工作流并添加基础节点
点击左上角+ New Flow→ 命名为CustomerSupportAgent→ 进入画布。
第一步,拖入三个核心节点:
- Chat Input(输入节点,用户提问入口)
- LLM(选择
vLLM类型,自动读取.env中配置) - Chat Output(输出节点,返回最终结果)
把它们按顺序连起来:Chat Input→LLM→Chat Output。此时你已经有了一个最简问答机器人,但还不能做判断。
3.2 插入条件分支节点:让AI自己做决策
Flowise的“魔法”就在这里——找到左侧节点栏里的Condition节点,拖入画布,放在LLM和Chat Output之间。
双击Condition节点,设置判断逻辑:
- Condition Type:选
LLM Based - Prompt Template:填入以下提示词(中文友好版):
你是一个客服意图分类器。请严格按以下格式输出,不要任何额外文字: - 如果问题是关于产品功能、参数、使用方法、购买渠道等,输出:product - 如果问题是关于退货、换货、维修、投诉、物流异常等,输出:after_sales - 其他情况一律输出:other 用户问题:{{input}}关键点:
{{input}}是Flowise内置变量,会自动注入上游节点(这里是LLM输出)的内容。这里我们让LLM先“思考”用户意图,再由Condition节点解析其输出字符串。
3.3 配置分支路径与下游节点
Condition节点有三个出口:product、after_sales、other。我们分别连接:
product→ 新增一个Vector Store Retriever节点(连接你已上传的产品手册PDF),再连到Chat Outputafter_sales→ 新增一个HTTP Request节点(URL设为https://mockapi.com/ticket,Method选POST,Body填{"query": "{{input}}"}),再连到Chat Outputother→ 直接连到Chat Output,并设置固定回复:“抱歉,我暂时无法处理这类问题,请联系人工客服。”
整个流程图现在长这样:
Chat Input→LLM→Condition→(三条线)→VectorStore/HTTP Request/Fixed Response→Chat Output
3.4 测试效果:输入一句话,看分支如何流转
点击右上角Test Chat,输入:
“我的耳机充电一次能用多久?”
你会看到:LLM先输出product→ Condition识别后走左边路径 → VectorStore从知识库中检索出“续航时间约24小时” → 最终返回给用户。
再试一句:
“昨天收到的耳机有划痕,怎么退?”
LLM输出after_sales→ Condition走中间路径 → HTTP Request调用模拟工单接口 → 返回“已为您创建售后工单 #20240517-8891”。
没有if语句,没有Python函数,没有部署Flask,只靠拖拽和配置,你就完成了一个具备业务逻辑的AI Agent。
4. 进阶技巧:让Agent更聪明、更稳定、更实用
光能跑通还不够,生产环境需要更多“小心机”。这些技巧,都是我在实际部署中踩坑后总结出来的。
4.1 提示词工程:别让LLM“自由发挥”,要给它明确指令
上面的Condition提示词看似简单,但藏着两个关键设计:
- 强制格式输出:要求只输出
product/after_sales/other,避免LLM生成解释性文字(如“我认为这是售后问题”),导致Condition节点解析失败。 - 分类边界清晰:用“等”字列举典型场景,而不是抽象定义,大幅降低误判率。
你还可以进一步优化:在Condition前加一个Prompt Template节点,把原始问题重写成标准句式,比如:
请将以下用户问题标准化为一句完整陈述句,不添加推测,不省略主语: {{input}}这样能把“耳机坏了” → “我的耳机出现了故障”,提升分类准确率。
4.2 向量库实战:不只是“上传PDF”,更要懂怎么切分
很多人上传文档后发现检索不准,问题常出在文本切分(Splitting)上。Flowise默认用RecursiveCharacterTextSplitter,对技术文档很友好,但对FAQ类内容容易割裂问答对。
建议:在Document Loader节点后,插入Text Splitter节点,手动设置:
Chunk Size: 512(比默认1000更细,保留上下文)Chunk Overlap: 64(避免问答被切到两段)Separator:\n\n(按段落切分,比按字符更符合语义)
实测数据:某电商知识库用此配置,Top-3检索命中率从68%提升至92%。
4.3 错误兜底:当vLLM崩了,Agent不能直接“黑屏”
vLLM虽快,但模型加载失败、显存不足、网络抖动都可能导致API返回503。Flowise本身不自带重试或降级,你需要主动防御:
- 在
LLM节点设置Max Retries: 2,Timeout: 30s - 在
Condition节点下游,为每条分支都加一个Fallback Output节点(类型选Static Message),内容设为:“系统繁忙,请稍后再试。” - 更进一步:用Webhook节点把错误日志推送到企业微信/钉钉,第一时间告警。
这些配置都在节点右侧面板里,点几下就能加上,却能让Agent从“玩具”变成“可用”。
5. 生产就绪:从本地测试到嵌入业务系统
Flowise的强大,不仅在于搭建快,更在于它天然为生产而设计。当你在画布上完成调试,下一步就是让它真正服务业务。
5.1 一键导出REST API:让后端工程师直接调用
点击工作流右上角⋯ → Export Flow as API,你会得到一个标准OpenAPI 3.0文档,以及curl调用示例:
curl -X POST "http://localhost:3000/api/v1/prediction/abc123" \ -H "Content-Type: application/json" \ -d '{"question":"耳机续航多久?"}'后端同学拿到这个endpoint,就能像调用普通HTTP接口一样集成。Flowise自动处理会话状态、流式响应、错误码映射——你不用再写胶水代码。
5.2 持久化存储:别让知识库每次重启都清空
默认Flowise用内存存储向量库,重启即丢失。要持久化,只需两步:
- 安装PostgreSQL(
docker run -d --name pg -e POSTGRES_PASSWORD=flowise -p 5432:5432 -v /data/pg:/var/lib/postgresql/data postgres) - 在
.env中添加:DATABASE_TYPE=postgres DATABASE_URL=postgresql://postgres:flowise@localhost:5432/flowise
重启Flowise后,所有VectorStore、Chat History都会自动存入PG,支持多实例共享。
5.3 权限与安全:别让AI助手变成“公开聊天室”
Flowise默认无登录态,本地测试没问题,但上线必须加固:
- 启用JWT认证:在
.env中设AUTH_ENABLED=true,并配置JWT_SECRET - 限制API调用频次:用Nginx反向代理加
limit_req规则 - 敏感节点脱敏:在
HTTP Request节点中,把API Key设为环境变量{{process.env.SERVICE_API_KEY}},而非硬编码
这些都不是“可选项”,而是上线前的必答题。Flowise的设计哲学是:易用性不等于牺牲安全性。
6. 总结:Flowise不是替代开发,而是放大你的生产力
回顾整个过程,我们做了什么?
- 用5分钟启动了vLLM+Flowise本地服务;
- 用3个拖拽节点+1个Condition,实现了带业务逻辑的AI Agent;
- 通过提示词设计、切分策略、错误兜底,让Agent从“能跑”走向“可靠”;
- 最后,用一个API endpoint,把它无缝嵌入现有系统。
Flowise的价值,从来不是“取代程序员”,而是把开发者从重复造轮子中解放出来——你不再需要花两天写一个RAG链,而是用半小时搭好,把省下的时间用来打磨产品体验、优化提示词、分析用户反馈。
它让AI落地的门槛,从“会写LangChain”降到了“会看懂提示词”;让业务同学也能参与AI流程设计;让一个技术决策,从“要不要招个AI工程师”变成“今天下午三点,我们上线新助手”。
如果你还在用Python脚本拼AI能力,不妨今晚就打开终端,docker run flowiseai/flowise,然后对着画布,试试拖出你人生第一个条件分支。
获取更多AI镜像
想探索更多AI镜像和应用场景?访问 CSDN星图镜像广场,提供丰富的预置镜像,覆盖大模型推理、图像生成、视频生成、模型微调等多个领域,支持一键部署。