n8n + Chatwoot + Dify — 业务逻辑驱动的客服中枢

这套方案在解决什么问题#

「Chatwoot + Dify」对纯问答类客服已经够用，但一旦涉及业务操作就会暴露问题：

• AI 接到「查我的订单」要直接读 ERP——逻辑分散
• AI 决定退款金额需要先调订单接口拿数据
• 高优先级工单需要通知 Slack + 飞书
• 客户满意度数据要每月汇总到 Notion
• 知识库需要从 GitHub docs 自动同步

让 Dify Workflow 直接调用所有外部 API 是反模式——每一处都需要硬编码 URL、写认证、处理错误。一旦 ERP 改接口，全部 Workflow 都要改。

正确做法：Dify 只调 n8n，n8n 负责所有「业务侧逻辑」。

架构#

关键点：所有「AI ↔ 业务系统」「客服 ↔ 业务系统」「外部触发 ↔ 内部数据」的连接都过 n8n。

何时选这套方案#

情况	适合？
AI 客服要读 / 写订单、退款、CRM	✓ 强烈推荐
业务系统多、接口杂、经常变动	✓
想用 GitHub Push 自动同步知识库	✓
多团队需要数据互通（销售、客服、运营）	✓
单一系统、客服只做问答	✗ 用 Chatwoot + Dify 就够

组件分工#

组件	职责	不做什么
Chatwoot	多渠道入口、人工坐席	不直接调业务系统
Dify	Prompt、知识库、LLM 调度	不直接调业务 API（只调 n8n）
n8n	业务逻辑、API 编排、定时任务	不直接面对客户
PostgreSQL	三者共用元数据	不存业务数据
Redis	队列、缓存

10 个真实自动化（典型 Workflow）#

编号	触发	工作流
W1	Dify 工具调用	查订单 → ERP → 返回结构化数据
W2	Dify 工具调用	退款判定（规则引擎 + 金额校核）
W3	Chatwoot Webhook	新工单 → 写入 Notion + 通知销售
W4	Chatwoot Webhook	紧急关键词 → 转人工 + 飞书告警
W5	Cron 每日	拉 Chatwoot 数据 → 计算 KPI → 推送报告
W6	GitHub Push	docs 变更 → 拉取 → 调 Dify API 重建知识库
W7	Cron 每周	抽样 50 条工单 → 调 LLM 评分 → 写入 Notion
W8	Chatwoot Webhook	工单解决 → 写客户 LTV 标签 → CRM 同步
W9	Dify 工具调用	多渠道通知（邮件 + Slack + SMS）统一接口
W10	Cron 每月	数据归档 → S3 + 触发审计

部署步骤#

1. 起 n8n（前置）#

# 推荐 PostgreSQL 持久化，不要用默认 SQLite
docker run -d --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e DB_TYPE=postgresdb \
  -e DB_POSTGRESDB_HOST=postgres \
  -e DB_POSTGRESDB_DATABASE=n8n \
  -e DB_POSTGRESDB_USER=n8n \
  -e DB_POSTGRESDB_PASSWORD=changeme \
  -e N8N_HOST=n8n.example.com \
  -e WEBHOOK_URL=https://n8n.example.com/ \
  -e N8N_BASIC_AUTH_ACTIVE=true \
  -e N8N_BASIC_AUTH_USER=admin \
  -e N8N_BASIC_AUTH_PASSWORD=changeme \
  n8nio/n8n

打开 https://n8n.example.com，创建账号。

2. 创建第一个 Workflow：订单查询#

n8n 拖拽节点：

Webhook (POST /lookup-order)
  → HTTP Request (ERP API)
  → 转换数据格式
  → Respond to Webhook (JSON)

发布后获取 webhook URL：https://n8n.example.com/webhook/lookup-order

3. 在 Dify 加自定义工具#

Dify → 工具 → 创建自定义工具：

openapi: 3.0.0
info:
  title: Business Tools
  version: 1.0
servers:
  - url: https://n8n.example.com/webhook
paths:
  /lookup-order:
    post:
      operationId: lookup_order
      parameters:
        - name: order_id
          in: body
          required: true
          schema:
            type: string
      responses:
        '200':
          description: Order info
  /initiate-refund:
    post:
      operationId: initiate_refund
      parameters: [...]

4. Dify Agent / Workflow 调用#

在 Dify Agent 里勾上「lookup_order」工具，AI 自动在合适时调用。

测试：

用户：「我的订单 ORD-12345 到哪了？」 AI：（调用 lookup_order → 拿到 “已发货 - 顺丰 SF1234567890”） AI：「您的订单已发货，运单号 SF1234567890，预计明天送达。」

5. Chatwoot → n8n 双向#

Chatwoot 推到 n8n：在 Chatwoot Settings → Integrations → Webhooks，URL 填 https://n8n.example.com/webhook/chatwoot-event

n8n 写回 Chatwoot：n8n 节点用 Chatwoot 的 API token 调用。

成本估算#

资源	月成本
8C/16G VPS（n8n + Dify）	$60
4C/8G VPS（Chatwoot）	$30
托管 Postgres	$25
LLM tokens（5,000 月会话）	$30-100
合计	$145-215 / 月

收益数据#

某 SaaS 团队上线 8 周：

指标	上线前（仅 Dify）	上线后（加 n8n）
AI 能处理的业务问题占比	35%	78%
业务系统 API 调用错误率	12%	2.5%
知识库延迟（docs 改完到 AI 生效）	1-7 天	< 5 分钟
工程团队维护成本	高（每改 ERP 都要改 Dify）	低（只改 n8n）
月度新增业务 Workflow	1-2 个	5-8 个

关键设计原则#

1. Dify 永远不直接调业务 API#

所有业务调用必须通过 n8n。这样一旦 ERP 接口变了，只改 n8n 一处。

2. n8n 的 Webhook 必须幂等#

同一个事件可能触发多次（网络重试），用 request_id 做去重。

3. 关键 Workflow 加错误告警#

每个 Workflow 末尾加「失败通知」分支：

Main flow → catch error → 飞书 / PagerDuty 通知 → 记录到 Notion

4. 业务 API 加限流#

促销日访问量暴涨，n8n 节点配「速率限制」防止打爆 ERP。

5. n8n 工作流要版本控制#

n8n 支持把 Workflow 导出为 JSON，提交到 Git 仓库——和代码一样 Review。

常见坑#

1. n8n SQLite 在大量 Webhook 下崩：生产必须用 PostgreSQL
2. 同步与异步混乱：业务 API 慢时 Dify 工具调用会超时，要把慢操作改成「触发后异步」
3. n8n 凭证管理：所有 API Token、密码集中在 n8n 凭证库，加密存储 + 定期轮换
4. 多环境：测试 / 生产 n8n 工作流要分开两个实例，不要共用
5. License 注意：n8n 是 Sustainable Use License，自部署免费但禁商业转售

演进路径#

阶段	加什么
1. 基础	Chatwoot + Dify + n8n
2. 监控	Grafana + Prometheus 抓 n8n metrics
3. 高可用	n8n Worker 模式（main + worker 拆分）
4. 多团队	n8n 加用户权限 + Workspaces
5. CI/CD	n8n workflows 导出到 Git + 自动部署

相关阅读#

• 用 n8n 给 AI 客服当中央编排：10 个真实自动化
• Chatwoot + Dify 基础组合
• Dify Workflow 实战手册