市面上大多教程，只讲了“是什么”；而我的专栏，致力于让大家明白“为什么”和“怎么改”。关注我（@跟着小勺子学AI自动化），一起揭开海外工作流的神秘面纱，构建你本土化、可落地的自动化解决方案。

注：该专栏讲解均通过我搭建的N8N自动化skills生成，全文由大模型拆解，可能存在疏漏和错误之处，敬请谅解

一、架构概览与技术评估

本工作流是一个 AI 驱动的多意图客户支持聊天机器人，基于 n8n LangChain 节点构建。系统通过 Webhook 接收用户消息，经 LangChain Agent 进行意图识别后，自动路由到对应的处理模块。无论是查询订单状态、寻求产品推荐，还是提交售后工单，均可在一个工作流中完成闭环。

该工作流的技术架构可划分为四个层级：触发层负责接收外部请求，分类层进行意图判断与路由，处理层分别执行订单查询、产品推荐和工单处理逻辑，集成层则完成数据库操作和邮件通知功能。

技术难度评估：

• 难度等级：⭐⭐⭐☆☆（3 星）

• 配置耗时：约 45 至 60 分钟

• 适用人群：具备 n8n 中级使用经验的用户

核心价值主张： 该工作流彻底解决了人工客服无法 7×24 小时即时响应、无法同时处理多类业务请求的行业级痛点，实现了客服自动化和智能化。

---

二、数据流转全景图

输入格式：{ "session_id": "xxx", "message": "用户问题" } 

    ↓ 

意图分类输出：{ "intent": "order_status", "product": "keyboard" } 

    ↓ 

分支路由 → 订单/推荐/工单/通用 

    ↓ 

最终输出：JSON响应 + 数据库操作 + 邮件通知（工单场景） 

---

三、核心节点技术详解

1. Webhook（触发器）

技术实现： 作为 RESTful 入口，接收 POST 请求。请求体需包含 session_id 和 message 两个字段。session_id 用于会话隔离，message 则是用户的实际查询内容。

关键配置参数：

参数	值	说明
httpMethod	POST	仅支持 POST 方法
responseMode	responseNode	响应模式

配置建议： 测试时需确保使用 POST 方法而非 GET，否则会触发 404 错误。

---

2. AI Agent（意图分类）

技术实现： 使用 GPT-4o-mini 作为底层 LLM，通过精心设计的 System Prompt 定义分类规则。Agent 接收用户消息后，输出严格 JSON 格式的分类结果。

分类逻辑：

{ "intent": "order_status", "product": "keyboard" } 

{ "intent": "support_ticket", "product": "mouse" } 

{ "intent": "product_recommendation", "product": "gaming chair" } 

{ "intent": "general", "product": "感谢语/闲聊" } 

关键配置参数：

参数	值	说明
model	gpt-4o-mini	经济高效的模型选择
systemMessage	分类规则定义	包含 4 种意图和示例

配置建议： System Prompt 中的示例质量直接影响分类准确率，建议覆盖尽可能多的边缘场景。

---

3. Code（JSON 解析）

技术实现： 将 AI Agent 输出的字符串解析为 JSON 对象，提取 intent 和 product 字段供后续 Switch 节点使用。

代码逻辑：

response = JSON.parse($input.first().json.output) 

return {"category": response} 

配置建议： 务必处理 JSON 解析异常，避免因 AI 输出格式偏差导致工作流中断。

---

4. Switch（路由分发）

技术实现： 基于 category.intent 字段进行四路分支判断，将请求路由到不同的处理分支。

分支映射：

分支序号	条件	目标节点
0	intent = order_status	Order Queries
1	intent = product_recommendation	Recommendations
2	intent = support_ticket	AI Agent1
3	intent = general	直接响应

配置建议： 字符串匹配大小写敏感，建议在分类阶段统一转换为小写。

---

5. Order Queries（订单查询 Agent）

技术实现： 专门处理订单相关查询。Agent 首先提取 order_id 或 product 信息，然后调用 getOrderStatus 工具查询 Supabase 数据库，最后将查询结果转换为自然语言回复用户。

工具集成：

工具名称	数据库表	查询字段
getOrderStatus	orders	order_id

典型流程：

用户："我的键盘什么时候到？" 

→ 提取：product = "keyboard" 

→ 调用：getOrderStatus(product = "keyboard") 

→ 返回："您的订单已于今天上午发货，预计明天送达。" 

配置建议： 若用户未提供 order_id，应引导其提供订单编号或购买时使用的邮箱。

---

6. Recommendations（产品推荐 Agent）

技术实现： 判断用户需求类型，智能选择推荐策略。若用户提及具体产品名，调用 getProductRecommendations；若提及品类概念，调用 getCategoryRecommendations。

工具集成：

工具名称	用途	数据库字段
getProductRecommendations	按产品名查询	name
getCategoryRecommendations	按品类查询	category

典型流程：

用户："推荐一款无线鼠标" 

→ 提取：product = "无线鼠标" 

→ 调用：getProductRecommendations(product = "无线鼠标") 

→ 返回：推荐列表 + 产品特点介绍 

---

7. AI Agent1（工单处理 Agent）

技术实现： 支持两种业务场景——创建新工单和查询工单状态。创建工单时需要完整收集 user_email、product、issue 信息，生成唯一 ticket_id 后写入数据库并发送通知邮件。

工具集成：

