TL;DR

这篇来自 Anthropic 的文章，系统性地阐述了其 Multi-Agent 研究系统的构建历程，为构建高级 AI Agent 提供了清晰的路线图。其核心内容可归纳为三点：

1. 为何选择多智能体： 明确了其在处理开放式、动态研究任务上的优越性。通过并行化与任务分解（Orchestrator-Worker 模式），系统能投入更多有效算力（Tokens），在广度搜索等任务上性能远超单个顶级模型。
2. 如何构建与评估： 分享了极具参考价值的工程方法论。这不仅包括架构设计，更深入到以启发式和协作为导向的 Prompt 工程、以清晰高效为目标的 Tool 设计，以及一套应对非确定性的高级评估范式（如小样本快迭代、LLM-as-judge、人工评估互补）。
3. 生产中的现实挑战： 揭示了从原型到可靠生产系统的巨大鸿沟。文章坦诚地讨论了高昂的 Token 消耗、有状态系统带来的错误累积、非确定性调试的困难，以及复杂的部署策略等现实问题。

如上，本文不仅是一份技术分享，更是一份宝贵的工程实践蓝图，对任何致力于将 Agentic AI 产品化的团队都具有重要的指导意义。

---

我们的 Research 功能使用多个 Claude agent 来更有效地探索复杂主题。我们分享了构建此系统时遇到的工程挑战和学到的经验教训。

Claude 现在具备了 Research 功能，使其能够跨网络、Google Workspace 以及任何集成进行搜索，以完成复杂的任务。

这个 multi-agent 系统从原型到生产的历程，教给了我们在系统架构、tool 设计和 prompt 工程方面的关键经验。一个 multi-agent 系统由多个 agent（在循环中自主使用 tool 的 LLM）协同工作组成。我们的 Research 功能涉及一个 agent，它根据用户查询规划研究流程，然后使用 tools 创建并行的 agents 来同时搜索信息。多 agent 系统在 agent 协调、评估和可靠性方面引入了新的挑战。

本文将分解对我们有效的原则——我们希望您在构建自己的 multi-agent 系统时会发现它们很有用。

multi-agent 系统的好处

研究工作涉及开放式问题，在这种问题中，很难预先预测所需的步骤。您无法为探索复杂主题硬编码一个固定的路径，因为这个过程本质上是动态和路径依赖的（path-dependent）。当人们进行研究时，他们倾向于根据发现不断更新自己的方法，跟随调查过程中出现的线索。

这种不可预测性使得 AI agents 特别适合研究任务。研究要求在调查展开时具有灵活性，能够转向或探索切题的联系。模型必须自主运行多个回合，根据中间发现来决定追求哪个方向。线性的、一次性的流水线无法处理这些任务。

搜索的本质是压缩：从庞大的语料库中提炼见解。Subagents 通过在各自的 context window 中并行操作来促进压缩，它们同时探索问题的不同方面，然后将最重要的 tokens 浓缩给主导研究的 agent。每个 subagent 还提供了关注点分离（separation of concerns）——即拥有独特的 tools、prompts 和探索轨迹——这减少了路径依赖，并实现了彻底、独立的调查。

一旦智能达到一个阈值，multi-agent 系统就成为扩展性能的重要途径。例如，尽管在过去 10 万年里，单个人的智力变得更高，但人类社会在信息时代的能力却呈指数级增长，这得益于我们的集体智慧和协调能力。即使是通用智能的 agents，在作为个体运作时也会面临限制；agent 群体可以完成更多的工作。

我们的内部评估显示，multi-agent 研究系统尤其擅长处理广度优先（breadth-first）的查询，这些查询涉及同时探索多个独立的方向。我们发现，在一个内部研究评估中，以 Claude Opus 4 为主导 agent、以 Claude Sonnet 4 为 subagents 的 multi-agent 系统，其性能比单个 Claude Opus 4 agent 高出 90.2%。例如，当被要求找出信息技术标准普尔 500 指数中所有公司的董事会成员时，multi-agent 系统通过将任务分解给 subagents 找到了正确答案，而 single-agent 系统则因缓慢的顺序搜索而未能找到答案。

