解读论文《SkillOrchestra: Learning to Route Agents via Skill Transfer》

简介: AI系统由多模型协作时,"派谁上场"是核心难题。现有方法要么无法应对多步骤任务,要么陷入"总调最贵模型"的死胡同。SkillOrchestra从历史轨迹提炼"技能手册",让编排器匹配最合适的智能体,性能提升22.5%,成本节省700倍。

论文《SkillOrchestra: Learning to Route Agents via Skill Transfer》提出了一种名为 SkillOrchestra 的 AI 应用编排框架。该框架旨在解决在复杂任务中如何高效、低成本地协调多个不同能力和成本的 AI 模型的问题。其核心创新在于,它不直接端到端地学习一个固定的路由策略,而是通过从过往经验中学习、提炼和迁移“技能”(Skills),来动态地、有针对性地为任务的每一步选择最合适的智能体。

01

论文试图解决的问题


现代 AI 应用正变得越来越复杂,通常由多个大型语言模型(LLM)和专用工具(如代码执行器、搜索引擎)组合而成,一般称为智能体。这类应用能否有成功应用,很大程度上取决于其“编排”(Orchestration)能力——在任务执行的每个环节,决定调用哪个模型或工具。现有的一些编排方法主要存在两大问题:

1. 模型路由方法: 这类方法仅根据用户最初的输入查询,一次性地做出一个粗粒度的决策,静态选择一个模型来完成整个任务。

这种“一刀切”的模型选择模式无法适应多步骤、动态演化的复杂任务,因为任务的不同阶段可能需要截然不同的能力。例如假设一个任务是“请分析最近一周的特斯拉股价,并预测下周的趋势”。

这个任务至少包含两个阶段:第一阶段是数据检索,需要调用搜索引擎或财经数据 API 来获取最新的股价数据;第二阶段是数据分析与预测,需要利用一个具备强大数理统计和代码执行能力的模型来进行时间序列分析。

静态路由在一开始就必须决定是调用一个“搜索型”模型还是一个“分析型”模型,而不是根据不同的任务阶段状态去选择相应的模型,因此无论选择哪个都无法高效地完成整个任务。

2. 基于强化学习的编排方法: 这类方法虽然更加灵活,能够处理多步决策,但面临着新的挑战。

首先,它们的训练成本极其高昂,需要大量的训练样本和计算资源。

其次,适应性差,当模型库或工具集发生变化时,往往需要重新训练。

最严重的问题是,它们常常会陷入“路由坍塌”(Routing Collapse)的困境——即无论任务需求如何,在选择模型时策略总是倾向于反复调用同一个功能最强但成本也最高的模型,忽视了其他更具性价比的选项,导致资源浪费和效率低下。

综上,本论文旨在解决的核心问题是:如何构建一个高效、经济、适应性强且决策粒度更精细的智能体编排系统,以克服现有方法的局限性。


02

论文的解决方案说明


论文提出的解决方案是 SkillOrchestra 框架,其精髓在于引入了“技能”这一中间抽象层,将复杂的端到端路由问题分解为“技能手册的构建”(Skill Handbook Learning)和“基于技能的路由” (Skill-Grounded Orchestration)两个阶段。

SkillOrchestra 核心组件是一个可复用的“技能手册”(Skill Handbook)。

图片源自论文,展示了模型路由与智能体编排方法的比较。左侧显示模型路由,在查询级别进行静态模型选择,无需动态模式或工具推理。

上图中间显示基于强化学习的智能体编排,通过隐式能力建模端到端地学习路由,容易出现路由崩塌。

上图右侧显示基于 SkillOrchestrat 的智能体编排,利用可重用的技能手册,采用显式的技能级别能力建模,实现代理的均衡利用和可扩展性。

2.1 技能手册的构建

“技能手册”是从智能体的历史执行轨迹(即成功和失败的案例)中自动学习和提炼出来的知识库。在深入其构成之前,首先需要理解这些“执行轨迹”是如何被获取和处理的。

执行轨迹是技能学习的原材料,其处理过程分为两步:

