阿里新 AI 框架跳过全量工具加载，Agent Token 消耗降低 99%

随着企业级人工智能系统规模不断扩大，以应对复杂的业务流程，从业者们面临着一个棘手的挑战：如何将子任务合理地分配到合适的工具和技能上。在一项工作流中，一个智能体可能拥有数百种工具和技能，却常常对每一步骤该选择哪一种工具感到困惑。 为了解决这一难题，阿里巴巴的研究人员开发了SkillWeaver框架——该框架能够为给定的任务生成执行图，并为每个节点选择最合适的技能。此外，他们还提出了“技能感知分解”（SAD）这一全新技术，通过构建反馈回路，使智能体能够迭代性地获取并筛选出相关的工具候选方案。这种组合式方法与反馈回路机制，使SkillWeaver区别于其他仅一次性选择工具的工具路由框架。 SkillWeaver适用于现实世界中的AI应用，这些应用中，智能体会自主协调多工具生态系统，例如模型上下文协议（MCP），以完成多步骤的业务操作，如下载数据集、对信息进行转换、生成可视化报告等。 在实际应用中，研究人员利用SkillWeaver开展的实验表明，采用这种“检索与路由”方式，不仅显著提升了准确率，而且与单纯将智能体暴露于整个工具库相比，其令牌消耗量降低了99%以上。 对于正在构建AI智能体的从业者而言，最重要的启示在于：任务分解的粒度，正是实现精准工具检索的最大瓶颈。

技能路由的挑战 在现代大型语言模型（LLM）智能体架构中，技能是一种关键的模式。技能是一种模块化、可重用的工具规范，它借助结构化的自然语言文档来定义。 当企业级智能体与海量工具生态深度融合时，将用户查询准确地路由至合适的技能，便成了一项艰巨的任务。若将整个工具库暴露给LLM以寻找合适的工具，效率极低，且往往很快就会超出上下文限制，同时还会消耗数十万的令牌。 目前大多数工具使用框架都试图通过API检索、文档匹配，或采用分层结构来解决这一问题——这些结构将路由严格视为单一技能的选择，或是逐步问题。 然而，这种单一技能的范式在企业环境中显得力不从心，因为现实世界的查询本质上具有复合性。像“下载数据集、对其进行转换、生成可视化报告”这样的标准业务请求，无法由单一工具完全完成。要实现这一目标，必须将提示词拆解开来，并将API客户端、数据处理器以及可视化工具依次串联成一个连贯的多步骤执行计划。

SkillWeaver与SAD的工作原理 为了解决这一问题，研究人员将处理需要多种技能的复杂任务的问题，归结为“组合式技能路由”。在面对复杂的用户提示和庞大的工具库时，智能体必须同时弄清：如何将请求拆分为一系列原子子任务；如何将每个子任务映射至最合适的单一技能；以及如何将这些技能组合成一个可执行的计划。 SkillWeaver通过三个不同的阶段来统筹这一过程：分解、检索和组合。在第一阶段，LLM充当任务分解器，将用户的复杂查询拆解为一系列子任务，而每个子任务都需要一种特定的技能。一旦子任务被清晰界定，系统便会利用嵌入式模型，将每个子任务与技能库进行比对，从而为每一步骤筛选出最顶尖的工具候选方案。 在最后阶段，规划器会根据各候选工具的协同效果来评估它们的表现。它会检查不同技能之间的兼容性，确保一个工具的输出能够自然地融入下一个工具的输入之中。随后，规划器会基于此生成最终的执行计划，将其构建成有向无环图（DAG），明确各任务之间的依赖关系，以便独立的任务能够并行执行。 以一位用户向AI智能体提出“下载数据集、对其进行转换、生成可视化报告”为例。在分解阶段，分解器LLM会将这一请求拆分为三个独立的子任务：下载数据集、对数据进行转换、生成报告。 在检索阶段，系统会搜索工具库，为第一步任务找到诸如“api-client”或“http-fetch”等候选工具，为第二步任务找到诸如“csv-parser”或“etl-pipeline”等工具，以此类推。最后，在组合阶段，系统会对这些候选方案进行评估，挑选出最契合的“api-client”、“csv-parser”和“chart-gen”组合，并将它们无缝衔接，形成一个可供执行的最终工作流。 这一流程的关键挑战在于：LLM往往生成的步骤描述较为通用，难以与工具库中实际可用技能的具体、专业术语相匹配。为解决这一问题，SkillWeaver引入了“迭代式技能感知分解”（SAD）这一全新反馈回路。SAD的工作原理是：首先由LLM拟定初始计划，进行初步搜索以寻找大致匹配的技能，然后将这些已检索到的技能作为提示反馈回路，重新输入LLM。这样一来，LLM可以对分解过程进行调整，使分解的粒度与词汇表完美契合实际存在的各类工具。

