Agent 的需求理解质量如何具体实现：从意图识别到槽位补全、追问与确认机制

文章目录一、需求理解的本质从“识别意图”升级为“构建可执行任务”二、第一步定义任务类型或意图模板三、第二步为每类任务设计槽位 Schema四、第三步用结构化输出承接模型理解结果五、第四步意图识别、槽位抽取和参数解析分层处理1. 意图识别2. 槽位抽取3. 参数标准化4. 参数校验六、第五步优先从上下文、用户画像和系统状态中补全信息七、第六步判断哪些信息可以默认哪些必须追问八、第七步为模糊偏好设计默认策略九、第八步高风险操作必须执行前确认十、第九步后端编排需求理解流程十一、第十步把追问也做成可评估对象十二、第十一步需求理解质量如何评估1. 意图识别准确率2. 槽位抽取准确率3. 参数标准化准确率4. 上下文继承准确率5. 缺失信息判断准确率6. 追问必要性判断7. 高风险确认准确率8. 任务可执行率十三、一个完整示例订机票需求理解流程1. 初步理解2. 参数标准化3. 缺失信息判断4. 合并追问5. 用户补充6. 搜索航班7. 下单前确认十四、工程实现建议十五、结论好的 Agent 不是“多问”而是“会判断”在 Agent 系统中需求理解质量并不只是传统 NLP 里的“意图识别准确率”。一个真正可用的 Agent不仅要知道用户大概要做什么还要理解用户的目标、约束条件、偏好、上下文依赖、系统状态以及当前任务还缺少哪些关键信息。换句话说需求理解质量衡量的是 Agent 是否能回答清楚以下几个问题用户到底要完成什么任务用户已经提供了哪些信息哪些信息可以从上下文、用户画像或系统状态中继承哪些信息可以通过默认策略合理处理哪些信息缺失但不影响继续执行哪些信息缺失且必须追问哪些操作在执行前必须二次确认这类能力不是单靠一个 Prompt 就能稳定实现的而是需要把意图识别、槽位抽取、结构化输出、上下文管理、缺失信息判断、追问策略、工具调用和安全确认机制组合成完整链路。一、需求理解的本质从“识别意图”升级为“构建可执行任务”传统聊天机器人通常会先判断用户意图例如“订机票”“查订单”“修改密码”“创建会议”。但 Agent 要进一步把自然语言请求转化为一个可执行任务对象。例如用户说明天下午帮我约一下王总别太晚线上就行。一个低质量系统可能只识别出“创建会议”意图然后立刻追问一堆问题会议几点会议多久王总是谁会议主题是什么用什么会议工具是否发送邀请但一个更好的 Agent 应该先构建任务理解{intent:create_calendar_event,goal:预约与王总的线上会议,participants:[王总],date:明天,time_preference:下午不要太晚,location_type:online,missing_fields:[具体参会人身份或联系方式,具体时间],can_default:{duration:30分钟,meeting_tool:默认线上会议工具},need_user_clarification:true,clarification_reason:无法唯一确定王总和具体会议时间}这就是从“意图识别”升级为“任务建模”。OpenAI Agents SDK 对 Agent 的定义也体现了这一点Agent 是由 LLM、指令、工具以及可选的 handoffs、guardrails 和 structured outputs 等运行时能力组成的应用单元不只是一个分类器。(OpenAI)二、第一步定义任务类型或意图模板需求理解的第一层是定义系统支持哪些任务类型。任务类型可以来自业务场景例如create_calendar_event 创建日程 book_flight 预订机票 query_order 查询订单 refund_order 申请退款 send_email 发送邮件 delete_file 删除文件 generate_report 生成报告 search_knowledge_base 查询知识库每个任务类型都应该定义任务名称 任务描述 适用场景 必要槽位 可选槽位 默认策略 可继承字段 是否需要工具调用 是否属于高风险操作 执行前是否需要确认例如“创建会议”的任务模板可以是{intent:create_calendar_event,required_slots:[participants,date,time],optional_slots:[duration,title,location,meeting_tool,description],defaults:{duration:30分钟,meeting_tool:Google Meet 或系统默认会议工具},confirmation_required:true}这样做的目的是让 Agent 不只是“理解一句话”而是能把用户输入映射到稳定的业务结构中。Dialogflow CX 官方文档中也有类似思想参数用于捕获并引用终端用户在会话中提供的值每个参数都有名称和实体类型相比原始文本参数是可被逻辑处理和响应生成使用的结构化数据。(Google Cloud Documentation)三、第二步为每类任务设计槽位 Schema任务类型确定后需要为每类任务设计槽位 schema。槽位可以理解为执行任务所需的结构化字段。以“订机票”为例{intent:book_flight,slots:{departure_city:{type:string,required:true,source:[user_input,user_profile,context]},arrival_city:{type:string,required:true},departure_date:{type:date,required:true},return_date:{type:date,required:false},passengers:{type:array,required:true},cabin_class:{type:enum,values:[economy,premium_economy,business,first],default:economy},price_preference:{type:string,required:false},time_preference:{type:string,required:false}}}这样 Agent 才能判断“明天”应该解析成具体日期。“上海到北京”对应出发地和目的地。“别太晚”是时间偏好不是具体时间。“便宜点”是价格偏好不是严格预算。“帮我订”属于高风险动作最终下单前必须确认。Rasa 官方文档也把 slot 描述为助手收集或推断出的有状态 key-value 信息Collect step 用于请求用户提供信息并填充 slot直到该 slot 被填充后才继续执行后续流程。(rasa.com)四、第三步用结构化输出承接模型理解结果在大模型 Agent 中不能只让模型自由输出一段自然语言解释而应该让模型按照 schema 输出结构化结果。这样后端才能稳定判断下一步是执行、追问、确认还是拒绝。OpenAI Structured Outputs 官方文档说明结构化输出可以确保模型响应符合开发者提供的 JSON Schema避免模型遗漏必填 key 或生成无效枚举值。(OpenAI开发者)例如可以让模型输出{intent:book_flight,confidence:0.91,slots:{departure_city:上海,arrival_city:北京,departure_date:2026-04-28,return_date:null,passengers:null,cabin_class:economy,price_preference:尽量便宜,time_preference:不要太晚},missing_required_slots:[passengers],ambiguous_slots:[{slot:time_preference,value:不要太晚,interpretation:优先选择18:00前到达或出发的航班}],can_proceed_with_defaults:false,need_clarification:true,clarification_questions:[请问乘机人是谁],need_confirmation_before_action:true,risk_level:high}这里的重点不是让模型“回答用户”而是先让模型“生成一个可执行的任务理解对象”。后端可以基于这个对象继续做业务判断。五、第四步意图识别、槽位抽取和参数解析分层处理一个稳定的实现通常不会把所有事情都交给模型一次性完成而是分层处理用户输入 ↓ 意图识别 ↓ 槽位抽取 ↓ 参数标准化 ↓ 上下文继承 ↓ 缺失信息判断 ↓ 追问或执行1. 意图识别判断用户要做什么例如{intent:create_calendar_event,confidence:0.88}如果置信度较低可以进入澄清流程你是想创建一个日程还是只是查询王总的空闲时间2. 槽位抽取从用户输入中抽取任务参数{participants:[王总],date_text:明天,time_preference:下午别太晚,location_type:online}3. 参数标准化把自然语言表达转成系统可处理格式{date:2026-04-28,time_window:{start:13:00,end:17:30},location_type:video_meeting}这一步非常关键。用户说的“明天”“下周五”“月底前”“别太晚”“便宜点”“附近”“尽快”都不能直接丢给业务系统而要转成可执行约束。4. 参数校验检查参数是否合法日期是否在未来 邮箱格式是否正确 金额是否超过限制 用户是否有权限操作目标资源 订单是否属于当前用户 删除对象是否存在OpenAI 的 function calling 文档说明函数工具可以通过 JSON Schema 定义让模型与应用提供的数据和动作连接模型可以决定调用哪些函数以及使用什么参数。(OpenAI开发者) 但参数是否真正合法、是否有权限执行仍然应该由后端校验。六、第五步优先从上下文、用户画像和系统状态中补全信息好的 Agent 不应该一缺信息就追问。追问会打断任务流降低用户体验。更合理的策略是先看当前用户输入有没有 再看当前会话上下文有没有 再看用户画像或长期偏好有没有 再看系统状态有没有 再看是否可以使用默认值 最后才判断是否必须追问例如用户说还是发给上次那个客户吧。如果上下文中刚刚提到“上次那个客户”是aliceexample.comAgent 可以继承这个对象而不是机械追问“请问客户是谁”。又如用户说明天早上继续安排那个会议。Agent 需要从上下文中继承“那个会议”的主题、参会人、会议方式然后只补齐日期和时间。一个后端状态对象可以这样设计{session_context:{last_task:create_calendar_event,last_participants:[aliceexample.com],last_topic:项目评审,last_location_type:online},user_profile:{default_meeting_duration:30分钟,work_hours:{start:09:00,end:18:00},preferred_meeting_tool:Google Meet},system_state:{calendar_available:true,timezone:Asia/Tokyo}}然后由补全器生成{participants:{value:[aliceexample.com],source:session_context,confidence:0.86},duration:{value:30分钟,source:user_profile,confidence:0.95},timezone:{value:Asia/Tokyo,source:system_state,confidence:1.0}}Rasa 的 slot 机制也体现了类似思想slot 是助手持有的状态信息可以表示用户已经提供或助手已经推断出的值。(rasa.com)七、第六步判断哪些信息可以默认哪些必须追问需求理解质量的关键不在于“发现缺失信息”而在于“判断缺失信息是否真的需要问”。可以把槽位分成四类类型示例处理方式可直接解析“明天”“下周五”“三点后”转成具体日期或时间范围可默认处理“别太晚”“别太贵”“随便找个会议链接”使用业务默认策略可继承处理“还是发给他”“继续上次那个”从上下文或用户画像继承必须追问出发地、乘客、收件人、付款方式合并追问例如“明天” → 可以转成具体日期 “别太晚” → 可以转成时间偏好 “便宜点” → 可以转成排序策略 “从这里出发” → 如果有定位权限可继承否则追问 “给王总发邮件” → 如果联系人唯一可继承否则追问 “帮我下单” → 执行前必须确认追问策略应该遵循一个原则只问影响下一步执行的关键信息并尽量合并问题。不好的追问请问出发地是哪里请问目的地是哪里请问日期是哪天请问乘客是谁请问舱位是什么更好的追问我还需要确认两项信息从哪里出发以及乘机人是谁舱位我可以先按经济舱处理。这样既减少打断又保持任务可执行。八、第七步为模糊偏好设计默认策略用户经常不会给出精确参数而是使用偏好表达别太晚 别太贵 尽快 附近 安静一点 正式一点 简单一点 性价比高 不要太复杂这些表达不应该一律追问而应该转成默认策略。例如订票场景{preference:别太晚,policy:{type:time_preference,default_interpretation:优先选择18:00前到达,strict:false}}餐厅推荐场景{preference:别太贵,policy:{type:price_preference,default_interpretation:优先选择中低价位人均不超过默认预算,strict:false}}会议安排场景{preference:别太晚,policy:{type:time_preference,default_interpretation:优先安排在工作时间内且不晚于17:30开始,strict:false}}这里要注意偏好不是硬约束。Agent 可以先按默认策略执行搜索或规划然后把解释带给用户我按“不要太晚”理解为优先选择 18:00 前到达的航班先帮你筛选这一类。这种做法比直接追问“别太晚是什么意思”更自然。九、第八步高风险操作必须执行前确认需求理解质量还包括一个重要能力判断哪些动作不能直接执行。以下操作通常需要确认下单 支付 退款 删除 发送邮件 发送消息 提交表单 修改生产数据 取消订单 公开发布内容 授权第三方访问例如用户说帮我把这封邮件发给客户。如果邮件内容已经生成Agent 不应该直接发送而应该确认我已准备好邮件收件人是 aliceexample.com主题是“项目报价确认”。确认后我再发送。再如用户说把这些旧文件都删掉。Agent 必须明确列出将删除的对象并让用户确认我找到 12 个符合条件的文件。删除后可能无法恢复请确认是否删除这 12 个文件。OpenAI Agents SDK 的 guardrails 文档说明护栏可以在工作流不同阶段运行输入护栏用于第一个 Agent输出护栏用于最终输出 Agent工具护栏会在每次自定义函数工具调用时运行并可在执行前后检查工具输入与输出。(OpenAI)因此在实现上可以把高风险确认设计成工具调用前的 guardrail{tool:send_email,risk_level:medium,requires_confirmation:true,confirmation_summary:{to:aliceexample.com,subject:项目报价确认,body_preview:Alice 您好以下是本次项目报价...}}只有用户确认后后端才真正调用发送工具。十、第九步后端编排需求理解流程一个比较完整的后端实现可以拆成以下模块Intent Router 意图路由 Slot Extractor 槽位抽取器 Normalizer 参数标准化器 Context Resolver 上下文补全器 Profile Resolver 用户画像补全器 Default Policy Engine 默认策略引擎 Missing Slot Analyzer 缺失信息分析器 Clarification Planner 追问规划器 Risk Classifier 风险分类器 Confirmation Manager 确认管理器 Tool Executor 工具执行器 Guardrail Engine 护栏引擎 Evaluation Logger 评估日志器整体链路可以是用户输入 ↓ 识别任务类型 ↓ 抽取槽位 ↓ 标准化参数 ↓ 从上下文 / 用户画像 / 系统状态补全 ↓ 判断缺失字段 ↓ 判断是否可以默认处理 ↓ 判断是否需要追问 ↓ 判断是否高风险 ↓ 执行工具或请求确认 ↓ 记录理解结果和评估数据对应伪代码如下defunderstand_user_request(user_input,session_context,user_profile,system_state):# 1. 意图识别intent_resultclassify_intent(user_input)# 2. 加载任务 schematask_schemaload_task_schema(intent_result.intent)# 3. 槽位抽取extracted_slotsextract_slots(user_input,task_schema)# 4. 参数标准化normalized_slotsnormalize_slots(extracted_slots,timezonesystem_state.timezone,localeuser_profile.locale)# 5. 上下文补全resolved_slotsresolve_from_context(normalized_slots,session_context,user_profile,system_state,task_schema)# 6. 默认策略补全resolved_slotsapply_default_policies(resolved_slots,task_schema.defaults)# 7. 缺失信息分析missing_analysisanalyze_missing_slots(resolved_slots,task_schema.required_slots)# 8. 风险判断riskclassify_risk(intentintent_result.intent,slotsresolved_slots,task_schematask_schema)# 9. 追问或确认ifmissing_analysis.must_ask:returnbuild_clarification_response(missing_analysis)ifrisk.requires_confirmation:returnbuild_confirmation_response(intent_result.intent,resolved_slots)# 10. 可以执行returnbuild_executable_task(intent_result.intent,resolved_slots)十一、第十步把追问也做成可评估对象很多 Agent 的问题不在于不能追问而是追问质量差。常见问题包括问了不必要的问题 一次只问一个问题导致多轮打断 重复询问已经提供的信息 没有解释为什么要问 没有区分可选信息和必填信息 没有利用上下文继承因此追问本身也应该结构化{need_clarification:true,missing_slots:[{slot:passengers,reason:订票必须知道乘机人,priority:high},{slot:departure_city,reason:当前上下文无法确定出发地,priority:high}],optional_slots_not_asked:[{slot:cabin_class,default:economy,reason:可以默认经济舱}],question:我还需要确认两项信息从哪里出发以及乘机人是谁舱位我可以先按经济舱处理。}这样可以避免 Agent 机械地逐字段追问。十二、第十一步需求理解质量如何评估需求理解质量最终要靠评估体系衡量而不是只看模型回答是否“看起来合理”。可以从以下维度评估1. 意图识别准确率Agent 是否正确判断用户要做什么。用户要创建会议是否误判为查询日程 用户要退款是否误判为查询订单 用户只是询问信息是否误判为执行操作2. 槽位抽取准确率Agent 是否正确抽取任务参数。“明天下午三点”是否正确解析为日期和时间 “发给王总”是否正确识别为收件人 “上海到北京”是否正确识别出发地和目的地3. 参数标准化准确率自然语言是否被转成系统可执行格式。“明天” → 具体日期 “下周五” → 具体日期 “别太晚” → 时间偏好 “便宜点” → 排序策略4. 上下文继承准确率Agent 是否正确使用历史信息。是否继承了上一次提到的客户 是否错误继承了过期上下文 是否把“他”解析成了正确联系人5. 缺失信息判断准确率Agent 是否知道什么还缺。是否发现缺少乘客信息 是否发现缺少收件人 是否发现缺少具体执行对象6. 追问必要性判断Agent 是否只问必须问的问题。是否没有追问可默认处理的信息 是否追问了影响执行的关键信息 是否合并追问减少多轮打断7. 高风险确认准确率Agent 是否在关键操作前请求确认。发送前是否确认 支付前是否确认 删除前是否确认 提交前是否确认8. 任务可执行率最终生成的任务对象是否能被后端直接执行。schema 是否完整 参数是否合法 权限是否可校验 工具调用是否明确 风险状态是否清晰十三、一个完整示例订机票需求理解流程用户输入帮我订明天下午从上海到北京的机票别太晚便宜点。1. 初步理解{intent:book_flight,slots:{departure_city:上海,arrival_city:北京,departure_date:2026-04-28,time_preference:下午别太晚,price_preference:便宜点}}2. 参数标准化{departure_city:上海,arrival_city:北京,departure_date:2026-04-28,departure_time_window:{start:12:00,end:18:00},sort_policy:[price_ascending,arrival_before_20:00]}3. 缺失信息判断{missing_required_slots:[passengers],defaulted_slots:{cabin_class:economy},need_clarification:true}4. 合并追问Agent 不应该问你要什么舱位你能接受多少钱你几点出发乘客是谁更好的回答是我可以先按经济舱、价格优先并优先筛选明天下午出发且不太晚到达的航班。还需要确认乘机人是谁5. 用户补充就我自己。系统从用户画像中补全乘机人信息{passengers:[{name:当前用户,source:user_profile}]}6. 搜索航班Agent 可以调用航班搜索工具但不能直接下单。{tool:search_flights,arguments:{departure_city:上海,arrival_city:北京,departure_date:2026-04-28,time_window:{start:12:00,end:18:00},passengers:1,cabin_class:economy,sort:price_ascending}}7. 下单前确认如果用户选择某个航班并说“就这个”Agent 仍然需要确认确认预订4 月 28 日上海飞北京经济舱乘机人为你本人票价 980 元。确认后我再下单。这就是需求理解质量在真实任务中的体现能执行但不越权能默认但不乱猜能追问但不打断过度。十四、工程实现建议如果要在项目中落地可以按以下优先级实现。第一阶段先建立任务 schema。不要一开始就追求通用智能体先把核心业务任务定义清楚包括必填槽位、可选槽位、默认值、风险等级和确认策略。第二阶段使用结构化输出。让模型输出稳定 JSON而不是自然语言。后端只消费结构化结果。第三阶段实现上下文补全。把当前会话、历史任务、用户画像和系统状态统一成 context object供模型和后端补全槽位。第四阶段实现缺失信息分析器。不是缺什么就问什么而是判断哪些必须问、哪些可以继承、哪些可以默认、哪些可以稍后再问。第五阶段实现确认与护栏。对高风险工具调用设置确认机制对工具输入输出做 guardrail 校验。第六阶段建设评估集。收集真实用户请求标注 intent、slots、missing slots、default policy、clarification question 和 confirmation requirement用于持续评估 Agent 需求理解质量。十五、结论好的 Agent 不是“多问”而是“会判断”需求理解质量的核心不是 Agent 能不能识别出一个意图而是它能否把用户的自然语言请求转化为一个安全、完整、可执行的任务对象。一个高质量 Agent 应该做到能判断用户要做什么 能抽取用户已经提供的信息 能把自然语言参数标准化 能从上下文、用户画像和系统状态中补全信息 能区分硬约束和软偏好 能合理使用默认策略 能只追问真正影响执行的关键信息 能在高风险操作前请求确认 能把最终任务交给后端稳定执行因此需求理解质量不是单点能力而是一套完整工程链路。它由任务 schema、槽位抽取、结构化输出、上下文管理、默认策略、追问规划、确认机制和护栏系统共同构成。真正优秀的 Agent不是机械预设一堆问题也不是遇到缺失信息就打断用户而是能在“理解、补全、追问、确认、执行”之间做出合理判断。