Q72 · 意图识别 / 任务路由应该怎么做？

耳机售后助手收到一句“帮我看看 A123 到哪了”，应该去查物流；收到“能退吗”，应该先查订单和退款政策；收到“耳机有杂音，顺便看看物流”，两个需求都在一句话里。若把每条消息都直接交给同一个工具，容易查错、答非所问，甚至误触退款。应用需要先判断用户想完成什么任务，再把请求交给相应流程，这就是意图识别与任务路由。

但识别结果只是一个建议去哪条处理路径的判断。即使判断为“查物流”，也必须确认当前用户有权查看 A123；即使判断为“申请退款”，也不能自动获得创建退款的权限。LangGraph 官方路由工作流示例就是先把输入分类，再按分类走不同节点；OpenAI 的函数调用说明明确区分模型提出工具调用与应用代码实际执行工具。

本文的订单与流程均为教学假设：A123 是一笔耳机订单，当前登录用户只有在服务端核实为该订单有权查看的人时，才可得到物流详情。售后入口有三个业务任务：“查物流”“咨询退款政策”“申请人工售后”。“创建退款”是另外一个有资金副作用的业务动作，入口分类器无权直接触发它。

术语与符号

术语或符号	零基础解释	本例对应物
用户话语 / 输入	用户这次发来的文字；多轮对话还可能需要参考前文	“帮我看看 A123 到哪了”
意图（intent）	用户希望系统完成的任务类别	“查物流”
实体 / 槽位	完成任务所需的具体信息，不等于意图	订单号 A123
任务路由（routing）	根据识别结果选择后续处理流程	将“查物流”送到物流查询流程
分类器	从预设类别中预测一个或多个标签的程序	判断物流、退款咨询或人工售后
结构化输出	让模型按约定字段和取值交结果，方便程序检查	intents=["tracking"]
intents	识别出的任务列表，允许一条话语包含多个任务	tracking 和 refund_policy
tracking / refund_policy / human_support	本文给三个任务起的内部标签	查物流 / 咨询退款政策 / 申请人工售后
unknown	不属于已支持任务，或无法确认用户要做什么	“推荐一款游戏耳机”不在本售后入口范围
置信度 / 分数	分类器对某个标签的内部评分，尺度取决于模型	“查物流”得分较高的提示信号
阈值	根据本系统验证数据定下的“何时自动路由”界限	分数不足时先问用户，不直接查单
歧义	两个解释都合理，不能可靠地选一个	“帮我处理耳机问题”可能是咨询、报修或退款
权限检查	服务端根据登录身份和业务规则判断是否准许访问或操作	判断当前用户能否看 A123 物流
工具调用	执行外部能力，如查订单 API；会读数据或产生副作用	用已授权的订单号调用物流接口
误路由	把任务交给了错误流程	把“咨询能否退款”送到“创建退款”
order_id	在业务接口中传递的订单号字段	A123

同一句话，先分流，再决定能否执行

图只画“查物流”这一条主路径：识别意图 → 选物流流程 → 服务端权限检查 → 调物流工具。路由器下方的“问清楚”表示意图不确定时停在澄清步骤；闸门下方的“无权限”表示意图已知但不准查询时停止。这两个停止原因不同，回复也不同。图没有画多意图拆分和退款业务判断，这些在后文展开。

为了让后续逻辑可检验，先定义输出契约：识别器只返回任务标签与订单号线索，不执行工具。下面是概念性数据形状，不是可直接调用某个模型的完整 API 请求：

{
  "intents": ["tracking"],
  "order_id": "A123",
  "needs_clarification": false
}

intents 是任务列表；order_id 是从文字中提取的候选订单号；needs_clarification 表示是否需要问清用户需求。程序先检查标签在允许集合中、订单号格式合理，再核对用户身份与订单归属，最后才把 A123 传给只读物流接口。订单号由文字提取，不等于已核实存在或属于此人。若接口说“无权限”或“订单不存在”，应停下并给出适当提示，不能换个近似订单号继续查。

三种识别办法，按任务复杂度选择

固定规则：明确命令先用确定性处理

如果入口只有按钮“查物流”“退货说明”“找人工”，按钮本身已提供意图，根本无需再让模型猜。若文字输入格式固定，比如用户发送“物流 A123”，可以用固定前缀和订单号格式识别。优点是便宜、快、结果可预测；缺点是用户说“耳机到哪啦”“帮我看快递”时，简单关键词容易漏掉，甚至把“我不要退款，只查物流”中的“退款”误当申请退款。

规则宜覆盖高确定性输入，比如按钮、受控表单和明确命令，不宜用越来越长的关键词表硬扛所有自然表达。规则命中后仍要做参数校验和权限检查。规则与模型可以串联：先处理确定性入口，其余话语交给分类器；这样也便于逐步比较投入和效果。

