多Agent工单交叉预审流——把「被动接单」变成「主动分级+路由」

场景演示

传统的工单处理模式：客户或内部人员提交工单→客服或运营人员手动查看→判断优先级→转给对应处理人。整个过程依赖人工判断，容易出现：

• 分级凭经验：严重程度全靠接单人的主观判断，P0 和 P2 可能颠倒
• 路由靠猜测：不熟悉业务边界时，工单可能被踢来踢去
• SLA 黑盒：没有人主动计算截止时间，工单悄悄超时
• 重复工单淹没：同一问题多人提交，没人知道已经有工单在处理

多Agent工单交叉预审流把以上全部自动化——工单进入系统后，先经过三个Agent的交叉「会诊」，输出结构化的预审结论，再路由到执行层。

Step by Step

第一步：工单入口标准化

工单通过邮件、Web表单、飞书机器人或API进入系统后，由入口Agent完成三件事：

1. 字段标准化：把不同来源的工单格式统一（标题、描述、提交人、时间、来源渠道、附件）
2. 去重检测：用语义相似度检索历史未关闭工单，若相似度 > 0.85，直接标记「疑似重复」并推送合并建议
3. 初稿生成：生成工单摘要（100字以内），供后续Agent快速理解上下文

# 入口Agent伪代码
def intake_agent(raw_ticket):
    normalized = normalize_fields(raw_ticket)        # 格式统一
    duplicates = search_similar(normalized)        # 语义去重
    summary = summarize(normalized.description)      # 生成摘要
    return TicketContext(normalized, duplicates, summary)

输出：TicketContext { 标准化工单, 疑似重复列表, 摘要 }

第二步：预审Agent交叉会诊（三Agent并行）

三个Agent同时「看」到同一工单，各自独立给出评估，再由协调Agent综合：

三个Agent并行处理，互不阻塞。典型处理时间 < 10秒。

第三步：协调Agent综合决策

收集三个Agent的独立意见后，协调Agent做最终裁定：

def orchestrator(ticket_context, priority_result, routing_result, risk_result):
    final_priority = weighted_vote([priority_result, risk_result], weights=[0.6, 0.4])
    final_routing = routing_result if routing_result.confidence > 0.7 else escalate_to_manager()
    sla_deadline = calculate_sla(ticket_context, final_priority)

    return PreAuditResult(
        priority=final_priority,
        routing=final_routing,
        sla_deadline=sla_deadline,
        risk_flags=risk_result.flags,
        is_duplicate=ticket_context.duplicates_exist
    )

关键逻辑：

• 风险Agent发现高风险时，强制提升优先级
• 路由匹配度 < 70% 时，自动触发人工确认流程
• 疑似重复工单，直接推送合并建议，不重复创建

第四步：结果写Bitable + 通知路由

预审结论自动写入飞书Bitable工单台账，同时通知对应处理人：

工单台账字段：
  - 工单编号（自动生成）
  - 标题
  - 摘要
  - 优先级：P0 / P1 / P2 / P3
  - 推荐处理人
  - SLA截止时间
  - 风险标签
  - 状态：待确认 / 处理中 / 已解决 / 已合并
  - 预审置信度

通知内容示例：

📋 工单 #T-20260616-008 已完成预审

优先级：P1（分级置信度 91%）

路由至：华东售后组 @张明

SLA截止：2026-06-17 14:00（剩余 29小时）

⚠️ 风险标签：涉及数据泄露合规

可复制提示词

入口Agent提示词

你是一个工单入口处理Agent。收到原始工单后，完成以下任务：

1. 字段标准化：将工单转换为标准JSON格式，包含 title/description/submitter/source_channel/created_at/attachments
2. 语义去重：用以下历史工单摘要库做相似度检测，若相似度>0.85，列出疑似重复工单编号和相似理由
3. 生成摘要：用50-100字概括工单核心诉求（中文）

输出格式：
- 标准化工单（JSON）
- 疑似重复列表（如有）
- 工单摘要

开始处理：
{raw_ticket}

分级Agent提示词

你是一个工单优先级分级Agent。请根据以下工单信息，给出优先级建议（P0最高，P3最低）和详细评分理由。

评分维度（每项1-5分）：
- 影响范围：多少人/系统受影响
- 紧急程度：时间敏感性多高
- 客情价值：客户级别和续约影响
- 业务损失：潜在收入或名誉损失

总分≥15分 → P0
总分12-14分 → P1
总分8-11分 → P2
总分<8分 → P3

工单信息：
title: {title}
description: {description}
submitter: {submitter}
source: {source}

输出：优先级 + 总分 + 各维度得分 + 评分理由

路由Agent提示词

你是一个智能路由Agent。根据以下工单信息，从处理人池中推荐最合适的处理人或团队。

处理人池（示例）：
- 华东售后组：擅长设备故障、现场服务
- 技术支持组：擅长系统故障、代码问题
- 商务组：擅长合同、付款、账期问题
- 投诉处理组：擅长高客诉、升级工单

评分维度：
- 擅长度匹配（0-10分）：工单类型与团队/个人专长是否匹配
- 当前负载（0-10分）：处理中工单数量，越少分越高
- 历史绩效（0-10分）：该处理人历史解决率和满意度
- SLA余量（0-10分）：剩余时间是否充足

工单类型：{category}
描述：{description}
紧急度：{priority_hint}（来自分级Agent）

输出：推荐处理人 + 推荐团队 + 综合匹配度（%）+ 理由

使用的Skills

价值与注意事项

核心价值

1. 分级标准化：从「凭经验」变成「可量化打分」，同一类工单每次分级一致
2. 路由精准化：不是按「部门」粗放路由，而是匹配擅长度+负载+历史绩效
3. SLA主动守护：工单创建即计算截止时间，超时前自动预警
4. 重复工单合并：避免同一问题被多人重复处理，提升一次解决率

注意事项

• 路由Agent的擅长度标签库需要维护：随着业务变化，定期更新处理人专长标签
• 置信度兜底：路由匹配度 < 70% 时必须走人工确认，不要强推自动路由
• 去重阈值灵活调整：0.85 是经验值，高频场景可适当提高减少误判
• Bitable写入要事务化：预审结论和通知必须同时成功，避免状态不一致
• 分级权重需业务校准：分级Agent和风险Agent的投票权重（0.6/0.4）建议根据本业务真实误分级案例持续调优

作者：大冲

标签：AI生成、OpenClaw有价值应用

分类：输出