如果你用过 ChatGPT 或类似的 AI 工具，你的体验大概率是这样的：你问一个问题，AI 给你一个答案。看起来像是一个 AI 从头做到尾。

但在越来越多复杂任务和 Agent 产品中，背后可能已经不是“一个人干活”，而是一支分工明确的 AI 团队。

你只说一句“帮我开发一个登录功能”，系统可能让一个 Agent 分析需求，一个 Agent 编写前端，一个 Agent 处理后端，还有一个 Agent 负责测试和审查。它们各自完成一部分工作，再由系统把结果组合起来。

这就是多 Agent 协作。

问题也随之而来：这些 Agent 是怎么配合的？谁决定下一步做什么？任务和上下文怎么传递？做完以后，结果又怎么汇总？

这篇文章不堆术语，而是用最通俗的方式，讲清楚四种常见的多 Agent 协作机制。

01

先打破一个幻觉

在聊具体机制之前，需要先纠正一个很容易产生的误解。

你可能会脑补这样的画面：

Agent A 对 Agent B 说：“帮我检查一下这段代码。”

Agent B 回答：“好的，马上给你结果。”

看起来就像两个 AI 在微信群里聊天。

但真实的工程系统通常不是这样运行的。

Agent 可能是一次独立的大模型调用、一个工作流节点，也可能是一个部署在远端的 Agent 服务。它们通常不会像人一样自由聊天，而是在编排系统的控制下，传递结构化的任务、消息、状态、上下文和结果。

例如，主 Agent 判断需要代码审查后，系统可能会：

1. 创建一份明确的审查任务；
2. 选择代码审查 Agent；
3. 传入代码、审查范围和输出要求；
4. 等待子 Agent 完成；
5. 将结果写回主流程；
6. 再由主 Agent 决定下一步。

把子 Agent 包装成工具，由主 Agent 通过 Tool Calling 调用，是一种非常常见的实现方式，但它不是多 Agent 协作的唯一形式。后面还会看到共享状态、控制权移交、消息发布订阅，以及跨系统 Agent 协议等不同方案。

核心认知：多 Agent 协作通常不是 AI 彼此自由聊天，而是由编排系统组织任务分发、上下文传递、状态更新和结果回传。

02

为什么需要多 Agent？一个 Agent 不行吗？

先说结论：不是所有任务都需要多 Agent。

如果任务很简单，一个 Agent 能够稳定完成，就没有必要为了“看起来更先进”而拆成多个 Agent。多 Agent 会增加模型调用次数、响应延迟、运行成本和调试难度。

它真正有价值的地方，主要体现在下面几个方面。

隔离上下文

一个 Agent 同时负责调研、写作、编码、测试和审核，随着上下文越来越长，关键信息容易被大量历史内容稀释，处理成本也会不断增加。

把任务拆开后，每个 Agent 可以拥有相对干净的上下文：

• 研究员只关注资料和事实；
• 写作者只关注结构和表达；
• 审核员只关注错误和风险。

每个 Agent 不需要知道所有信息，只需要拿到完成自己任务所需的部分。

使用不同的能力和模型

不同任务需要的能力并不相同。

调研 Agent 可能需要联网检索，代码 Agent 需要读取仓库和运行命令，审核 Agent 需要更强的逻辑判断。系统还可以为不同任务选择不同模型，在质量、速度和成本之间做取舍。

控制工具和权限

多 Agent 还能形成更清晰的权限边界。

例如：

• 调研 Agent 只能搜索和读取资料；
• 代码审查 Agent 只能读代码，不能修改；
• 发布 Agent 才拥有部署权限。

相比把所有高风险工具都交给一个 Agent，这种拆分更容易控制风险。

并行处理可以拆分的任务

如果几个任务之间没有强依赖，就可以让多个 Agent 同时处理。

例如，让三个研究 Agent 分别调查市场、技术和竞品，最后再统一汇总。相比一个 Agent 依次完成，整体耗时可能更短。

因此，多 Agent 更适合以下任务：

