先讲一个不少人都见过的场景收藏夹里躺着几十个“AI大模型零基础入门”视频标题从“10小时学会 LangChain”到“RAG 知识库实战”再到“Agent 开发全流程”每一个看起来都很完整每一个都写着“从入门到项目实战”。但真正打开看的时候第一集还能跟着敲几行代码到第三集就开始讲组件、讲编排、讲微调越来越飘越来越抽象。最后收藏夹吃灰知识体系还是碎片。这不是学习态度的问题而是这批教程普遍缺少一个“认知地图”。LangChain、RAG、Agent、大模型微调这四个词看起来是四个并列的技术名词但它们根本不是同一个层面的东西。LangChain 是开发范式RAG 是架构方案Agent 是应用形态微调是模型定制手段。如果不知道它们各自解决什么问题、边界在哪里、学习顺序该怎么排哪怕把视频从头到尾看完也只会得到一堆术语不会变成能落地做 LLM 应用的能力。这篇文章不打算把“10小时教程”复述一遍而是想把这四块内容拆开揉碎讲清楚每一块的定位、核心机制、学习重点和最容易踩的坑最后给出一条可执行的入门路径。它适合零基础的人建立一个完整框架也适合已经学了一半但觉得混乱的人回来校准方向。1. LangChain先理解它解决的是“重复流程的结构化”而不是“调用模型”很多人入门 LangChain 的第一个疑问是我不就是调个 API 吗为什么要多套一层框架这个疑问很正当因为如果只做单次对话、单次生成直接用模型 SDK 反而更简单。LangChain 的价值从来不在“让模型跑起来”而在“让复杂的应用流程可以被描述、被复用、被维护”。1.1 LangChain 到底编排了什么可以把一个 LLM 应用拆成几个常见的组成部分模型调用、提示词管理、外部数据接入、记忆、工具调用、结果输出。如果不使用框架这些逻辑全部要靠自己写胶水代码而且每换一个模型或每加一个功能都要重构一遍。LangChain 做的事是提供一套抽象的组件接口把上面这些模块变成“可插拔”的单元。你不需要每次都从零写提示词拼接逻辑也不需要自己维护“历史对话怎么塞进上下文”这种重复劳动。它更像是一个流程编排器帮你把一次 LLM 应用开发从“手写面条代码”变成“组装标准化零件”。这里要强调一个容易被误解的点LangChain 不是模型也不替你做模型选型。它只是一个中间层底下的模型可以是 OpenAI 的 GPT 系列也可以是开源的 Llama、ChatGLM、Qwen或者国内云厂商的接入点。真正决定生成质量的仍然是模型本身、提示词设计、数据质量这些底层因素。1.2 一个最小可运行的入门示例先看一个非常简化的链式调用示例。这里仅演示结构实际使用时要根据自己的模型接口和版本调整from langchain.prompts import PromptTemplate from langchain.llms import OpenAI from langchain.chains import LLMChain # 1. 定义提示词模板 prompt PromptTemplate.from_template( 你是{domain}领域的专家。请用简洁的语言回答下面的问题\n{question} ) # 2. 初始化模型 llm OpenAI(modelgpt-4, temperature0) # 3. 构建一条链 chain LLMChain(llmllm, promptprompt) # 4. 执行 result chain.run(domain法律, question合同里的违约金上限一般怎么约定) print(result)这个示例启发意义大于实战意义。它告诉你 LangChain 的核心思路把“提示词模板”“模型实例”“执行逻辑”分别定义再组合成一条链。当你需要处理更复杂的场景时只需要在链上继续挂组件而不是推翻重写。1.3 入门阶段最关键的认知转变刚开始学 LangChain不要急着把每一个组件都学完。真正要建立的是三种意识模块化意识模型、提示词、数据、记忆、输出解析它们是不同模块应该分开设计、分开测试。配置化意识模型名称、温度参数、最大 token 数、超时时间这些都应该能通过配置调整而不是写死在业务代码里。流程化意识一个完整的应用通常不是“一次提问一次回答”而是“用户输入 → 检索 → 组装上下文 → 调用模型 → 解析输出 → 决定是否继续调用工具”。用一句话总结LangChain 的核心价值不是帮你省掉 5 分钟编码时间而是把一次性的临时脚本变成一套可扩展、可维护、可替换组件的工作流框架。2. RAG知识库不是把文档扔进去就完事关键在检索质量RAGRetrieval-Augmented Generation检索增强生成是当前落地最广的 LLM 应用方向之一。它解决的问题很明确大模型的训练数据有截止时间也不了解企业内部文档直接问经常“一本正经地胡说八道”。RAG 的思路是在让模型回答之前先从你的文档库里检索出相关内容把内容拼进上下文再让模型基于这些材料生成答案。这个思路听起来不复杂但真正做过的都知道坑全藏在细节里。很多入门教程把 RAG 简化成四步加载文档、切分、向量化、检索。但实际项目里这四步每一步都足以决定最终效果的好坏。2.1 RAG 的真正难点不在“向量化”而在“检索质量”向量化只是把文本映射成向量现在有大量成熟的 Embedding API 和开源模型可以用。但向量化之后检索回来的结果到底准不准、有没有把最相关内容排在最前面、有没有把不相关内容也带进来这才是决定生成质量的关键。影响检索质量的因素至少有这些文档切分策略切块过小语义不完整切块过大噪音太多还可能超过模型上下文限制。Embedding 模型的选型通用模型未必适合你的垂直领域比如法律、医疗、代码场景可能需要额外评估。检索策略只做向量相似度检索还是结合关键词检索还是做混合检索重排召回数量的设置召回 3 段还是 10 段不是拍脑袋决定的要看实际答案质量和上下文长度。从工程经验看RAG 项目 70% 的问题都出在“文档没有处理好”和“检索结果不精准”上而不是模型不够强。很多团队换更强的模型问题依然存在原因就在这里模型在强也架不住你把不相关内容硬塞给它。2.2 一个最简 RAG 流程示例以下示例展示了一个相对完整的 RAG 流程骨架from langchain.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS from langchain.chains import RetrievalQA from langchain.llms import OpenAI # 1. 加载本地文档 loader TextLoader(knowledge_base.txt) documents loader.load() # 2. 切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) docs text_splitter.split_documents(documents) # 3. 向量化并存储 vectorstore FAISS.from_documents(docs, OpenAIEmbeddings()) # 4. 构建检索问答链 qa RetrievalQA.from_chain_type( llmOpenAI(modelgpt-4), retrievervectorstore.as_retriever(search_kwargs{k: 3}) ) # 5. 查询 answer qa.run(发票丢失了还能报销吗) print(answer)这段代码能不能直接复制到生产环境不能。它只是一个最小演示。真实项目里你还要处理 PDF 的表格布局、文档去重、权限过滤、增量更新、检索结果命中率评估等问题。但作为入门它足够帮你建立整条链路的体感。2.3 RAG 的进阶方向与评估意识现在的 RAG 已经发展出不少进阶方向。比如 Agentic RAG把原来的“一次检索一次生成”改成“模型自主决定要不要检索、检索几次、要不要换一种检索方式”再比如 Ontology RAG在检索前引入领域本体或知识图谱结构提升对专业术语的召回能力。这些方向很有价值但零基础阶段不建议一上来就追。更值得先掌握的是评估意识。怎么知道你的 RAG 系统到底好不好常见的评估维度包括命中率检索出的文档是否包含答案、生成准确率最终回答是否正确、答案完整度该说的有没有说全、幻觉率有没有编造文档中不存在的信息。你可以先人工抽几十条测试问题把模型的回答和检索到的文档对照着看。别急着追求花哨指标先保证“检索结果里真的有答案”。3. Agent从“回答机器”到“任务执行者”核心是推理、工具与反馈Agent 是当前热度最高的方向但也是误解最多的方向。很多人把 Agent 想象成“一个无所不能的 AI 助手”这其实是产品形态不是技术原理。技术层面的 Agent核心是一个“循环”模型根据用户目标进行推理决定调用哪个工具拿到工具结果后继续推理直到任务完成或达到上限。3.1 Agent 和普通链式调用的本质差异普通 LLM 应用是先写好固定的流程比如“先检索再生成”每一步都是预设好的模型没有决定权。Agent 不一样它让模型自己决定下一步做什么。举一个简单的类比普通聊天机器人像一个接线员你问什么它就按固定话术去找答案Agent 更像一个办事员你交代一个目标它会自己拆解成多个步骤需要查资料就查资料需要计算就调用计算器遇到情况还会停下来判断下一步怎么走。这个差异决定了 Agent 开发的重点不是“模型调用”而是三件事工具设计模型不能凭空获得外部信息你必须把 API、数据库、搜索、代码执行器等能力封装成它能理解的工具。规划与反馈模型在每一步之后需要看到结果再决定是继续、调整还是终止。这一步最考验提示词设计和异常处理能力。安全与边界Agent 如果被授予了执行操作的权限它可能在错误理解下做出不可逆操作。落地前必须加权限控制、人工审核、操作日志和最大执行次数限制。3.2 从 LangChain 到 LangGraph复杂 Agent 场景的演进入门时你会先接触 LangChain 里的 Agent 概念比如用AgentExecutor来跑一个简单的多工具循环。这种设计适合快速验证但遇到需要精细控制状态、分支、循环、人工介入的场景会变得不方便。LangGraph 应运而生它的核心不同在于把 Agent 的每一步都建模成一张图节点之间可以互相跳转、循环、条件分支状态管理更显式。作为零基础学习者不需要马上在 LangChain 和 LangGraph 之间二选一。先理解区别LangChain 倾向于“链式编排”LangGraph 倾向于“图状状态机”。如果你只需要一个简单的查文档 → 回答流程LangChain 够用如果你要做一个有多个工具、有分支判断、有复杂状态管理的实际项目可以开始了解 LangGraph。3.3 Agent 落地时最容易翻车的地方Agent 不是“给模型加个工具列表”就能稳定工作的。最常见的翻车点工具描述不清晰模型看不懂你的工具是干什么的、参数应该怎么填它就瞎调用。没有设置最大循环次数一个任务可能反复调用工具停不下来最后白白消耗时间和费用。错误处理缺失第三方 API 可能超时、报错、返回空值。Agent 看到异常结果后经常会把这个异常当成正常结果继续回答。权限过于开放开发环境可以放开但接生产系统时删除、修改、转账等高危操作必须加人工确认环节。网上很多 Agent 视频拿“个人助手”做演示看起来很简单但那个场景本身就比较简单工具也就两三个。真正到业务场景里工具数量一多、依赖一变复杂稳定性和安全性才是核心挑战。4. 大模型微调不是所有场景都需要但它解决的是“适配领域”问题微调Fine-tuning是最容易被误解的一个模块。不少零基础学员一学到大模型微调就觉得自己马上要训练一个“自己的 ChatGPT”了。实际上微调并不是训练一个新模型而是在已开源的大模型基础上用特定数据集继续训练让模型更适应某个领域、某种语气、某种输出格式。4.1 微调到底改变了什么大模型出厂时已经具备了强大的通用能力但它不一定懂你的行业黑话不一定按你指定的格式输出也不一定了解你团队的特殊规则。微调就是在模型的既有能力上“加补丁”让它偏向你需要的方向。常见的微调诉求包括让模型学会特定领域的术语和表达习惯。让模型按固定 JSON 结构输出方便接业务系统。让模型模仿某种风格、语气、角色设定。让模型更擅长某类任务比如代码生成、合同审查、客服应答。但微调有一个非常重要的事实它不会给模型补充新知识。如果你希望模型回答“公司内部报销流程是什么”但内部流程从来没出现在训练数据里那微调是没用的正确做法是 RAG。微调擅长改变“行为方式”RAG 擅长补充“事实知识”。两者不是竞争关系而是互补关系。4.2 零基础微调到底要准备什么零基础学微调最容易被视频里的“10分钟完成微调”误导。实际上完整流程大概是这样的数据准备收集几百到几千条高质量指令数据每一条都包含“指令 输入 期望输出”。数据清洗去掉重复、错误、语无伦次的数据检查输出是否符合格式要求。格式转换把数据整理成模型要求的训练格式比如 ShareGPT 格式或 Alpaca 格式。训练选择开源底座模型配置 LoRA 等参数高效微调方法在单卡或少量 GPU 上跑若干轮。评估准备一批训练时没见过的问题对比微调前后输出变化。合并与部署把训练得到的 LoRA 权重与底座模型合并导出部署。对于零基础不建议一上来就买一堆卡、跑全量微调。先用 CPU 或云上几小时的 GPU拿几百条数据、一个小尺寸模型比如 7B 或更小把全流程跑通再逐步加数据量。很多人卡在的不是算力而是数据质量。4.3 算力门槛与常见误区关于算力有一个比较实用的判断标准如果你的微调目标是“学会输出格式”一般几百条数据就够了如果目标是“学会某个领域的内容”那在数据量没有上几千上万条的情况下微调效果可能还不如一个精心设计的 RAG 方案。GPU 方面云厂商按小时租用显卡做实验是成本最低的方式。不要在物理机还没确认显卡型号和显存大小时就盲目掏钱买设备。注意微调一个 7B 模型用 LoRA 方法通常需要至少 16GB 显存不同底座和上下文长度还会变动。这个门槛不算低但在云上完全可以接受。还有一个常见误区是把微调当成“万能药”。项目效果不好先不调提示词、先不查数据直接微调。这个顺序错得比较远。正确的排查链路应该是先看提示词够不够清晰 → 再看 RAG 检索结果准不准 → 再看是否需要引入工具或 Agent 流程 → 最后才考虑要不要微调模型。微调是最后一块拼图不是第一块。5. 给零基础的四层学习路径从“会调用”到“会做 LLM 项目”现在来回答一个最核心的问题如果从零开始到底应该按什么顺序学这四块内容我给出一条经过验证的路径。这条路径不看学习速度看的是每一步有没有建立正确的心智模型。5.1 第一层先学会“单次调用”和“提示词工程”不要一上来就上框架。先用模型提供方给的 SDK写一个最简单的“输入文本 → 返回结果”程序。在这一层重点理解几个基础概念Token输入和输出是如何被计量的。温度temperature它影响随机性不是越高越好。上下文长度模型一次能接收多少文本。提示词结构系统提示词、用户消息、示例内容应该怎么放。这一层不需要学太多几周内掌握就够。目的只有一个对模型的行为有直接体感。5.2 第二层用 LangChain 或直接 API 搭建“固定流程应用”当你熟悉了单次调用再学 LangChain思路会顺畅很多。你会发现框架里的提示词模板、输出解析器、记忆组件都是在帮你解决已经遇到过的真实问题。这一层的练习目标可以是用 LangChain 做一个简单的问答助手。把历史对话塞进上下文实现“多轮记忆”。结合一个公开 API写一个简单的“查天气 智能推荐”链式应用。到这里应该能回答“链路流程”是怎么构建的。5.3 第三层用 RAG 把外部知识接入你的应用当你想让模型回答它训练数据里没有的知识就进入 RAG 层。先学会跑通最小链路然后花主要精力研究检索效果换切分参数、换 Embedding、调召回数量、做少量测试集人工评估。这一层结束时你应该能回答这类问题一份 PDF 文档要进入知识库需要经过哪些步骤为什么检索结果不准如何判断一个 RAG 系统“能用”5.4 第四层再碰 Agent最后才考虑微调Agent 放在第四层是因为它依赖你对“模型调用、流程编排、工具使用”的熟悉程度。如果前几层没有建立好Agent 出错时你根本分不清问题出在模型、工具还是编排逻辑。微调放在最后是因为它对数据工程和评估体系的要求更高。零基础直接把微调作为学习第一步很容易把大量时间耗在环境安装和参数调优上反而忽略了更重要的产品逻辑。5.5 各模块难度与投入参考模块核心目标入门难度落地难点适合场景提示词工程掌握与模型对话的正确方式低场景变化多需要经验积累所有 LLM 应用的基础LangChain掌握流程编排与组件化开发中框架版本更新快组件边界模糊需要将模型能力接入业务系统时RAG解决模型知识时效与私有知识问题中高检索质量提升困难评估体系欠缺知识库问答、企业文档助手Agent让模型自主决策、调用工具完成任务高状态管理、异常处理、安全边界复杂多步骤任务场景微调让模型适配特定领域与输出风格高数据质量要求高算力成本不低需要特定风格、特定格式、领域强化的场景6. 学习过程中最值得反复确认的四个问题最后把整篇文章的实操要点收束成四个判断问题。每当你学一个新模块、看一个新项目视频都可以用它们来检查自己是不是在正确的路径上。问题一这个模块解决的是“流程、知识、决策、还是行为”对应关系是LangChain 解决流程RAG 解决知识Agent 解决决策微调解决行为。如果你把知识问题用微调解决大概率既花钱又没效果如果你把行为问题用 RAG 解决模型还是不会按你要的格式输出。问题二你的项目到底卡在哪一层先用一条最小链路把整个项目跑通再逐层排查。比如知识库问答效果不好先看文档加载对不对、切分合不合理、检索结果有没有命中答案最后才看模型生成。不要一上来就换模型、调温度。问题三你做了评估吗没有评估优化就是“感觉调参”。RAG 项目至少要准备 30 到 50 条有代表性的测试问题微调项目至少要准备一组“训练中没见过的评估集”。每次改动后都跑一遍看准确率和完整度是上升还是下降。没有评估习惯项目永远停留在“碰运气”阶段。问题四你跑通的最小流程有多小最小不等于简陋。最小流程指的是在成本最低、调试最快的前提下把所有关键环节完整跑一遍。比如微调就用几百条数据在云端小模型上跑一轮RAG 就用一个文档一个库一条链路跑通。先证明链路可行再扩大数据和工作量。这个顺序可以避免很多无效努力。大模型应用开发看起来链路很多、框架很杂但真正沉淀到纸面上逻辑并不复杂。它难在每一条链路的细节——数据干不干净、检索准不准、工具边界清不清楚、评估是不是闭环。零基础入门的正确目标不是“10小时学会所有概念”而是“在理解每个模块定位的前提下按顺序跑通每一条最小链路”。等这些链路都断断续续跑过之后那些视频里的进阶内容才会从背景音变成真正能用的知识。