MCP 智能客服中的人机协作平滑流转：低置信度下的自动转工单机制
在搭建基于 Model Context Protocol（MCP）的自动化客服系统时，许多独立开发者容易走向两个极端：
- 极端一：过度自信，完全不留人工通道。大模型直接面对所有客户，一旦遇到模型理解不了的罕见极端纠纷，模型开始胡言乱语甚至死循环，导致原本对产品很有意愿的客户在气愤中直接流失；
- 极端二：过于保守，稍微复杂一点就弹“请联系人工”。但独立开发者白天还要写代码、做饭、遛猫，根本做不到 24 小时守在电脑前秒回消息。用户看到人工不在线，同样会感到沮丧。
一套真正成熟的商业级智能客服架构，必须遵循**“人机协同（Human-in-the-loop）”的弹性分流哲学**：
大模型负责消化 85% 以上的高频、确定性咨询（查订单、重发发票、退订指引）；而一旦大模型自评置信度过低、检测到用户强烈的负面情绪、或者涉及高危操作（如申请退款、修改账号主体），系统必须瞬间且平滑地冻结大模型的自主决策，将完整的会话上下文自动提炼为结构化工单，并通过 Webhook 实时唤醒开发者的移动设备。
本文分享我在 3 款上线产品中运行的基于动态置信度评分（Confidence Scoring）与飞书/Telegram 协同的人机兜底流转体系。
什么时候大模型必须立即“闭嘴”
在我的生产规则引擎中，设定了四道触发强行转人工的刚性熔断红线：
- 涉及资金出入与退款争议：任何包含“退款（Refund）”、“拒付（Dispute）”、“投诉（Complaint）”的高风险意图，大模型只被允许执行安抚与政策陈述，绝对严禁自主承诺退款到账时间。
- 多轮对话死循环（Repetition Loop）：当用户在最近三轮对话中反复输入相似语义的问题（通常意味着大模型的回答未能击中痛点），系统判定当前上下文陷入死锁。
- MCP 工具查询结果为空或发生异常：大模型调用底层 MCP Server 查订单，接口返回 404 或超时。此时大模型极易产生幻觉，向用户捏造虚假的物流或账单信息。
- 模型自身输出的置信度评分低于阈值（Confidence < 0.7）：模型在推理思考链中明确对用户的特定专业术语感到不确定。
MCP 服务端置信度自检与工单流转工具设计
在 MCP Server 中，我们不仅暴露“业务查询工具”，更暴露出一个专门用于降级流转的系统级工具：escalate_to_human_support。
我们在 System Prompt 中赋予模型自我审视的元认知能力，一旦它觉得自身无法确定，优先主动调用该流转工具：
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js' import { Server } from '@modelcontextprotocol/sdk/server/index.js' import axios from 'axios' const server = new Server({ name: 'support-escalation-server', version: '1.0.0' }, { capabilities: { tools: {} } }) server.setRequestHandler(ListToolsRequestSchema, async () => { return { tools: [ { name: 'escalate_to_human_support', description: '当用户的诉求涉及退款争议、复杂账单核算、或当前知识库无法给出 100% 确定答复时，调用此工具将工单安全流转给人工客服。', inputSchema: { type: 'object', properties: { issueCategory: { type: 'string', enum: ['refund_request', 'account_takeover', 'technical_bug', 'complex_inquiry'], description: '问题的核心分类', }, urgencyLevel: { type: 'string', enum: ['low', 'medium', 'high', 'critical'], description: '紧急度评估', }, conversationSummary: { type: 'string', description: '对前序对话核心矛盾的一句话中肯总结，便于人工 5 秒内看懂', }, }, required: ['issueCategory', 'urgencyLevel', 'conversationSummary'], }, }, ], } }) server.setRequestHandler(CallToolRequestSchema, async (request) => { if (request.params.name === 'escalate_to_human_support') { const args = request.params.arguments as any const userEmail = (request.params as any)._context?.userEmail || '匿名客户' // 1. 将工单推送到开发者的 Telegram / 飞书即时通信群 const alertMessage = ` 🚨 【客服系统触发人工流转】 - 客户邮箱: ${userEmail} - 问题类型: ${args.issueCategory} - 紧急程度: ${args.urgencyLevel.toUpperCase()} - 矛盾摘要: ${args.conversationSummary} - 触发时间: ${new Date().toLocaleString()} ` await axios.post(`https://api.telegram.org/bot${process.env.TELEGRAM_BOT_TOKEN}/sendMessage`, { chat_id: process.env.TELEGRAM_CHAT_ID, text: alertMessage, }) // 2. 在本地数据库创建工单记录 await createSupportTicket({ email: userEmail, category: args.issueCategory, summary: args.conversationSummary, status: 'pending_human', }) // 3. 返回给大模型安全的话术指导 return { content: [ { type: 'text', text: JSON.stringify({ status: 'escalated_successfully', systemDirective: '工单已直接抄送创始人团队。请以诚恳、温暖的口吻向用户致歉，并告知我们已收到全部上下文，通常在 2 小时内会直接通过此对话框或邮件给出最终解决方案。', }), }, ], } } throw new Error('未支持指令') })前端对话窗口的平滑状态切换
当 Agent 触发了人工流转后，前端的交互不能只是冷冰冰地结束，我们通过 WebSocket 或 SSE 接收到escalated状态，对界面执行微调：
- 消息气泡下方渲染一个带工单编号的进度条：
工单 #TK-202610-08 已同步至值班工程师； - 输入框变为“可继续留言补充信息”状态；
- 如果开发者在移动端 Telegram 点击了回复，后端的 Webhook 会直接将开发者的手打文字注入回用户的同一个网页聊天流中，用户甚至感知不到系统曾经在 AI 与真人之间完成过无缝切换。
实战效果与客户口碑复盘
这套人机协同系统在过去半年的生产运行中，呈现出极高的商业价值：
- 杜绝恶性幻觉：AI 再也没有向任何一个用户做出过“明天立刻全额退款”等荒唐承诺；
- 创始人精力深度解放：整整86.4%的常见问题被 AI 独立闭环解决，我每天真正需要手动介入处理的疑难工单平均不到 3 单；
- 用户满意度飙升：即便是遭遇系统 Bug 的愤怒客户，在看到系统不仅能准确总结他的核心诉求、还能在几分钟内引来创始人亲自答复时，原本的抵触情绪往往能瞬间转化为对团队极其负责的敬佩与好感。
智能客服的核心竞争力，不是吹嘘自己的 AI 有多像真人，而是用严谨的工程边界保护用户的核心利益。放低身段，把不确定的难题体面地接回人类手中，这是技术向善与商业长青的最优平衡点。