SkillWeaver的实际应用 为了评估SkillWeaver在真实企业场景中的表现，研究人员打造了一个名为CompSkillBench的自定义基准测试。该基准测试包含300个不同难度等级的多步骤查询。为了模拟真实世界环境，他们使用了来自公开MCP生态系统的2,209种真实世界技能库，涵盖云基础设施、金融、数据库等24个功能类别。 在核心引擎方面，研究人员主要采用了轻量级的70亿参数模型（Qwen2.5-7B-Instruct）来进行任务分解，并搭配标准的语义搜索检索器（MiniLM结合FAISS索引）来查找工具。SkillWeaver在三种主要配置下进行了评测：一种是“LLM-Direct”粗暴式方法——即把所有工具名称直接塞入大型模型的提示词中；另一种是未使用SAD的普通LLM分解方式；第三种则是ReAct风格的智能体循环流程。 实验结果表明，任务分解是最大的瓶颈。在面对庞大的工具库时，普通LLM的表现往往不尽如人意，但SAD反馈回路则能大幅提升性能。在常规配置下，70亿参数的模型仅有51.0%的时间能够成功完成任务分解（即准确预测出正确的步骤数量）。而当激活SAD反馈回路后，准确率大幅提升至67.7%（在更大规模的Qwen-Max模型中，准确率更是达到了92%）。在需要四到五种不同技能的“高难度”任务中，SAD将准确率提升了50%。 一个令人着迷的发现是：在缺乏引导的情况下，更大的模型反而可能表现更差。在常规配置下进行测试时，140亿参数的更大模型的准确率甚至跌至低于70亿参数模型的水平，因为它往往会将任务过度分解为微观且不必要的步骤。然而，当SAD反馈回路被引入后，检索到的工具提示帮助模型重新回归现实，准确率也随之提高。这表明，让智能体与特定工具的词汇体系保持一致，往往比支付更高、更昂贵的LLM更具实效性。 另一个重要的收获是令牌消耗的节省。使用超大规模的Qwen-Max模型的LLM-Direct基线显示，将所有工具直接纳入大型模型的提示词中，往往收效甚微。尽管该模型在任务拆解方面几乎做到了完美，但在工具选项泛滥的情况下，它仅在21.1%的时间内成功找到了正确的工具类别。而SkillWeaver所采用的精准“检索与路由”方式，不仅在准确率上远超这一方法，还将上下文窗口的消耗量从预估的88.4万令牌大幅削减至每条查询约1,160个令牌，降幅高达99.9%。对于从业者而言，这意味着API成本大幅降低，响应时间也得以缩短。 最后，传统的ReAct基线彻底失败，其分解准确率仅为0%。它的循环流程往往将多步骤计划简单地拆解为孤立的动作，而非明确地规划出一个连贯的多工具序列。

开发者须知 虽然研究人员尚未公开SkillWeaver的源代码，但他们的研究成果基于现成的工具，这些工具易于复现。 “技能感知分解”（SAD）是该框架的核心创新点，它巧妙地运用了提示工程与检索回路。论文作者已在文中分享了提示模板，开发者只需借助LangChain、LlamaIndex等标准编排库，或直接使用纯Python脚本，就能轻松实现这一功能。 在检索环节，作者利用了all-MiniLM-L6-v2开源嵌入式模型作为核心框架。研究发现，替换为稍强一些的现成编码器（如BGE-base-en-v1.5）后，模型的准确率立即得到提升，无需进行任何微调。尽管现成的双编码器在近70%的时间内都能将相关工具精准地推荐至前10名候选中，但其在稳定排名首位时却往往捉襟见肘，大约只有37%的时间能将工具精确地排在第一位。为了弥补这一差距，团队很可能需要引入二次交叉编码器，或利用LLM进行重新排序，以对前10名候选进行再次优化。 在前期准备阶段，首要任务是将工具库进行向量化处理，并提前构建FAISS索引。实际上，这并不算什么大障碍。在基准测试中，将全部2,209种技能进行嵌入式处理和索引，仅耗时15秒。一旦完成构建，从索引中检索工具的延迟几乎可以忽略不计，每条查询的延迟不超过15毫秒。对于企业级环境而言，同步工具索引不过是项简单的后台作业而已。 SkillWeaver目前的一个局限性在于缺乏错误恢复机制。尽管SkillWeaver能够成功绘制出兼容的执行图，但研究人员的试点研究表明，多步骤工具链仍面临诸多挑战。例如，如果在第二步的API调用失败，整条链就会中断。论文的核心贡献仅限于路由与规划阶段。若要实现真正的生产部署，从业者必须在组合阶段之上，自行构建错误恢复、回退及重试机制，以应对现实世界中出现的API超时或格式错误的输出。