这篇论文来自 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 在三个基准上的平均 pass@1 达到 71.62%，比最强 baseline 高出 16.28% 的相对提升。

从技术审美上看，四元组抽象的设计思路清晰且工程友好，"编排与执行解耦"的哲学也符合软件工程中关注点分离的原则。如果你关注 Agent 系统的架构设计，或者想了解如何在不写死角色的前提下实现灵活的多智能体协作，这篇文章值得细读。

● ● ●

1. 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，而是可以从经验中学习的。

论文展示了两种学习方式：

1. 监督微调（SFT）：用专家编排轨迹来微调编排器，提升子任务分解和四元组合成的质量。在 GAIA 上带来了 +11.51% 的 pass@1 提升。

2. 迭代式 In-context Learning：通过反复交互来优化编排器的 prompt，实现性价比感知的模型路由——在 GAIA 上提升了 +3.03% 的 pass@1，同时降低了 18.5% 的平均成本。

主要贡献总结

论文的贡献可以概括为三点：

● 提出了一个以编排器为中心的 Agentic 系统 AOrchestra，通过统一的四元组接口实现子智能体的按需动态创建

● 在三个高难度基准上取得了强劲的 training-free 性能，搭配 Gemini-3-Flash 时平均 pass@1 相对最强 baseline 提升 16.28%

● 证明了编排策略是可学习的：SFT 提升基础编排能力，In-context Learning 实现性价比 Pareto 优化

● ● ●

2. 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）**的统一抽象，让子智能体的创建过程完全自动化、完全动态化。

● ● ●

3. 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 工具 接收四元组 作为参数，据此实例化一个执行器：

● 用模型 运行

● 工具集限制为

● 仅基于 来做决策

执行器完成后，返回一个结构化的观测 ，通常包括：

1. 简洁的结果摘要

2. 相关产出物（文件、引用等）

3. 错误信息或日志（如果执行失败）

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-5

SFT 的关键结论： 即使只是简单的 SFT，也能把 Qwen3-8B 作为编排器的 GAIA 准确率从 56.97% 提升到 68.48%，提升幅度达 +11.51%。分析执行轨迹发现，微调后的模型在处理复杂任务时展现出更强的长链路问题解决能力，总尝试次数比基础模型增加了 56%。这说明"编排"本身是一个可以被高效学习的技能。

为什么用 SFT 而不是 RL？ 作者明确表示，本文优先展示训练专职编排器的潜力，因此采用了最直接的 SFT 方案。其他训练方法（如 GRPO）完全可以替代 SFT 来进一步提升编排能力。换句话说，SFT 是一个下界——用更先进的训练方法，编排质量还有提升空间。

维度二：In-context Learning 优化性价比编排

目标： 不改变模型权重，通过优化编排器的 prompt 来实现成本感知的模型路由。

方法： 把编排器的指令 作为可学习对象，通过迭代交互来优化：

其中 是优化轮次。

具体流程：

1. 用当前 prompt 运行 AOrchestra，收集交互轨迹 及性能和成本指标

2. 一个优化模型（Claude Sonnet 4）分析这些轨迹，找出编排策略中的低效之处

3. 生成改进后的 prompt

4. 反复迭代，直到性价比收敛

这个过程实质上是在做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 的关键结论： 通过迭代优化 prompt，AOrchestra 在 GAIA 上实现了 +3.03% 的 pass@1 提升，同时降低了 18.5% 的平均成本。这说明编排器可以学会"该用便宜模型的时候用便宜模型，该用贵模型的时候才用贵模型"——一种精细化的模型路由能力。

SFT 和 ICL 的互补关系： 这两种学习方式针对的是不同的维度。SFT 改善的是编排质量——更好地分解任务、组合四元组；ICL 改善的是编排效率——用更少的成本达到更好的效果。前者需要训练，后者不需要，两者可以叠加使用

● ● ●

4. 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）

● 固定角色 MAS：OWL、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 编排器的整体表现：

● GAIA：pass@1 达到 80.00%（Level 1: 89.25%，Level 2: 76.22%，Level 3: 66.67%）

● SWE-Bench-Verified：pass@1 达到 54.40%

● Terminal-Bench 2.0：pass@1 达到 80.47%

● 三个基准的平均：71.62%

核心结论： 相比最强的 baseline，AOrchestra 在三个基准上的平均 pass@1 实现了 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 通过将复杂任务分解为多个短链路子任务，每个子智能体都在干净的上下文中工作，有效规避了这个问题。

● ● ●

5. Conclusion 结论与展望
   ===================

一个好的系统设计，不仅要解决当下的问题，还要为未来留下足够的扩展空间。

论文的核心贡献

AOrchestra 提出了一个以编排器为中心的 Agentic 框架，其核心创新在于三点：

第一，统一的四元组抽象。 把任意 Agent 建模为 ，让子智能体的创建过程从"人工预设"变成了"动态生成"。这个抽象既简洁又通用，四个维度覆盖了 Agent 的全部关键属性。

第二，编排与执行的彻底解耦。 编排器只做分解、创建、委派，绝不直接执行环境操作。这种严格的关注点分离让系统的每个部分都可以独立演进——编排器可以学习更好的策略，子智能体可以替换为更强的执行器。

第三，可学习的编排策略。 通过 SFT 和 ICL 两条互补的学习路径，证明了编排能力本身是一个可以被高效学习的技能。SFT 提升编排质量，ICL 优化性价比，两者可以叠加使用。

实验验证的关键数据

在三个高难度基准上的表现：

基准测试	AOrchestra pass@1	关键亮点
GAIA	80.00%	Level 3 困难任务也达到 66.67%
SWE-Bench-Verified	54.40%	真实 GitHub 代码修复
Terminal-Bench 2.0	80.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%免费】