工具名称	功能	数据库表
Code Tool	生成 ticket_id	无
createSupportTicket	创建工单	support_tickets
getTicketStatus	查询工单	support_tickets
Send	发送邮件	Gmail

工单创建流程：

用户："我的显示器有问题" 

→ 询问邮箱 → "请提供您的邮箱地址" 

→ 用户："test@example.com" 

→ 收集完成 → 调用Code Tool生成TKT-20250711-8471 

→ 调用createSupportTicket写入数据库 

→ 调用Send发送邮件通知 

→ 返回："工单已创建，ID: TKT-20250711-8471" 

关键约束： Agent 输出不得包含**、/等特殊字符，以免导致 JSON 解析失败。

---

8. Simple Memory（记忆管理）

节点 ：

• 主分支

• 订单分支）

• 工单分支

技术实现： 使用 Buffer Window Memory 机制，保留最近 7 轮对话上下文。sessionKey 动态绑定到用户 session_id，实现多用户会话隔离。

配置参数：

参数	值	说明
sessionIdType	customKey	自定义 session 标识
sessionKey	$json.body.session_id	动态从请求获取
contextWindowLength	7	保留 7 轮对话

配置建议： 生产环境务必使用动态 sessionKey，避免不同用户的对话历史混淆。

---

四、国内外服务替代方案

国外原服务	工作流位置	推荐国内替代方案	技术差异说明
OpenAI (GPT-4o-mini)	分类 Agent 及所有处理 Agent	智谱 AI (GLM-4-Flash)、DeepSeek (DeepSeek-Chat)	API 协议高度兼容，需调整 endpoint 和认证方式
Supabase	数据库操作节点（getOrderStatus、createSupportTicket 等）	飞书多维表格 API、阿里云 RDS MySQL、腾讯云 DB	SQL 语法完全兼容，飞书需转换 API 调用方式
Gmail	邮件发送节点（Send）	阿里云邮件推送、SendGrid 国内版、腾讯企业邮	需配置 SMTP 参数，建议使用阿里云邮件推送

---

五、部署与配置指南

5.1 前置依赖清单

1. OpenAI API Key：用于所有 LangChain Agent 的 LLM 调用

2. Supabase 项目：创建 orders、support_tickets、products 三张表

3. Gmail 账号：开启 IMAP/SMTP 用于发送工单通知邮件

4. n8n 实例：Cloud 版或自托管版（推荐自托管以便自定义配置）

5.2 数据库表结构设计

orders 表（订单）：

字段名	类型	说明
order_id	text	订单唯一标识
product	text	产品名称
status	text	订单状态
eta	timestamp	预计送达时间

support_tickets 表（工单）：

字段名	类型	说明
ticket_id	text	工单唯一标识
user_email	text	用户邮箱
product	text	产品名称
issue	text	问题描述
status	text	工单状态

products 表（产品）：

字段名	类型	说明
name	text	产品名称
category	text	产品分类
description	text	产品描述

5.3 配置要点与避坑指南

节点类型	关键参数	避坑提示
Webhook	responseMode 设为 responseNode	确保测试时使用 POST 方法
Switch	精确匹配 intent 值	大小写敏感，建议统一小写处理
Supabase	filters.conditions 正确映射字段	提前确认表名和字段名存在
Simple Memory	sessionKey 必须动态绑定	避免使用静态值导致会话混淆
Code	处理 JSON.parse 异常	AI 输出格式可能不标准

5.4 调试策略

分段测试法：

1. 单独测试 Webhook 触发，验证输入数据格式

2. 测试 AI Agent 分类，验证输出 JSON 结构

3. 分支测试：向 Switch 的 4 个输出口分别发送测试数据

4. 工具测试：单独调用 Supabase 工具验证数据库连接

日志查看： 通过 n8n 执行日志中的 AI Tool 调用记录，可以清晰看到每个工具的输入输出，便于定位问题。

---

六、扩展建议与最佳实践

6.1 行业定制化建议

应用场景	修改建议
电商零售	增加“退货退款”intent，集成退款 API 和退货流程
SaaS 产品	增加“功能咨询”intent，连接文档知识库或 Notion
本地化	替换为中文 LLM（如智谱 GLM），支持多语言回复
会员系统	集成会员等级查询，提供个性化服务

6.2 生产环境最佳实践

稳定性保障：

• 增加 Error Trigger 节点，捕获任意节点的异常错误

• 为 Supabase 操作添加 IF_ERROR 条件分支，防止单点故障导致工作流中断

• 使用加密变量存储 API Key 和数据库凭证

性能优化：

• 意图分类 Agent 可降级使用更小模型（如 GPT-3.5-Turbo）

• 简单查询直接走数据库，避免不必要的 LLM 调用

• 设置请求超时，防止外部 API 响应过慢

监控告警：

• 配置 Slack/飞书 Webhook，监控工作流执行失败

• 定期统计各 intent 的分布比例，优化分类准确率

---

七、总结

本工作流展示了如何利用 n8n 构建一个完整的 AI 客服系统。通过 LangChain Agent 实现智能意图识别，结合 Supabase 实现数据持久化，配合 Gmail 完成邮件通知，形成了完整的客服闭环。该架构具有良好的扩展性，可根据实际业务需求灵活调整分支逻辑和集成服务。

---

如果你对该工作流感兴趣，关注本公众号后私信我关键词【工作流解读】获取本系列所有解读的json源文件（持续更新）～