大语言模型原理、微调与agent开发

很多人学大模型是跳着学的：先跑通一个 Agent demo，回头发现不知道 token 怎么算、微调数据该怎么准备，卡在半懂不懂。这篇按原理、微调、Agent 三段给一条顺序清楚的学习线，每段说清该懂什么、动手做什么、什么情况下可以跳过，以及后面哪些坑是因为前面没学扎实造成的。

很多人学大模型是跳着学的：先跟着教程跑通一个 Agent demo，回头发现不知道 token 怎么算、上下文为什么爆、微调数据该怎么准备，于是卡在半懂不懂的状态。报错的时候分不清是模型本身不行、还是编排写错了，调来调去全靠猜。

这篇按原理、微调、Agent 三段给一条顺序清楚的学习线。每段说清该懂什么、动手做什么、做到什么程度算过关，哪些情况可以跳过，以及后面那些坑多半是因为前面没学扎实才出现的。你可以把它当成一份路线图，边看边对着自己的进度打勾。

先定顺序：为什么是原理→微调→Agent

这三段各自解决不同的问题：原理帮你听懂命令行里的报错和文档里的名词，微调帮你改变模型的行为习惯，Agent 帮你把模型接进一条真实流程里。顺序反了，学到后面全是在补前面的债。

最常见的跳步后果是：上下文窗口和 token 没搞明白就去调 Agent，循环跑飞了、成本忽然涨上去，你根本判断不出是模型选错了、提示词写崩了，还是编排逻辑本身有 bug。先学原理，就是为了让后面每次出错都有归因的方向。

• 原理段过关：能被别人问住时讲明白 token、上下文、采样这几个词
• 微调段过关：能拿自己的几十条数据跑通一次训练，并说清结果好坏
• Agent 段过关：能写一个只带一个工具、有明确停止条件的循环
• 三条都过了再进下一段，不要一边学原理一边纠结 Agent 框架选型
• 如果是纯应用层岗位、只做提示词调用，原理段可以适当压缩，但不建议整段跳过

什么情况下可以跳过原理段？如果你只做提示词调用，不碰上下文管理和成本估算，注意力机制的细节确实可以先放一边。但只要你要调接口、算费用、排查报错，token 和上下文这两块就绕不过去。

第一段：原理只需要学到能用的程度

原理不是让你去推导公式，而是学到「够用」：看到现象能解释，看到成本能估算，看到报错能定位。重点只有几件事，别一上来就啃论文。

token 与分词

模型眼里的最小单位，中文和英文的切法不一样，直接影响长度和费用

上下文窗口

一次对话能塞进去的总量，超了就被截断或报错，是很多诡异问题的根源

温度与采样

控制输出随机性的旋钮，调到极端会变得死板或跑偏

幻觉

模型在没依据时照样流畅作答，这是特性不是 bug，要靠外部信息约束

动手环节不用多：找同一段文本，分别用不同方式数一次 token，观察输入输出长度怎么影响延迟和费用。再到站内的基础词条把一个一个名词点开看，不熟的记在笔记本上，比反复刷视频有用。

1. 过一遍词条到 /ai-dict/category/basics 把基础名词挨个点开，读不懂的先记下来，别急着往下学
2. 数一次 token拿一段自己的中文和一段英文分别数一遍，感受两种语言的单位差异
3. 估一次成本按你的实际使用长度，到 /price-watch 核对当时的价格数字，自己算一遍单次调用的量级
4. 复述验证合上资料，用自己的话把 token、上下文、采样讲一遍，讲不顺就是没懂

这一段最大的误区是「学太深」。对绝大多数应用开发者来说，知道现象和边界就够了，不必纠结内部结构。把省下来的时间放到后面的动手环节，收获更大。

第二段：微调前先判断要不要微调

很多人一遇到效果不好就想微调，这是最容易走弯路的地方。提示词、RAG、微调是三条不同的路，各自擅长处理的问题完全不一样。选错了，钱花了、时间搭进去，效果还可能更差。

判断标准其实很简单：如果你想让回答更礼貌、更符合某种格式、更贴某个任务的套路，微调合适；如果你只是想让模型知道昨天刚发布的资料，那应该走 RAG，而不是微调。知识型需求用微调去灌，通常费钱又不好维护。

• 先小后大：拿小参数模型或轻量微调方式跑通一遍，确认方向对了再上规模
• 先验证再投入：拿几十条样本先试，别一上来就整理上千条数据
• 数据准备往往比训练本身更花时间，格式、清洗、去重、留验证集都要提前想
• 什么情况不该微调：知识更新频繁、数据拿不到合规授权、只是想让回答更客气

还有一层容易被忽略：数据来源的合规性。如果训练数据来自别人的内容或用户数据，先问清授权和许可，别等做完再返工。这一条在个人练手时问题不大，一旦涉及对外服务就必须提前确认。

第二段动手：把微调流程走完一遍

这一段的目的是走通流程，不是追求效果。哪怕最后结果一般，只要你能说清每一步在干什么、哪里可能出问题，就算过关。

