本文整理了腾讯Agent开发面试中的核心问题及解答，涵盖模型输出失败处理、RAG检索、向量数据库应用、Agent架构设计等关键知识点。文章深入剖析了面试官追问的底层逻辑，并提供了工业界兜底方案。适合准备大模型面试或从事Agent相关项目的开发者学习，助力提升工程化能力和系统设计思维。

一场面试，十几个硬核问题，横跨模型可靠性、RAG检索、工具扩展、代码生成……我把面试官的“灵魂拷问”和我的思考完整拆解给你看。

写在前面

两个月前，我投递了腾讯Agent开发方向。说实话，简历能过筛选已经让我有点意外了。但真正让我头皮发麻的，是接下来的两轮技术面试。

一面问得广，二面挖得深。面试官没有问“什么是Agent”这种入门题，而是直接抛出了生产环境里才会遇到的真实痛点：模型输出失败了怎么办？RAG召回率怎么评估？AI决策冲突了谁说了算？

这篇文章，我把两轮面试的所有问题、我的回答、以及事后复盘到的“更优解”完整整理出来。不管你是准备面试，还是正在做Agent相关的项目，相信都能从中找到共鸣和启发。

第一面：基础纵深，一个都别想蒙混过关

一面面试官很年轻，说话语速快，上来没有寒暄，直接开问。

1. AI Agent项目中，模型输出失败可以分为哪些情况？

我当时把失败分成了三大类：

• 格式失败：模型没有按照约定的JSON或结构化格式返回，比如多了前后缀、少了闭合括号。
• 内容失败：模型输出了“我无法回答这个问题”或者无关内容，甚至直接幻觉编造。
• 调用失败：API超时、限流、服务端5xx错误等基础设施层面的问题。

面试官追问了一句：“还有没有一种失败叫‘逻辑自洽失败’？” 我愣了一下，他解释说：“比如模型输出了一个行动计划，但前后步骤互相矛盾。” 后来我查资料才知道，这在多步推理的Agent中很常见——模型第一步说“先查数据库”，第二步却直接“根据用户输入生成答案”，跳过了查询环节。

复盘建议：除了上面三类，建议补充推理链路断裂和工具调用顺序错误。面试官其实在考察你对Agent执行全流程的认知颗粒度。

2. 如何处理模型输出失败？有哪些策略和工业界兜底方案？

我回答了重试、降级、兜底回复三层策略：

• 重试：指数退避重试，对于格式错误可以用校验+反馈修正（把错误信息塞回prompt让模型自己改）。
• 降级：如果模型持续失败，跳过当前Agent节点，使用默认策略或规则引擎兜底。
• 兜底回复：最终给用户一句“暂时无法处理，已转人工”或保存上下文待后续处理。

面试官点头，然后补了一个工业界常见做法：输出结构化校验层（Pydantic/Schema验证），在模型输出后、业务逻辑前，做一个强校验。如果校验失败，不直接抛错，而是走“修复-重试”闭环。另外，对于关键业务，会做双模型交叉验证——用一个小模型快速验证大模型的输出是否合理。

这个回答让我意识到，生产环境的容错设计远比想象中复杂。

3. RAG检索中，数据如何进行向量索引？

这题相对基础。我讲了从原始文档到向量索引的标准流程：

1. 文档解析（PDF/Word/Markdown转纯文本）
2. 文本分块（Chunking）
3. 调用Embedding模型（如BGE、OpenAI embedding）生成向量
4. 存入向量数据库（Milvus、Qdrant、Pinecone等），同时建立倒排索引做关键词检索（混合检索）
5. 构建索引参数（HNSW、IVF等算法）

面试官追问了索引构建时的内存和速度权衡，我说了HNSW的参数调优（ef_construction、M值），他基本满意。

4. 文本分块的长度一般是多少？如何权衡？

我回答：常用chunk size在256~1024 tokens之间。权衡点有三个：

