论文精读｜AOrchestra：让编排器自动「按需创建」专属子智能体的 Agentic 框架

这篇论文来自HKUST(GZ)香港科技大学广州和DeepWisdom联合 RUC、ECNU、UdeM Mila 等多所院校发表于 2026 年 2 月的 arXiv 预印本。论文题为“AOrchestra: Automating Sub-Agent Creation for Agentic Orchestration”聚焦于一个非常实际的问题当 Agent 面对复杂的长链路任务时如何自动化地创建和管理子智能体在多智能体系统Multi-Agent Systems大行其道的今天大多数方案要么让子智能体只做上下文隔离的线程要么把它们写死成固定角色比如 Coder、Searcher。前者缺乏专业化能力后者又太僵硬、覆盖不了动态变化的子任务。AOrchestra 提出了一个简洁而优雅的思路把任意 Agent 抽象为一个四元组 (Instruction, Context, Tools, Model)然后由一个专职的编排器Orchestrator在运行时动态实例化子智能体。编排器自己不干活只负责拆解任务、组装四元组、委派执行。这个设计带来了三个直接的好处● 每个子智能体都能拿到量身定制的上下文和工具集而不是全盘接收或啥也没有● 子智能体的实现是即插即用的可以是 ReAct、Mini-SWE、Claude Code 等任意框架● 编排策略本身是可学习的既可以通过 SFT 提升编排质量也可以通过 In-context Learning 优化性价比实验覆盖了三个高难度的 Agent 基准测试GAIA数字世界通用任务、SWE-Bench-Verified真实 GitHub 代码修复和Terminal-Bench 2.0终端环境操作。搭配 Gemini-3-Flash 时AOrchestra 在三个基准上的平均 pass1 达到71.62%比最强 baseline 高出16.28%的相对提升。从技术审美上看四元组抽象的设计思路清晰且工程友好编排与执行解耦的哲学也符合软件工程中关注点分离的原则。如果你关注 Agent 系统的架构设计或者想了解如何在不写死角色的前提下实现灵活的多智能体协作这篇文章值得细读。● ● ●Introduction 从「人类协作」到「按需创建子智能体」人类处理复杂工作靠的是分工协作。当 Agent 也被推向同样复杂的多轮任务时一个精心设计的 Agentic 系统就成了突破单模型上限的关键路径。背景Agent 正在被推向更复杂的任务语言智能体Language Agent在任务自动化方面展现了巨大潜力。但随着任务变得越来越复杂、链路越来越长单个模型的能力天花板逐渐显现。于是一种自然的思路浮出水面让多个智能体协作完成任务就像人类团队的分工合作一样。现有方案的两种典型模式为了应对这种需求社区发展出了两条主要路线第一条路线固定工作流的多智能体系统MAS。比如 MetaGPT 把 Agent 组织成产品经理、架构师等固定角色通过预定义的通信协议协作。OWL 则采用 planner-worker 工作流将领域无关的规划和领域特定的执行模块化。但这类系统有个根本问题——工作流是写死的。面对开放环境中动态变化的子任务固定流程很难灵活应对。第二条路线子智能体即工具Sub-Agent-as-Tools。这条路线更实用主智能体编排器通过显式的工具调用tool call把子任务委派给子智能体。但目前的实现又退化成了两种有限模式模式 (a)子智能体 上下文隔离线程。比如 THREAD、Context-Folding 这类系统把子智能体主要当作隔离上下文的手段目的是防止上下文腐烂Context Rot——随着对话越来越长模型的表现会显著下降。但问题是这些子智能体没有专业化能力只是主智能体的分身而已。模式 (b)子智能体 固定角色。比如 Claude Code、Chain-of-Agents 这类系统预定义了一组固定的子智能体角色Coder、Searcher、Writer、Reviewer 等。它们有专业化能力但覆盖不了开放环境中层出不穷的新型子任务而且需要大量人工设计。什么是 Context Rot当输入 Token 数不断增加时LLM 的性能会逐渐退化——就好像模型的注意力被稀释了。这个现象被称为 Context Rot上下文腐烂是长链路任务中一个非常现实的挑战。THREAD 和 Context-Folding 通过开辟独立的子线程来缓解这个问题但代价是子智能体失去了专业化定制的机会。AOrchestra 的核心洞察面对这两种模式的局限AOrchestra 提出了第三条路核心洞察Core Insight子智能体应该被视为一个灵活的抽象单元而非预定义的固定角色。系统应该能在运行时根据具体的子任务需求动态组合子智能体的能力——这才是真正的按需特化On-demand Specialization。具体怎么做作者把任意 Agent 建模为一个统一的四元组这四个维度沿着两条互补的轴线组织●工作记忆Working Memory指令 上下文——Agent 需要做什么、依据什么信息●执行能力Capabilities工具集 模型——Agent 能做什么、用什么模型来做这个四元组就像一张能力配方编排器只要填好这四个字段就能即时生成一个专门针对当前子任务的子智能体。编排器只管调度不干活基于这个抽象AOrchestra 引入了一个专职编排器Orchestrator。编排器的职责非常明确● 把整体目标分解为下一个子任务●创建一个定制化的子智能体填写四元组● 通过显式工具调用委派执行关键设计编排器自己绝不执行任何环境操作。它只做编排——分解、创建、委派。这种编排与执行的彻底解耦带来了三个好处(1) 每个子智能体都能获得干净的定制化上下文提高执行准确率(2) 编排器对子智能体的内部实现完全无感子智能体可以随意替换(3) 编排策略本身是可学习的。编排策略是可学习的AOrchestra 的一个重要亮点是编排策略不是写死的 prompt而是可以从经验中学习的。论文展示了两种学习方式监督微调SFT用专家编排轨迹来微调编排器提升子任务分解和四元组合成的质量。在 GAIA 上带来了11.51%的 pass1 提升。迭代式 In-context Learning通过反复交互来优化编排器的 prompt实现性价比感知的模型路由——在 GAIA 上提升了3.03%的 pass1同时降低了 18.5% 的平均成本。主要贡献总结论文的贡献可以概括为三点● 提出了一个以编排器为中心的 Agentic 系统AOrchestra通过统一的四元组接口实现子智能体的按需动态创建● 在三个高难度基准上取得了强劲的training-free 性能搭配 Gemini-3-Flash 时平均 pass1 相对最强 baseline 提升16.28%● 证明了编排策略是可学习的SFT 提升基础编排能力In-context Learning 实现性价比 Pareto 优化● ● ●Related Work 相关工作从固定工作流到动态按需创建子智能体的设计范式正在发生转变。2.1 Multi-Agent Systems 多智能体系统多智能体系统MAS是社区早期探索的方向。其核心思路是让多个 Agent 各司其职、协同工作。几个代表性工作●MetaGPT把 Agent 组织成软件开发团队产品经理、架构师等角色通过预定义的通信协议协作●OWL采用 planner-worker 工作流把领域无关的规划和领域特定的执行模块化●AutoAgents尝试为每个任务自动构建不同的多智能体系统但底层仍依赖固定工作流MAS 的根本局限在于工作流是固定的。尽管多智能体协作能改善任务分解但在开放环境中固定的协调模式往往带来巨大的协调开销coordination overhead而且对上下文路由context routing的控制有限——要么信息过度共享noisy over-sharing要么遗漏关键信息harmful omission。这些局限推动了社区向**子智能体即工具Sub-Agent-as-Tools**范式的转变。2.2 Sub-Agent as Tools 子智能体即工具这一范式的核心操作是由一个主 Agent编排器通过工具调用的方式来调度子智能体。几个代表性工作及其特点●THREAD支持递归生成子智能体来处理分解后的子问题但子智能体本质上只是主智能体的副本缺乏独立的专业化能力●Context-Folding为子任务开辟分支完成后将中间步骤压缩成摘要再折叠回来有效管理上下文长度但同样没有把子智能体当作完整的专业化 Agent来对待●Claude Code支持在隔离的上下文窗口中运行子智能体可以自定义 system prompt 和工具权限但这些子智能体通常是固定的预配置角色仍然需要人工设计为什么子智能体即工具比传统 MAS 更实用因为它把多智能体之间复杂的通信协议简化成了清晰的工具调用接口。主智能体不需要和子智能体对话只需要通过一次函数调用发起委派、接收返回结果。这大幅降低了协调开销也让上下文的传递更加可控。AOrchestra 沿着 Sub-Agent-as-Tools 这条路线继续前进但做了一个关键的升级把子智能体从静态实体变成了动态单元。编排器不再从一个固定的角色列表中选取子智能体而是在每一步都自动创建一个全新的、量身定制的子智能体——指令、上下文、工具、模型四个维度全部按需配置。AOrchestra 与现有工作的本质区别无论是 THREAD 的递归分支、Context-Folding 的上下文压缩还是 Claude Code 的隔离窗口它们都没有从动态抽象的视角来看待子智能体。AOrchestra 首次提出了一个**框架无关framework-agnostic**的统一抽象让子智能体的创建过程完全自动化、完全动态化。● ● ●Methodology 方法论本章是整篇论文的技术核心。作者先形式化定义了问题然后详细介绍 AOrchestra 的系统设计最后展示编排器如何通过学习来持续提升。Figure 3: Overall design of our proposed agentic framework, AOrchestra, for complex, long-horizon tasks. The orchestrator solves a user task by repeatedly delegating subtasks to on-the-fly instantiated sub-agents, each defined by a unified four-tuple (I,C,T,M)(I,C,T,M). The orchestrator is learnable and can improve its decomposition, context routing, and capability allocation from past experience.3.1 Problem Formulation 问题形式化在展开具体设计之前先把问题说清楚。任务交互的基本框架整个 Agentic 系统要解决的是给定一个用户目标**通过与环境的多步交互来完成任务。**环境暴露一个环境级动作空间包括 shell 命令、网页操作、代码编辑等执行后返回观测、工具输出或错误信息。一条任务的交互轨迹可以表示为其中 是第 步的系统状态包括累积的历史、中间结果和环境反馈 是采取的动作 是返回的观测。系统按照状态转移函数演化说白了就是每走一步系统都会把新获得的信息整合进内部状态。Sub-Agent-as-Tools 视角在这个范式下主智能体编排器可以选择●直接执行环境动作●委派一个子智能体来执行●终止交互编排器的动作空间是这三者的并集不同系统的区别主要在于 是怎么参数化的——是只传上下文还是委派给一个固定角色以及编排器自己是否也执行环境动作。优化目标系统的目标是最大化任务成功率同时可选地权衡执行成本其中 是编排器策略 可以包括 Token 消耗、工具调用次数、延迟或金钱成本 控制性价比的权衡。为什么要把 Cost 也纳入优化目标因为在实际部署中不同模型的价格差异巨大。比如 Claude-4.5-sonnet 的输入价格是 DeepSeek-V3.2 的 12 倍。如果一个简单的子任务也用最贵的模型那成本会急剧膨胀。AOrchestra 的模型路由设计正是为了解决这个问题——让简单任务用便宜模型复杂任务用强力模型。3.2 AOrchestra 系统设计统一的四元组 Agent 抽象AOrchestra 的核心抽象是无论是主智能体还是子智能体都可以用同一个四元组来描述。四个维度分别是● Instruction任务指令明确当前目标和成功标准● Context经过筛选的工作上下文Agent 据此来做决策● Tools工具集定义了 Agent 的动作空间● Model底层模型负责与环境交互四元组的两条轴线这四个维度并非杂乱无章而是沿两条清晰的轴线组织——工作记忆 (I, C)决定 Agent “知道什么、要做什么”执行能力 (T, M)决定 Agent “能做什么、用什么做”。这种分离让每个维度都可以独立配置实现精细化的能力组合。关键的设计理念是子智能体不是一个静态实体而是一个可以在运行时被参数化和创建的动态单元。主智能体编排器本身也可以表示为一个四元组 。区别在于编排器的工具集 暴露的是系统级工具, 而不是环境级工具。编排器的动作空间在 AOrchestra 的设计中编排器绝不直接执行环境动作。它的动作空间被严格限制为只有两个选择要么委派一个子智能体去干活要么结束交互返回最终答案。在第 步编排器从 中采样一个动作 ● 如果 系统根据四元组 实例化一个执行器 执行子任务并返回观测● 如果 交互终止输出最终答案返回的观测通过状态转移函数整合到下一步状态。为什么编排器不能直接执行环境动作这是一个刻意的设计选择。如果编排器也能直接操作环境那它的角色就变得模糊了——既是指挥官又是士兵。严格的解耦让编排器专注于高层决策而把底层执行完全交给子智能体。这不仅简化了编排器的学习任务也让子智能体的实现可以完全独立。Delegate 和 Finish 的实现在工程实现层面AOrchestra 给编排器提供了两个系统工具Delegate 工具接收四元组 作为参数据此实例化一个执行器● 用模型 运行● 工具集限制为● 仅基于 来做决策执行器完成后返回一个结构化的观测 通常包括简洁的结果摘要相关产出物文件、引用等错误信息或日志如果执行失败Finish 工具终止交互输出最终响应 。四元组各维度的配置策略编排器在创建子智能体时需要精心配置四个维度。配置 Context ©从完整的交互历史中筛选出与当前子任务最相关的细节。不是全盘复制也不是完全不给——而是做精准的信息过滤。这解决了 MAS 中常见的noisy over-sharing和harmful omission问题。配置 Instruction (I)为子任务制定清晰、自包含、可执行的成功标准。指令要足够具体让子智能体不需要额外信息就能理解任务。配置 Tools (T)从工具池中选择最小必要工具集。多余的工具只会分散子智能体的注意力。配置 Model (M)根据子任务的难度和特点匹配合适的模型。简单任务用便宜模型复杂任务用强力模型。AOrchestra 的三大优势(1) 动态定制——每个子智能体都获得量身定制的能力和干净的上下文显著提升执行准确率(2) 即插即用——编排器只操作四元组抽象不关心子智能体的内部实现ReAct、Mini-SWE、甚至 Claude Code 都可以作为执行后端(3) 可学习——编排策略可以通过训练或 prompt 优化来持续改进。3.3 Learnable Orchestrator 可学习的编排器有了 编排任务就可以表达为学习一个在结构化动作上的策略由于委派参数 是显式可用的学习可以聚焦在两个互补的维度维度一SFT 优化任务编排目标提升编排器做什么、给什么上下文、用什么工具的能力。方法给定专家编排轨迹 通过行为克隆Behavior Cloning来微调编排器其中 是专家动作 或 。实现细节● 基座模型选用Qwen3-8B非思考模式● 用TaskCraft作为种子数据集● 用Gemini-3-Flash收集 2K 条编排轨迹● 使用LLamaFactory框架进行全参数微调2 个 epoch学习率 1e-5SFT 的关键结论即使只是简单的 SFT也能把 Qwen3-8B 作为编排器的 GAIA 准确率从 56.97% 提升到 68.48%提升幅度达11.51%。分析执行轨迹发现微调后的模型在处理复杂任务时展现出更强的长链路问题解决能力总尝试次数比基础模型增加了 56%。这说明编排本身是一个可以被高效学习的技能。为什么用 SFT 而不是 RL作者明确表示本文优先展示训练专职编排器的潜力因此采用了最直接的 SFT 方案。其他训练方法如 GRPO完全可以替代 SFT 来进一步提升编排能力。换句话说SFT 是一个下界——用更先进的训练方法编排质量还有提升空间。维度二In-context Learning 优化性价比编排目标不改变模型权重通过优化编排器的 prompt 来实现成本感知的模型路由。方法把编排器的指令 作为可学习对象通过迭代交互来优化其中 是优化轮次。具体流程用当前 prompt 运行 AOrchestra收集交互轨迹 及性能和成本指标一个优化模型Claude Sonnet 4分析这些轨迹找出编排策略中的低效之处生成改进后的 prompt反复迭代直到性价比收敛这个过程实质上是在做Pareto 优化——在性能和成本之间找到最优的权衡点。Figure 4: Pareto front curve of GAIA. We plot GAIA accuracy and average cost per task (USD, log scale). Each point corresponds to a configuration, and the dashed curve indicates the Pareto frontier formed by AOrchestra across different model routing choices.ICL 的关键结论通过迭代优化 promptAOrchestra 在 GAIA 上实现了3.03%的 pass1 提升同时降低了 18.5% 的平均成本。这说明编排器可以学会该用便宜模型的时候用便宜模型该用贵模型的时候才用贵模型——一种精细化的模型路由能力。SFT 和 ICL 的互补关系这两种学习方式针对的是不同的维度。SFT 改善的是编排质量——更好地分解任务、组合四元组ICL 改善的是编排效率——用更少的成本达到更好的效果。前者需要训练后者不需要两者可以叠加使用● ● ●Experiments 实验验证好的设计需要经得起数据的检验。这一章通过三个高难度基准测试和多维度的消融分析全面检验 AOrchestra 的效果。4.1 Experimental Setup 实验设置三个基准测试论文选择了三个具有代表性的高难度基准覆盖了不同类型的复杂任务GAIA数字世界的通用任务基准测试 Agent 在开放环境中的综合问题解决能力。任务包括网页搜索、文件处理、多步推理等分为 Level 1、2、3 三个难度层次。SWE-Bench-Verified真实的 GitHub 代码修复任务。每个任务要求 Agent 阅读完整的代码库、定位问题、生成补丁。这是对代码理解和软件工程能力的硬核测试。Terminal-Bench 2.0终端环境下的操作任务。任务涉及文件系统操作、系统管理、环境配置等测试 Agent 在终端环境中的实际操作能力。为什么选这三个基准它们分别代表了三种典型的长链路任务场景开放域信息检索与推理GAIA、代码库级软件工程SWE-Bench、系统级终端操作Terminal-Bench。如果 AOrchestra 能在这三个差异巨大的场景中都表现良好那就说明其设计具有很强的通用性。实验配置编排器模型的选择● 主要使用Gemini-3-Flash作为编排器training-free 实验● 也测试了Claude Sonnet 4、GPT-4.1等编排器● SFT 实验中使用微调后的Qwen3-8B子智能体可选的模型池包括Gemini-3-Flash、Claude Sonnet 4、GPT-4.1、DeepSeek-V3.2、Qwen3-8B 等。Baseline 包括●单体 Agent直接用单个模型完成任务如 Claude Sonnet 4 ReAct●固定角色 MASOWL、MetaGPT 等●Sub-Agent 方案THREAD、Context-Folding 等4.2 Main Results 主实验结果Figure 1: Overall performance on three challenging agentic benchmarks (GAIA, Terminal-Bench-2, SWE-Bench-Verified) paired with Gemini-3-Flash when comparing AOrchestra against other popular agentic frameworks.全局表现AOrchestra 搭配 Gemini-3-Flash 编排器的整体表现●GAIApass1 达到80.00%Level 1: 89.25%Level 2: 76.22%Level 3: 66.67%●SWE-Bench-Verifiedpass1 达到54.40%●Terminal-Bench 2.0pass1 达到80.47%●三个基准的平均71.62%核心结论相比最强的 baselineAOrchestra 在三个基准上的平均 pass1 实现了16.28%的相对提升从 61.59% 到 71.62%。在 GAIA 上达到了 80.00%在 Terminal-Bench 2.0 上达到了 80.47%。这个提升幅度在 Agent 基准测试中是非常显著的。分难度层次分析在 GAIA 的三个难度层次上AOrchestra 都表现突出●Level 1简单任务89.25%——相对简单的任务几乎都能搞定●Level 2中等任务76.22%——需要多步推理和工具组合仍然保持较高准确率●Level 3困难任务66.67%——即使是最难的任务也有三分之二的成功率这说明 AOrchestra 的“按需特化”策略在复杂任务上的优势更加明显——任务越复杂动态子智能体创建的价值越大。与单体 Agent 的对比一个有意思的观察即使是最强的单体 Agent比如直接用 Claude Sonnet 4 做 ReAct在长链路任务上也会因为 Context Rot 而性能下降。AOrchestra 通过将复杂任务分解为多个短链路子任务每个子智能体都在干净的上下文中工作有效规避了这个问题。● ● ●Conclusion 结论与展望一个好的系统设计不仅要解决当下的问题还要为未来留下足够的扩展空间。论文的核心贡献AOrchestra 提出了一个以编排器为中心的 Agentic 框架其核心创新在于三点第一统一的四元组抽象。把任意 Agent 建模为 让子智能体的创建过程从人工预设变成了动态生成。这个抽象既简洁又通用四个维度覆盖了 Agent 的全部关键属性。第二编排与执行的彻底解耦。编排器只做分解、创建、委派绝不直接执行环境操作。这种严格的关注点分离让系统的每个部分都可以独立演进——编排器可以学习更好的策略子智能体可以替换为更强的执行器。第三可学习的编排策略。通过 SFT 和 ICL 两条互补的学习路径证明了编排能力本身是一个可以被高效学习的技能。SFT 提升编排质量ICL 优化性价比两者可以叠加使用。实验验证的关键数据在三个高难度基准上的表现基准测试AOrchestra pass1关键亮点GAIA80.00%Level 3 困难任务也达到 66.67%SWE-Bench-Verified54.40%真实 GitHub 代码修复Terminal-Bench 2.080.47%终端环境操作三基准平均71.62%相对最强 baseline 提升 16.28%局限性与未来方向作者也坦诚地指出了几个值得探索的方向更先进的训练方法。当前的 SFT 只是一个起点下界。使用 GRPO 等强化学习方法来训练编排器有可能进一步提升编排质量。编排器的学习空间远未被充分挖掘。更复杂的编排拓扑。当前的 AOrchestra 采用的是线性的编排-执行循环。未来可以探索更复杂的拓扑结构比如子智能体之间的并行执行、层级嵌套、甚至子智能体递归委派。跨任务的编排迁移。当前的 SFT 和 ICL 都是在特定基准上优化的。一个有趣的问题是在 GAIA 上学到的编排策略能否迁移到 SWE-Bench 上编排能力的通用性边界在哪里更精细的成本建模。当前的成本主要考虑 Token 消耗和模型价格。在实际生产环境中延迟、并发、API 限流等因素也需要纳入考量。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】