大模型学习路线全攻略：从本地部署、微调到Agent实战

如果你已经在搜索引擎里翻过一轮“大模型入门”，你大概率会陷入一种困境：资料太多、方向太杂、有的讲数学推导、有的上来就教你部署、还有的在讨论Agent框架，你根本不知道该从哪一块先下手。更麻烦的是，很多教程默认你已经有深度学习基础，或者默认你手头有一张顶配显卡，这对真正想系统性入门的人来说，非常劝退。

这篇文章就是干这件事的：我给你一条经过验证的、从零开始的大模型系统性学习路径，覆盖基础理论、本地部署、微调实战、提示词工程和Agent应用这五个核心板块。不管你是做后端开发的、搞数据分析的、在职的算法工程师，还是单纯想把自己的电脑用起来跑个本地模型，都能从这套资料里找到自己的入口。我把每个阶段要学什么、为什么要学、学到什么程度可以往下走，以及我自己在实际学习过程中踩过的坑，全部写清楚。

1. 先想清楚：大模型入门到底在学什么

很多人的第一反应是“我要训练一个自己的大模型”，于是直接去看Transformer的论文、去啃反向传播的数学推导，然后在一周之内放弃。我见过太多这样的案例了，包括我自己刚接触时也犯过这个毛病。实际上，大模型入门和深度学习入门有本质区别：你要学的不是怎么从零训练出一个模型，而是怎么在已有模型的基础上，完成部署、调用、微调和应用开发。这就像你学开车，不需要先学会造发动机，你要做的是把车开稳、知道车子的仪表盘在说什么、遇到故障能排查。

所以系统性入门的第一步，是给自己画一张地图，明确这条路上有几个必经站点，每个站点需要投入多少精力，学完以后能干什么。我按照自己的经验，把整条路分成四个阶段：基础准备、原理认知、实践上手、进阶应用。每个阶段之间是强依赖关系，但它们的依赖程度没有你想的那么强——你不需要把所有数学推导搞懂才能部署一个模型，你只需要理解关键概念，然后在实践中不断补课。

1.1 大模型不是“学”出来的，是“用”出来的

这是我反复跟新人强调的一句话。大模型的技术栈非常深，从底层CUDA优化到上层Agent编排，中间隔了好几个专业领域。如果按照学术路线，你先搞懂注意力机制、再学分布式训练框架、再研究推理优化，一套下来至少需要一年时间，而且很多知识在日常开发中根本用不上。但如果你先动手把模型跑起来，每天和它对话、写几个脚本调用它的API、尝试让它帮你完成实际任务，你对“大模型能做什么、不能做什么”的感知会建立得飞快。有了这种感知，再回头去看Transformer、看量化原理、看微调策略，每一个知识点都会变得鲜活起来，因为你已经踩过对应的坑了。

我自己带过几个从零开始转行的新人，他们的路径几乎都是先跑通一个本地模型，然后用它做一些小工具，比如让模型写周报、做摘要、抽取结构化信息。这些人坚持下来的概率远高于那些一开始就抱着一本深度学习教材啃的人。原因很简单：正反馈来得快。你在终端敲一个命令，一个能对话的模型就出现在你面前了，这种成就感是支撑你继续深入的最大动力。

1.2 入门路线图：四个阶段层层递进

我把路线划分为四个阶段，每个阶段都有明确的学习目标和产出物。第一阶段是打地基，包括Python基础、PyTorch基础、机器学习和深度学习的基本概念。这个阶段不需要太深入，能看懂代码、能理解loss和梯度是什么就够了。第二阶段是原理认知，你需要搞懂大模型的底层架构——Transformer、Token、注意力机制、训练流程，至少要能从概念层面讲清楚大模型为什么“大”、它和传统深度学习模型的区别在哪里。第三个阶段是实践上手，这也是最关键的一步：学会部署一个开源模型到本地，调用它，了解显存、量化、推理引擎这些实操概念。第四阶段是进阶应用，包括提示词工程、上下文工程、微调、以及Agent开发。到了这一步，你已经不是“会用大模型”了，而是“能用大模型解决实际问题”。

