为客服 Agent 增设风险路由层

AI 支持 Agent 并不需要怀有恶意，也足以破坏用户的信任。它只需要在回答退款问题、服务中断投诉、安全疑虑或企业续约工单时，用看似专业自信的语气给出证据薄弱的答案。

因此，任何认真构建 AI 产品的团队，都需要在允许 Agent 自主发送回复之前，部署一个 AI 支持升级路由器。路由器负责决定 AI 何时可以直接回答、何时只能起草回复、何时应该提出澄清问题，以及何时必须由人工接手。

目标不是将人工从支持工作中移除，而是在避免人力浪费于常规问题的同时，保护客户免受少数不适合快速自动化处理的情况影响。

工作定义：AI 支持升级路由器是一个策略层。它会评估每一次支持对话的意图、风险、证据、置信度、账户上下文和客户情绪，然后决定下一步最安全的操作。

近期 AI 平台释放出的信号都指向同一个方向：Agent 正在从演示项目进入生产工作流。客户支持产品开始推出能够分类、起草、回复和转交工单的 AI Agent。AI gateway 和支出控制台的陆续发布也表明，团队如今越来越关注成本、路由、可观测性和业务影响。

开发者的讨论始终围绕着几个令人不安的问题：

• 如何阻止 AI 支持 Agent 重复犯下同样的错误？

• 如何防止幻觉内容发送给客户？

• 哪些回复应该在发送前由人工审批？

• 如何在转交过程中保留上下文，避免客户重新解释一遍所有事情？

• 如何衡量自动化究竟是真正解决了问题，还是仅仅更快地转发了问题？

搜索 AI 升级处理时，结果大多是平台页面、泛泛的客户服务建议，以及高层次的路由概念。真正缺少的是一份面向构建者的实用指南：schema、阈值、队列、证据检查，以及适合小型 AI 产品团队的安全默认设置。

这正是本文要填补的空白。

核心错误：把升级处理当成兜底机制

许多团队会像这样连接支持自动化流程：

user message -> AI answer -> if user complains -> human handoff

这种方式看起来很简单，但顺序完全反了。

升级处理不应该只发生在 AI 失败之后，而应该发生在 AI 执行不安全操作、给出缺乏依据的答案，或者进一步激怒客户之前。

更合理的流程如下：

user message
  -> classify intent
  -> score risk
  -> check evidence
  -> estimate answer confidence
  -> inspect account context
  -> choose safe action

安全操作可能包括：

• 提出澄清问题

• 起草回复，交由人工审核

• 路由至计费、安全、客户成功或工程团队

• 因为客户正在生气、客户价值较高，或者受到了事故影响而暂停自动化

这会让升级处理从一个紧急按钮，转变为整个支持流程的控制平面。

每个支持 Agent 都需要的路由状态

不要一开始就设计十几个复杂的工作流。先从五种路由状态开始。

这些状态足够简单，独立开发者也能实现；同时又足够清晰，支持团队可以对其进行审计。

第 1 步：识别支持请求的意图

路由器在考虑置信度之前，应该先知道自己正在处理哪一类问题。

AI 产品支持中的常见意图包括：

• 登录或访问问题

• 计费或退款问题

• 套餐限制或配额问题

• 数据导入或导出问题

• 安全或隐私疑虑

• 服务中断或性能投诉

意图识别不只是为了分析数据，它还会改变后续的安全操作。

对于“如何连接 Slack？”这类问题，模型通常可以依据文档直接回答。但对于“为什么你们的系统会泄露其他客户的数据？”这类问题，它不应该在未经人工审核的情况下自由作答。

type SupportIntent =
  | "how_to"
  | "billing"
  | "bug_report"
  | "security_privacy"
  | "outage"
  | "cancellation_risk"
  | "feature_request"
  | "account_access"
  | "unknown";

type IntentResult = {
  intent: SupportIntent;
  confidence: number; // 0 to 1
  reason: string;
};

意图置信度较低时，绝不能直接生成一份信心十足的答案，而应该路由至 clarify 或 draft_for_review。

第 2 步：先评估风险，再考虑置信度

置信度回答的是：“AI 认为自己知道答案吗？”

风险回答的则是一个更重要的问题：“如果 AI 答错了，会发生什么？”

在决定允许模型执行哪些操作之前，先划分风险等级。

type RiskTier = "low" | "medium" | "high" | "critical";

type RiskSignal = {
  tier: RiskTier;
  reasons: string[];
  requiresHuman: boolean;
};

一套实用的初始策略如下：

• 低风险：文档问题、设置帮助、简单故障排查

• 中风险：针对特定账户的回答、临时解决方案、套餐限制问题

• 高风险：计费争议、取消订阅风险、生产环境 bug、集成故障

• 严重风险：安全事故、隐私疑虑、法律请求、服务中断、数据丢失

function routeByRisk(risk: RiskSignal) {
  if (risk.tier === "critical") return "human_handoff";
  if (risk.tier === "high") return "draft_for_review";
  return null; // continue scoring
}