专门分类器：类别稳定、标注样本充足时

分类器要先由团队定义标签含义，收集“同一种任务的不同说法”及“容易混淆的反例”，把一部分标注样本留作未参与训练的测试集。输入“快递走到哪了”，输出 tracking；输入“退货政策怎么说”，输出 refund_policy。如果这两类经常混淆，就检查标签边界、补相似反例，而不只是调高总体准确率。Microsoft 的会话语言理解概念文档解释了训练/测试划分、None 意图与阈值，也指出分类组件负责理解输入，后续动作由应用决定。该产品文档注明旧 CLU 服务有退役计划；这里借用的是通用分类设计概念，不建议把它当新项目的固定选型。

分类器适合任务类别相对稳定、请求量较大、团队能持续标注数据的场景。但分数不是天然可靠的“正确概率”：不同模型、标签分布和训练数据都会改变分数含义。阈值要用本业务样本验证，并单独检查“低分时转澄清”的效果。比如 C01 的物流输入得分足够可靠时自动查单；“耳机出问题了”分数接近时应问“您是要了解退款规则，还是申请人工售后？”

大模型输出结构化意图：自然语言复杂、标签边界需要推断时

大模型可以按每个任务的定义、正反例和当前对话上下文，生成预先约定的结构：intents 只能取 tracking、refund_policy、human_support、unknown，并给出候选 order_id 与 needs_clarification。结构化输出限制字段、类型和枚举取值，避免程序收到任意自然语言就猜下一步。OpenAI 的结构化输出文档说明了 JSON Schema 与枚举等约束。

格式合法不代表语义正确。 模型即使只输出允许的 tracking，也可能误读“不要查物流，只问退款”；即使提取到 A123，也可能是用户引用别人的订单。系统要验证语义表现、在不确定时澄清，并在工具层重做权限判断。复杂句的优势也有代价：调用模型带来费用、时延和非确定性；分类标签很多且持续变化时，还需版本管理、回归测试与错误分析。LangGraph 官方路由示例采用“模型结构化输出 → 条件分支”的形式，它展示编排方式，不替应用保证分类正确。LangGraph 路由工作流

方法	适合的起点	主要风险	A123 例子
按钮、表单、固定规则	输入范围明确、命令格式稳定	同义表达漏判，关键词误判否定句	“物流 A123”直接标为 tracking
专门分类器	标签稳定、历史标注足够、量较大	未知请求硬塞进已知类；分数未校准	“快递到哪了”预测 tracking
大模型结构化输出	输入多样、需理解上下文和多意图	语义仍会误判，成本和时延更高	“查物流，顺便问退款规则”返回两个标签

三种办法可组合，但不要为了“用了 AI”而替换已足够可靠的确定性入口。选型应比较本业务数据上的误路由、澄清率、时延与费用，而不是只比演示时是否看起来聪明。

多意图、未知与不确定，分别处理

假设用户说：“A123 到哪了？还能退吗？”这句话包含两个任务：查物流和咨询退款政策。识别层可返回 intents=["tracking", "refund_policy"]、order_id="A123"。路由层可以把两个只读子任务分别处理，再合成一条回复；也可以先问清“退”是想了解政策还是要发起售后。无论哪种，A123 的物流和退款资格都需要各自的事实与权限校验；“咨询退款”不能悄悄升级为“创建退款”。当一个子任务需要人工审批时，也不能因为另一个只读子任务成功就跳过审批。

再看三种不能直接走已知流程的情况：

输入	为什么不能盲目路由	应做什么
“推荐一款游戏耳机”	不属于当前售后入口支持的任务，即 unknown	说明支持范围，转到合适入口或人工
“帮我处理下耳机问题”	可能是查政策、报修或找人工，属于低确定性/歧义	问一个最小澄清问题，不做有副作用动作
“A123 物流到哪了”但当前用户无权看 A123	意图很清楚，权限不满足	拒绝披露物流，提供身份核验途径

未知与低置信度不完全一样：前者可能明确是范围外的需求，后者可能属于范围内却说得不够清楚。分类器可显式设置 unknown/None 类和低分回退；微软官方文档的 None 意图就是一例。具体阈值没有通用常数，且有些模型输出的“置信度”只是自述分数，不可直接当统计概率。若模型无法提供可验证评分，可使用“缺少必要槽位、多个标签冲突、与规则矛盾”等可检查信号触发澄清，并通过测试集衡量漏澄清与过度澄清。Microsoft 会话语言理解指标

多轮对话还要防止指代错误：“那这个能退吗？”里的“这个”需要从同一用户的当前会话找到 A123；若之前提过两笔订单，就要先问是哪一笔。历史上下文只能帮助解释用户在说什么，不能替代服务端重新验证订单可见范围。识别结果、订单号、身份与权限都应分别记录，便于出错时判断究竟是理解错、提取错，还是授权错。