这条路线看着很长，但每一步的目标都有限定范围，不需要无限深入。比如第二阶段，你不需要能手推Transformer的全部公式，但你需要知道自注意力机制是在算什么、为什么Transformer能处理长序列；第三阶段，你不需要自己写一个推理引擎，但你要能说清楚量化是什么、为什么同样的模型在不同显存下表现不同。这样掐住每个阶段的深度边界，学习效率会高很多。

2. 打地基：没有这几块基础，后面处处踩坑

我知道你急着想跑模型，但有一些基础还是得先补。这里说的“基础”不是让你去重修数学系课程，而是指那些在实际操作中一定会碰到的东西。很多人部署失败、微调出问题、看论文看不懂，根源都不是因为某个具体操作错了，而是前置知识有缺口。我在这里给你划个范围，哪些必须学会，哪些可以以后遇到再补。

2.1 数学与编程：够用就好，不用重读本科

数学方面，你真正高频用到的是：线性代数里的矩阵乘法、向量、维度变换；概率论里的分布、期望、条件概率；微积分里的梯度、链式法则。这些概念在Transformer的原理、训练过程、推理计算中反复出现。但你不一定要会推导，我建议你达到的水平是：看到一段代码里的矩阵维度变换，能明白它这一步在做什么；提到梯度下降，能说出来它是在沿着loss下降最快的方向更新参数。这就可以了。高等数学里的级数、复变函数这类内容，基本不会用到，完全可以跳过。

编程方面，Python是必须的，至少要熟练使用列表、字典、函数、类、装饰器、生成器，还要会看报错信息、会调试。PyTorch是绕不开的，因为绝大多数开源大模型的代码都是PyTorch写的。你需要掌握的是tensor的基本操作、Dataset和DataLoader的使用、模型的保存与加载。不需要自己去实现一个完整的训练循环，因为现在的框架已经把底层封装得很好了，但你要能看懂别人写的训练代码，在报错时能定位到是数据问题、模型问题还是显存问题。如果你已经有TensorFlow的基础，迁移过来也不难，核心概念是通用的。

2.2 硬件与工具链：没有4090也能学

很多人一提到大模型，第一反应就是“没有好显卡玩不了”。这话只对了一半。如果你要做70B级别模型的全参数微调，那确实需要多张A100级别的卡，不是你个人电脑能承受的。但对于入门阶段的学习来说，你需要的硬件门槛远比想象中低。一张8GB显存的显卡就能跑7B量级的量化模型，16GB显存的话可以比较流畅地跑13B的量化模型。哪怕你只有CPU，也能通过llama.cpp这类工具运行小模型，就是速度慢一些。我甚至见过有人用树莓派跑过小模型，虽然性能不怎么样，但用来理解推理流程是够的。

工具链方面，有几个东西建议提前装好并熟悉。首先是命令行基础，因为大部分部署工具都是通过命令行操作的，不会基本命令会非常痛苦。其次是Docker，很多开源项目的环境依赖非常复杂，用Docker可以省去大量环境配置的麻烦。第三是Git，你要经常从GitHub上clone代码、查看release版本，这些操作离不开Git。这些工具不需要精通，能完成基本操作就够了。我在最初学的时候，因为这些基础工具不熟，前前后后浪费了很多时间在环境配置上，最后才发现用Docker一条命令就能解决。

3. 原理篇：从Transformer到ChatGPT，把黑盒变灰盒

如果你只是想把大模型当搜索工具用，那可以跳过这一节。但只要你想做微调、想开发Agent、想在问答效果不理想时知道怎么优化，你就必须对底层原理有一些理解。这不只是“面试要考”，而是因为它直接决定了你日常debug的方向。比如模型回答经常重复，你要知道这是解码参数设置的问题；模型记不住你给的长文档，你要知道这是上下文窗口的限制。这些都是原理层面的东西。

3.1 死磕Transformer的核心机制