仅这一条规则，就能阻止支持自动化中最危险的模式：让表达流畅的模型把敏感问题当成普通 FAQ 处理。

第 3 步：要求提供证据，而不是凭感觉回答

对于支持场景，最安全的 AI 答案通常应以以下来源之一为依据：

• 当前账户状态

• 最近的事故状态

• 已获批准、可供支持团队使用的工程记录

路由器应该追问：“有哪些证据支持这个答案？”

一个实用的证据对象如下：

type EvidenceItem = {
  sourceType: "docs" | "runbook" | "account_state" | "incident" | "ticket_history";
  sourceId: string;
  title: string;
  freshness: "fresh" | "stale" | "unknown";
  allowedForCustomer: boolean;
  relevance: number;
};

然后执行一条简单规则：

function hasCustomerSafeEvidence(items: EvidenceItem[]) {
  return items.some(
    (item) =>
      item.allowedForCustomer &&
      item.freshness !== "stale" &&
      item.relevance >= 0.75
  );
}

如果不存在可安全提供给客户的证据，AI 就不应该发送一份信心十足的答案。它可以提出澄清问题、起草回复等待审核，或者进行升级处理。

内部记录即使内容属实，也不一定适合直接告诉客户。

第 4 步：区分回答置信度与路由置信度

不要用一个置信度分数解决所有问题。

至少需要三个分数：

• 意图置信度：我们是否正确识别了请求？

• 证据置信度：我们是否掌握了可靠的信息来源？

• 回复置信度：生成的回复是否准确、完整？

只有当这三个分数都足够高，并且风险等级允许时，才能自动发送回复。

type RoutingScore = {
  intentConfidence: number;
  evidenceConfidence: number;
  replyConfidence: number;
  sentimentScore: number; // -1 angry to +1 happy
};

function chooseRoute(risk: RiskTier, score: RoutingScore) {
  if (risk === "critical") return "human_handoff";
  if (risk === "high") return "draft_for_review";

  if (score.sentimentScore < -0.55) return "human_handoff";
  if (score.intentConfidence < 0.7) return "clarify";
  if (score.evidenceConfidence < 0.8) return "draft_for_review";
  if (score.replyConfidence < 0.82) return "draft_for_review";

  if (risk === "medium") return "draft_for_review";
  return "auto_reply";
}

这些阈值并非放之四海而皆准。关键在于让它们足够明确、可以度量，并且易于调整。

第 5 步：使用账户上下文，但不要泄露账户信息

良好的支持路由离不开账户上下文，糟糕的支持路由则会把所有信息一股脑塞进 prompt。

应该只传递路由决策所必需的事实：

{
  "account_tier": "growth",
  "is_enterprise": false,
  "open_incidents": 1,
  "billing_status": "active",
  "recent_tickets_30d": 4,
  "recent_sentiment": "frustrated",
  "permissions": {
    "can_view_billing": false,
    "can_discuss_security": false
  }
}

支持 Agent 不需要获取原始发票、私人评论、完整的 Slack 对话串或 CRM 中的每一条记录，才能决定是否应该升级处理。它只需要范围经过约束、足以选择安全路由的上下文。

这样既能降低 token 成本，也能减少信息泄露的风险。

第 6 步：在转交时保留上下文

糟糕的转交会迫使用户重复说明问题。良好的转交则会为人工支持人员提供一份整理清楚的信息包。

转交信息包应该包括：

• 客户消息摘要

• 风险等级及其原因

• AI 尝试生成的草稿（如果有）

• 客户情绪信号

• 允许提供给人工队列的账户上下文

• 建议采取的下一步操作

{
  "route": "human_handoff",
  "queue": "billing_specialist",
  "summary": "Customer says they were charged after cancellation and is frustrated.",
  "intent": "billing",
  "risk_tier": "high",
  "risk_reasons": ["refund request", "negative sentiment", "account-specific billing"],
  "evidence_found": ["subscription_status", "latest_invoice"],
  "evidence_missing": ["cancellation_timestamp"],
  "suggested_next_action": "Verify cancellation timestamp before replying."
}

这样一来，即使自动化系统没有直接发送回复，它依然能够发挥作用。

第 7 步：加入针对不同队列的路由机制

人工转交并不意味着把所有问题都扔进同一个队列。

• 计费和退款 → 计费支持

• 企业账户风险 → 客户成功团队

• 安全或隐私 → 安全支持

• 可复现的 bug → 技术支持或工程分诊

• 服务中断投诉 → 事故响应队列

• 表述模糊但情绪愤怒的消息 → 资深综合支持人员

一个简单的队列选择器如下：

function selectQueue(intent: SupportIntent, risk: RiskTier) {
  if (intent === "security_privacy") return "security_support";
  if (intent === "billing") return "billing_support";
  if (intent === "outage") return "incident_response";
  if (intent === "bug_report" && risk !== "low") return "technical_support";
  if (intent === "cancellation_risk") return "customer_success";
  return "general_support";
}

路由器应该让人工首次响应变得更快，而不只是把工单转移到另一个地方。