• 可以清晰拆分成多个专业步骤；
• 需要隔离上下文或工具权限；
• 存在可并行执行的子任务；
• 需要不同模型或不同专业能力；
• 流程复杂，需要反复判断、回退或恢复。

03

核心：四种常见协作机制

下面介绍四种容易理解、也经常出现在实际系统中的协作方式：

1. Subagent as Tool：把子 Agent 当成工具调用；
2. Graph-State：通过共享状态和图路由推进流程；
3. Handoff：把当前对话和控制权移交给另一个 Agent；
4. Pub-Sub：通过消息发布和订阅驱动 Agent 工作。

需要注意：这不是行业唯一的标准分类，也不是互斥的四选一。

一个实际系统完全可以同时使用多种机制。例如，外层用 Graph-State 控制整体流程，其中一个节点通过 Tool Calling 调用多个子 Agent；某个客服节点又可以通过 Handoff 把用户转交给退款专家。

为了让四种方式更容易比较，后面每一节都会回答四个问题：

• 谁决定下一步？
• Agent 之间传递什么？
• 谁直接面向用户？
• 状态保存在哪里？

04

机制一：Subagent as Tool——把子 Agent 当成工具

这是最直观、也最常见的多 Agent 组织方式。

核心思想一句话：

主 Agent 保持控制权，把专业子 Agent 注册成可以调用的工具。

假设用户说：“帮我写一篇关于多 Agent 的文章。”

整个过程可能是这样的：

1. 用户把任务交给主 Agent；
2. 主 Agent 判断需要先做资料调研；
3. 主 Agent 调用 research\_agent，并传入具体调研任务；
4. 研究 Agent 在独立上下文中完成调研；
5. 调研结果作为工具结果返回主 Agent；
6. 主 Agent 再调用 writer\_agent 完成写作；
7. 主 Agent 检查并整合结果，最后回复用户。

这里的关键是：子 Agent 完成任务后，结果会回到主 Agent，用户仍然只和主 Agent 交互。

生活类比是：主管给不同专家派单。专家完成后把结果交还主管，最终仍由主管对客户负责。

OpenAI Agents SDK 中的“Agents as tools”就是一个直接的例子：

from agents import Agent
research_agent = Agent(name="Research Agent",instructions="负责资料调研，并输出结构化事实摘要。",)writer_agent = Agent(name="Writer Agent",instructions="根据提供的资料写出通俗、准确的文章。",)manager_agent = Agent(name="Manager Agent",instructions="分析用户任务，按需调用专业 Agent，并整合最终答案。",tools=[research_agent.as_tool(tool_name="research_topic",tool_description="需要检索和整理资料时使用。",),writer_agent.as_tool(tool_name="write_article",tool_description="已有资料，需要生成文章时使用。",),],)

四个关键问题

• 谁决定下一步？ 主 Agent 的模型和运行时。
• 传递什么？ 主 Agent 为子 Agent 生成的任务输入，以及子 Agent 返回的结果。
• 谁面向用户？ 主 Agent。
• 状态在哪里？ 对话主状态通常由主 Agent 保存；子 Agent 往往使用隔离的临时上下文。

适用场景

• 主流程清晰，专业任务可以独立委派；
• 希望统一由一个 Agent 面向用户；
• 需要让不同团队维护不同专业 Agent；
• 希望通过上下文隔离减少主会话负担。

优点

• 概念简单，容易实现；
• 主 Agent 统一控制，结果容易汇总；
• 子 Agent 上下文相对独立；
• 子任务可以串行，也可以按需并行。

局限

• 所有结果通常都要回到主 Agent，主 Agent 容易成为中心瓶颈；
• 复杂流程中的循环、恢复和显式状态管理不够直观；
• 如果主 Agent 的任务描述不准确，子 Agent 可能从一开始就拿错上下文。

Tool Calling 并不是不能处理动态决策。主 Agent 完全可以根据当前结果动态选择下一个子 Agent。只是当流程出现大量分支、循环、持久化状态和失败恢复时，显式的图结构通常更容易管理。

05

机制二：Graph-State——所有节点围绕共享状态协作

