AI Agent并非简单的聊天机器人，而是一个由LLM、Token、Context、Prompt、Tool、MCP、Agent Loop和Skill构成的工程系统。本文从工程视角拆解这些核心组件，阐述它们如何协同工作，帮助读者理解 Claude Code、Codex等产品的原理和解决的问题。通过解析LLM的文本预测功能、Token作为计算单位、Context作为工作区、Prompt作为任务指令等，揭示Agent如何实现目标规划、工具调用和循环执行，最终完成复杂任务。文章强调Agent的核心在于多步执行而非单次回答，并介绍了Coding Agent为何在开发者中率先普及。理解这些底层构件，才能真正掌握AI Agent的运行方式，为未来软件工程升级奠定基础。

AI Agent 不是一个更会聊天的大模型，而是一套由 LLM、Token、Context、Prompt、Tool、MCP、Agent Loop 和 Skill 共同组成的工程系统。理解这些底层构件，才能真正理解 Claude Code、Codex、Cursor、OpenCode、Hermes-Agent 这类产品为什么会出现，以及它们到底在解决什么问题。

过去一年，AI 圈最热的词，已经从“大模型”逐渐变成了“Agent”。
你可能已经听过很多名词：

LLM、Token、Context、Prompt、RAG、Tool、MCP、Agent、Agent Skill、Claude Code、Codex、Cursor、OpenCode、Hermes-Agent。

这些概念看起来分散，甚至有点像营销词。但如果从工程视角拆开，它们其实可以串成一条非常清晰的技术链路：

LLM -> Token / Tokenizer -> Context / Context Window -> Prompt / System Prompt -> RAG -> Tool -> MCP -> Agent Loop -> Agent Skill -> Coding Agent / Domain Agent

一句话概括：

LLM 负责生成，Token 是计算单位，Context 是工作区，Prompt 是任务指令，Tool 连接外部系统，MCP 统一工具接入方式，Agent 负责规划与执行，Skill 则把可复用经验沉淀成能力包。

这篇文章不讲玄学，也不堆概念。我们从最底层开始，一层一层往上拆，把 AI Agent 的底层逻辑讲清楚。

---

一、Agent 到底是什么？

如果只用一句话解释 Agent，可以这样说：

Agent 是一个能够围绕目标进行规划、调用工具、观察结果，并持续推进任务完成的系统。

注意，这里有三个关键词：

• 目标：Agent 不是简单回答一句话，而是要完成一个任务。
• 工具：Agent 需要调用外部能力，比如读文件、查资料、执行命令、访问 API。
• 循环：Agent 会根据工具返回结果继续判断下一步，而不是一次生成就结束。

所以，Agent 不是单独的模型。

更准确地说：

Agent = LLM + Prompt + Context + Tool + Runtime + Memory/State + Policy

LLM是Agent的推理核心，但Agent本身是一个更完整的工程系统。

这也是为什么同一个模型，在普通聊天框里只是Chatbot，放到Claude Code、Codex、Cursor、OpenCode这类工具里，就变成了能读代码、改文件、运行命令、观察结果并继续修复问题的Coding Agent。

二、LLM：Agent 的推理发动机

LLM，全称 Large Language Model，也就是大语言模型。

今天主流大模型大多基于 Transformer 架构。Transformer 最早由 Google 团队在 2017 年论文《Attention Is All You Need》中提出，后来被 GPT、Claude、Gemini 等模型体系不断放大，成为当前 AI 浪潮的底层技术基座。

从工程使用角度看，我们不需要一开始就陷入复杂的注意力矩阵和训练细节。你可以先把 LLM 理解为一个高维文本预测函数：

输入一段上下文 -> 预测下一个最可能出现的 Token

例如用户输入：

这个技术方案怎么样？

模型不是一次性把完整回答全部“想好”。它会先预测第一个 Token，再把这个 Token 追加回上下文，再预测下一个 Token，如此循环，直到输出结束标识。

这也是为什么大模型通常会一个字、一个词、一个片段地流式输出。

这里有一个关键认知：

LLM 本身只负责生成文本。它不会天然拥有执行能力。

它不会自己读你的代码仓库，不会自己访问数据库，也不会自己调用接口。它能做的是根据上下文生成下一段最合理的文本。至于这段文本能否触发工具、能否执行动作，取决于外层平台如何设计。

这就引出了下一个概念：Token。

---

三、Token：模型真正处理的基本单位

人类读的是文字，模型处理的是数字。

在文字和数字之间，需要一个翻译器，这个翻译器叫 Tokenizer。

