1. 项目概述从“全能模型”到“技能路由”的范式演进最近在折腾大语言模型智能体LLM Agents时我一直在思考一个问题我们是不是对单个模型的要求太高了我们总希望一个模型能理解所有指令、掌握所有技能、应对所有场景这就像要求一个工程师既要精通前端React又要会写底层C驱动还得懂Kubernetes集群运维结果往往是“样样通样样松”。在实际的Agent应用开发中这种“全能型”思路常常导致系统臃肿、响应迟缓且在面对复杂、组合性任务时表现不稳定。这正是“Compositional Skill Routing”组合式技能路由这个技术方向试图解决的核心痛点。简单来说Compositional Skill Routing是一种新的智能体架构范式。它不再依赖单个“超级模型”去硬扛所有任务而是将复杂问题“分解”Decompose成子任务从一组预先定义或学习到的“技能库”中“检索”Retrieve最合适的专家技能模块最后将这些技能的执行结果“组合”Compose起来形成最终解决方案。其核心思想是“分而治之”与“专业分工”。这听起来有点像微服务架构之于单体应用或者插件化系统之于大而全的软件。背后的驱动力很明确随着任务复杂度的提升单一模型的性能天花板日益明显而模块化、组合化的设计能带来更好的可扩展性、可维护性以及任务执行的精准度。这个项目标题“Compositional Skill Routing for LLM Agents: Decompose, Retrieve, and Compose”精准地概括了其三大核心阶段。它适合正在构建复杂AI应用、寻求更高可靠性与效率的开发者、研究者和技术决策者。无论你是想打造一个能处理多步骤客服对话的机器人还是一个能自主进行市场调研和报告撰写的分析助手理解并应用这套方法论都能让你的智能体从“玩具”升级为真正可用的“工具”。接下来我将结合自己的实践和思考深入拆解这三大环节的技术细节、实现路径以及那些容易踩坑的地方。2. 核心架构与设计哲学为何“路由”优于“蛮干”在深入技术细节之前我们必须先理解为什么需要“技能路由”这种架构。传统的LLM智能体无论是基于ReAct、Tool Calling还是其他框架其核心工作流可以概括为接收用户请求 - 模型思考规划- 调用工具/API - 整合结果 - 输出。在这个过程中负责“思考”和“规划”的通常是同一个LLM。这就带来了几个根本性问题2.1 单一模型的局限性首先知识冲突与遗忘。一个通用模型在学习了大量数据后其内部参数表征是高度耦合的。当你要求它同时精通编程、医疗咨询和创意写作时不同领域的知识可能会在参数空间内相互干扰导致在特定任务上的表现不如专精模型。其次上下文长度与效率的权衡。复杂的任务规划往往需要很长的思考链Chain-of-Thought这会大量消耗宝贵的上下文窗口挤占实际工具调用和结果处理所需的空间。最后成本与延迟。使用超大参数量的模型来处理每一个简单的子任务比如查个天气在成本和响应时间上都是不经济的。2.2 组合式技能路由的优势组合式技能路由架构正是针对上述问题提出的系统性解决方案。它的设计哲学包含以下几点关注点分离将“任务规划与分解”战略层、“专业技能执行”战术层和“结果合成”整合层分离开由不同的模块负责。这符合软件工程的高内聚、低耦合原则。专业化优势为不同类型的子任务配备专门的“技能模型”。这个技能模型可以是一个微调过的小模型一个针对特定API进行了优化的提示模板甚至是一段精心编写的代码函数。专业化的技能模块在其领域内通常比通用模型更准确、更快速。动态性与可扩展性技能库可以动态增删。当需要增加新能力时只需开发一个新的技能模块并将其注册到库中无需重新训练或调整核心路由与规划模型。这极大地提升了系统的可扩展性。资源优化通过路由机制可以将简单任务导向轻量级技能复杂任务才动用重量级模型从而实现计算资源的合理分配降低整体运营成本。这种架构很像一个高效的技术团队产品经理规划模型分析客户需求并拆解成任务单然后根据任务类型分派给对应的专家技能模型——前端工程师、后端工程师、测试工程师等。专家们完成各自工作后再由项目经理组合模块整合成最终产品交付。这显然比让一个“全栈工程师”从头到尾包办一切要高效、可靠得多。注意转向技能路由架构并非没有代价。它引入了模块间通信、状态管理、错误传递等新的复杂度。决策的关键在于你的应用场景如果任务相对单一且固定传统单体智能体可能更简单直接但如果面对的是开放域、多步骤、需要多种专业知识的复杂任务技能路由架构的优势将非常明显。3. 第一阶段分解——将模糊意图转化为清晰任务图一切始于“分解”。用户的原始请求往往是模糊、复杂且充满歧义的。例如“帮我分析一下上周的销售数据预测下季度趋势并写一份给管理层的简报”。这个请求至少包含了数据获取、数据分析、趋势预测、报告撰写等多个环节。分解阶段的目标就是将一个这样的宏观目标解析成一个结构化的、可执行的任务序列或任务图。3.1 分解的策略与方法分解的核心是一个“规划器”通常由一个LLM担任。这个规划器需要具备强大的逻辑推理和领域理解能力。常见的分解策略有顺序分解将任务分解为一系列前后依赖的步骤。例如“1. 从数据库获取上周销售数据2. 清洗并汇总数据3. 运行时间序列预测模型4. 根据预测结果生成简报要点5. 格式化为PPT草案。” 这适用于线性流程的任务。层次分解将任务分解为树状结构顶层是总目标下层是子目标子目标可能进一步分解。这更适合结构复杂的任务。图状分解识别出子任务之间的依赖关系形成有向无环图。某些任务可以并行执行某些则必须等待前序任务完成。例如“获取数据”和“确定简报模板”可以并行但“分析数据”必须在“获取数据”之后。在实际实现中我们会给规划器LLM一个精心设计的提示词要求它输出结构化的分解结果比如JSON格式{ main_goal: 分析销售数据并撰写简报, sub_tasks: [ { id: 1, description: 从CRM系统的‘Sales’表中提取过去7天的所有交易记录。, output: raw_sales_data.csv, dependencies: [] }, { id: 2, description: 清理数据处理缺失值统一货币单位计算每日总销售额。, output: cleaned_daily_sales.csv, dependencies: [1] }, { id: 3, description: 使用Prophet模型对清理后的日销售额数据进行未来90天的预测。, output: sales_forecast_plot.png forecast_data.csv, dependencies: [2] }, { id: 4, description: 基于原始数据总结关键指标如环比、最佳销售品类并整合预测结论形成文字摘要。, output: analysis_summary.md, dependencies: [2, 3] }, { id: 5, description: 将文字摘要和关键图表填充到公司标准的PPT模板中生成最终简报文件。, output: management_briefing.pptx, dependencies: [4] } ] }3.2 分解的挑战与实操心得分解阶段看似简单实则暗藏玄机是后续所有步骤的基础。这里有几个关键的实操要点规划器的选择与提示工程规划器LLM的能力直接决定分解质量。通常我们会选择在推理和编码任务上表现好的模型如GPT-4、Claude-3或DeepSeek。提示词必须明确要求结构化输出并给出清晰的示例。一个技巧是让规划器“扮演”一个经验丰富的项目经理或系统架构师这能有效提升其分解的逻辑性。粒度把控分解的粒度至关重要。粒度过粗如“处理数据”技能模块仍然无法直接执行粒度过细如“打开Excel文件”、“点击A列”则会产生大量不必要的任务节点增加路由和调度开销。一个好的经验法则是每个子任务的描述应该明确到能让一个具备相关领域知识的“专家”无需再追问上下文就能直接执行。例如“计算每日总销售额”是合适的粒度“处理数据”则不是。依赖关系识别自动识别子任务间的依赖关系是高级功能也是难点。初期可以依靠规划器LLM来推断但这可能出错。更稳健的做法是在技能库中为每个技能模块预定义其输入/输出格式系统在分解后自动分析任务描述的输入输出从而推导出依赖图。例如任务3的描述中提到了“使用清理后的数据”系统可以自动将其与任务2的输出cleaned_daily_sales.csv建立依赖关系。错误处理与重规划分解不是一劳永逸的。当某个子任务执行失败或者执行结果不符合预期时系统需要有能力触发“重规划”。这可能涉及调整后续任务序列甚至回溯到分解阶段重新分析。在设计时要为整个流程注入“容错”和“反馈”机制。实操心得在项目初期不要追求全自动的完美分解。可以采用“人机协同”的方式先由LLM生成一个初步分解草案再由开发人员审核、调整和确认。这既能保证质量也能为后续优化全自动流程积累高质量的分解样本数据。4. 第二阶段检索——为任务匹配最合适的技能专家任务被清晰分解后下一步就是为每个子任务找到“对的人”即技能检索。这是“路由”概念的核心体现。我们有一个“技能库”里面注册了各种技能模块。检索器的任务是根据当前子任务的描述从库中找出最匹配的一个或多个技能。4.1 技能库的构建与表征技能库的本质是一个可检索的数据库。每个技能条目至少包含技能名称/ID唯一标识符。技能描述用自然语言详细描述该技能能做什么。例如“调用WeatherAPI根据城市名查询未来24小时的天气情况返回温度、湿度、天气状况和降水概率。”调用方式如何执行这个技能。可能是一个API的端点地址和参数说明一个本地函数的调用路径或是一段封装好的提示词模板。输入/输出格式明确该技能接受什么格式的输入如JSON Schema以及返回什么格式的数据。元数据如技能类别“数据获取”、“文本生成”、“代码执行”、所需计算资源、平均执行耗时、作者、版本等。检索的关键在于如何根据“任务描述”找到最相关的“技能描述”。传统的关键词匹配如TF-IDF在这里效果有限因为自然语言表述多样。因此向量检索成为了主流技术。4.2 基于嵌入模型的语义检索具体流程如下离线处理将技能库中所有技能的“描述”文本通过一个文本嵌入模型如text-embedding-3-small、bge-large-zh等转换为高维向量嵌入并存入向量数据库如Chroma、Weaviate、Milvus。在线检索当收到一个子任务描述时使用同样的嵌入模型将其转换为查询向量。相似度计算在向量数据库中计算查询向量与所有技能向量之间的相似度通常用余弦相似度。返回结果返回相似度最高的前k个技能作为候选。这种方法实现了语义层面的匹配。即使任务描述是“帮我看看北京明天会不会下雨”而技能描述是“查询城市天气预报”两者没有共同关键词但通过向量相似度也能被正确匹配。4.3 检索的优化与混合策略单纯的语义检索有时会出错尤其是当技能库庞大或任务描述模糊时。因此需要引入混合策略元数据过滤在向量检索前或后利用技能的元数据进行筛选。例如如果任务明显是“画图”可以先过滤出类别为“图像生成”的技能再进行向量检索提高精度和速度。重排序向量检索返回Top-K个候选后可以使用一个更精细的“重排序器”来二次排序。这个重排序器可以是一个小型的交叉编码器模型它同时接收任务描述和技能描述输出一个更精确的相关性分数。LLM作为裁判将向量检索得到的Top-3个候选技能连同任务描述一起交给一个LLM可以是较小的模型让它基于对任务和技能的深层理解选择或合成最终技能。提示词可以是“给定任务T和三个候选技能A、B、C请判断哪个技能最适合执行该任务并说明理由。”技能组合检索有时一个任务可能需要多个技能协同完成。检索器需要有能力识别这种情况并返回一个技能序列或组合方案。这可以通过让LLM分析任务复杂度或检索出多个相关技能后由组合模块决定如何调用。4.4 实操中的陷阱与解决方案冷启动问题新系统技能库空空如也检索无从谈起。解决方案是建立一个“基础技能包”覆盖最常见操作如网络搜索、计算器、文件读写、调用特定知名API。随着使用再不断扩展。技能描述的质量技能描述直接决定检索效果。描述必须准确、全面、无歧义。避免使用过于宽泛或内部术语。一个好的实践是采用“功能输入输出”的模板来编写描述。相似度阈值设置一个相似度阈值。当最高相似度低于该阈值时认为技能库中没有合适技能系统应触发“技能缺失”处理流程例如向用户反馈无法完成或尝试调用一个通用的“问题分解与规划”技能来进一步拆解该任务。动态更新技能库需要支持动态增删改。新的技能注册后其向量表征需要实时或定期更新到向量数据库中。踩坑记录我曾遇到一个案例任务描述是“生成本月销售数据的柱状图”。技能库中有一个“用Matplotlib生成图表”的技能但描述写的是“使用Python Matplotlib库绘制各种统计图表”。由于“柱状图”这个词在技能描述中没有出现仅靠早期版本的嵌入模型检索相似度并不高反而检索到了一个描述中有“生成图像”但实际是AI绘画的技能。后来通过优化技能描述加入“柱状图、折线图、饼图”等关键词并采用“嵌入模型检索LLM重排序”的混合方案才彻底解决了问题。这告诉我们技能描述的工程和检索策略的调优与算法本身同等重要。5. 第三阶段组合——将子结果编织成最终答案检索到的技能被逐一执行后我们会得到一系列子结果。这些结果是分散的、原始的可能是数据片段、文本段落、图表、状态码等。“组合”阶段的任务就是像一个导演或编辑一样将这些素材有机地整合起来形成一个连贯、完整、符合用户原始意图的最终输出。5.1 组合的层次与策略组合并非简单的字符串拼接它发生在不同层次数据流组合这是最基本的形式。前一个技能的输出是后一个技能的输入。系统需要按照任务依赖图管理好中间数据的传递。例如数据清洗技能输出的DataFrame对象需要正确地传递给预测模型技能。这要求系统有良好的状态管理和数据序列化/反序列化能力。信息整合当多个技能并行执行或产生互补信息时需要将它们的信息整合起来。例如一个技能查询了A产品的价格另一个技能查询了其竞品B的价格组合模块需要将两者放在一个对比表格中。叙事性合成对于需要生成最终报告、摘要或回答的任务组合模块需要具备强大的文本合成能力。它需要理解各子结果的核心信息并按照逻辑如总分总、时间顺序、重要性排序组织语言生成通顺、专业的文本。这个角色通常也由一个LLM担任我们可称之为“合成器”。5.2 合成器的关键作用与提示设计“合成器”是一个专门的LLM其输入是所有子任务的描述、执行状态成功/失败以及它们的输出结果其任务是生成面向用户的最终答案。一个有效的合成器提示词框架如下你是一个智能助理的结果合成专家。你的任务是根据以下任务分解和执行结果生成一个完整、清晰、专业的最终回复给用户。 **用户的原始请求** {用户原始查询} **任务分解与执行记录** 1. 任务[任务1描述] 状态成功 输出[任务1输出内容可能是文本、数据、文件路径等] 2. 任务[任务2描述] 状态成功 输出[任务2输出内容] 3. 任务[任务3描述] 状态失败 错误信息[任务3错误详情] ... **合成要求** - 只基于以上提供的执行结果进行合成。如果任务失败请在回复中诚实说明并分析其对最终目标的影响。 - 整合所有成功任务输出的关键信息。 - 回复结构应清晰语言应专业且易于理解。 - 如果生成了文件如图表、文档请在回复中说明文件已生成并描述其内容。 请开始你的合成工作5.3 处理执行失败与部分成功组合阶段必须具备鲁棒性以处理子任务失败的情况。策略包括降级处理如果某个获取详细数据的技能失败但有一个获取摘要数据的技能成功合成器可以在最终报告中说明“详细数据暂缺”但仍基于摘要数据给出洞察。影响评估与说明合成器需要评估失败任务对整体目标的影响。如果它是关键路径上的任务则最终回复应明确告知用户任务无法完成并解释原因。如果是辅助性任务则可以忽略或寻找替代方案。触发重试或重规划对于某些可预见的临时性错误如网络超时组合模块可以决定自动重试该技能。对于更复杂的失败它可以向规划模块反馈触发对剩余任务的重新规划。5.4 状态管理与上下文传递一个健壮的组合系统需要维护完整的执行上下文。这包括全局状态存储用户原始目标、任务图、各任务状态、输入输出映射等。中间数据存储妥善保管每个技能产生的中间数据确保它们能在后续技能或合成器需要时被正确访问。对于大型数据可能需要引用文件路径或数据库ID而非直接存储在内存中。对话历史在多轮对话的Agent中本轮的组合结果和上下文需要被妥善保存以便在下一轮交互中作为历史信息被参考。个人体会组合阶段是最能体现智能体“智能”和“用户体验”的环节。一个机械的拼接式回复和一个经过理解、整合、润色的回复给用户的感觉是天差地别的。在实践中我发现专门训练或精心提示一个“合成器”模型其效果远好于让负责规划的同一个模型来兼职合成。这再次印证了“分工专业化”的优势。此外为合成器提供清晰、结构化的输入如我上面提到的提示词框架比直接把一堆杂乱的结果扔给它能显著提升最终输出的质量和稳定性。6. 系统实现与工程化考量理解了Decompose, Retrieve, Compose的核心概念后我们需要将其落地为一个可运行的系统。这里不涉及具体某一行代码而是讨论架构选型和工程实践中必须考虑的关键问题。6.1 参考架构设计一个典型的组合式技能路由系统可能包含以下组件[用户请求] | v ------------------- | 规划器 (Planner) | - 通常是一个强大的LLM负责任务分解 | (LLM 提示工程) | ------------------- | v (结构化任务列表/图) | v ------------------- | 技能路由器 | | (Skill Router) | - 核心路由逻辑 ------------------- | v ------------------- | 技能检索器 | - 对接向量数据库进行语义检索 | (Retriever) | ------------------- | v [技能执行队列] | v ------------------- | 技能执行器 | - 调用具体的技能模块API、函数、模型等 | (Executor) | ------------------- | v (子任务结果集合) | v ------------------- | 合成器 (Synthesizer)| - 另一个LLM负责结果整合与最终回复生成 | (LLM 提示工程) | ------------------- | v [最终回复给用户]6.2 技能模块的标准化接口为了便于管理、检索和调用所有技能模块应遵循统一的接口标准。一个简单的设计可以是class Skill: def __init__(self, skill_id, name, description, input_schema, output_schema): self.skill_id skill_id self.name name self.description description # 用于检索的文本 self.input_schema input_schema # 定义输入格式如JSON Schema self.output_schema output_schema # 定义输出格式 async def execute(self, input_data: Dict, context: Dict) - Dict: 执行技能的核心方法。 :param input_data: 符合input_schema的输入数据 :param context: 全局执行上下文可能包含用户信息、历史等 :return: 符合output_schema的输出数据必须包含‘status’(success/error)和‘output’字段 # ... 具体的技能逻辑 ... return { status: success, output: {...}, # 技能执行结果 metadata: {...} # 耗时、消耗token等元数据 }6.3 异步执行与依赖调度对于存在依赖关系的任务图需要一个小型的调度器。它解析任务间的依赖决定哪些任务可以并行执行哪些必须顺序执行。利用Python的asyncio等异步框架可以大幅提升并行任务的执行效率。对于无依赖的子任务并行执行能显著缩短整体响应时间。6.4 监控、日志与可观测性在分布式、模块化的系统中可观测性至关重要。你需要记录规划日志原始请求、分解出的任务图。检索日志每个子任务的描述、检索到的候选技能及相似度分数。执行日志每个技能调用的开始/结束时间、输入、输出、状态、错误信息。合成日志合成器的输入和最终输出。这些日志不仅用于调试和排错更是优化系统如改进技能描述、调整检索策略、训练规划器的宝贵数据来源。7. 典型问题排查与性能调优实录在实际开发和运维这样一个系统时你会遇到各种各样的问题。下面是我总结的一些典型场景及其排查思路。7.1 问题规划器分解出的任务不合理要么太粗要么太细。排查检查提示词首先审视给规划器的提示词是否足够清晰是否提供了好的示例尝试加入更具体的约束如“请将任务分解为5-10个可独立执行的子任务”。更换模型如果使用的是较小或较旧的模型尝试升级到更强大的模型如从GPT-3.5-Turbo切换到GPT-4或Claude-3。规划能力对模型的要求很高。引入验证环节在规划器后增加一个“任务验证”步骤用另一个LLM或一套规则来判断分解的合理性并对不合理处进行修正或重分解。人工反馈循环收集一批分解不好的案例进行人工修正然后将这些“问题分解-修正后分解”的对加入提示词作为示例或用于微调规划器模型。7.2 问题技能检索不准经常匹配到错误的技能。排查检查技能描述这是最常见的原因。确保描述准确、具体、无歧义并包含关键的同义词。可以尝试用LLM来优化和扩写现有技能描述。评估嵌入模型你使用的文本嵌入模型是否适合你的领域中文/英文、通用/专业尝试更换或微调嵌入模型。可以在技能库上构建一个测试集评估不同嵌入模型的检索准确率。调整检索策略是否只用了向量检索尝试引入元数据过滤或LLM重排序。调整相似度阈值太高可能导致召回不足太低则精度下降。分析失败案例对检索错误的案例进行归因分析。是语义理解偏差还是技能库覆盖度不足针对性地补充技能或调整描述。7.3 问题整体流程耗时太长用户体验差。排查与调优性能剖析使用监控日志分析耗时瓶颈在哪里。是规划慢检索慢还是某个技能执行慢规划阶段对于常见或模式固定的任务可以引入“缓存”机制。将“用户请求 - 任务图”的结果缓存起来下次遇到相同或高度相似的请求直接使用。检索阶段向量检索本身很快但如果技能库极大数万以上需要考虑索引优化。确保向量数据库的索引类型适合你的查询模式。执行阶段并行化确保无依赖的任务真正在并行执行。技能优化对执行慢的技能进行优化例如为耗时的计算技能增加超时和中断机制。异步流式输出对于长任务可以考虑采用流式响应先返回部分确定的结果而不是让用户等待所有任务完成。合成器也可以分阶段工作。模型调用规划器和合成器的LLM调用通常是主要延迟来源。考虑使用更快的模型如推理优化后的版本或对非关键路径的LLM调用使用较小的模型。7.4 问题技能执行失败导致整个流程中断。排查与容错设计错误分类将错误分为可重试的如网络超时、API限流和不可重试的如参数错误、权限不足。实现重试机制为可重试错误配置指数退避的重试策略。备用技能为关键技能配置备用方案。例如主要天气API失败时自动切换到备用天气API。优雅降级在组合阶段合成器需要被训练或提示以处理部分失败的情况生成仍具价值的回复而不是直接报错。超时控制为每个技能设置合理的超时时间防止一个技能的卡死阻塞整个流程。7.5 问题最终合成的答案质量不高像是生硬的拼凑。排查检查合成器输入确保输入给合成器的信息是结构化和完整的。杂乱的输入必然导致低质量的输出。优化合成器提示词像前文所述提供清晰的指令、上下文和格式要求。让合成器“扮演”一个专业的编辑或分析师。升级合成器模型合成文本需要很强的语言理解和生成能力尝试使用更先进的模型。后处理在合成器输出后可以增加一个简单的后处理步骤进行基本的格式检查、错别字纠正等。构建一个成熟的组合式技能路由系统是一个持续迭代的过程。从最简单的顺序流水线开始逐步引入更复杂的依赖调度、更智能的检索、更鲁棒的容错机制。每一次问题的解决都会让你的智能体变得更加强大和可靠。这套架构的真正威力在于它将复杂系统的可控性和可解释性与大型语言模型的通用能力结合了起来为构建下一代可靠、高效的AI应用提供了坚实的蓝图。