• 检索精度：块太小，语义不完整，召回的相关内容可能缺少上下文；块太大，噪声多，且超过Embedding模型的最大长度限制。
• 模型上下文窗口：如果每个chunk太大，塞进LLM时总token数容易超限。
• 语义边界：尽量按段落、标题或句子边界切，而不是硬截断。可以用LangChain的递归字符分割器或者语义分割模型。

面试官追问了一句：“如果文档里有表格和代码块，你怎么办？” 我承认没做特殊处理，他提示说可以单独走表格解析器或代码摘要提取。这块是个加分点，建议大家补充。

5. 为什么使用向量数据库？与MySQL的区别是什么？PostgreSQL对Agent有什么提升？

这个问题有层次：

• 为什么用向量数据库：因为需要做近似最近邻（ANN）搜索，MySQL的B+树索引无法高效处理高维向量的距离计算。向量数据库通过HNSW、IVF等算法，能在亿级数据中实现毫秒级召回。
• 与MySQL的区别：MySQL是精确查询（等值、范围、全文），向量数据库是相似性查询（余弦相似度、欧氏距离）。两者可以共存：MySQL存元数据，向量库存embedding，检索时先向量召回再MySQL过滤。

然后面试官抛出一个新东西：PostgreSQL对Agent有什么提升？ 我当时只答了pgvector扩展，让PostgreSQL也能存向量，省去维护两个数据库的麻烦。面试官补充说，PostgreSQL的事务特性和行级锁对于Agent的多轮对话状态管理很有价值——多个Agent同时写同一个会话上下文时，能避免脏写。另外，PostgreSQL的JSONB字段可以直接存Agent的tool call记录，查询和回溯都很方便。

这个回答让我发现，向量数据库不是银弹，传统关系型数据库在很多场景下依然不可替代。

6. 如何评估RAG的召回率？常用指标有哪些？

我回答了信息检索领域的标准指标：

• Recall@K：前K个检索结果中包含相关文档的比例。K一般取5或10。
• MRR（Mean Reciprocal Rank）：第一个相关文档的排名的倒数取平均，适合“只要一个正确答案”的场景。
• NDCG（Normalized Discounted Cumulative Gain）：考虑排序位置和相关性等级（比如高度相关、部分相关、不相关），适合有分级标注的场景。

面试官追问：怎么在实际项目中快速标注测试集？ 我答了两种：一是人工抽样标注，二是用大模型（如GPT-4）自动标注然后人工抽检。他补充说还可以用点击日志作为隐式反馈——用户点开哪个chunk，就认为那个chunk相关。

7. 如何处理大模型输出死循环问题？兜底策略是什么？如何让模型生成更优内容？

死循环在Agent的ReAct模式中非常常见。我的回答：

• 检测：设置最大迭代次数（比如10步），或者检测重复的observation内容（连续两次一样就判定死循环）。
• 兜底：触发最大步数后，强制终止并返回已有结果或提示用户简化问题。
• 优化：在prompt中明确要求“每步必须推进状态，禁止重复相同动作”；另外可以在状态中记录历史动作，让模型知道“我已经做过这些了”。

面试官追加了一个技巧：给模型增加一个“思考是否陷入循环”的元认知步骤——每执行3步后，让模型自己判断“我是不是在原地打转？”如果是，主动换策略。这其实就是Meta-Prompt的一种应用。

8. 如何检测输出重复率？有哪些方法？

我说了两类：

• 字面重复：用n-gram重合度、Jaccard相似度、或者计算连续输出的embedding余弦相似度。设置阈值，超过就认为重复。
• 语义重复：用BERT或RoBERTa做语义相似度判断。

面试官补充了工程上的细节：流式输出时可以做滑动窗口实时检测，一旦发现连续几轮输出相似度过高，提前打断，而不是等完整输出完再后处理。

9. 如何设计Agent架构支持工具可插拔扩展？原理是什么？

这题考察系统设计能力。我的思路：