Tokenizer 做两件事：

编码：把文本切分成 Token，再映射成 Token ID。解码：把模型输出的 Token ID 还原成可读文本。

这里最容易误解的一点是：

Token 不等于字，也不等于词。

例如中文里的一个词，可能被切成多个 Token；英文里的长单词，也可能被切成词根、前缀、后缀等多个 Token；某些符号和特殊字符甚至会被拆成多个 Token。

所以更准确的理解是：

Token 是模型自己使用的一套文本切分单位。

它不是语言学里的“词”，而是模型训练和推理时处理文本的最小粒度之一。

为什么工程师必须理解 Token？

因为它直接影响四件事：

• 成本：输入和输出 Token 越多，调用成本越高。
• 速度：生成 Token 越多，响应时间越长。
• 上下文容量：模型一次能接收的信息量由 Context Window 决定。
• Agent 能力边界：工具描述、系统提示词、历史记录、Skill 指令都会消耗 Token。

很多 Agent 系统效果不好，不是模型不够强，而是上下文组织太差，Token 被无效信息占满了。

---

四、Context：大模型的临时工作区

我们经常觉得大模型“记得刚才聊过什么”。

但严格来说，大模型并没有人类意义上的记忆。它之所以能接上前文，是因为应用程序在每次请求时，把历史对话、当前问题、系统规则等内容重新组织后，一起发给模型。

这些信息的总和，就是 Context，也就是上下文。

一个真实 Agent 请求里的 Context，通常包含：

• 用户当前问题
• 历史对话
• System Prompt
• 可用工具列表
• 工具参数 schema
• 工具调用结果
• RAG 检索片段
• 当前任务状态
• Agent Skill 元数据和指令

Context 可以理解为模型本轮推理时看到的“临时工作区”。

而 Context Window，则表示这个工作区最多能容纳多少 Token。

很多人会天然觉得 Context Window 越大越好。这个判断只对了一半。

大窗口确实能放更多内容，但也会带来三个问题：

• 成本更高
• 延迟更大
• 噪声更多

如果把无关文档、冗余历史、过长工具描述全部塞进去，模型反而更容易抓不住重点。

所以 Agent 工程里有一个非常核心的能力：

不是把所有信息塞给模型，而是把正确的信息在正确的时机塞给模型。

RAG 和 Skill 的渐进式加载，本质上都是围绕这个目标设计的。

---

五、RAG：让模型只看到相关知识

假设你有一套上千页的产品手册，希望模型基于手册回答用户问题。

最简单粗暴的方式，是把整本手册塞进 Context。

但这通常不是好方案。

更工程化的方式是 RAG，也就是 Retrieval-Augmented Generation，检索增强生成。

RAG 的基本流程是：

把文档切成多个片段。为片段建立向量索引、关键词索引或混合索引。用户提问时，先检索最相关的片段。只把这些片段放入 Context。模型基于检索结果生成回答。

RAG 解决的不是“让模型变聪明”，而是“让模型看到正确资料”。

在 Agent 系统里，RAG 往往不是一个独立产品能力，而是一个可调用工具。Agent 会先判断当前任务是否需要查知识库，如果需要，再调用检索工具，把结果带回上下文继续推理。

所以 RAG 可以看成 Agent 的外部知识入口。

---

六、Prompt：给模型的任务指令

Prompt 不神秘，它就是给模型的输入指令。

例如：

帮我写一篇技术文章。

这是 Prompt。

但这个 Prompt 太宽泛。模型不知道文章写给谁看，写多深，什么风格，是否要代码示例，是否要工程实践。

更好的 Prompt 会明确四件事：

• 目标：要完成什么任务
• 背景：为什么要做这件事
• 约束：不能做什么，必须遵守什么
• 输出：以什么格式交付

在真实系统里，Prompt 通常分为两类。

User Prompt 是用户当前输入的问题或任务。

System Prompt 是系统在后台设定的角色、规则、边界和行为规范。

例如做一个数学辅导助手，System Prompt 可以写：

你是一个耐心的数学老师。学生提问时，不要直接给答案，而是一步步引导学生理解解题思路。

当用户问“3 + 5 等于几”时，模型就不会直接说“8”，而是会尝试引导。

这说明 System Prompt 对模型行为有很强的约束作用。

但 Prompt 也不是万能的。随着任务变复杂，单靠 Prompt 很快会遇到瓶颈：