如果一个任务不是简单的“研究完再写作”，而是需要来回判断、补充、审核和返工，单纯依赖主 Agent 连续调用工具，流程会越来越难看清。

这时候可以使用 Graph-State 模式。

它的核心思想是：

把工作流表示成一张图，由节点执行工作，由边决定下一步，所有节点围绕一份结构化状态推进任务。

可以把 State 理解为当前任务的“工作台快照”。里面可能保存：

• 用户原始需求；
• 已完成的调研结果；
• 当前文章草稿；
• 审核意见；
• 当前应该进入哪个步骤；
• 错误次数和重试次数。

每个节点读取自己需要的字段，完成工作后返回局部更新。共享状态并不意味着所有 Agent 必须看到全部信息，系统可以通过状态结构和上下文组装，只向不同节点提供必要内容。

一个简化流程可能是：

1. 用户消息进入 State；
2. Supervisor 判断下一步先调研；
3. Researcher 将调研结果写入 State；
4. Supervisor 再次读取 State，判断资料是否充分；
5. 如果不足，继续补充调研；
6. 如果充分，路由到 Writer；
7. Writer 写入草稿后，路由到 Reviewer；
8. Reviewer 判断通过或退回修改；
9. 直到流程结束。

LangGraph 的核心抽象就是 State、Node 和 Edge。下面是用于解释结构的简化代码：

from typing import Literal, TypedDict
from langgraph.graph import StateGraph, START, END
class TeamState(TypedDict):
messages: list[str]next:
Literal["researcher", "writer", "FINISH"]
def supervisor_node(state: TeamState):
# 根据当前状态判断下一步，并返回局部状态更新...
def researcher_node(state: TeamState):
# 执行调研，把结果写回 messages...
def writer_node(state: TeamState):
# 根据调研结果生成文章...
def route(state: TeamState):
return state["next"]
builder = StateGraph(TeamState)
builder.add_node("supervisor", supervisor_node)
builder.add_node("researcher", researcher_node)
builder.add_node("writer", writer_node)
builder.add_edge(START, "supervisor")
builder.add_conditional_edges("supervisor",route,{"researcher": "researcher","writer": "writer","FINISH": END,},)
builder.add_edge("researcher", "supervisor")
builder.add_edge("writer", END)
app = builder.compile()

这里使用 next 字段只是为了方便理解，不是所有 Graph-State 系统都必须这样设计。路由也可以由固定边、条件函数、命令或其他状态字段决定。

四个关键问题

• 谁决定下一步？ 图运行时根据边、条件函数和当前 State 决定；某些节点也可以通过更新状态参与决策。
• 传递什么？ 结构化的 State 更新，而不只是某个函数的返回字符串。
• 谁面向用户？ 由图设计决定，可以是固定节点，也可以是当前活跃节点。
• 状态在哪里？ 图状态由运行时管理，需要时可以通过 Checkpoint 持久化和恢复。

适用场景

• 有复杂条件分支和循环；
• 需要审核、返工和重试；
• 任务可能被暂停后恢复；
• 需要清楚查看当前执行到哪一步；
• 需要将确定性工作流和 Agent 判断混合起来。

优点

• 流程结构显式，复杂路由更容易表达；
• 适合循环、失败恢复、人工审批和长任务；
• 状态可以持久化，便于追踪和调试；
• 可以将规则节点与 LLM 节点组合使用。

局限

• 状态结构和路由设计需要额外工程投入；
• 节点增多后，调试状态更新和并发合并并不简单；
• 上下文传递不合理时，仍然可能出现信息过多或信息缺失。

06

机制三：Handoff——把对话控制权交给专家

如果说 Subagent as Tool 像“主管找专家问一个问题”，那么 Handoff 更像“客服把电话转接给专业部门”。

它的核心思想是：

当前 Agent 不只是向另一个 Agent 获取一次结果，而是把当前对话的处理权转交给它。

举个例子。

用户对客服总管说：“为什么我的退款还没到账？”

Subagent as Tool 的做法

客服总管调用退款专家：

“请查询这个订单的退款状态。”

退款专家返回：

“退款正在银行处理中，预计两个工作日到账。”