大模型的基石是Transformer架构，这个架构的核心是自注意力机制。你可以用一个很简单的类比来理解：当模型在生成下一个词的时候，它会回看已经生成的整个序列，判断哪些词和当前要生成的词关系最紧密，然后给这些词分配不同的注意力权重。比如在“小明喜欢打球，他每周都_”这句话里，模型预测下一个词时，“小明”和“打球”的注意力权重会比较高，因为“他”指代小明，而“打球”决定了接下来大概率会说“去球场”之类的动作。这就是自注意力在做的事。

Transformer的另一个关键设计是位置编码。因为注意力机制本身不关心词的顺序，它只看词与词之间的关系，所以需要把位置信息也编码进去，让模型知道哪个词在前面、哪个词在后面。再往后发展出了旋转位置编码（RoPE）等改进方案，这也是现在主流大模型都在用的技术，它能让模型更好地处理长文本。理解这些之后，你再去看模型的参数量、层数、头数这些概念，就有坐标系了。7B模型指的就是有70亿个参数，这些参数在训练过程中被不断调整，最终学会了语言的统计规律。

3.2 大模型的“成长路径”：预训练、指令微调与人类对齐

现在的通用大模型不是一步训练出来的，它经历了一个类似“求学”的过程。第一步是预训练，用海量的互联网文本训练，目标是预测下一个词。这一步练出来的模型叫基座模型，它学会了语言和知识，但不太会“听话”——你问它问题，它可能只会续写一段文字而不是回答你的问题。第二步是指令微调，用大量“指令-回答”对让模型学会遵循指令，这是它能变成“助手”的关键。第三步是人类对齐，通过RLHF或DPO等技术，让模型的回答更符合人类的偏好，更有用、更安全。比如ChatGPT系列的模型就是走了完整的三步。

理解这个成长路径对你做微调极其重要。当你拿一个开源基座模型直接做问答时，它会表现得很奇怪，这不是模型质量差，而是它根本没经过指令微调。市面上的Qwen、Llama等模型大多发布了多个版本，Base版是基座模型，Instruct版或Chat版是对齐过的模型。你日常使用、开发应用时要选对齐过的版本，做领域预训练扩展时才会用到Base版。这个区分很多人一开始不清楚，结果拿Base模型做产品，效果一言难尽，还以为模型不行。

3.3 上下文窗口：大模型的“工作记忆”

上下文窗口是另一个你必须理解的概念。它指的是模型一次能“看到”的输入长度，通常用Token数来衡量。Token可以粗略理解为词或子词的拆分单位，中文一个汉字大概对应1到1.5个Token。上下文窗口决定了模型能记住多少对话历史、能处理多长的文档。当前主流的模型窗口从4K到200K不等，很多场景下的模型“健忘”，其实就是因为你给的材料超过了窗口大小，模型把前面的内容“忘掉”了。

处理超长输入是一个系统工程。一方面模型侧会通过RoPE、滑动窗口等技术尽量延长上下文长度，另一方面用户侧需要做好内容裁剪和分段。你在使用中如果发现模型对长文档的后半部分理解很差，大概率就是上下文超限了，这时不是换一个更聪明的模型就能解决，而是要把文档做摘要、分块、或者用检索增强的方式只把关键段落喂给模型。这个理解能帮你少走很多弯路。

4. 动手篇：本地部署一台属于自己的大模型

原理看得再多，不如亲手部署一次。本地部署是整条入门路径里正反馈最强烈的一步：当你第一次在终端里看到模型流式地吐出文字时，那种“我自己运行了一个大模型”的感觉，比看十篇教程都有用。而且部署过程中你会遇到大量真实问题——显存不够怎么办、下载慢怎么办、模型文件是什么格式、怎么对外提供API——这些问题每一个都能加深你对大模型运行机制的理解。

4.1 为什么入门阶段一定要先部署一次