• 信息太长，容易占满上下文。
• 规则太多，容易互相冲突。
• 任务需要外部数据，模型无法凭空获取。
• 任务需要执行动作，模型本身没有执行能力。

这时候就需要 Tool。

---

七、Tool：让模型连接真实世界

大模型默认只能生成文本，无法直接感知和影响外部世界。

你问它“今天上海天气怎么样”，如果没有外部工具，它只能基于已有知识猜测或拒答，因为实时天气不在模型参数里。

Tool 就是为了解决这个问题。

从工程角度看，Tool 本质上就是一个函数：

输入参数 -> 执行逻辑 -> 返回结果

例如天气查询工具可以抽象成：

get_weather(city: string, date: string) -> weather_report

数据库查询工具可以抽象成：

query_database(sql: string) -> rows

代码搜索工具可以抽象成：

search_code(keyword: string) -> matched_files

这里有一个非常重要的边界：

模型不会真正执行工具，平台才会真正执行工具。

完整流程通常是：

平台把用户问题、历史上下文和工具列表发给模型。模型判断是否需要工具。如果需要，模型输出工具调用意图和参数。平台解析模型输出，调用真实函数、命令或 API。平台把工具结果写回 Context。模型基于工具结果继续推理或生成最终答案。

模型负责：

• 判断要不要调用工具
• 选择调用哪个工具
• 生成工具参数
• 理解工具返回结果
• 总结为用户可读答案

平台负责：

• 管理工具权限
• 校验参数
• 执行真实调用
• 捕获错误
• 回传结果
• 记录审计日志

理解这个边界，就能理解为什么 Agent 工程必须重视权限、沙箱、确认机制和审计。

Agent 越能干，越不能让它无约束地执行。

---

八、MCP：统一工具接入协议

当工具越来越多，新的问题出现了。

同一个工具，如果要接入不同 Agent 平台，可能要为每个平台分别适配一套协议。

例如一个文件检索工具，如果要同时接入桌面助手、命令行助手、IDE 助手、企业知识库助手，可能要写多套胶水代码。

MCP，全称 Model Context Protocol，可以理解为一套面向模型上下文的标准协议。

它解决的问题是：

工具和资源如何以统一方式暴露给 Agent。

MCP 通常可以承载三类能力：

• Tools：可执行函数，比如查天气、搜索代码、查询数据库、调用内部 API。
• Resources：可读取资源，比如文件、文档、配置、数据表结构。
• Prompts：可复用提示模板，比如代码审查模板、故障分析模板、需求澄清模板。

如果用一个类比来理解，MCP 有点像 AI Agent 世界里的统一接口标准。

没有统一标准时，每个平台都要自己定义工具如何描述、如何调用、如何返回。统一之后，工具开发者只需要按一种方式暴露能力，不同 Agent 宿主就可以按标准接入。

这对企业内部尤其重要。

企业里往往已经有很多系统：

• 代码仓库
• 知识库
• 工单系统
• 监控平台
• 发布平台
• 数据查询平台
• 内部权限系统

如果这些能力都能通过统一协议暴露给 Agent，那么 Agent 就不再只是聊天窗口，而会变成企业软件系统的新入口。

---

九、Agent：从回答问题到完成任务

有了 LLM、Prompt、Context、Tool 和 MCP，Agent 的轮廓就清楚了。

Agent 的核心不是“一次回答”，而是“多步执行”。

一个典型 Agent Loop 长这样：

接收目标 -> 分析当前状态 -> 制定下一步计划 -> 选择工具 -> 执行工具 -> 观察结果 -> 更新状态 -> 继续下一轮 -> 输出最终结果

例如用户提出：

帮我分析这个项目为什么测试失败，并尝试修复。

普通 Chatbot 可能只能给出一些建议。

Coding Agent 则会尝试：

读取项目结构。查看测试脚本。运行测试命令。分析失败日志。定位相关代码。修改代码。再次运行测试。如果还有失败，继续迭代。最后汇总修改内容和验证结果。

这就是 Agent 和 Chatbot 的关键区别：

Chatbot 偏回答，Agent 偏完成任务。

常见 Agent 架构包括：

• ReAct：Reason + Act，边推理边行动。
• Plan-and-Execute：先规划，再逐步执行。
• Workflow Agent：把任务拆成固定流程节点。
• Multi-Agent：多个 Agent 分工协作。

不同产品会采用不同实现方式，但底层逻辑大同小异。

Claude Code、Codex、Cursor、OpenCode、Hermes-Agent 等产品，本质上都是把这套 Agent Loop 放进不同的工程场景里。

