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