从模型训练到 Agent：一份把 AI 技术串起来的学习路线

很多 AI 学习路线的问题，不是资料太少，而是把概念排成了一个词汇表：Transformer、预训练、SFT、RLHF、RAG、MCP、Agent、Multi-Agent……每个词都认识，放到一个真实项目里却不知道谁该先出现。

我更喜欢用一条业务闭环理解它们：数据和反馈制造模型能力；模型在推理时处理信息；检索、工具与工作流把能力接到业务；评测、安全和运营把演示变成产品。

这篇文章的目标不是让你一口气成为算法研究员，而是让你能回答三个问题：模型为什么会这样工作？某个技术到底解决什么问题？面对真实业务时应该怎样选型？

先记住这句话

模型本体解决“会不会”；后训练解决“能不能按要求做”；RAG、工具和工作流解决“能不能可靠完成真实业务动作”；评测与治理决定“能不能上线并持续产生价值”。

这句话可以防止很多错误决策：把频繁变化的知识塞进微调、用一个自由循环的 Agent 承担审批流程，或只凭公开榜单就采购模型。

AI 技术全景图

flowchart TB A[业务问题\n用户、流程、KPI、风险] --> B[数据层\n语料、标注、偏好、知识库、评测集] B --> C[模型层\nToken → Embedding → Transformer] C --> D[训练层\n预训练 → 持续预训练 → SFT → 偏好优化或 RL] D --> E[推理层\n上下文、采样、缓存、量化、模型路由] E --> F[应用层\nPrompt、结构化输出、RAG、工具调用] F --> G[Agent 与编排\n计划、状态、执行、验证、人机协作] G --> H[生产运营\n评测、监控、安全、成本、灰度、回滚] H --> A

图中的箭头不是一次性流水线，而是两个反馈闭环。

训练闭环：数据与标注 → 训练 → 离线评测 → 发现失败样本 → 补数据、改训练或改评测。
产品闭环：真实任务 → 系统评测 → 灰度上线 → 观察质量、成本与风险 → 人工反馈回流。

真正成熟的团队会同时维护这两个闭环。

第一层：模型究竟在做什么

Token、Embedding 与 Transformer

模型先把文本切成 token。它不是严格的汉字或单词，而是模型处理的离散片段；输入和输出 token 数直接影响上下文、延迟和账单。

每个 token 会被映射为一个向量，也就是 embedding。语义相近的内容通常会在向量空间里更接近，这也是向量检索能工作的直觉基础。

大多数现代语言模型使用 Transformer。它的自注意力机制会让一个 token 根据上下文中其他 token 的相关性聚合信息，因此能理解长距离关系；训练阶段又可以很好地并行。Transformer 的原始论文是 Attention Is All You Need。

训练和推理不是一回事

训练的基本循环是：前向计算 → 计算损失 → 反向传播 → 更新参数。它需要大量数据、GPU 和工程能力。

推理则固定模型参数，按上下文逐 token 生成结果。temperature、top-p 等参数改变的是输出的随机性与多样性，不是“智力旋钮”。KV Cache、批处理、量化、缓存和模型路由则决定线上延迟和成本。

因此，大多数企业不应该从零训练基础模型。更常见、更有价值的工作是：选择模型、准备高质量上下文、接入工具、建立评测和运营闭环。

第二层：训练链路——能力从哪里来

预训练：获得通用能力

预训练通常在海量文本、代码或多模态数据上做自监督学习。对自回归 LLM 来说，最常见目标是“根据前文预测下一个 token”。它让模型学会语言模式、代码结构和一些可泛化的世界规律。

预训练得到的是基础能力，不保证模型会遵从用户、稳定调用工具、拒绝高风险请求或说出可核验的事实。

持续预训练：适应稳定领域

持续预训练（continued pretraining）让底座模型继续阅读某个领域的长期语料，例如法律文本、医学术语或特定编程语言。它适合改变模型对领域语言分布的熟悉程度，但不适合注入经常变化、必须可引用的事实。

SFT：把“会”变成“会按要求做”

