Agent 意图识别 12 个核心概念：以千问订外卖为例

写在最前​

01​

PART​

用户输入​

很多产品经理会把 用户输入 理解成聊天框里的那一句话。​

做 Agent 时，这个理解太窄。用户输入不只是文本，还包括当前页面、定位、选中的对象、上传的文件、语音转写结果，甚至用户刚刚点过哪个按钮。​

在订外卖里，用户说帮我点个附近的外卖。文本只告诉你用户想吃饭，当前位置和收货地址才告诉你附近到底是哪。用户说送公司，地址簿才知道公司对应哪栋楼、哪个门、哪个电话。​

拆这个概念时，老王会先看输入入口，而不是先看模型怎么分类。​

文本输入解决用户说了什么。​

场景输入解决用户在哪里说。​

状态输入解决用户刚才做了什么。​

权限输入解决系统能不能继续查。​

如果输入只收一句话，后面所有推理都会悬空。Agent 不是读心术，它需要把用户表达和业务现场一起吃进去。​

​

​

日常做产品方案时，别只画一个对话框。你要列清楚每个入口能给 Agent 提供哪些输入信号。​

更细一点，输入信号还要写清楚来源、可信度和有效期。定位来自系统 GPS，地址来自用户地址簿，口味偏好来自历史订单，当前页面来自前端埋点，这几类输入的可靠程度不一样，不能混在一起用。​

💡 方案落点​

比如用户说送公司，但当前定位在家附近，这就是输入冲突。方案里不能只写识别到公司地址，而要写系统优先使用哪个地址、是否需要确认、确认文案怎么说、用户不授权定位时怎么降级。一个可执行的输入设计，至少要有四列：输入项、来源、使用条件、失败兜底。​

02​

PART​

场景上下文​

同一句话，放在不同场景里，意思会变。​

用户在中午 12 点说随便点个，和晚上 10 点说随便点个，系统推荐的东西就不该一样。用户在公司附近说附近，和在家里说附近，也不是同一个配送范围。​

场景上下文 就是把一句话放回真实业务现场。​

订外卖至少要看这些上下文。​

时间，上班日午餐、晚餐、夜宵。​

地点，当前定位、家、公司、酒店。​

历史，最近吃过什么，经常复购什么。​

偏好，不吃香菜、不吃辣、常选 25 到 35 元。​

平台状态，商家是否营业，商品是否售罄，配送是否可达。​

没有上下文，清淡点只是一个形容词。有了上下文，它才可能变成 轻食、粥、蒸菜、低油简餐 这些候选方向。​

​

​

产品经理设计意图识别时，不要把上下文当附加项。很多意图识别错误，本质上不是模型没听懂，是上下文没给够。​

上下文也不能越多越好。很多系统把历史偏好、当前位置、当前页面、平台库存一股脑塞给模型，最后模型反而会被噪音带偏。产品经理要先给上下文分层。​

第一层是 本次任务上下文，比如用户现在在哪、当前时间、刚刚说了什么。第二层是 用户长期上下文，比如忌口、常用地址、价格偏好。第三层是 业务实时上下文，比如商家营业、库存、配送时效、优惠券是否可用。三层更新频率不同，错误影响也不同，方案里要分别说明。​

03​

PART​

意图​

意图 不是用户说出的动词，而是用户希望系统完成的目标。​

帮我点外卖，这个表面意图是订餐。再往下拆，它可能是推荐外卖、复购上一单、指定商家下单、指定品类筛选，或者只是问附近有什么好吃的。​

外卖场景里，订外卖这个一级意图太粗，不能直接拿来驱动系统。​

你至少要拆出这些子意图。​

推荐外卖，用户还没确定吃什么。​

指定品类，用户想吃麻辣烫、轻食、牛肉饭。​

指定商品，用户已经知道要买哪一份。​

历史复购，用户说照上次那份来。​

订单操作，修改、取消、查询配送、售后。​

老王看意图树，最怕一张表里只有十几个大类。看起来整齐，落地时没法执行。​

意图分类的终点不是分类标签，而是下一步动作。 识别出用户要订外卖以后，系统到底是去搜索、推荐、加购物车，还是停下来确认，这才是产品方案要写清楚的地方。​

意图树最好按用户目标和系统动作来拆，不要按公司内部系统来拆。用户不会说我要调用商家检索系统、价格计算系统、订单系统，他只会说附近有什么、照上次来、帮我下单、订单怎么还没到。​

所以每个意图下面，建议写四个东西：典型说法、关键槽位、下一步动作、不能自动做的边界。比如历史复购意图，典型说法是照上次那份来，关键槽位是历史订单 ID 和当前可售状态，下一步动作是复查商品是否仍可买，边界是不能绕过用户确认直接付款。​

04​

PART​

实体​