客服总管拿到结果后，继续和用户沟通。

Handoff 的做法

客服总管判断这是退款问题后，直接将用户转交给退款 Agent。接下来由退款 Agent 面向用户，继续询问订单号、解释状态并完成处理。

从用户体验上看，这是控制权移交；从具体实现上看，Handoff 仍然可能通过一个类似 transfertorefund\_agent 的工具触发。

OpenAI Agents SDK 中可以这样配置：

from agents import Agent
billing_agent = Agent(name="Billing Agent",instructions="负责处理账单和扣款问题。",)
refund_agent = Agent(name="Refund Agent",instructions="负责处理退款申请和退款状态。",)
triage_agent = Agent(name="Triage Agent",instructions="判断用户问题所属领域，并在需要时转交给专业 Agent。",
handoffs=[billing_agent, refund_agent],)

Handoff 时，接收方通常能获得对话历史，但并不代表必须原样传递所有内容。实际系统可以过滤、裁剪或总结上下文，只把专业 Agent 需要的信息交给它。

另外，专家 Agent 完成任务后是否自动交还给原 Agent，也取决于系统设计。它可以继续负责后续对话，也可以通过新的 Handoff 转回客服总管。

四个关键问题

• 谁决定下一步？ 当前活跃 Agent 根据用户意图决定是否移交。
• 传递什么？ 对话历史、当前状态和经过筛选的上下文。
• 谁面向用户？ 当前接管控制权的 Agent。
• 状态在哪里？ 通常保存在跨轮次的会话状态中，并记录当前活跃 Agent。

适用场景

• 客服、咨询和多领域问答；
• 专家需要直接向用户追问信息；
• 不同阶段需要不同提示词、工具和权限；
• 对话会持续多轮，不适合每次都回到统一主 Agent。

优点

• 更接近真实的专家转接体验；
• 专家 Agent 可以直接和用户沟通；
• 多轮对话中可以减少反复经过主 Agent 的开销；
• 不同 Agent 可以拥有不同的工具和行为规则。

局限

• 上下文交接设计更复杂；
• 需要明确谁当前拥有控制权；
• 如果来回转接过多，用户体验和调试都会变差；
• 错误的 Handoff 可能让用户进入不合适的处理流程。

07

机制四：Pub-Sub——通过消息发布和订阅协作

前三种方式大多能看到一个比较明确的主流程或当前控制者。

但在更大规模、更松耦合的系统里，Agent 可能由不同团队开发，运行在不同服务中，并不适合由一个主 Agent 直接管理所有参与者。

这时可以采用 Pub-Sub，也就是消息发布/订阅模式。

核心思想是：

Agent 不直接指定谁来处理，而是向消息总线发布事件；订阅了相关事件的 Agent 自动接收并执行。

例如：

1. 研究 Agent 完成资料收集，发布 ResearchCompleted；
2. 写作 Agent 订阅这个事件，收到后开始写作；
3. 写作完成后发布 DraftCreated；
4. 审核 Agent 订阅草稿事件，自动开始检查；
5. 审核失败时发布 RevisionRequested，写作 Agent 再次被唤醒。

生活类比是一个团队群，但这里的重点不是“大家随意聊天”，而是发送有明确类型和结构的事件。

消息中可能包括：

{
"event": "DraftCreated",
"task_id": "article-1024",
"artifact_url": "...",
"version": 3
}

这个系统里不一定完全没有协调者，但各 Agent 不需要直接知道彼此的地址和内部实现。它们只需要知道自己发布什么事件、订阅什么事件。

四个关键问题

• 谁决定下一步？ 消息类型、订阅关系和各 Agent 的消费逻辑共同决定。
• 传递什么？ 事件、消息以及结果或文件的引用。
• 谁面向用户？ 通常由独立的入口服务或响应 Agent 负责，不一定是事件生产者。
• 状态在哪里？ 分散在消息系统、任务存储和各 Agent 自己的状态中。

适用场景

• 大规模、松耦合的 Agent 网络；
• 多个团队独立开发和部署 Agent；
• 事件驱动的异步任务；
• 一个事件需要同时唤醒多个处理者；
• 长耗时任务和后台流水线。

