AI Agent落地不崩的根基：意图识别与变量聚合实战解析

先声明一下，这篇东西不是我坐在家里拍脑袋想出来的。过去两个月我一直在调一个基于大模型的客服质检与工单自动流转系统，表面上看是“对话管理”，真正动手以后发现，最折磨人的根本不是模型推理，而是两个看起来不起眼、实则撑起整个业务闭环的环节：意图识别和变量聚合。这两个环节做不好，后面的规划、编排、工具调用全都要跟着崩。这篇文章就把我在这个模拟项目X里反复踩坑、反复验证之后的思路和具体做法整理出来，希望能帮正在搞Agent落地的朋友少走几步弯路。

1. 意图识别与变量聚合，为什么是Agent的地基

先说个直观感受。很多人一提Agent就想到“大模型会自己规划、自己调用工具”，听起来很美好，但实际落到业务里，你会发现一个尴尬的事实：大模型再聪明，如果连用户到底想干什么都没搞清，后面的规划再精巧都是白搭。我这边有个数据佐证这个观点：在模拟项目X的测试集里，意图识别准确率每提升3个百分点，端到端工单流转的一次通过率就能提高近8个百分点。这个相关性足以说明，意图识别不是“入口环节”，而是整个Agent的承重墙。

那变量聚合又是什么？简单的说，就是对话里散落的“关键信息”能不能被完整捞出来。我举个自己的例子：用户说“我想把之前那个订单退了，就是上周三下午买的那双鞋”。这句话里，意图是“退款”，但真正让系统能干活的是一个不能少的信息组合——订单时间（上周三）、商品（那双鞋）、动作（退款）。如果Agent只是识别出“退款”这两个字，却没有抓住“上周三”“那双鞋”这两个变量，后续工具调度时就会因为缺参数而反复追问用户，体验会非常糟糕。

所以，意图识别和变量聚合这两个环节，本质上是一对配合关系：意图负责回答“用户想要什么结果”，变量负责回答“执行这个结果需要哪些原料”。两者分开处理，反而容易各管一摊；放在一起看，才是一个完整的信息抽取链路。我后来的系统设计，也是把这两块放在同一个上下文处理器里联合调试的。

下面这张表能比较直观地说明它们的差异和配合关系：

我见过不少团队花大精力在规划链（Planning）和工具编排上，意图识别用简单分类模型顶着，变量抽取完全依赖模型自由生成，结果一到复杂场景就“露馅”。所以我写这篇文章的态度很明确：意图识别和变量聚合不是“基础模块”，而是Agent效果的天花板，值得投入和模型选型一样多的精力。

2. 意图识别方案选型，我为什么放弃了纯Prompt分类

2.1 从正则匹配到大模型分类的演进路线

最早我做意图识别的时候，用的是最古老的方案：正则表达式加关键词规则。比如用户消息里出现“退”“换”“取消”，就归到售后意图。这套方案在请求量小、话术固定的场景下确实能跑，但很快就被现实教训了。用户根本不会按照你预设的词来说话——出现“我不想要了，给我弄一下”这种表述时，关键词一个都没有，语义却是再明显不过的退款意图。

后来我换成了微调之后的文本分类模型。效果比正则好不少，至少能处理一些语义上的变体。但分类模型有一个先天缺陷：它只能打标签，不能解释为什么打这个标签，而且对多意图的混合表达处理起来很痛苦。比如“帮我查一下订单到哪了，顺便把这个地址改一下”，这句话里有两个意图，查询物流和修改地址，分类模型只能二选一，或者强行设一个“复合意图”标签，但复合意图的组合数量是指数级增长的，根本枚举不完。

再往后就是大模型时代了，我一开始也是随大流用Prompt让大模型输出意图标签。但简单Prompt的问题在于：输出不稳定。同一个“我要投诉”在不同温度参数下可能被分到“售后”或“客诉”，边界很模糊。后来我把“意图分类”升级成“意图解析”——不只要标签，还要标签对应的置信度、关键证据片段、以及子意图结构，才算真正把大模型在语义理解上的优势用起来。

2.2 结构化输出的意图Schema设计

这里分享一个我觉得最重要的实践：给意图识别设计一个结构化的Schema，而不是让模型输出自由文本。我这个Schema长这样：