我强烈建议你至少在本地跑通一次部署，哪怕你平时主要用的是云端API。原因有三个。第一，部署能让你直观理解模型的物理形态：一个模型长什么样、占多少磁盘、加载到内存或显存里是什么状态、运行时CPU和GPU分别承担什么工作。这些感知是纯调API永远建立不起来的。第二，部署能帮你建立成本意识。当你自己跑一次模型，看到显存的占用、TOPS（每秒操作次数）的消耗，你就知道为什么有些场景用云端API划算、有些场景必须本地部署。第三，部署是很多进阶操作的入口。微调完的模型要能上线服务，Agent要调用本地模型，这些都依赖部署知识。

部署本身不复杂，但现在工具链比较多，新人容易迷失在“该用哪个”上。我梳理一下主流工具各自的定位：Ollama适合最快跑通对话，一键安装，交互体验最好；llama.cpp侧重CPU推理和低显存场景，擅长各种量化格式；vLLM面向生产环境，主打高吞吐推理，是服务化部署的首选；HuggingFace Transformers则是学术研究和开发调试的标配，灵活度最高。对入门来说，建议先用Ollama把流程跑通，然后再去尝试vLLM，对比一下两者的差异。当你看到一个模型从下载到提供服务只需要几条命令时，你会有“原来这么简单”的感觉；当你换用vLLM，发现同样的模型吞吐量高了好几倍时，你对“为什么生产环境要选高并发方案”就有了真实的体感——这种对比就是最值钱的学习材料。

4.2 工具选型：从Ollama到vLLM怎么选

不同的部署工具没有绝对的好坏，只有适合的场景。Ollama的定位是“轻松上手”：它把模型下载、量化转换、推理服务全部封装好了，你只需要一条命令就能拉取并运行一个模型。它的默认端口是11434，启动之后你可以直接通过HTTP调用，也可以接入各种第三方UI，甚至能被Open WebUI、LangChain这些框架直接对接，非常方便。我自己的经验是，Ollama特别适合前期熟悉模型、做实验、快速验证想法，比如我想对比不同模型在同一个任务上的表现，用Ollama一条命令启动一个模型，比写脚本简单得多。

vLLM走的是“生产级推理服务”的路线。它的核心优势是吞吐量高，通过PagedAttention等技术把显存利用做到极致，特别适合API服务、大规模并发调用的场景。代价是配置更复杂，你需要自己写启动命令，指定模型路径、量化方式、并发参数等。它的默认服务端口是8000，兼容OpenAI格式的接口。如果你准备把模型作为正式服务对外提供，最终大概率要落在vLLM上。入门阶段建议：先用Ollama跑通，再用vLLM部署一遍同一个模型，体感差异会非常直观。到了这一步，你自然就理解了为什么生产环境里很少有人用HuggingFace的原始代码直接跑服务。

4.3 部署一台“能跑”但“不卡”的本地模型的实操流程

下面给你一套具体的操作流程。假设你用的是Windows或Linux系统，有8GB以上显存的NVIDIA显卡。我先用Ollama为例，因为它最快能让你看到结果。

第一步是安装Ollama。Windows用户直接下载安装包即可，Linux用户执行官方提供的一键安装脚本。安装完成后，打开终端验证一下：ollama --version。

第二步是拉取模型。以Qwen2.5系列为例，执行：ollama pull qwen2.5:7b。这会自动下载模型文件并做好量化。下载速度取决于你的网络，模型文件大概在4到5GB之间。如果你想跑更轻量的模型，可以选qwen2.5:3b或者llama3.2:3b。

第三步是运行模型。在终端执行：ollama run qwen2.5:7b。这会进入一个交互式对话界面，你可以直接输入问题测试。如果终端界面显示正常、模型能流式输出文字，恭喜你，第一个大模型已经跑起来了。

第四步，把模型变成API服务。启动另一个终端，执行：ollama serve，然后在浏览器或curl中访问：curl http://localhost:11434/api/generate -d '{"model": "qwen2.5:7b", "prompt": "你好"}。看到返回的JSON，说明模型已经具备对外提供服务的标准HTTP接口了。