---

十、Agent Skill：把经验沉淀成可复用能力

---

当 Agent 能读文件、调工具、执行任务之后，很快会遇到一个新问题：

很多任务不是一次性的，而是重复出现的。

例如：

• 每次写技术文章，都要按固定结构组织。
• 每次做代码审查，都要检查安全、性能、可维护性、测试覆盖。
• 每次分析故障，都要先看现象、再看日志、再定位变更。
• 每次生成接口文档，都要按团队模板输出。
• 每次做版本发布，都要先检查变更、风险、回滚方案。

如果每次都把这些规则塞进 Prompt，效率很低，也容易遗漏。

这就是 Agent Skill 的价值。

Skill 是写给 Agent 看的能力说明文档。

它通常会描述：

• 这个 Skill 适合什么任务
• 任务目标是什么
• 执行步骤是什么
• 可用工具有哪些
• 判断规则是什么
• 输出格式是什么
• 有哪些示例
• 有哪些禁止事项

一个典型 Skill 可以拆成两层。

第一层是元数据层。

它告诉 Agent：

name: tech-article-writerdescription: Use this skill when writing a structured technical article for developer audiences.

这部分相当于 Skill 的名片。Agent 可以根据名称和描述判断当前任务是否匹配。

第二层是指令层。

它告诉 Agent 具体怎么做：

 # Goal Write a publishable technical article for developer audiences. # Steps 1. Identify the target reader.2. Extract the core technical chain.3. Explain concepts from bottom to top.4. Add engineering examples.5. End with a practical summary. # Output Format - Title- Lead- Main sections- Architecture summary- Final takeaway

这类设计背后有一个重要机制：渐进式披露。

Agent 不需要一开始就加载所有 Skill 的完整内容。它可以先读取 Skill 的名称和描述，只有当任务匹配时，才加载完整指令。

这能带来三个好处：

• 节省 Token
• 降低上下文噪声
• 让团队经验可版本化、可复用、可审查

对企业来说，Skill 不只是 Prompt 文件。

它更像一种轻量级 SOP，一种把组织经验转化为 Agent 可执行能力的方式。

---

十一、Coding Agent：为什么开发者会最先感受到变化？

---

Agent 最容易落地的场景之一，就是软件研发。

原因很简单：软件工程天然具备几个特点：

• 上下文丰富：代码、文档、测试、日志、提交记录都可以被读取。
• 任务可拆解：分析、修改、验证、总结可以形成闭环。
• 反馈明确：测试通过与否、编译是否成功、Lint 是否报错都能作为观察结果。
• 工具成熟：Git、Shell、包管理器、测试框架、CI 系统都可以被工具化。

这就是 Coding Agent 快速爆发的原因。

以常见产品为例：

产品	典型形态	更适合的场景
Claude Code	命令行 Coding Agent	大型仓库分析、跨文件修改、复杂任务拆解
Codex	OpenAI 体系 Coding Agent	代码生成、修复、自动化工程任务
Cursor	IDE Agent	日常开发、代码补全、重构、上下文问答
OpenCode	开源/可定制 Agent	私有化、企业集成、可控工具链
Hermes-Agent	Agent 工程框架或执行载体	任务编排、工具集成、领域能力封装

这些产品的差异不只在模型，而在于运行环境：

• 能不能读完整项目上下文
• 能不能调用命令
• 能不能修改文件
• 能不能观察测试结果
• 有没有权限控制
• 有没有任务记忆
• 有没有可复用 Skill

所以，判断一个 Coding Agent 是否好用，不能只看“它用了哪个模型”，还要看它的工程闭环是否完整。

很多团队刚开始用 AI 时，停留在 Prompt 阶段。

典型方式是：

把需求复制给模型，让模型生成结果。

这当然有价值，但很难规模化。

因为每个人写 Prompt 的方式不同，输出质量也不稳定。更重要的是，团队经验没有沉淀下来。

真正进入 Agent 阶段后，企业要沉淀的不是一堆零散 Prompt，而是一套可复用能力体系：

业务知识 -> 文档和知识库工程规范 -> System Prompt 和 Policy操作流程 -> Skill外部系统 -> Tool / MCP执行闭环 -> Agent Runtime

这也是为什么 Agent 会推动软件工程组织方式变化。

过去我们把经验写进文档，靠人去读、去理解、去执行。

未来更可能是：

把经验写成 Agent 可以理解和执行的 Skill，让 Agent 在任务中主动调用。

例如一个代码审查 Skill，可以要求 Agent：

