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.9 | 4.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 在真实场景里是像个靠谱的助手，还是像个只会复读“已转人工”的按钮。
最后留一个最实际的建议：先跑通单条会话的转人工流程，确认上下文、工单和坐席端都能正常工作；再逐步加入澄清、改写、自助路径等前置干预；最后再基于日志和指标去调阈值。这个顺序，能帮你避开大多数“转人工混乱”的坑。