Multi-agent 系统之所以有效，主要是因为它们有助于投入足够的 tokens 来解决问题。在我们的分析中，三个因素解释了 BrowseComp 评估（该评估测试浏览 agent 定位难找信息的能力）中 95% 的性能差异。我们发现，token 使用量本身解释了 80% 的差异，而 tool calls 的数量和模型选择是另外两个解释性因素。这一发现验证了我们的架构，该架构将工作分配给具有独立 context window 的 agents，以增加并行推理的能力。最新的 Claude 模型在 token 使用上起到了巨大的效率倍增器作用，因为升级到 Claude Sonnet 4 带来的性能提升比在 Claude Sonnet 3.7 上将 token 预算翻倍还要大。Multi-agent 架构有效地扩展了 token 的使用，以应对超出单个 agent 限制的任务。

但有一个缺点：在实践中，这些架构会快速消耗 tokens。在我们的数据中，agents 通常比聊天交互多使用约 4 倍的 tokens，而 multi-agent 系统比聊天多使用约 15 倍的 tokens。为了在经济上可行，multi-agent 系统要求任务的价值足够高，以支付其带来的性能提升。此外，一些需要所有 agents 共享相同上下文或 agents 之间存在许多依赖关系的领域，目前并不适合 multi-agent 系统。例如，大多数编码任务涉及的真正可并行的任务比研究要少，而且 LLM agents 在实时协调和委派任务给其他 agents 方面还不够出色。我们发现，multi-agent 系统在那些涉及大量并行化、信息量超出单个 context window、以及与众多复杂 tools 交互的高价值任务上表现出色。

Research 功能的架构概述

我们的 Research 系统采用了一种带有 orchestrator-worker 模式的 multi-agent 架构，其中一个主导Agent(Lead Agent) 协调整个流程，同时将任务委派给并行的、专门的 subagents。

multi-agent 架构的实际运作：用户查询流经一个 lead agent，该 agent 创建专门的 subagents 以并行搜索不同方面。

当用户提交查询时，主导 agent 会分析查询，制定策略，并生成 subagents 以同时探索不同方面。如上图所示，subagents 充当智能过滤器，通过迭代使用搜索 tools 收集信息（此例中是关于 2025 年的 AI agent 公司），然后将公司列表返回给主导 agent，以便其汇编最终答案。

使用 Retrieval Augmented Generation (RAG) 的传统方法采用静态检索。也就是说，它们获取与输入查询最相似的一组文本块，并用这些文本块生成响应。相比之下，我们的架构使用多步搜索，动态地查找相关信息，适应新的发现，并分析结果以形成高质量的答案。

流程图展示了我们 multi-agent Research 系统的完整工作流。当用户提交查询时，系统会创建一个 LeadResearcher agent，进入一个迭代的研究过程。LeadResearcher 首先思考方法并将其计划保存到内存（Memory）中以持久化上下文，因为如果上下文窗口超过 200,000 tokens，它将被截断，保留计划至关重要。然后，它会为特定的研究任务创建专门的 Subagents（这里显示了两个，但可以是任意数量）。每个 Subagent 独立执行网页搜索，使用 interleaved thinking 评估 tool 结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并决定是否需要更多研究——如果需要，它可以创建额外的 subagents 或优化其策略。一旦收集到足够的信息，系统就会退出研究循环，并将所有发现传递给一个 CitationAgent，该 agent 处理文档和研究报告，以确定引用的具体位置。这确保了所有声明都正确归属于其来源。最终，附带引用的研究结果将返回给用户。

研究型 agent 的 Prompt 工程与评估