如果你要部署量化的GGUF格式模型，可以把模型文件放到 llama.cpp 或 Ollama 的模型目录中，执行 ollama create 命令从本地模型文件创建新的模型标签。这个过程会做格式转换和量化校准，也是理解模型文件结构和量化过程的好机会——你能直观看到同一个模型在FP16、Q8、Q4这些不同量化等级下体积和效果的差异，这才叫真正把部署玩明白了。

4.4 部署后的三件套：API、WebUI、CLI

跑通一个对话模型只是第一步，真正让模型用起来，还要熟悉三件套：API、WebUI和CLI。

API是把模型能力集成进你代码的唯一途径。标准做法是调用OpenAI兼容格式的接口。比如用Ollama本地服务，你的Python代码可以这样写：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "用一句话介绍你自己"}] ) print(response.choices[0].message.content)

这段代码的意思是：把本地Ollama服务当作一个OpenAI兼容的服务端，你手里的代码可以不改框架直接切入。掌握了这套调用方式，你会发现很多现成的开源工具都能接上你的本地模型，这也是为什么我说部署是一切应用开发的入口。

WebUI是给非技术人员用的可视化界面。最常见的方案是Open WebUI，安装好之后你可以在浏览器里和模型对话、管理模型、配置知识库。它的安装也很简单，用Docker一条命令就能启动。如果你想让公司同事都能用本地模型，搭一个Open WebUI是最快的方案。

CLI是命令行接口，适合脚本场景和自动化。比如在shell脚本里调用模型做批量文本处理、定时生成摘要等。很多模型框架本身也自带CLI入口，比如llama.cpp的main命令、Ollama的run命令。这三个接口各有用武之地，你至少要熟练掌握API和CLI，WebUI知道怎么搭就行。

5. 进阶篇：微调不是猛料堆叠，是精准手术

当你把部署、调用、提示词工程都玩熟练之后，自然会遇到一个瓶颈：通用模型虽然聪明，但不懂你的业务。你问它公司内部的规章制度，它一脸茫然；你让它按照某个特定的写作风格输出，它总是做不到位。这时候你就会想到微调。微调是让大模型“进入某个行业”的核心手段，也是当前企业对大模型人才最重要的技能需求之一。

5.1 先搞明白微调的适用边界

微调不是万能的，很多场景下根本不需要微调。我见过不少团队一上来就微调，花了几万块钱的算力，结果效果还不如在提示词里多写100字描述。你要先学会判断什么时候需要微调。一般来说，下面这些信号出现时，才值得考虑微调：模型在你特定领域的术语理解很差，比如医疗诊断、法律条文、工业设备故障描述；模型的输出风格和要求不匹配，比如需要模仿特定文风、固定输出格式；模型缺乏你独有的知识，比如企业内部制度、私有数据；你用了提示词、加了检索增强，仍然达不到效果。

反过来，如果问题只是“回答不够准确”或者“偶尔出错”，那大概率是提示词或检索增强就能解决的。微调的代价不小，需要准备数据、消耗算力、做评估，而且还有过拟合和灾难性遗忘的风险。对入门者来说，最好的策略是：先尝试提示词工程，再尝试结合检索，最后才考虑微调。每一步都要设置明确的评估指标，用数据说话，而不是凭感觉。

5.2 三种主流微调方式怎么选

微调分三种：全参数微调、LoRA、QLoRA。全参数微调是把模型的所有参数都更新，效果最好，但需要极大的显存和数据集，对入门者基本不现实。LoRA是给模型增加少量低秩适配参数，只训练这些新增参数，原来的模型参数保持不变，这样显存占用大幅降低，同时效果在很多场景下逼近全量微调。QLoRA是在LoRA的基础上，把基座模型的权重量化到4bit，进一步降低显存门槛，使得消费级显卡也能微调大模型。

