AI智能体转人工后用户还得把诉求重说一遍，2026年这段上下文该怎么交过去才不丢？

结论先说：AI智能体转人工后用户还得把诉求重说一遍，2026年多数项目卡的不是坐席系统，而是智能体这一侧没有可交接的状态载体。常见做法是把上下文拆成事实、摘要、待办三件套，落到一张坐席工作台能直接读的交接单上：统一会话ID、用户身份主键、订单或工单锚点、二到四句结构化摘要、未决诉求与风控标注。字段齐了，用户通常不必重复陈述；只补摘要不补锚点，坐席仍要开口问订单号，等于只省了一半功夫。

转人工这一步为什么常常断在半路

转人工是一个跨系统动作：智能体跑在推理侧，会话上下文多数只活在当前会话窗口里；坐席工作台读的是业务侧数据，靠的是订单号、用户ID这类结构化主键。两边没有公共主键时，坐席除了开口再问一遍，没有别的办法把对话接上，用户体感就是「又要说一遍」。

按能力层（模型与多模态）→业务层（意图、槽位、工单）→载体层（网站、小程序、APP、H5）→数据与风控这四层来看，上下文产生在能力层，却要在载体层被消费。状态写在能力层、使用发生在载体层，是这类断点反复出现的根因，而不是坐席系统本身不好用。

• 会话ID断裂：智能体侧按请求生成随机ID，坐席按工单ID接手，两条线各记各的。
• 锚点缺失：用户说过订单号，但没被提取成结构化槽位，转接后等于没说过。
• 摘要没生成：指望坐席翻原始对话，十几轮消息里找重点，翻两屏就容易放弃。

这三种断点在2026年的客服类项目里仍然常见，原因也类似：大家把精力放在模型答得像不像人，交接链路反而没人认领。

三件套加一张交接单，怎么划分才够用

不把原始对话直接丢给坐席，有三个现实理由：原始消息里混着工具调用日志与内部提示词，不适合外露；长度按轮次线性增长，坐席没时间读完；涉及金额、时效、承诺的内容需要以系统字段为准，不能靠自然语言复述。所以交接的落点应该是一张字段固定的交接单。

常见的划分方法是「三件套加一张单」：事实、摘要、待办是内容，交接单是载体。四步都做完，坐席才可能接近零复述。

1. 会话事实：用户身份主键、订单或工单锚点、入线渠道、首次接入时间，必须能对上业务系统的主键。
2. 结构化摘要：把三到十轮对话压成二到四句，写清用户已确认的结论和明确否定过的选项。
3. 待办与未决：用户到底要什么、卡在哪一步、自己试过什么、期望什么时候有结果。
4. 风控与合规标注：是否涉及退款、投诉、医疗或未成年用户等需要升级处理的场景，供坐席判断优先级。

交付现场常见的那点事

在某类客服项目里，约束通常是预算有限、排期只有两周左右、素材是现成的提示词和话术库，坐席团队还要兼顾原有工单。做法上先只做摘要和订单锚点两个字段，快速上线。结果第一周坐席反馈，摘要把「用户其实要改收货地址」写成了「用户咨询物流」，坐席照摘要回了错方向，用户当场发火。后来返工重写摘要提示词，并补上一个坐席可编辑、可回写的摘要字段，整体多花了一周左右。

这段代价说明的点很具体：不是模型写不出摘要，而是没给坐席留修改口。改稿的常见区间是半个工作日到一周，取决于字段数量和回写逻辑的复杂度；如果一开始就把摘要可编辑、金额以系统字段为准写进需求，返工通常会少掉大半。

• 交接单要留一个原始对话回看入口，正文能摘录就摘录，不能摘录的让坐席点一下看原话。
• 摘要模板固定成「用户想做什么＋已确认什么＋还差什么」，比让模型自由发挥稳定。
• 转接前做一次字段完整性校验，缺主键就先不转，提示用户补一句，比转到人工再问更省事。

两条路线怎么比：原文透传还是结构化交接单

2026年常见做法有两类。原文透传开发量小，适合坐席人数少、内部自用的场景；结构化交接单前期投入重，但可统计、可抽检、可脱敏，适合要出报表或有合规要求的项目。选择的关键不是技术难度，而是坐席日均接待量和是否需要跨系统协作。

• 开发量：原文透传经验区间约0.5到2人日；结构化交接单常见落在3到10人日，含字段定义与回写逻辑，字段多、要跨端复用时可能再多几天。
• 运行成本：差异主要在存储与坐席端渲染，经验区间每月从几十元到几百元不等，量级取决于会话量与留存时长。
• 隐私风险：原文透传可能把内部提示词、工具日志带进坐席可见范围，也容易被截图外传；交接单可以按字段脱敏。
• 可统计性：交接单能直接算复述率、摘要可读率、坐席编辑率；原文透传难以量化。
• 适用对象：原文透传偏向内部试用与小团队；交接单偏向对客且有人工工单流的业务。

如果只按一条标准来选，可以看转人工的日均次数和是否跨团队协作：次数少、坐席就在旁边，原文透传够用；次数上来、坐席要按历史判断处理方式，交接单的投入更容易收回。

适用场景与边界

适合做完整交接链路的情况是：转人工背后有明确业务动作，比如改单、退款、投诉升级；单次会话轮次偏多，坐席接手要多花时间问背景；以及已经有CRM或工单系统可以挂主键。这时把字段定清楚，收益是能直接看到的。

反过来，纯咨询型、单轮就结束的小工具，或者没有登录体系、拿不到用户主键的场景，不必急着上整套交接单。转接频次很低时也一样，如果一天转人工不超过几十次，完整链路的投入产出比通常不划算，先用一条固定话术让用户补一句关键信息更实际。

• 适合：多轮对话、有工单流、坐席需要按用户历史判断处理方式。
• 不必上：单轮问答、无身份体系、转接量很小的内部工具。
• 边界：拿不到稳定主键时，任何交接方案只能做到部分还原，不要对外承诺零复述。

常见问题

转人工的交接单，至少要有哪几个字段？

至少包括统一会话ID、用户身份主键、订单或工单锚点、二到四句摘要和未决诉求。少一项，坐席多半就要再问一次，交接的意义会被抵消。

摘要如果是模型写的，写错了算谁的责任？

摘要定位是辅助信息，不是结论。涉及金额、时效、承诺的内容以系统字段为准，摘要允许坐席编辑并回写，验收口径里也应写明它不作为处理凭证。

小程序、APP、H5都要转人工，怎么保证上下文不丢？

给每条会话一个跨端统一主键，登录态绑用户ID，未登录用设备标识加短时效令牌，转接时按主键取状态，比按渠道各存一份更稳。

这套东西验收时，看到什么算合格？

抽二三十到五十通转接会话，看坐席是否仍需用户复述订单号或诉求。复述率、摘要可读率和坐席编辑率可作抽检口径，具体阈值按业务约定。

落地顺序上，先定交接单字段，再改智能体提示词，最后接坐席工作台渲染，比反过来做返工少。如果当前只做单轮问答、没有身份体系或转接量很小，可以先不上这套链路；有工单流、坐席需要看历史的业务，再按四层把状态落到业务侧。