multi-agent 系统与 single-agent 系统有关键区别，其中包括协调复杂性的迅速增长。早期的 agents 会犯一些错误，比如为简单查询生成 50 个 subagents，无休止地在网上搜索不存在的来源，以及因过多的更新而互相干扰。由于每个 agent 都由一个 prompt 指导，prompt 工程是我们改进这些行为的主要手段。以下是我们学到的一些关于 prompting agents 的原则：

1. 像你的 agent 一样思考。要迭代 prompts，你必须理解它们的效果。为了帮助我们做到这一点，我们使用我们的 Console，利用系统中的确切 prompts 和 tools 建立了模拟，然后一步步观察 agents 的工作。这立即揭示了失败模式：agents 在已经有足够结果时仍继续工作，使用过于冗长的搜索查询，或选择不正确的 tools。有效的 prompting 依赖于建立一个准确的 agent 心智模型，这能让最有影响力的改变变得显而易见。
2. 教会 orchestrator 如何委派任务。在我们的系统中，主导 agent 将查询分解为子任务，并向 subagents 描述这些任务。每个 subagent 需要一个目标、一个输出格式、关于使用哪些 tools 和来源的指导，以及明确的任务边界。没有详细的任务描述，agents 会重复工作、留下空白，或找不到必要的信息。我们开始时允许主导 agent 给出简单的、短小的指令，如“研究半导体短缺”，但发现这些指令常常模糊不清，导致 subagents 误解任务或执行与其他 agents 完全相同的搜索。例如，一个 subagent 探索了 2021 年的汽车芯片危机，而另外两个则重复工作，调查当前的 2025 年供应链，没有有效的劳动分工。
3. 根据查询复杂度调整投入。Agents 很难判断不同任务的适当投入量，所以我们在 prompts 中嵌入了扩展规则。简单的事实查找只需要 1 个 agent 进行 3-10 次 tool calls，直接比较可能需要 2-4 个 subagents，每个进行 10-15 次 calls，而复杂的研究可能会使用超过 10 个 subagents，并明确划分责任。这些明确的指导方针帮助主导 agent 有效地分配资源，并防止在简单查询上过度投入，这是我们早期版本中常见的失败模式。
4. Tool 设计和选择至关重要。 Agent-tool 接口与人机界面同样关键。使用正确的 tool 效率高——通常，这是绝对必要的。例如，一个在网上搜索只存在于 Slack 中的上下文的 agent 从一开始就注定要失败。在使用 MCP 服务器让模型访问外部 tools 时，这个问题会更加复杂，因为 agents 会遇到描述质量参差不齐的未知 tools。我们为 agents 提供了明确的启发式规则：例如，首先检查所有可用的 tools，将 tool 的使用与用户意图匹配，为广泛的外部探索搜索网络，或优先选择专门的 tools 而不是通用的。糟糕的 tool 描述会把 agents 引向完全错误的道路，所以每个 tool 都需要一个明确的目的和清晰的描述。
5. 让 agent 自我改进。我们发现 Claude 4 模型可以是出色的 prompt 工程师。当给定一个 prompt 和一个失败模式时，它们能够诊断出 agent 失败的原因并提出改进建议。我们甚至创建了一个 tool 测试 agent——当给定一个有缺陷的 MCP tool 时，它会尝试使用该 tool，然后重写 tool 描述以避免失败。通过数十次测试该 tool，这个 agent 发现了关键的细微差别和 bug。这个改进 tool 人体工程学的过程，使得未来使用新描述的 agents 的任务完成时间减少了 40%，因为它们能够避免大多数错误。
6. 先从广泛开始，再逐步收窄。搜索策略应该模仿专家的人类研究：在深入具体细节之前先探索整体情况。Agents 常常默认使用过长、过于具体的查询，导致返回结果很少。我们通过 prompting agents 从简短、宽泛的查询开始，评估可用信息，然后逐步收窄焦点来纠正这种倾向。
7. 引导思考过程。extended thinking 模式会引导 Claude 在一个可见的思考过程中输出额外的 tokens，可以作为一个可控的草稿纸。主导 agent 使用思考来规划其方法，评估哪些 tools 适合任务，确定查询复杂度和 subagent 数量，并定义每个 subagent 的角色。我们的测试表明，extended thinking 提高了指令遵循、推理和效率。Subagents 也会进行规划，然后在 tool 结果出来后使用 interleaved thinking 来评估质量、识别差距并优化它们的下一个查询。这使得 subagents 在适应任何任务时都更加有效。
8. 并行 tool 调用改变速度和性能。复杂的研究任务自然涉及探索许多来源。我们早期的 agents 执行顺序搜索，速度慢得令人痛苦。为了提速，我们引入了两种并行化：（1）主导 agent 并行启动 3-5 个 subagents，而不是串行启动；（2）subagents 并行使用 3 个以上的 tools。这些改变使复杂查询的研究时间缩短了高达 90%，让 Research 功能能在几分钟内完成更多工作，而不是几小时，同时覆盖比其他系统更多的信息。

