1. 从调API到造系统大模型应用开发到底在学什么我刚开始接触大模型应用开发那会儿脑子里只有一个朴素的想法调个接口把问题丢进去把答案拿出来这不就完事了吗结果第一个真实需求就把我打回原形——用户问帮我查一下上个月华东区的退货率顺便对比一下前年同期模型一本正经地编了一个数字出来语气还特别自信。那一刻我才明白大模型应用开发的核心根本不是调用模型而是围绕模型搭建一套能约束它、喂养它、验证它的工程系统。这个认知转变是我整个学习路径的分水岭。如果你现在也处在会写几行调用代码但一上真实场景就翻车的阶段那这篇内容就是写给你的。我会把自己从零摸索到能独立交付 Agent 项目的完整路径拆开讲包括每个阶段该学什么、为什么这么排序、哪些坑我踩过、哪些工具我最后留下了、哪些被我扔了。先把几个高频词的关系理清楚因为很多人一开始就被这些名词绕晕概念它解决的核心问题一句话理解大模型LLM语言理解与生成大脑但记性差、爱瞎编RAG让模型用上外部知识给大脑配一个可查的资料库Agent让模型能自主决策并调用工具给大脑装上手脚和行动循环上下文工程决定每一步往模型里塞什么控制大脑此刻看到的信息Harness把模型、工具、循环、评测串起来的运行框架大脑的躯干和神经系统看懂这张表你就知道学习顺序为什么不能乱。先懂模型的能力边界再学怎么补知识RAG再学怎么让它动起来Agent最后学怎么把它管住上下文工程 Harness。跳过任何一步后面都会以玄学 bug的形式还回来。我见过太多人一上来就冲 Agent 框架结果连为什么模型会忽略我给的文档都解释不了。这不是框架的问题是底层认知缺了一块。下面我按自己实际走过的顺序一块一块拆。2. 第一阶段把模型本身摸透而不是急着套框架2.1 先搞清楚模型能做什么和模型以为自己在做什么学任何东西第一步都是建立准确的直觉。大模型最反直觉的一点是它没有不知道这个状态。你问它一个它训练数据里没有的事实它不会说我不清楚而是会基于语言概率生成一个看起来最像答案的答案。这就是幻觉的根源。我当时的做法是刻意做实验去感受这个边界。比如同一个问题问三遍看答案是否稳定给它一个虚构的人名问生平看它是否照样编得头头是道给它一段超长文本问细节看它在中段是否开始丢信息。这些实验花不了多少时间但能让你对什么时候必须外挂知识形成肌肉记忆。这里有个我踩过的坑很多人以为换个更大的模型就能解决幻觉其实不能。更大的模型只是让幻觉更像真的因为它的语言建模能力更强。真正解决幻觉的是 RAG 和工具调用不是模型参数量。想通这一点你就不会在选型上无限纠结。2.2 本地部署这件事值得亲手做一遍现在获取模型能力的方式很多云端 API 最省事。但我强烈建议每个学应用开发的人都亲手做一次本地部署哪怕只是跑一个 7B 级别的小模型。原因很简单只有自己部署过你才会真正理解上下文长度、显存占用、量化精度、推理速度这些参数是怎么互相牵制的。我当时的硬件不算强显卡显存有限所以走的是量化路线。量化说白了就是用更低的精度存模型权重比如把原本 16 位浮点的权重压到 4 位模型体积能缩到四分之一左右代价是精度略有损失。对于学习和验证流程来说这个损失完全可以接受。部署工具我最后留下的是 Ollama理由是它对新手足够友好一条命令拉模型、一条命令起服务不用折腾环境。但这里有个经验别一上来就追求哪个模型最强先追求哪个模型能在你的机器上稳定跑起来。跑不起来的模型再强也和你没关系。等你把流程跑通了再根据任务类型换模型。选模型的时候我一般看三个维度中文能力、指令遵循能力、以及在你硬件上的实际吞吐。前两个看评测和实际试第三个必须自己测。同一个模型在不同量化等级下回答质量差异可能比你想象的大尤其是涉及推理和代码的任务。2.3 微调不是万能药先问自己三个问题大模型微调这个词热度很高但我必须泼一盆冷水大部分应用开发场景根本不需要微调。微调适合的是改变模型的风格、格式或特定领域表达习惯而不是往模型里灌知识。灌知识用 RAG改行为才考虑微调。在决定微调前我会问自己三个问题我的需求是模型不知道某知识还是模型知道但输出格式不对前者用 RAG后者才可能微调。我有没有足够的高质量标注数据微调对数据质量极其敏感几百条脏数据能把模型带偏。我能不能接受微调后模型在其他任务上能力下降这就是所谓的灾难性遗忘。如果三个问题都指向微调那再动手。我做过一次小规模微调用的是 LoRA 这类参数高效方法它只训练一小部分附加参数不动原模型权重显存需求低很多。整个流程是准备指令格式的数据集、配置训练参数、跑训练、合并权重、部署验证。每一步都有坑比如数据格式和模型预期的模板不匹配会导致训练 loss 正常但推理结果一塌糊涂。微调最容易被忽略的一步是效果展示——你必须用一批没参与训练的样本去验证而不是看训练 loss 下降就以为成功了。3. 第二阶段RAG让模型说有据可查的话3.1 RAG 的本质是检索 拼上下文不是魔法RAG 全称是检索增强生成拆开看就三件事把知识存起来、根据问题把相关知识捞出来、把捞出来的内容拼进提示词让模型基于它回答。听起来简单但真正决定效果的是中间那一堆细节。我最初做 RAG 的失败经历很典型把所有文档一股脑切成一堆小段全部向量化存进库然后用户一问就检索最相似的几段丢给模型。结果模型经常答非所问或者把不相关的段落硬凑成答案。问题出在哪出在切分和检索这两个环节被我想得太简单了。切分不是随便按字数切。一份文档里一个完整的逻辑单元可能跨好几个段落你按固定长度硬切就会把一句话切成两半检索出来的片段语义不完整。我后来改成按语义边界切比如按标题层级、按段落、按句子边界并且让相邻片段有重叠避免关键信息正好落在切口上。3.2 检索质量决定 RAG 的上限检索环节我踩的坑更多。最核心的一个认知是向量相似度不等于语义相关。用户问退货流程文档里写的是商品退回操作指引字面差异大但语义相关纯向量检索可能漏掉反过来两段都提到退货但一个讲政策一个讲物流向量可能都召回但只有一个有用。所以成熟的 RAG 方案基本都会做混合检索向量检索负责语义匹配关键词检索负责精确匹配两路结果再融合排序。我实测下来混合检索对中文场景的提升非常明显尤其是涉及专有名词、编号、型号这类内容时。还有一个容易被忽略的点是重排序。检索阶段为了不漏通常会多召回一些候选然后用一个专门的重排序模型对候选做精细打分把最相关的排到前面。这一步相当于粗筛 精筛成本不高但效果提升明显。环节常见做法我实际采用的改进切分固定字数切按语义边界切 片段重叠检索纯向量向量 关键词混合排序按相似度加一层重排序模型生成直接拼上下文明确指令 引用来源3.3 RAG 和 MCP 到底什么关系经常有人问 RAG 和 MCP 的区别我用一句话概括RAG 解决知识从哪来MCP 解决工具怎么接。RAG 是把外部知识喂给模型MCP 是一套让模型能标准化调用外部工具和数据的协议。两者不冲突经常一起用——RAG 负责知识检索MCP 负责把检索能力、数据库、业务系统统一暴露给模型。理解这个区别很重要因为它决定了你架构设计时的分层思路。知识层用 RAG能力层用工具调用或 MCP决策层用 Agent 循环控制层用上下文工程。分层清晰后面出问题才好定位。3.4 一个能跑起来的 RAG 项目该有的样子我建议每个学 RAG 的人都完整做一个本地知识库项目哪怕只是给自己用。完整流程包括文档加载与解析、切分、向量化、入库、检索、重排、拼上下文、生成、引用标注。每一步都亲手写一遍比看十篇教程都管用。这里有个实操心得先别急着上框架用最朴素的方式把流程跑通一遍。比如手动调用向量化接口、手动算相似度、手动拼提示词。跑通之后你才知道框架帮你做了什么出问题时才知道该往哪查。上来就用全自动框架一旦效果不好你连从哪下手都不知道。引用标注这个细节也值得说。让模型在回答里标出这句话来自哪份文档的哪一段不仅提升可信度还方便你排查是检索错了还是生成错了。我现在的习惯是只要 RAG 效果不对第一件事就是看检索出来的原文八成问题出在检索而不是生成。4. 第三阶段Agent从问答到干活4.1 Agent 和普通调用的本质区别是循环普通调用是一问一答Agent 是给一个目标它自己决定下一步做什么做完看结果再决定下一步直到完成。这个循环是 Agent 的灵魂。它意味着模型不只是生成文本还要生成行动指令比如调用某个工具、查询某个数据、执行某段代码。我第一次写 Agent 的时候最大的困惑是模型怎么知道有哪些工具可用答案是你把工具的描述写进提示词里模型根据描述决定调哪个。所以工具描述写得好不好直接决定 Agent 聪不聪明。描述要清楚说明这个工具干什么、需要什么参数、返回什么。写得含糊模型就会乱调或者不调。4.2 工具设计比模型选择更影响成败我做过一个对比实验同一个模型同一套任务只改工具描述和参数设计成功率能差出一大截。这让我彻底改变了模型决定一切的想法。在 Agent 场景里工具设计的质量往往比模型选型更关键。好的工具设计有几个原则单一职责一个工具只干一件事参数明确每个参数的含义和格式都写清楚返回结构化方便模型理解结果错误信息友好工具失败时返回的信息要能让模型判断是重试还是换路。我见过最坑的工具设计是一个万能工具参数一大堆模型根本不知道该传什么最后只能瞎猜。4.3 Agent 的评测不评测就等于闭眼开车Agent 开发最容易失控的地方是改了一版不知道是变好还是变坏。因为 Agent 的行为是概率性的同一个输入两次运行结果可能不同。所以必须建立评测机制否则你就是在凭感觉调参。我的做法是准备一批有标准答案或标准行为的测试用例每次改动后跑一遍看成功率、平均步数、工具调用准确率这些指标。评测集不用很大几十条覆盖典型场景就够但必须稳定可复现。这里有个坑评测用例本身要定期更新因为你的 Agent 能力在变老用例可能已经不能反映真实水平了。Agent 评测还有个特殊难点很多任务没有唯一正确答案只有过程是否合理。这时候就要评过程比如工具调用顺序对不对、有没有多余步骤、有没有陷入死循环。我一般会记录完整的执行轨迹人工抽查加自动指标结合。4.4 多 Agent 不是越多越好现在多 Agent 很火但我踩过的坑告诉我大部分任务单 Agent 加好工具就够了多 Agent 反而增加不确定性和调试难度。多 Agent 适合的是那种职责天然分离、需要不同角色协作的场景比如一个负责规划、一个负责执行、一个负责审核。如果只是把单 Agent 的任务硬拆成多个只会让通信成本飙升、错误传播链变长。我现在的原则是能用单 Agent 解决就不上多 Agent实在需要再拆而且拆的时候要明确每个 Agent 的边界和交接协议。边界不清的多 Agent 系统调试起来是噩梦。5. 第四阶段上下文工程决定 Agent 智商的隐形手5.1 上下文不是塞得越多越好上下文工程这个词听起来玄其实核心就一句话在每一步决定往模型的上下文窗口里放什么、不放什么、以什么顺序放。这件事直接决定模型的表现但很多人根本没意识到它的存在。我早期的一个错误就是能塞就塞把历史对话、检索结果、工具返回全堆进去。结果模型开始忽略关键信息或者被无关内容带偏。后来我才明白模型的注意力是有限的上下文越长关键信息被淹没的概率越大。上下文工程的第一原则是做减法不是做加法。具体怎么做我会把上下文分成几类系统指令角色和规则、当前任务用户目标、相关记忆历史关键信息、工具结果刚拿到的数据。每一类都要精简只保留当前步骤真正需要的。历史对话不是全留而是摘要或只留关键节点。5.2 上下文压缩和记忆管理Agent 跑多步之后上下文会迅速膨胀。这时候就需要压缩。压缩不是简单截断而是把历史信息提炼成更短的摘要保留决策相关的部分。我一般会让模型自己总结到目前为止发生了什么、结论是什么、下一步该干什么把这段摘要作为后续的上下文。记忆管理是另一个关键点。短期记忆是当前任务的上下文长期记忆是跨会话的知识。长期记忆通常存到外部存储需要时检索回来。这里和 RAG 的思路是相通的——记忆本质上也是一种检索。5.3 上下文工程和 Harness 的关系Harness 这个词最近很热我的理解是它是把模型、工具、循环、上下文管理、评测全部串起来的运行框架。如果说 Agent 是会干活的系统那 Harness 就是让这个系统稳定运行的骨架。上下文工程是 Harness 里最核心的模块之一因为它决定了每一步模型看到什么。很多人问 Harness 和 Agent 的区别我打个比方Agent 是司机Harness 是整辆车加交通规则加仪表盘。司机再厉害车不行、规则不清、仪表盘没有照样到不了目的地。所以学 Agent 到一定阶段必然会接触到 Harness 这一层因为它解决的是如何让 Agent 可靠、可观测、可迭代的问题。6. 第五阶段把一切串起来做一个完整项目6.1 项目选题从自己真实的需求出发学到这里最有效的巩固方式就是做一个完整项目。选题我建议从自己真实的需求出发因为真实需求有真实的边界和验收标准不会像玩具项目那样随便糊弄。比如做一个个人知识助手能检索自己的笔记、能调用几个工具、能多轮对话、能引用来源。这个项目会把前面所有东西串起来RAG 负责知识检索Agent 负责决策和工具调用上下文工程负责控制每步输入Harness 负责整体运行和评测。做完一遍你对整个体系的理解会从知道变成会做。6.2 环境配置和部署的实战细节环境配置是新手最容易卡住的地方。我的经验是把环境当成项目的一部分来管理而不是临时凑合。依赖版本要固定配置文件要版本化部署脚本要能一键复现。我踩过最深的坑是在我机器上能跑换台机器就各种报错最后发现是依赖版本不一致。部署的时候要考虑几个现实问题模型放哪、服务怎么起、并发怎么处理、失败怎么重试、日志怎么看。这些在玩具项目里可以忽略但一旦要给别人用一个都不能少。我一般会先做一个最小可用版本跑通主流程再逐步加健壮性。6.3 效果展示和迭代项目做完一定要做效果展示而且要诚实。展示成功案例的同时也要展示失败案例和边界。这不是自曝其短而是让你和用户都清楚系统能干什么、不能干什么。我现在的习惯是准备一组典型问题覆盖简单、中等、困难三档跑一遍看表现把结果记录下来作为基线。迭代的时候每次只改一个变量然后跑评测对比。同时改多个地方你永远不知道是哪个改动起了作用。这个原则听起来简单但真做起来很容易违反因为人总想一次改到位。忍住一次一个。7. 我踩过的那些坑以及最后留下的工具和方法7.1 那些让我熬夜的典型问题第一个坑是提示词里的指令被模型忽略。排查了很久才发现是指令放在了上下文中间被长文本淹没了。解决办法是把关键指令放在开头和结尾中间放参考资料。这个规律后来成了我的固定习惯。第二个坑是工具调用陷入死循环。Agent 反复调用同一个工具因为工具返回的错误信息不够明确模型以为重试就能成功。解决办法是给工具加最大重试次数并且让错误信息明确告诉模型这条路走不通换一种方式。第三个坑是RAG 检索到了正确文档但模型没用。原因是拼上下文时没有明确告诉模型请基于以下资料回答模型就自由发挥了。加上明确的指令和引用要求后问题基本消失。7.2 我最后留下的工具组合工具这东西适合自己的才是最好的。我最后留下的组合是本地部署用 Ollama 做快速验证向量库用轻量方案先跑通Agent 框架选一个社区活跃、文档清楚的评测自己写脚本。框架只是脚手架核心逻辑一定要自己能讲清楚。如果用了某个框架但说不清它内部怎么运转那这个框架对你就是黑盒出问题只能干瞪眼。7.3 给不同阶段的人的建议如果你刚入门别贪多先把调用模型 简单 RAG跑通建立信心。如果你已经会调 API重点补上下文工程和评测这两块是区分玩具和产品的分水岭。如果你已经在做 Agent把精力放在工具设计和可观测性上这两块决定你的系统能不能规模化。学习路径不是线性的我经常在做一个项目时回头补前面的知识。这很正常带着问题去学比按部就班地学效率高得多。我自己的习惯是每学一个新概念就立刻找一个小场景用起来用不起来就说明还没真懂。最后分享一个我坚持了很久的小习惯给每个项目写一份踩坑记录记下遇到的问题、排查过程、最终解法。这份记录比任何教程都值钱因为它是你自己的。下次遇到类似问题翻出来就能用。学大模型应用开发这件事拼的不是谁记得多而是谁踩的坑多、总结得快。