客服工单每条都要人读一遍再猜分类、定优先级、找负责人。用 n8n 加一个强制JSON输出的模型步骤，把四步压到几秒，错派率还能往下压。

📜 目录

• 一、整条链路长什么样
• 二、先定 schema，再写提示词
• 三、n8n 节点逐步配置
• 四、错派率怎么压下来
• 五、三个必须设的护栏
• 六、能指望的效果
• 常见问题

AI工单Agent：用n8n自动化分类与分派

客服团队最不值钱又最耗时的动作，是分拣：读一遍工单，判断这属于账务还是功能缺陷，估一个紧急程度，再去找该谁接。一条工单两分钟，一天三百条就是十个小时。这活儿有明确规则、有历史数据可以对答案，正是模型能稳定吃下的部分。

这篇用 n8n 搭一条最小可用的分拣流，重点在"怎么让模型输出能直接进系统的结构化数据"，以及上线后怎么把错派率压下来。

一、整条链路长什么样

Webhook（接工单）→ 取正文与客户信息
   → 模型节点（输出固定 schema 的 JSON）
   → 校验（字段是否齐全、置信度是否够）
   → Switch（按类别+优先级分派）
   → 写回工单系统（更新类别/优先级/负责人）
   → 低置信度或校验失败 → 人工复核队列

关键设计：模型只负责"判断"，不负责"动作"。所有写操作都在后面的节点里做，这样才能在出错时回滚、能审计、能重放。

二、先定 schema，再写提示词

顺序反过来是新人最常见的错误：先写一大段提示词，再指望模型输出能用。正确做法是先定字段，让字段反推提示词。

confidence 这一项最容易被省掉，但它是整条流的安全阀。模型自己报的置信度不完全可靠，可它把"我拿不准"这句话显式化了，配合人工抽查，能把错派拦在系统外。

三、n8n 节点逐步配置

1. Webhook 触发器

用一个专属路径接工单系统的 webhook，方法选 POST，Respond 设成立即返回 200，别让工单系统等模型跑完——它通常有 5 秒超时，超时会重发，导致重复处理。

2. 组装输入

用 Set 节点把需要的字段挑出来：标题、正文、客户等级、历史工单数。不要把整条工单 JSON 塞给模型，里面有大量内部 ID 和空字段，纯属浪费 token，还会干扰判断。

3. 模型节点

HTTP Request 节点直连任意 OpenAI 兼容端点，或者用 AI Agent 节点。提示词里三件事必须写死：

• 输出格式：只输出 JSON，不要 markdown 代码块，不要解释
• 分类定义：每一类给一个正例和反例。比如"退款进度查询属于 billing，不是 howto"
• 兜底规则：信息不足以判断时，category 填 other，confidence 填 0.3 以下

4. 校验节点

用 Code 节点做三件事：JSON.parse 包在 try 里；检查枚举值是否在允许集合内；检查 confidence 是否低于 0.6。任一项不过就走人工队列。

5. 路由与写回

Switch 节点按 category 分四路，每路内部再按 priority 决定是立即通知还是进普通队列。写回用 HTTP Request 调工单系统的更新接口，PATCH 而非 PUT，只改三个字段，别整条覆盖。

四、错派率怎么压下来

上线第一周一定不准，能不能变准取决于你有没有闭环。

第一层：日志留全

每条工单把模型输出、校验结果、最终人工修正都落一张表。没有这张表，后面所有优化都是猜。

第二层：每周抽五十条对答案

统计错在哪：是分类边界模糊，还是优先级判断偏差。前者改提示词里的分类定义，后者改规则。

第三层：把修正喂回去

把典型的错判改成 few-shot 示例放进提示词。示例不用多，五到十条覆盖住高频边界情况就够，塞太多反而把上下文成本拉高、判断变慢。

第四层：能规则化的就别用模型

"包含'发票''退款'关键词的一律归 billing"这类硬规则，写在模型前面当快速通道。模型留给真正需要读懂语义的工单，又快又省。

五、三个必须设的护栏

第三点尤其重要。工单正文里天然带客户隐私，很多团队直接把原文丢给云端模型，事后才发现这是个合规漏洞。脱敏节点应该是标配，不是可选项。

六、能指望的效果

不要许诺"全自动"。现实的目标是：六到八成工单自动分派，剩下两三成转人工，整体首响时间从小时级压到分钟级，错派率比纯人工低。

这两件事决定上限：历史工单量够不够大（决定你能不能验证准确率），以及工单系统有没有可靠的更新接口（决定闭环能不能自动跑）。

常见问题

Q：没有专门的工单系统能玩吗？ A：能。任何有 API 的系统都行，Zendesk、Jira、Linear，甚至自己数据库加一个 webhook 触发。最简陋的做法是把结果写回一张 Google Sheet，先跑通再谈集成。

Q：模型把两条不同意图的工单分到同一类怎么办？ A：说明分类粒度太粗。先看这类工单的共同点和差异点，如果差异是业务上要区分对待的，就拆出子类；如果业务上根本不区分，就不用拆，别为了好看把分类做复杂。

Q：要不要用微调模型？ A：除非你已经积累了几千条带正确标注的历史工单，否则不值得。先用提示词加 few-shot 跑到瓶颈，再考虑微调，那时的收益才清晰。

Q：处理延迟多少算正常？ A：单条工单从触发到写回，一到三秒是正常区间。超过五秒通常是模型端排队，或者你在节点里串了不必要的查询。

注：n8n 节点名称、工单系统 API 字段随版本变动，具体以各自官方文档为准。