我们的 prompting 策略专注于灌输良好的启发式规则，而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的 prompts 中——例如将困难问题分解为更小的任务，仔细评估来源质量，根据新信息调整搜索方法，以及识别何时应专注于深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外的副作用，以防止 agents 失控。最后，我们专注于一个具有可观察性和测试用例的快速迭代循环。

agent 的有效评估

好的评估对于构建可靠的 AI 应用至关重要，agent 也不例外。然而，评估 multi-agent 系统带来了独特的挑战。传统评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 产生输出 Z。但 multi-agent 系统并非如此运作。即使起点完全相同，agents 也可能采取完全不同的有效路径来达到目标。一个 agent 可能搜索三个来源，而另一个可能搜索十个，或者它们可能使用不同的 tools 来找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常不能仅仅检查 agents 是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评估方法，既能判断 agents 是否达到了正确的结果，又能判断它们是否遵循了合理的过程。

立即用小样本开始评估。在 agent 开发的早期，改变往往会产生巨大的影响，因为有大量唾手可得的改进空间。一个 prompt 的微调可能会将成功率从 30% 提高到 80%。在效应如此之大的情况下，你只需几个测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询集开始。测试这些查询常常能让我们清楚地看到变化的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好是立即用几个例子开始小规模测试，而不是等到你能建立更全面的评估时再动手。

LLM-as-judge评估如果做得好，可以很好地扩展。研究的输出很难以编程方式评估，因为它们是自由格式的文本，并且很少有单一的正确答案。LLMs 很自然地适合评分输出。我们使用了一个 LLM 评委，它根据一个评分标准来评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有被要求的方面？）、来源质量（是否使用了主要来源而非质量较低的次要来源？），以及 tool 效率（是否以合理的次数使用了正确的 tools？）。我们尝试了多个评委来评估每个部分，但发现单个 LLM 调用、单个 prompt、输出 0.0-1.0 的分数和一个通过/失败的等级，这种方式最一致，且与人类判断最吻合。当评估的测试用例确实有明确答案时，这种方法尤其有效，我们可以用 LLM 评委简单地检查答案是否正确（例如，它是否准确列出了研发预算前三的制药公司？）。使用 LLM 作为评委使我们能够可扩展地评估数百个输出。

人工评估能发现自动化遗漏的问题。测试 agent 的人能发现评估遗漏的边缘案例。这些包括在不寻常查询上的幻觉答案、系统故障或微妙的来源选择偏见。在我们的案例中，人工测试员注意到，我们早期的 agents 总是选择经过 SEO 优化的内容农场，而不是像学术 PDF 或个人博客这样权威但排名较低的来源。在我们的 prompts 中加入来源质量的启发式规则帮助解决了这个问题。即使在自动化评估的世界里，手动测试仍然至关重要。