我建议你的入门策略是：先学QLoRA，它最省资源，在单张24GB显存的显卡上就能微调7B到13B的模型。等你熟悉了整个流程，再尝试LoRA，最后才去了解全参数微调的机制和挑战。理解这三种方式的区别，核心是抓住“哪些参数被更新”和“显存开销怎么变化”。QLoRA之所以能大幅降低显存，核心在于它把原先需要保存在显存中的全量模型权重压缩成了4bit的量化表示。这意味着原来要16GB才能加载的模型，现在只需要约5GB就能住进显存里，省下的空间全用来跑梯度计算。

5.3 数据质量比数据量更重要

微调的效果受三个因素影响：数据、数据、数据。这句话可能有点极端，但我在实操中确实发现，数据质量对微调效果的影响远大于模型选择、超参调整这些技术因素。一份好的微调数据集，应该满足几个条件。

第一，指令和回答都要清晰。你希望模型学会什么，就要给它什么样的样本。如果是做意图分类，每条数据都要有明确的意图标签和对应的回答。第二，覆盖要全面且均衡。不要绝大部分样本都是同一类场景，测试时你会发现模型对没见过的场景表现极差。第三，数据量不是越多越好。我见过不少团队盲目堆数据，十几万条样本丢进去训练，结果效果不如精心准备的几千条。原因是低质量数据混杂了大量噪声，模型学到了错误的关联。对大多数垂直场景，三五千条到一两万条优质样本已经能出不错的效果。几十万条以上属于“堆数据”的范畴，只适合从零预训练或领域预训练，入门阶段不建议尝试。

数据清洗是另一个容易被忽略的环节。原始数据往往包含HTML标签、重复文本、不完整的句子、错误标签，这些都要清理干净。我建议你写一个专门的数据检查脚本，统计每条样本的长度分布、检查是否有空样本、看标签是否均衡、抽样读几条确认质量。上线前做一轮数据清洗，能省掉后面排查问题的很多时间。

5.4 微调实操的训练参数参考

微调的核心超参数主要有这么几个：学习率、训练轮数、批大小、序列长度、LoRA的秩和Alpha。我给一个入门参考值，你在这个基础上按自己数据的情况再调。学习率一般设置为1e-4到2e-4之间，太大会导致模型训练不稳定，太小则收敛过慢。训练轮数通常3到5轮，你可以观察loss曲线，如果训练后期loss下降明显变慢，就说明模型开始收敛了。批大小受显存限制，通常设置为1到4，配合梯度累积来弥补小批量带来的不稳定。序列长度要根据你的数据来定，一般取512到2048，太短会截断信息，太长显存压力大。LoRA的秩r通常设置8到64，越大代表新增参数越多，表达能力越强，但也更容易过拟合；Alpha一般设为r的两倍。

我建议微调流程做一个闭环：先准备少量数据试跑一次，看看训练loss是否下降、loss是否在预期范围；然后保存模型，手动测试几个典型case，看效果是否符合预期；接着把效果不符合预期的case加进训练数据，再做一轮。这样一轮一轮地迭代，比一次性训练一个大模型然后靠“祈祷”有效得多。我自己常用的流程是：先用200条数据跑通整个微调链路，确认无报错，再逐步扩大数据量到2000条、5000条。这样每一步都能验证模型质量，不会白白浪费算力。

6. 应用篇：提示词工程、上下文工程与Agent实战

部署和微调解决的是“模型能力”问题，而应用层解决的是“怎么把能力落到业务中”的问题。这一层的核心技能包括提示词工程、上下文工程、以及当前最火的Agent开发。很多人在原理和部署上花了大量时间，到应用层反而容易忽视。但坦白讲，如果你的目标是在工作中使用大模型或做AI应用开发，应用层技能带来的产出增量是最大的。

6.1 提示词工程：把模型当作聪明但固执的新人

把大模型想象成一个知识渊博但缺乏常识的新员工：你问得笼统，它给得就泛；你把规则说得越明确、示例给得越具体，它的输出就越接近你想要的结果。这就是提示词工程的核心逻辑。它不只是“写好一段prompt”，而是要你系统性地设计：(1) 角色和任务定义，(2) 输入输出格式，(3) 约束条件和禁止事项，(4) 示例（Few-shot样例）。