1. 轨迹获取: 系统首先会构建一个“探索性数据集”。具体做法是,针对同一个初始问题(Query),系统会刻意地选用不同的智能体(Agent)去尝试完成任务,从而为这一个问题生成一个包含多条不同执行路径和结果的轨迹集合。

这个集合中既包含了成功的轨迹,也包含了失败的轨迹。

2. 轨迹对比与分析: 这是提炼新技能的核心环节。系统会从上述集合中,针对同一个问题,找出一对轨迹——一条成功轨迹和一条失败轨迹。通过对比这两条轨迹的差异,系统可以定位到导致任务失败的关键“能力缺失点”。

例如,可能发现成功轨迹中调用了代码解释器进行了精确计算,而失败轨迹中模型试图进行心算导致出错。此时,一个更高阶的“发现者”模型(LLM-based Discoverer)就会将这个“能力缺失点”抽象、泛化为一个可复用的技能,例如命名为 numerical_approximation (数值近似计算),并将其存入技能注册表。

通过这个流程,系统源源不断地从具体的成功与失败案例中,学习并扩充其对“能力”的定义。

接下来,这些学习到的技能被组织进“技能手册”的三个核心部分:

1. 技能注册表(Skill Registry): 这是对智能体所需能力的精细化、层级化的定义。技能(Skill)的定义是:一个技能是一种可复用的能力抽象,它明确了在某个操作模式(如 searchcode)下完成任务所需的具体能力类型。技能在高级的“模式”和具体的“智能体”之间构建了一个中间层,从而将“能力需求”与“智能体”解耦。

2. 智能体档案(Agent Profiles): 为每个智能体(即模型与工具的组合)建立一个档案,详细记录它在每个特定“技能”上的表现(如成功率)、预估成本(如 token 消耗、延迟)以及使用建议(如优缺点)。这相当于为每个智能体制作了一份详细的“能力说明书”。

3. 模式选择洞察(Mode Selection Insights): 记录在不同任务状态下,应该采取何种操作模式(如“搜索”、“编码”或“回答”)的经验法则。例如,“如果需要进行多步数学计算,应从搜索模式切换到编码模式”。

这个技能手册构建过程是迭代进行的,系统会通过“合并”相似技能、“拆分”过于宽泛的技能来不断优化技能手册的质量和粒度。

2.2 基于技能的编排流程

在实际任务执行时,SkillOrchestra 的编排器会利用“技能手册”进行决策,流程分三步:

1. 手册选择: SkillOrchestra 的一个核心洞察——“技能手册”并非越大越好,其最优的规模和粒度取决于使用它的“编排器”模型自身的能力。

因此,在实际部署时,系统会首先为当前的编排器模型选择一个最适合它的“子手册”。

  • “大手册” vs “子手册”大手册 (Global Handbook) 指的是通过技能学习和提炼过程构建的、包含所有已发现技能的完整版技能手册。它可能包含上百个非常细粒度的技能,是整个系统的“母知识库”。例如,论文图示中提到的包含 98 个技能的候选手册就可以看作是一个“大手册”。

    子手册 (Orchestrator-Specific Handbook) 指的是从“大手册”中筛选出的一个子集,专门用于匹配某个特定编排器模型的能力。例如,一个为 Qwen2.5-3B 这样较弱的编排器选择的“子手册”可能只包含 10 个核心、粗粒度的技能;而为一个像 GPT-5 这样的强编排器选择的“子手册”则可能包含 43 个更细致的技能。

  • 构建方式: “子手册”的构建过程被称为“帕累托最优的手册选择”。系统会在一个验证数据集上,测试不同规模和组合的“子手册”(如分别测试只含 10 个、20 个、43 个...技能的手册版本)。对于每个版本,系统都会评估其在特定编排器下的“任务准确率”和“执行成本”。最终,系统会选择那个能够在该编排器上实现最佳“性能-成本”权衡(即帕累托最优)的手册版本作为最终部署的“子手册”。


  • 示例假设一个任务需要进行符号逻辑推理。一个强大的编排器,在使用包含 symbolic_logic 和 numerical_approximation等多个细分技能的“子手册”时,能准确识别出前者并调用专门的模型,从而高效完成任务。而一个较弱的编排器,如果也使用同样复杂的手册,可能会混淆这两个技能,错误地调用了数值计算模型,导致任务失败。因此,对这个弱编排器来说,一个只包含 data_processing这个更宽泛技能的“子手册”反而更优,因为它能稳定地做出一个虽不完美但正确的路由决策。

