1. 从“你说东它做西”到“心领神会”意图识别的价值困境做AI应用开发尤其是对话式Agent最让人头疼的场景是什么不是模型API调用失败也不是算力不够而是你精心设计的Agent面对用户一句看似简单的请求给出了一个完全跑偏的、令人啼笑皆非的回应。比如用户说“帮我订一张明天去上海的机票”你的Agent却开始滔滔不绝地介绍上海的旅游景点。或者用户问“这个月的销售报表生成一下”Agent却回复“已为您打开日历应用”。这种“鸡同鸭讲”的体验会瞬间摧毁用户对产品的信任感。问题的核心往往不在于后端执行某个具体任务的能力比如调用订票API或生成报表的函数而在于第一步就没走对——Agent根本没听懂用户到底想干什么。这就是“意图识别”要解决的根本问题让机器理解人类自然语言背后真正的目的和意图。而“路由”则是基于识别出的意图将用户的请求精准地分发给最擅长处理该任务的“专家”模块或工具。你可以把它想象成一个超级智能的客服总机用户说一句话它不仅能听懂用户要找哪个部门意图识别还能瞬间把电话转接到对应的分机路由并且确保这个分机有权限、有能力处理用户的问题。在实际项目中跳过或轻视意图识别与路由直接让一个大模型去处理所有问题是初期最常见的架构误区。这会导致几个严重问题响应质量不稳定模型可能会胡编乱造、处理效率低下用“重型火炮”去打“苍蝇”、功能边界模糊难以控制Agent能做什么、不能做什么以及运营成本高昂每次对话都消耗大量算力。因此构建一个意图明确、路由清晰的中控系统是打造实用、可靠、高效Agent的基石。它决定了你的Agent是“智能助手”还是“人工智障”。2. 意图识别不只是文本分类更是场景理解很多人一提到意图识别第一反应就是把它当作一个多分类的文本分类任务。这没错但只对了一半。在简单的、封闭的场景下比如智能音箱的几十个固定指令用分类模型确实可行。但在开放的、复杂的对话式Agent中意图识别面临着更严峻的挑战。2.1 意图的层次与模糊性用户的真实意图往往是多层次的、隐含的。例如用户输入“最近有什么好看的科幻电影推荐吗”表层意图是“请求电影推荐”。但深层可能隐含了多个子意图用户可能处于“休闲娱乐”状态偏好“科幻”类型希望获得“近期上映”或“高口碑”的作品列表甚至隐含了“帮我筛选掉烂片”的期望。一个粗糙的分类器可能只能打出recommend_movie的标签但优秀的意图识别模块应该能解析出更丰富的结构化信息比如{domain: “entertainment” intent: “recommend” constraints: {genre: “sci-fi” time: “recent” quality: “high”}}。这种结构化表示能为后续的路由和任务执行提供精确的“导航图”。2.2 基于大语言模型的意图解析新范式与老问题如今我们有了强大的大语言模型LLM似乎可以让模型直接理解并输出结构化意图。这确实是一种更灵活、更强大的范式。基本流程是设计一个精心构造的提示词Prompt要求模型根据用户查询输出固定格式的JSON其中包含领域、意图、关键参数等信息。{ “user_query”: “帮我订一张本周五北京飞深圳的机票要早上的航班” “parsed_intent”: { “domain”: “travel” “primary_intent”: “book_flight” “slots”: { “departure_city”: “北京” “arrival_city”: “深圳” “date”: “本周五” “time_preference”: “早上” } } }这种做法优势明显无需训练数据、意图定义可动态扩展、对复杂和隐含意图的理解能力强。但它也引入了新的挑战输出格式不稳定LLM可能不严格按照你要求的JSON格式输出或者多一个逗号少一个引号导致下游解析失败。意图漂移对于边界模糊的查询不同版本的模型、甚至同一模型在不同上下文中的输出可能不一致。成本与延迟每次对话都调用LLM进行意图解析会增加响应时间和API成本。2.3 混合策略在成本与效果间寻找平衡因此在实际生产系统中纯粹的LLM方案或纯粹的传统分类方案都很少见更多的是混合策略规则/关键词匹配先行对于高频、明确的意图如“打开设置”、“退出登录”用简单的规则或关键词快速匹配并返回成本极低速度极快。传统分类模型兜底用一个轻量级的、本地部署的文本分类模型如基于BERT微调的小模型覆盖大部分常见意图。这个模型用历史对话数据训练专门针对你的业务场景优化在准确率和速度上都有保障。LLM作为复杂情况仲裁者当规则和分类模型都无法给出高置信度的结果或者查询本身非常复杂、模糊时再将问题抛给LLM进行深度理解和解析。这相当于把LLM用作一个“专家会诊”只在必要时启用。实操心得不要试图用一个方案解决所有问题。建立一个意图识别的“决策流水线”根据查询的复杂度、历史命中率和成本考量动态选择最合适的识别路径。同时务必为所有意图识别结果添加一个“置信度”分数低置信度的结果可以触发澄清追问例如“您是想查询订单还是想联系客服”这比给出一个错误答案体验要好得多。3. 路由策略从“if-else”到“智能调度中心”识别出意图之后下一步就是路由。最简单的路由就是一堆if-else或者switch-case语句如果意图是A就调用模块A如果是B就调用模块B。在意图数量很少的初期这没什么问题。但随着业务增长意图数量膨胀到几十上百个模块之间可能有依赖、有优先级、有版本更替时这套系统就会变得难以维护像一团乱麻。3.1 基于规则的路由及其局限基于规则的路由其核心是一个静态的映射表。例如intent_router { “book_flight”: FlightBookingTool “check_weather”: WeatherQueryTool “set_reminder”: ReminderService “general_qa”: GeneralChatModel }它的优点是简单、直接、零延迟。但缺点同样突出僵化一个意图只能路由到一个固定的工具或服务无法根据上下文动态选择最优解。缺乏降级与容错如果目标工具失效整个请求就失败了没有备选方案。难以处理复合意图用户一句话里可能包含多个意图“定机票并提醒我航班时间”简单的映射无法处理。3.2 基于向量的语义路由这是更高级的一种方式尤其适合工具Tools数量众多且描述复杂的场景。其核心思想是将每个可用工具的“功能描述”文本例如“这是一个用于查询实时天气的工具输入城市名返回温度、湿度、天气状况”通过嵌入模型Embedding Model转换为一个高维向量。同时也将用户当前查询结合被识别出的意图转换为向量。然后通过计算余弦相似度找到与用户查询最匹配的几个工具。# 伪代码示例 tool_descriptions [“查询天气” “预订航班” “设置日历提醒”...] tool_vectors embed_model.encode(tool_descriptions) # 预计算工具向量 user_query_vector embed_model.encode(“明天上海天气怎么样”) similarities cosine_similarity(user_query_vector tool_vectors) best_tool_index np.argmax(similarities) selected_tool available_tools[best_tool_index]这种方法的优点是灵活、可扩展。新增一个工具时只需要将其描述加入列表并计算向量无需修改核心路由逻辑。它能发现一些基于关键词匹配无法发现的潜在关联。但缺点是对工具描述的撰写要求很高且依赖嵌入模型的质量。3.3 基于LLM的决策路由这是目前最强大、也最复杂的路由方式。直接将用户查询、历史对话上下文、以及所有可用工具的详细描述包括功能、输入输出格式、使用示例一起输入给LLM要求LLM扮演一个“调度员”的角色自主分析应该调用哪个或哪几个工具甚至规划调用顺序。你是一个智能助手调度中心。你有以下工具可用 - 工具A天气查询输入城市名返回天气。 - 工具B航班搜索输入出发地、目的地、日期返回航班列表。 - 工具C日历创建输入事件标题、时间创建日历事项。 用户请求“帮我看看下周北京飞广州的航班如果天气好就定周五的顺便在日历里记一下。” 请分析用户请求决定需要调用哪些工具以及调用的顺序和参数。LLM可以输出一个复杂的执行计划如[调用工具B搜索航班 - 调用工具A查询广州周五天气 - 如果天气好调用工具C创建日历提醒]。这种方式智能度最高能处理极其复杂的复合请求和逻辑判断。但其成本、延迟和不确定性也是最高的需要非常精细的提示工程和输出格式控制。3.4 设计一个健壮的路由层在实际系统中我通常会采用分层路由策略第一层快速过滤。通过意图识别结果中的domain和primary_intent快速缩小候选工具范围。例如domain: travel的请求绝不会路由到音乐播放工具集。第二层精确匹配。在候选工具集内使用基于向量相似度的匹配找到最相关的几个工具。这里可以设置一个相似度阈值高于阈值的才进入下一轮。第三层智能决策。对于高价值、高复杂度的场景或者当第二层匹配结果有多个且相似度接近时启用LLM进行最终决策和规划。第四层降级与兜底。如果以上所有路由均失败如无匹配工具、工具调用异常则必须有一个兜底策略。通常是路由到一个通用的对话模型并给出友好提示如“我目前还无法处理这个请求但可以帮您查询信息或进行简单对话”。同时路由层必须记录详细的日志每个请求的意图识别结果、路由路径、各阶段候选工具及得分、最终执行结果。这些日志是优化整个系统最重要的数据资产。4. 核心环节实现构建一个可维护的意图路由系统理论讲完了我们来看如何动手搭建。一个可维护的系统关键在于将“数据”、“逻辑”和“配置”分离。4.1 意图与工具的定义用数据驱动不要将意图和工具的映射关系硬编码在代码里。应该使用结构化的配置文件如YAML、JSON或数据库来管理。# intents.yaml intents: - name: “book_flight” description: “用户预订机票” sample_utterances: # 示例语句用于训练分类模型或few-shot学习 - “我要订一张去北京的机票” - “下周上海飞深圳有航班吗” - “查一下明天飞成都的票” domain: “travel” required_slots: [“departure_city” “arrival_city” “departure_date”] # 执行必需的关键参数 optional_slots: [“airline_preference” “time_preference”] # tools.yaml tools: - name: “flight_booking_tool” description: “通过合作航司API查询并预订航班。输入需要出发城市、到达城市和日期。” endpoint: “http://internal-service/flight/book” input_schema: # 严格的输入格式定义可用于生成LLM的function calling描述 type: “object” properties: departure_city: {type: “string”} arrival_city: {type: “string”} date: {type: “string” format: “date”} required_permissions: [“user.payment”] # 执行所需权限 fallback_tool: “general_travel_agent” # 降级工具这样当需要新增一个意图或工具时你只需要修改配置文件然后通过管理后台或CI/CD流程热加载或重启服务即可无需改动核心路由代码。4.2 路由执行引擎的实现路由引擎的核心职责是接收解析后的意图根据策略选择工具组装参数调用工具并处理返回结果。这里有一个关键设计点工具调用的标准化。无论底层工具是HTTP服务、gRPC、数据库查询还是一个Python函数都应该通过一个统一的适配器接口来调用。class ToolAdapter: def __init__(self tool_config): self.config tool_config def execute(self parsed_intent user_context): # 1. 参数验证与补全检查required_slots是否齐全从对话历史或用户Profile中补全optional_slots validated_args self._validate_and_complete_args(parsed_intent.slots user_context) # 2. 权限检查检查user_context中的权限是否满足tool.required_permissions if not self._check_permission(user_context): return {“error”: “Insufficient permission”} # 3. 调用工具 try: if self.config.type “http”: result self._call_http_endpoint(validated_args) elif self.config.type “function”: result self._call_local_function(validated_args) # ... 其他类型 except Exception as e: # 4. 异常处理与降级 logger.error(f“Tool {self.config.name} failed: {e}”) if self.config.fallback_tool: return self._invoke_fallback(parsed_intent user_context) else: return {“error”: “Service temporarily unavailable”} # 5. 结果格式化将工具返回的原始数据转换为面向用户对话的友好响应 formatted_response self._format_result(result parsed_intent) return formatted_response这个适配器模式将易变的工具调用逻辑封装起来使路由引擎保持稳定和简洁。4.3 上下文管理让对话拥有记忆单次的意图识别和路由是远远不够的。真实的对话是连续的有上下文的。例如 用户“北京的天气怎么样” - 意图query_weather 槽位{city: “北京”}用户“那上海呢” - 如果没有上下文系统会困惑“上海”指的是什么。因此路由系统必须与一个对话上下文管理器紧密耦合。这个管理器负责维护一个会话Session内的状态包括对话历史之前的用户输入和系统响应。已填充的槽位在多轮对话中逐步收集到的任务参数。用户偏好与身份从用户Profile中获取的静态信息。当新的用户输入到来时意图识别模块和路由引擎不仅要看当前这句话还要查询当前的对话上下文。在上面“那上海呢”的例子中上下文管理器会告诉系统上一轮的话题是“天气查询”因此这一轮的意图很可能也是query_weather并且可以将上一轮的部分参数如查询的“天气”这个动作继承下来只替换城市为“上海”。这极大地提升了对话的自然度和效率。5. 评估、迭代与避坑指南一个意图路由系统上线只是开始。如何衡量它的好坏如何持续改进5.1 核心评估指标你需要监控一套核心指标而不是凭感觉意图识别准确率在标注了真实意图的测试集上模型预测正确的比例。这是基础指标。路由准确率识别出的意图被正确路由到预期工具的比例。注意意图识别对了路由也可能错比如映射表配置错误。工具调用成功率路由后工具被成功调用并返回有效结果的比例。这反映了下游服务的稳定性。用户任务完成率最终用户发起一个任务如订票有多少比例被完整、正确地完成了。这是终极指标。平均对话轮次完成一个典型任务需要多少轮对话。轮次越少通常说明系统越高效、智能。人工接管率有多少比例的对话最终需要转接给人工客服处理。这个指标需要谨慎看待下降是好事但也要分析接管的原因。5.2 常见的“坑”与应对策略坑一意图定义过细或过粗。定义过细如把“查天气”分成query_weather_todayquery_weather_tomorrowquery_weather_weekend会导致样本稀疏、模型难以学习、路由逻辑复杂。定义过粗如只有一个general_query意图则失去了路由的意义。应对从用户真实query中聚类结合业务逻辑定义颗粒度适中的意图。一个原则是一个意图最好对应一个清晰、可执行的动作。坑二对LLM的过度依赖与失控。初期为了快速验证把所有复杂判断都丢给LLM很快会发现成本激增、响应变慢且一些关键业务逻辑如风控、权限难以嵌入。应对确立“LLM as a last resort”原则。能用规则和轻量级模型解决的绝不用LLM。必须用LLM时通过严格的Prompt工程和输出解析如Pydantic模型来约束其行为。坑三忽略负样本和边界情况。只收集用户“应该怎么问”的样本忽略了用户“实际会怎么问”以及各种稀奇古怪、带有歧义或攻击性的问法。应对主动进行模糊查询、对抗性测试。在测试阶段让不同背景的人非项目成员来随意提问收集这些“脏数据”加入到意图分类器的训练中或者作为规则系统的过滤条件。坑四路由成为单点故障。路由服务本身宕机导致所有用户请求失败。应对路由服务本身需要高可用部署。同时设计一个极简的、本地化的“安全模式”路由当主路由服务不可用时可以降级到仅支持几个最核心的功能如“重启”、“帮助”、“联系客服”。5.3 持续迭代的飞轮构建意图路由系统是一个持续迭代的过程形成一个数据驱动的闭环上线与监控系统上线收集真实的用户对话日志和各项指标。分析与标注定期如每周分析日志重点查看低置信度的意图识别结果、路由失败案例、用户中途放弃的对话流。对这些bad cases进行人工标注明确正确的意图应该是什么。模型与规则更新将新标注的数据加入到意图分类模型的训练集中重新训练和部署模型。同时根据新发现的常见误解或新业务需求更新路由规则和工具配置。A/B测试对于重大的策略变更如引入新的路由算法通过A/B测试来验证其效果确保指标尤其是任务完成率有正向提升而不是下降。这个循环跑得越快你的Agent就能越快地理解用户越精准地服务用户。最终用户甚至感觉不到“意图识别”和“路由”的存在只觉得这个助手聪明、懂事、好用。而这正是我们设计这个复杂系统的全部意义所在。
1. 从“你说东它做西”到“心领神会”意图识别的价值困境做AI应用开发尤其是对话式Agent最让人头疼的场景是什么不是模型API调用失败也不是算力不够而是你精心设计的Agent面对用户一句看似简单的请求给出了一个完全跑偏的、令人啼笑皆非的回应。比如用户说“帮我订一张明天去上海的机票”你的Agent却开始滔滔不绝地介绍上海的旅游景点。或者用户问“这个月的销售报表生成一下”Agent却回复“已为您打开日历应用”。这种“鸡同鸭讲”的体验会瞬间摧毁用户对产品的信任感。问题的核心往往不在于后端执行某个具体任务的能力比如调用订票API或生成报表的函数而在于第一步就没走对——Agent根本没听懂用户到底想干什么。这就是“意图识别”要解决的根本问题让机器理解人类自然语言背后真正的目的和意图。而“路由”则是基于识别出的意图将用户的请求精准地分发给最擅长处理该任务的“专家”模块或工具。你可以把它想象成一个超级智能的客服总机用户说一句话它不仅能听懂用户要找哪个部门意图识别还能瞬间把电话转接到对应的分机路由并且确保这个分机有权限、有能力处理用户的问题。在实际项目中跳过或轻视意图识别与路由直接让一个大模型去处理所有问题是初期最常见的架构误区。这会导致几个严重问题响应质量不稳定模型可能会胡编乱造、处理效率低下用“重型火炮”去打“苍蝇”、功能边界模糊难以控制Agent能做什么、不能做什么以及运营成本高昂每次对话都消耗大量算力。因此构建一个意图明确、路由清晰的中控系统是打造实用、可靠、高效Agent的基石。它决定了你的Agent是“智能助手”还是“人工智障”。2. 意图识别不只是文本分类更是场景理解很多人一提到意图识别第一反应就是把它当作一个多分类的文本分类任务。这没错但只对了一半。在简单的、封闭的场景下比如智能音箱的几十个固定指令用分类模型确实可行。但在开放的、复杂的对话式Agent中意图识别面临着更严峻的挑战。2.1 意图的层次与模糊性用户的真实意图往往是多层次的、隐含的。例如用户输入“最近有什么好看的科幻电影推荐吗”表层意图是“请求电影推荐”。但深层可能隐含了多个子意图用户可能处于“休闲娱乐”状态偏好“科幻”类型希望获得“近期上映”或“高口碑”的作品列表甚至隐含了“帮我筛选掉烂片”的期望。一个粗糙的分类器可能只能打出recommend_movie的标签但优秀的意图识别模块应该能解析出更丰富的结构化信息比如{domain: “entertainment” intent: “recommend” constraints: {genre: “sci-fi” time: “recent” quality: “high”}}。这种结构化表示能为后续的路由和任务执行提供精确的“导航图”。2.2 基于大语言模型的意图解析新范式与老问题如今我们有了强大的大语言模型LLM似乎可以让模型直接理解并输出结构化意图。这确实是一种更灵活、更强大的范式。基本流程是设计一个精心构造的提示词Prompt要求模型根据用户查询输出固定格式的JSON其中包含领域、意图、关键参数等信息。{ “user_query”: “帮我订一张本周五北京飞深圳的机票要早上的航班” “parsed_intent”: { “domain”: “travel” “primary_intent”: “book_flight” “slots”: { “departure_city”: “北京” “arrival_city”: “深圳” “date”: “本周五” “time_preference”: “早上” } } }这种做法优势明显无需训练数据、意图定义可动态扩展、对复杂和隐含意图的理解能力强。但它也引入了新的挑战输出格式不稳定LLM可能不严格按照你要求的JSON格式输出或者多一个逗号少一个引号导致下游解析失败。意图漂移对于边界模糊的查询不同版本的模型、甚至同一模型在不同上下文中的输出可能不一致。成本与延迟每次对话都调用LLM进行意图解析会增加响应时间和API成本。2.3 混合策略在成本与效果间寻找平衡因此在实际生产系统中纯粹的LLM方案或纯粹的传统分类方案都很少见更多的是混合策略规则/关键词匹配先行对于高频、明确的意图如“打开设置”、“退出登录”用简单的规则或关键词快速匹配并返回成本极低速度极快。传统分类模型兜底用一个轻量级的、本地部署的文本分类模型如基于BERT微调的小模型覆盖大部分常见意图。这个模型用历史对话数据训练专门针对你的业务场景优化在准确率和速度上都有保障。LLM作为复杂情况仲裁者当规则和分类模型都无法给出高置信度的结果或者查询本身非常复杂、模糊时再将问题抛给LLM进行深度理解和解析。这相当于把LLM用作一个“专家会诊”只在必要时启用。实操心得不要试图用一个方案解决所有问题。建立一个意图识别的“决策流水线”根据查询的复杂度、历史命中率和成本考量动态选择最合适的识别路径。同时务必为所有意图识别结果添加一个“置信度”分数低置信度的结果可以触发澄清追问例如“您是想查询订单还是想联系客服”这比给出一个错误答案体验要好得多。3. 路由策略从“if-else”到“智能调度中心”识别出意图之后下一步就是路由。最简单的路由就是一堆if-else或者switch-case语句如果意图是A就调用模块A如果是B就调用模块B。在意图数量很少的初期这没什么问题。但随着业务增长意图数量膨胀到几十上百个模块之间可能有依赖、有优先级、有版本更替时这套系统就会变得难以维护像一团乱麻。3.1 基于规则的路由及其局限基于规则的路由其核心是一个静态的映射表。例如intent_router { “book_flight”: FlightBookingTool “check_weather”: WeatherQueryTool “set_reminder”: ReminderService “general_qa”: GeneralChatModel }它的优点是简单、直接、零延迟。但缺点同样突出僵化一个意图只能路由到一个固定的工具或服务无法根据上下文动态选择最优解。缺乏降级与容错如果目标工具失效整个请求就失败了没有备选方案。难以处理复合意图用户一句话里可能包含多个意图“定机票并提醒我航班时间”简单的映射无法处理。3.2 基于向量的语义路由这是更高级的一种方式尤其适合工具Tools数量众多且描述复杂的场景。其核心思想是将每个可用工具的“功能描述”文本例如“这是一个用于查询实时天气的工具输入城市名返回温度、湿度、天气状况”通过嵌入模型Embedding Model转换为一个高维向量。同时也将用户当前查询结合被识别出的意图转换为向量。然后通过计算余弦相似度找到与用户查询最匹配的几个工具。# 伪代码示例 tool_descriptions [“查询天气” “预订航班” “设置日历提醒”...] tool_vectors embed_model.encode(tool_descriptions) # 预计算工具向量 user_query_vector embed_model.encode(“明天上海天气怎么样”) similarities cosine_similarity(user_query_vector tool_vectors) best_tool_index np.argmax(similarities) selected_tool available_tools[best_tool_index]这种方法的优点是灵活、可扩展。新增一个工具时只需要将其描述加入列表并计算向量无需修改核心路由逻辑。它能发现一些基于关键词匹配无法发现的潜在关联。但缺点是对工具描述的撰写要求很高且依赖嵌入模型的质量。3.3 基于LLM的决策路由这是目前最强大、也最复杂的路由方式。直接将用户查询、历史对话上下文、以及所有可用工具的详细描述包括功能、输入输出格式、使用示例一起输入给LLM要求LLM扮演一个“调度员”的角色自主分析应该调用哪个或哪几个工具甚至规划调用顺序。你是一个智能助手调度中心。你有以下工具可用 - 工具A天气查询输入城市名返回天气。 - 工具B航班搜索输入出发地、目的地、日期返回航班列表。 - 工具C日历创建输入事件标题、时间创建日历事项。 用户请求“帮我看看下周北京飞广州的航班如果天气好就定周五的顺便在日历里记一下。” 请分析用户请求决定需要调用哪些工具以及调用的顺序和参数。LLM可以输出一个复杂的执行计划如[调用工具B搜索航班 - 调用工具A查询广州周五天气 - 如果天气好调用工具C创建日历提醒]。这种方式智能度最高能处理极其复杂的复合请求和逻辑判断。但其成本、延迟和不确定性也是最高的需要非常精细的提示工程和输出格式控制。3.4 设计一个健壮的路由层在实际系统中我通常会采用分层路由策略第一层快速过滤。通过意图识别结果中的domain和primary_intent快速缩小候选工具范围。例如domain: travel的请求绝不会路由到音乐播放工具集。第二层精确匹配。在候选工具集内使用基于向量相似度的匹配找到最相关的几个工具。这里可以设置一个相似度阈值高于阈值的才进入下一轮。第三层智能决策。对于高价值、高复杂度的场景或者当第二层匹配结果有多个且相似度接近时启用LLM进行最终决策和规划。第四层降级与兜底。如果以上所有路由均失败如无匹配工具、工具调用异常则必须有一个兜底策略。通常是路由到一个通用的对话模型并给出友好提示如“我目前还无法处理这个请求但可以帮您查询信息或进行简单对话”。同时路由层必须记录详细的日志每个请求的意图识别结果、路由路径、各阶段候选工具及得分、最终执行结果。这些日志是优化整个系统最重要的数据资产。4. 核心环节实现构建一个可维护的意图路由系统理论讲完了我们来看如何动手搭建。一个可维护的系统关键在于将“数据”、“逻辑”和“配置”分离。4.1 意图与工具的定义用数据驱动不要将意图和工具的映射关系硬编码在代码里。应该使用结构化的配置文件如YAML、JSON或数据库来管理。# intents.yaml intents: - name: “book_flight” description: “用户预订机票” sample_utterances: # 示例语句用于训练分类模型或few-shot学习 - “我要订一张去北京的机票” - “下周上海飞深圳有航班吗” - “查一下明天飞成都的票” domain: “travel” required_slots: [“departure_city” “arrival_city” “departure_date”] # 执行必需的关键参数 optional_slots: [“airline_preference” “time_preference”] # tools.yaml tools: - name: “flight_booking_tool” description: “通过合作航司API查询并预订航班。输入需要出发城市、到达城市和日期。” endpoint: “http://internal-service/flight/book” input_schema: # 严格的输入格式定义可用于生成LLM的function calling描述 type: “object” properties: departure_city: {type: “string”} arrival_city: {type: “string”} date: {type: “string” format: “date”} required_permissions: [“user.payment”] # 执行所需权限 fallback_tool: “general_travel_agent” # 降级工具这样当需要新增一个意图或工具时你只需要修改配置文件然后通过管理后台或CI/CD流程热加载或重启服务即可无需改动核心路由代码。4.2 路由执行引擎的实现路由引擎的核心职责是接收解析后的意图根据策略选择工具组装参数调用工具并处理返回结果。这里有一个关键设计点工具调用的标准化。无论底层工具是HTTP服务、gRPC、数据库查询还是一个Python函数都应该通过一个统一的适配器接口来调用。class ToolAdapter: def __init__(self tool_config): self.config tool_config def execute(self parsed_intent user_context): # 1. 参数验证与补全检查required_slots是否齐全从对话历史或用户Profile中补全optional_slots validated_args self._validate_and_complete_args(parsed_intent.slots user_context) # 2. 权限检查检查user_context中的权限是否满足tool.required_permissions if not self._check_permission(user_context): return {“error”: “Insufficient permission”} # 3. 调用工具 try: if self.config.type “http”: result self._call_http_endpoint(validated_args) elif self.config.type “function”: result self._call_local_function(validated_args) # ... 其他类型 except Exception as e: # 4. 异常处理与降级 logger.error(f“Tool {self.config.name} failed: {e}”) if self.config.fallback_tool: return self._invoke_fallback(parsed_intent user_context) else: return {“error”: “Service temporarily unavailable”} # 5. 结果格式化将工具返回的原始数据转换为面向用户对话的友好响应 formatted_response self._format_result(result parsed_intent) return formatted_response这个适配器模式将易变的工具调用逻辑封装起来使路由引擎保持稳定和简洁。4.3 上下文管理让对话拥有记忆单次的意图识别和路由是远远不够的。真实的对话是连续的有上下文的。例如 用户“北京的天气怎么样” - 意图query_weather 槽位{city: “北京”}用户“那上海呢” - 如果没有上下文系统会困惑“上海”指的是什么。因此路由系统必须与一个对话上下文管理器紧密耦合。这个管理器负责维护一个会话Session内的状态包括对话历史之前的用户输入和系统响应。已填充的槽位在多轮对话中逐步收集到的任务参数。用户偏好与身份从用户Profile中获取的静态信息。当新的用户输入到来时意图识别模块和路由引擎不仅要看当前这句话还要查询当前的对话上下文。在上面“那上海呢”的例子中上下文管理器会告诉系统上一轮的话题是“天气查询”因此这一轮的意图很可能也是query_weather并且可以将上一轮的部分参数如查询的“天气”这个动作继承下来只替换城市为“上海”。这极大地提升了对话的自然度和效率。5. 评估、迭代与避坑指南一个意图路由系统上线只是开始。如何衡量它的好坏如何持续改进5.1 核心评估指标你需要监控一套核心指标而不是凭感觉意图识别准确率在标注了真实意图的测试集上模型预测正确的比例。这是基础指标。路由准确率识别出的意图被正确路由到预期工具的比例。注意意图识别对了路由也可能错比如映射表配置错误。工具调用成功率路由后工具被成功调用并返回有效结果的比例。这反映了下游服务的稳定性。用户任务完成率最终用户发起一个任务如订票有多少比例被完整、正确地完成了。这是终极指标。平均对话轮次完成一个典型任务需要多少轮对话。轮次越少通常说明系统越高效、智能。人工接管率有多少比例的对话最终需要转接给人工客服处理。这个指标需要谨慎看待下降是好事但也要分析接管的原因。5.2 常见的“坑”与应对策略坑一意图定义过细或过粗。定义过细如把“查天气”分成query_weather_todayquery_weather_tomorrowquery_weather_weekend会导致样本稀疏、模型难以学习、路由逻辑复杂。定义过粗如只有一个general_query意图则失去了路由的意义。应对从用户真实query中聚类结合业务逻辑定义颗粒度适中的意图。一个原则是一个意图最好对应一个清晰、可执行的动作。坑二对LLM的过度依赖与失控。初期为了快速验证把所有复杂判断都丢给LLM很快会发现成本激增、响应变慢且一些关键业务逻辑如风控、权限难以嵌入。应对确立“LLM as a last resort”原则。能用规则和轻量级模型解决的绝不用LLM。必须用LLM时通过严格的Prompt工程和输出解析如Pydantic模型来约束其行为。坑三忽略负样本和边界情况。只收集用户“应该怎么问”的样本忽略了用户“实际会怎么问”以及各种稀奇古怪、带有歧义或攻击性的问法。应对主动进行模糊查询、对抗性测试。在测试阶段让不同背景的人非项目成员来随意提问收集这些“脏数据”加入到意图分类器的训练中或者作为规则系统的过滤条件。坑四路由成为单点故障。路由服务本身宕机导致所有用户请求失败。应对路由服务本身需要高可用部署。同时设计一个极简的、本地化的“安全模式”路由当主路由服务不可用时可以降级到仅支持几个最核心的功能如“重启”、“帮助”、“联系客服”。5.3 持续迭代的飞轮构建意图路由系统是一个持续迭代的过程形成一个数据驱动的闭环上线与监控系统上线收集真实的用户对话日志和各项指标。分析与标注定期如每周分析日志重点查看低置信度的意图识别结果、路由失败案例、用户中途放弃的对话流。对这些bad cases进行人工标注明确正确的意图应该是什么。模型与规则更新将新标注的数据加入到意图分类模型的训练集中重新训练和部署模型。同时根据新发现的常见误解或新业务需求更新路由规则和工具配置。A/B测试对于重大的策略变更如引入新的路由算法通过A/B测试来验证其效果确保指标尤其是任务完成率有正向提升而不是下降。这个循环跑得越快你的Agent就能越快地理解用户越精准地服务用户。最终用户甚至感觉不到“意图识别”和“路由”的存在只觉得这个助手聪明、懂事、好用。而这正是我们设计这个复杂系统的全部意义所在。