实体 是用户话里提到的业务对象。​

帮我点个附近的外卖，清淡点，30 块以内，半小时能到，不要香菜，送到公司。​

这里的实体不止一个。​

地址实体，公司。​

价格实体，30 块以内。​

时间实体，半小时。​

口味实体，清淡。​

忌口实体，香菜。​

范围实体，附近。​

实体识别 不是把词圈出来就结束。产品系统还要把它们映射成真实业务对象。​

公司要映射到地址 ID。附近要映射到配送坐标和半径。30 块以内要映射到预计实付价。不要香菜要映射到商品规格、订单备注或商品过滤。​

​

​

产品经理写方案时，不能只写识别地址、识别金额、识别偏好。要继续写每个实体进入业务系统以后，落在哪个字段、调用哪个服务、失败时怎么处理。​

实体识别真正麻烦的地方，是抽出来以后还要归一化和消歧。公司不是一个稳定字段，它可能对应多个地址。附近也不是一个固定范围，它要结合配送半径、城市密度、商家可达范围一起算。30 块以内也要明确是商品原价、优惠后实付，还是包含配送费。​

比较稳的做法，是给实体加状态。已确认实体 可以直接进入后续流程，候选实体 需要用户选择，推断实体 只能用于推荐排序，冲突实体 必须触发澄清。这样研发和测试才知道，系统什么时候能继续走，什么时候必须停下来。​

05​

PART​

槽位​

槽位 是完成一个意图必须补齐的参数。​

用户说要订外卖，系统不是知道主意图就能下单。它还需要地址、商品、数量、规格、备注、优惠、支付方式，以及是否提交订单。​

这些信息就是槽位。​

外卖下单里，槽位可以分三类。​

必填槽位，地址、商品、数量。​

可默认槽位，数量默认 1 份，优惠默认最优。​

高风险槽位，提交订单和支付必须确认。​

不要把槽位理解成表单字段。字段是系统存储结构，槽位是 Agent 为了完成任务必须知道的信息。​

用户没说数量，默认一份就行。用户没说优惠，默认用最优券就行。用户没说支付方式，不能替他猜。用户没确认提交订单，不能直接下单。​

​

​

老王在评审 Agent 方案时，会特别看槽位表。哪些能默认，哪些要追问，哪些必须确认，这张表决定体验，也决定风险。​

槽位表别只写字段名，还要写补齐策略。地址可以从地址簿补，商品可以从推荐候选补，数量可以默认 1 份，优惠券可以默认最优组合，但支付方式、提交订单、修改地址这类槽位不能靠默认值糊过去。​

方案里可以把槽位状态分成五种：已提供、已推断、系统默认、待用户确认、无权限获取。比如用户说公司，地址簿里只有一个公司地址，可以标成已推断但下单前确认。用户说随便点个，商品槽位不能直接默认成某个商品，而应该先生成候选。​

06​

PART​

约束​

约束 是用户给任务加的边界。​

30 块以内、半小时能到、清淡点、不要香菜，这些都不是普通描述，而是筛选条件。​

Agent 如果不理解约束，就会变成只会搜索的机器人。​

约束还有 软硬之分。​

硬约束，不能吃香菜，超出配送范围不能下单，支付前必须确认。​

软约束，清淡点、快一点、别太贵、评分高一点。​

冲突约束，30 元以内和半小时能到可能同时满足不了。​

外卖推荐里最常见的问题，是系统把软约束当硬约束，或者把硬约束当软约束。​

不吃香菜是硬约束，不能随便忽略。清淡点是偏好，可以用排序处理。半小时能到要看平台预计时间，如果最近都要 38 分钟，系统应该让用户放宽条件，而不是假装能做到。​

​

​

产品经理要在方案里写清楚 约束优先级。没有优先级，Agent 遇到冲突时就只能乱选。​

约束处理要设计冲突策略。用户同时说 30 块以内、半小时能到、评分高、清淡，如果附近只有一家 35 块且 28 分钟送达的轻食，系统不能简单失败，也不能偷偷突破预算。它应该告诉用户哪个约束无法满足，并给出可选择的放宽方向。​

落到产品文档里，约束至少要写三件事：约束来源是什么、优先级怎么排、冲突时怎么解释。比如忌口优先级高于口味偏好，预算优先级高于评分排序，配送不可达直接终止，配送稍慢可以请求用户确认。​

​

​

07​

PART​

置信度​

Agent 不能假装永远听懂了。​

用户说点一份麦当劳板烧鸡腿堡套餐，送公司，不要冰可乐，系统理解的置信度很高。用户说午饭随便点个清淡的，系统知道大方向，但具体品类和商品不明确，置信度就只能算中等。​

置信度不只是模型给的分数，它还取决于业务条件是否完整。​

你可以把它拆成三层。​