2. 模式选择(Mode Selection): 在任务的每一步,编排器首先会查阅手册中的“模式选择洞察”,结合当前任务状态,决定下一步应该执行哪种操作模式,例如是应该上网搜索,还是应该编写代码。

任务状态是指“原始问题 + 到该时刻为止累积的交互历史”。这意味着“任务状态”是一个动态变化、不断增长的上下文。以下面的多轮问答为例:

  • 初始状态 (S0): 仅包含原始问题:“这首歌的作曲家是谁?”
  • 第一轮后的状态 (S1): 包含了原始问题,以及第一次调用 Qwen2.5-7B 后的完整交互记录(包括 Qwen 给出的那个包含错误信息和大量噪音的回答)。
  • 第二轮后的状态 (S2): 包含了原始问题、第一次的交互记录,以及第二次调用 LLaMA-3.1-70B 后的交互记录(包括 LLaMA 给出的那个不确定的回答)。
  • 第三轮(S3):编排器在决定第三步是继续搜索还是直接回答时,它的决策依据就是这个包含了前两次失败尝试的完整状态 S2。通过分析这个累积的交互历史,编排器可以判断出当前信息尚不充分或存在矛盾,因此需要继续调用 search 模式进行交叉验证,而不是直接进入 answer 模式。

3. 智能体选择(Agent Selection): 在确定了操作模式后,编排器会分析当前子任务需要哪些具体“技能”。然后,它会查阅所有可用智能体的“档案”,找到在这些技能上表现最好、且成本最低的那个智能体,并将其选中执行任务。

通过手册选择-模式选择-智能体选择这三步流程,SkillOrchestra 将原本模糊的、凭感觉的路由决策,转变为一个清晰的、基于数据和明确权衡的结构化查询过程。它不再盲目地依赖最强的模型,而是为每个子任务“量体裁衣”,实现了能力与需求的精准匹配,从而在提升效果的同时,极大地降低了系统运行的总体成本。

2.3 实践中的挑战与解决方法

在构建“技能手册”并将其应用于实践的过程中,论文作者识别并解决了两个关键的挑战:

挑战一:技能粒度与编排器能力的适配问题。

  • 问题描述: 学习到的“技能手册”可能包含非常细粒度的技能划分。一个能力强大的编排器模型(如 GPT-5)或许能理解并利用这些细微差别,但一个能力较弱的编排器模型(如 Qwen2.5-3B)可能会被这些过于精细的技能搞糊涂,错误地识别任务需求,从而做出错误的路由决策,反而降低了性能。

  • 解决方法:帕累托最优的手册选择(Pareto-Optimal Handbook Selection)。论文并未使用“一刀切”的手册选择策略,而是为每个编排器模型“量身定制”一个最适合其能力的“子手册”。


    具体做法是,在验证集上测试不同粒度的技能组合,找到那个能在特定编排器的能力下,实现最佳“性能-成本”平衡点的技能组合。这确保了即便是能力较弱的编排器,也能从技能体系中获得最大收益,而不会被其复杂性所拖累。

挑战二:原始技能集的质量问题。

  • 问题描述: 最初通过对比成功/失败案例自动发现的技能,可能存在冗余、重叠或定义过于宽泛的问题,形成一个杂乱无章的“草稿”技能集。直接使用这样的技能集,会影响路由的效率和准确性。

  • 解决方法:技能手册的提炼(Handbook Refinement)。文设计了一个迭代式的“提炼”流程来优化技能集。该流程包含两个核心操作,一是拆分(Splitting),即当发现某个技能在不同任务上的表现差异巨大时,系统会判定该技能可能包含了多种潜在的子能力,并将其拆分成更具体的几个技能。

    二是合并(Merging),即当发现两个不同技能所对应的模型表现惊人地相似时,系统会认为这两个技能在路由决策上是等价的,并将它们合并以消除冗余。这个过程由一个更高阶的“反思模型”(LLM-based Reflector)来监督和执行,确保了技能手册的质量和结构不断优化。

