AI答不上来时，怎样连同上下文和待办转给人工？

转人工应把任务交给一个可确认的接收对象，并带上足够的上下文、已做动作、结果与待办。系统要分清“发起转交、进入队列、有人接收、处理结束”，还要安排队列不可用或无人接通时的下一步。仅回复“已经为您转人工”，或创建一张没有负责人和内容的工单，都不能说明问题已经有人处理。

这适合已经运行客服或内部助手、需要处理资料缺失、任务异常或人工请求的团队。人工接管负责让任务继续完成；执行前审批负责批准一个具体动作。接管人员接过会话，也不因此自动获得原本没有的数据权限或商务批准权。

先定义什么时候转，以及转给谁

转交触发可包括用户主动要求人工、关键依据不足、任务超出允许范围、重复失败、需要专业判断或业务系统不可用。模型给出的“信心分”可以是辅助信号，但没有校准时，不宜用一个通用分数决定所有业务是否继续。可以先用明确规则处理资料缺失、权限拒绝和重复错误。

上下文包应让接手的人直接继续工作

简明摘要有助于接手，但应提供受控查看原会话或相关记录的入口，防止摘要遗漏关键限定。没有必要把全部历史原样复制到所有系统。资料内容、可见角色、保存与清理方式，应按企业已确认的使用规则落实。

官方平台机制说明了什么，又留下什么工作

Microsoft Copilot Studio的通用客服平台handoff文档展示了一种机制：自建适配器接收handoff.initiate事件，提取会话上下文与记录，再交给客服平台。该页当前说明这条handoff路径仅支持Direct Line，需要客服平台可通过API或SDK交互，并明确适配器需要定制开发。

这说明“有转交事件”和“完成服务接管”之间仍有接入工作。项目需要确认客服系统接口、队列与人员规则、上下文能否写入并被接收方看到，以及失败如何返回。不能因为平台文档有handoff功能，就假定任意客服台、任意渠道可以直接接上。其他平台应核对其当时实际支持范围。

转交过程要有可核对状态

1. 发起转交：记录触发原因和任务标识，告知用户当前正在请求人工处理。
2. 目标已受理：取得客服台或工单系统的有效回执，核对上下文已关联；这一步还不等于人员已接手。
3. 进入队列与分配：确认队列、技能和可用人员规则，避免工单进入无人负责的分类。
4. 人工接收：按业务定义确认接收状态，交代剩余任务；自动系统避免继续并发处理同一动作。
5. 处理收口：将人工处理结果与未完成事项回到原任务，区分完成、需补资料与结束，避免只停在已转交。

异步工单与实时坐席的状态不同。异步受理可以显示“已登记，等待处理”，实时会话则应说明是否已经连接人员。只有在存在真实服务安排时，才向用户展示具体的响应时间；不能由模型自行承诺几分钟内有人回复。

无人接通、转交失败或用户离线，怎样继续

先为每种情况约定去向：队列关闭可提供已批准的联系渠道，接口失败进入可追踪的重试或待处理记录，用户离线可保留工单并按其允许的方式联系。若当前没有人工服务能力，应说明可用下一步，不模拟一个不存在的坐席或回执。

重试转交时使用同一任务关联信息核对是否已经创建工单，避免重复排队。人工接收后，如自动流程需要恢复，应先确认哪些动作已由人完成，谁仍拥有处理权。简单地恢复最初流程，可能再次发消息、改记录或把人工决定覆盖掉。

示例：售后助手缺依据，怎样把待办交给技术人员

示例（非客户案例）：内部售后助手收到一项设备异常描述，现有资料缺少对应版本的处理说明。它可以整理用户描述、已核对的资料版本、缺失点及已经排除的步骤，转交有权限的技术支持队列，并明确当前没有形成可靠处理结论。

验收时分别模拟队列可用、人员离线、接口返回失败、重复转交和用户补充信息。核对接收端看到的上下文是否一致，用户是否看到了真实状态，新补充信息能否关联原工单。最后由接手人按任务说明继续处理，而不是只检查转人工按钮是否弹出成功提示。

• 能从原任务查到受理回执、接收队列、人工状态与最终结果。
• 接收人能看到需要的资料与待办，且没有获得超出其权限的信息。
• 转交失败有责任人和后续动作，用户不会一直看到含糊的等待。
• 接管与自动恢复不会重复执行已有动作；人工处理结果不会被旧状态覆盖。

需要批准后再执行某个动作，可看人工审批与真实动作的核对方法；需要处理执行超时和重复写入，可看任务重试与续跑。已选助手任务需要连到真实客服台或工单系统时，可与企业 AI 项目落地服务确认接口、接收流程和验收范围。