OpenClaw如何通过动态技能路由解决AI Agent技能选择难题

1. 从“技能海啸”到精准定位一个核心问题的提出最近在折腾各种AI Agent和工具调用框架一个老生常谈的问题又浮现在脑海里当一个大模型能调用的技能Skill数量膨胀到成千上万甚至“千万级”时它会不会像处理超长上下文或者面对海量Function Call选项时那样因为信息过载而“选错”这个问题并非空穴来风。我们经历过LLM在超长上下文里“迷失”找不到关键信息也见过在几十上百个Function Call定义面前模型给出一个似是而非、甚至完全错误的函数调用。那么当技能库的规模从几十个跃升到百万、千万量级模型会不会彻底“懵圈”随机乱点鸳鸯谱或者陷入选择困难症带着这个疑问我深入翻看了OpenClaw这个项目的技能加载与调用机制。结论有点反直觉在OpenClaw的设计下模型因为技能数量爆炸而“选错”技能的概率被极大地降低了甚至可以说“不会”。这听起来是个好消息对吧但别高兴太早OpenClaw巧妙地绕开了“选择困难”这个坑却把问题转移到了另一个更底层、也更棘手的地方。这也是标题里那个“另一个问题”的由来。简单来说OpenClaw通过一套“按需加载、动态索引”的机制确保了在任何一次具体的用户请求面前模型需要“看见”和“抉择”的技能集合始终是一个可控的、高度相关的子集而非整个千万级的技能库。这从根本上避免了上下文爆炸导致的决策混乱。然而这套机制的成功强烈依赖于一个前提技能描述的精准度与向量化检索的召回质量。如果技能的描述Skill Description写得不准确、有歧义或者向量检索模型没能理解用户query的真实意图那么即使只给模型呈现了10个高度相关的技能它也可能在这10个里面选错。问题从“在汪洋大海里捞针”变成了“在10根相似的针里选对那唯一的一根”挑战的性质发生了变化。接下来我们就拆开看看OpenClaw是怎么做到的以及这个“另一个问题”具体是什么我们又该如何应对。2. OpenClaw技能加载机制为何能避免“选择困难症”要理解OpenClaw如何避免技能选择爆炸我们需要先看看传统的Function Call或简单技能调用是怎么做的。在很多框架里无论是通过LangChain的Tool调用还是直接使用LLM的Native Function Calling通常的做法是在对话开始时或者每个Agent初始化时就把所有可用的工具/函数描述包括名称、描述、参数schema一次性塞进系统提示词System Prompt里或者通过类似“tools: [...]”的字段传递给模型。当工具数量不多比如十几个时这没问题。但当这个列表增长到几百、几千时问题就来了上下文占用大量工具描述会挤占宝贵的上下文窗口留给用户query和历史对话的空间就少了。模型性能下降有研究表明当可选函数列表过长时LLM的调用准确率会下降。模型需要花更多“精力”去理解和区分这些函数增加了内部计算负担和出错概率。成本飙升更多的Tokens意味着更高的API调用成本。OpenClaw的解决方案核心是动态技能路由与按需加载。它不一次性把所有技能都暴露给LLM。整个流程可以概括为以下几个关键步骤2.1 技能注册与向量化索引首先每个Skill在注册到OpenClaw时除了其执行代码或调用端点必须提供一段清晰、准确的文本描述。这段描述至关重要它需要说明这个技能是干什么的、能解决什么问题、输入输出是什么。例如一个“获取天气”的技能描述可能是“根据用户提供的城市名称查询该城市当前及未来几天的天气情况包括温度、湿度、天气状况晴、雨等和风力。”OpenClaw会利用一个嵌入模型Embedding Model将所有这些技能的描述文本转换成高维向量Vector并存储在一个向量数据库如Milvus, Pinecone, Qdrant等中。这个过程为后续的语义检索打下了基础。注意这里就埋下了第一个伏笔。技能描述的质量直接决定了向量表示的质量。如果描述写得模糊如“处理数据”、过于宽泛如“提供帮助”或包含歧义词那么它的向量就可能无法准确代表其真实功能导致后续检索出错。2.2 用户请求的意图解析与技能检索当用户发起一个请求比如“帮我查一下北京明天会不会下雨”时OpenClaw不会直接把请求和所有技能列表扔给LLM。意图提取系统首先会用LLM通常是一个较小、较快的模型或规则方法从用户query中提取核心意图关键词或生成一个更概括的查询语句。对于上面的例子可能会提取出“天气 查询 北京 明天 下雨”。向量检索用同样的嵌入模型将上一步得到的意图查询文本也转化为向量。然后用这个查询向量去向量数据库中做相似度搜索Similarity Search比如使用余弦相似度Cosine Similarity找出与查询向量最相似的Top-K个技能向量。这个K值通常不大比如5 10 20。这一步是避免“选择爆炸”的核心。通过向量检索系统从千万级的技能池中快速筛选出了可能与当前用户请求最相关的区区几十个技能。对于LLM来说它需要处理的候选技能列表从“千万级”骤降到了“十位数级”。2.3 精简上下文构建与LLM决策OpenClaw拿到检索出的Top-K个技能后会只把这些技能的描述名称、描述、参数格式化然后连同用户的原始请求一起构建成一个精简的提示词发送给核心的LLM比如Claude、GPT-4进行决策。此时的提示词大致结构如下用户请求帮我查一下北京明天会不会下雨 请根据以下技能描述判断是否需要调用某个技能来满足用户请求。如果需要请严格按照格式输出调用指令。 可用的技能 1. 技能名称get_weather 描述根据用户提供的城市名称查询该城市当前及未来几天的天气情况... 参数{“city”: “string”} 2. 技能名称set_reminder 描述为用户设置一个日历提醒... 参数{“time”: “string”, “event”: “string”} ...其他几个检索出的技能 请分析并决定。你看LLM只需要面对5-10个高度相关的技能选项做出判断的难度和负担大大降低。它不再需要从“翻译技能”、“写代码技能”、“订机票技能”、“查天气技能”等毫不相关的海量技能中做选择。这种设计极大地提升了技能调用的准确性和响应速度。2.4 技能执行与结果返回LLM如果决定调用某个技能比如get_weather就会输出结构化的调用指令。OpenClaw的运行时接收到指令后会动态加载并执行对应的技能代码或调用远程服务将执行结果返回并可能由LLM进行总结后回复给用户。整个流程的关键在于“检索前置”。它把“从海量选项中做选择”这个复杂问题转化成了“先做一次快速的语义过滤再从少量精品中做选择”的两阶段问题。第一阶段检索由高效、专门的向量搜索完成第二阶段精挑由LLM完成。分工明确效率倍增。3. “另一个问题”当检索成为新的瓶颈OpenClaw的机制听起来很完美但它成功的前提是第一步的语义检索必须足够精准。如果检索环节就出错了那么后面LLM再聪明也只能在错误的候选集里打转。这就是它引入的“另一个问题”——对技能描述质量和检索系统鲁棒性的极端依赖。我们可以把这个问题拆解成几个具体的挑战3.1 技能描述的“表述鸿沟”技能描述是由开发者编写的自然语言文本。这里存在多重鸿沟开发者与用户的话语体系不同开发者可能用专业术语描述技能而用户用生活化语言提问。例如一个技能描述是“执行多模态情感分析”用户却说“看看这张图里的人高兴不”。如果描述里没提到“图片”、“情绪”、“高兴”这些同义词或相关词检索就可能失败。描述的粒度与覆盖面描述写得太细可能覆盖不到用户多样的问法写得太粗又容易和别的技能混淆。比如“处理文件”这个描述对于“压缩PDF”、“转换图片格式”、“合并Excel表格”这几个具体技能来说都适用但显然不够精确。动态与静态描述的冲突有些技能的功能会随着时间或数据变化。比如一个“推荐最新新闻”的技能其描述是“推荐新闻”但用户今天问“有什么热点”明天问“俄乌局势最新进展”虽然都指向这个技能但查询的向量表示可能会有差异。我的实操心得编写技能描述时要采用“用户视角”。想象用户会怎么问然后把那些问法中的关键词融入到描述里。可以借鉴SEO的思路为技能描述准备一个“关键词列表”确保核心功能、同义词、常见场景词都被涵盖。例如对于天气技能描述中应包含“天气”、“气候”、“温度”、“下雨”、“下雪”、“预报”、“查询”等多个词汇。3.2 向量检索模型的“理解偏差”我们依赖嵌入模型将文本转换为向量。但没有任何一个嵌入模型是完美的。领域不匹配通用的嵌入模型如OpenAI的text-embedding-ada-002在通用领域表现良好但在非常垂直、专业的领域如医疗、法律、特定行业术语其语义理解可能不到位。一个关于“凝血功能”查询可能检索不到描述为“检测血小板聚集率”的专业技能。多语言与混合语言如果技能描述是中文用户查询是中英文混杂如“帮我find一下最新的paper”检索效果可能会打折扣。长尾查询与零样本问题对于训练数据中少见的、或表述非常独特的用户查询嵌入模型可能无法生成准确的向量导致检索出的技能不相关。解决方案与尝试微调嵌入模型如果技能领域非常专业可以考虑用自己领域的技能描述和查询对对开源的嵌入模型如bge-large-zh进行微调让它更“懂行”。混合检索Hybrid Search不要只依赖向量检索。可以结合关键词检索如BM25。先用关键词快速过滤掉明显不相关的技能再用向量检索做语义精排。这样可以保证基本的召回率避免因为语义理解的细微偏差而完全漏掉关键技能。查询重写Query Rewriting在检索前先用一个小LLM对用户查询进行重写或扩展。比如将“明天冷吗”重写为“查询明天的天气温度和体感是否寒冷”。这相当于给检索系统一个更清晰、更标准的“搜索指令”。3.3 检索数量K值的权衡Top-K的K值设置是个艺术。K太小可能漏掉相关技能召回率低K太大又会让LLM面对过多的选项走回“选择困难”的老路同时增加上下文消耗。我的经验是动态调整K值对于简单的、意图明确的查询如“翻译hello world”K可以设小一点比如3-5。对于复杂的、模糊的查询如“帮我分析一下这个数据”K需要设大一点比如10-15因为“分析数据”可能对应数据可视化、统计分析、异常检测等多个技能。更高级的策略可以是先用一个较小的K进行检索如果LLM判断检索结果中没有合适的技能输出“无需调用技能”或置信度很低则自动扩大K值进行第二轮检索。4. 从MCP/Function Call的对比看问题迁移为了更清楚地看到OpenClaw方案的优势与代价我们把它和常见的MCPModel Context Protocol以及原生Function Call做个对比。特性传统Function Call / MCP (一次性加载)OpenClaw (检索式加载)技能暴露方式所有技能描述一次性放入上下文。仅检索出的Top-K相关技能放入上下文。上下文占用随技能数量线性增长极易爆炸。基本恒定只与K值有关。LLM决策难度技能越多决策越难准确率可能下降。决策集小且相关难度低准确率高。瓶颈所在LLM的认知与推理能力。需要从海量信息中筛选。检索系统的精度与召回率。检索错了全盘皆输。技能更新影响新增/修改技能需要更新整个提示词模板可能影响历史对话。新增技能只需更新向量库对现有提示词和流程无影响动态性强。冷启动技能新技能立刻进入候选池但可能被淹没。新技能只要描述准确就能通过检索被找到。适用规模适合技能数量较少100的场景。非常适合技能数量巨大千级、万级、百万级的场景。这个对比清晰地展示了问题的迁移路径传统方案压力全部给到了LLM。问题本质是LLM在超长、杂乱上下文中的注意力分配与推理能力问题。OpenClaw方案压力转移到了检索系统。问题本质变成了信息检索领域的精度-召回权衡、查询理解与语义匹配问题。后者在工程上通常更可控。我们可以通过优化描述、改进模型、调整策略来持续提升检索质量而这些优化手段相对独立于LLM本身的能力。而提升LLM处理超长上下文和复杂选择的能力则更依赖于模型本身的升级成本更高且不可控。5. 实战优化提升OpenClaw技能调用精度的关键步骤理解了问题所在我们就可以有的放矢地进行优化。以下是我在实践和测试中总结出的几个关键步骤。5.1 技能描述工程像写API文档一样精心打磨这是成本最低、效果最显著的优化点。不要随便写一两句话敷衍了事。结构化描述模板为所有技能制定一个描述模板强制包含以下几个部分核心功能用一句话说清这个技能最主要干什么。典型用例列举2-3个最常见的用户提问例子。输入说明详细说明每个参数的含义、格式、示例。输出说明说明技能返回什么。关键词/同义词额外附上一组与技能相关的关键词。 例如技能calculate_compound_interest功能计算复利投资的未来价值。用例“如果每月定投1000元年化收益5%30年后有多少钱”“帮我算一下复利。”输入principal(本金数字)annual_rate(年利率小数)years(年限整数)monthly_addition(可选每月追加投资数字)。输出一个包含期末总金额、总投入、总收益的JSON对象。关键词复利 利息 投资计算 理财 未来价值 compound interest, investment。A/B测试描述对于重要的技能可以准备多个版本的描述通过一批真实的用户查询测试哪个版本的检索召回率更高。5.2 构建分层的技能索引对于技能库特别庞大的情况可以考虑建立分层或分类的索引而不是一个巨大的扁平向量库。技能分类人工或利用LLM对技能进行粗粒度分类如“工具类”、“查询类”、“创作类”、“分析类”。当用户请求到来时先判断其所属的大类可以用一个更快的文本分类模型然后只在该类别的技能子库中进行向量检索。这相当于在检索前加了一层粗筛能进一步提升精度和速度。元数据过滤为技能添加元数据标签如domain: finance,input_type: image,output_type: chart。在检索时除了语义相似度还可以结合元数据过滤。例如用户查询“把这张图变成卡通风格”可以强制要求检索结果必须包含input_type: image和output_type: image的技能。5.3 实施混合检索与重排序策略不要孤注一掷地依赖向量检索。关键词向量混合检索如前面所述使用Elasticsearch负责关键词匹配和过滤和向量数据库负责语义匹配结合。先通过关键词快速圈定一个范围比如100个技能再在这100个里用向量检索找出最相关的10个。这能有效避免因语义细微差异导致的遗漏。重排序检索出Top-K比如20个候选技能后不要直接交给LLM。可以引入一个更小、更快的“重排序模型”或“交叉编码器”对这20个技能描述 用户查询对进行更精细的相关性打分只取分数最高的前5个给LLM。交叉编码器因为能同时看到查询和描述进行深度交互计算通常比双塔式的向量检索模型更准。5.4 建立反馈与迭代闭环系统上线后必须收集反馈数据持续优化。日志记录详细记录每一次用户查询、检索返回的技能列表、LLM最终选择的技能、以及技能执行结果/用户满意度如果有办法评估的话。挖掘bad cases定期分析日志找出典型的失败案例检索失败用户需要的技能根本不在Top-K返回列表中。选择失败技能在列表中但LLM没选它或者选错了。参数错误选了正确的技能但参数解析错了。针对性优化对于检索失败优化技能描述或检索模型。对于选择失败可以考虑在给LLM的提示词中增加更明确的指引或者将频繁被混淆的技能描述修改得更有区分度。将bad cases作为新的训练数据用于微调嵌入模型或重排序模型。6. 总结与展望技能调用的未来在于“调度智能”回过头看最初的问题“千万级skill会像mcp和function call一样因上下文爆炸而选错吗” 在OpenClaw这类采用检索式架构的系统里答案是否定的。它通过将“选择”问题转化为“检索选择”的两段式问题巧妙地规避了上下文爆炸对LLM决策的直接冲击。然而这种架构将系统的核心风险从LLM的认知上限转移到了检索系统的可靠性上。“技能描述的质量”和“语义检索的精度”成为了新的生命线。这要求我们像对待核心算法一样对待技能描述工程像优化推荐系统一样优化检索链路。我个人在实践中深刻体会到构建一个强大的智能体Agent系统不仅仅是堆砌强大的LLM更是要设计一个精密的“调度系统”。这个系统需要理解用户意图NLU需要从海量资源中快速定位目标检索需要做出精准决策LLM还需要可靠地执行技能运行时。OpenClaw在“检索”这一步给出了一个优雅的解法但它也只是智能体工程化道路上的一个环节。未来的方向或许是让这个“调度系统”更加自适应和智能化。例如检索的K值能否由模型根据查询复杂度动态预测技能描述能否由LLM根据实际调用反馈自动优化当检索出现歧义时系统能否主动发起澄清式询问这些问题都需要我们在工程实践中继续探索。最终让千万级技能被精准、流畅地调用不再是一个令人生畏的难题而是一个可以通过分层架构、精心设计和持续迭代来解决的工程挑战。OpenClaw为我们打开了一扇门门后的道路依然需要我们一步步去夯实。