Multi-agent 系统具有涌现行为，这些行为是在没有特定编程的情况下产生的。例如，对主导 agent 的微小改变可能会不可预测地改变 subagents 的行为。成功需要理解交互模式，而不仅仅是单个 agent 的行为。因此，这些 agents 的最佳 prompts 不仅仅是严格的指令，而是定义了劳动分工、解决问题的方法和投入预算的协作框架。要做到这一点，依赖于仔细的 prompting 和 tool 设计、可靠的启发式规则、可观察性以及紧密的反馈循环。可以参阅我们 Cookbook 中的开源 prompts[1] 来查看我们系统中的示例 prompts。

生产环境的可靠性与工程挑战

在传统软件中，一个 bug 可能会破坏一个功能、降低性能或导致服务中断。在 agentic 系统中，微小的变化会级联成巨大的行为变化，这使得为必须在长期运行的进程中保持状态的复杂 agents 编写代码变得异常困难。

Agent 是有状态的（stateful），错误会累积。Agents 可以长时间运行，在多次 tool calls 之间保持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。没有有效的缓解措施，微小的系统故障对 agents 来说可能是灾难性的。当错误发生时，我们不能简单地从头开始：重新启动对用户来说既昂贵又令人沮丧。相反，我们构建了可以从 agent 发生错误的地方恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让 agent 知道某个 tool 正在失灵并让它自行适应，效果出奇地好。我们将基于 Claude 构建的 AI agents 的适应性与重试逻辑和定期检查点等确定性保障措施相结合。

调试受益于新方法。Agents 做出动态决策，并且即使使用相同的 prompts，每次运行之间也是不确定的。这使得调试更加困难。例如，用户会报告 agents “找不到明显的信息”，但我们看不出原因。是 agents 使用了糟糕的搜索查询？选择了差的来源？还是遇到了 tool 故障？增加全链路的生产环境追踪让我们能够诊断 agents 失败的原因并系统地修复问题。除了标准的可观察性，我们还监控 agent 的决策模式和交互结构——所有这些都在不监控单个对话内容的情况下进行，以维护用户隐私。这种高层次的可观察性帮助我们诊断根本原因，发现意外行为，并修复常见故障。

部署需要谨慎协调。Agent 系统是由 prompts、tools 和执行逻辑构成的高度有状态的网络，几乎是连续运行的。这意味着每当我们部署更新时，agents 可能处于其流程的任何位置。因此，我们需要防止我们善意的代码更改破坏现有的 agents。我们不能同时将所有 agents 更新到新版本。相反，我们使用 rainbow deployments[2] 来避免中断正在运行的 agents，通过逐步将流量从旧版本转移到新版本，同时保持两者同时运行。

同步执行（Synchronous execution）会造成瓶颈。目前，我们的主导 agents 同步执行 subagents，等待每组 subagents 完成后才继续。这简化了协调，但在 agents 之间的信息流中造成了瓶颈。例如，主导 agent 无法引导 subagents，subagents 无法相互协调，整个系统可能会因为等待单个 subagent 完成搜索而被阻塞。异步执行（Asynchronous execution）将实现额外的并行性：agents 同时工作，并在需要时创建新的 subagents。但这种异步性在结果协调、状态一致性和跨 subagents 的错误传播方面增加了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能的提升将证明这种复杂性是值得的。

结论

在构建 AI agent 时，最后一英里往往占据了旅程的大部分。在开发人员机器上能工作的代码库，需要大量的工程工作才能成为可靠的生产系统。agentic 系统中错误的复合性质意味着，对于传统软件来说的小问题可能会让 agents 完全脱轨。一个步骤的失败可能导致 agents 探索完全不同的轨迹，从而导致不可预测的结果。出于本文所述的所有原因，原型与生产之间的差距往往比预期的要大。

尽管存在这些挑战，multi-agent 系统已被证明在开放式研究任务中非常有价值。用户表示，Claude 帮助他们找到了他们未曾考虑过的商业机会，驾驭了复杂的医疗保健选项，解决了棘手的技术 bug，并通过揭示他们自己找不到的研究联系，节省了长达数天的工作时间。通过精心的工程设计、全面的测试、注重细节的 prompt 和 tool 设计、稳健的运营实践，以及对当前 agent 能力有深刻理解的研究、产品和工程团队之间的紧密协作，multi-agent 研究系统可以在生产规模上可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。