{ "intent": "after_sale_refund", "confidence": 0.92, "evidence": ["我想退了", "上周三买的"], "sub_intent": "refund_order", "slots_required": ["order_time", "product_desc"], "slots_provided": ["order_time", "product_desc"] }

这个设计有三个值得注意的点。

第一，evidence字段非常有用。它记录的是模型判断依据的原文片段，一旦发现某个case分类错误，可以直接看evidence来判断是模型理解错了，还是输入本身就有歧义，大大降低了debug成本。

第二，slots_required和slots_provided这两个字段是在意图识别阶段就为变量聚合做铺垫的。什么意思呢？就是在判断意图的同时，让模型顺手检查一下：完成这个意图需要哪些槽位，用户这次已经提供了哪些。这样后面的变量聚合环节就有了明确的工作清单，而不是盲目抽取所有实体。

第三，confidence不是摆设。我一开始也不信模型自己给的置信度，后来发现这个值在多数情况下还是能反映可靠程度的。我最新的处理方式是：置信度高于0.85直接采纳；在0.6到0.85之间进入人工复核或让模型二次确认；低于0.6则走默认的兜底意图（clarification），先把话说清楚再往下走。

还需要说明的是，这套Schema不是一次定死的。我大概每跑一周数据就会回头看一眼误判案例，把一些真正的难点表达（比如反讽、省略主语）补充到Few-shot示例里。大模型分类的Few-shot示例质量，远比数量重要，精选五六个典型case，比硬塞三五十个模糊案例有用得多。

2.3 多轮对话里的意图修正与歧义处理

单轮意图识别其实相对好做，真正的挑战在多轮对话。用户在对话过程中会不断补充信息、修改观点、甚至推翻前面的诉求。举个我实际遇到的情况：

用户第一句话说“我要买个大一点的显示器”，意图是 purchase，变量是“大一点的”。第二句又说“等等，其实我是想换掉现在这个旧的”，这时候意图就变了，从购买变成了换货。如果系统不对多轮上下文做意图修正，就会按照最初的“购买”意图继续走，整个流程就歪了。

我的解决方案是把“意图状态”维护在一个轻量级的上下文中，每一轮新输入不是独立判断，而是结合前一轮的意图和已填充的变量做增量判断。用大模型去判断“当前这句话是一个独立意图、是对原意图的修正、还是对原意图的补充”，这个三分类可以大大减少误判。

实际操作上，我在Prompt里加了一个“对话状态摘要”段，每次调用时把最近的意图、已确认的变量、待补充的变量清单拼接进去，让模型基于这个状态做判断。这里有个经验要提醒你：不要把整个对话历史都塞进去，token太长反而降低准确率；保留最近两到三轮的高密度信息就足够了，再早的信息只需压缩成状态摘要。

歧义处理方面，我走的是“先确认再执行”的路线。当confidence不高、或者关键证据互相矛盾时，我会让Agent主动生成一句确认话术，而不是硬猜。比如用户说“这个也不要了”，系统没法确认“这个”是哪个商品的时候，就回复“你说的‘这个’是指刚才那款机械键盘吗？”，而不是默认为购物车里第一个商品。这个“主动询问”的兜底策略，虽然看起来AI有点笨，但实际业务里用户接受度非常高，远好于自作主张后被打差评。

3. 变量聚合的两种路径，以及它们如何分工协作

3.1 规则抽取与大模型抽取的边界划分

变量聚合这个环节，技术选型上有个常见的困惑：到底是继续依赖大模型，还是退回去用规则？我的结论是：不要二选一，而是按照变量类型划分边界，各自负责自己擅长的部分。

拿我的模拟项目X举例，系统里需要聚合的变量大致分三类：

第一类是强规则变量，比如订单号、手机号、日期时间、金额数字。这类变量格式清晰、规律性强，用正则表达式或者规则模板就能准确抽取，根本不需要大模型出场。比如“2025-03-11”这种日期格式，“订单号：D831927377”这种模式，规则抽取的准确率可以轻松做到99%以上，而且速度极快、成本为零。

第二类是弱规则变量，比如商品名称、地址、人名。这类变量没有严格的格式约束，但有明显的领域特征。我的做法是用一个实体识别模型做初步抽取，再用大模型做归一化。举个例子，用户说“我要那个银色的27寸”，实体识别模型能抓出“银色”“27寸”，但要让系统真正理解这是“颜色=银色、尺寸=27英寸”，还得靠大模型做一次语义归一。