03

论文解决方案的效果说明


论文提出 SkillOrchestra 框架针对上述问题提供了高度完整且有效的解决方案。其中一些论文实验数据如图:

图:性能与成本对比

图:左侧基于 SkillOrchestra 编排器可以缓解路由坍塌问题,右侧跨编排器模型通用

从论文中详尽的实验数据和分析来看,其解决问题的完成度非常高,主要体现在以下几个方面:

评估维度

SkillOrchestra 表现

备注

任务效果(Accuracy)

在 10 个不同的基准测试中,性能最高超过当前最先进的 RL 方法 22.5%

覆盖了通用问答、多步推理问答和数学推理等多种复杂任务。

学习效率(Efficiency)

学习成本相比两种主流 RL 方法(Router-R1 和 ToolOrchestra)分别降低了 700 倍和 300 倍

无需昂贵的端到端强化学习训练,数据效率极高。

决策质量(Routing Behavior)

有效避免了“路由坍塌”,实现了更加均衡和合理的智能体调用。

例如,RL 方法 98% 的调用都给了最贵的模型,而 SkillOrchestra 会根据任务需求,将调用分散到多个不同成本和能力的模型上。

知识迁移与适应性

学习到的“技能手册”可以被不同的编排器模型直接复用,无需重新训练。

这是一个重大优势,意味着系统可以轻松适应模型库的更新换代,具有很强的可扩展性和模块化特性。

成本效益(Cost-Effectiveness)

在取得更高准确率的同时,显著降低了推理成本。

通过智能地选择更经济的模型处理简单子任务,避免了不必要的开销。

综上所述,SkillOrchestra 不仅在理论上提出了一个优雅的替代方案,更通过大量的实验证明了其在实践中的优势。它成功地解决了现有编排方法在效率、成本和适应性上的核心痛点,为构建 AI 应用提供了一条清晰且可行的路径。

04

请注意,这不是 Agent 的 SKILL.md



在阅读 SkillOrchestra 论文时,很容易将其中的"技能"(Skill)概念与业界另一个广为人知的概念——Anthropic 提出的 Agent Skills ——相混淆。尽管两者都旨在增强 AI 智能体的能力,但它们的底层哲学、实现方式和核心用途存在本质区别。

简单来说,SkillOrchestra 的"技能"是应用在内部自动学习到的、用于优化路由决策的抽象能力标签,而 Anthropic 的"Agent Skill"是由人类开发者为智能体编写的、用于执行具体任务的显式指令集

05

局限性与未来方向



尽管 SkillOrchestra 取得了显著的优势,但其当前的设计也存在一些潜在的局限性,并为未来的研究指明了方向。

5.1 潜在局限性

  • 对高质量执行轨迹的依赖: “技能手册”的学习过程始于对成功和失败任务轨迹的分析。这意味着系统的初始性能高度依赖于所提供的“探索性数据集”的质量和多样性。如果初始数据存在偏差或覆盖面不足,学习到的技能可能无法泛化到更广泛的真实世界场景中。

  • 技能提炼过程的可扩展性: 技能的“拆分”与“合并”由一个更高阶的“反思模型”(如 GPT-5)来指导。随着智能体池和技能数量的急剧增长,这种依赖于大型模型进行的操作,可能会成为一个计算和成本上的瓶颈。

  • 技能定义的静态性: 尽管技能手册可以被提炼和筛选,但单个技能一经定义(即其自然语言描述和指标),其本身是相对静态的。系统目前缺乏一种机制,让技能的内在定义能够根据持续的反馈进行动态的、细微的自我调整。

5.2 未来可探索的方向

  • 全自动化的持续技能进化: 当前的技能学习和提炼在很大程度上是离线完成的。一个更理想的未来系统将能够从实时的生产流量中持续、自动地学习和进化其技能手册,实现一个真正意义上的自适应、自优化的编排系统。

  • 跨组织、跨领域的技能迁移: 论文成功验证了技能在不同编排器模型间的可迁移性。一个更宏大的愿景是,实现技能在不同组织、甚至不同知识领域间的迁移。这可能催生一个开放的“技能市场”,允许开发者共享、交易和复用高质量的技能定义,极大地加速 AI 应用的开发。

  • 更深度的人机协同回路: 未来的研究可以探索如何将人类专家的直接反馈更紧密地整合到技能学习的循环中。例如,允许人类专家直接修正技能的定义、调整智能体的能力评估,或者对特定的路由决策给出赞成或否决的意见,从而以更高效的方式指导系统学习。