先理解变更范围。再检查潜在 bug。再检查性能风险。再检查安全问题。最后给出按严重程度排序的审查意见。

一个技术写作 Skill，可以要求 Agent：

先提炼知识框架。再补齐背景概念。再按开发者社区风格组织文章。最后输出可发布 Markdown。

这比单次 Prompt 更稳定，也更适合团队协作。

到这里，我们可以把整套体系压缩成一张图：

LLM ↓Token / Tokenizer ↓Context / Context Window ↓Prompt ├─ User Prompt └─ System Prompt ↓RAG ↓Tool ↓MCP ↓Agent Loop ↓Agent Skill ↓Domain Agent ├─ Coding Agent ├─ Knowledge Agent ├─ Data Agent └─ Business Agent

每一层解决的问题如下：

层级	解决的问题	常见误区
LLM	语言理解、推理、生成	把 LLM 误认为 Agent 本身
Token	模型处理文本的基本单位	以为 Token 等于字或词
Context	模型当前能看到的信息总和	以为上下文越长越好
Prompt	给模型任务和规则	以为 Prompt 能解决所有问题
RAG	给模型提供相关知识	以为 RAG 等于把资料全塞进去
Tool	连接外部系统	以为模型自己执行工具
MCP	统一工具和资源接入	以为 MCP 只是另一个 API
Agent Loop	多步规划和执行	以为 Agent 只是聊天机器人
Skill	沉淀可复用经验	以为 Skill 只是长 Prompt
Domain Agent	面向具体领域完成任务	忽略权限、审计和边界

这张图的重点不是名词，而是层级关系。

只有把底层链路打通，才能判断一个 Agent 产品到底强在哪里，又弱在哪里。

---

最后Agent 时代真正的竞争力是什么？

过去十年，软件行业经历了几次重要变化。

从单体系统走向分布式服务。

从手工部署走向自动化流水线。

从脚本工具走向平台化工程。

从人肉协作走向标准化流程。

而今天，我们正在进入下一个阶段：

Agent 驱动的软件工程。

很多人担心：

AI 会不会取代程序员？

但从工程实践来看，更可能发生的是：

程序员开始拥有自己的数字同事。

它们不会取代开发者，却会逐渐承担：

• 文档整理
• 信息检索
• 代码生成
• 代码审查
• 测试执行
• 结果验证
• 任务总结

未来的软件团队很可能会变成：

人类工程师 +Coding Agent +Knowledge Agent +Business Agent

真正的竞争力也将发生变化。

过去我们比拼的是：

谁写代码更快。

未来我们比拼的可能是：

谁能把组织经验、业务知识和工程规范，更高效地沉淀为 Agent 能够理解和执行的 Skill。

因为代码可以生成。

流程可以自动化。

但优秀团队积累多年的工程经验，才是最难复制的资产。

从这个角度看，Agent 的本质并不是新的聊天机器人。

它更像软件工程领域的一次基础设施升级。

而今天讨论的 LLM、Token、Context、Prompt、RAG、Tool、MCP、Agent Loop、Skill，正是这场升级背后的底层构件。

理解它们，也是在理解未来软件工程的运行方式。

最后

如果说程序员已经是高薪职业，那么干AI的程序员，就是高薪中的高薪。

现在的市场，已经用数据给程序员指明了方向：学AI大模型，就是冲刺高薪的最优解！

看着身边越来越多的同行转型大模型、拿到高薪offer，很多人心里都动了心，但真正的难题来了：零基础小白不知道从哪入门？有基础的程序员找不到系统学习路径？实战项目练手无门？面试不知道考什么？

别慌！今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包，覆盖从入门到实战、从理论到面试、从基础到进阶的全流程，所有资料均已整理归档，无冗余、无套路，免费分享给每一位想抓住AI风口的程序员和小白！

👇👇扫码免费领取全部内容👇👇

1、大模型系统化学习路线

2、大模型学习书籍&文档

3、AI大模型最新行业报告

4、大模型项目实战&配套源码

5、大模型大厂面试真题

四阶段精细化学习规划（附时间节点，可直接照做）

结合上述资源，给大家整理了一份可直接落地的四阶段学习规划，总时长约2个月，小白可循序渐进，程序员可根据自身基础调整节奏，高效掌握大模型核心能力，快速实现从“入门”到“能落地、能面试”的跨越。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

👇👇扫码免费领取全部内容👇👇

6、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

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

https://mp.weixin.qq.com/s/RUSTEmAy6wQRx5sjOAXd4g