第三类是上下文推断变量，比如指代词（“这个”“那个”“刚才说的”）、省略成分（“一样的那款”）。这类变量没有规则可循，必须依赖对多轮对话的语义理解，只能交给大模型处理。比如用户说“就是上次我朋友推荐的那个”，要准确解析出“朋友推荐的那款产品”，就非得结合历史对话不可。

上面这个分类可能看起来很简单，但你真去实现的时候，会发现真正的难点在于判断一个变量到底属于哪一类。我的经验是：宁可先归到规则的范畴去试一试，如果发现规则覆盖不了再多补充规则，直到确实搞不定再转给大模型。这样做的原因是，规则抽取的结果稳定、可预期，大模型抽取虽然灵活，但偶尔会“发挥过头”，把不该抽的也抽进来，这种不确定性对后续流程是个隐患。

3.2 变量生命周期：抽取、验证、更新、失效

变量聚合的另一个关键设计，是给每个变量定义一个生命周期。我最初没有这个概念，把对话里抽取到的所有变量都丢进一个全局变量池，后来发现会有问题：用户改主意了，之前抽到的旧变量还留在池子里，系统还以为那是用户当前的需求。比如用户先说“我要上海的地址”，后一句改成“发的北京吧”，如果旧值没被正确覆盖，系统就会把订单发往上海。

后来我给变量池加了一套完整的状态管理：

• 抽取：从当前轮对话中抽取出新的变量值，标记为“待确认”；
• 验证：对变量做合法性检查，比如手机号是不是11位、日期是不是合理的格式；
• 更新：如果用户对某个变量给出了新值，旧值直接覆盖，不搞保留多个候选；
• 失效：当用户明确表达“不要之前那个了”或者意图变更时，相关的变量进入失效状态，不能再被后续流程使用。

这里面最重要的一个细节是“更新时间线”。我给每个变量记录了三份时间戳：首次出现时间、最近更新时间、最后确认时间。为什么要这样？因为用户可能在第5轮确认了地址，又在第12轮补充了备注，这时候系统需要知道变量的“新鲜度”。如果某个变量已经超过三轮对话没有更新，我倾向于在进入工具调用前主动让用户确认一次，防止信息过期出问题。

另外，变量优先级也是必不可少的。同一个变量如果出现了多个候选值，系统不自动选择“最新值”，而是结合置信度和意图关联度做加权。举个例子，用户说“收货人电话是138xxxx，你记一下——不是，用139xxxx那个”，如果不做优先级处理，模型很可能把第二个号码直接覆盖上去，但对话语境里“不是”是一个明显的否定信号，应该抛弃旧值采纳新值，这时候权重的设计就比简单的“后说为准”要靠谱得多。

这个生命周期管理看着不难，但带来一个直观收益：工具调用的参数补齐率从最初的不到60%提升到了90%以上，用户被追问的次数明显下降。

4. 意图与变量的联动机制，让整个Agent有的放矢

4.1 意图槽位模板驱动变量采集

意图识别和变量聚合如果只是各自独立工作，它们对整个Agent的协同增益其实不强。真正让两者发挥合力的，是“意图槽位模板”这个机制。

我的做法是这样：为每个意图预定义一套槽位模板，指明完成该意图需要哪些变量、哪些是必填、哪些是选填。以“退款”意图为例，它的槽位模板是：

• 必填槽位：订单号（order_id）、退款原因（refund_reason）
• 选填槽位：商品描述（product_desc）、购买时间（purchase_time）
• 互斥槽位：订单号 和 商品描述+购买时间 至少提供一组

这个模板的价值在于，它把变量聚合从“尽力而为”变成了“按需驱动”。系统先看到意图，马上就能知道当前缺什么、有什么，然后有的放矢地生成下一步动作：缺了必填槽位就去问用户，缺了选填槽位就尝试通过已有信息推断，实在推不出来再问。

实际体验中，这种机制让对话决策变得非常自然。用户说“我要退款”，系统就会基于槽位模板判断“订单号缺了”，于是回复“好的，我帮您处理退款，方便提供一下订单号吗？”。用户把订单号发过来，系统填充槽位后检查“退款原因也缺”，但系统注意到订单信息里有商品详情和购买时间，于是可以适度简化提问，只问原因。这就是意图和变量相互驱动的价值，整个对话流程不是脚本写死的，而是根据数据情况动态生成的。