• 注册中心模式：每个工具实现统一的接口（name、description、input_schema、execute方法），启动时动态扫描并注册到工具管理器。
• 配置文件驱动：用YAML/JSON定义工具列表，Agent根据用户意图从注册表中匹配工具。
• 原理：利用依赖注入和反射/动态加载（Python的importlib或Java的SPI机制）。Agent只依赖工具接口抽象，不依赖具体实现，新增工具时无需修改Agent核心代码。

面试官追问：“如果要支持工具的热加载（不重启服务），怎么做？” 我说可以用插件目录监听（watchdog）或者基于消息队列动态拉取工具定义。他补充说工业界也有用gRPC调用独立工具服务的方式，工具服务可以独立升级。

10. Agent和大模型（LLM）的核心区别是什么？

我的理解：

• LLM：一个静态的文本生成模型，接收输入，输出文本。没有状态记忆（除了上下文窗口），没有行动能力，没有外部交互。
• Agent：以LLM为核心控制器，但拥有记忆、规划、工具使用、反思四大能力。Agent可以调用外部API、检索知识库、执行代码，并根据环境反馈调整下一步行动。

面试官总结了一句很精辟的话：“LLM是大脑，Agent是大脑+手脚+记忆。”

11. MCP（模型上下文协议）解决了什么问题？

MCP是Anthropic提出的开放协议。我说了核心价值：

• 标准化工具接口：以前每个Agent框架（LangChain、Semantic Kernel等）都有自己的工具定义方式，切换框架成本高。MCP定义了统一的tool schema和通信协议。
• 上下文共享：MCP支持在多个Agent之间共享上下文信息（比如用户偏好、会话历史），避免重复传递。
• 服务发现：Agent可以动态发现可用的MCP Server提供的工具。

面试官补充了一个点：MCP其实也解决了安全性问题——工具调用可以通过MCP Server做权限校验和审计日志，而不是让Agent直接持有API密钥。

12. Skills和Function Call的区别是什么？

这个问题我答得不太好，当时只说了表面的区别。回来后查资料：

• Function Call（OpenAI等模型提供的能力）：模型输出一个结构化的函数调用请求（函数名+参数），由外部执行并返回结果。它是一次性的、无状态的。
• Skills（比如AutoGPT的Skills、LangChain的Toolkits）：是一组相关功能的封装，可以包含多个步骤、有状态、甚至可以调用其他Skill。Skills更偏向组合和编排，而Function Call是原子能力。

面试官提醒：Skills通常还包含说明文档和示例，模型可以阅读理解后使用，而Function Call依赖预先定义好的schema。

第二面：项目拷打，场景题一个比一个狠

二面面试官显然看了我的简历，每个问题都贴着我的项目经历问。

1. 实习拷打（略）

这部分主要聊了我之前的实习内容，面试官会不断追问细节，验证项目是否真实做过。建议大家对自己的项目要深挖到每一行代码的决策理由。

2. 你们有没有遇到Agent之间“决策冲突”的情况？比如设计和代码生成不一致，是怎么解决的？

我们项目里有两个Agent：一个负责设计（输出方案），一个负责实现（生成代码）。冲突经常发生——设计Agent说用Redis缓存，代码Agent却直接用数据库查询。

我们的解决方案：

• 共享上下文窗口：代码Agent启动时，先加载设计Agent的输出作为“约束条件”。
• 冲突检测规则：预定义了一些常见的冲突模式（比如缓存方案vs直查数据库），如果检测到冲突，暂停执行，交由一个仲裁Agent判断。
• 最终方案：引入单一事实来源——设计文档经评审后不可变，代码Agent只能遵从，如果确实需要调整，必须走变更流程。

面试官问：“仲裁Agent如果也错了呢？” 我回答可以降级为人工确认。他笑了笑说：“所以最终兜底还是人。”

3. 你们为什么选择“技术方案驱动”，而不是直接让AI从PRD出码？

这是个好问题。我们的理由是：

• PRD（产品需求文档）通常含混，有大量隐含假设和业务约束，直接出码会产出大量幻觉和错误逻辑。
• 技术方案驱动：先让AI根据PRD生成一个技术方案（包含架构、模块划分、数据流、接口定义），人工确认后再生成代码。这样把错误前置，减少后期返工。
• 效果：技术方案阶段的修正成本比代码阶段低一个数量级。

