AI Agent 项目里最容易被低估的一个设计点不是模型选型也不是 Prompt 怎么写而是“什么时候转人工”。很多团队在第一版落地时会直接把“转人工”当成最后兜底Agent 答不上来就转人工多轮对话没进展就转人工用户表达有点模糊也转人工。这个思路看起来稳妥实际落地之后问题很多。这篇文章就围绕这个现象展开适合正在做 AI Agent 开发、智能客服系统、人机协同流程或者准备做 Agent 测试和面试复盘的同学看。我要先给一个核心判断AI Agent 不能一遇到问题就转人工不是因为“转人工”这个动作本身有错而是因为“一遇到问题就转”这个判断逻辑太粗暴。它会直接推高人工成本、打断用户体感、让 Agent 失去持续优化的机会。真正应该做的是设计一套分级处理机制把“转人工”从逃生通道改造成有条件的升级机制。1. 先把“转人工”拆开看为什么它是兜底方案不是终点1.1 很多团队的第一版实现其实只有一句话我见过不少项目的第一版代码逻辑非常简单。Agent 识别用户意图如果置信度低于某个阈值就返回一句“正在为您转接人工客服”。有的甚至连阈值都没有只要大模型回答里出现了类似“我不确定”的表达就触发转人工。这种实现最直接的问题是Agent 把“我不确定”当成了“我解决不了”。但实际场景里“我不确定”的原因很多用户表达不完整比如只说了一个关键词用户用词和知识库里的标准问法不一致用户的问题需要多轮信息才能确定但 Agent 没有追问用户当前处于负面情绪中表达混乱知识库里明明有答案但召回逻辑没找到当前上下文缺失Agent 缺少前几轮的会话信息。这些情况绝大多数可以通过澄清、重新召回、改写问题、补充上下文来解决。直接转人工等于把所有问题都推给了人工坐席。1.2 被忽视的三个代价第一个代价是用户体感中断。用户正在自助解决问题的流程里突然被切到人工意味着要重新描述问题、等待排队、可能还要重复提供订单号或账号信息。这个过程非常消耗耐心。哪怕最终问题解决了用户对产品的评价也会明显下降。第二个代价是人工成本。人工坐席资源是有限的。如果转人工率被粗暴触发拉高人工团队会不断处理大量本可以由 Agent 完成的基础问题。团队很快会陷入两种状态要么增加人力成本要么排队时间变长导致用户投诉。无论哪一种都是项目不可持续的信号。第三个代价是数据断裂。用户被转人工之后Agent 侧只留下一句“已转人工”后续人工坐席怎么解决的用户是否满意问题属于哪个类别Agent 完全不知道。这意味着 Agent 失去了最重要的学习样本。想做后续优化时会发现所有转人工记录里只有原因没有结果没有可复用的答案。1.3 先建立一组可量化的判断指标讨论“要不要转人工”之前先要有一组指标不然全是主观感受。我建议至少关注这几个指标含义需要警惕的信号转人工率触发转人工的会话数 / 总会话数突然升高或高于同类业务基线人工一次解决率用户首次接入人工后问题是否解决转人工率高但解决率低说明转接质量差用户重复联系率同一用户短期内再次发起会话升高说明首次处理没真正结束问题人工坐席平均处理时长人工处理一个会话的耗时升高说明上下文传递不足坐席在重复询问用户满意度会话结束后的评分或评价转人工流程处明显低于纯自助流程有了这些指标再讨论什么时候该转人工才不会变成“我觉得应该转”“我觉得不应该转”的争论。2. Agent 想转人工的时候系统里到底发生了什么2.1 触发转人工的原因需要分类不能混在一起我在实际项目里会把转人工触发源分成五类每一类的处理方式完全不同。第一类是意图识别低置信度。用户的问题经过意图识别后最高分意图的置信度低于阈值。这类问题最值得优化因为可能只是表达方式不在知识库覆盖范围内。第二类是多轮对话失败。Agent 已经追问过几轮但用户提供的信息一直无法匹配到可用答案。这类问题需要重点看澄清策略是否合理不能无限追问。第三类是用户主动要求人工。用户直接说“转人工”“找人工”“我要投诉”。这类情况应该优先尊重用户意愿不适合强行把用户留在自助流程里。第四类是高风险或敏感操作。涉及资金、隐私、账号安全、法律风险等场景即使 Agent 能处理也应该有人工确认环节。这类转人工不是能力不足而是流程要求。第五类是规则限制。某些业务只有人工坐席有权限操作Agent 本身就不应该尝试处理。很多团队的问题在于无论属于哪一类都走同一个转人工分支。这会导致两类典型故障。一类是本该转的不转比如用户已经明确要求人工Agent 还在反复澄清另一类是不该转的乱转比如用户只是换了一种问法Agent 就放弃了。2.2 判断转人工的核心参数下面这些参数不同项目差异很大这里给的是通用参考。实际落地时要根据业务场景和历史数据调整不能直接照搬。参数说明常见初始值判断逻辑意图置信度阈值低于该值触发低置信度流程0.4 到 0.5不是直接转人工而是进入澄清流程澄清最大轮数单轮澄清不得无限进行2 到 3 轮超过后仍未满足条件再考虑转人工负面情绪分数阈值识别用户情绪状态0.7 以上触发预警只作参考不单独决定是否转人工未解决标记次数同一会话内重复表达无法解答2 次配合澄清轮数和意图置信度一起判断人工坐席可用性当前排队人数和平均等待时间按团队资源设定人工不可用时应提示用户稍后回访这里容易被忽略的是不要用单一参数做转人工决策。比如意图置信度低未必需要转人工可以先走一轮澄清但如果连续三次澄清都失败同时用户情绪分数偏高这时候再触发人工理由才足够充分。2.3 转人工之前先看会话上下文是否完整我排查过很多“莫名其妙的转人工”案例最终发现答案不在模型层而在上下文。有的用户进入会话时Agent 没有拿到用户ID导致无法查询订单状态有的会话经过多个系统跳转前几轮的槽位数据已经丢了。在这种状态下即使知识库有完整答案Agent 也无法找到可以参考的实体信息。所以在设计“是否转人工”的判断逻辑时要额外加一个上下文完整性检查。比如用户要查询订单状态但会话里没有任何订单号或用户身份信息Agent 先要做的是补齐信息而不是直接判定为无法解决。3. 转人工之前先让 Agent 把这几件事试完3.1 第一件事主动澄清而不是立刻放弃用户第一次表达不清楚时不要直接判定失败。我一般会先做一次澄清把用户的问题换个说法重复一遍同时给出几个常见选项让用户确认。举个电商场景的例子。用户说“我要退款”这个表述并不完整。Agent 不应该直接回复“无法理解您的意思”更不应该转人工。可以先反问您是要申请退款还是查询退款进度如果是申请退款需要确认订单号和商品问题如果是查询进度需要提供订单号。这一轮澄清的价值有两个第一通过选项缩小用户真实意图的范围第二让用户感觉 Agent 在主动解决问题而不是复读机式地提示“请换个说法”。3.2 第二件事换一种召回方式而不是只靠向量检索很多 Agent 项目使用向量检索从知识库召回答案。向量检索的问题在于用户问题如果和知识库中的标准问法差距过大召回分数就会偏低最终导致“找不到答案”的判断。这时候最好的做法不是直接放弃而是换一种召回方式。比如把用户问题改写为标准问法再重新检索或者同时使用关键词检索和向量检索做结果融合再或者从知识库中提取标签用标签匹配兜底。有一类常见问题是用户用口语化表达业务名词。比如知识库里写的是“售后服务”用户说的是“售后找谁”“有问题找谁”“客服在哪”。如果 Agent 只做字面匹配很难命中。但如果提前配置了同义词表或者用大模型对用户问题做一次标准化改写召回结果会完全不同。3.3 第三件事结合上下文重写用户问题用户在多轮对话里的下一句话往往依赖前文信息。直接把用户最新一句当作完整问题去做语义理解很容易误判。更好的做法是把最近几轮对话整理成会话摘要再把用户当前问题放到摘要上下文中重新理解。比如用户问“那这个怎么收费”如果脱离上下文Agent 根本不知道“这个”指什么。但在前文里用户已经问过某个具体功能的开通方法Agent 就能推断出“这个”指的是该功能。这个能力不一定要单独写一套复杂的状态管理模块。很多场景下只要在调用模型做意图识别时把前两轮的用户输入和 Agent 回复拼接进去准确率就会提升不少。对已经用到大模型的项目来说这是一个成本低、收益明显的优化点。3.4 第四件事给用户一个自助替代路径如果 Agent 确实无法直接解决问题不要只抛出一句“转人工”或“暂时无法处理”。可以先给用户一条可执行的自助方案。比如提供官网操作指引、帮助文档链接、问题反馈表单或者告知用户需要准备哪些材料再联系人工。这一步的目的是把“失败体验”转换成“等待中的进展”。用户至少不会觉得自己被晾在一边。同时它也能过滤掉一部分其实不需要人工介入的问题。3.5 为“预转人工”阶段建立诊断日志我比较建议在进入转人工流程之前增加一个诊断日志模块把触发转人工前的信息都记录下来。包括当前意图及置信度、澄清了几轮、用户是否重复表达、命中了哪些知识点、有哪些知识点差点命中、上下文是否完整、用户情绪分数。这些日志的价值在后续测试和优化时非常大。想降低转人工率不能靠猜要看日志里最多的问题是哪个类别。如果 60% 的转人工都是因为“用户表述过短导致意图识别失败”那就去优化澄清策略如果大部分是因为“知识库没有覆盖”那就去补知识库而不是盲目调阈值。4. 确定要转人工了怎么交接才不丢上下文4.1 转人工不是传一句话而是传一份结构化交接单真正到转人工这一步时很多系统只做了一件事把用户当前这句话发给人工坐席。结果人工坐席看到的是“我要退款”四个字不知道用户是谁、订单号是多少、之前 Agent 问过哪些问题、用户有没有已经提供过关键信息。正确做法是生成一份结构化交接单。至少包含以下内容用户标识用户ID、手机号或订单号会话摘要用户最初的问题、Agent 已经确认的信息、未确认的信息已尝试方案Agent 做过哪些澄清、查过哪些知识库、给出过哪些建议触发转人工的原因属于低置信度、多轮失败、用户主动要求、高风险还是规则限制优先级或紧急程度比如账号安全类问题需要优先接入用户当前情绪状态如果检测到明显负面情绪需要提示人工坐席。4.2 技术上的交接方式要看现有系统如果项目用的是第三方客服平台、工单系统或自研坐席工作台转人工的对接方式会不同。常见做法有三种。第一种是走 API 创建工单。Agent 在判断需要转人工后将格式化好的交接单通过接口提交到人工系统生成一个工单用户侧显示“已为您创建工单客服会尽快处理”。这种方式适合异步处理场景。第二种是走 Webhook 实时通知坐席。Agent 把交接单推送到坐席工作台坐席可以直接看到上下文并开始回复。这种方式适合实时文字客服。第三种是用户端无缝切换。通过 SDK 或前端状态同步把会话历史、用户身份、问题标签直接带到人工会话界面。用户不需要重新描述问题坐席也能看到之前的对话记录。不管用哪种方式都要在设计阶段明确一个问题人工坐席看到的上下文能不能支撑他直接开始处理。如果还需要从头问一遍订单号说明交接设计不达标。4.3 伪代码示例转人工前的信息汇总下面是一个简化的伪代码示例展示转人工前如何汇总信息。不同项目的数据结构会有差异这里只说明思路。def build_handoff_context(session, user, intent_result, clarify_logs): return { user_id: user.id, user_phone: user.phone, order_id: session.get_slot(order_id), problem_type: intent_result.predicted_intent, confidence: intent_result.confidence, clarify_rounds: len(clarify_logs), clarify_logs: clarify_logs, attempted_answers: session.attempted_answers, trigger_reason: analyze_trigger_reason(session, intent_result), urgency: detect_urgency(session), emotion_score: session.emotion_score, summary: generate_session_summary(session) } # 当确认需要转人工时 context build_handoff_context(session, user, intent_result, logs) create_ticket(user.id, context) notify_human_agent(context)这个 JSON 结构不复杂但它解决了一个很关键的问题人工坐席不再需要从零开始理解用户诉求。4.4 转人工后的反馈闭环很多人忽略转人工后的数据回流。人工坐席处理完问题后应该把最终处理结果、解决方案、问题分类回填到系统里。这些数据可以用于补充知识库优化意图识别训练集分析哪些转人工是可以避免的评估 Agent 在“转人工前干预”环节的效果。没有反馈闭环转人工就真的成了“一锤子买卖”Agent 永远不知道自己哪里做得不够。5. 不轻易转人工的效果怎么用测试和数据验证5.1 先准备一组覆盖典型场景的测试用例想验证“不轻易转人工”的策略是否有效不能只看几个手工对话示例要做成可回归的用例集。我一般会先准备这些类型正常提问用户用标准问法提问应该直接命中答案模糊表达用户只说关键词或口语化表达应该触发澄清后命中同义改写用户用不同说法表达同一个意图应该能识别缺少关键信息用户没有提供订单号/账号应该主动索要多轮追问用户在追问中省略主语应该结合上下文理解用户主动要求人工应该尊重用户需求尽快转人工高风险操作应触发人工确认流程知识库外问题应进入替代路径或转人工情绪激烈表达应走情绪安抚流程必要时优先转人工。每个用例要记录预期行为和实际行为。这样跑回归测试时才能批量发现哪些改动影响了哪些场景。5.2 做策略改动前先记录基线数据任何优化都不应该在改完代码之后才开始看数据。正确的顺序是记录当前版本的转人工率、澄清后的解决率、人工一次解决率、用户满意度分析当前转人工记录确认优化方向在测试环境跑带标签的用例集小范围灰度发布对比测试组和对照组的数据确认正向效果后再全量发布。下面是一个简化的对比表格用来观察策略调整后的变化。这里的数值只是示意不是标准结果。指标调整前调整后说明转人工率35%22%下降了 13 个百分点澄清后解决率30%42%说明澄清策略有效人工一次解决率68%74%转人工的用户问题更明确用户满意度3.94.2自助解决率提升体感更好平均人工处理时长6 分钟4.5 分钟上下文交接更完整需要强调的是转人工率下降不是最终目标。如果转人工率下降了但用户重复联系率上升了或者人工一次解决率下降了那说明 Agent 在用“话术硬扛”用户的合理需求。这种情况比高转人工率更糟。5.3 转人工率不是越低越好要分场景设目标不同业务场景的合理转人工率差异很大。比如高频简单咨询类业务转人工率可以控制在很低的水平涉及复杂售后、投诉、账号安全类的业务就不能为了追求低转人工率而强行阻断人工通道。我见过一个比较理性的做法按问题类型分别设置转人工率目标。查询类目标低于 10%投诉类不做硬性控制更关注最终解决率。这样既不会给 Agent 团队设一个不合理的指标也不会让用户体验受损。5.4 用日志定位“最不该转却转了”的场景复盘时不要只看总量要把转人工记录拆开看触发原因。我一般会按下面这个规则排序优先处理成本最高的场景用户主动要求人工但坐席无法满足核心诉求的Agent 在没有任何澄清和干预的情况下直接转人工的转人工后人工坐席发现答案就在知识库里的同一用户短期内多次转人工的高风险场景正确触发转人工的。前两类是明确的优化机会第四类往往说明用户的问题没有被根治。把这些记录攒下来就是一份很有价值的产品改进清单。6. 实战中会踩的坑以及我的排查顺序6.1 用户反复问Agent 却一直不转人工这是和“一遇到问题就转人工”相反的问题。Agent 陷入反复澄清的循环用户已经明显不耐烦了系统还在让用户“换个说法”。这种情况通常有两个原因。一是澄清轮数设得太高比如允许澄清 5 次以上。二是缺少用户主动要求人工的快速通道。用户可能已经输入“算了”“转人工”“我要投诉”但系统仍然没识别出转人工意图。排查时先看日志里的澄清轮数再看用户最新的几条输入。如果用户已经明确表达了负面情绪或人工诉求直接把人工通道打开比任何模型优化都重要。6.2 转人工率突然飙升先看是不是上游数据出了问题一个稳定运行的系统转人工率通常比较平稳。如果突然飙升不要急着调模型参数先按这个顺序排查看知识库最近是否更新了大量内容导致旧答案失效看接口用户身份、订单查询等依赖的下游接口是否超时或报错看模型服务意图识别服务或大模型服务的响应是否正常看 Prompt最近是否改过系统 Prompt导致回答风格或判断逻辑变化看会话上下文是否存在槽位信息丢失导致 Agent 拿不到关键信息看日志触发转人工的分布集中在哪个意图类别。很多次转人工率异常最后发现不是 AI 能力问题而是依赖服务波动。排查顺序搞反的话会在错误的方向上浪费很多时间。6.3 转人工后坐席看不到完整上下文人工坐席抱怨“用户进来后我还要重新问一遍”这是上下文交接设计的问题。排查时重点看交接单里有没有携带用户标识前几轮的槽位数据是否同步到工单或坐席工作台触发转人工前的澄清和尝试记录有没有展示给坐席用户侧是否重新出现了“为了安全请重新验证身份”的流程。要记住转人工只是把处理权交给人工不是把“用户理解成本”也交给人工。上下文传递不完整人工坐席的处理效率不会比 Agent 高多少。6.4 参数调优建议一次只动一个变量很多团队在调转人工策略时会同时调整置信度阈值、澄清轮数、情绪阈值、知识库内容。结果效果变好了不知道是谁的功劳效果变差了也不知道该回滚谁。更稳妥的做法是一次只调整一个变量并且通过 A/B 测试确认效果。比如先增加“意图低置信度时主动澄清一轮”观察转人工率和澄清后解决率的变化。确认有效后再考虑增加第二轮澄清的限制条件。批量调整适合在已经积累了较多日志、能做出较准确判断的阶段进行不适合在项目早期做。6.5 给 Agent 开发者的最终建议如果你正在做 AI Agent 实战项目不管是智能客服、内部知识助手还是业务引导系统我都建议在架构设计阶段就考虑转人工机制而不是等项目上线后再补。“转人工”不是一个 if 分支而是一条完整的流程包含触发判断、前置干预、上下文汇总、人工交接、结果回流。它的设计质量直接决定了 Agent 在真实场景里是像个靠谱的助手还是像个只会复读“已转人工”的按钮。最后留一个最实际的建议先跑通单条会话的转人工流程确认上下文、工单和坐席端都能正常工作再逐步加入澄清、改写、自助路径等前置干预最后再基于日志和指标去调阈值。这个顺序能帮你避开大多数“转人工混乱”的坑。