Agent 高频题 17. 意图识别和路由：怎么分、交给谁、分错了怎么办
1. Agent 高频题 17. 意图识别和路由：怎么分、交给谁、分错了怎么办
携程一场 Agent 一面连着问：基于用户意图的路由机制是怎么工作的？路由准确率怎么样，识别错了有什么处理机制？用户一句话里有多个意图，系统怎么处理？
迅雷一场 Agent 一面开头就问：你们怎么知道意图分得对，有没有量化指标？用户两次问法差不多，实际意图却不一样，怎么判断出来？
汇川一场数字化全栈一面问到架构演进：为什么后来去掉了最初的分类器？没有分类器，模型怎么知道往哪个方向查？最初的方向走偏了，靠什么拉回来？同一位作者十月发的另一场面经里，面试官也问：为什么取消独立的分类器，改成把各类沉淀成 Skill 动态挂载？
这是 Agent 高频面试题单第 17 题的详解。题单里这题是 26 位作者、29 场面试，标的是「分布很散」。这次和第 12 到 16 题一样，重读库里记过的牛客链接，共 516 篇。按意图、路由、分发、分类器、多模型、澄清、口语化、错别字这些词找出 98 篇，按分类、识别、兜底、置信度、调度、客服这类词又找出 262 篇，逐条读过，再用信息不全、直接回答、复杂度、备用模型这类词扫了一轮补漏。去掉的有前端路由（Vue Router、动态路由）、网络的路由表、Redis 的槽位、Spring 的 DispatcherServlet、面试末尾的闲聊和反问，还有只问基座模型选型的；只问工具多了怎么选对的归第 24 题。剩下问到这道题的有 57 场、46 位作者。追问分十一个方向（按作者数，一场可以算进几类）：
问得最多的是意图识别用什么做，其次是交给谁、怎么证明分得对。公司确实散：字节 7 场，美团 6 场（另有一篇美团和阿里写在一起的），百度、腾讯、快手各 4 场，其余 31 场分散在二十多家公司。
这题和前几题有交叉。第 3 题讲派给哪个子 Agent 时说过，意图识别和路由的细节留到这一题；模型分层的依据第 12 题讲过，Skill 的描述怎么写、触发评测怎么做第 8 题讲过。这里讲中间这段：一句话进来，怎么判断它要什么、该交给谁，分错了怎么发现、怎么兜住。
[!abstract] 速览
意图识别回答「用户要什么」，路由回答「交给谁处理」。类别按处理方式分、不按话题分；识别用规则、小模型、大模型级联，拿不准就追问或转人工。评测要分层抽样，按类看精确率和召回率，越界单独算；分错了每一层都要留出口。入口分类器可以拿掉，分流挪到 Skill 和工具的描述、系统提示词、Harness 的硬规则里。
1.1. 先说清楚：识别什么、交给谁
1.1.1. 识别是为了分流
意图识别回答「用户要什么」，路由回答「交给谁处理」。面经里常见的是前一句问意图识别，后一句就问路由，因为识别出来的结果，主要就是用来决定这次请求往哪走。
Anthropic 在《Building effective agents》里把路由列为一种 workflow：先给输入分类，再交给专门的后续任务。分开以后，每条路可以写自己的提示词；不分开，为一类输入调好的提示词，可能让另一类变差。它也写了适用条件：类别确实不同、分开处理更好，而且分类本身能做准，用大模型或传统分类模型都可以。举的例子一个是客服，一般咨询、退款、技术支持走不同的流程、提示词和工具；另一个是按难度分模型，简单常见的问题给小而便宜的模型，难的、少见的给更强的模型。
1.1.2. 路由的目的地
同一个请求往往要分好几次：是不是业务问题，哪一类业务，查接口还是检索，用哪个模型答。每一次分流都可能出错，前面错了，后面很难救回来。
1.1.3. 判断放在哪
常见三种放法：
| 放法 | 怎么做 | 谁这么做 |
|---|---|---|
| 入口先分 | 一个路由节点或分类器先判，再交给对应分支 | LangGraph 的条件边、Dify 的问题分类器节点 |
| 交给主模型选 | 把各个 Skill、工具、子 Agent 的说明给主模型，它在循环里决定调谁 | Claude Code 靠描述选 Skill 和子 Agent；OpenAI Agents SDK 里，转交给另一个 Agent 在模型看来就是一个工具，名字类似 transfer_to_refund_agent |
| 混合 | 确定的信号由代码先判，剩下的交给模型 | 代码先判命令、订单号、风控名单、系统状态 |
三种放法的取舍在第七节。第二到五节先讲入口分流要定的几件事：类别、识别方法、难的输入，以及多意图和越界。
面试常问：意图识别是怎么做的，链路是什么？用户的自然语言一路调配到接口，完整流程讲一下。用户提问以后，从接收输入、识别意图、选处理路径，到调用 Skill、组织结果，系统按什么顺序执行？
1.2. 类别怎么定
1.2.1. 按处理方式分，不按话题分
Claude 文档的工单路由指南写的是：路由效果和类别定义得好不好成正比。
可以这样判断：两个类别如果最后交给同一个处理者，用同样的工具和权限，就合并；一个类别里如果有两种需要不同处理方式的请求，就拆开。按话题分（物流、售后、账户），常常把风险完全不同的请求放进同一类。
我在《FDE 面试题 01》的题解里，给一家 200 人电商的 AI 客服分过四层工单：L0 查询（物流进度、商品规格、包邮门槛），规则清楚，机器可以直接答；L1 操作（改地址、催发货、补发票），要写后台；L2 协商（特殊退款、破损补偿、客诉升级），涉及裁量，要留痕；L3 风险和冲突（情绪宣泄、维权威胁、舆情），第一时间转人工。这四层是按谁能处理、错了代价多大来分的。同样跟钱有关，问包邮门槛在 L0，特殊退款申请在 L2。
除了意图，分流还要看别的维度。工单路由指南提醒，紧急程度、客户类型、SLA、语言都会影响分给谁。这些最好作为单独的字段输出，不要和意图揉成一个标签。
1.2.2. 分层
快手一场效果营销日常二面问：两层意图识别具体怎么设计？
类别多了，分类器要在几十类里挑，提示词里的定义和例子越来越长，相近的类也越来越多。工单路由指南的办法是：超过 20 个类别时，把意图组织成一棵树，每一层一个分类器，逐层往下分。好处是每条父路径可以用自己的提示词，判得更细；代价是多一层就多一次调用的延迟，所以它建议每层用最快的模型。
小厂一场 Agent 开发一面里，候选人讲的就是两层：第一层是检索路由，规则前置、小模型、规则兜底，把问题分成检索、闲聊、综合三类；第二层只处理检索类，用小模型按问题结构再分（简单问答、并列、链式、聚合、综合、元对话、越界拒答），分发到不同的工作流。
[!warning] 错误会相乘
第一层准确率 95%，第二层也 95%，两层都对的只有约 90%。第一层分错了，请求就进了错的分支，第二层只能在错的类别里挑。所以第一层的类别要粗、要好分，拿不准的不硬分，留给下一层或者兜底分支。
1.2.3. 抽象
腾讯一场社招三面问：为什么抽象化以后，意图识别的效果更好？
面经里没写候选人怎么抽象的。通常的道理是：用户的说法无穷多，系统能做的动作有限。按系统的动作定义意图（查订单、改地址、退款），具体对象放进参数（哪个订单、改到哪里），类别就少了，边界也清楚了。「查北京天气」和「明天上海会不会下雨」都是查天气，城市和日期是槽位。类别少、彼此好区分，分类器容易学，标注也容易一致。
1.2.4. 标签从哪来，类别怎么变
FDE 那道题里有一条约束：历史工单的分类标签打得乱七八糟。所以第一周先抽 200 条，自己按 L0 到 L3 打标；再从历史工单里抽 50 条做评估集，每条标上是否该转人工，其中混入 10 条退款例外或纠纷类的负例，检验模型能不能主动拒答。线上已有的标签不能直接当标准答案。每个类别写一段定义，附几条正例，再附几条最容易混的反例。
类别会变，新业务上线就要加类。加了新类，原来落在相邻类别的请求可能被它抢走，所以每次改定义，都要把整个评测集重跑一遍，不只跑新类的样例。
面试常问：两层意图识别具体怎么设计？为什么做了抽象，意图识别效果就更好？
1.3. 用什么分：规则、小模型、大模型
B站一场 AI 应用 Agent 开发一面连着问了四句：意图识别有哪些实现方式？规则匹配、小模型分类和 LLM 分类分别适合什么场景？用大模型分类时，Zero-shot 和 Few-shot 怎么选？标注数据少时，怎么提升分类的稳定性？快手一场 AI 全栈二面问：意图识别用的是规则、小模型，还是直接用主模型？为什么？
1.3.1. 四种做法
四种做法是规则和关键词、向量相似度、小模型分类、大模型 zero-shot 与 few-shot，要准备的东西、快慢和成本、改类别的代价、各自的弱点都不一样。Semantic Router 这类库走的是第二种：每条路由配一些例句，请求进来，比较它和各条路由在向量空间里的距离，毫秒级做决定，不用等一次大模型生成。
工单路由指南列了什么时候用大模型更合适：标注数据少，几十条带标签的样例就能起步；类别会变；输入是非结构化的文本；类别靠语义条件定义，不是靠关键词；需要说得出分类理由；边界模糊的请求多；要支持多种语言，又不想每种语言训一个模型。把这份清单反过来读：类别稳定、标注充足、量大、要求毫秒级响应的入口，小模型更合适。
1.3.2. 级联
实际系统常把几种叠在一起。小厂那场的检索路由是规则前置、小模型、规则兜底。浩鲸和影石两场面经出自同一位作者，候选人讲的是：先做意图分类，再按意图和关键词从工具白名单里粗召回一批候选，最后让大模型在候选里选。
[!tip] 级联的顺序
- 规则先拦确定的：命令、订单号、明确的关键词、风控名单。
- 小模型或向量判大多数，同时给出置信度。
- 置信度不够的交给大模型。
- 大模型也拿不准的，追问用户或转人工。
便宜的放前面，扛大部分流量；贵的只处理少数难例。
字节一场前端二面考 AI Coding 题，候选人介绍了用关键词匹配给用户反馈做预清洗，关键词的缺陷很快暴露出来；候选人说改用 LLM 判断，面试官追问：LLM 成本高呢？候选人和 AI 一起得出的结论是设计置信度指标。级联要回答的就是这个问题：哪些交给便宜的，哪些值得花钱，按什么划线。
1.3.3. 用大模型分类，几个要点
- 先写清类别定义。Dify 的问题分类器节点，每个类别有一段描述，模型读这段描述来选分支。它的文档建议描述写得彼此能区分，类别有重叠时加上「凡是和……有关的」「不包括……」这类边界说明。
- 再决定给不给例子。工单路由指南说，给例子是提升效果最有效的办法。边界能用文字说清的，zero-shot 也能用；边界要靠例子才说得清的（什么算投诉，什么算咨询），就上 few-shot，例子优先选边界上的。例子多到塞不下时，指南建议用向量库检索和当前请求最相近的例子，再放进提示词，它引用的分类示例里，准确率从 71% 提到了 93%。
- 输出收紧。只允许输出给定的类别，加一个「其他」，再加置信度或一句理由。结构化输出第 22 题讲。
- 标注少时求稳。同一批请求多跑几次，看结果一致不一致；不一致的地方，就是该补定义或例子的地方。工单路由指南把分类一致性列成指标，建议拿一批固定输入定期测，目标 95% 以上。
1.3.4. 小模型怎么选
腾讯一场 AI 全栈一面问：意图分类模型和 query 改写模型是怎么选的，对比过其他模型吗？对比是定量实验还是主观感受？为什么用 Qwen 2.5 系列，意图分类用 0.5B 量级，参数规模怎么考虑的？
答法是拿同一份带标签的测试集说话。规则基线、0.5B、更大一档的模型、大模型 zero-shot 各跑一遍，比每类的准确率、P95 延迟和单次成本，在满足准确率要求的方案里选最快、最便宜的。0.5B 够不够，取决于类别多少、难不难分，参数量本身说明不了什么。
1.3.5. Jev 和 BERT
字节一场后端一面问：怎么看 Jev，它和 BERT 有什么区别，对你的 Agent 有什么用？
我九月写过 Jev。BERT 是 2018 年的预训练模型，做分类要加输出层、拿标注数据微调，一个任务训一次。Jev 是 TypeSafe 九月发布的判断模型，不靠自由文本续写来组织答案：开发者交进一段状态和一个范围有限的问题，它返回各个选项的概率；选项用文字描述，不用为每个任务训练。我那篇里举的例子就是分流：用户写「连续扣了我两次钱，请退回重复的一笔」，程序同时问归哪个部门、有没有明确要求退款、优先级多高，再决定进哪个流程。
限制也要一起说。截至九月，它只收文本，英文表现最好；官方自己列的缺陷里有否定和隐含意图可能理解错；它返回的 confidence 是按答案分布算出来的统计量，不能直接当成这一次答对的概率。一个公开的钓鱼邮件测试里，直接下结论时 Jev 的准确率是 62.6%，Haiku 4.5 是 81.3%，而简单的正则规则已经做到 91.8%；改成让模型分别提取几个风险信号、再用逻辑回归组合，两者分别到 95.0% 和 93.2%，差异不显著。这组数字来自测试作者，我没有复跑。它说明两件事：规则、小模型、判断模型、大模型要放在同一份测试集上比；把一个大判断拆成几个小信号，有时比换模型更管用。
1.3.6. 会不会太慢
小厂那场还问：意图识别用模型，会不会导致识别耗时过长？候选人用 Langfuse 做了全链路测试（面经里写的是 LongFuse），意图路由那一段耗时不长。
前置的识别排在首 token 前面，第 16 题第七节讲过怎么处理：先量，再让它短（小模型、只输出一个标签、不开思考或用低 effort），能合并的合并，能和检索并行的并行。工单路由指南推荐用 Haiku 5.5 的 low effort 做这类分类。
面试常问：意图识别有哪些实现方式，规则、小模型分类、LLM 分类各适合什么场景？用大模型分类时 Zero-shot 和 Few-shot 怎么选，标注少时怎么让分类稳定？意图识别用规则、小模型还是主模型，为什么？意图分类和改写的模型怎么选，对比过别的吗，为什么用 0.5B？Dify 的分类器节点用大模型做分类，讲讲？关键词匹配有缺陷，改用 LLM 又贵，怎么办？怎么看 Jev，它和 BERT 有什么区别？技术类客诉怎么做前置分类和分流？意图识别用模型，会不会太慢？
1.4. 难的输入：口语、错别字、歧义、信息不全
1.4.1. 口语化和错别字
字节一场 Agent 开发后端日常实习一面问：用户问题口语化、有错别字或意图不明确时，怎么处理？小鹏一场 AI 全栈培训生一面问：大模型是怎么解决意图识别里的模糊问题的？原理是什么？
大模型对错别字、口语和换说法通常比规则和小模型稳。它在大量真实文本上预训练过，「退货」「退掉」「不想要了」在它那里意思相近；它还能读到对话上下文和你写在提示词里的类别定义，按语义而不是字面去对。小鹏问的原理可以这样答，但要补一句：模型不会自己知道没把握，拿不准时也可能给出一个看起来很确定的答案，所以后面还要有置信度和追问。
规则和小模型那一路，可以在前面加一层归一化：纠错、同音字和拼音、繁简和全半角、常见缩写。用户原话要保留，归一化的结果只拿来识别，不要用改写后的句子替换原文往下传，改写也可能改错意思。训练小模型时，可以往数据里加错别字和口语的变体。
还有两种容易判错的输入，工单路由指南都提到了。一是隐含诉求，比如「我的包裹等了两周多了」，其实是在查物流。二是情绪压过诉求：用户火气很大时，模型可能先去回应情绪，忘了判断用户要什么。办法是在提示词里给这类例子，说明判断意图时先不看情绪。情绪本身可以作为另一个字段单独判，FDE 那套里情绪冲突属于 L3，直接转人工。
1.4.2. 多轮里的指代
「那个也退了吧」「还是寄到上次那个地址」，只看这一句判不出意图，要看前几轮。做法是识别之前，用最近几轮把这句改写成能独立看懂的问题，或者直接把最近几轮一起交给分类器。检索前的改写第 1 题讲过，这里是给识别用的。
1.4.3. 歧义：同样的话，不同的意图
迅雷那场问：用户两次问法相似，但实际意图不一样，怎么判断出来？字节一场一面问搜索里的意图消歧：同一个查询词可能对应成语、电影、歌曲等不同对象，怎么判断用户真正想找什么？除了语义检索，还能结合哪些信息？
只看句子分不出来时，就要加句子以外的信息：
- 入口和页面：从订单详情页进来问「怎么退」，多半指这个订单。
- 用户状态：有没有进行中的订单，是不是刚付完款，上一次工单是什么。
- 对话历史和个人习惯：前几轮在聊什么，平时搜什么。
- 当下的热度：最近是不是有一部同名电影刚上映。
这些信息该由代码查出来，作为字段交给分类器，不要让模型去猜。还是分不开时，搜索可以把几种解释的结果混排，让用户点；办事就追问。
1.4.4. 意图不明确：追问还是猜
看两件事：有多少把握，猜错了代价多大。
| 情形 | 做法 |
|---|---|
| 只读、可撤销的（搜索、查询） | 先按最可能的意思做，同时给出别的选项 |
| 有副作用的（退款、转账、删除） | 拿不准就确认，不猜 |
| 追问本身 | 一次只问一件事，尽量给选项让用户点 |
| 追问的上限 | 小厂那场问数平台的做法：时间、区域、指标口径三项缺了，就引导用户补齐再检索，用大模型追问一次，还不行就不再重试，也不触发检索 |
Rasa 的 FallbackClassifier 是一个现成的参照：最高的意图置信度低于阈值，或者前两名的置信度差得太近（小于 ambiguity_threshold），都判成兜底意图，再接一条请用户换个说法的规则。后一种情况值得单独处理：两个类别差不多时，与其硬选一个，不如问用户是哪一个。
1.4.5. 信息不全：补参数
美团一场 Agent 一面问：用户输入的信息不完整，系统怎么校验、补全参数并继续执行？哪些参数必须用户确认？残缺信息没法唯一确定资源时，系统怎么选？
这是传统对话系统里的填槽。补的顺序：
- 从对话里找：前几轮说过的地址、订单号。
- 从系统里查：「我上一个订单」就查最近的订单，唯一的就直接用。
- 用默认值：只限不影响结果的参数，比如每页条数。
- 问用户。
必须用户确认的，是决定副作用和钱的参数：金额、收款方、收货地址、要删除的对象。查出多个候选时，列出来让用户选，写操作不替用户挑。参数校验失败怎么回给模型，第 11 题讲过。
面试常问：用户的问题口语化、有错别字或意图不明确，怎么处理？大模型怎么解决意图识别里的模糊问题，原理是什么？两次问法差不多、意图却不同，怎么区分？同一个查询词可能是成语、电影或歌曲，怎么判断用户想找哪个，语义检索之外还能用哪些信息？用户给的信息不完整，系统怎么校验、补全参数，哪些必须让用户确认？残缺的信息定位不到唯一的资源，系统怎么选？
1.5. 多意图、闲聊和越界
1.5.1. 一句话多个意图
携程那场问：遇到用户多意图请求，系统怎么处理？腾讯一场社招二面问：线上跑的话，用户的提问大部分会落到多意图吗？
先分清两种情况：
- 一个意图、多个参数：「查一下北京和上海的天气」是一个意图，两个城市。
- 真的多个意图：「这件退了，再帮我买一件大一号的」是退货和下单两件事，而且有先后。
真多意图要拆成子意图，标出依赖：互不依赖的可以并行；有先后的按顺序做，相当于一个小计划（第 14 题）；互相冲突的，比如同时要取消订单又要改地址，问用户。实现上，小模型用多标签分类，每个类别单独判是或否，不要只取概率最高的那一个；大模型直接输出一个意图列表，每个带上对应的原文片段。工单路由指南也提到，一次请求里有多个问题时，模型可能分不清主次，要在提示词里写明意图的优先级，让它排出主要诉求。
线上到底有多少多意图，要拿日志统计。论文里的比例不能直接用：多意图研究常用的 MixATIS、MixSNIPS 两个数据集，是把单意图的句子用「and」这类连词拼起来造的，MixSNIPS 还有意让含一个、两个、三个意图的句子按 3:5:2 配比。在 MixSNIPS 里，两个或三个意图的句子占七成，这是数据集的设计，不是用户的真实分布。
1.5.2. 闲聊
欢乐互娱一场前端实习一面问 RAG 项目时追问：具体怎么判断用户输入是不是闲聊？
闲聊通常单独作为一类，走便宜的模型或固定话术，不进检索和工具。判断方法和其他类一样，难在边界：带着业务信息的寒暄不是闲聊，「心情不好，快递还没到」要按物流处理。闲聊这一类宁可判窄：把业务请求当成闲聊，用户的事没人管；把闲聊当成业务，只是多花一次检索。
1.5.3. 越界：归不进任何一类
去哪儿一场一面问：平台不知道用户问题属于哪一类时，怎样处理数据并作出判断？
分类器默认每一句话都属于某个已知类别，线上并不是这样。2019 年的 CLINC150 数据集专门研究这个问题：150 个意图、10 个领域，另外收了一批不属于任何意图的查询。作者的结论是，几种基准分类器在已知意图上表现不错，识别越界查询却很吃力。
常见的几种做法，往往一起用：
- 显式的「其他」类，配上越界的例子。Dify 文档的客服示例就有一类「Other questions」，「今天天气怎么样」归到这里。
- 置信度阈值，低于阈值算拿不准。
- 向量方案里，离每一类的例句都远，就算越界。
越界以后去哪：交给一个通用的 Agent（工具全一些、权限小一些），或者追问，或者明说做不了；高风险的转人工。这些请求要单独记下来，新类别就从这里来。
要务科技一场面试碰到的是另一种分支。面试官问怎么过滤广告、系统消息这类垃圾信息，候选人答用大模型识别、直接拦截；面试官接着问识别错了怎么兜底，候选人的答法是所有消息都留档，操作者能看到拦截标记。拦截分支的错误是静默的：被拦下的消息没人回，发消息的人也未必会再来问。不留档、不抽查，就发现不了。
面试常问：用户一句话里有多个意图，系统怎么处理？线上的提问大部分是多意图吗？怎么判断用户输入是不是闲聊？平台判断不出用户问题属于哪一类时，怎么处理？用模型拦截垃圾信息，识别错了怎么兜底？
1.6. 路由：交给谁、怎么交
1.6.1. 几种实现
美团一场 Agent 开发一面问：Agent 系统里的路由机制怎么设计，怎么判断请求该交给哪个 Agent 处理？淘天一场技术一面问 Router 节点怎么决定把任务分给哪个子 Agent。百度一场 Agent 面问：在 LangGraph 的基础上有没有做过上层的路由决策，比如由 AI 判断该走哪个节点、跳到哪个节点？
几种常见写法：
- LangGraph：路由节点调一次模型，用结构化输出拿到类别，写进 state；再用条件边（
add_conditional_edges）按 state 决定下一个节点。路由函数可以返回一个节点名、END，或者一组节点让它们并行。入口就要分流的话，条件边可以从 START 出发。文档提醒，同一个节点不要既接静态边又接条件边，混着用，两条路都会跑；要在一步里既更新状态又跳转，用 Command。 - Dify：问题分类器节点，每个类别一个出口，接不同的知识库、回复模板或工作流。
- OpenAI Agents SDK：分诊 Agent 带着 handoffs，转交在模型看来是一个工具；可以给每个目标写一段
handoff_description，提示模型什么时候选它。 - 自己写：分类只输出结构化字段（类别、子类、优先级、要不要转人工），代码查一张「类别到处理者」的映射表。
智谱一场实习一面问数据怎么路由到对应部门，字节一场抖音电商客户端一面问：接口返回时如果有问题分类的诉求，怎么组织返回结果，让不同问题对应不同的解决方案和流程？都可以用映射表答。分类和派发分开，派发规则放在配置里，业务调整分工不用改代码、不用发版；查不到的类别进默认队列。
1.6.2. 查接口、检索，还是直接答
阿里一场二面问：系统怎么决定一个请求应该走哪条路径？哪些问题适合直接调工具或执行确定性查询，哪些需要检索知识库？边界怎么划分？
按答案在哪划：
- 答案在业务系统里（订单状态、库存、余额），走接口，不检索。第 1 题说过，这类精确查询应该走接口。
- 答案在文档里（规则、说明、案例），走检索。
- 两边都要的，两边都查。「这个订单能不能退」要订单状态，也要退货规则。
- 都不需要的（寒暄、通用常识），直接答。
能用代码判断的，交给代码。百度一场后端 Go/Agent 一面问到一个细节：为什么「场上有没有未领取的 Intent、有没有新 Fact」这种事不让 Agent 判断，而由后端判断？这类问题的答案就在系统状态里，查一下就知道。代码判断又快又稳，还能写测试。模型负责从语言里理解用户要什么，状态和规则由代码核对。我在 Jev 那篇里写过同样的分工：重复扣款是否存在、金额是否一致、是否超过期限，用数据库和代码核对。
1.6.3. 按把握和复杂度分流
网易雷火一场全栈一面连着问：AI 知识库怎么区分简单请求和复杂请求？怎么根据置信度决定直接回答、进入完整工作流，还是返回证据不足？怎么根据问题复杂度动态控制模型调用次数？
可以分三档：
| 档 | 什么情况 | 怎么走 |
|---|---|---|
| 直接答 | 有把握、简单，命中 FAQ、一跳就能答的事实 | 短链路 |
| 完整工作流 | 复杂，多跳、要比较、要汇总 | 拆子问题（第 14 题） |
| 证据不足 | 查不到、拿不准 | 说明查不到什么，给出已知的部分，或者追问，不硬答 |
置信度从哪来要说清楚。模型自己报的数字未必准；可以用小分类器的概率、多次采样是否一致、检索结果的分数和覆盖情况。Jev 那篇里讲过校准：系统把一批预测都标成「80% 把握」，结果只有一半是对的，这个数字就不能直接拿来控制自动化。阈值要在评测集上定，看每个阈值下有多少请求被自动处理、这部分准了多少。
1.6.4. 多轮里每轮都重新分吗
LangChain 的多 Agent 文档比较过几种结构：路由器是无状态的，每个请求都要先调一次模型来分流；handoff 和 Skill 是有状态的，上一轮交给的 Agent、加载过的 Skill 还在，同样的请求再来一次，能省掉 40% 到 50% 的模型调用。每轮重新分，能接住用户中途换话题，代价是多一次调用，还可能在一件事做到一半时被分走。可以折中，让当前路由「粘住」：同一件事里默认不换，出现明显的新诉求，或者用户说「另外」「换个问题」时再重新分。
1.6.5. 派给子 Agent
派给哪个子 Agent，第 3 题第三节讲过三点：各个 Agent 的说明不能重叠；给路由留一个拿不准的出口；派错了允许退回，转交次数要有上限。小米一场后端 Java 一面问怎么提高 Multi-Agent 调度和路由的准确性，答法见第九节的评测。
面试常问：路由机制怎么设计，怎么判断请求该交给哪个 Agent？什么时候引入多 Agent，Router 节点怎么决定分给哪个子 Agent？在 LangGraph 上有没有做过上层路由，由 AI 判断走哪个节点？带多个检索分支的业务 Agent，意图理解和路由怎么实现，路由决策层的核心也是大模型吗？怎么提高多 Agent 调度和路由的准确性？一个请求走哪条路径怎么决定，哪些直接调工具或做确定性查询，哪些要检索知识库？怎么区分简单和复杂请求，怎么按置信度决定直接答、走完整工作流还是返回证据不足，怎么按复杂度控制模型调用次数？数据怎么路由到对应部门？有问题分类的诉求时，怎么让不同问题走不同的方案和流程？基于用户意图的路由是怎么工作的？
1.7. 要不要单独做一层意图识别
1.7.1. 为什么面试官问「去掉分类器」
汇川和无锡赫玛那两场问的是同一个变化：最初在入口放一个分类器，后来把它拿掉，改成把每一类的处理办法写成 Skill，让主模型按需加载。启云方一场 AI Agent 一面问的是这件事的底层：工具调用是靠关键词、触发条件，还是意图识别来决定的？在用 Function Calling 的 Agent 里，通常三者都不是，模型读工具描述自己决定（第 7 题）。
第 3 题引过 Anthropic 十月 22 日讲什么时候把子 Agent 并回主循环的文章。和这题直接相关的有两段。一段是比较结果：在几个企业部署里，一个带 Skill 的单 Agent，质量上常常胜过「一份提示词包办一切」和「拆成子 Agent」两种设计，单个任务的成本和延迟也往往更低。另一段是他们常见到的方案演进：意图分类器，固定的多步推理流水线，按用户分群，分开的推荐分支，最上面再加一个多 Agent 编排器。反馈往往是，这些结构大多在替模型做它已经不需要别人代劳的事，一份清楚的系统提示词、四五个轻量的数据工具，加上严格的输出护栏，就能覆盖大部分场景。
去掉入口分类器，理由有三条：
- 入口分错了，后面救不回来。专门的分支只带了这一类的工具和上下文，发现方向不对也换不了。汇川那场接着问的就是这个：最初的检索方向走偏了，系统有哪些机制拉回来？在单个循环里，模型看到工具返回的结果，可以换一个 Skill 继续；入口分类器的决定是一次性的。
- 维护成本。每加一类，要标数据、改分类器、加分支。
- 主模型能做了。很多场景里，分类器替模型做的判断，主模型自己就能做，还能结合整个对话的上下文。
1.7.2. 什么时候还值得单独一层
入口分流在这几种情况下仍然划算：
| 场景 | 为什么还值得 |
|---|---|
| 量大、要快、类别清楚的入口 | 客服的高频问题，规则或小模型分得又快又便宜，不必每次都跑一个大模型循环 |
| 必须走固定流程的 | 投诉、纠纷、涉及资金和合规的请求，要走写死的流程或者直接转人工，判断要能审计。FDE 那道题里 L3 的工单第一时间转人工，不交给模型回答 |
| 成本分层 | 简单的给小模型（第十一节、第 12 题） |
| 安全前置 | 注入、越权的请求在进 Agent 之前拦掉（第 20 题） |
| 隔离 | 不同租户、不同产品线的数据和工具要隔开，入口先分开，再进各自的 Agent |
小红书一场端侧推理实习一面问：生产场景是不是先识别意图，再推导工具依赖？可以答两种都有：流程固定、风险高的，适合先识别再走固定流程；开放的任务，适合交给模型在循环里选。要说清楚自己的系统属于哪种、为什么。
1.7.3. 路由没有消失，挪了位置
拿掉入口分类器以后，分流的决定挪到了三个地方：Skill 和工具的描述，模型读它们来选；系统提示词里写的什么情况做什么；Harness 里的硬规则，比如写操作要审批、某些请求必须转人工。评测也要跟着挪。Anthropic 那篇文章建议，还有编排器的时候，统计路由选对了几成；并进主循环以后，改为检查模型有没有加载对的 Skill、调对的工具。
面试常问：架构演进中为什么去掉了最初的分类器？没有分类器，模型怎么知道往哪个方向排查，方向走偏了怎么拉回来？为什么取消独立的分类器，把各类沉淀成 Skill 动态挂载？工具调用是靠关键词、触发条件还是意图识别决定的？生产里是不是先识别意图，再推导工具依赖？「有没有未领取的 Intent、有没有新 Fact」这类判断，为什么交给后端而不交给 Agent？
1.8. Skill 路由
1.8.1. Skill 是怎么被选中的
美团一场 AI 后端二面连着问三句：系统有多个 Skill 时，怎样把用户问题路由到正确的 Skill？同一产品存在多个 Skill 时，如何处理路由冲突？随着 Skill 增多，如何持续提升路由准确率？淘天供应链一场一面问：不同的 Skill 之间，大模型怎么选？提示词怎么写？
以 Claude Code 为例，每个 Skill 的名字和描述常驻在上下文里，完整内容用到时才加载，模型读描述决定什么时候用哪个。Anthropic 的 Skill 写作建议要求描述同时写清做什么、什么时候用，并且用第三人称，因为描述会注入系统提示词，视角不一致会影响模型发现它。描述和正文怎么写，第 8 题讲过，这里只讲跟路由有关的四件事。
1.8.2. 冲突和重叠
两个 Skill 的描述都写着「分析 SQL 时使用」，模型只能猜。办法按代价从低到高：
| 顺序 | 办法 | 具体做法 |
|---|---|---|
| 一 | 改描述 | 写上什么时候不用，划清边界。Claude Code 文档的排错部分，Skill 触发得太多，第一条建议就是把描述写得更具体 |
| 二 | 合并 | 功能重叠的合成一个，里面再分情况 |
| 三 | 分作用域 | 只在相关的目录、项目或产品线里挂载，不相关的模型看不到 |
| 四 | 定优先级 | 更具体的先于更通用的，写进系统提示词 |
1.8.3. Skill 多了，描述会被截掉
去哪儿那场问：故障分类扩到几十上百类，Skill 和 MCP 越来越多，应该怎样管理，避免冲突或让 Agent 误解？除了上面四条，Skill 多了还会碰到一个硬限制。Claude Code 的文档写明，Skill 清单有一个预算，随模型上下文窗口按 1% 算；超了以后，它会先丢掉最少用的那些 Skill 的描述，只留名字，模型也就少了用来匹配的关键词。每个 Skill 的描述和 when_to_use 合计也会截在 1,536 个字符。所以 Skill 越来越多时，第一步是清理：用不上的关掉，相近的合并；到了几百个的规模，要先检索候选、再让模型选（第 24 题）。子 Agent 也一样，Claude Code 也是按描述决定派给哪个子 Agent，自定义子 Agent 的描述合计超过 15,000 个 token，启动时会给出警告。
1.8.4. 换了模型，路由会变
科大讯飞一场飞凡计划的面试问：更换底层大模型，要不要重新调优 Skill？不同模型的指令遵循差异大，模糊指令容易让 Skill 匹配出错，频繁换模型要不要全量重评？候选人提出拆分链路，让主 Agent 只负责选择、几个子 Agent 负责判断，面试官指出：底层模型一换，选择结果还是会变。
Skill 路由的准确率是「这份描述加这个模型」共同的结果，模型一换，结果就可能变。Anthropic 的 Skill 写作建议专门有一条：Skill 是加在模型上的，效果取决于底层模型，要在每个打算用的模型上都测一遍；对 Opus 刚好的说明，换到 Haiku 可能要写得更细。实际做法是把路由评测集当回归测试，换模型、改描述、加 Skill 都重跑。这样换模型时不用人工逐个重试，跑一遍评测就知道哪些 Skill 选错了。
1.8.5. 选错了怎么发现
美团一场 AI 后端一面问：Skill 执行时出现错误路由或幻觉，系统怎么识别和兜底？
- Skill 自己检查前提：正文第一步先核对请求是否归自己管，不归就停下，说明原因，退回主循环。
- 每轮记下加载了哪个 Skill，事后能统计误加载。
- 校验结果；用户说「不是这个意思」，当作重新路由的信号。
美团一场全栈日常实习一面问：用户输入后，从路由到 Skill 调用的完整流程是什么？美团一场后端开发一面问：进入意图识别之后，深度分析这类场景怎么适配，主要是装配 Skill 和 MCP 吗？可以按顺序说：入口的硬规则先过（命令、安全拦截）；模型读 Skill 清单，决定加载哪个；读进 SKILL.md，按说明调工具、跑脚本，需要的 MCP 工具在这一步用上；校验结果；不对就换一个 Skill，或者追问。
面试常问：有多个 Skill 时，怎么把用户问题路由到正确的那个？同一产品有多个 Skill，路由冲突怎么处理？Skill 越来越多，怎么持续提高路由准确率？Skill 怎么组织、识别和召回，相似的提示词怎么保证准确率，是不是统一放进目录交给 AI 调度？不同 Skill 之间大模型怎么选，提示词怎么写？故障类别扩到几十上百类，Skill 和 MCP 越来越多，怎么管，怎么避免冲突和误解？换了底层模型，要不要重新调 Skill，要不要全量重评？Skill 出现错误路由或幻觉，怎么发现、怎么兜底？从路由到 Skill 调用，完整流程是什么？识别出意图以后，深度分析这类场景怎么适配，主要靠装配 Skill 和 MCP 吗？
1.9. 怎么知道分得对
1.9.1. 先有一份评测集
迅雷那场第一问：你们怎么知道意图分得对，指标量化吗？
评测集从线上日志里抽，按类别分层抽样，每一类都要有；再专门补几种：两类之间最容易混的边界样本、越界样本、多意图样本、带错别字和口语的、要看上下文才能判的多轮样本。标签请懂业务的人标，每一类写清判定规则，有争议的拿出来讨论再定。评测集怎么建第 4 题讲过；Skill 触发评测的正反例第 8 题讲过，要点是反例不能全用无关的闲聊，要用带着相同关键词、但不该触发的近邻。
1.9.2. 看哪些指标
| 指标 | 看什么 |
|---|---|
| 每一类的精确率和召回率 | 不只看总准确率。类别不平衡时，总准确率会被大类撑高 |
| 混淆矩阵 | 哪两类最常混，改定义、补例子就从那里下手 |
| 越界单独算 | 越界的召回率和已知类的准确率分开报，CLINC150 的结论就是这两者可能差很远 |
| 按代价加权 | 把退款请求判成闲聊，比把闲聊判成 FAQ 严重得多，高风险类别单独设门槛 |
| 覆盖率和准确率一起报 | 设了置信度阈值以后，说清自动处理了多少、这部分准了多少、多少交给了追问或人工 |
| 一致性 | 同一批输入多跑几次，结果相同的比例 |
工单路由指南给了一组参考目标：分类一致性 95% 以上；难例准确率至少 80%；首次分配的路由准确率，行业常见目标是 90% 到 95%；改派率低于 10%，好的系统在 5% 以下。这些是参考值。
科大讯飞一场 AI 应用一面问：Skill 路由评测主要评测什么，怎样做？路由差是否只改 description？东方财富一场 AI 应用一面问：除了描述，误路由还有什么原因，Skill 数量有影响吗？路由如何量化，什么阈值放行？
误路由的原因不只是描述：类别本身重叠；Skill 太多，清单被截断（第八节）；换了模型；上下文太长，无关内容干扰判断；请求本身有歧义，该追问却没追问。自己的放行门槛按错误代价定：只读的 Skill 可以宽一些；有副作用的，要求精确率高、误触发率低；新版本不能让原来判对的样本变错。
1.9.3. 分段和端到端
第四节那场问搜索消歧的字节一面还问：评测只看最终答案，还是也检查意图识别、工具选择与调用轨迹？快手 AI 全栈二面那场问：除了检查是否路由到正确的 Skill、调用了正确的工具和知识文档，还怎么判断最终的诊断结果是正确的？
两层都要。分段指标（路由对不对、工具对不对）用来定位问题在哪；端到端的结果（问题解决没有、答案对不对）才是用户感受到的。路由全对、答案错了，问题在后面；答案对了、路由错了，可能是兜底救回来的，也要记下。
腾讯一场大模型算法面问：怎么量化分析模型、知识库、工具、路由模块分别对最终效果的贡献？路由这一块可以这样量：把路由换成人工标注的正确答案，相当于一个不会错的路由器，再跑一遍端到端，提升的部分就是改进路由最多还能带来多少；再换成一个最简单的基线，比如全部走默认分支，看现在的路由比基线好多少。其他模块同样一次只换一个，就是第 4 题讲的消融。
1.9.4. 线上信号
离线评测之外，线上能看到这些信号：
- 用户马上换个说法重问，或者说「不是这个意思」。
- 点了转人工，或者换到别的入口。
- 兜底分支和「其他」类的比例突然变化。
- 各类的占比和平时不一样，可能是新业务、新说法，也可能是分类器出了问题。
GPT-5 的系统卡（2025 年 8 月）是一个产品级的例子。GPT-5 有一个实时路由器，按对话类型、复杂度、是否需要工具，以及用户明确表达的意图（比如在提示词里写「好好想一想」），决定用快的模型还是深度推理的模型。这个路由器持续用真实信号训练，包括用户什么时候手动切换模型、对回答的偏好，以及测得的正确率。OpenAI 当时还说，打算以后把这些能力整合进一个模型里。
1.9.5. 「准确率多少」怎么答
腾讯社招二面问意图识别最终准确率多少，携程那场问路由准确率怎么样。
[!note] 报准确率要带口径
报数要带上口径：测试集多大、从哪来、分几类、有没有越界样本，总体和最差的一类各是多少，主要混在哪两类之间。只报一个「95%」，下一个问题多半就是怎么算的。
面试常问：怎么知道意图分得对，有没有量化指标？意图识别的准确率最终多少？路由准确率怎么样？Skill 路由评测评什么、怎么做，为什么要做，正反例怎么构造？路由差是不是只改 description，除了描述还有什么原因，Skill 数量有没有影响？路由怎么量化，什么阈值放行，上线了吗？评测只看最终答案，还是也查意图识别、工具选择和调用轨迹？路由和工具都对了，怎么判断最终诊断是对的？模型、知识库、工具、路由各自对效果贡献多少，怎么量化？
1.10. 分错了怎么办
1.10.1. 每一层都留出口
要务科技、快手支付测开、携程、经纬恒润都问了识别错了怎么办。
[!caution] 每一层都要留出口
- 入口：置信度不够就追问，或者交给通用分支，不硬分。
- 执行中：分到的处理者先核对前提，发现不归自己就退回，带上原因（第 3 题）。退回和转交都要限次数，免得几个分支来回踢。
- 结果：校验输出；用户说「不对」，就带着这句纠正重新分。
- 人：高风险的、连续失败的转人工。FDE 那道题的辅助回复面板里，「建议转人工处理」是每单都给的一项判定，转人工的按钮常驻。
浩鲸那场问：拿到一批候选工具后，大模型选错了怎么兜底？可以叠几道：选出的工具必须在这个意图的白名单里；参数过校验；有副作用的先确认；执行出错按第 11 题处理；重试几次还不行就转人工。候选人这场答的是重试三次失败转人工。
1.10.2. 讲一次误判
阿里那场还问：遇到过系统误判用户意图的情况吗？举一个具体例子：错误发生在哪一步，为什么会判断错，后来怎样通过路由规则、上下文或追问机制修正？
这道题只能用自己的真实案例答，可以按这个顺序组织：
- 现象：用户说了什么，系统分到了哪里，结果怎样。
- 错在哪一层：改写、分类、阈值、缺上下文，还是类别定义本身就含糊。
- 为什么错：新的说法，两类边界不清，或者缺了一个只有系统状态才知道的信息。
- 怎么改：强信号加规则，缺信息就补字段，分不开就加追问，定义含糊就改类别。
- 怎么防复发：这条样本进评测集，改完把整个评测集重跑一遍。
经纬恒润那场问有没有遇到模型理解错用户意图的情况、怎么解决的，也是这个结构。误判的样本回流进评测集，走第 13 题的 bad case 流程。
面试常问：意图识别有误时有什么兜底？意图识别或工具路由错了怎么办？路由识别错误时有什么处理机制？遇到过模型理解错用户意图吗，怎么解决的？遇到过误判吗，错在哪一步、为什么错，后来怎么靠路由规则、上下文或追问修正？候选工具里大模型选错了怎么兜底？
1.11. 多模型路由和切换
1.11.1. 依据和几种实现
泛微一场面试问：为什么需要多个模型？模型路由怎么实现？为什么要根据复杂度选择不同的生成方式？百度一场 Agent 一面问：模型路由的依据是什么？阿里优酷一场二面问：不同任务怎么选模型？
依据和成本账第 12 题讲过：任务类型和难度，要不要工具和多步推理，上下文多长，结果能不能验证，错了代价多大，延迟和预算；加第二个模型之前，先试同一个模型调低 effort。我六月写 GPT-5.6 发布时说过，一个应用以后可能在两个维度上同时路由：选哪一档模型，用多大的推理强度。这里补几种实现方式：
| 方式 | 做法 | 例子 |
|---|---|---|
| 按角色固定分 | 编排、重推理、执行分给不同的模型 | Claude Code 做编排，规划、架构和重推理交给 GPT-5.6 Sol，执行、轻任务和子 Agent 交给 Grok 4.5，中间用 CLIProxyAPI 做协议转换和模型路由 |
| 按阶段切 | 按模式切换模型 | Claude Code 的 opusplan，计划模式用 Opus，执行时切到 Sonnet；它只是按模式切换，不是按任务难度自动路由 |
| 按请求动态分 | 训练一个路由器判断该用强模型还是弱模型，或者先用便宜的、不行再升级 | RouteLLM；级联 |
| 产品自带 | 平台自己按请求路由 | 第九节 GPT-5 的实时路由器 |
不管哪种，都要能验证请求真的去了你以为的那个模型。混合配置那篇里记过两个坑：只看 /model 菜单或者听模型自报，没有去查实际的用量记录 modelUsage；四个角色都配了，却忘了配默认的兜底模型。
1.11.2. 切换重答
度小满一场 AI 全栈二面连着问了四句：多模型切换重答，是系统自动切换的，还是用户可选的？你负责的状态机起什么作用？切换模型重答时，会把上一个模型的上下文带过去吗？从大窗口模型切到小窗口模型，上下文不够用怎么办？同一位作者的一面问：多模型切换和路由功能是怎么设计的？
逐条答：
- 谁触发。用户手动选「换个模型重答」，和系统自动切换（限流、服务端错误、超时、拒答）都常见。Claude 的新模型被安全分类器拒答时，返回的是正常响应，
stop_reason为 refusal；API 有一个服务端的fallbacks参数（目前是 beta），设成"default"以后，会按拒答类别自动换到 Anthropic 推荐的模型重试，这是平台替你做的一次路由。Haiku 5.5 没有这个服务端兜底，简单请求路由给它时，拒答后的重试要靠 SDK 的中间件或者自己写。 - 状态机。记住这一轮由哪个模型答、为什么切、已经切过几次，防止在几个模型之间来回切，也方便事后统计各模型的表现。
- 上下文带不带。对话历史要带过去，用户和助手的消息、工具结果都在里面，否则新模型不知道前面发生了什么。模型专属的东西不一定能用：Claude 的思考块和产生它的模型绑定，当前模型读不了的，API 会在这次请求里丢掉，不计费。文档建议照常发送完整历史，让 API 去丢，客户端不要自己删，切回原来的模型时还能读到。跨厂商切换更麻烦，我在混合配置那篇里写过，文本和工具调用能跑，不代表思考块、签名、提示词缓存这些专属语义也等价。
- 缓存。提示词缓存按模型隔离，切到新模型要重新写一遍前缀（第 12 题算过这笔账）。所以自动切换要少，主循环里尽量不换模型。
- 窗口不够。切换前先数 token；装不下就压缩较早的轮次，保留系统提示词、最近几轮和关键事实（第 5 题）；压缩以后还装不下就不切，告诉用户。
1.11.3. 多个模型怎么衔接
百度一场 Agent Harness 一面问：怎么保证多个模型的输出无缝衔接？有没有做过内部的 QA 模型，专门回答已有的一类问题？
多个模型之间靠接口衔接：输出用结构化格式；工具定义各模型一致；中间结果写成显式的产物，比如计划文件、结构化摘要，下一个模型读产物，不依赖上一个模型没写出来的推理。专门回答一类问题的模型，就是路由的一个目的地：高频、固定的那一类（比如 FAQ），可以交给小模型，或者直接查缓存的答案（第 12 题的应用层缓存），省下的钱和延迟要和它答错的比例一起算。
面试常问：为什么需要多个模型，模型路由怎么实现？为什么要按复杂度选不同的生成方式？模型路由的依据是什么？不同任务怎么选模型？多模型切换和路由怎么设计？切换重答是系统自动切还是用户选，状态机起什么作用，上一个模型的上下文带不带过去，从大窗口切到小窗口模型怎么办？多个模型的输出怎么衔接？有没有专门回答一类问题的内部 QA 模型？
1.12. 面试怎么答
两分钟左右的主线：
- 先说清楚：意图识别回答用户要什么，路由回答交给谁。目的地有流程、Agent、Skill、数据源、模型、人，还有回到用户追问。
- 类别按处理方式定：交给同一个处理者的合并，处理方式不同的拆开；类别多了就分层，每层留「其他」和「拿不准」的出口。
- 怎么识别：规则拦确定的，小模型或向量扛大头，大模型处理难例，还拿不准就追问或转人工。选哪种看数据、类别会不会变、延迟和成本，用同一份测试集比。
- 难的输入：口语和错别字靠语义理解，原话保留；歧义靠句子以外的信息，比如入口、状态、历史；信息不全按「对话、系统、默认值、问用户」的顺序补，决定副作用和钱的参数必须确认。
- 多意图和越界：真多意图拆开、标出依赖；越界单独识别，记下来当新类别的来源。
- 判断放在哪：能用代码判断的不交给模型；开放的任务可以把分流交给主模型，按 Skill 和工具的描述来选；量大、合规、要审计的入口仍然单独分。
- 怎么证明：分层抽样的评测集，看每类的精确率和召回率、混淆矩阵，越界单独算，按代价加权；换模型、改描述都重跑；线上看重问、纠正、转人工和各类占比的变化。
- 分错了：每一层留出口，派错能退回，次数有上限，误判样本回流进评测集。
「你的项目」按这个顺序准备：
- 分几类、怎么定的，每类大概占多少流量。
- 用什么识别，为什么，和别的方案在同一份测试集上比的数字。
- 准确率怎么算的：测试集多大、从哪来，总体和最差的一类，主要混在哪两类之间。
- 拿不准和分错了怎么办：阈值多少、怎么定的，追问和转人工各占多少。
- 一次真实的误判：错在哪一层，怎么改的，改完怎么防复发（第 13 题）。
几个常见的失分点：
- 只说「用大模型做意图识别」，说不出类别怎么定、拿不准怎么办。
- 类别按话题分，同一类里风险完全不同。
- 只报一个总准确率，说不出测试集和最差的一类。
- 置信度直接用模型自报的数字，没有在评测集上定阈值。
- 没有「其他」类，所有输入都硬分到已知类别。
- 多意图只取第一个。
- 决定副作用的参数缺了就猜。
- 说去掉了分类器，讲不出路由挪到了哪里、现在怎么评。
- Skill 多了只会说改描述，不知道清单会被截断。
- 换了模型，不重跑路由评测。
- 讲自动切换模型，不提上下文、缓存和窗口。
面试常问：讲讲你负责的意图识别。实习期间的意图识别是怎么做的？有没有做过意图识别，怎么做的？
1.13. 出处
文中的面试问法都出自下面这些面经，括号里是发帖日期，链到牛客原帖。
- 开头的例子：携程 Agent 一面（10-17） · 迅雷 Agent 一面（09-23） · 汇川技术数字化全栈一面（09-22） · 无锡赫玛科技（10-10）
- 意图识别怎么做：规则、小模型还是大模型：B站 AI 应用 Agent 开发一面（08-18） · 欢乐互娱前端实习一面（08-24） · 字节 Trae 二面（09-03） · 双非前端字节二面（AI Coding 题）（09-05） · 快手 AI 全栈二面（09-07） · 腾讯 AI 全栈一面（09-10） · 金山数娱 AI 应用一面（09-13） · 智谱 AI Native Builder 实习一面（09-15） · 美团后端开发一面（09-22） · 字节后端一面（09-23） · 腾讯社招三面（09-23） · 腾讯社招二面（09-23） · 影石移动端一面（09-30） · 快商通 Agent 全栈一面（09-30） · 浩鲸科技一面（09-30） · 无锡赫玛科技（10-10） · 字节抖音开放平台一面（10-11） · 得物 Java 二面（10-16） · 微店 AI 全栈一面（10-16） · 小厂 Agent 开发一面（10-18）
- 路由：交给哪个 Agent、节点、工作流：百度 Agent 面（附在小红书一面帖里）（08-24） · 美团 Agent 开发一面（08-25） · 小米后端 Java 一面（08-27） · 淘天技术一面（09-02） · 快手 AI 全栈二面（09-07） · 字节抖音电商客户端一面（09-15） · 智谱 AI Native Builder 实习一面（09-15） · 网易雷火全栈一面（09-21） · 影石移动端一面（09-30） · 美团和阿里二面（10-14） · 携程 Agent 一面（10-17）
- 怎么知道分得对：准确率、评测、阈值：小米后端 Java 一面（08-27） · 快手 AI 全栈二面（09-07） · 美团 AI 后端二面（09-14） · 腾讯社招二面（09-23） · 迅雷 Agent 一面（09-23） · 东方财富 AI 应用一面（09-24） · 科大讯飞 AI 应用一面（09-24） · 腾讯大模型算法一二面（10-02） · 字节一面（260901）（10-03） · 科大讯飞飞凡计划（10-13） · 携程 Agent 一面（10-17）
- 识别错了怎么办：要务科技（09-07） · 美团 AI 后端一面（09-10） · 快手支付测开一面（09-30） · 浩鲸科技一面（09-30） · 经纬恒润 AI 应用一面（10-03） · 美团和阿里二面（10-14） · 携程 Agent 一面（10-17）
- Skill 路由：怎么选对、重叠了怎么办：快手 AI 全栈二面（09-07） · 美团 AI 后端一面（09-10） · 美团 AI 后端二面（09-14） · 去哪儿一面（09-22） · 美团后端开发一面（09-22） · 淘天供应链 AI 应用一面（09-23） · 东方财富 AI 应用一面（09-24） · 科大讯飞 AI 应用一面（09-24） · 美团全栈日常实习一面（10-12） · 科大讯飞飞凡计划（10-13） · 快手 AI 全栈一面（10-14）
- 多模型路由和切换：泛微智能化开发（08-30） · 百度 Agent 一面（09-06） · 百度 Agent Harness 一面（09-08） · 阿里优酷二面（09-09） · 度小满 AI 全栈一面（09-30） · 度小满 AI 全栈二面（09-30）
- 口语化、错别字、模糊、信息不全：小鹏 AI 全栈培训生一面（09-02） · 字节 Agent 开发后端日常实习一面（09-23） · 迅雷 Agent 一面（09-23） · 字节一面（260901）（10-03） · 美团 Agent 一面（10-12）
- 要不要单独做一层意图识别：百度后端 Go/Agent 一面（08-28） · 启云方 AI Agent 一面（09-03） · 小红书端侧推理实习一面（09-14） · 汇川技术数字化全栈一面（09-22） · 无锡赫玛科技（10-10）
- 意图体系：分几层、怎么抽象：快手效果营销日常二面（08-25） · 腾讯社招三面（09-23） · 小厂 Agent 开发一面（10-18）
- 一句话多个意图：腾讯社招二面（09-23） · 携程 Agent 一面（10-17）
- 闲聊、越界、归不进任何一类：欢乐互娱前端实习一面（08-24） · 去哪儿一面（09-22）
- 外部资料：Anthropic Building effective agents（2024-12-19）、Building agents: When to fold subagents into your main agent loop（2026-10-22） · Claude 文档 Ticket routing、Skill authoring best practices、Refusals and fallback、Preserved thinking，Claude Code 文档 Skills、Subagents、Model configuration（都是 11-08 读取） · LangGraph Graph API、LangChain Multi-agent、OpenAI Agents SDK Handoffs、Dify Question Classifier、Semantic Router、Rasa FallbackClassifier（都是 11-08 读取） · OpenAI GPT-5 System Card（2025-08） · 论文 An Evaluation Dataset for Intent Classification and Out-of-Scope Prediction（CLINC150，EMNLP 2019）、AGIF（MixATIS、MixSNIPS，Findings of EMNLP 2020）