面试官补充说，这其实也是Chain-of-Thought在工程上的体现——强制模型先思考再行动。

4. 你们.catpaw/rules这套知识库，和像OpenClaw这种基于RAG的memory，有什么区别？

我解释了我们的设计：

• .catpaw/rules：是确定性规则库，存储的是“必须遵守的约束”（比如代码规范、API命名约定、数据库设计原则）。它是结构化、版本化的，按路径匹配生效。
• OpenClaw的RAG memory：存储的是非结构化经验（比如历史对话、代码片段、踩坑记录），通过相似性检索召回。

区别：Rules用于“强制约束”，RAG用于“参考建议”。Rules的优先级高于RAG检索结果。

面试官追问：“如果规则和RAG结果冲突呢？” 我们设计的是规则优先——因为规则来自架构师沉淀，代表强制标准；RAG只是参考。

5. 如果知识库内容过多，AI也会有上下文压力，你们是怎么做裁剪或者命中的？

我们用了两阶段检索：

1. 粗筛：基于路径和文件名规则，只加载当前任务相关的规则文件（比如修改user模块，只加载user相关的rules）。
2. 精剪：对于每个规则文件，按“是否包含当前代码中的关键词”做二次过滤。此外，我们给每条规则加了触发条件字段，AI只在条件满足时才注入该规则。

面试官认可了这个方案，同时建议可以尝试动态重要性评分——让一个轻量模型给每条规则打分，只保留Top-K。

6. 你们有没有做embedding检索？

做了。但不是用于rules（rules是确定性匹配），而是用于历史对话检索和相似代码片段检索。比如用户问“以前有没有遇到过这种bug”，我们用embedding从历史issue库中召回相似案例。

面试官追问：“embedding检索的召回率和精确率大概多少？” 我说没做严格评测，只做了人工抽检。他建议至少要跑一个Recall@10的评测，不然上线后心里没底。

7. 如果知识库里的内容是错的或者过期了，会不会对AI产生误导？你们怎么治理这个问题？

这是个大坑。我们遇到过：规则库里有一条“禁止使用async/await”，但那是两年前的技术决策，后来已经废弃了。AI遵守了这条规则，生成的代码全是回调风格，被Code Review打回。

治理方案：

• 版本标记：每条规则带生效时间范围和版本号，AI在生成代码时会检查规则是否适配当前代码库基线。
• 反馈闭环：当开发者发现AI遵守了错误规则时，可以一键“报告规则错误”，触发规则审核流程。
• 规则保鲜：定期（每月）用大模型自动扫描规则库，标记出可能与当前代码实践不符的规则，人工复核。

面试官补充了一个做法：规则的健康度评分——统计每条规则被AI遵循的次数和被人纠正的次数，得分过低的规则自动降级或删除。

8. 在一个非常大的存量项目里（比如几十万行代码），你们是怎么让AI快速理解项目结构的？

我们做了两件事：

• 项目结构摘要：预先生成一个项目拓扑图（目录树 + 每个模块的核心职责 + 关键入口文件），压缩成几千tokens作为AI的system prompt的一部分。
• 按需加载源码：AI不直接看全部代码，而是先读摘要，确定要修改哪个模块后，再通过工具动态读取该模块的关键文件。

面试官问：“摘要怎么保证不过时？” 我们通过CI流程：每次代码合并后自动重新生成摘要，确保AI永远看到最新的项目结构。

9. 你们现在AI出码留用率是50%+，那剩下50%主要问题出在哪里？

留用率是指：AI生成的代码经过人工审核后，最终合并到主干的占比。我们统计过，剩下50%的问题分布：

• **30%**：逻辑正确但不符合业务隐含约束（比如没考虑某些边界条件）
• **20%**：使用了已废弃的API或过时的写法
• **15%**：性能问题（比如N+1查询、没有加索引）
• **15%**：代码风格不一致（虽然我们做了规则约束，但仍有漏网）
• **20%**：完全错误的幻觉代码（比如调用了不存在的函数）