我在实际项目中常用的方法是：把你想要的行为拆解成一条条明确规则，再用两到三个正反例告诉模型“什么样是对的、什么样是不对的”。很多模型对“禁止事项”不敏感，但对“正例”和“反例”的对比学习效果很好。提示词也不是一蹴而就的，要像调试代码一样迭代：每次调整一个变量，对比输出效果，保留有效的改动。我在给团队做培训时经常举一个例子：一个客服咨询分类任务，第一版提示词写的是“帮我分类用户问题”，效果惨不忍睹；后来改成“你是客服工单分类专家，请根据以下规则将用户问题分类为退换货、价格咨询、物流查询、投诉建议四类，每个类别给出置信度和理由”，并附上8个示例，准确率直接提升了几十个点。提示词工程的本质，是把你脑子里的行业知识翻译成模型能理解的语言。

6.2 上下文工程与Agent：决定大模型能不能“长脑子”

提示词工程的另一个升级方向是上下文工程。简单来说，上下文工程解决的是“模型看不到它能看的所有信息”的问题。比如你要让模型基于一份几百页的合同做分析，但模型的上下文窗口只有32K，根本装不下全部内容。这时候你要做“上下文管理”：把文档切块、用向量检索找到相关段落、再把检索结果和问题一起拼进提示词里，这个组合就是当前大模型应用中最主流的RAG（检索增强生成）模式。

Agent则是更高阶的一层。Agent的本质是让模型变成一个能动起来的执行者：它不仅能“说”，还能“做”。比如你给它一个任务“帮我查一下本周的销售数据并生成一份周报”，Agent会把任务拆解成多个子步骤，调用数据库API、生成图表、写周报。当前主流的Agent框架有LangChain、AutoGen、以及各模型厂商自己的Agent API。入门阶段我不建议直接套太重型的框架，可以先从“手工写Agent循环”开始：定义一个工具函数，让模型决定调用哪个工具，把工具返回结果喂回模型，再让模型决定下一步。这样你才能理解Agent的本质是什么。等你理解透了，再去看LangChain等框架，就会觉得那些抽象概念都有了实体。市面上关于Agent的教程很多，但大多是教你怎么用框架，很少有讲清楚“模型怎么决定调用工具的”以及“多轮工具调用的状态管理怎么做”这两个核心问题。这两个问题才是Agent开发真正的难点。

6.3 场景选型：云端API还是本地部署

这是企业落地时最常被问的问题之一，跟你的具体场景强相关，不是一个简单的“哪个好”就能回答的。你需要从数据安全、成本、实时性、扩展性四个维度综合判断。

如果业务场景涉及敏感数据，比如医疗记录、客户信息、内部代码库，那基本只能本地部署，数据不能出内网。如果场景对实时性要求极高，比如工业产线质检，网络抖动会导致不可接受的延迟，本地单机部署也几乎是唯一选择。反过来，如果你的调用量不稳定、峰值流量忽高忽低，或者你对模型能力要求很高但不希望自己管理GPU集群，那云端API更合适。成本方面，云端API按token计费，适合低频或者短期项目；如果你长时间的稳定调用量很大，本地部署的边际成本会更低，但前期需要买显卡、维护服务器。

我之前遇到过有人问：“工业检测、服装检测这类AI用的是云联网还是单机的AI，用的什么大模型足够？”这类场景的核心特征是数据不宜出车间、实时性要求高、容错率低，所以必须本地部署专用模型。至于选什么模型，通常不需要用千亿级大模型，一个7B到13B的通用多模态模型微调后就能满足大部分质检分类需求，便宜而且速度快。另一个常见问题：“如何使用大模型分析不同股票的K线图？”这种属于分析辅助型任务，对数据实时性要求不高，云端API可以完成文本分析，但如果涉及交易嗅觉的实时性，最好还是本地部署配合量化数据库。把这些问题想明白了，你选型就不会犯大错。

