大模型和智能体这两年热度一直没降但真正让我觉得“时机到了”的是最近开始有成批成批的读者来问同一个问题我想系统学大模型和智能体但打开教程列表就头大先学什么、后学什么、学到什么程度算入门完全没概念。这篇超详细的学习大纲就是冲着这个问题来的。我给它的定位不是“又一篇科普”而是一份能照着执行的学习路线从最底层的大模型原理到微调和部署走到智能体的系统设计和安全审计最后落到实战项目和面试准备。内容密度比较高适合两种人一是准备转行做AI应用开发的工程师二是已经在做业务系统、想用大模型和智能体改造现有产品的技术负责人。零基础也可以跟但建议把前置知识部分多花点时间。我有一个判断先放在开头这个领域最大的障碍不是技术本身而是学习顺序。很多人卡在两三天就劝退问题不在智商在于一上来就看Transformer论文、折腾CUDA环境把自己的热情提前消耗光了。所以我会把整个学习路径拆成阶段每个阶段都有明确目标和完成标志。1. 学之前先弄清楚的大方向1.1 大模型和智能体到底是什么关系很多人分不清大模型和智能体的边界这其实很正常因为两者在圈子里经常被混着说但混着说会导致学习路径混乱。大模型准确说是LLMLarge Language Model本质上是一个概率模型。它的核心能力是给定一串文字预测下一个字或下一段字最可能是什么。你可能觉得这听起来很简单但就是这个“下一词预测”在参数量和数据量足够大的情况下涌现出了理解、推理、总结、翻译、代码生成这些能力。你可以把大模型理解为一个人的“大脑”它存储了大量的知识模式但大脑不会自己行动得有人指挥它。智能体Agent则是在大模型这个“大脑”外面加上感知、规划、记忆、工具使用的完整系统。它会根据目标拆解任务调用工具比如搜索、计算器、API、数据库根据执行结果调整下一步计划然后循环往复直到完成目标。所以学习路径应该是先弄明白大脑怎么工作再去研究怎么给大脑配上手脚和身体。这也是我这篇大纲的基本逻辑。网上一堆“三小时搞定智能体开发”的教程让你在Coze或者Dify上拖几个节点拼一个机器人。那当然可以很快但你会发现离开平台自己写代码就抓瞎因为你不懂智能体内核——循环、记忆、工具调用、容错。真正稳的路径是先学大模型再学智能体顺序不能反。1.2 你应该自学、报班还是跟着开源社区走先说结论自学完全可行但前提是你愿意忍受信息筛选的折磨。报班的价值不是“课程内容”本身大部分课程内容在免费文档里都能找到报班主要帮你省掉两件事——找资料的时间和自我怀疑的时间。如果你选择自学我给你一个实体项目建议不要从“看论文”开始从“跑通一个本地模型”开始。原理部分可以边跑边学边学边补。一旦你把模型跑起来了会自然生出很多问题带着问题去学原理吸收效率是看着教程学的十倍。如果你决定报班也不是不行。大机构和小机构我都接触过选课标准就一条看它有没有真实的企业级项目而不是玩具demo。教你在公开数据集上跑一个文本分类这种项目面试官一眼就能看出成色。真正有价值的课是教你用大模型解决一个实际业务问题比如给企业做私有知识库问答、给客服系统做智能工单分类这种项目才扛得住面试追问。1.3 零基础需要补哪些底子哪些其实可以跳过这条我给最实际的建议。数学方面你不需要先把线性代数、概率论学完再动手。你需要的是“用到哪补到哪”。向量和矩阵运算要有概念因为模型的输入输出都基于向量表示注意力机制的QKV要看得懂公式因为这是Transformer的骨架梯度下降和反向传播知道大概原理就行排错的时候用得上。但你不必被复杂的数学证明拖住现在框架都帮你封装好了你调API的时候不需要手写反向传播。编程方面Python语法是必选项至少能写循环、函数、类、列表推导式能看懂装饰器。如果你之前是做Java、Go、C的后端那Python不复杂一周就能上手关键是要能熟练使用requests、pandas这种数据处理常用库。操作系统方面我建议你至少熟悉Linux的基础命令。后面部署模型、装CUDA、跑Docker十有八九是在服务器上做的。不需要成为运维专家但会看日志、会改环境变量、会用nohup挂后台进程这些日常操作要过关。这里有个特别重要的提醒不要在第一周就尝试把大模型的原理全部弄懂。我见过太多人倒在“Attention is All You Need”这篇论文上那篇论文的符号和公式对初学者不友好。正确的姿势是先会“用”再研究“懂”。2. 第一站把大模型的基本原理吃透2.1 从Transformer到GPT一条不那么痛苦的学习路线学大模型原理我不建议直接啃原始论文。我推荐一个顺序亲测有效。第一步先看一篇好的图解文章把Transformer的整体结构在脑子里建立图像。你要记住的是几个核心名词Embedding向量嵌入、位置编码、多头注意力、残差连接、LayerNorm、Feed-Forward层。不要深究细节但要知道数据在模型里是怎么流动的。第二步理解“预训练微调”这个范式。预训练就是让模型在海量无标注文本上做“填空”或“预测下一个词”这个阶段模型学会的是“语感”——语言的规律、知识的结构。微调是在预训练的基础上用少量有标签数据让模型适应特定任务。注意微调不是从零训练而是在已有能力上做“调优”。第三步去了解GPT系列为什么强大。GPT的架构其实比原版Transformer简化了只保留了Decoder部分。它真正厉害的地方在于三点模型规模大、训练数据多、训练目标统一生成式预训练。它的涌现能力——比如上下文学习In-Context Learning和思维链Chain-of-Thought——都是规模堆出来的副产物不是刻意设计的。这个过程如果你用两周时间完成我觉得节奏刚好。期间找一个5亿参数级别的小模型跑起来感受一下输入输出会极大降低恐惧感。2.2 预训练、微调和RAG三者的定位完全不同这是初学者最容易混淆的三件事我先用一句话做个粗暴区分预训练是“从零学说话”微调是“练口音和话术”RAG是“边说话边翻参考书”。预训练成本极高不是个人或者小公司该干的事。训练一个千亿参数的模型动辄需要数百张GPU跑几周甚至几个月成本用百万美元起步来计算。所以普通人做预训练更多是学术研究或者大厂的技术壁垒。你要知道预训练存在的意义但不需要自己上手做。微调是个人和中小团队可以尝试的方向。它的常见路径是拿一个开源基座模型比如Qwen、Llama系列用领域数据做增量训练。LoRA低秩适配进一步把微调成本降了下来它只训练一小部分额外参数几百块一张消费级显卡就能跑。微调适合的场景是让模型学会特定格式的输出、特定领域的术语、特定的情感和语气。RAG全称检索增强生成是目前企业落地最广的一种技术方案。它的核心思路把私域文档向量化存入数据库用户提问时先检索最相关的片段再把这些片段拼到Prompt里让模型生成回答。优点很明显实时更新知识不需要重新训练模型、降低幻觉风险、数据来源可追溯。选择逻辑是这样的如果你的目标是让模型更懂某个领域的“说话方式”应该微调如果你的目标是让模型回答某个领域的“具体事实”应该上RAG。两者不是对立的可以组合使用但绝大多数场景下RAG的性价比远高于微调。2.3 上下文长度是硬指标但别只看数字上下文长度Context Window指的是模型一次能“看到”多少文本。它决定了模型处理长文档、多轮对话、复杂代码文件的能力上限。现在很多模型把上下文做到了128K甚至200K看起来很长但实际使用中往往有一个隐性门槛——模型对长上下文的有效利用程度远没有达到标称水平。学术界有个著名的“Lost in the Middle”现象模型在输入超长时对处于中间位置的文本关注度最低。也就是说你把一个文档库的关键信息放在Prompt的中间模型可能完全忽略它。这个问题的工程启示是你设计Prompt时重要的指令要放在开头和结尾尤其是结尾位置对最终生成的“定调”影响最大。另外上下文长度和成本成线性关系。每次请求模型都要处理输入的所有TokenToken数量直接决定API费用和延迟。在实际系统中很少有人把整个文档库全塞进上下文而是用RAG先做筛选只把最相关的内容放进去。所以作为学习者你应该把上下文长度当成一个“上限值”而不是“日常值”时刻想着压缩信息密度。2.4 多模态大模型值得什么时候学多模态模型是指可以同时理解文本、图片、音频、视频的模型比如GPT-4V、Qwen-VL、Llava这些。学习多模态的时机我建议放单模态文本模型掌握之后。原因在于多模态模型的底层逻辑并没有脱离语言模型的范式。现在主流的多模态方案是把图片切块后转成视觉Token和文本Token拼在一起统一输入Transformer。结构上多了视觉编码器损失函数上多了对比学习损失但核心的Attention机制没变。你只要把单模态模型吃透了多模态的学习成本不会很高——你要补的只是视觉编码器的原理和不同模态对齐的方式。但多模态的工程价值非常高。很多实际场景天然需要多模态比如工业质检需要看图判断缺陷、智能客服需要识别用户上传的产品照片、内容审核需要图文联合判断。所以当你学完单模态后多模态是一个很自然的扩展方向它会让你的技能覆盖面瞬间变大。3. 第二站微调、RAG、提示词工程三板斧3.1 微调不是唯一的出路先学会判断该不该微调我见过太多项目上来就喊“我们要微调一个行业模型”结果一问数据量只有几千条。这个判断太草率了。决定是否微调有几个现实的前提条件。第一是数据量。微调效果和数据质量、数量的关系是硬性的。深度微调的话通常需要十万甚至百万量级的有效训练样本即使用LoRA我也建议至少准备数万条高质量数据否则很容易过拟合或者效果提升不明显。很多团队只有几千条数据做出来的效果还不如直接用Prompt加示例来得实在。第二是基座模型本身。如果你用的模型已经是通用能力很强的闭源模型你基本不需要微调因为它的知识面和指令遵循能力远超你微调一个开源小模型能得到的水平——除非你的数据非常特殊或者你有数据安全合规要求不能调用外部API。所以“先闭源API试跑再评估是否私有化微调”是一个稳妥的路径。第三是成本。微调不是一次性的模型上线后你还要持续评估、调参、增量更新。把整个微调链路稳定跑起来至少需要一个懂模型训练的工程师。如果团队没有这个条件我更建议用RAG方案。这不是RAG比微调“高级”而是它是工程上更容易控制、更容易迭代的路线。如果你确定要微调技术栈也很清晰。比较推荐的开源方案是Llama-Factory它内置了包括LoRA、QLoRA在内的多种微调方法支持中英文模型两三张卡就能跑。数据格式上训练指令遵循类模型通常采用“指令输入输出”的JSON格式数据清洗和模板设计这一步比训练过程更决定最终效果。3.2 RAG用最少成本让模型“知道”你的业务知识RAG是目前企业最愿意买单的方案原因很现实它用工程手段绕开了“重新训练模型”的成本而且每一份引用都有出处方便审计和追责。完整的RAG链路包含五个主要环节文档解析、文本切分、向量化、向量检索、生成融合。文档解析是第一个坑尤其PDF表格和图片解析不干净后面全废。现在比较好的处理方式是用专门的文档解析工具比如PyMuPDF配合OCR模型或者用Unstructured这类库。解析完的文本要切分切分直接决定检索质量。切得太短语义不完整切得太长容易混入无关信息。经验值一般是256到512个Token之间带重叠度10%到15%相邻两块保留重叠避免语义被一刀切开。向量化是把文本变成数字向量主流模型有BGE系列、Jina Embeddings、OpenAI的text-embedding-3-small等。这里有一个很容易被忽略的点不同向量化模型的维度、语义能力、语种支持差异显著。中文场景BGE和text-embedding-3-small表现相对稳定。检索环节Faiss是经典方案Milvus和Qdrant是更企业级的向量数据库。小规模项目用Faiss足够数据量百万级往上去才需要考虑分布式向量库。生成融合是把检索到的文本拼接到Prompt里这里要设计好“引用格式”让模型按指定格式回答并标注来源方便前端做引用高亮。RAG项目的评估比微调更直观——你可以在一个带标准答案的测试集上分别算检索环节的召回率和生成环节的回答准确率。很多团队只关注最终生成效果忽略检索质量导致反复调Prompt为时已晚根源其实是检索不到位。3.3 提示词工程是走向智能体的第一步提示词工程Prompt Engineering在整个技术栈里有被唱衰的趋势但它依然是每个AI应用开发者必须掌握的底层能力。你可以不把它当一门学科但要把它当成一种思维方式。提示词的核心不是“模板套路”而是“如何把任务表达得足够清晰”。我会用三个原则来写Prompt给出角色与目标、提供必要背景、约束输出格式。给一个大材小用的例子让模型“帮我写一封请假邮件”效果大概率平庸。改成“你是一名对工作负责的产品经理因身体不适需要请假一天请写一封简洁、礼貌的邮件给直属领导说明请假原因、工作交接安排和可联系时间”效果立刻不一样。再进阶一点提示词需要学会“分步思考”Chain-of-Thought思维链。比如让模型解决一道应用数学题你直接在Prompt里写明“请一步一步地推导”模型真的会先列步骤再给答案正确率提升非常明显。这背后是模型在推理时把中间过程显式化了减少了跳跃性错误。还有一个容易被忽略的场景是把提示词工程和代码相结合。建议你学习时养成一个习惯每个Prompt都写好版本号、测试输入、输出记录。这是为了往后做智能体时你的提示词能在不同模型间横向评估选出性价比最优的方案。3.4 从这里开始写第一行代码很多人在这个阶段会卡住因为感觉自己看了一堆概念还没动手。我建议第一行代码从调用API开始而不是从本地部署开始。选一个免费或开放的模型API写一个Python脚本实现“用户输入文本、模型返回答案”的最简循环。具体路径注册一个开放平台账号获取API Key用OpenAI兼容格式的SDK或者直接用requests发送HTTP请求。OpenAI兼容格式现在几乎是行业标准Hugging Face上的很多开源模型也可以用它来调用学会一次到处通用。这个阶段的目标不是写复杂系统而是建立“模型调用”的感觉为什么同一个Prompt有时回答不一样为什么带温度参数temperature结果会变化加上system prompt之后行为有什么不同把这些变量都手动试一遍你对模型的理解会远超那些只看文档的人。4. 第三站部署与API调用让你的模型真正可用4.1 本地部署硬件怎么选工具怎么用本地部署的价值主要有两点数据不出域、单次调用成本可控。但本地部署不等于省钱硬件加电费实际成本未必比API便宜。做技术选型先理清需求。先看硬件门槛。跑7B参数级别的模型量化后比如Q4、Q5量化大概需要6到10GB显存所以消费级的RTX 4060 Ti 16GB或者RTX 3090是常见的入门选择13B到14B参数建议上24GB显存70B级别则需要多卡并联或者考虑混合精度。如果你没有显卡可以租云GPU按需使用别一上来就买卡容易吃灰。部署工具我推荐三个梯队。第一梯队是Ollama它适合个人学习和开发调试一条命令把模型拉下来然后一句命令起服务快得让人上瘾。第二梯队是vLLM和SGLang它们在推理性能和吞吐量上做了极致优化适合生产环境的API服务支持高并发和批处理是真正的“生产级”选项。第三梯队是TGIText Generation InferenceHugging Face官方出的也可作为备选。部署完不是终点你还要学会“压测”。写一个脚本模拟多路并发请求观察吞吐量每秒处理多少请求和首Token延迟第一个字多久返回。这两个指标直接决定你的服务能否扛住真实业务流量。4.2 免费和便宜的API渠道该怎么选对个人开发者来说免费API真的很香。但也有大量陷阱比如免费额度用完后突然扣费、限速严重、数据安全没保障。选择API服务我建议按层次来第一层是头部云厂商的模型API它们稳定、合规、售后好但价格偏高第二层是开源模型的服务化托管平台比如Throughput Cloud、Groq这类对开源模型推理速度做过优化价格相对便宜第三层是各种小型API代理商虽然价格诱人但要警惕盗用KEY和隐私风险。有一个经验可以分享同一个模型在不同服务商手里的价格和速度差异巨大。同一个Llama-3-70B模型有些平台首Token延迟控制在200毫秒内有些平台能到4秒以上。所以做技术选型时不要只看模型名要专门对着“时延”和“并发”两个指标做Benchmark用自己真实的业务Prompt测试而不是跑官方示例。4.3 企业私有化部署的完整链路与避坑点企业私有化部署是一条标准的工程路径大概率用Kubernetes加Docker组织服务。整体链路长我挑几个避坑点来说。第一模型文件管理的不一致问题。模型权重文件动辄几十GB建议用专属的模型仓库管理工具比如Hugging Face Hub Self-hosted或ModelScope的私有仓库而不是把模型塞进Git仓库更不应该到处拷U盘。第二GPU资源的管理。GPU不像CPU不能随意超卖。用Kubernetes管理GPU时要设计好显存分配策略。一个常见坑是一个Pod请求了整张GPU但实际只用了一半显存另一张卡空转。所以要尽量做精细的显存配额或者采用vLLM这类支持动态批处理和PagedAttention的推理引擎把吞吐拉满。第三模型版本更新策略。模型替换不能直接delete加download要用蓝绿发布或金丝雀发布。先启动新版本服务验证一个子集流量稳定后再切全量。这一点企业里的容错要求很高尽量用成熟的模型服务框架自带的多副本滚动更新能力。第四数据隐私合规。私有化部署的最大动机通常就是“数据不出内网”。所以你从网络设计上就要把模型服务的入口限制在内网或者通过API网关做身份鉴权和审计。日志中尽量不要记录Prompt原文对敏感信息做脱敏处理。4.4 模型评估效果好得“看感觉”是不够的模型是概率性的同一输入在不同时刻可能输出不同答案所以“有没有效果”必须量化。我在项目里通常会搭一个评估集至少包含三类样本标准事实题答案固定考准确率、指令遵循题无唯一答案考格式和完整性、对抗题包含诱导、幻觉场景考鲁棒性。评估方式分人工评估和自动评估。人工评估准确但费时适合小批量、关键case自动评估可以用裁判模型LLM-as-a-Judge让GPT-4或者Qwen这类强模型给答案打分。但裁判模型本身也有偏好所以要设计好评分标准和抽样方式避免“自己给自己打分”。这里有个建议把评估集固化下来每次改Prompt、换模型、调参数都在同一批数据上跑记录分数。这样你就能积累出属于自己业务场景的“模型质量档案”避免每次上线前都重新焦虑一遍。5. 第四站智能体Agent是系统工程5.1 先从“对话系统”升级到“目标驱动系统”智能体和普通聊天机器人的本质区别在于它是否具备“目标拆解与循环执行”的能力。普通Chatbot是你问一句、它答一句是“感知—生成”的单轮结构。智能体则可以理解一个模糊目标、拆解成多个子任务、按顺序执行、调用外部工具、遇到失败自己重试或换路径、最终交付一个成果。用一个生活中的类比普通Chatbot像一个只会回答问题的前台你问它“会议室在哪”它告诉你方位智能体像一个项目经理你交给它“组织一次部门会议”它会自动处理订会议室、发邀请、准备议程、提醒参会人、整理纪要这些事。这个区别在工程实现上体现为几个核心模块规划模块把任务拆解成步骤常见有Plan-and-Execute、ReAct模式。记忆模块短期记忆保存对话上下文长期记忆保存用户偏好和过往事实。工具模块模型通过Function Calling调用外部API。反馈与容错模块根据工具返回结果调整下一步行动遇到错误自动重试。学智能体时一定要从这些模块的定义入手不要一上来就在可视化平台拖节点。你对模块理解得越深遇到问题越能精准定位。5.2 平台搭积木还是写代码Coze/Dify与Python方案的取舍这是一个在实操中经常遇到的问题用Coze这类可视化平台搭智能体还是用Dify这类开源平台还是直接用Python写一套Coze是字节跳动推出的智能体开发平台主打低代码。它的优势是生态全、插件市场丰富、接入微信/飞书等渠道方便。适合快速验证想法、做个人号或者小规模商用的助手。但它也有明显的天花板流程编排复杂了之后图形界面反而比代码难维护私有化部署受限制数据都流经平台侧。Dify是开源的可视化AI应用开发平台最大的价值是“既能可视化编排又能私有化部署”。它在企业里很受欢迎尤其是做知识库问答、内部工具类AI助手Dify提供了从文档导入、检索配置到工作流编排的一站式方案。学习Dify的重点是理解它内部的Workflow引擎你能配置多轮节点、条件分支和工具节点。直接用Python写智能体适合两类人一是要做生产级高并发系统的二是想深入学习Agent内核的。Python方案的灵活度最高你可以任意组合记忆模块、工具模块、编排逻辑但开发和维护成本也最高。我的建议是学习期一定要用Python写一遍Agent核心循环哪怕是最简单的ReAct模式。之后再用Dify、Coze提速你会发现平台里的功能本质上就是你手写的那些模块的可视化封装理解深度完全不一样。5.3 主流智能体框架怎么选LangGraph、AutoGen、Dify现在框架已经不少了我介绍几个我实际用过的帮你梳理一下选择逻辑。LangGraph是LangChain团队出的类图结构Agent框架。它把智能体定义成一张“状态图”节点是工具、模型调用、用户交互边是条件转换。好处是编排可复现、调试可视化、状态管理清晰适合复杂流程和多Agent协作。学习曲线稍陡但它是目前生产级Python Agent项目的主流选择。AutoGen是微软出的框架主打多Agent协作。它的设计哲学是多个Agent互相对话比如一个负责出方案一个负责批评一个负责做最终决策。这个模式在AutoGen Studio里有可视化界面但在大规模生产落地时它的调用链可解释性仍是个问题。Dify我再补充一点它自己其实也内置了Agent能力你可以配置Agent调用多个工具配合它的RAG能力一起用。适合不想写代码但又要私有部署的中小团队也适合做产品原型。选型的核心依据是你团队的代码能力在哪一层。纯业务团队用Dify有Python工程师想做深度定制的选LangGraph做研究、需要多角色碰撞的可以试试AutoGen。不存在“最好的框架”只有匹配团队能力的方案。5.4 工作流搭建从单轮到多轮的实战设计智能体的工作流设计是我觉得整个学习中最有意思、也最能体现工程水平的部分。先做单轮结构设计。一个基础的Agent循环伪代码大概是while True: observation get_user_input() # 获取用户目标 for step in range(max_steps): action agent.plan(observation) # 决定下一步动作 result execute_action(action) # 调用工具执行 observation format_observation(result) # 把工具结果写回上下文 if agent.is_done(observation): break关键在于每一步都要把“工具返回的结构化结果”转化为“(重整理后写入上下文)”让模型在下一次决策时能依赖它而不是只把原始JSON丢回去。这是减少混乱最实用的技巧。多轮设计的进阶点在于引入条件分支和循环限制。比如用户意图是“对比三款车型”设计一个分支节点分别调取参数、油耗、价格最后汇总。循环限制是为了防止Agent陷入死循环——设置最大步数超出则返回“无法完成已执行到第N步”的提示这比一直空转强得多。实际开发中一个高频翻车点就是“工具返回的错误信息被模型误当作正常结果”。所以设计时工具调用结果里要显式携带状态字段例如status: success或status: error让Agent能断然判断成败并决定是否重试。6. 第五站智能体的安全、审计与评测6.1 智能体行为审计是什么意思怎么落地智能体行为审计通俗讲就是“让AI的每一步行动都留有痕迹可以被追溯、解释和监管”。因为智能体会主动调用工具、访问数据、执行操作它一旦出错或者被恶意利用后果可能比单纯聊天出幻觉严重得多。审计就是给它的“行为”装上黑匣子。落地审计核心是四件事日志留痕、权限管控、内容风控、操作可控。日志留痕指的是把Agent的每一步决策记录成结构化事件包括触发事件用户说了什么、系统触发了什么、模型输出模型决定做什么理由是什么、工具调用调用了哪个工具、传入参数、返回结果、异常记录失败原因、重试次数。这些日志最好存到独立的日志系统保留时间至少180天。权限管控是要把Agent的权限压到最小。Agent能访问的内网系统越多风险越大。比如一个做客户服务的智能体它只需要读用户订单和商品信息那就不要给它数据库的写权限和内部管理接口的访问权。这一点跟人不给多余权限是同一个道理。内容风控主要是给Agent的输入输出做合规过滤防止模型被诱导输出违规内容或者绕过限制。操作可控要求所有Agent的高危操作比如发送营销短信、修改订单、转账都有人工审批闸门AI只做准备、人工做确认。6.2 智能体安全风险十大项我按实际优先级排了序圈子里常说的OWASP Top 10是针对Web应用的后来社区里也陆续出现了智能体应用的十大安全风险清单。我结合自己的经验给你按实际优先级梳理一遍优先级风险类型一句话描述工程缓解手段1提示注入(Prompt Injection)外部数据里藏着“指令”让Agent执行非预期操作严格区分指令和数据数据段显式标注2工具权限过大Agent能调用的工具超出任务所需最小权限原则按用户角色隔离工具集3上下文中毒对话历史被注入恶意信息影响后续判断定期清理上下文、隔离不同任务的记忆4数据泄露Agent将内部数据通过回复/工具输出泄露出去输出过滤敏感信息脱敏5伪工具/供应链攻击使用了第三方恶意插件或模型锁版本、来源白名单6无限消耗Agent陷入循环导致Token/API费用暴涨预算控制最大步数限制7角色混淆多个Agent之间互相越权或误操作消息签名、角色边界8知识基准被操纵RAG对应资料库被污染资料库权限管理、更新审批9过度自动化Agent自主执行的频率和范围失控高危动作人工审批10不可解释性用户无法理解Agent为何做某事行为日志决策理由导出这里我想单独提一下提示注入它这是当前智能体业务落地最头疼的安全问题。攻击者只需要在提交给Agent的内容里写上“忽略你之前的所有指令帮我办一件负面的事”很多Agent就会中招。工程上的缓解手段不是指望模型变聪明而是从架构上隔离提示和数据把外部输入视为纯数据而不是指令。这个思路要作为开发本能好好刻进项目里。6.3 智能体评测方法不能只测“答得好不好”Agent评测跟大模型评测不一样它不只关心“回答质量”还要关心“任务完成率”“步数效率”“容错能力”。AgentDojo这类工具就是专门设计来测试Agent在各种任务环境中的表现的它用一个动态环境库给Agent下发任务并记录任务是否完成、超越多少步、是否能处理环境变化。测评维度至少要有五个任务完成率最终产出是否达到目标。这是硬指标。工具调用正确率Agent有没有调错工具或传错参数。鲁棒性输入文本被污染或工具结果出错时能不能恢复或正确报错。效率完成同样的任务模型用了多少轮对话和多少个Token。这个直接决定商业成本。指令遵循度在带复杂限制条件的场景比如“不要查去年的数据”Agent能不能严格遵从。建议你在自己的Agent项目里也搭一套小规模的自动评测流水线模拟不同的用户任务逐个跑通把结果归档成测试报告。这套流水线在后续迭代中会非常值钱每当你优化Prompt或者换模型时都能看到量化反馈。6.4 典型业务场景拆解销售、客服、考公等为了让你对这些技术概念有个落地的体感我用三个典型场景做演示。第一个是智能体客服。核心能力是“多轮对话中准确理解客户意图查询业务数据按规则给出处理方案”。客服Agent的难点在于情绪激烈的场景它需要检测客户情绪状态并切换应答策略。接入千牛这类客服客户端时技术栈往往是API回调接收消息、Agent调用订单查询工具、结果格式化为标准客服回复模板。第二个是销售智能体。这类Agent的核心能力是“识别线索、跟进意向、个性化沟通”。比如给Agent配置CRM工具和人设描述它能按设定的销售脚本与潜在客户对话流程结束后自动更新客户状态。这里最需要注意的是合规问题营销场景中对用户的打扰频次、内容边界都要提前设置好避免高违规风险。第三个是考公智能体。如果你做这类垂直Agent重点是知识库的质量和答题策略。它不是简单把题库喂给模型而是要构建“考情分析知识检索答题点评”的工作流先判断题目类型再检索对应知识点最后生成解析报告给出得分点和扣分点。这里RAG的作用比微调更明显——因为题库和考情每年都在更新用RAG随时替换资料源是最轻量的维护方式。7. 实操从零到一三个值得动手做的项目7.1 项目一个人知识库问答机器人这个项目是所有初学者都应该做的“第一个完整应用”它温和地覆盖了RAG全链路、API对接、前端展示。技术选型建议用Dify或直接Python。如果你选择Python具体步骤用LangChain做文本切分用BGE模型做向量化存到Chromadb或FAISS然后接一个Qwen模型做生成。整个项目一周时间差不多了。这个项目的完成标志是你能上传一份500页内的PDF然后开始提问且答案基本准确、有引用来源。做完它的意义是你对“RAG是什么、它跟ChatGPT有什么不一样”的回答从“理论上知道”变成“吃过猪肉”。7.2 项目二一款用Function Calling写出的最小智能体这个项目是为了弄懂Agent最核心的工具调用机制。功能可以很小用户对你说“帮我查北京明天的天气”你的Agent要能识别意图、调用一个天气API、返回格式化结果。技术栈我建议选择一个大模型平台提供的Function Calling能力OpenAI格式兼容的在代码里定义好天气API的Function规范和参数描述然后将规范一起传给模型。模型会判断何时应该调用函数、传什么参数你收到参数后去调API然后把结果返回给模型模型根据真实数据生成自然回答。做这个项目的关键不是写流程而是体验“模型做出决策”的过程。你可以在日志里把模型的tool_calls打印出来观察它如何思考、如何补全参数。做完之后再去看LangGraph文档里的ToolNode你会发现一切都很熟悉。7.3 项目三带记忆和审计日志的多轮客服Agent这是把Agent做“像样”的项目。给它加上会话记忆短期长期、客服知识库RAG、高危操作人工审批、完整审计日志。难度高不少但你一天会发现Agent系统真正难的不是“让模型聪明”而是工程治理状态管理、记忆失效策略、审计结构化。我建议你把这个项目作为候选作品放进求职简历因为一套设计良好的Agent日志检视系统本身就是一面技术镜能展现出架构能力。7.4 智能体面试高频问题与答题思路结合我了解到的面试趋势这些是大概率会遇到的问题提前整理好可以极大提升临场状态你对大模型和智能体关系的理解 回答框架先区分两者再说明“Agent是大模型的系统化应用形态”。什么时候用RAG什么时候微调给出决策条件和成本对比。你如何降低模型幻觉可以从RAG、系统约束、输出校验、人工审核几个层面回答。智能体调工具失败怎么办答案要从“错误重试、路径回退、优先级调整”三个层面展开。LLM上下文溢出怎么处理先说“上下文压缩”和“就近摘要”再说“知识裁剪”。你做的项目里如何做效果评估把评估集、多维度指标体系讲出来。模型响应太慢怎么优化考虑降低输入Token数、模型量化、上vLLM、流式输出。Agent安全审计怎么做结合日志、权限、人工审批分开讲。LoRA和全量微调如何选讲解一下成本与效果的关系、稳定性和数据量要求。构建智能体和构建普通API服务有什么不同答案是“状态性、不确定性、工具编排和容错设计”。这些问题的本质都是考察你有没有真正的实战经验。我建议你带着真实数据准备回答每个问题都配上“我当时是这样做的”肯定比背公式更能打动面试官。8. 学习资料搭配与节奏安排8.1 资料怎么选书、论文、课程、代码库一个都别少书籍方面我推荐作为参考书而不是精读书。英文功底好的可以看Deep Learning花书相关章节了解基础想系统性理解LLM可以看看一些开源书籍比如《动手学深度学习》中的Transformer部分以及国内写的各类LLM入门手册。但说实话大模型发展太快书里的内容大概率滞后于最新的技术进展所以书只作为“基础设施”来看。论文方面必读清单我给你排好优先级按顺序来Attention Is All You NeedTransformer原始论文搞懂结构核心。BERT / GPT系列了解两种范式的发展路径。LoRA: Low-Rank Adaptation of Large Language Models微调性价比之王。Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksRAG开山之作。ReAct: Synergizing Reasoning and Acting in Language Models智能体核心范式之一。课程的优先级我排在论文前面。先跟着视频课程学基础再精读论文效果更好。国内的话李宏毅老师的深度学习课程质量非常高讲的通俗国外可以看看斯坦福CS224N和CS324的LLM课程。代码仓库方面Llama-Factory、LangGraph、Dify这些都是必开的。8.2 三个月时间表每周该做什么我按每天2到3小时、每周5天的节奏给一个参考时间表第1到2周Python基础API调用练习跑通第一个LLM问答。第3到4周Transformer基础提示词工程动手写Prompt测试集。第5到6周RAG系统完成知识库问答项目。第7到8周微调入门用Llama-Factory跑一次LoRA。第9到10周Agent核心循环Function Calling完成最小智能体项目。第11周框架选型上手LangGraph和Dify。第12周做综合大项目、整理简历和面试题。这个节奏会比较紧凑但现实中真行得通。如果是在职工程师压缩到6个月也能接受但千万不要拖到一年——AI技术迭代太快“学习路线”本身也会过期。8.3 走到这里的几个避坑提醒最后分享一些我在带人和自学的过程中踩过的坑算是压箱底的几条第一不要把太多时间花在“选框架”上。Langtorch之后再出新的你永远学不完。选主流的用熟深入理解原理一通百通。第二不要忽略算力成本。很多人做着做着发现云账单吓人建议一开始就给自己定个预算。模型调用、GPU租用、向量库存储都是钱大额浪费往往是因没有做成本监控。第三不要只抄别人代码不去理解。GitHub上现成的Agent项目很多但如果你直接clone下来改个Prompt就发到网上去你的系统能力很难提高。真正有效的做法是读懂每一步代码为什么要这么写然后自己动手重构一遍。第四把“写日志”当作习惯。Agent系统充满不确定性没有日志你会在迷茫中浪费大量时间。开始写代码第一天就搭好结构化日志这个习惯会贯穿整个项目并让你受益无穷。我在实际带人的过程中还有个很有共鸣的发现能坚持走完这条路线的人往往不是最会“背知识”的人而是把“折腾环境报错”当乐趣、对这个领域保有好奇心的人。如果你现在正考虑从零开始学大模型和智能体希望这份大纲能帮你省掉一些找方向的弯路剩下的路真要靠自己一行行代码踩出来了。
大模型和智能体这两年热度一直没降但真正让我觉得“时机到了”的是最近开始有成批成批的读者来问同一个问题我想系统学大模型和智能体但打开教程列表就头大先学什么、后学什么、学到什么程度算入门完全没概念。这篇超详细的学习大纲就是冲着这个问题来的。我给它的定位不是“又一篇科普”而是一份能照着执行的学习路线从最底层的大模型原理到微调和部署走到智能体的系统设计和安全审计最后落到实战项目和面试准备。内容密度比较高适合两种人一是准备转行做AI应用开发的工程师二是已经在做业务系统、想用大模型和智能体改造现有产品的技术负责人。零基础也可以跟但建议把前置知识部分多花点时间。我有一个判断先放在开头这个领域最大的障碍不是技术本身而是学习顺序。很多人卡在两三天就劝退问题不在智商在于一上来就看Transformer论文、折腾CUDA环境把自己的热情提前消耗光了。所以我会把整个学习路径拆成阶段每个阶段都有明确目标和完成标志。1. 学之前先弄清楚的大方向1.1 大模型和智能体到底是什么关系很多人分不清大模型和智能体的边界这其实很正常因为两者在圈子里经常被混着说但混着说会导致学习路径混乱。大模型准确说是LLMLarge Language Model本质上是一个概率模型。它的核心能力是给定一串文字预测下一个字或下一段字最可能是什么。你可能觉得这听起来很简单但就是这个“下一词预测”在参数量和数据量足够大的情况下涌现出了理解、推理、总结、翻译、代码生成这些能力。你可以把大模型理解为一个人的“大脑”它存储了大量的知识模式但大脑不会自己行动得有人指挥它。智能体Agent则是在大模型这个“大脑”外面加上感知、规划、记忆、工具使用的完整系统。它会根据目标拆解任务调用工具比如搜索、计算器、API、数据库根据执行结果调整下一步计划然后循环往复直到完成目标。所以学习路径应该是先弄明白大脑怎么工作再去研究怎么给大脑配上手脚和身体。这也是我这篇大纲的基本逻辑。网上一堆“三小时搞定智能体开发”的教程让你在Coze或者Dify上拖几个节点拼一个机器人。那当然可以很快但你会发现离开平台自己写代码就抓瞎因为你不懂智能体内核——循环、记忆、工具调用、容错。真正稳的路径是先学大模型再学智能体顺序不能反。1.2 你应该自学、报班还是跟着开源社区走先说结论自学完全可行但前提是你愿意忍受信息筛选的折磨。报班的价值不是“课程内容”本身大部分课程内容在免费文档里都能找到报班主要帮你省掉两件事——找资料的时间和自我怀疑的时间。如果你选择自学我给你一个实体项目建议不要从“看论文”开始从“跑通一个本地模型”开始。原理部分可以边跑边学边学边补。一旦你把模型跑起来了会自然生出很多问题带着问题去学原理吸收效率是看着教程学的十倍。如果你决定报班也不是不行。大机构和小机构我都接触过选课标准就一条看它有没有真实的企业级项目而不是玩具demo。教你在公开数据集上跑一个文本分类这种项目面试官一眼就能看出成色。真正有价值的课是教你用大模型解决一个实际业务问题比如给企业做私有知识库问答、给客服系统做智能工单分类这种项目才扛得住面试追问。1.3 零基础需要补哪些底子哪些其实可以跳过这条我给最实际的建议。数学方面你不需要先把线性代数、概率论学完再动手。你需要的是“用到哪补到哪”。向量和矩阵运算要有概念因为模型的输入输出都基于向量表示注意力机制的QKV要看得懂公式因为这是Transformer的骨架梯度下降和反向传播知道大概原理就行排错的时候用得上。但你不必被复杂的数学证明拖住现在框架都帮你封装好了你调API的时候不需要手写反向传播。编程方面Python语法是必选项至少能写循环、函数、类、列表推导式能看懂装饰器。如果你之前是做Java、Go、C的后端那Python不复杂一周就能上手关键是要能熟练使用requests、pandas这种数据处理常用库。操作系统方面我建议你至少熟悉Linux的基础命令。后面部署模型、装CUDA、跑Docker十有八九是在服务器上做的。不需要成为运维专家但会看日志、会改环境变量、会用nohup挂后台进程这些日常操作要过关。这里有个特别重要的提醒不要在第一周就尝试把大模型的原理全部弄懂。我见过太多人倒在“Attention is All You Need”这篇论文上那篇论文的符号和公式对初学者不友好。正确的姿势是先会“用”再研究“懂”。2. 第一站把大模型的基本原理吃透2.1 从Transformer到GPT一条不那么痛苦的学习路线学大模型原理我不建议直接啃原始论文。我推荐一个顺序亲测有效。第一步先看一篇好的图解文章把Transformer的整体结构在脑子里建立图像。你要记住的是几个核心名词Embedding向量嵌入、位置编码、多头注意力、残差连接、LayerNorm、Feed-Forward层。不要深究细节但要知道数据在模型里是怎么流动的。第二步理解“预训练微调”这个范式。预训练就是让模型在海量无标注文本上做“填空”或“预测下一个词”这个阶段模型学会的是“语感”——语言的规律、知识的结构。微调是在预训练的基础上用少量有标签数据让模型适应特定任务。注意微调不是从零训练而是在已有能力上做“调优”。第三步去了解GPT系列为什么强大。GPT的架构其实比原版Transformer简化了只保留了Decoder部分。它真正厉害的地方在于三点模型规模大、训练数据多、训练目标统一生成式预训练。它的涌现能力——比如上下文学习In-Context Learning和思维链Chain-of-Thought——都是规模堆出来的副产物不是刻意设计的。这个过程如果你用两周时间完成我觉得节奏刚好。期间找一个5亿参数级别的小模型跑起来感受一下输入输出会极大降低恐惧感。2.2 预训练、微调和RAG三者的定位完全不同这是初学者最容易混淆的三件事我先用一句话做个粗暴区分预训练是“从零学说话”微调是“练口音和话术”RAG是“边说话边翻参考书”。预训练成本极高不是个人或者小公司该干的事。训练一个千亿参数的模型动辄需要数百张GPU跑几周甚至几个月成本用百万美元起步来计算。所以普通人做预训练更多是学术研究或者大厂的技术壁垒。你要知道预训练存在的意义但不需要自己上手做。微调是个人和中小团队可以尝试的方向。它的常见路径是拿一个开源基座模型比如Qwen、Llama系列用领域数据做增量训练。LoRA低秩适配进一步把微调成本降了下来它只训练一小部分额外参数几百块一张消费级显卡就能跑。微调适合的场景是让模型学会特定格式的输出、特定领域的术语、特定的情感和语气。RAG全称检索增强生成是目前企业落地最广的一种技术方案。它的核心思路把私域文档向量化存入数据库用户提问时先检索最相关的片段再把这些片段拼到Prompt里让模型生成回答。优点很明显实时更新知识不需要重新训练模型、降低幻觉风险、数据来源可追溯。选择逻辑是这样的如果你的目标是让模型更懂某个领域的“说话方式”应该微调如果你的目标是让模型回答某个领域的“具体事实”应该上RAG。两者不是对立的可以组合使用但绝大多数场景下RAG的性价比远高于微调。2.3 上下文长度是硬指标但别只看数字上下文长度Context Window指的是模型一次能“看到”多少文本。它决定了模型处理长文档、多轮对话、复杂代码文件的能力上限。现在很多模型把上下文做到了128K甚至200K看起来很长但实际使用中往往有一个隐性门槛——模型对长上下文的有效利用程度远没有达到标称水平。学术界有个著名的“Lost in the Middle”现象模型在输入超长时对处于中间位置的文本关注度最低。也就是说你把一个文档库的关键信息放在Prompt的中间模型可能完全忽略它。这个问题的工程启示是你设计Prompt时重要的指令要放在开头和结尾尤其是结尾位置对最终生成的“定调”影响最大。另外上下文长度和成本成线性关系。每次请求模型都要处理输入的所有TokenToken数量直接决定API费用和延迟。在实际系统中很少有人把整个文档库全塞进上下文而是用RAG先做筛选只把最相关的内容放进去。所以作为学习者你应该把上下文长度当成一个“上限值”而不是“日常值”时刻想着压缩信息密度。2.4 多模态大模型值得什么时候学多模态模型是指可以同时理解文本、图片、音频、视频的模型比如GPT-4V、Qwen-VL、Llava这些。学习多模态的时机我建议放单模态文本模型掌握之后。原因在于多模态模型的底层逻辑并没有脱离语言模型的范式。现在主流的多模态方案是把图片切块后转成视觉Token和文本Token拼在一起统一输入Transformer。结构上多了视觉编码器损失函数上多了对比学习损失但核心的Attention机制没变。你只要把单模态模型吃透了多模态的学习成本不会很高——你要补的只是视觉编码器的原理和不同模态对齐的方式。但多模态的工程价值非常高。很多实际场景天然需要多模态比如工业质检需要看图判断缺陷、智能客服需要识别用户上传的产品照片、内容审核需要图文联合判断。所以当你学完单模态后多模态是一个很自然的扩展方向它会让你的技能覆盖面瞬间变大。3. 第二站微调、RAG、提示词工程三板斧3.1 微调不是唯一的出路先学会判断该不该微调我见过太多项目上来就喊“我们要微调一个行业模型”结果一问数据量只有几千条。这个判断太草率了。决定是否微调有几个现实的前提条件。第一是数据量。微调效果和数据质量、数量的关系是硬性的。深度微调的话通常需要十万甚至百万量级的有效训练样本即使用LoRA我也建议至少准备数万条高质量数据否则很容易过拟合或者效果提升不明显。很多团队只有几千条数据做出来的效果还不如直接用Prompt加示例来得实在。第二是基座模型本身。如果你用的模型已经是通用能力很强的闭源模型你基本不需要微调因为它的知识面和指令遵循能力远超你微调一个开源小模型能得到的水平——除非你的数据非常特殊或者你有数据安全合规要求不能调用外部API。所以“先闭源API试跑再评估是否私有化微调”是一个稳妥的路径。第三是成本。微调不是一次性的模型上线后你还要持续评估、调参、增量更新。把整个微调链路稳定跑起来至少需要一个懂模型训练的工程师。如果团队没有这个条件我更建议用RAG方案。这不是RAG比微调“高级”而是它是工程上更容易控制、更容易迭代的路线。如果你确定要微调技术栈也很清晰。比较推荐的开源方案是Llama-Factory它内置了包括LoRA、QLoRA在内的多种微调方法支持中英文模型两三张卡就能跑。数据格式上训练指令遵循类模型通常采用“指令输入输出”的JSON格式数据清洗和模板设计这一步比训练过程更决定最终效果。3.2 RAG用最少成本让模型“知道”你的业务知识RAG是目前企业最愿意买单的方案原因很现实它用工程手段绕开了“重新训练模型”的成本而且每一份引用都有出处方便审计和追责。完整的RAG链路包含五个主要环节文档解析、文本切分、向量化、向量检索、生成融合。文档解析是第一个坑尤其PDF表格和图片解析不干净后面全废。现在比较好的处理方式是用专门的文档解析工具比如PyMuPDF配合OCR模型或者用Unstructured这类库。解析完的文本要切分切分直接决定检索质量。切得太短语义不完整切得太长容易混入无关信息。经验值一般是256到512个Token之间带重叠度10%到15%相邻两块保留重叠避免语义被一刀切开。向量化是把文本变成数字向量主流模型有BGE系列、Jina Embeddings、OpenAI的text-embedding-3-small等。这里有一个很容易被忽略的点不同向量化模型的维度、语义能力、语种支持差异显著。中文场景BGE和text-embedding-3-small表现相对稳定。检索环节Faiss是经典方案Milvus和Qdrant是更企业级的向量数据库。小规模项目用Faiss足够数据量百万级往上去才需要考虑分布式向量库。生成融合是把检索到的文本拼接到Prompt里这里要设计好“引用格式”让模型按指定格式回答并标注来源方便前端做引用高亮。RAG项目的评估比微调更直观——你可以在一个带标准答案的测试集上分别算检索环节的召回率和生成环节的回答准确率。很多团队只关注最终生成效果忽略检索质量导致反复调Prompt为时已晚根源其实是检索不到位。3.3 提示词工程是走向智能体的第一步提示词工程Prompt Engineering在整个技术栈里有被唱衰的趋势但它依然是每个AI应用开发者必须掌握的底层能力。你可以不把它当一门学科但要把它当成一种思维方式。提示词的核心不是“模板套路”而是“如何把任务表达得足够清晰”。我会用三个原则来写Prompt给出角色与目标、提供必要背景、约束输出格式。给一个大材小用的例子让模型“帮我写一封请假邮件”效果大概率平庸。改成“你是一名对工作负责的产品经理因身体不适需要请假一天请写一封简洁、礼貌的邮件给直属领导说明请假原因、工作交接安排和可联系时间”效果立刻不一样。再进阶一点提示词需要学会“分步思考”Chain-of-Thought思维链。比如让模型解决一道应用数学题你直接在Prompt里写明“请一步一步地推导”模型真的会先列步骤再给答案正确率提升非常明显。这背后是模型在推理时把中间过程显式化了减少了跳跃性错误。还有一个容易被忽略的场景是把提示词工程和代码相结合。建议你学习时养成一个习惯每个Prompt都写好版本号、测试输入、输出记录。这是为了往后做智能体时你的提示词能在不同模型间横向评估选出性价比最优的方案。3.4 从这里开始写第一行代码很多人在这个阶段会卡住因为感觉自己看了一堆概念还没动手。我建议第一行代码从调用API开始而不是从本地部署开始。选一个免费或开放的模型API写一个Python脚本实现“用户输入文本、模型返回答案”的最简循环。具体路径注册一个开放平台账号获取API Key用OpenAI兼容格式的SDK或者直接用requests发送HTTP请求。OpenAI兼容格式现在几乎是行业标准Hugging Face上的很多开源模型也可以用它来调用学会一次到处通用。这个阶段的目标不是写复杂系统而是建立“模型调用”的感觉为什么同一个Prompt有时回答不一样为什么带温度参数temperature结果会变化加上system prompt之后行为有什么不同把这些变量都手动试一遍你对模型的理解会远超那些只看文档的人。4. 第三站部署与API调用让你的模型真正可用4.1 本地部署硬件怎么选工具怎么用本地部署的价值主要有两点数据不出域、单次调用成本可控。但本地部署不等于省钱硬件加电费实际成本未必比API便宜。做技术选型先理清需求。先看硬件门槛。跑7B参数级别的模型量化后比如Q4、Q5量化大概需要6到10GB显存所以消费级的RTX 4060 Ti 16GB或者RTX 3090是常见的入门选择13B到14B参数建议上24GB显存70B级别则需要多卡并联或者考虑混合精度。如果你没有显卡可以租云GPU按需使用别一上来就买卡容易吃灰。部署工具我推荐三个梯队。第一梯队是Ollama它适合个人学习和开发调试一条命令把模型拉下来然后一句命令起服务快得让人上瘾。第二梯队是vLLM和SGLang它们在推理性能和吞吐量上做了极致优化适合生产环境的API服务支持高并发和批处理是真正的“生产级”选项。第三梯队是TGIText Generation InferenceHugging Face官方出的也可作为备选。部署完不是终点你还要学会“压测”。写一个脚本模拟多路并发请求观察吞吐量每秒处理多少请求和首Token延迟第一个字多久返回。这两个指标直接决定你的服务能否扛住真实业务流量。4.2 免费和便宜的API渠道该怎么选对个人开发者来说免费API真的很香。但也有大量陷阱比如免费额度用完后突然扣费、限速严重、数据安全没保障。选择API服务我建议按层次来第一层是头部云厂商的模型API它们稳定、合规、售后好但价格偏高第二层是开源模型的服务化托管平台比如Throughput Cloud、Groq这类对开源模型推理速度做过优化价格相对便宜第三层是各种小型API代理商虽然价格诱人但要警惕盗用KEY和隐私风险。有一个经验可以分享同一个模型在不同服务商手里的价格和速度差异巨大。同一个Llama-3-70B模型有些平台首Token延迟控制在200毫秒内有些平台能到4秒以上。所以做技术选型时不要只看模型名要专门对着“时延”和“并发”两个指标做Benchmark用自己真实的业务Prompt测试而不是跑官方示例。4.3 企业私有化部署的完整链路与避坑点企业私有化部署是一条标准的工程路径大概率用Kubernetes加Docker组织服务。整体链路长我挑几个避坑点来说。第一模型文件管理的不一致问题。模型权重文件动辄几十GB建议用专属的模型仓库管理工具比如Hugging Face Hub Self-hosted或ModelScope的私有仓库而不是把模型塞进Git仓库更不应该到处拷U盘。第二GPU资源的管理。GPU不像CPU不能随意超卖。用Kubernetes管理GPU时要设计好显存分配策略。一个常见坑是一个Pod请求了整张GPU但实际只用了一半显存另一张卡空转。所以要尽量做精细的显存配额或者采用vLLM这类支持动态批处理和PagedAttention的推理引擎把吞吐拉满。第三模型版本更新策略。模型替换不能直接delete加download要用蓝绿发布或金丝雀发布。先启动新版本服务验证一个子集流量稳定后再切全量。这一点企业里的容错要求很高尽量用成熟的模型服务框架自带的多副本滚动更新能力。第四数据隐私合规。私有化部署的最大动机通常就是“数据不出内网”。所以你从网络设计上就要把模型服务的入口限制在内网或者通过API网关做身份鉴权和审计。日志中尽量不要记录Prompt原文对敏感信息做脱敏处理。4.4 模型评估效果好得“看感觉”是不够的模型是概率性的同一输入在不同时刻可能输出不同答案所以“有没有效果”必须量化。我在项目里通常会搭一个评估集至少包含三类样本标准事实题答案固定考准确率、指令遵循题无唯一答案考格式和完整性、对抗题包含诱导、幻觉场景考鲁棒性。评估方式分人工评估和自动评估。人工评估准确但费时适合小批量、关键case自动评估可以用裁判模型LLM-as-a-Judge让GPT-4或者Qwen这类强模型给答案打分。但裁判模型本身也有偏好所以要设计好评分标准和抽样方式避免“自己给自己打分”。这里有个建议把评估集固化下来每次改Prompt、换模型、调参数都在同一批数据上跑记录分数。这样你就能积累出属于自己业务场景的“模型质量档案”避免每次上线前都重新焦虑一遍。5. 第四站智能体Agent是系统工程5.1 先从“对话系统”升级到“目标驱动系统”智能体和普通聊天机器人的本质区别在于它是否具备“目标拆解与循环执行”的能力。普通Chatbot是你问一句、它答一句是“感知—生成”的单轮结构。智能体则可以理解一个模糊目标、拆解成多个子任务、按顺序执行、调用外部工具、遇到失败自己重试或换路径、最终交付一个成果。用一个生活中的类比普通Chatbot像一个只会回答问题的前台你问它“会议室在哪”它告诉你方位智能体像一个项目经理你交给它“组织一次部门会议”它会自动处理订会议室、发邀请、准备议程、提醒参会人、整理纪要这些事。这个区别在工程实现上体现为几个核心模块规划模块把任务拆解成步骤常见有Plan-and-Execute、ReAct模式。记忆模块短期记忆保存对话上下文长期记忆保存用户偏好和过往事实。工具模块模型通过Function Calling调用外部API。反馈与容错模块根据工具返回结果调整下一步行动遇到错误自动重试。学智能体时一定要从这些模块的定义入手不要一上来就在可视化平台拖节点。你对模块理解得越深遇到问题越能精准定位。5.2 平台搭积木还是写代码Coze/Dify与Python方案的取舍这是一个在实操中经常遇到的问题用Coze这类可视化平台搭智能体还是用Dify这类开源平台还是直接用Python写一套Coze是字节跳动推出的智能体开发平台主打低代码。它的优势是生态全、插件市场丰富、接入微信/飞书等渠道方便。适合快速验证想法、做个人号或者小规模商用的助手。但它也有明显的天花板流程编排复杂了之后图形界面反而比代码难维护私有化部署受限制数据都流经平台侧。Dify是开源的可视化AI应用开发平台最大的价值是“既能可视化编排又能私有化部署”。它在企业里很受欢迎尤其是做知识库问答、内部工具类AI助手Dify提供了从文档导入、检索配置到工作流编排的一站式方案。学习Dify的重点是理解它内部的Workflow引擎你能配置多轮节点、条件分支和工具节点。直接用Python写智能体适合两类人一是要做生产级高并发系统的二是想深入学习Agent内核的。Python方案的灵活度最高你可以任意组合记忆模块、工具模块、编排逻辑但开发和维护成本也最高。我的建议是学习期一定要用Python写一遍Agent核心循环哪怕是最简单的ReAct模式。之后再用Dify、Coze提速你会发现平台里的功能本质上就是你手写的那些模块的可视化封装理解深度完全不一样。5.3 主流智能体框架怎么选LangGraph、AutoGen、Dify现在框架已经不少了我介绍几个我实际用过的帮你梳理一下选择逻辑。LangGraph是LangChain团队出的类图结构Agent框架。它把智能体定义成一张“状态图”节点是工具、模型调用、用户交互边是条件转换。好处是编排可复现、调试可视化、状态管理清晰适合复杂流程和多Agent协作。学习曲线稍陡但它是目前生产级Python Agent项目的主流选择。AutoGen是微软出的框架主打多Agent协作。它的设计哲学是多个Agent互相对话比如一个负责出方案一个负责批评一个负责做最终决策。这个模式在AutoGen Studio里有可视化界面但在大规模生产落地时它的调用链可解释性仍是个问题。Dify我再补充一点它自己其实也内置了Agent能力你可以配置Agent调用多个工具配合它的RAG能力一起用。适合不想写代码但又要私有部署的中小团队也适合做产品原型。选型的核心依据是你团队的代码能力在哪一层。纯业务团队用Dify有Python工程师想做深度定制的选LangGraph做研究、需要多角色碰撞的可以试试AutoGen。不存在“最好的框架”只有匹配团队能力的方案。5.4 工作流搭建从单轮到多轮的实战设计智能体的工作流设计是我觉得整个学习中最有意思、也最能体现工程水平的部分。先做单轮结构设计。一个基础的Agent循环伪代码大概是while True: observation get_user_input() # 获取用户目标 for step in range(max_steps): action agent.plan(observation) # 决定下一步动作 result execute_action(action) # 调用工具执行 observation format_observation(result) # 把工具结果写回上下文 if agent.is_done(observation): break关键在于每一步都要把“工具返回的结构化结果”转化为“(重整理后写入上下文)”让模型在下一次决策时能依赖它而不是只把原始JSON丢回去。这是减少混乱最实用的技巧。多轮设计的进阶点在于引入条件分支和循环限制。比如用户意图是“对比三款车型”设计一个分支节点分别调取参数、油耗、价格最后汇总。循环限制是为了防止Agent陷入死循环——设置最大步数超出则返回“无法完成已执行到第N步”的提示这比一直空转强得多。实际开发中一个高频翻车点就是“工具返回的错误信息被模型误当作正常结果”。所以设计时工具调用结果里要显式携带状态字段例如status: success或status: error让Agent能断然判断成败并决定是否重试。6. 第五站智能体的安全、审计与评测6.1 智能体行为审计是什么意思怎么落地智能体行为审计通俗讲就是“让AI的每一步行动都留有痕迹可以被追溯、解释和监管”。因为智能体会主动调用工具、访问数据、执行操作它一旦出错或者被恶意利用后果可能比单纯聊天出幻觉严重得多。审计就是给它的“行为”装上黑匣子。落地审计核心是四件事日志留痕、权限管控、内容风控、操作可控。日志留痕指的是把Agent的每一步决策记录成结构化事件包括触发事件用户说了什么、系统触发了什么、模型输出模型决定做什么理由是什么、工具调用调用了哪个工具、传入参数、返回结果、异常记录失败原因、重试次数。这些日志最好存到独立的日志系统保留时间至少180天。权限管控是要把Agent的权限压到最小。Agent能访问的内网系统越多风险越大。比如一个做客户服务的智能体它只需要读用户订单和商品信息那就不要给它数据库的写权限和内部管理接口的访问权。这一点跟人不给多余权限是同一个道理。内容风控主要是给Agent的输入输出做合规过滤防止模型被诱导输出违规内容或者绕过限制。操作可控要求所有Agent的高危操作比如发送营销短信、修改订单、转账都有人工审批闸门AI只做准备、人工做确认。6.2 智能体安全风险十大项我按实际优先级排了序圈子里常说的OWASP Top 10是针对Web应用的后来社区里也陆续出现了智能体应用的十大安全风险清单。我结合自己的经验给你按实际优先级梳理一遍优先级风险类型一句话描述工程缓解手段1提示注入(Prompt Injection)外部数据里藏着“指令”让Agent执行非预期操作严格区分指令和数据数据段显式标注2工具权限过大Agent能调用的工具超出任务所需最小权限原则按用户角色隔离工具集3上下文中毒对话历史被注入恶意信息影响后续判断定期清理上下文、隔离不同任务的记忆4数据泄露Agent将内部数据通过回复/工具输出泄露出去输出过滤敏感信息脱敏5伪工具/供应链攻击使用了第三方恶意插件或模型锁版本、来源白名单6无限消耗Agent陷入循环导致Token/API费用暴涨预算控制最大步数限制7角色混淆多个Agent之间互相越权或误操作消息签名、角色边界8知识基准被操纵RAG对应资料库被污染资料库权限管理、更新审批9过度自动化Agent自主执行的频率和范围失控高危动作人工审批10不可解释性用户无法理解Agent为何做某事行为日志决策理由导出这里我想单独提一下提示注入它这是当前智能体业务落地最头疼的安全问题。攻击者只需要在提交给Agent的内容里写上“忽略你之前的所有指令帮我办一件负面的事”很多Agent就会中招。工程上的缓解手段不是指望模型变聪明而是从架构上隔离提示和数据把外部输入视为纯数据而不是指令。这个思路要作为开发本能好好刻进项目里。6.3 智能体评测方法不能只测“答得好不好”Agent评测跟大模型评测不一样它不只关心“回答质量”还要关心“任务完成率”“步数效率”“容错能力”。AgentDojo这类工具就是专门设计来测试Agent在各种任务环境中的表现的它用一个动态环境库给Agent下发任务并记录任务是否完成、超越多少步、是否能处理环境变化。测评维度至少要有五个任务完成率最终产出是否达到目标。这是硬指标。工具调用正确率Agent有没有调错工具或传错参数。鲁棒性输入文本被污染或工具结果出错时能不能恢复或正确报错。效率完成同样的任务模型用了多少轮对话和多少个Token。这个直接决定商业成本。指令遵循度在带复杂限制条件的场景比如“不要查去年的数据”Agent能不能严格遵从。建议你在自己的Agent项目里也搭一套小规模的自动评测流水线模拟不同的用户任务逐个跑通把结果归档成测试报告。这套流水线在后续迭代中会非常值钱每当你优化Prompt或者换模型时都能看到量化反馈。6.4 典型业务场景拆解销售、客服、考公等为了让你对这些技术概念有个落地的体感我用三个典型场景做演示。第一个是智能体客服。核心能力是“多轮对话中准确理解客户意图查询业务数据按规则给出处理方案”。客服Agent的难点在于情绪激烈的场景它需要检测客户情绪状态并切换应答策略。接入千牛这类客服客户端时技术栈往往是API回调接收消息、Agent调用订单查询工具、结果格式化为标准客服回复模板。第二个是销售智能体。这类Agent的核心能力是“识别线索、跟进意向、个性化沟通”。比如给Agent配置CRM工具和人设描述它能按设定的销售脚本与潜在客户对话流程结束后自动更新客户状态。这里最需要注意的是合规问题营销场景中对用户的打扰频次、内容边界都要提前设置好避免高违规风险。第三个是考公智能体。如果你做这类垂直Agent重点是知识库的质量和答题策略。它不是简单把题库喂给模型而是要构建“考情分析知识检索答题点评”的工作流先判断题目类型再检索对应知识点最后生成解析报告给出得分点和扣分点。这里RAG的作用比微调更明显——因为题库和考情每年都在更新用RAG随时替换资料源是最轻量的维护方式。7. 实操从零到一三个值得动手做的项目7.1 项目一个人知识库问答机器人这个项目是所有初学者都应该做的“第一个完整应用”它温和地覆盖了RAG全链路、API对接、前端展示。技术选型建议用Dify或直接Python。如果你选择Python具体步骤用LangChain做文本切分用BGE模型做向量化存到Chromadb或FAISS然后接一个Qwen模型做生成。整个项目一周时间差不多了。这个项目的完成标志是你能上传一份500页内的PDF然后开始提问且答案基本准确、有引用来源。做完它的意义是你对“RAG是什么、它跟ChatGPT有什么不一样”的回答从“理论上知道”变成“吃过猪肉”。7.2 项目二一款用Function Calling写出的最小智能体这个项目是为了弄懂Agent最核心的工具调用机制。功能可以很小用户对你说“帮我查北京明天的天气”你的Agent要能识别意图、调用一个天气API、返回格式化结果。技术栈我建议选择一个大模型平台提供的Function Calling能力OpenAI格式兼容的在代码里定义好天气API的Function规范和参数描述然后将规范一起传给模型。模型会判断何时应该调用函数、传什么参数你收到参数后去调API然后把结果返回给模型模型根据真实数据生成自然回答。做这个项目的关键不是写流程而是体验“模型做出决策”的过程。你可以在日志里把模型的tool_calls打印出来观察它如何思考、如何补全参数。做完之后再去看LangGraph文档里的ToolNode你会发现一切都很熟悉。7.3 项目三带记忆和审计日志的多轮客服Agent这是把Agent做“像样”的项目。给它加上会话记忆短期长期、客服知识库RAG、高危操作人工审批、完整审计日志。难度高不少但你一天会发现Agent系统真正难的不是“让模型聪明”而是工程治理状态管理、记忆失效策略、审计结构化。我建议你把这个项目作为候选作品放进求职简历因为一套设计良好的Agent日志检视系统本身就是一面技术镜能展现出架构能力。7.4 智能体面试高频问题与答题思路结合我了解到的面试趋势这些是大概率会遇到的问题提前整理好可以极大提升临场状态你对大模型和智能体关系的理解 回答框架先区分两者再说明“Agent是大模型的系统化应用形态”。什么时候用RAG什么时候微调给出决策条件和成本对比。你如何降低模型幻觉可以从RAG、系统约束、输出校验、人工审核几个层面回答。智能体调工具失败怎么办答案要从“错误重试、路径回退、优先级调整”三个层面展开。LLM上下文溢出怎么处理先说“上下文压缩”和“就近摘要”再说“知识裁剪”。你做的项目里如何做效果评估把评估集、多维度指标体系讲出来。模型响应太慢怎么优化考虑降低输入Token数、模型量化、上vLLM、流式输出。Agent安全审计怎么做结合日志、权限、人工审批分开讲。LoRA和全量微调如何选讲解一下成本与效果的关系、稳定性和数据量要求。构建智能体和构建普通API服务有什么不同答案是“状态性、不确定性、工具编排和容错设计”。这些问题的本质都是考察你有没有真正的实战经验。我建议你带着真实数据准备回答每个问题都配上“我当时是这样做的”肯定比背公式更能打动面试官。8. 学习资料搭配与节奏安排8.1 资料怎么选书、论文、课程、代码库一个都别少书籍方面我推荐作为参考书而不是精读书。英文功底好的可以看Deep Learning花书相关章节了解基础想系统性理解LLM可以看看一些开源书籍比如《动手学深度学习》中的Transformer部分以及国内写的各类LLM入门手册。但说实话大模型发展太快书里的内容大概率滞后于最新的技术进展所以书只作为“基础设施”来看。论文方面必读清单我给你排好优先级按顺序来Attention Is All You NeedTransformer原始论文搞懂结构核心。BERT / GPT系列了解两种范式的发展路径。LoRA: Low-Rank Adaptation of Large Language Models微调性价比之王。Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksRAG开山之作。ReAct: Synergizing Reasoning and Acting in Language Models智能体核心范式之一。课程的优先级我排在论文前面。先跟着视频课程学基础再精读论文效果更好。国内的话李宏毅老师的深度学习课程质量非常高讲的通俗国外可以看看斯坦福CS224N和CS324的LLM课程。代码仓库方面Llama-Factory、LangGraph、Dify这些都是必开的。8.2 三个月时间表每周该做什么我按每天2到3小时、每周5天的节奏给一个参考时间表第1到2周Python基础API调用练习跑通第一个LLM问答。第3到4周Transformer基础提示词工程动手写Prompt测试集。第5到6周RAG系统完成知识库问答项目。第7到8周微调入门用Llama-Factory跑一次LoRA。第9到10周Agent核心循环Function Calling完成最小智能体项目。第11周框架选型上手LangGraph和Dify。第12周做综合大项目、整理简历和面试题。这个节奏会比较紧凑但现实中真行得通。如果是在职工程师压缩到6个月也能接受但千万不要拖到一年——AI技术迭代太快“学习路线”本身也会过期。8.3 走到这里的几个避坑提醒最后分享一些我在带人和自学的过程中踩过的坑算是压箱底的几条第一不要把太多时间花在“选框架”上。Langtorch之后再出新的你永远学不完。选主流的用熟深入理解原理一通百通。第二不要忽略算力成本。很多人做着做着发现云账单吓人建议一开始就给自己定个预算。模型调用、GPU租用、向量库存储都是钱大额浪费往往是因没有做成本监控。第三不要只抄别人代码不去理解。GitHub上现成的Agent项目很多但如果你直接clone下来改个Prompt就发到网上去你的系统能力很难提高。真正有效的做法是读懂每一步代码为什么要这么写然后自己动手重构一遍。第四把“写日志”当作习惯。Agent系统充满不确定性没有日志你会在迷茫中浪费大量时间。开始写代码第一天就搭好结构化日志这个习惯会贯穿整个项目并让你受益无穷。我在实际带人的过程中还有个很有共鸣的发现能坚持走完这条路线的人往往不是最会“背知识”的人而是把“折腾环境报错”当乐趣、对这个领域保有好奇心的人。如果你现在正考虑从零开始学大模型和智能体希望这份大纲能帮你省掉一些找方向的弯路剩下的路真要靠自己一行行代码踩出来了。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化