先这样答
上线的 Agent 一定有处理不了的情况，转人工要当一个正经功能设计，做四件事。第一，触发条件是确定的规则，不是模型「感觉不行」：模型自评置信低于阈值、用户明确要求人工、任务触发高危操作、同一步骤重试耗尽仍失败——满足任一就转。第二，转接带上下文：人工接手时看到的是对话摘要、已尝试过的方案、用户的关键诉求，而不是让用户从头再解释一遍。第三，边界清晰：转接生效后 Agent 停止自主行动，只做记录和整理，避免人和 Agent 同时对用户输出两套说法。第四，结果回流：人工最终怎么解决的，脱敏后进评测集，成为下一版改进的依据——转人工不只是止损，还是最便宜的数据来源。
设计目标要想清楚：不是「转得越少越好」。该转不转硬撑，用户损失和信任成本更高；目标是转得准（该转的都转了）、转得顺（用户不用重复解释）。
面试官会怎么追问
- 「置信度怎么估？模型自评可靠吗？」 自评不完全可靠，要和规则信号组合：用户反复改写提问、连续多轮纠错、任务卡在同一个步骤，这些客观信号比自评稳定。自评当参考，规则当触发器。
- 「人工响应慢，用户在排队期怎么办？」 预期管理要做好（明确告知排队和预计等待），同时 Agent 在排队期间继续处理可以自动化的部分，人工只接管真正需要决策的点，而不是全量接管。
- 「怎么衡量转人工设计得好不好？」 看一组组合指标：转接率、转接后的人工解决率、用户重复解释次数、Agent 单独解决率随版本的变化。只考核转接率会造出「不敢转」的 Agent，必须配上解决率一起看。
回答的坑
- 把转人工当失败指标。不敢转的 Agent 才是事故源，边界内诚实地转手是设计目标，把「零转人工」当 KPI 会逼着一线把问题捂住。
- 转接不带上下文。用户向人工重复解释一遍全流程，体验比不转还差——转接的上下文摘要和质量，和人能不能解决问题同样重要。
—— 本题完 ——