6.4 一个完整项目：从选题到交付的入门实战

学完所有理论知识，最重要的一件事是做一个完整的小项目。项目不一定要高端，但一定要贯穿整个流程。我推荐的一个入门项目：构建一个内部知识库问答机器人。具体来说，你选一个你熟悉的领域，比如公司内部的产品手册或规章制度，收集几十页文档，做切片和向量化存储；然后用一个开源模型做本地部署或云端API；实现一个检索增强的问答接口；最后把它封装成一个简单的Web界面或命令行工具。这个项目做完，你至少打通了文档处理、向量检索、模型调用、提示词设计、应用封装整条链路。这个过程中你一定会遇到各种意想不到的坑，但所有的坑都是学习的机会。

我见过很多人学了一堆教程，却始终没有输出过一个完整作品，这是最大的问题。判断你是否入门，标准只有一个：你能不能在没有人指导的情况下，独立完成一个从数据到模型再到应用的闭环。能，就是入门了。

7. 常见坑位与避坑实录

最后这部分，我把带新人时最常遇到的坑集中列一下，你可以作为自查清单用。

7.1 新手最容易踩的六个坑

第一个坑，万事开头就问“用什么框架”。其实在项目早期，框架选择对整个技术路线的影响微乎其微，python+requests就够了。真正影响效果的是数据质量和模型选择。所以我建议你先拿最简单的框架把流程跑通，再根据瓶颈迭代。第二，模型选型一上来就用70B甚至更大。大模型能力强，但部署成本也高，很多任务用7B就够了。先评估任务复杂度，再选模型，这才是理性做法。第三，数据准备阶段不写脚本检查。很多新人直接把原始数据丢进微调流程，结果训练结束后才发现数据里全是乱码和重复文本。我之前说过，数据清洗这一步省不了。第四，提示词反复改但从不记录版本。有效的提示词工程是需要版本管理的，改哪个变量、效果如何变化，都要留痕。我用过最简单的做法是给提示词写注释，标注每个参数的调整日期和目的，后来发现问题定位效率翻倍。第五，微调后只测一个case就判定效果。测试要覆盖不同场景，至少三十到五十个有代表性的case，才能对模型效果有客观判断。第六，忽略了评估指标。做微调和提示词优化一定要有量化指标，比如准确率、召回率、用户满意度评分，否则你永远不知道自己的改动是不是真正变好了。

7.2 常见问题速查表

我把平时支持“大模型入门”同学时反复回答的问题整理成了表格，方便你按图索骥。

7.3 怎么辨别“官方”资源与山寨网站

这里必须多说一句。大模型领域的官方资源，基本都在GitHub仓库和官网，使用公开的GitHub、HuggingFace、模型官方站点等正规渠道下载即可。但我也观察到，网上存在大量“大模型官网下载”之类的链接，点进去可能并不是真正的官方渠道，甚至会诱导用户下载来路不明的安装包。判断一个站点是否可靠，我给你三个标准：一是看域名，官方域名通常就是模型的官方品牌；二是看是否使用官方GitHub仓库或经过认证的模型托管平台；三是对于那些声称提供“一键安装”“绿色破解版”的链接，一律保持警惕，大模型本身是开源的，不存在需要“破解”的版本。

7.4 关于入门心态的几点唠叨

最后，分享几句我在带人过程中反复说的话。第一，学大模型一定会遇到挫折，遇到问题时先确认信息，再动手操作，不要病急乱投医。第二，动手永远是第一位的。看一百个视频教程不如自己跑一次模型，踩一个坑获得的成长远超看懂一百页文档。第三，保持记录习惯。我在整个学习过程中，坚持在博客上记录每个项目的思路、问题和解决方案，很多当时的顿悟其实都是整理笔记时想通的。这套资料虽然叫“系统性入门资料”，但我更希望它成为你动手实践的路标，而不是又一个收藏夹里的吃灰链接。把文档合上，去跑一个模型，遇到问题再回来翻，这才是它真正的价值所在。