优点

• 发布者和订阅者解耦；
• 容易扩展新的 Agent；
• 天然支持异步处理和一对多分发；
• 适合跨服务、跨团队协作。

局限

• 消息顺序、重复消费和失败重试处理复杂；
• 很难从单个调用链看清完整过程；
• 调试需要统一的事件追踪和任务标识；
• 分布式状态一致性和最终结果汇总难度较高。

08

延伸：A2A 不是 Pub-Sub 的另一个名字

讲到 Agent 间通信，很容易看到另一个热门概念：A2A，也就是 Agent2Agent Protocol。

需要特别强调：A2A 不能直接等同于 Pub-Sub。

Pub-Sub 是一种消息分发架构；A2A 是独立 Agent 系统之间的互操作协议。它解决的问题是：不同公司、不同框架、不同技术栈构建的 Agent，如何发现彼此、委派任务、传递进度并交付结果。

A2A 的核心角色和对象包括：

• A2A Client：代表用户发起任务的 Agent 或应用；
• A2A Server：提供能力的远程 Agent；
• Agent Card：描述 Agent 身份、能力、地址和认证方式的数字名片；
• Message：一次通信消息；
• Task：具有状态和生命周期的工作单元；
• Artifact：远程 Agent 最终交付的文档、图片或结构化数据等成果。

A2A 可以采用请求响应、轮询、SSE 流式更新和异步推送通知等交互方式，并不要求所有 Agent 连接到同一条消息总线。

截至 2026 年 7 月，A2A 已发布 1.0 规范，提供多种官方 SDK，并由 Linux Foundation 项目治理。它已经不只是一个研究概念，但相较于普通的 Tool Calling 和单体工作流，跨组织的工程落地仍处于生态建设阶段。

A2A 和 MCP 有什么区别？

可以用一句话记住：

• MCP 用来连接 Agent 与工具、数据源和外部系统；
• A2A 用来连接相互独立的 Agent 系统。

例如，一个旅行 Agent 可以通过 MCP 查询航班和酒店工具，再通过 A2A 把签证材料整理任务委派给另一个独立 Agent。

09

四种方式一张表总结

机制	谁决定下一步	主要传递内容	谁面向用户	状态位置	典型场景	相对工程复杂度
Subagent as Tool	主 Agent	任务参数、子 Agent 结果	主 Agent	主会话 + 隔离子上下文	专业任务委派、统一汇总	★★
Graph-State	图运行时、条件边和状态	结构化 State 更新	由图设计决定	共享状态与 Checkpoint	复杂分支、循环、恢复、审批	★★★★
Handoff	当前活跃 Agent	对话历史、当前状态、控制权	接管后的 Agent	跨轮次会话状态	客服转接、多领域咨询	★★★
Pub-Sub	事件和订阅关系	事件、任务标识、结果引用	独立入口或响应 Agent	消息系统 + 分布式存储	异步流水线、大规模松耦合网络	★★★★★

复杂度只是相对判断。一个最简单的消息队列可能比复杂的 LangGraph 容易，而一个包含数十个工具和子 Agent 的 Tool-Call 系统，也可能非常难维护。

更重要的是，这些方式可以组合使用，而不是必须选择其中一种。

10

实战拆解：CodeBuddy Code 如何用 Markdown 配置子 Agent？

讲完机制，再来看一个真实产品中的实现方式。

以CodeBuddy Code 支持通过 Markdown 文件配置专门的子 Agent。用户不需要手动实现一套复杂的 Agent 注册系统，只要描述子 Agent 的名称、适用场景、工具权限和系统提示词，就可以让主 Agent 按需委派任务。

例如，在项目的 .codebuddy/agents/ 目录下创建：

---name: code-reviewerdescription: 代码审查专家。修改代码后，主动检查质量、安全性和可维护性。tools: Read, Grep, Glob, Bashmodel: inherit---你是一名资深代码审查专家。请重点检查：- 代码是否清晰、可维护；- 是否存在安全漏洞；- 错误处理是否完整；- 是否需要补充测试。

