本文深入浅出地介绍了大语言模型LLM及其应用架构从基础概念如LLM、LLM API、上下文管理等到构建智能体的四个阶段再到进阶架构中的上下文管理、MCP协议、Sub-Agent模式等最后给出了选择Tool、Skill、Sub-Agent的原则。文章旨在帮助程序员理解并掌握大模型开发技术提供了丰富的实战案例和代码示例适合对AI开发感兴趣的小白和程序员学习。1、概念全景图LLM大语言模型 │ │ 厂商通过 HTTP 提供调用能力 ▼ LLM API │ │ 客户端维护对话历史数组 ▼ Context上下文 │ │ 告诉 LLM 你有哪些工具可用 ▼ Tool Calling工具调用 │ │ 加入循环思考 → 行动 → 观察 ▼ Agent Loop智能体循环 │ ├──────────────┬──────────────┐ ▼ ▼ ▼ MCP 协议 Sub-Agent Agent Skill (标准化工具对接) (分工协作) (流程复用)2、基础概念2.1 LLM大语言模型ChatGPT、Claude、Gemini、DeepSeek 等都是 LLM。本质是超大号的文字接龙机器——给一段文字按概率逐词预测下一个词。当参数量达到千亿级别它就涌现出了写代码、写文章、做数学题的能力。2.2 LLM API大模型接口LLM 跑在云端 GPU 集群上厂商通过 HTTP API 提供调用能力你的代码 → HTTP POST带上问题 → LLM 服务 → HTTP 响应返回回答2.3 Context上下文LLM 本身是无状态的——每次调用都是一次全新的请求它不会记得上一句你说了什么。所谓上下文就是你随请求一起发过去的所有信息包括对话历史之前的每一轮问答系统提示词告诉 AI 你是谁、该怎么做的指令工具结果上一步工具调用返回的数据第 1 次请求[消息1] → AI 回复1 第 2 次请求[消息1, 回复1, 消息2] → AI 回复2 第 3 次请求[消息1, 回复1, 消息2, 回复2, 消息3] → AI 回复3每次都把完整历史发过去AI 才能记住之前聊了什么。记忆不在 AI 脑子里而在你发送的数组里。每个模型有上下文窗口Context Window限制比如 128K tokens。超出这个长度最早的内容就会被截掉。2.4 Tool / Function Calling工具调用这是从聊天机器人进化到Agent的关键一步。普通 LLM 只能生成文字但如果告诉它有个get_weather工具它就能返回结构化的调用请求{ functionCall: { name: get_weather, args: { city: 深圳 } } }LLM 并没有真的查天气它只是说我想调这个工具。真正执行的是你的代码。LLM 负责动脑决策代码负责动手执行。2.5 AI Agent智能体Agent 是一种架构模式把上面三者串在一起Agent LLM大脑 Tools手脚 Loop驱动循环LLM 负责理解任务、做出决策Tools 负责执行具体操作Loop 让 AI 反复思考→行动→观察直到任务完成2.6 MCP模型上下文协议有了 Tool CallingAgent 可以调用工具。但每接一个新工具你都要写一套定义、解析、执行的代码。工具一多维护成本爆炸。MCPModel Context Protocol 定义了一套统一的协议让 Agent 能以即插即用的方式对接外部工具和数据源——相当于 AI 世界的 USB 接口标准。2.7 Sub-Agent子智能体一个 Agent 什么都干容易出错上下文也会被塞满无关信息。Sub-Agent 模式是让主 Agent 把子任务委派给专门的小 Agent。每个子 Agent 有自己独立的上下文和专属工具做完后只把结果交还给主 Agent。2.8 Agent Skill技能Tool 是单个动作比如读文件但很多任务是一套固定流程比如生成 Git commit需要查状态 → 看 diff → 写 commit message → 执行提交。Agent Skill 就是预定义好的 prompt 工具组合——把多个工具和 prompt 打包成一键触发的流程。2.9 Context Management上下文管理LLM 的上下文窗口是有限的。对话越长历史消息越多总会塞满。而且 token 越多响应越慢、费用越高。上下文管理就是在记住足够多和别超标之间找平衡常见策略包括滑动窗口、摘要压缩、RAG 检索增强。3、从零构建 Agent — 四个阶段整个构建过程分为四个递进阶段每个阶段解锁一项新能力。3.1 阶段一单次对话API 调用最简单的起点——调用 LLM API让 AI 回答一个问题。const body { messages: [ { role: system, content: 你是一个有帮助的助手。 }, { role: user, content: 你好 }, ], }; const res await fetch(apiEndpoint, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey}, }, body: JSON.stringify(body), }); const data await res.json(); console.log(data.choices[0].message.content);关键参数系统提示词system prompt告诉 AI 你是谁、该怎么做的隐藏指令用户看不到但 AI 会始终遵守。对话内容messages用户实际发送的消息每条消息带 role谁说的和 content说了什么。能力 单轮问答关掉程序就全忘。3.2 阶段二多轮对话上下文维护LLM 本身不记得上一句你说了什么——每次 API 调用都是一次全新的、独立的请求。解决方案是在客户端维护一个 history 数组每次请求时带上完整历史class Chat { private history: Message[] []; async send(text: string): Promisestring { this.history.push({ role: user, content: text }); const reply await this.client.sendMessage(this.history, this.systemPrompt); this.history.push({ role: assistant, content: reply }); return reply; } }每次调 API 都把完整对话历史发过去LLM 本身是无状态的记忆完全靠客户端的数组模拟。能力 多轮对话但只会说不会做。3.3 阶段三工具调用Function CallingAI 能记住对话了但它只能说不能做。给 AI 一双手——Tool Calling。工具注册表——用标准格式描述每个工具{ name: run_shell_command, description: Run a shell command on the users machine..., parameters: { command: { type: string, description: The shell command to execute }, }, required: [command], }工具实现execute(params: Recordstring, unknown): Promiseunknown { const command params.command as string; return new Promise((resolve) { exec(command, { timeout: timeoutMs }, (error, stdout, stderr) { resolve({ exitCode: error?.code ?? 0, stdout, stderr }); }); }); }把工具列表随请求发给 API 后AI 的回复可能从纯文本变成函数调用请求// 纯文本回复 { text: 你好有什么可以帮你的 } // 工具调用请求 { functionCall: { name: run_shell_command, args: { command: ls -la } } }AI 没有真的执行命令它只是下达指令代码负责跑腿。3.4 阶段四Agent LoopReAct 循环有了工具调用能力但 AI 只能完成单步动作。现实任务通常需要多步协作。引入 Agent Loop即自动化的驱动循环——调完工具看结果把结果喂回给 AI让它继续判断下一步。这个过程通常被称为 ReAct (Reason Act)Reasoning推理AI 思考当前状况决定下一步Acting行动AI 发出工具调用请求代码执行工具Observation观察代码将工具执行结果反馈给 AI核心循环代码async send(text: string): Promisestring { this.history.push({ role: user, content: text }); for (let i 0; i MAX_ROUNDS; i) { const result await this.client.sendMessage(this.history, options); this.history.push({ role: assistant, content: result }); if (!result.functionCall) { return result.text ?? ; } const { name, args } result.functionCall; const toolResult await this.toolRegistry.execute(name, args); this.history.push({ role: tool, content: JSON.stringify({ name, result: toolResult }), }); } throw new Error(Max tool call rounds exceeded); }实际运行示例用户帮我看看当前目录有什么文件然后统计代码行数 第 1 圈AI → 执行 ls -la → 代码返回结果 第 2 圈AI → 执行 wc -l src/*.ts → 代码返回结果 第 3 圈AI → 返回文本总结 → 循环结束 ✅MAX_ROUNDS 是安全阀防止 AI 死循环。3.5 工程化原则拥有 Agent Loop 后Agent 已经能自主运行但要真正可用还需要关注以下工程化原则。工具设计从 “万能胶” 到 “手术刀”不要只提供一个 run_shell_command 万能工具而应该设计专门的工具read_file支持分页读取避免大文件直接撑爆上下文edit_file通过 old_string → new_string 的方式修改代码比让 AI 生成 shell 命令更安全且可靠list_directory返回结构化的 JSON 列表包含文件大小和类型工具越原子化、越结构化Agent 运行的成功率就越高。上下文注入给 Agent 戴上 “扩增实境眼镜”在每轮对话启动前自动采集环境信息并注入到 Prompt 中当前工作目录 (CWD)文件列表 (File List)当前时间 (Timestamp)这样 Agent 一开始就知道自己在哪里、“手头有什么”不需要先花一轮工具调用去探索环境。显示优化让 “黑盒” 变透明Agent 在执行工具时应该给用户清晰的反馈interface ToolExecuteResult { data: unknown; // LLM 需要的结构化原始数据 displayText?: string; // 用户在终端看到的友好提示 }比如执行 shell 命令时显示 $ ls -la读取文件时显示 Read src/index.ts (lines 1-20)而不是把原始 JSON 甩给用户。指令优化从 “聊天” 到 “工作”系统提示词对 Agent 的行为影响巨大为开发者工具场景应注意强制要求禁止废话直接输出结果角色定位明确自己是一个交互式 CLI Agent思考链鼓励在调用工具前进行简短的推理4、进阶架构4.1 上下文管理上下文窗口是 Agent 的工作记忆但它有硬性限制。对话越长、工具调用越多token 消耗越快。为什么需要上下文管理问题说明Token 限制每个模型有上下文窗口上限如 128K tokens超出就截断成本Token 数量直接决定 API 费用历史越长越贵速度输入 token 越多模型响应延迟越高常见策略策略 1滑动窗口只保留最近 N 轮对话丢弃更早的消息。function slidingWindow(history: Message[], maxTurns: number): Message[] { if (history.length maxTurns * 2) { return history; } const systemPrompt history[0]; const recentMessages history.slice(-(maxTurns * 2)); return [systemPrompt, ...recentMessages]; }优点实现简单效果直接。 缺点早期信息完全丢失。策略 2摘要压缩让 LLM 把旧的对话历史压缩成一段摘要。原始历史5000 tokens 用户问了天气 → AI 查了天气 → 用户问了新闻 → AI 查了新闻 → ... 压缩后200 tokens 用户先查了深圳天气25°C 晴然后查了今日科技新闻共 3 条 接着要求将新闻翻译成英文。优点保留关键信息压缩比高。 缺点压缩本身消耗 token且可能丢失细节。策略 3RAG 检索增强不把所有信息都塞进上下文而是存到外部知识库需要时按需检索。用户提问上次讨论的数据库方案是什么 1. 把问题转成向量 → 去向量数据库检索 2. 找到相关的历史片段 → 注入当前上下文 3. LLM 基于检索结果回答优点上下文永远保持精简可以记住无限量的历史。 缺点需要额外的向量数据库基础设施。策略组合实际项目中通常组合使用┌─────────────────────────────────────────────┐ │ 1. 系统提示词 (始终保留) │ │ 2. 压缩摘要旧历史 (摘要压缩) │ │ 3. 检索到的相关知识片段 (RAG) │ │ 4. 最近 N 轮对话 (滑动窗口) │ │ 5. 当前用户输入 (始终保留) │ └─────────────────────────────────────────────┘上下文管理没有银弹需要按场景组合不同策略。4.2 MCP 协议每个工具都要写一套定义→解析→执行的胶水代码。工具一多维护成本爆炸。MCP 就是为解决这个问题而生的标准化协议。MCP 解决的问题没有 MCP 时Agent A 对接 GitHub → 写一套 GitHub 工具定义 执行逻辑 Agent A 对接 Slack → 写一套 Slack 工具定义 执行逻辑 Agent B 对接 GitHub → 再写一套跟 A 的还不一样 ...M 个 Agent × N 个工具 M × N 套集成代码。有了 MCPAgent A ─┐ ┌─ GitHub MCP Server Agent B ─┤── MCP 协议 ──────┤─ Slack MCP Server Agent C ─┘ (标准接口) └─ 数据库 MCP ServerM N 套代码就够了。MCP 的核心能力MCP 定义了三种核心原语Tools (工具)Agent 可以调用的可执行函数让模型执行操作Resources (资源)Server 暴露给 Agent 的只读数据让模型读取上下文Prompts (提示词)Server 提供的预定义 Prompt 模板复用高质量的指令MCP 架构┌─────────────────────────────────────────────────┐ │ Host │ │ (Agent 应用) │ │ │ │ ┌────────────┐ ┌────────────┐ │ │ │ MCP Client │ │ MCP Client │ ... │ │ └─────┬──────┘ └─────┬──────┘ │ └─────────┼───────────────┼───────────────────────┘ │ MCP 协议 │ MCP 协议 ▼ ▼ ┌────────────┐ ┌────────────┐ │ MCP Server │ │ MCP Server │ │ (GitHub) │ │ (Database) │ └────────────┘ └────────────┘MCP 通信过程Agent(Host) MCP Client MCP Server │ │ │ │ 1. 启动时 │ ── initialize ──▶ │ │ │ ◀── 工具列表 ──── │ │ │ │ │ 2. 用户提问 │ │ │ ──查 GitHub issue─▶ │ │ │ │ │ │ 3. LLM 决定调工具 │ │ │ ── tool_call ──────▶ │ ── execute ────▶ │ │ │ ◀── result ───── │ │ ◀── tool_result ───── │ │ │ │ │ │ 4. LLM 生成回复 │ │ │ ◀── 返回给用户 │ │4.3 Sub-Agent 模式单 Agent 面临两个核心瓶颈上下文污染搜索代码的中间结果、测试日志等占满上下文和任务过杂需要在不同类型的工作间反复切换。Sub-Agent 模式通过分工协作来解决这些问题。Sub-Agent 架构用户帮我调研 React 和 Vue 的优缺点然后写一个技术选型报告 ┌──────────────┐ │ 主 Agent │ ← 理解任务、拆分、汇总 │(Orchestrator)│ └───────┬──────┘ ┌─────────┼─────────┐ ▼ ▼ ▼ ┌───────────┐ ┌──────────┐ ┌──────────┐ │调研 Agent │ │调研 Agent│ │写作 Agent│ │ (React) │ │ (Vue) │ │ (报告) │ └───────────┘ └──────────┘ └──────────┘每个子 Agent有自己独立的上下文——互不干扰有自己专属的工具集——搜索 Agent 有搜索工具写作 Agent 有文件工具做完后只返回结果——不带过程中的废料Sub-Agent 定义每个 Sub-Agent 通常由以下元素组成name: code-reviewer # 唯一标识 description: Reviews code... # 描述信息用于主 Agent 决策时选择 tools: [read_file, list_dir] # 工具白名单 model: model-name # 可覆盖默认模型 maxTurns: 15 # 限制最大工具调用轮数 prompt: | # 专属系统提示词 You are a code reviewer specialized in identifying: - Security vulnerabilities - Performance issues ...关键设计要点工具白名单限制子 Agent 只能用必要的工具降低风险独立模型可以为不同子任务选择最合适的模型轮数限制每个子 Agent 有自己的 maxTurns防止某个子任务失控执行流程主 Agent 决定委派任务 │ ▼ 1. 根据任务描述选择合适的 Sub-Agent │ ▼ 2. 构建受限的工具集只给白名单中的工具 │ ▼ 3. 创建新的 Chat 实例独立上下文 │ ▼ 4. Sub-Agent 执行任务在自己的 Agent Loop 中 │ ▼ 5. 返回结果给主 Agent只有最终结果没有中间过程4.4 Agent SkillTool 是单个动作但很多实际任务是一套固定流程需要多个 Tool 配合加上特定的 prompt 指引。Skill 就是把这套流程打包成一个可复用的快捷操作。Skill 的本质一个 Skill prompt 模板 元数据。┌─────────────────────────────────────────────────────┐ │ Agent Skill │ │ │ │ 元数据: │ │ name / description / trigger │ │ │ │ Prompt 模板: │ │ 作为 prompt 注入主对话上下文 │ │ 指导 Agent 按步骤执行任务 │ └─────────────────────────────────────────────────────┘Skill 与 Tool、Sub-Agent 的区别ToolSkillSub-Agent粒度单个动作一套完整流程独立的子任务触发LLM 自动选择用户命令 / LLM 调用LLM 调用执行方式直接执行函数prompt 注入主对话上下文派生独立 Chat 实例上下文共享主 Agent 上下文共享主 Agent 上下文独立上下文Skill 定义示例name: commit description: Generate a conventional commit message for staged changes trigger: /commit prompt: | Analyze the staged changes and generate a commit message following the Conventional Commits specification. The commit message should: 1. Start with a type: feat, fix, docs, style, refactor, test, or chore 2. Include a scope in parentheses if applicable 3. Have a concise subject line (max 50 chars) 4. Include a body if the change is complex两种触发方式方式一用户命令触发用户直接输入触发命令如 /commit系统匹配到对应 Skill将 prompt 注入对话const skillMatch skillRegistry.match(userInput); if (skillMatch) { const injectedPrompt skillLoader.load(skillMatch.skill, skillMatch.args); const reply await chat.send(injectedPrompt); }方式二LLM 自主调用将 Skill 包装成一个 ToolLLM 在 Agent Loop 中可以自主决定调用{ tool: skill, parameters: { skill_name: commit, task: 为当前暂存的更改生成提交信息 } }Skill 的价值场景不用 Skill用 Skill重复性流程用户每次手动描述每一步一条命令一键搞定领域知识用户需要知道具体步骤和参数Skill 封装了专家经验自动执行团队协作每个人的操作方式不一致统一的 Skill 定义保证流程一致性4.5 如何选择Tool vs Skill vs Sub-Agent需求来了 │ ├─ 是单个原子操作读文件、发请求、执行命令 │ └─ → 用 Tool │ ├─ 是固定流程每次步骤一样只是输入不同 │ └─ → 用 Skill │ ├─ 需要独立上下文中间过程会污染主对话 │ └─ → 用 Sub-Agent │ └─ 需要不同模型子任务适合用专门的模型 └─ → 用 Sub-Agent具体场景对照场景推荐方案理由读取一个文件Tool单个原子操作生成 Git commit messageSkill固定流程查 diff → 写 message → 提交调研某个技术方案Sub-Agent需要大量搜索中间结果会污染主上下文执行代码审查Sub-Agent需要独立上下文可能需要不同模型格式化代码Tool单个操作调用 formatter 即可生成单元测试Skill固定流程读源码 → 分析 → 生成测试同时调研 3 个竞品Sub-Agent × 3并行执行各自独立上下文组合使用实际项目中这三者经常组合使用用户输入 /review触发 Skill │ ▼ Skill prompt 指导主 Agent 拆分任务 │ ├─ Sub-Agent 1代码审查使用 read_file Tool ├─ Sub-Agent 2安全检查使用 grep、read_file Tool └─ Sub-Agent 3性能分析使用 run_command Tool │ ▼ 主 Agent 汇总三个 Sub-Agent 的结果生成报告5、总结本文覆盖了从 LLM 到 Agent 的完整知识体系基础概念LLM 是无状态的文字接龙机器通过 API 调用Context 是你发送的全部信息历史 提示词 工具结果记忆在数组里而不是 AI 脑子里Tool Calling 让 LLM 从只能说进化到能动手但 LLM 只负责决策代码负责执行构建过程四个阶段单次对话 → 调 API一问一答多轮对话 → 客户端维护 history 数组工具调用 → 注册工具LLM 决定何时调用Agent Loop → ReAct 循环自动多步执行进阶架构上下文管理滑动窗口 摘要压缩 RAG按场景组合MCP 协议标准化工具对接M × N → M NSub-Agent独立上下文的分工协作Skill可复用的流程模板选择原则原子操作用 Tool固定流程用 Skill需要独立上下文用 Sub-Agent那么如何学习大模型 AI 对于刚入门大模型的小白或是想转型/进阶的程序员来说最头疼的就是找不到系统、全面的学习资源要么零散不成体系要么收费高昂白白浪费时间走弯路。今天就给大家精心整理了一份全面且免费的AI大模型学习资源包覆盖从入门到实战、从理论到面试的全流程所有资料均已整理完毕免费分享给各位核心包含AI大模型全套系统化学习路线图小白可直接照做、精品学习书籍电子文档、干货视频教程、可直接上手的实战项目源码、2026大厂面试真题题库一站式解决你的学习痛点不用再到处搜集拼凑扫码免费领取全部内容1、大模型系统化学习路线学习大模型方向比努力更重要很多小白入门就陷入“盲目看视频、乱刷资料”的误区最后越学越懵。这里给大家整理的这份学习路线是结合2026年大模型行业趋势和新手学习规律设计的最科学、最系统从零基础到精通每一步都有明确指引帮你节省80%的无效学习时间少走弯路、高效进阶。2、大模型学习书籍文档理论是实战的根基尤其是对于程序员来说想要真正吃透大模型原理离不开优质的书籍和文档支撑。本次整理的书籍和电子文档均由大模型领域顶尖专家、大厂技术大咖撰写涵盖基础入门、核心原理、进阶技巧等内容语言通俗易懂既有理论深度又贴合实战场景小白能看懂程序员能进阶为后续实战和面试打下坚实基础。3、AI大模型最新行业报告无论是小白了解行业、规划学习方向还是程序员转型、拓展业务边界都需要紧跟行业趋势。本次整理的2026最新大模型行业报告针对互联网、金融、医疗、工业等多个主流行业系统调研了大模型的应用现状、发展趋势、现存问题及潜在机会帮你清晰了解哪些行业更适合大模型落地哪些技术方向值得重点深耕避免盲目学习精准对接行业需求。值得一提的是报告还包含了多模态、AI Agent等前沿方向的发展分析助力大家把握技术风口。4、大模型项目实战配套源码对于程序员和想落地能力的小白来说“光说不练假把式”只有动手实战才能真正巩固所学知识将理论转化为实际能力。本次整理的实战项目涵盖基础应用、进阶开发、多场景落地等类型每个项目都附带完整源码和详细教程从简单的ChatPDF搭建到复杂的RAG系统开发、大模型部署难度由浅入深小白可逐步上手程序员可直接参考优化既能练手提升技术又能丰富简历为求职和职业发展加分。5、大模型大厂面试真题2026年大模型面试已从单纯考察原理转向侧重技术落地和业务结合的综合考察很多程序员和新手因为缺乏针对性准备明明技术不错却在面试中失利。为此我精心整理了各大厂最新大模型面试真题题库涵盖基础原理、Prompt工程、RAG系统、模型微调、部署优化等核心考点不仅有真题还附带详细解题思路和行业踩坑经验帮你精准把握面试重点提前做好准备面试时从容应对、游刃有余。6、四阶段精细化学习规划附时间节点可直接照做结合上述资源给大家整理了一份可直接落地的四阶段学习规划总时长约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 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】