这几年大模型相关的文章铺天盖地但大部分要么只讲某个单点技术要么停在介绍一下最近有什么新模型的层面。真正能把整条链路串起来讲清楚的文章反而很少。如果你也想搞懂从一堆语料到一个能自己调用工具、拆解任务的Agent之间到底发生了什么这篇综述就是给你写的。我会从预训练开始一路讲到后训练、推理侧工程最后落到Agent智能体上。代码级别的东西不会展开太多但每个阶段最关键的设计逻辑、最容易踩的坑、以及实测下来值得注意的经验我都会尽量交代清楚。不管你是刚入门的技术爱好者还是已经在做AI应用开发的工程师这条链路读下来至少能建立起一个不虚的全局框架。1. 预训练模型能力的原点预训练是所有大模型的起点。很多人用它的时候只关心哪个模型强但如果不理解预训练阶段到底做了什么后面遇到的很多问题——为什么越大的模型越难伺候、为什么某些任务一定要微调、为什么上下文一长就犯迷糊——你都没法真正想明白。1.1 数据管线与Tokenizer一切能力的地基预训练的第一步不是写模型结构而是攒数据。你可能听过数据即特征工程这种说法放到大模型时代数据管线的优先级比模型结构还要高。我自己在本地复现小规模预训练的时候最深的感受是模型结构抄别人的就能work数据管线如果偷懒损失是肉眼可见的。一条正经的预训练数据管线至少包含几个环节收集、清洗、去重、过滤、配比。收集阶段中文社区常见的开源来源是Common Crawl的中文子集、各类开源语料比如WuDaoCorpora、以及爬取的网页正文。但原始爬虫数据脏得一塌糊涂HTML标签、广告文本、乱码、重复段落到处都是所以清洗阶段必须做。一般会用语言识别过滤掉非目标语言的页面用规则模型把低质量文本筛掉再用MinHash、SimHash这类算法做大规模去重。这里有个容易忽略的细节去重不只是去完全重复还要做模糊去重。很多互联网内容只是换了标题重新发布正文几乎一样这些重复数据会严重拉低模型的知识多样性。配比阶段更像个玄学活。通用文本、代码、数学、多语种各占多少比例直接决定了模型的天赋倾向。比如代码比例加多了模型在逻辑推理类任务上往往表现更好数学语料虽然占比不大但对提升科学推理能力很关键。业界一个大致经验是代码和数学类语料合计可以占到20%-30%剩下的以通用文本为主。这个比例没有绝对标准但你可以把它理解成喂什么草出什么奶。Tokenizer是另一个被严重低估的环节。大模型在预训练时要先把原始文本切成一堆tokenBPEByte Pair Encoding是最主流的切法。它会把高频词保留为整词低频词拆成子词甚至单字符。测tokenizer好不好用有个土办法同一段中文文本不同tokenizer切出来的长度能差一倍以上。中文场景下如果词典里中文词覆盖太少一段200个字的中文会被切成300多个token不仅浪费上下文窗口还影响模型对语义的理解。所以你看有些开源模型专门扩大中文词典就是为了一口气解决这个事。1.2 架构选择为什么是Transformer一统天下模型结构这块业界的答案算是非常统一了以Transformer为基础几乎清一色用Decoder-only架构。早期大家在Bert那种Encoder-only和GPT这种Decoder-only之间纠结过后来发现Decoder-only在文本生成、代码补全、以及后续的Agent场景里通用性最强而且训练起来也稳。OpenAI带了一波节奏现在开源生态基本以LLaMA/Qwen系架构为事实标准。Transformer核心是自注意力机制。它的作用是让每个位置的token都能看到序列里所有其他token从而建模长距离依赖。但直接做全局注意力有个致命问题计算量是序列长度的平方。为了解决这个现代大模型基本普及了GQA分组查询注意力——把多个query头共享一组key/value算力省了效果损失却很小。你如果手头有张消费级显卡想跑大模型GQA其实是模型能不能塞进显存的关键设计。位置编码也演变了好几代。最初的绝对位置编码不擅长外推更长的序列后来有了RoPE旋转位置编码让模型通过旋转向量来感知相对位置关系。RoPE的厉害之处在于它天然支持外推配合推理时的缩放手段很多模型可以超出训练长度继续生成而不立刻崩溃。你现在看到各家模型动不动宣称支持128K上下文背后基本都离不开RoPE。再往后是MoE混合专家。这个设计思路是不增加计算量也可以扩大参数量。把一个大模型拆成多个专家子网络每个token只激活其中一部分专家。典型的例子是Mixtral 8x7B总参数56B推理时只激活13B左右效果却接近同体积稠密模型的两倍。不过MoE也给显存调度和推理框架带来额外复杂度部署时不能只按激活参数量算显存。1.3 Scaling Law为什么大力出奇迹是物理规律你可能听过大力出奇迹这个调侃但大模型的能力增长确实可以写成一个近似公式。OpenAI那张经典的Scaling Law的图说明模型性能随着参数量、数据量和计算量的幂次增长而稳定提升基本没有天花板。其中一个著名的结论是模型参数量、数据量token数和训练计算量之间存在近似关系 (L \approx \frac{N \cdot C}{6D})其中 (N) 是参数量(C) 是计算量(D) 是数据量。实际指导意义是增大模型和增大数据要同步进行单独一路加码收益会递减。Chinchilla那篇论文更是给出一个直观参考对于一个 (N) 参数的模型理想的训练数据大概要 (20N) 个token。也就是说一个7B参数的模型理想状态下要训练约1400亿token。早期很多模型其实都是欠训练的——参数很大但语料不够后来各家发现后拼命补语料效果才提上来。这个视角对理解为什么模型越做越大很重要。参数规模决定模型性能的潜在上限但能不能发挥出来靠的是数据量喂够、计算量跟上。你要是想在小规模设备上复现一个模型玩别贪心参数量和数据量按这个比例配训练曲线才会健康。预训练阶段还有个现象叫涌现能力。某些能力比如复杂推理、上下文学习在模型小的时候几乎为零但超过某个参数规模后就突然冒出来。对Agent特别关键的一点是工具调用、函数遵循这类能力也是在预训练阶段打下基础的。代码语料教会了模型理解结构化格式JSON、函数签名、API调用模式这些模型都是先从大量代码里见过世面后面做对齐才顺理成章。2. 后训练与对齐决定模型好用不好用的分水岭预训练出来的模型严格说只是个续写器。你问它中国的首都是哪里它可能给你续一段百科也可能顺着哪里接一句抒情散文。要让它变成一个懂得人类指令、不胡说八道的助手必须走完后训练阶段。2.1 指令微调SFT的实测经验指令微调Supervised Fine-TuningSFT的逻辑很直接用一大批指令标准回答的数据把模型的续写行为矫正成回答用户问题的行为。这是门槛最低、也是大多数做微调的人最先接触的环节。做SFT最关键的技能是造数据不是调参。业界有个共识指令数据的质量远重要于数量。几万条精心整理、覆盖场景广泛的数据效果往往好于几十万条从互联网抓来的噪声数据。质量不行的数据尤其可怕——它教给模型的是错误偏好后面RLHF都很难掰回来。我实操微调的时候超参数方面有几个经验可以分享学习率常规预训练的峰值学习率在 (3 \times 10^{-4}) 量级SFT通常要更低集中在 (1 \times 10^{-5} \sim 2 \times 10^{-5})压太高会导致灾难性遗忘——模型突然只会说新数据里的风格原本通用知识崩塌了。Epoch数不要贪多1到3个epoch通常就够重复训练太多轮模型容易过拟合到指令模板上。填充与打包训练数据要用Pad对齐到统一长度也可以把多条短样本packing到一条长序列里提高显卡利用率。我做7B模型微调时用packing比直接pad大概省了30%的时间。SFT阶段最容易犯的错是拿少量数据硬怼期待模型顿悟新能力。比如你想让模型学会工具调用就找了几百条调用示例去微调结果模型学会了格式化输出但一遇到没见过的工具就懵。真正的工具调用能力需要大量多样化的工具描述、参数格式、执行反馈数据的组合训练而且要覆盖足够的调用失败后如何处理的场景。这个认知一定要建立起来。2.2 RLHF与DPO从学霸到会来事SFT做完模型已经能懂人话了但还有个问题它会一本正经地胡说八道而且回答风格生硬机械。RLHF基于人类反馈的强化学习就是来解决怎么说的问题。RLHF经典流程分三步。第一步训练一个奖励模型Reward Model它的任务是给模型的输出打分哪些回答是人类喜欢的哪些是没人味的。第二步让策略模型就是你要调教的模型针对一批提示词生成回答用奖励模型打分。第三步用PPO这类强化学习算法更新策略让模型输出的奖励期望越来越高。为了防止模型为了刷高分变成奖励黑客——比如输出一堆讨好奖励模型的漂亮废话——还会加入一个和参考模型的KL散度约束控制模型不要偏离太远。这套流程效果很好但工程复杂度高要同时跑策略模型、参考模型、奖励模型和Critic模型逻辑上4份模型副本显存和训练稳定性都被折腾得够呛。于是后来出现了DPO直接偏好优化思路是绕开奖励模型直接用人给出的偏好对 \\text{chosen} \ vs \text{rejected}\ 来更新策略。公式里有个超参数 (\beta) 控制对参考模型的偏离程度一般取0.1左右让模型在变得更讨喜和别跑偏之间取平衡。DPO的优势是省了一套奖励模型训练流程我自己实测DPO对小模型的偏好对齐效果很直接尤其在控制回答风格、减少无意义安全拒答方面立竿见影。但它也不是万能的它只能处理偏好数据能表达的东西如果偏好本身没覆盖到的敏感问题DPO依然管不住。这个阶段有个非常重要的认知对齐不等于抹杀能力。做得过度的RLHF会让模型变得温吞、什么都不敢说、创造力下降业界调侃的对齐税就是这个意思。你要是做产品一定要留好对齐前的模型做对照实验防止把模型调教成一根只会说漂亮话的木头。2.3 评测视角如何判断模型真的变好了每次做微调或者对齐我都被问同一个问题效果到底变好了没如果不建立一套评测方法那就只能靠肉眼感受很容易被几条例子骗了。工业界常见的评测分层大概是这样评测层级典型数据集/方式解决的问题知识问答MMLU、C-Eval、MMLU-Pro模型掌握多少跨学科知识推理能力GSM8K、MATH、HumanEval数学/代码/逻辑推理是否扎实指令遵循IFEval、FollowBench是否准确完成用户约束真实产品指标线上A/B、用户留存最终业务是否有收益我的建议是论文刷分表可以参考但自己的评测集一定要自己建。把你产品里真实的用户问题挑一两百条出来做好标准答案或评分标准每次微调完一个版本就跑一遍看涨跌。模型在公开排行榜上刷分跟我们实际应用场景的优化方向经常是两回事。3. 推理侧工程从裸模型到可用工具很多人拿到一个开源模型下载下来跑通demo之后下一步就蒙了怎么让它变得又快又稳怎么接入业务这一阶段的知识业内叫做推理侧工程。虽然它不像训练那么高大上但在真实应用里它决定了一个模型能不能落地。3.1 上下文工程与提示词设计现在模型能力越来越强传统那种写个精心雕琢的prompt让它听话的做法正在逐渐让位给一套更系统的上下文工程。为什么因为模型本质上是一个极度依赖上下文的系统。你给它什么资料、什么格式约定、什么示例它就直接按那个模式工作。提示词设计里面的第一原则是把规则说清楚把格式定死。比如你想让模型输出JSON别只说请以JSON格式返回要给出完整的JSON schema示例明确字段类型和约束。像如果……则输出 [AWARD]否则输出 [REJECT]这种标签式约定比单纯用自然语言说请判断要可靠得多。Few-shot示例也很有讲究。给一个例子是引导格式给两个三个是强化模式。我试过在数据抽取场景里放3个包含边界情况的示例后抽取准确率直接从70%升到85%以上。但示例也不能太多太长的上下文既增加延迟又可能让模型把示例里的错误模式也学走。上下文工程还有个大坑叫上下文迷失。网上流传很多全体翻译全体忽略的提示词攻击本质上就是利用模型对上下文中不同位置信息的关注程度不均。有研究发现模型对长文本开头和结尾的内容关注度高中间容易被忽略。所以如果你要喂长文档重要的约束条件放开头和结尾比塞中间有效得多。3.2 RAG让模型查资料再回答想让模型回答新鲜知识或在私有知识库上做问答靠微调是不划算的。今天微调一次明天换了一批文档又得重来。RAG检索增强生成的思路更优雅不指望模型记住所有知识而是在回答前先查一遍资料库把相关资料塞进上下文让模型基于这些资料回答。一个标准的RAG流程分四步走文档切分把PDF、网页、Word文档切成一段段文本块。切分是RAG质量的关键切太大检索噪音多切太小语义不完整。我实测纯中文文档按500-800字切分重叠50-100字效果还算均衡。向量化用Embedding模型把每个文本块转成向量。检索把用户问题也转成向量做相似度搜索找出Top-K最相关的文本块。生成把检索到的文本块用户问题喂给大模型让它基于检索内容作答并且明确要求如果资料不包含答案就直说不知道。RAG这条链路里很多人以为瓶颈在Embedding或大模型其实最容易翻车的是切分和检索。切分不当会让一句话被腰斩成两段检索自然搜不到。检索到了但排名不准又会让正确答案淹没在噪声里。我后来给项目加了一路重排Rerank模型把向量召回的结果再用交叉编码器精排一遍整体回答准确率又有明显提升。如果你在做一个正经的知识库问答产品重排基本是标配。和RAG齐名的一个方向是长上下文微调。其实就是把上下文窗口从4K、8K一路撑到128K甚至1M。但注意窗口变长不只是改位置编码的事训练数据里要有足够多的长序列样本模型才能真正学会利用长上下文。很多号称支持128K的模型实际喂到60K就开始丢细节了。所以做产品别迷信长窗口能检索别硬塞又慢又费钱质量还不保证。3.3 部署与加速量化、KV Cache与推理框架推理部署这块核心目标就一个在成本可控的硬件上把延迟压到可接受范围吞吐量提上去。先说量化。大模型的权重默认是FP16格式每个参数占2字节。一个7B模型FP16权重就有约14GB光权重就把消费级显卡快挤爆了。量化就是降低权重精度把FP16压缩成INT81字节甚至INT40.5字节。INT4量化之后7B模型的权重约3.5GB一张普通显卡就能跑。代价是极低精度下可能出现质量损失好在现代量化方法比如GPTQ、AWQ在4bit下已经把损失控制得比较小。我个人的经验是7B以下模型做INT4要谨慎偶尔会冒出明显的逻辑错误13B以上模型做4bit量化损失就小得多属于以量换质的值当买卖。推理阶段另一个吃显存的大户是KV Cache。生成文本时模型每算一个新token都要把之前所有token的key和value缓存下来避免重复计算。序列越长KV Cache越大。一张8GB显存的卡跑一个7B模型上下文稍长一点就爆显存多半是KV Cache的锅。公式可以粗略这么算KV Cache大小约等于 (2 \times L \times H \times N \times P_{size})其中 (L) 是序列长度(H) 是隐藏层维度(N) 是层数(P_{size}) 是精度字节数。这个算下来你就能理解为什么大家都在用GQA、为什么需要流式推理。推理框架的选择上如果只是个人玩vLLM基本是首选。它用PagedAttention管理KV Cache内存利用率高吞吐量是原生Transformers的好几倍。服务端要做并发和流式输出也很方便。TensorRT-LLM适合NVIDIA GPU上极致压榨性能部署复杂度高一些。llama.cpp则适合CPU推理和边缘设备。选框架的核心逻辑是先定硬件和后端再选框架不要为了强而强行上不熟悉的框架。4. Agent模型从生成文字到完成任务如果说前三个阶段解决的是模型能说会道Agent要解决的就是模型能干实事。看到这里你会明白Agent其实不是凭空冒出来的新物种它是建立在预训练对齐推理工程之上的应用形态。让模型自己拆解任务、调用工具、根据结果调整下一步这就是智能体的核心。4.1 Agent核心机制ReAct与工具调用Agent最经典的工作机理叫ReActReasoning Acting思路是让模型在思考和行动之间循环交替。具体来说给定一个任务模型先输出思考过程Thought然后决定要调用哪个工具Action传入参数并得到工具返回的观测结果Observation然后再思考下一步循环下去直到得出最终答案Final Answer。这个循环写成一个提示词模板大概是这个意思你是一个智能助手可以按以下循环工作 Thought: 分析当前情况和下一步该做什么 Action: 调用某个工具格式为 {工具名称(参数)} Observation: 工具的返回结果 Thought: 根据返回结果决定下一步... Final Answer: 给出最终答案真正的工程实现里工具调用的标准做法是Function Calling。模型在输出时不只是生成自然语言还会生成一个结构化的函数调用指令比如{name: search_web, arguments: {query: 2026年最佳AI论文}}。后端解析这个JSON后执行真实函数把结果作为消息返给模型。这里有个经验之谈工具描述一定要写清楚。同样是搜索工具搜索某个关键词并返回前三条最相关的结果和搜索网页两种描述模型在什么场景下触发调用准确率差别极大。工具调用还有个大坑模型经常幻想参数。比如你给它一个天气API说明只支持中国城市它一激动传进去一个New York。所以做工具封装的时候参数校验逻辑一定要放在模型外面让程序兜底而不是指望模型每次都不犯错。4.2 记忆、规划与编排把Agent串成系统一个实用的Agent不能每轮对话都六亲不认。得有记忆才能在多轮交互中保持连贯得有规划能力才能拆解复杂任务。记忆在工程上一般分成两层短时记忆就是对话历史直接塞进上下文窗口。长时记忆把重要信息抽取出来存到向量数据库或普通数据库里下次需要时再检索回来。长时记忆怎么做才不鸡肋有很多流派。一种做法是对话摘要每轮对话结束后由模型生成一段摘要存起来来新对话时把摘要调出来当背景另一种做法是按用户/项目维度把用户偏好已完成任务这些结构化信息抽出来存属性表。你可以理解成短时记忆是电脑里的草稿纸长时记忆是云盘。真正强大的Agent一定要善于把用过就忘的信息沉淀起来。规划这块主流的框架有两种思路。一种叫Plan-and-Execute模型先把任务完整拆解成子任务清单然后逐一执行。另一种是纯ReAct式的迭代规划每次只决定下一步干什么。前者的好处是步骤清晰、可追溯但容易在遇到意外时死板后者的好处是灵活但可能失控。实际产品里我见到最多的是混合式大任务先生成计划框架每个子步骤执行时再走ReAct循环。编排还有一个层级问题。单个Agent调用多个工具只是最基础的工具增强更复杂的场景会让多个Agent协作。比如一个研究型Agent先检索资料把结果丢给写稿Agent整理成文再丢给审校Agent检查事实错误。多Agent系统听起来很酷但代价是上下文开销成倍增长、错误传播链变长、调试困难。我的建议是别为了Agent而Agent能用单个工作流解决的事别硬上多Agent架构。4.3 框架选型与安全别在最后一步翻车现在Agent开发框架多到让人眼花缭乱LangChain、AutoGen、MetaGPT、CrewAI、自研的都有。不过如果你问我个人看法框架是手段不是目的。框架帮你省掉的是底层调用模型、维护会话、封装工具这些脏活但真正决定Agent智商上限的还是你的任务编排设计、工具质量、以及提示词里的约束是否到位。我在项目里实际用下来的感受是先用最薄的自研封装跑通端到端确认问题所在再引入重框架。很多场景里一个简单的while循环加上Function Calling就能跑出很不错的效果。等并发上来了、需要多轮多Agent协作了再去上LangGraph这类偏底层的编排框架反而顺手。框架选型的本质是选抽象层次别被框架教程带着走。安全方面是Agent最容易翻车的点。主要体现在几个层面提示注入恶意用户可以把一些隐藏指令藏在检索到的文档里让模型执行忽略系统指令之类的操作。解决思路是对模型输出做校验敏感操作加二次确认工具系统和模型上下文隔离。数据泄漏Agent调用的工具会携带大量信息隐私数据可能在模型输出中被间接带出来。要做权限隔离和数据脱敏。工具滥权给Agent的工具应该按最小权限原则赋予——只需要读的别给写权限只查天气的API别给文件删除权限。做Agent安全评测一个很土但有效的方法是准备一批恶意文档和越权指令拼接进检索库然后观察Agent会不会真的执行危险操作。发现漏洞后针对性加固比幻想一个完美安全方案有用得多。最后无论你用的是开源模型还是API都必须注意Agent的有效性是脆弱的。同一个Agent工作流换个模型可能就瘫了半截。模型升级后第一件事不是看新模型的成绩单而是把你自家的Agent评测集跑一遍看看任务成功率有没有波动。这几乎是我踩过最多次的坑了。写在最后的一点个人经验把这条链路从头走到尾我的体会是大模型技术并没有哪一步是魔法。预训练给能力地基后训练让能力可用推理侧工程把能力变成产品Agent再把产品变成会干活的数字员工。每一步都有它自己的坑而坑和坑之间还经常互相牵连。如果你想入门我确实建议你别一上来就追最火的多Agent框架先老老实实把一个开源模型部署起来做两轮SFT再手写一个带工具调用的ReAct循环把所有环节亲手趟一遍。这个过程走完你再看任何一篇新技术文章都不会再觉得云里雾里了。最后再分享一个小技巧当你的Agent产品出问题时先别急着赖模型。把输入输出日志打开看看是哪一轮ReAct思考错了、还是工具返回的数据不对、还是上下文被截断了。90%的Agent失败都不是模型不够聪明而是系统设计没照顾到模型的边界。想清楚这一点你的调试效率能翻倍。