面试官追问：“这50%里有多少可以通过改进提示词解决，多少需要改系统设计？” 我说大概一半一半，有些问题是prompt可以优化的（比如明确边界条件），但像API废弃这种需要实时知识库配合。

10. 在复杂业务场景下，AI出码质量下降，你觉得是什么问题？

我总结了三个根因：

• 上下文窗口不足：复杂业务往往涉及多个模块，单个对话的上下文塞不下全部信息，AI只能看到局部，做出的决策就是局部最优但全局错误。
• 推理深度不够：模型在复杂逻辑链上容易“短路”，比如需要5步推理，模型只做了3步就给出答案。
• 缺乏反事实思考：AI很少主动问“如果这个条件不满足会怎样？”，所以边界条件处理得差。

面试官补充了一个观点：模型的能力边界——有些复杂场景可能已经超出了当前模型的能力上限，这时候不应该硬推AI出码，而是让人工介入。

11. AI有没有出现过“看起来对，但其实逻辑是错的”这种情况？

太多例子了。我举了一个经典案例：AI写了一个函数判断用户是否有权限，代码跑起来完全正常，但逻辑是“只要用户不是admin就拒绝”，而产品需求是“admin和owner都有权限”。因为测试用例只测了admin和普通用户，没测owner，所以测试全过。上线后owner角色无法使用，紧急回滚。

面试官说这就是测试用例覆盖不全和AI缺乏深层语义理解的结合问题。我们的改进措施：要求AI生成代码的同时，必须生成一个“逻辑验证清单”，列出所有可能的角色和预期结果，人工快速验证。

12. 你们有没有做过代码diff级别的控制，比如限制AI修改范围？

做过。我们在工具层实现了一个修改范围沙箱：

• AI在生成代码前，必须先声明“我打算修改哪些文件的哪些行范围”。
• 系统校验这个范围是否超出权限（比如不允许修改核心框架文件）。
• 生成代码后，再次校验实际diff是否在声明的范围内。超出范围的部分自动丢弃并告警。

这个设计防止了AI“好心办坏事”——有时候AI会顺手改掉看似无关但实际关键的代码。

面试官问：“如果AI需要修改的文件不在声明范围内怎么办？” 那就走一个“扩展申请”流程，AI需要重新声明理由，通过后才能执行。

13. 你们基于Playwright做自动化测试，那测试用例是怎么保证覆盖率的？有没有评估指标？

我们做了：

• 覆盖率指标：行覆盖率、分支覆盖率、关键路径覆盖率（人工定义的核心业务流程）。
• 用例生成：让AI根据PRD和代码变更自动生成测试用例，然后人工筛选。
• 变异测试：用工具自动修改代码（比如把>改成<），看测试用例能否发现。如果发现不了，说明测试用例质量不足。

面试官最后点评：“你们在工程化上想得比较深了，但AI出码留用率50%还有很大提升空间，建议把错误分类做更细的统计，然后逐个击破。”

写在最后：这些面试题背后的“潜台词”

两轮面试下来，我发现腾讯的面试官并不是在考“背答案”，而是在考察你有没有真正趟过生产环境的坑。

一面更多是基础能力检验，但每个问题都可以往深处挖——比如模型输出失败，不是简单说“重试”，而是要想到校验层、降级策略、双模型验证。

二面则完全围绕你实际做过的项目展开，每一个追问都在探测你的问题边界：你知道为什么这么做吗？遇到极端情况怎么办？数据说话了吗？

如果你也在准备Agent方向的面试，我建议你：

1. 手写一个简单的Agent框架，哪怕只有几百行代码，你会对工具调用、记忆、规划有完全不同的理解。
2. 多踩坑，多记录。把每次模型幻觉、死循环、决策冲突的案例整理成自己的“错题本”。
3. 关注工程落地，而不仅仅是模型效果。面试官非常看重RAG的评测、知识库治理、代码diff控制这些“脏活累活”。

那么如何学习大模型 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%免费】