语义置信度，用户到底想干什么。​

槽位置信度，执行所需参数是否齐。​

结果置信度，工具返回的候选是否真的满足要求。​

高置信低风险，可以直接执行到结果。高置信高风险，只能执行到确认页。中等置信，可以用默认值先推进。低置信，才需要追问。​

​

​

老王不建议把所有不确定都丢给用户。追问太多，Agent 就退化成表单。真正好的设计，是知道什么时候默认，什么时候确认，什么时候停。​

置信度最好不要只看一个总分。产品上更有用的是把置信度和风险等级放在一起判断。低风险的推荐，可以在中等置信度下先给候选；高风险的支付，即使语义置信度很高，也必须走确认。​

比如用户说就来第二个吧，语义上很明确，但如果当前候选列表已经刷新，第二个指的可能不是同一个商品，结果置信度就下降了。这时候系统要么锁定候选快照，要么重新确认商品名，不能只凭一句第二个继续下单。​

08​

PART​

澄清​

澄清不是把缺失字段问一遍。​

外卖场景里，用户通常很急。你问他想吃什么品类、预算多少、送到哪里、几点送、要不要发票，他会觉得这个 Agent 很笨。​

好的澄清只问影响执行和风险的关键问题。​

地址不明确，要问。商品规格必须选择，要问。超预算，要问。提交订单和支付，要确认。​

但用户没说数量，可以默认一份。没说优惠，可以自动用最优券。没说排序，可以按评分、时效、价格综合排。​

澄清策略可以设计成四种动作。​

直接执行，信息足够且低风险。​

默认补全，缺口不影响安全。​

追问澄清，缺口会改变结果。​

停止确认，涉及交易、支付、取消、地址变更。​

​

​

产品经理要把追问从聊天话术，前置成决策规则。不是文案写得客气就行，关键是系统知道哪些问题值得问。​

澄清问题要尽量设计成选择题，而不是开放题。不要问你想吃什么，可以问给你找三类：粥粉面、轻食、家常菜，选哪个方向。不要问预算多少，可以问 30 元以内找不到，放宽到 35 元可以吗。这样用户的认知负担低，系统也能直接继续执行。​

还要避免连续追问。好的 Agent 会先根据现有信息往前推进，到了真正影响结果的节点再问。比如地址不清先问地址，商品不明确先给候选，订单提交前再集中确认商品、价格、地址、送达时间，而不是一上来把所有字段问完。​

09​

PART​

任务拆解​

用户说帮我点个外卖，系统不能只执行一个动作。​

它背后是一条任务链。​

解析地址，查附近商家，筛营业状态，筛预算和配送时间，匹配清淡偏好，排除香菜风险，推荐候选，选择规格，加入购物车，使用优惠，展示确认页，用户确认后再提交订单。​

这就是任务拆解。​

Agent 的产品价值，不在于它能回答用户，而在于它能把一个模糊目标拆成多个可执行步骤。​

任务拆解还要区分自动步骤和确认步骤。​

搜索、筛选、排序、生成候选，可以自动。提交订单、支付、取消订单，不能自动。​

​

​

老王看任务拆解，会看每一步有没有输入、输出、失败兜底和风险等级。只画一条漂亮流程线，没写这些细节，后面研发和测试都接不住。​

任务拆解还要写清楚哪些步骤可以并行，哪些步骤必须串行。查附近商家、查优惠券、读取用户偏好可以并行；生成候选必须等商家、商品、配送时效和价格都校验完；提交订单必须等用户确认。​

每一步最好都有一个可观测结果。查商家返回多少家，筛预算剩多少个候选，排除香菜影响了哪些商品，配送时效是否命中半小时。这样不仅方便调试，也方便后续分析 Agent 为什么推荐了这家，而不是只留下一句模型觉得合适。​

10​

PART​

能力路由​

Agent 听懂用户以后，不能自己凭空把外卖送到你楼下。​

它要调用外卖搜索、商品库、配送时效、价格计算、优惠券、购物车、订单、支付、售后这些业务能力。​

能力路由就是决定下一步交给哪个系统处理。​

用户说附近，路由到定位和商家搜索。用户说上次那家，路由到历史订单。用户说 30 块以内，路由到价格计算。用户说不要香菜，路由到商品规格和备注。用户确认下单，路由到订单系统。​

这里有个常见误区，把所有理解都压给大模型。​

大模型适合理解自然语言，但价格、库存、配送时效、商家营业状态，必须查业务系统。否则答案听起来聪明，执行时一碰就碎。​

​

​

产品经理写 Agent 方案时，一定要把自然语言理解和业务能力调用分开。模型负责理解，系统负责验证，工具负责执行。​