一个 Clio embedding plot 展示了当今人们使用 Research 功能最常见的方式。最主要的使用案例类别是：开发跨专业领域的软件系统 (10%)，开发和优化专业及技术内容 (8%)，制定业务增长和收入生成策略 (8%)，协助学术研究和教育材料开发 (7%)，以及研究和核实有关人物、地点或组织的信息 (5%)。

如何学习大模型 AI ？

我国在AI大模型领域面临人才短缺，数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着Al技术飞速发展，预计到2025年，这一缺口将急剧扩大至400万，严重制约我国Al产业的创新步伐。加强人才培养，优化教育体系，国际合作并进，是破解困局、推动AI发展的关键。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

2025最新大模型学习路线

明确的学习路线至关重要。它能指引新人起点、规划学习顺序、明确核心知识点。大模型领域涉及的知识点非常广泛，没有明确的学习路线可能会导致新人感到迷茫，不知道应该专注于哪些内容。

对于从来没有接触过AI大模型的同学，我帮大家准备了从零基础到精通学习成长路线图以及学习规划。可以说是最科学最系统的学习路线。

针对以上大模型的学习路线我们也整理了对应的学习视频教程，和配套的学习资料。

大模型经典PDF书籍

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路！

配套大模型项目实战

所有视频教程所涉及的实战项目和项目源码等

博主介绍＋AI项目案例集锦

MoPaaS专注于Al技术能力建设与应用场景开发，与智学优课联合孵化，培养适合未来发展需求的技术性人才和应用型领袖。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

为什么要学习大模型？

2025人工智能大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 ， 大模型作为其中的重要组成部分 ， 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力， 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ，为各行各业带来了革命性的改变和机遇 。

适合人群

• 在校学生：包括专科、本科、硕士和博士研究生。学生应具备扎实的编程基础和一定的数学基础，有志于深入AGI大模型行业，希望开展相关的研究和开发工作。
• IT行业从业人员：包括在职或失业者，涵盖开发、测试、运维、产品经理等职务。拥有一定的IT从业经验，至少1年以上的编程工作经验，对大模型技术感兴趣或有业务需求，希望通过课程提升自身在IT领域的竞争力。
• IT管理及技术研究领域人员：包括技术经理、技术负责人、CTO、架构师、研究员等角色。这些人员需要跟随技术发展趋势，主导技术创新，推动大模型技术在企业业务中的应用与改造。
• 传统AI从业人员：包括算法工程师、机器视觉工程师、深度学习工程师等。这些AI技术人才原先从事机器视觉、自然语言处理、推荐系统等领域工作，现需要快速补充大模型技术能力，获得大模型训练微调的实操技能，以适应新的技术发展趋势。
  

课程精彩瞬间

大模型核心原理与Prompt：掌握大语言模型的核心知识，了解行业应用与趋势；熟练Python编程，提升提示工程技能，为Al应用开发打下坚实基础。

RAG应用开发工程：掌握RAG应用开发全流程，理解前沿技术，提升商业化分析与优化能力，通过实战项目加深理解与应用。

Agent应用架构进阶实践：掌握大模型Agent技术的核心原理与实践应用，能够独立完成Agent系统的设计与开发，提升多智能体协同与复杂任务处理的能力，为AI产品的创新与优化提供有力支持。

模型微调与私有化大模型：掌握大模型微调与私有化部署技能，提升模型优化与部署能力，为大模型项目落地打下坚实基础。

顶尖师资，深耕AI大模型前沿技术

实战专家亲授，让你少走弯路

一对一学习规划，职业生涯指导

• 真实商业项目实训
• 大厂绿色直通车

人才库优秀学员参与真实商业项目实训

以商业交付标准作为学习标准，具备真实大模型项目实践操作经验可写入简历，支持项目背调

大厂绿色直通车，冲击行业高薪岗位

文中涉及到的完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】