AI智能体技能路由实战：从意图识别到精准调用的300+技能调度方案

1. 项目概述当AI智能体面对技能“选择困难症”最近在折腾AI智能体开发特别是那些能调用外部工具Skill的智能体框架比如Dify、LangChain这些。我给自己搭建的一个测试智能体一口气“安装”了300多个Skill——从查天气、订机票到写代码、分析数据再到控制智能家居五花八门应有尽有。然后一个非常现实且核心的问题就摆在了面前当用户用自然语言说“帮我看看明天上海天气怎么样顺便查一下飞北京的机票”时这个AI智能体怎么知道该从这300多个Skill里精准地挑出“天气预报查询”和“机票搜索”这两个来用而不是错误地调用“写一首关于天气的诗”或者“计算两地距离”呢这可不是个简单的问题。它直接关系到智能体是否“智能”是只能机械执行预设指令还是能真正理解用户意图并动态调度资源。这个过程在技术圈里通常被称为“技能路由”Skill Routing或“工具调用”Tool Calling是构建实用AI智能体的核心挑战之一。它远不止是字符串匹配那么简单背后涉及到意图识别、技能描述、匹配算法、优先级仲裁等一系列复杂机制。今天我就结合自己趟过的坑把这套机制从里到外拆解一遍聊聊如何让一个“装备”了数百个技能的AI智能体变得既聪明又可靠。2. 核心挑战与设计思路拆解2.1 为什么“技能路由”如此棘手给AI智能体装一堆Skill理想很丰满感觉它瞬间就“全能”了。但现实是如果没有一套好的调度机制结果往往是灾难性的。主要难点集中在以下几个方面意图模糊与歧义用户的自然语言请求往往是模糊和多义的。比如“订一张票”可能是电影票、火车票、机票。再比如“画个图”是生成统计图表还是艺术创作智能体需要结合上下文对话历史、用户画像来消歧。技能描述与检索的“语义鸿沟”我们定义Skill时通常是用结构化的方式比如一个JSON对象包含name,description,parameters等字段。但用户的查询是自由文本。如何让智能体理解“看看明天天气”和WeatherQuerySkill的description字段“获取指定城市未来几天的天气预报”是同一回事这需要将两者映射到同一个语义空间进行比较。技能间的冲突与重叠当多个Skill的描述都与用户请求高度相关时如何选择最合适的一个例如既有SearchWebSkill通用网页搜索也有SearchFlightSkill专用机票搜索。当用户查询“北京到上海的航班”时显然专用技能更合适。这需要一套评分和排序机制。参数提取与验证即使选对了Skill还需要从用户语句中准确提取出该Skill所需的参数。比如WeatherQuerySkill需要city和date两个参数。用户说“明天上海天气”智能体需要解析出city上海date明天并将“明天”转换成具体的日期格式如2023-10-27。参数缺失或格式错误都会导致调用失败。性能与扩展性当有300个Skill时难道每次用户请求都要把这300个Skill的描述全部塞给大模型LLM去判断吗这会造成巨大的上下文Context开销速度慢、成本高而且可能超出模型的上下文长度限制。我们需要高效的检索和过滤机制。2.2 主流解决方案的设计思路面对这些挑战社区和工业界逐渐形成了几个主流的设计模式其核心思想是“分层过滤精准匹配”。思路一基于大模型LLM的意图识别与直接调用这是最直观也是早期常用的方法。将用户请求和所有Skill的描述甚至参数schema一起构造一个详细的Prompt提交给LLM如GPT-4要求模型直接输出应该调用的Skill名称和参数。例如Prompt可能是“你是一个助手可以调用以下工具[列出所有Skill的JSON描述]。用户说‘XXX’。请分析应该调用哪个工具并提取参数。”注意这种方法在Skill数量少比如少于20个时简单有效。但当Skill数量膨胀到几百个时把全部描述塞进Prompt会极大增加token消耗、降低速度并且可能因为上下文过长导致模型注意力分散准确率下降。它不适合大规模Skill库的场景。思路二检索增强Retrieval-Augmented的路由这是目前处理大规模Skill库的主流和更优方案。其核心是将“从300个里找”的问题先变成“从10个里找”。具体步骤如下技能索引预先对所有Skill的元信息名称、描述、示例等进行向量化Embedding存入向量数据库如Chroma, Pinecone, Weaviate。请求向量化当用户请求到来时同样将其转换为向量。语义检索在向量数据库中进行相似度搜索如余弦相似度快速召回与用户请求最相关的Top-K个例如5-10个候选Skill。精准决策将这少量的候选Skill的详细描述连同用户请求交给LLM做最终的精挑细选和参数提取。这种方法结合了向量检索的高效和LLM的理解深度既解决了性能问题又保证了准确性。思路三基于规则或分类器的预处理对于一些非常明确、高频的指令可以设置规则优先匹配。例如如果用户消息以“/weather”开头直接路由到天气查询Skill。或者训练一个简单的文本分类器先将请求分到几个大的类别如“查询类”、“创作类”、“工具类”再在类别内进行更精细的路由。这可以作为上述检索方法的一个补充或前置过滤层进一步提高效率。在我的实践中思路二检索增强路由是平衡效果与复杂度的最佳选择也是接下来重点详解的部分。3. 技能路由系统的核心组件与实现一个完整的、能处理300个Skill的路由系统需要多个组件协同工作。下面我以一个基于Python的简化实现为例拆解每个部分。3.1 技能Skill的标准化描述一切的基础是清晰、结构化的Skill定义。一个良好的Skill描述应该包含足够让路由机制理解的语义信息。通常我们使用类似OpenAI Function Calling或ReAct格式的JSON Schema。{ “skill_name”: “get_weather”, “description”: “获取指定城市在特定日期的天气预报信息包括温度、天气状况、湿度、风速等。”, “parameters”: { “type”: “object”, “properties”: { “location”: { “type”: “string”, “description”: “城市名称例如北京、上海” }, “date”: { “type”: “string”, “description”: “查询日期格式为YYYY-MM-DD。默认为明天。” } }, “required”: [“location”] }, “examples”: [“上海明天天气怎么样”, “查询一下北京后天是否下雨。”] }关键点解析description字段至关重要它需要清晰、全面地概括技能功能是向量检索和LLM理解的主要依据。避免使用过于技术化或简略的描述。parameters的description字段同样重要它帮助LLM从用户语句中提取和映射参数。比如location的描述“城市名称”就明确告诉模型要找的是地名。examples字段是强力辅助提供几个用户可能怎么说的例子能显著提升检索和意图识别的准确性。它给向量模型提供了更丰富的语义信号。3.2 技能索引的构建与向量化我们需要把数百个这样的Skill描述转换成机器可以快速检索的形式。import json from sentence_transformers import SentenceTransformer import chromadb # 1. 加载所有Skill定义 def load_skills(skills_dir): skills [] for file in os.listdir(skills_dir): if file.endswith(‘.json’): with open(os.path.join(skills_dir, file), ‘r’, encoding‘utf-8’) as f: skill_data json.load(f) # 将关键信息拼接成一段文本用于生成向量 skill_text f“{skill_data[‘skill_name’]} {skill_data[‘description’]} {‘ ‘.join(skill_data.get(‘examples’, []))}” skill_data[‘text_for_embedding’] skill_text skills.append(skill_data) return skills # 2. 初始化嵌入模型和向量数据库 embedding_model SentenceTransformer(‘paraphrase-multilingual-MiniLM-L12-v2’) # 选择一个轻量高效的模型 chroma_client chromadb.PersistentClient(path“./skill_vector_db”) collection chroma_client.get_or_create_collection(name“skills”) # 3. 生成向量并存入数据库 all_skills load_skills(“./skills”) for i, skill in enumerate(all_skills): embedding embedding_model.encode(skill[‘text_for_embedding’]).tolist() # 存储元数据时保留完整的skill定义以备后续使用 collection.add( embeddings[embedding], metadatas{“full_definition”: json.dumps(skill, ensure_asciiFalse)}, idsf“skill_{i}” )实操心得嵌入模型的选择对于中文场景paraphrase-multilingual-MiniLM-L12-v2是一个不错的平衡选择它支持多语言且体积较小。如果追求更高精度可以选用更大的模型如text-embedding-3系列但需考虑计算成本。索引文本的构造如何拼接skill_text直接影响检索质量。我的经验是name description examples的组合通常效果最好。name本身可能包含关键信息如search_flightdescription提供详细说明examples则覆盖了多样的用户表达方式。元数据存储向量数据库里除了存向量一定要把完整的Skill定义以元数据形式存下来。这样在检索到ID后能立刻拿到Skill的详细Schema无需再去原始文件里查找提升效率。3.3 请求处理与技能检索流程当用户发出请求时系统需要快速运转起来。def route_user_request(user_query: str, top_k: int 5): “”” 处理用户查询返回最可能调用的Skill及其参数。 “”” # 1. 将用户查询向量化 query_embedding embedding_model.encode(user_query).tolist() # 2. 从向量数据库检索最相似的Top-K个技能 results collection.query( query_embeddings[query_embedding], n_resultstop_k ) retrieved_skills [] for i in range(len(results[‘ids’][0])): skill_id results[‘ids’][0][i] skill_meta json.loads(results[‘metadatas’][0][i][‘full_definition’]) # 可以附带相似度分数供后续决策参考 skill_meta[‘retrieval_score’] results[‘distances’][0][i] # 注意Chroma返回的是距离越小越相似 retrieved_skills.append(skill_meta) # 3. 如果检索结果为空或分数太低可能用户请求不在技能范围内 if not retrieved_skills or retrieved_skills[0][‘retrieval_score’] 0.5: # 距离阈值可调整 return None, {“error”: “未找到匹配的技能”} # 4. 将候选技能和用户查询交给LLM做最终决策和参数提取 final_skill, extracted_params call_llm_for_final_decision(user_query, retrieved_skills) return final_skill, extracted_params关键点解析top_k的选择这个值需要权衡。太小可能漏掉正确但描述不那么匹配的技能太大会增加后续LLM调用的负担和成本。经过测试对于300个技能的库top_k5到top_k10通常是一个甜点区间。分数阈值设置一个检索相似度的阈值非常重要。如果最相似的技能距离都超过某个值比如0.5具体取决于嵌入模型和距离度量方式说明用户的请求很可能不在现有技能库的覆盖范围内。此时应该直接返回“无法处理”或者触发一个通用的“Fallback Skill”如一个联网搜索技能而不是强行调用一个不相关的技能。3.4 大模型的最终决策与参数提取检索环节缩小了范围最后一步需要LLM的深度理解能力来一锤定音。这里我们构造一个精心设计的Prompt。def call_llm_for_final_decision(user_query: str, candidate_skills: list): import openai # 或其他LLM API # 构造System Prompt定义角色和任务 system_prompt “””你是一个精准的技能路由助手。你需要根据用户的请求从提供的候选技能列表中选择最合适的一个技能并严格按照该技能要求的参数格式从用户请求中提取出对应的参数值。 如果没有任何技能匹配请回答‘无匹配技能’。 请以JSON格式输出包含两个字段chosen_skill_name和parameters。 “”” # 构造用户消息清晰列出候选技能 user_message f“用户请求{user_query}\n\n” user_message “可选技能列表\n” for i, skill in enumerate(candidate_skills): user_message f“{i1}. 技能名{skill[‘skill_name’]}\n” user_message f“ 描述{skill[‘description’]}\n” user_message f“ 参数{json.dumps(skill[‘parameters’], ensure_asciiFalse)}\n” if skill.get(‘examples’): user_message f“ 示例{‘; ‘.join(skill[‘examples’])}\n” user_message “\n” user_message “请分析并输出JSON。” # 调用LLM API response openai.chat.completions.create( model“gpt-4”, # 或使用更经济的模型如 gpt-3.5-turbo messages[ {“role”: “system”, “content”: system_prompt}, {“role”: “user”, “content”: user_message} ], temperature0.1, # 低温度保证输出稳定 response_format{“type”: “json_object”} # 强制JSON输出如果API支持 ) result json.loads(response.choices[0].message.content) if result[‘chosen_skill_name’] ‘无匹配技能’: return None, {} # 根据技能名找到完整的技能定义 chosen_skill_def next((s for s in candidate_skills if s[‘skill_name’] result[‘chosen_skill_name’]), None) return chosen_skill_def, result[‘parameters’]注意事项Prompt工程是关键System Prompt要明确指令和输出格式。在用户消息中清晰地结构化展示每个候选技能的信息名称、描述、参数Schema、示例能极大帮助模型理解。模型选择GPT-4在复杂推理和遵循指令方面表现更佳但成本高。GPT-3.5-turbo对于大多数场景已经足够且响应更快、更经济。可以根据实际准确率要求进行选择。温度Temperature设置对于这种需要确定性输出的任务应将温度设置为较低的值如0.1或0以减少输出的随机性确保路由的稳定性。强制JSON输出如果使用的LLM API支持如OpenAI的JSON Mode务必启用。这能保证返回结果的可解析性避免后续处理出错。4. 高级优化与实战避坑指南基本的检索-决策流程搭建起来后要让它真正在生产环境中稳定、高效、准确地运行还需要一系列优化措施。4.1 提升检索精度的技巧向量检索的质量是整个流程的基石。如果检索阶段就找偏了LLM再厉害也无力回天。技能描述的优化多维度描述除了功能描述可以加入使用场景、输入输出示例的总结。例如“【技能】文本总结。【场景】适用于用户提供长篇文章、报告或网页内容时快速提取核心要点。【输入】长文本。【输出】包含关键信息的摘要段落。”关键词注入在描述中自然地融入可能的关键词。比如一个“生成二维码”的技能描述里除了“生成二维码”可以加上“制作QR code”、“产生扫码图”等同义表述增加被检索到的概率。负面描述对于容易混淆的技能可以在描述中说明“不适用于什么”。例如一个“英文翻译中文”的技能可以加上“本技能仅处理英译中中译英请使用其他技能”。检索策略的优化混合检索Hybrid Search结合语义向量检索和关键词如BM25检索。有些请求中的关键词非常明确如“用Python写个冒泡排序”关键词检索可能更准。将两种检索结果融合如加权分数能取长补短。许多现代向量数据库如Weaviate, Qdrant已内置支持混合检索。重排序Re-ranking先用向量检索召回一个较大的候选集如top-20再用一个更小、更精的交叉编码器Cross-Encoder模型对候选集进行重新打分和排序。虽然多了一步但精度提升显著。元数据过滤在检索时加入过滤条件。例如可以为技能打上分类标签category: “query”如果能在对话早期确定用户意图的大类可以先按标签过滤再在子集内做语义检索极大提升效率。4.2 处理复杂请求与多技能调用用户的请求往往不是单一的。多轮对话中的技能路由不能孤立地看待单条消息。需要维护对话历史并将其作为上下文输入给检索和LLM决策模块。例如用户先说“我想去旅游”再说“看看上海的天气”结合历史就知道“上海”是旅游目的地查询天气是为此服务的。可以在构造检索文本时将最近几轮对话拼接起来。并行与串行技能调用并行用户请求“同时查一下北京和上海的天气”这需要调用一次天气查询技能但参数location需要处理为列表[“北京” “上海”]或者拆分成两个独立的调用。这需要在参数提取和技能执行逻辑上做支持。串行工作流用户请求“查一下明天上海天气如果下雨就推荐室内活动”。这需要先调用天气查询技能根据其结果是否下雨再决定是否调用活动推荐技能。这需要引入“智能体工作流”或“规划Planning”能力让LLM根据中间结果动态决定下一步动作。框架如LangChain的Agent Executor就支持这种多步推理。4.3 系统健壮性与错误处理在实际运行中各种意外情况都可能发生。技能调用失败Skill依赖的API可能宕机、返回异常格式、超时。路由系统必须有重试机制、超时控制并准备友好的降级回复如“暂时无法获取天气信息请稍后再试”。参数提取不全或错误LLM可能提取出错误的参数或者用户根本没提供必要参数。需要在调用技能前进行参数验证。如果缺少必要参数应该触发一个“参数澄清”的子流程让智能体主动询问用户例如“您想查询哪个城市的天气呢”而不是直接报错。无匹配技能的处理Fallback当检索和LLM都认为没有技能匹配时不能简单返回“我不知道”。一个成熟的系统应该有一个默认的Fallback Skill比如联网搜索技能告诉用户“我暂时没有直接处理这个问题的功能但我可以为您搜索一下相关信息”。通用对话技能切换到一个纯聊天模式进行开放域对话。技能推荐基于语义相似度向用户推荐几个可能相关的技能例如“您是想要查询信息还是需要创作内容我可以帮您做A、B、C这几件事”。4.4 性能与成本优化当Skill数量巨大、请求量高时成本控制至关重要。缓存策略请求缓存对于完全相同的用户查询可以直接缓存路由结果选择的技能和参数短时间内再次遇到可直接使用避免重复的向量计算和LLM调用。嵌入缓存用户查询和Skill描述的嵌入向量可以缓存。虽然Skill嵌入是预计算的但用户查询的嵌入对于相同或相似的查询可以复用。模型选型降级并非所有请求都需要最强的GPT-4来决策。可以设计一个两级路由先用一个轻量级模型如小型BERT分类器或便宜的LLM对请求进行粗分类如果置信度很高直接路由如果置信度低再走完整的“检索GPT-4”精调流程。异步与批处理对于向量检索和LLM调用可以采用异步非阻塞的方式避免阻塞主线程。对于LLM调用如果支持批处理API可以将多个决策请求合并发送以降低平均延迟和成本。5. 效果评估与持续迭代搭建好系统不是终点我们需要一套方法来衡量它好不好用并持续改进。评估指标路由准确率随机抽取一批用户历史请求或构造测试集人工标注其应该调用的正确技能计算系统自动路由的准确率。参数提取准确率对于路由正确的请求进一步检查提取出的参数值是否准确。响应时间P95 P99从用户发出请求到系统返回技能路由结果的时间直接影响用户体验。Fallback率触发“无匹配技能”Fallback的请求比例。比例过高说明技能库覆盖不足或路由精度不够。迭代闭环收集bad cases建立一个渠道如日志分析、用户反馈持续收集路由错误或失败的案例。根因分析是技能描述不清晰是检索模型不行还是LLM决策Prompt有缺陷针对性地优化。A/B测试任何大的改动如更换嵌入模型、修改Prompt模板、增加重排序模块都应进行线上A/B测试用真实流量验证效果提升。我个人最深的一个体会是技能路由不是一个“一劳永逸”的工程问题而是一个需要持续运营和优化的“数据算法”产品。最初版本的准确率可能只有70%通过不断分析错误案例、优化技能描述、调整检索策略、完善Prompt这个数字可以逐步提升到95%以上。这个过程也是你对你所构建的智能体能力边界理解不断加深的过程。当你看到它越来越精准地理解用户意图并调用正确的工具时那种感觉就像在精心调教一个逐渐变得得心应手的数字助手。