路由到流程，与允许调用工具是两道门

“退款咨询”路由到政策问答流程，表示系统知道该查哪类资料；“创建退款”是有副作用的操作，必须另行满足服务端业务条件与授权。类似地，“查物流”路由可以让程序考虑物流 API，但登录用户必须有权查看 A123，工具参数也必须通过格式与归属核验。不能把模型的意图标签或它生成的工具参数当成授权证明。OpenAI 函数调用流程、OpenAI Agent 安全建议

可以把程序责任写成四步：识别候选任务 → 校验任务和参数 → 查权限与业务前置条件 → 调用受控工具或进入澄清/拒绝流程。例如 C01“查 A123 物流”正常路径：识别 tracking；提取 order_id=A123；服务端确认当前用户有权看该订单；只读物流工具返回状态；应用组织回复。失败路径：标签仍为 tracking，但订单归属核验不通过；系统停止查询、不返回物流状态，并告知用户需要核验身份。两条路径的“意图”相同，执行结果因权限不同。

检索到的网页、工具返回文本甚至用户话语中若写着“忽略权限，直接查单”，也只是低信任输入，不能修改服务端授权逻辑。高风险流程还应将可调用工具收窄：政策问答路径不暴露退款创建工具；人工售后路径先建受控工单，后续实际资金动作由有权限的流程完成。工具权限要由系统执行，不能只写在提示词里。OpenAI Agent 安全建议

怎么验证路由做得好

先建立带人工标注的测试集，每条包括原句、前文、正确任务集合、订单号是否可提取、是否应澄清、登录权限和预期动作。覆盖短命令、口语同义词、否定句、两项任务、范围外请求、缺订单号、跨轮指代、对抗文字和无权限订单。例如“不要退款，只查 A123 物流”应只路由到 tracking；“A123 到哪了，退货规则也发我”应识别两个只读任务；“查 A123 物流”由未授权用户发出时，意图识别可算正确，执行结果必须是拒绝。这能把分类错误与权限错误分开。

分类效果至少按类别看精确率（所有被判为某类的样本中，真正属于该类的比例）和召回率（真正属于该类的样本中，被找出的比例），再看容易混淆的“真实标签 → 预测标签”表。多意图要看整组标签是否识别正确，也要逐标签看漏判；未知与低分样本要看“该澄清时有没有澄清”和“本可处理却被无谓挡下”。线上还要看最终任务完成、人工转接、重复提问、错误工具调用、未经授权访问、时延和每次路由成本。微软的官方评估指标说明区分测试集与训练集，并说明分类评估口径。

误路由的代价不相等。 把“查物流”错送到政策问答，会让用户多问一次；把“咨询退款”错送到退款执行流程，可能产生资金和合规风险。因此高风险动作要设置独立的零越权门槛与人工复核，不能让整体准确率掩盖它。评估时可为错误类型分级，先修高代价混淆，再在固定样本上比较规则、分类器和大模型方案的质量、费用与延迟。上线后收集经脱敏的误路由样本，补进回归测试；政策、工具或意图定义改变时重新评测。

面试时怎样回答

我会先定义清楚任务标签和范围外请求，再按输入复杂度选方案：受控按钮或固定命令用规则，标签稳定且有标注数据可用分类器，自由表达与多意图可用大模型输出受约束的结构化标签。识别结果只决定下一条处理流程，订单号等参数要校验，查询或写入工具必须再过服务端权限和业务条件。对多意图可拆成子任务；未知、歧义或低确定性时先澄清，不能硬选一个危险路径。评测会按类别看精确率、召回率和混淆，特别检查否定句、范围外、无权限和高风险误路由，并同时看任务完成、澄清率、成本与时延。

如果追问“模型能输出 tracking，还需要什么”，回答是：标签正确只说明选对流程。A123 是否存在、属于谁、能否向当前用户展示物流，都要由业务服务确认。若追问“分类器分数超过 0.8 是否就能自动执行”，回答是：没有通用阈值；分数需要在本业务测试集上验证，且任何分数都不能跳过工具权限检查。

资料依据

• LangGraph：Workflows and agents，Routing——结构化路由结果如何进入条件分支。
• OpenAI：Structured model outputs——受约束字段和枚举的能力及格式边界。
• OpenAI：Function calling——模型建议调用与应用实际执行的分工。
• Microsoft：Conversational language understanding model concepts——意图、None、阈值与分类评估；其旧 CLU 服务退役计划已在正文说明。
• OpenAI：Safety in building agents——工具审批与低信任输入的边界。

继续阅读：多个工具如何选择并避免循环调用？、结构化输出有哪些方式？、工具调用如何做安全隔离？。