监督微调（SFT）用“指令—理想回答”示范模型应该怎样回答、怎样输出 JSON、怎样调用工具或怎样遵守固定流程。

当任务稳定、重复、可以获得高质量样本时，SFT 很有效。LoRA 一类参数高效微调方法可以只训练少量附加参数，降低成本。它更适合教模型稳定行为，而不是替代知识库。

偏好优化与强化学习：把“好”写成可优化的目标

强化学习（RL） 是在环境中通过反馈最大化奖励的广义范式。放在语言模型里，奖励可能来自人类偏好、程序验证结果或任务是否完成。

经典 RLHF 的链路通常是：先 SFT，再让人比较两个回答，训练奖励模型，最后用 PPO 一类算法优化模型，同时用约束防止它偏离太远。InstructGPT 是理解这条链路的好起点。

DPO 则直接使用“更喜欢 A 而不是 B”的偏好对优化策略，工程链更短。不要把它理解为“DPO 一定优于 RLHF”：选择取决于奖励是否可验证、偏好数据质量、训练预算和评测结果。DPO 论文解释了它的目标函数。

偏好优化最难的部分往往不是算法，而是“好”到底如何定义。奖励设计得差，模型就可能学会迎合指标而不是真的完成任务，这叫 reward hacking。

第三层：RAG、工具与 Agent 各自负责什么

RAG：给模型外部、可追溯的知识

RAG（Retrieval-Augmented Generation）把知识放在模型参数之外：文档解析和清洗 → 切块与元数据 → 检索与重排 → 注入少量相关上下文 → 带来源回答。

它适合私有、实时、长尾、需要引用的知识，例如产品文档、制度、客服知识库。它不只是“上传 PDF”：真正的瓶颈常在文档质量、权限、切块、召回、重排和引用忠实度。RAG 原论文给出了基本框架。

Tool Calling：让模型连接真实系统

工具调用的正确分工是：模型产出符合 schema 的调用意图和参数；程序校验参数、执行 API，再把观察结果返回模型。模型不应直接拥有无限权限。

一个面向生产的工具至少应具备：输入校验、最小权限、读写分级、幂等键、超时与重试、审计日志。涉及支付、删改数据、发信和对外承诺时，应先预览或转人工确认。

Agent：在不确定处做多步判断

Agent 可以理解为一个循环：

获取上下文 → 规划下一步 → 调用工具 → 观察结果 → 校正或完成 → 验证

模型是 Agent 的“大脑”，但并不是 Agent 的全部。一个可靠的 Agent 还需要状态、上下文、工具、权限、预算、停止条件、证据记录和验证器。

flowchart LR U[用户目标] --> C[上下文编译器\n状态、RAG、记忆、规则] C --> M[模型与规划器] M --> P[策略控制\n权限、风险、预算、停止条件] P --> T[工具网关\n搜索、数据库、代码、业务 API] T --> O[观察与证据] O --> V[验证器] V -->|通过| R[交付] V -->|失败或高风险| H[重试、降级或人工接管] H --> C

OpenAI 将 Agent 的基础概括为模型、工具和指令，并建议先把单 Agent 做到可评估，再按复杂度增加编排。实战指南

工作流、单 Agent 与多 Agent 怎样选择

确定性工作流：步骤清楚、风险高、要审计的任务优先。例如审批、订单变更、资料抽取。
单 Agent：需要在多信息源和工具之间动态判断，但边界仍可控。
多 Agent：只有当角色确实能独立并行、交叉校验或清晰交接时才拆分。

一个实用原则是：工作流是骨架，Agent 是其中处理不确定性的节点。 不要为了显得先进把每个流程交给自由循环的多 Agent。LangGraph 这类编排运行时的价值，在于显式状态、持久化、人工介入和可观测性，而不是替你决定产品架构。LangGraph 概览

第四层：让 Demo 变成产品

评测先于“感觉不错”

公开 benchmark 可以帮我们了解能力边界，但不能替代业务评测。应该建立一组金标案例，至少覆盖：