第 8 步：衡量问题是否解决，而不是衡量工单是否被拦截

“工单拦截率”可能会奖励糟糕的行为。AI Agent 可以通过给出浅薄的答案，让用户无奈放弃，从而实现所谓的工单拦截。

应该跟踪更有意义的指标：

• 自动回复解决率

• AI 回复后重新开启的工单数

• 按意图分类的人工接管率

• 路由至正确队列的平均耗时

• AI 回答后的客户情绪

• 包含客户安全证据的回复比例

• 各队列的升级准确率

• 每个已解决对话的成本

• AI 草稿的审核拒绝率

一个实用指标是安全自动化率：

safe automation rate = AI-resolved conversations without reopen / eligible low-risk conversations

这种指标不会因为路由器升级了高风险工单而对其进行惩罚。路由器阻止不安全场景中的自动化时，恰恰是在正确履行职责。

一套可以直接采用的实用路由策略

下面是一套适合小型 AI 产品团队的精简策略：

它并不花哨，而这正是它有效的原因。

它应该位于架构中的什么位置

将升级路由器放在对话接入和回复执行之间。

channels
  -> conversation normalizer
  -> intent classifier
  -> evidence retriever
  -> risk scorer
  -> escalation router
  -> AI reply / clarification / review queue / human handoff
  -> audit log

路由器不应该只存在于 prompt 文本中。prompt 可以解释策略，但最终路由必须由代码强制执行。

为每一次决策保留下列日志：

• 决策发生时使用的阈值

• 人工覆盖决策（如果有）

这样，当客户投诉、审核人员拒绝草稿，或者某个队列收到错误转交时，你就拥有了完整的反馈闭环。

常见的实现错误

应尽早警惕以下问题：

• 让模型自行决定自己的权限。模型可以建议路由，但你的应用程序应该强制执行路由决策。

• 只依赖情绪。一位愤怒的客户可能遇到的只是简单问题；一位情绪平静的客户也可能正在报告安全漏洞。

• 过早自动发送针对特定账户的回答。如果答案依赖计费记录、权限或事故状态，就应该提高阈值。

• 隐藏升级处理的原因。“置信度低”不如“计费争议、缺少取消时间戳、情绪愤怒”具体。

• 只衡量工单量。还要关注重新开启的工单、投诉、退款、审核拒绝和存在流失风险的对话。

一套轻量级上线计划

首先以只读模式运行。识别意图和风险，在工单旁边显示建议的路由，并将路由器的判断与人工决策进行比较。接下来，只自动路由明显的严重风险转交，以及低风险的文档问题。然后再为中等风险工单启用 AI 草稿。自动发送应该放在最后，而且只适用于证据充分、重新开启率较低、范围明确的回复。

在你的 AI 支持 Agent 发送回复之前，先问这些问题：

• 我们是否以足够高的置信度识别了意图？

• 风险等级是否足够低，可以使用自动化处理？

• 我们是否拥有新鲜、可以安全提供给客户的证据？

• 回复是否以这些证据为依据？

• 客户是否正在生气、属于高价值客户，或者受到了事故影响？

• 错误答案是否可能造成财务、安全、法律或信任方面的损害？

• 我们是否记录了路由、分数、阈值和证据？

• 如果由人工接管，对方能否准确知道接管的原因？

如果答案不明确，就不要自动发送。应该起草回复、提出澄清问题或转交人工。

什么是 AI 支持升级路由器？

AI 支持升级路由器是一个策略层，用于决定某次支持对话应该由 AI 直接回复、提出澄清问题、生成需要人工审核的草稿，还是立即转交人工处理。它会使用意图、风险、证据、置信度、情绪和账户上下文来作出决策。

升级路由与聊天机器人的 fallback 有何区别？

fallback 通常发生在聊天机器人失败之后。升级路由则发生在不安全的回复发送之前，避免高风险工单被当作普通 FAQ 处理。

AI 支持 Agent 是否应该使用置信度分数？

应该，但不能用一个分数衡量所有事情。应分别跟踪意图置信度、证据置信度和回复置信度。只有当所有必要分数都超过阈值，并且风险等级允许时，才能自动发送回复。

什么情况下应该由人工审核 AI 支持回复？

计费争议、退款、特定账户问题、安全疑虑、隐私问题、服务中断投诉、愤怒的客户、高价值账户，以及任何缺少有力客户安全证据的回答，都应该由人工审核。

哪些指标可以说明支持自动化是否有效？

实用指标包括自动回复解决率、重新开启的工单数、审核拒绝率、证据覆盖率、人工接管率、升级准确率、进入正确队列所需的时间、回复后的客户情绪，以及每个已解决对话的成本。

小型团队能否在没有完整支持平台的情况下构建它？

可以。先从简单的 schema、五种路由状态、针对严重风险的硬性规则、证据检查和审计日志开始。收集真实结果之后，再加入高级队列路由和参数调优。

对于后续操作，你可以考虑屏蔽此人和／或举报其滥用行为。