这段配置包含两部分：

1. YAML Frontmatter

它描述这个子 Agent 是谁，以及系统应该怎么使用它：

• name：子 Agent 的唯一名称；
• description：它适合处理什么任务，也是自动委派的重要依据；
• tools：它能使用哪些工具；
• model：指定模型，或者用 inherit 继承主会话模型。

2. 系统提示词正文

分隔线后面的内容定义子 Agent 的角色、目标、工作步骤和输出要求。

CodeBuddy Code 会读取这些配置，并在任务与 description 匹配时，将工作委派给相应的子 Agent。子 Agent 使用独立上下文完成任务，再把结果返回给主 Agent。

从使用者视角看，这可以理解为一种声明式的 Subagent as Tool：

• 传统方式需要写代码注册 Agent；
• CodeBuddy 把注册过程封装成 Markdown 配置；
• 用户只声明“它是谁、什么时候用、能做什么”；
• 具体的创建会话、加载工具和结果回传由产品运行时处理。

这里需要注意，我们能够从官方文档确认其配置形式、独立上下文和任务委派行为，但没有必要进一步断言产品内部一定被转换成某一种特定的 Function Calling 实现。对普通读者来说，理解它表现出的协作模式已经足够。

11

如果你是小白，从哪里开始？

如果你看完以后想自己上手，可以按照下面的路线逐步学习。

第一步：先体验工作流拆分

可以先用低代码或可视化 Agent 平台，搭一个“调研—写作—审核”的简单流程。

这一阶段不用追求框架和代码，重点是理解：

• 一个任务怎么拆成多个角色；
• 每个角色需要什么输入；
• 输出怎么传给下一步；
• 什么情况下需要返工。

第二步：尝试 Subagent as Tool

用 OpenAI Agents SDK、LangChain 或其他支持子 Agent 的框架，搭一个主 Agent 调用研究员和写作者的例子。

这是最容易理解的多 Agent 起点。

CrewAI 也适合用来体验“定义角色、任务和团队”的高层编排方式。它除了 Crew 之外，还提供支持状态、路由和持久化的 Flow，因此不要把整个 CrewAI 框架简单等同于一种 Tool-Call 实现。

第三步：学习 Graph-State

当流程开始出现下面这些需求时，可以学习 LangGraph：

• 根据结果动态分支；
• 调研不足时循环补充；
• 审核失败时退回修改；
• 中途暂停，之后继续；
• 插入人工确认节点。

理解 State、Node 和 Edge 后，复杂工作流会变得更容易描述。

第四步：再理解 Handoff 和事件驱动

如果你在做客服或多轮咨询，重点研究 Handoff。

如果你在做异步流水线、多个系统和多个团队之间的协作，再研究 Pub-Sub、任务队列和事件追踪。

第五步：关注 MCP 和 A2A

最后再去理解两个跨系统协议：

• MCP 解决 Agent 如何连接工具和数据；
• A2A 解决独立 Agent 如何发现、委派和协作。

不一定马上用得上，但它们能帮助你建立更完整的 Agent 系统视角。

12

写在最后

多 Agent 不是为了让系统里出现更多“AI 角色”，而是为了更合理地拆分任务、隔离上下文、控制权限和组织协作。

Agent 之间所谓的“沟通”，本质上也不是简单模仿人类聊天，而是在回答四个工程问题：

1. 谁决定下一步做什么？
2. 任务和上下文怎么传过去？
3. 状态保存在哪里？
4. 结果由谁接收并继续处理？

Subagent as Tool 用中心化方式委派专业任务；Graph-State 用共享状态和图控制复杂流程；Handoff 把对话控制权交给更合适的专家；Pub-Sub 用消息和事件连接松耦合的 Agent。

而 A2A、MCP 这样的协议，则进一步把协作范围从单个应用内部，扩展到了不同工具和独立 Agent 系统之间。

你不需要死记每一个框架的 API。只要抓住任务、上下文、状态、控制权和结果这几个核心对象，再看任何多 Agent 产品，都会更容易理解它到底在封装什么。

学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%免费】