4.2 工具调用前的变量完备性检查与对齐

变量聚合的最终目的是什么？是让工具调用一次成功。在进入工具调用之前，最后一个关键环节是“变量完备性检查”。

我在系统里设计了一个前置检查函数，逻辑很简单，但效果很好：

def check_slot_completeness(intent, variables): template = slot_template_registry.get(intent) required = template.required_slots alternative_groups = template.alternative_groups missing = [] for slot in required: if slot not in variables or variables[slot].status != "confirmed": missing.append(slot) # 检查互斥组 for group in alternative_groups: if not any(slot in variables for slot in group): missing.append(f"at_least_one_of_{group}") return missing

这个检查函数做完之后，如果还有缺失，Agent就进入“补问模式”；如果没有缺失，就直接进入工具调用。这一步看似是一个简单的if-else，但如果没有它，模型就会带着残缺参数去调用外部API，轻则报错重试，重则生成脏数据。

还有个细节是“对齐（Alignment）”。工具调用前，我还会把变量值做一次格式化对齐，比如日期从“3月11日”归一化成“2025-03-11”，地址从“上海市浦东新区xx路xx号”拆分出省市区三级结构。这一步不做的话，即使变量看起来齐全，下游系统也不认。这个教训是我在某次对接订单查询API时踩到的，当时系统的日期参数传的是“星期三”，对方接口只接受“2025-03-12”这种格式，直接报了一个很难追踪的错误。

4.3 意图与变量联动的场景演示

为了让上面的逻辑更具体，我把我实际测过的一个场景完整列出来，从原始对话到最终工具调用，走一遍全过程：

用户输入第一句：“我想把前几天买的那个蓝牙耳机退了。”

• 意图识别结果：intent=after_sale_refund，confidence=0.94，evidence=[“退了”]；
• 槽位解析：product_desc=“蓝牙耳机”（弱规则），purchase_time=“前几天”（上下文推断，待确认）；
• 检查结果：缺少order_id，但有product_desc和purchase_time，满足互斥组条件（可以不放订单号），但退款原因未知。

Agent回复：“好的，为了帮您快速办理退款，请确认一下订单号，如果没有的话告诉我具体是哪款耳机，我也可以帮您查。”

用户第二句：“就是白色的那款，QC45。”

• 意图识别结果：intent保持不变，confidence继续走高；
• 变量聚合：product_desc从“蓝牙耳机”细化到“白色QC45”，purchase_time仍不明确；
• 检查结果：退款原因（refund_reason）缺失，其他已满足。

Agent再次询问：“需要了解一下您退货的原因，方便我们改进。”

用户第三句：“降噪效果一般吧。”

• 变量聚合：refund_reason=“降噪效果一般”；
• 检查结果：所有必填链路已满足，触发工具调用。

整个三段对话看起来跟人工客服没什么区别，但背后的逻辑完全是意图和变量两个引擎联动跑出来的。如果只看意图识别，这个场景可能在前两轮就卡住了；如果只看变量聚合，第三句话的“降噪”这个原因没有前后文也难归到refund_reason这个槽位。两者缺一不可。

5. 实战中的常见问题与排查技巧实录

5.1 问题一：意图识别频繁出现摇摆

现象：同一句话，用户换了一种表达方式后就被归到了错误的意图，而且很多是本来边界很清晰的场景。

排查过程：最初我怀疑是模型能力问题，后来逐个case翻看evidence，发现大多数错误都集中在带否定词和对比表达的句子上。比如“我不要这个品牌的，换一个别的”，模型会把“换一个”识别为换货意图，但用户其实是想重新挑选，而不是处理一笔订单。

解决方式：把这类“否定+请求”的典型句式做成专门的Few-shot示例，并在Prompt里强调“当出现否定现有方案并要求替代时，优先归类为选购（selection）意图而不是售后（after_sale）意图”。改完这个，相关case的准确率从74%提升到了91%。

心得：不要急着换模型或加数据，先看看失败case的pattern是不是能通过示例工程解决。大模型的意图分类能力通常够用，问题是你不给它边界条件，它就会按自己的理解去猜。

5.2 问题二：变量抽取存在幻觉

现象：有时候系统会抽取出对话里根本不存在的变量值。比如用户说“我在静安区”，模型却补了一个“上海市”出来，把地址填成了“上海市静安区”，虽然逻辑上没错，但这不是用户提供的信息，一旦用于流程会产生误导。

