上下文传递
设计目标
转人工时上下文传递的核心诉求是：让客服打开后台后不需要再问客户一遍。如果客服接管后第一句话是"您好，请问有什么问题？"，整个 AI 客服系统就失败了——客户已经讲了三五轮，再被要求复述会立即升级负面情绪。
上下文传递的目标是让客服在 30 秒内做到三件事：
- 看懂客户原诉求
- 知道 AI 已经做了什么
- 判断下一步该怎么处理
这三件事对应三类信息：客户原话、AI 处理记录、建议动作。
必传信息清单
| 信息项 | 来源 | 用途 |
|---|---|---|
| 最近 N 条客户消息（含原话） | messages.role='customer' | 听到客户原声，避免转述偏差 |
| 已识别意图 | messages.intent / conversation.intent_category | 快速判断问题类别 |
| 触发规则 | 转人工规则 #1-7 | 知道为什么转过来 |
| 关联订单号 | messages.tool_calls 或 tickets.related_order_id | 立即调出订单 |
| 已引用知识库 | messages.cited_article_ids | 知道 AI 引用了什么规则 |
| 工具调用结果 | messages.tool_calls | 看到订单查询返回的结构化数据 |
| 已创建工单 | tickets.id 关联 | 直接进工单详情页 |
| AI 三段摘要 | conversation.summary | 30 秒理解全局 |
缺少任何一项，客服都可能要回看完整聊天记录或重新询问客户。这八项是接管 UI 的最小必备字段。
AI 三段摘要格式
conversation.summary 字段在转人工时由 LLM 生成，固定三段结构：
【客户诉求】
客户反馈订单 MT-20260503-001 少送一份花蛤，态度焦急，要求处理。
【AI 已处理】
1. 致歉并安抚情绪
2. 调用订单查询工具确认订单含 1 份花蛤
3. 创建错餐工单（priority=high）
4. 触发转人工规则 #3（负面情绪 + 投诉）
【建议下一步】
1. 核对订单实际配送内容
2. 如确实少送，建议补发或退款 22 元
3. 如骑手已离开，建议联系骑手平台核实
摘要不是聊天记录复制粘贴，而是结构化提炼。客服读完摘要应能直接进入处理动作，而不是再去翻消息历史。
客户侧一致性
客户侧的状态显示必须和后台严格一致。常见错误模式和正确处理：
| 场景 | 错误处理 | 正确处理 |
|---|---|---|
后台仍是 pending_human | 客户侧显示"客服已接管" | 客户侧显示"已通知老板，请稍等" |
客服已接管（human） | AI 还在自动回复 | AI 暂停响应，客户消息直接给客服 |
| 客服回复后 | 客户消息样式仍是 AI 风格 | 客户看到 agent 风格气泡（不同颜色 + 头像） |
| 工单已 resolved | 客户侧无任何提示 | 客户侧显示"问题已处理，如有问题继续联系" |
状态一致性是接管体验的基本要求。任何不一致都会让客户产生疑虑（"到底有没有人在处理？"），进而升级为更严重的投诉。
接管时的 UI 关键信息
商家后台的接管面板（/admin/conversations/[id]）应该一屏显示：
┌─────────────────────────────────────────────────────────┐
│ ⚠ pending_human · 触发规则 #3 · 优先级 high │
│ 客户：张先生（VIP） 订单：MT-20260503-001 │
├─────────────────────────────────────────────────────────┤
│ 【客户诉求】 │
│ 反馈订单少送一份花蛤，态度焦急，要求处理。 │
│ │
│ 【AI 已处理】 │
│ ✓ 致歉安抚 ✓ 查订单 ✓ 建工单 ✓ 转人工 │
│ │
│ 【建议下一步】 │
│ • 核对订单 → • 决定补发或退款 22 元 → • 联系客户 │
├─────────────────────────────────────────────────────────┤
│ [📋 查看完整对话] [🎫 工单 T-2049] [📦 订单详情] │
│ [✅ 接管] [↩ 释放回 AI] [☎ 拨打客户电话] │
├─────────────────────────────────────────────────────────┤
│ 输入回复... [发送] │
└─────────────────────────────────────────────────────────┘
关键设计点：
- 顶部状态栏立即显示风险等级
- 三段摘要直接呈现，不需要客服点击展开
- 主要操作按钮（接管、查工单、查订单）都在一屏内
数据写入时机
为了保证上下文及时可见，系统在以下时机写入字段：
| 时机 | 写入字段 |
|---|---|
| 客户消息进入 → 意图识别后 | messages.intent |
| 转人工规则命中 | conversation.status='pending_human'，tickets 行 |
| LLM 生成摘要 | conversation.summary |
| 工具调用结束 | messages.tool_calls |
| 知识库引用 | messages.cited_article_ids |
| 客服接管 | conversation.status='human'，assigned_to |
| 客服回复 | messages.role='agent' |
| 工单解决 | tickets.resolution，resolved_at |
每个写入都进入数据库 transaction 确保原子性，避免出现"客户已转但摘要未生成"的中间状态。
失败兜底
如果 LLM 生成摘要失败（超时或异常），系统的兜底策略：
- 不阻塞转人工流程，仍然把状态切到
pending_human - 摘要字段填入「自动摘要生成失败，请查看完整对话」
- 仍然把转人工规则、工单 ID、关联订单写入工单
description - 后台异步重试摘要生成（最多 3 次）
兜底原则：结构化字段优先于自然语言摘要。即使没有摘要，客服只要能看到触发规则、关联订单、客户最近 3 条原话，仍然能完成接管。
后续优化方向
当前实现是"三段摘要 + 字段联动"。未来可以扩展为结构化卡片：
- 订单卡：订单号、菜品、金额、骑手、ETA
- 情绪卡：情绪等级（中性/不满/愤怒）、关键负面词
- 风险卡：触发规则、优先级、健康风险标识
- 建议动作卡：候选回复模板、退款金额建议、SOP 链接
客服不需要读完整聊天日志，就能在 10 秒内判断处理优先级。这是 D5+ 阶段的优化方向，但前提是当前的"必传信息 + 三段摘要"已经稳定运行。