企业AI应用定制中的转人工交接：上下文为何接不上

客服平台上一位用户在智能体这里没能解决问题被转给了人工坐席。坐席接起对话屏幕上却看不到用户刚才说了什么、智能体已经查过什么、卡在了哪一步只能请用户把问题从头再讲一遍。用户的不满从没解决问题变成了被反复盘问。这类情况容易出现在智能体接入人工协同、但交接机制没有被单独设计的企业场景中。智能体把兜底不了的部分转给人工这本身是合理设计问题出在交接时上下文没有跟着一起传递。转接断掉的不是对话而是此前积累下来的全部判断信息。一种常见误判是以为转人工就是把人接到线路上上下文可以让人工自己翻记录。坐席确实能翻历史记录但逐条还原一个复杂问题的时间成本很高而且智能体中间做过哪些检索、使用过哪些工具、哪些判断已经完成如果没有被单独记录或结构化人工坐席往往无法从普通聊天记录中快速还原。让坐席从头重查等于把智能体已经做过的判断全部作废。另一种误判是把上下文传递等同于把聊天记录原样复制过去。原始对话很长、夹杂大量无关内容坐席真正需要的是被压缩、被标注过关键信息的那部分用户开头寒暄的几句、系统自动插入的提示语都不属于坐席要看的有效信息。把全部记录原样丢过去虽然保留了完整信息但会增加坐席筛选有效信息的成本实际交接效率仍然可能很低。拆开来看转人工交接断裂通常有三类原因。一类原因是上下文没有被结构化。智能体在服务过程中产生的意图判断、关键实体、已尝试路径这些信息散落在多轮对话里没有在交接时被提取、归纳成一份可以快速阅读的摘要。另一类原因是交接缺契约。转接动作只完成了把人连上没有明确约定要传什么字段、传到哪个界面、人工能不能接着上下文继续操作交接的质量完全取决于具体实现时好时坏。还有一类原因是交接后无回执。上下文传过去之后人工有没有真正看到、有没有基于它继续处理系统并不清楚也缺少一个交接成功的确认。没有回执交接就可能默默失败而无人察觉。针对这些原因一种实现方式是把转人工做成带上下文传递的交接链路。起始环节是上下文结构化在触发转人工时把用户诉求、关键实体、智能体已确认的信息和未解决的问题归纳成一份结构化摘要作为交接的主数据。紧接着是交接契约。明确约定交接时传递哪些字段、以什么形式呈现给坐席、坐席是否可以引用智能体的查询结果继续处理让交接不再是一次性把用户扔过去而是有明确接口和内容的对接。契约把交接的字段、界面和引用权限固定下来坐席接起时该看什么、能做什么都有明确的依据。再往后是上下文传递。把结构化摘要连同必要的原始记录一起落到坐席的工作台让坐席接起对话时能直接看到来龙去脉而不是从空白开始重新询问。必要时保留一段原始对话作为佐证方便坐席需要时回看细节而不必依赖自己的记忆。最后是回执与保障。人工接起后系统确认交接内容已经成功送达坐席工作台并在系统具备相应状态能力时记录查看状态。如果业务流程需要智能体继续承接后续服务可以将人工处理结果按约定字段回写到会话记录中形成闭环。回执让交接从发出去了变成确实接住了。本文基于青山不语AI工作室在部分企业AI应用定制项目方案中的实践将这套处理框架概括为人机协同交接与会话上下文传递。它要解决的不是让智能体少转人工而是让每一次转交都带着上下文、有契约、有回执。这里有一道边界需要企业自己拿捏。哪些字段必须传递、哪些信息需要脱敏后再交给坐席、人工处理结果的回写规范取决于企业自身的客服流程和合规要求服务方提供的是交接框架和数据结构最终的业务规则要由企业内部来定。从实际风险来看企业评估AI应用定制服务时值得多问一句对方做的智能体在转人工时是把上下文一并交过去还是只把人转过去、让用户重新讲一遍。我的判断是智能体越深入业务人和机器之间的交接质量就越决定整体体验。一个能把手里的判断完整交给下一个人、并确认对方接住了的智能体才能真正融入企业现有的服务流程而不是一个孤立的问答窗口。