排查过程：我在变量抽取模块加了“source_trace”字段，记录每个变量的原文来源，发现幻觉内容都发生在模型试图“脑补补全”的时候。也就是说，用户的表述不完整，模型就自动给加了合理但多余的信息。

解决方式：两处拦截。第一，在Prompt里明确要求“只能抽取用户明确提到的信息，禁止推断未提及的信息”；第二，在代码层做校验，凡是变量值里有“来源文本中不存在的连续片段长度超过一定阈值”的，直接降级为待确认状态，发给用户确认而不是默认采纳。

心得：变量聚合宁可抽少了让用户补，也不能让模型自作主张。一个“多余的理由推断”带来的业务风险，远比“少一个参数让用户补充”麻烦得多。

5.3 问题三：多轮指代消解的误伤

现象：用户在第8轮说“那个地址发错了”，Agent误以为用户要更换之前地址，其实用户只是想告知某个订单地址有误。

排查过程：这个问题的根源是“对话状态摘要”里没有区分“当前正在操作的对象”和“历史提及对象”。系统把地址在所有轮次中都当成了同一个“待发货地址”变量，结果新轮次的指令直接覆盖了池子里的值。

解决方式：引入“对象隔离”机制。每当出现新的订单号、商品ID等锚点变量时，把变量池按对象拆分，地址只能存在当前活跃对象下面。这样用户即便在后续提到“那个地址”，系统也能根据锚点判断它指代的是哪一个订单地址，而不是无脑覆盖。

心得：变量池不是一张平铺的大表，应该有层次和归属。尤其多对象场景下（比如一个订单、一个售后单并行处理时），归属关系不清晰就会引发连锁错误。

5.4 问题四：意图变更后旧变量残留

现象：用户最初要咨询发货时间，聊了几句后转为退款，但系统调用退款工具时，把之前咨询环节保存的“期望到货时间”也当成参数传过去了。

解决方式：这是变量生命周期里“失效”机制的经典场景。我在每次意图变更时，都会对照新意图的槽位模板，把旧意图相关的不匹配变量全部标记为失效，而不是删除，这样既能保留对话历史供追溯，又不会误用到下一轮工具调用中。

心得：意图变更不能只改一个标签，变量池需要跟着做一次“垃圾回收”。很多 Agent 出现“上下文污染”问题，根源就在这。

5.5 快速排查兜底清单

最后整理一个我平时排查问题会走的清单，遇到Agent在意图识别或变量聚合上表现异常时，可以按顺序自查：

• 确认输入对话状态摘要是否包含正确的历史意图（可能摘要本身已经错了）；
• 检查变量抽取结果的source_trace，确认是否有无中生有的信息；
• 把失败case丢到单独的线下测试里，用同样的模型参数跑一遍，排除温度和采样随机性；
• 对照槽位模板，确认是变量缺失还是变量存在但状态不是confirmed；
• 查看最近一次的意图变更记录，确认是否有旧变量需要失效；
• 如果错误集中在某个特定表达上，优先补充Few-shot示例而不是盲目加数据。

这六条里，前三条覆盖了大部分“模型不听话”的问题，后三条则更多是工程层面的状态管理问题。按照这个顺序排查，基本不需要重新整理数据就能解决80%以上的线上问题。

6. 一些想说的个人体会

经过这两个多月的反复调整，我最大的感受是：AI Agent这个事，看起来是“模型能力”的比拼，落到工程实现里其实是“信息管理”的较量。意图识别和变量聚合，本质上都是信息从无序到有序的转化过程。模型再聪明，如果信息链路是断的，规划器和工具调度器就是在沙地上盖楼。

如果你是在做客服Agent、工单系统、流程自动化这类偏业务落地的项目，我建议你从一开始就把意图识别的输出做成结构化数据，而不是一个字符串标签，否则后面的变量对齐会极其痛苦。同时，尽早为变量池设计生命周期和归属关系，不要等对话复杂了再回来补课，那时候改起来成本已经很高了。

最后分享一个小技巧：每次模型判断错误的case，我都习惯性把当时的完整输入（包含对话状态摘要）存成快照，线下用同一个模型复跑。你会发现很多线上看起来“模型傻”的问题，其实是因为上下文摘要丢了关键信息——这是工程问题，不是模型问题。这个习惯帮我省下了大量无效调参的时间，也希望对你有所帮助。