能力路由要有降级路径。外卖搜索接口超时，是否还能用缓存候选。配送时效接口失败，是否可以展示商家但标注时效待确认。优惠券接口失败，是否允许先给原价候选。不同能力失败，对用户体验和交易风险的影响不一样。​

还要给每个工具调用写输入输出契约。比如商家搜索需要地址坐标、配送半径、营业状态过滤；价格计算需要商品、规格、配送费、优惠券；订单提交需要用户确认快照。没有这些契约，Agent 只会停留在调用工具四个字，研发落地时会反复返工。​

11​

PART​

风险权限​

外卖是交易场景，风险权限不能靠感觉。​

推荐一家店是低风险。读取定位和历史订单是中风险。提交订单、支付、取消已支付订单、修改地址，都是高风险。​

Agent 越能办事，越需要边界。​

边界可以这样设计。​

低风险动作自动做，比如搜索、筛选、推荐。​

中风险动作要求授权，比如定位、历史订单、地址簿。​

高风险动作必须确认，比如提交、支付、取消、改地址。​

这不是保守，而是交易产品的基本功。​

用户说帮我点外卖，不代表允许你直接付款。用户说取消，也不一定是取消已支付订单，可能只是不要当前推荐。​

​

​

老王一直强调，Agent 的智能不能建立在越权上。越会执行，越要把确认、授权、审计和可撤销设计清楚。​

风险权限还要和用户可感知的成本绑定。搜索错了，成本很低。推荐错了，用户最多换一个。下单错了，涉及钱、地址、隐私、骑手履约，成本马上变高。所以确认不只是法律合规动作，也是产品体验的一部分。​

方案里建议给高风险动作设计确认快照。快照里至少包含商品、规格、价格、优惠、配送费、地址、预计送达时间和支付方式。用户确认的是这一次快照，不是泛泛地同意 Agent 帮我点外卖。后续任何关键字段变化，都应该重新确认。​

12​

PART​

状态记忆​

Agent 不是一次性问答。​

用户可能先说点个清淡的，系统推荐鸡胸肉轻食饭。用户接着说不要鸡胸肉，换个热的。这个时候系统要知道，当前任务还是订外卖，只是新增了排除鸡胸肉和偏好热食。​

这就是状态记忆。​

它要记住当前任务是什么，执行到哪一步，用户已经确认过哪些条件，哪些候选被排除，购物车里有什么，哪些动作还没确认。​

状态记忆和长期记忆也要区分。​

不吃香菜可以是长期偏好。今天想吃清淡，只适用于本次任务。工作日中午常送公司，可以是场景偏好。用户刚说不要鸡胸肉，只是当前任务里的临时排除项。​

​

​

如果没有状态记忆，多轮对话就会断。用户说就第 2 个吧，系统不知道第 2 个是谁。用户说加杯喝的，系统不知道加到哪个订单里。​

状态记忆要有边界和过期机制。本次对话里的候选列表，可能 5 分钟后库存和配送时间就变了，不能长期复用。今天想吃清淡，也不能直接写成永久偏好。用户明确说以后都不要香菜，才适合沉淀为长期偏好。​

产品方案里可以把记忆分成三类：会话状态、任务状态、长期偏好。会话状态解决用户刚才说了什么，任务状态解决订单流程走到哪一步，长期偏好解决下次是否还要继续用。三类记忆的读取、更新、删除规则不同，必须分开设计。​

13​

PART​

最后​

很多团队做 Agent，卡在一个误区里，只设计识别，不设计执行。​

识别订外卖只是开始。真正的产品方案，要继续回答 12 个问题。​

用户输入从哪里来。​

场景上下文怎么补。​

意图树怎么分层。​

实体如何映射成业务对象。​

槽位哪些能默认，哪些必须补齐。​

约束怎么排序和冲突处理。​

置信度低时怎么推进。​

澄清什么时候问，问什么。​

任务怎么拆成可执行步骤。​

每一步路由到哪个系统。​

哪些动作需要授权和确认。​

多轮状态怎么持续维护。​

把这 12 个问题答清楚，Agent 才能从能聊天走向能办事。​

老王最后给一个判断标准。​

如果你的意图识别方案，只能输出用户想订外卖，那它还只是一个分类器。​

如果它能输出用户要在公司地址附近，找 30 元以内、30 分钟左右、偏清淡、不要香菜的餐品，系统先推荐候选，用户确认后再提交订单和支付，这才是 Agent 产品方案。​

更进一步，一个成熟的方案还要能解释每一步为什么这么做。为什么选这家店，为什么没有选另一家，为什么需要追问地址，为什么必须确认支付，为什么这次不能满足 30 分钟送达。解释能力不是写给用户看的花活，而是写给产品、研发、测试、运营一起定位问题的依据。​

产品经理做 Agent，不要只盯着模型能不能听懂。要盯着系统听懂以后，能不能安全、准确、低成本地往下一步走。​