参考链接

[1] SkillOrchestra: Learning to Route Agents via Skill Transfer

https://arxiv.org/abs/2602.19672

[2] Agent Skills

https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview


目录
相关文章
|
18天前
|
存储 人工智能 定位技术
一些 Harness Engineering 的实践
Harness Engineering 是AI智能体时代的新型工程范式,核心是为Agent构建可靠环境而非优化模型。OpenAI、Anthropic、LangChain等实践表明:通过结构化知识库、双重智能体架构、组件化Harness设计及自动化反馈回路,可提升Agent在长周期、大规模任务中的稳定性与自主性。
3867 4
|
19天前
|
存储 人工智能 机器人
你养的龙虾,怎么才能越用越聪明?
通过三本说明书立人设、建记忆系统告别金鱼脑、开启“心跳”主动服务、积累技能复利、接入生态学本领、组建多智能体团队——龙虾的能力上限,就是你想象力的边界。
421 2
|
1月前
|
存储 人工智能 Linux
保姆级图文流程!OpenClaw(Clawdbot)阿里云/本地部署配置百炼 API +self-improving-agent skill 与避坑南
在AI工具普及的2026年,OpenClaw(原Clawdbot)凭借开源灵活、功能可扩展的特性,成为个人与轻量团队的核心AI助手。但多数用户在使用中会遇到共性问题:AI无法记住使用偏好、重复犯相同错误、难以积累实操经验,导致效率提升有限。而self-improving-agent技能的出现,彻底解决了这一痛点——它为OpenClaw赋予“记忆”与“学习能力”,通过自动记录用户纠正、错误案例、最佳实践,实现持续自我进化,让AI助手越用越贴合需求。
1661 0
|
3月前
|
人工智能 前端开发 Java
关于Agent框架,豆包,DeepSeek、Manus都选择了它
2025年被视为Agent元年,通过向Manus、豆包、DeepSeek提问“编程框架第一性原理”,发现三者不约而同推荐阿里巴巴开源的AgentScope。
629 2
关于Agent框架,豆包,DeepSeek、Manus都选择了它
|
Shell iOS开发 MacOS
|
2月前
|
人工智能 运维 供应链
对待 Skills,请理性祛魅
本文深度解析Anthropic推出的Agent Skills技术:剖析其“渐进式披露”原理、模块化设计及在降本、可维护性、跨模型迁移等方面的显著优势;同时警示26.1%高漏洞率带来的安全风险,呼吁开发者理性祛魅、平台筑牢安全护栏。
563 2
|
1月前
|
运维 JavaScript BI
SaaS ERP系统源代码,完美运行的项目源码
这是一款基于SpringBoot+Vue的SaaS ERP源码系统,覆盖采购、销售、生产、财务等全业务模块,支持自定义流程、报表与表单,具备软件著作权,可商用及二次开发,专为中小企业提供灵活、易用、云端化的企业管理解决方案。
107 2
|
19天前
|
JSON IDE API
从源码看 Qwen Code 的设计思路
Qwen Code 是基于AI Agent的智能编程助手,采用模块化分层架构。其核心为可循环执行的Agent对话机制,协调用户输入、大模型推理与工具调用,支持Plan/Default/Auto-edit/YOLO四种执行模式,并集成子智能体、MCP协议及会话管理等服务。本文将从源码角度来解析其设计思路。
262 7
|
2月前
|
人工智能 前端开发 安全
一文讲解与Agent前端发展相关的几个阶段和协议
本文梳理了Agent前端协议从“胶水代码”到标准化的演进历程。解析了MCP、MCPApps、A2A、AG-UI及A2UI在能力、协作、通信与呈现架构中的核心作用。通过深度集成,前端正实现AI能力的富交互呈现,推动人机交互走向“可见、可控、可信”。
402 4