1. 整理数据按任务把数据整理成问答或指令格式，留出一部分做验证集，千万别拿训练集自测
2. 选小模型起步选一个参数量小的模型先跑通，成本低、反馈快，出错也容易定位到数据还是参数
3. 记录损失曲线训练时把损失记下来，不下降或明显过拟合，先回头查数据质量，再看超参
4. 做前后对比准备一批固定问题，训练前后各问一遍，看目标任务是不是真的变好了
5. 合并与部署搞清微调产物怎么并回原模型、怎么起服务；本地跑不动时再到 /compute/sizing 估配置

评估是最容易被糊弄的一步。很多人训练完自己问两句觉得「好像好点了」就收工，这不算评估。要有一批固定问题、固定的判断标准，看的是目标任务的表现，而不是模型的通用能力有没有变强。

如果本地机器跑不动训练，不必硬扛。到站内的算力页面看看当时的配置行情，先搞清楚显存、时长和成本的关系，再决定是租卡还是换成更小的模型。入门阶段用小模型反馈更快，不要一上来就追最大的。

第三段：Agent 到底是什么，先分清边界

Agent 不是「换个提示词就自动变聪明」。它和应用的核心区别在于多了循环、工具调用和状态管理：模型不再只回答一次，而是可以根据结果决定下一步做什么，直到满足停止条件。

把核心组件拆开看，缺哪块会表现成什么故障，这样调试时才有方向。规划负责拆任务，工具调用负责拿外部信息，记忆负责跨步骤保留信息，执行反馈负责判断这一步成没成。

• 规划缺失：任务一复杂就开始乱答，或者只做第一步就停
• 工具调用缺失：明明需要查数据却凭记忆瞎编
• 记忆缺失：多轮之后忘了前面说过什么，前后矛盾
• 执行反馈缺失：工具报错了也照样往下走，最后输出一堆废结果
• 不适用的情况：任务一步就能答完、不需要外部数据时，用 Agent 是自找麻烦

框架选型不用纠结太久。先理解 MCP 这类工具协议在做什么，再去 /stacks/frameworks 挑一个主流的熟悉起来。边学边换框架意义不大，把一套用透比每套都摸一遍强。如果任务本身不需要多轮决策，直接写普通调用就好，不必硬套 Agent。

第三段动手：从单工具做到多步任务

入门阶段最重要的不是功能多，而是循环能稳定跑起来、能停下来。先做一个模型加一个工具、且有明确停止条件的最小闭环，跑顺了再谈多工具协作。

1. 搭最小闭环一个模型、一个工具、一个明确的停止条件，先让整个循环能跑通、能退出
2. 按顺序排查故障模型不调用工具、调用参数写错、循环不结束、结果不校验，按这个顺序逐个查
3. 存日志把每一步的输入输出和中间结果都记下来，否则出错时无法复盘是哪一步断的
4. 接现成方案需要外部能力时，先到 /stacks/agent-apis 和 /stacks/vector-dbs 找现成的，别自己造

排查顺序很重要。很多人一看到结果不对就去改提示词，其实问题往往出在工具返回格式上，模型拿到看不懂的内容自然就乱了。按「先看模型有没有调用、再看参数对不对、再看循环有没有退出、最后看结果有没有校验」的顺序走，能省掉大量瞎试的时间。

另外，工具的数量不是越多越好。每多一个工具，模型选错的概率就上升一些。入门阶段控制在两三个以内，等单个工具稳定了再扩。什么时候该扩？当你发现模型在几种明确不同的任务间反复切换、且每个任务都需要外部数据时，才值得加。

把三段拼成一份可执行的周计划

光有路线不够，得排进时间里。按周给自己设目标，每周留一个能跑通的产出物，比列一堆学习清单有用得多。产出物可以很小：一段能数 token 的脚本、一次跑通的微调、一个能停下来的 Agent 循环。

• 算力与费用怎么安排：先用免费额度和小模型练手，需要训练时再到 /compute/sizing 估配置
• 数据对比要留底：训练前后的输出都存下来，别只凭印象
• 自检三条：能不能讲清概念、能不能复现流程、出错能不能定位，都过再进下一段
• 什么情况该停下来补基础：反复在同一个概念上卡住，或者总是照抄代码跑通却不知为何

什么时候该停下来补基础？如果你已经连续几次在同一类报错上栽跟头，或者代码能跑但你说不清每一步在干什么，那就是原理段欠账了。回头补比硬撑着往下学更快。

常见走弯路与纠正方式

最后列几个高频弯路，都是初学者容易踩的，对照着检查自己的进度。

这些弯路的共同点是「跳步」：跳过原理直接上 Agent，跳过数据准备直接开训，跳过评估直接上线。走回头路花的力气，往往比当初慢一点更多。

判断自己有没有学扎实，有个简单办法：给一个完全不懂的同事讲一遍，能讲到对方听懂，基本就稳了。讲不通的地方，就是下一次该补的地方。