组件层：检索召回、引用正确性、工具参数合法率。
任务层：端到端成功率、失败恢复率、人工接管率。
业务层：节省时长、转化、满意度、风险事件。

每次改模型、提示词、索引、工具或策略，都要跑回归集；再通过小流量灰度观察线上结果。LLM-as-a-judge 可以提高效率，但需用人工标注样本校准，不能把它当唯一裁判。

安全、成本与可观测性是横向能力

不要信任用户输入、网页、PDF、检索结果或工具返回的指令。它们都可能携带 prompt injection。安全要靠工具白名单、最小权限、敏感数据隔离、输出校验、沙箱、人工确认和审计等多层防线。

每次任务最好能留下 trace：模型和提示词版本、上下文来源、token、延迟、检索证据、工具调用、状态变化、最终结果和人工反馈。对业务而言，一个比“单次调用价格”更有意义的指标是：每次有效任务成功的总成本。

一份从能讲到能做的八周路线

第 1 周：模型心智模型

学习 token、embedding、Transformer、上下文窗口、训练与推理。目标是用三分钟解释“LLM 为什么能生成文本，也为什么会幻觉”。

第 2 周：训练与后训练

把预训练、持续预训练、SFT、LoRA、偏好优化、RLHF 与 DPO 放在同一张图里。目标是说清：什么需求用 RAG，什么需求值得微调，什么问题才需要 RL。

第 3 周：做一个可引用 RAG

选择一批公开或个人文档，完成解析、切块、检索、重排与带引用回答。先测“有没有检索到正确证据”，再测“拿到证据后是否忠实回答”。

第 4 周：工具与受控工作流

做“查数据 → 生成草稿 → 规则校验 → 人工确认 → 执行”的最小系统。重点不是接更多工具，而是把权限、失败和回滚设计清楚。

第 5 周：单 Agent 与状态机

加入任务状态、有限重试、工具选择和成功验证。能画出状态转移图，比能背框架 API 更重要。

第 6 周：多 Agent 与协作边界

只在有明确职责边界时引入检索、分析、执行、审校等角色。比较单 Agent 与多 Agent 的质量、成本、延迟和故障面。

第 7 周：评测与生产化

建立 30 到 50 条金标案例，接入 trace、回归评测、权限边界、模型路由和成本统计。

第 8 周：完成一个能验收的项目

用一个真实业务主题收尾，例如“企业知识助手”或“客服流程助手”。验收条件不应是“能聊天”，而应是：有引用、能完成规定动作、失败可解释、高风险操作可控、每次迭代可回归验证。

面试前的四小时冲刺法

如果时间只剩一个下午，不要刷论文。

45 分钟：Token、Transformer、训练和推理、幻觉。
60 分钟：预训练、SFT、LoRA、RLHF、DPO 的分工。
75 分钟：RAG、工具、Agent 与工作流的架构图。
45 分钟：评测、安全、成本、灰度与回滚。
60 分钟：拿“企业知识助手”完整串讲一次。

可以用下面这段作为面试表达：

我会把 AI 产品看成受控的决策系统，而不是一次模型调用。先用业务 KPI 和风险边界定义任务，再判断该用提示词、RAG、工具工作流还是 Agent。知识要有来源和权限，动作要有 schema、最小权限和审批，最后用任务成功率、事实正确率、成本、延迟和安全事件形成闭环。

学习方法：每个概念都问四个问题

不要把学习变成看资料收藏夹。每接触一个新概念，都写下：

它解决哪一种失败？
它的输入与输出分别是什么？
它的成功指标是什么？
它怎样影响上游和下游？

例如，RAG 的失败不是“模型参数太少”，而是“没有拿到可信、及时、授权的证据”；工具调用的成功不是“模型发起了函数调用”，而是“受控地完成了动作且结果被验证”。

推荐采用“讲清楚 → 做出来 → 测出来”的循环：先用自己的话解释；再实现一个最小版本；最后故意准备失败案例和评测。这比连续看十篇综述更容易形成可迁移能力。