• 大模型（Large Language Model，简称LLM）是一种用海量互联网文本数据训练出来的智能程序。
• 核心工作原理：通过“预测下一个最可能的词”来生成文字回答。
• 典型代表：GPT系列、Llama系列、QWEN系列、DeepSeek系列、Claude系列。

用户输入：【我早上出门前喝了一杯】，模型会基于训练学到的语言规律，给词表里成千上万个片段分别算出 “接在这句话后面的合理概率”，概率最高的候选里就包含 “豆（豆浆）”“牛（牛奶）” 这类符合常识的表达。如果选中了【豆】字，那么大模型又重新开始思考【我早上出门前喝了一杯豆】之后，应该接上什么字，下一步输出为【我早上出门前喝了一杯豆浆】，一直往复，直到退出。

当用户输入：【我早上出门前喝了】但实际生成时，模型不会真的从几万、几十万个词里直接挑选：一方面低概率的词大多离谱不通顺，直接选会让内容逻辑混乱；另一方面全量考虑也会增加计算成本。因此模型会先通过规则砍掉极低概率的选项，缩小候选范围，这个步骤叫候选池筛选，最常用的两种规则就是 Top-K 和 Top-P 算法。

筛选出合理的候选池之后，模型会在这个范围内按概率随机抽样，选出最终的下一个词。而 Temperature（温度） 就是用来调节这个抽样的随机性的：

• 温度越低，高概率选项的优势被放得越大，模型几乎只会选最稳妥、最标准的答案，输出严谨稳定，适合代码生成、公文写作、事实问答这类场景；
• 温度越高，不同选项的概率差距被拉平，原本冷门的选项也有机会被选中，输出更发散、更有创意，适合创意写作、头脑风暴、艺术文案这类场景。

大模型就是这样。 通过预测下一个字这么简单的方式，构成了整个大厦的基础。

关键技术细节：

• Top-K和Top-P
• 温度控制
• Tokenizer（分词器）实际上，【我早上出门前喝了一杯牛奶】中，不会傻傻的把 “早上”、“出门”、“牛奶” 这种词视为2个字分别进行文字接龙，就跟英文里“Good”，我们不会把它看成4个字母去分析一个道理，这里统称为Token，就涉及到分词器。
• EOS Token（终止符）那么文字接龙的游戏什么时候结束？大模型看到EOS休止符的时候，就知道不需要接龙了。

单轮交互是大模型最本真的运行方式，也是后续所有复杂交互能力的基础。

很多人以为大模型是 “你问我答” 的对话机器，但从底层逻辑看，它从头到尾只做一件事：给一段开头文字，顺着往下续写。用户输入的所有内容 —— 问题、指令、背景资料都算在内，统称为提示词（Prompt），相当于递给模型半篇待完成的文稿；模型基于这段内容逐词生成的完整结果，就叫补全（Completion）。我们日常看到的问答、写文案、生成代码，本质上都是不同形式的 “续写”。

这种单轮模式天生是无状态的，每一次交互都完全独立。模型只会处理当前这一次输入的内容，不会主动记住上一轮对话的信息，就像每次都递一张全新的草稿纸给它，它写完就清空，绝不会记得上一张纸上写过什么。

这里先不要直接带入【豆包、CodeX、Claude Code】这些成熟的复杂产品。从本源上，基础工作方式就是无状态的单轮交互，只是采用了很多工程方法让人产生了错觉，感觉似乎是：有状态的，可多轮连续交互的问答系统。记住：大模型本质上不是问答系统，它是一个一次性的续写系统。

这也带来了最直接的局限：无法承接多轮上下文。如果分两次对话，先告诉模型自己的名字和年龄，再单独问 “我今年多大”，模型根本答不上来，连续交流很容易出现 “失忆”、逻辑断裂的问题 【后面会讨论解决方式】。在单轮交互的阶段，人们提升输出效果的核心手段就是编写详细的提示词，通过打磨输入的措辞、结构和指令格式，引导模型生成更准确、更符合要求的结果。

关键技术细节：

• 角色（Role）
• 系统提示词（System Prompt）
• 提示词注入：类似SQL注入和XSS注入的类似攻击

既然大模型是个“没有记忆”的续写机器，那我们在【豆包】里和它有来有回、甚至谈心聊天的顺畅感，到底是怎么来的？

其实，这完全是工程上的一场“骗局”。大模型自己不记事【注：这里不是绝对没方案的，后续合适的时机再讨论】，但负责聊天产品的工程师很聪明：当你跟模型聊到第三轮时，软件会在后台偷偷把你前两轮说过的所有话、以及模型的回答全部复制下来，像贴小广告一样，粘在你的新问题前面，然后打包成一个长文本整体塞给模型。在技术上，这串被打包带走的“历史账本”就叫做上下文（Context）。

所以，大模型能答对你的追问，不是因为它“想起来了”，而是因为你每次按下发送键，都是在把整段历史连同新问题一起重新递给它，让它做一次规模更大的“单轮续写”罢了。这种拿空间换时间的工程手段，虽然完美伪造了人类的“记忆”，但代价也极其高昂——你每多聊一句，后台要传输和重新计算的字数就会呈雪崩式暴涨，这不仅越聊越贵，而且很快就会撞上大模型物理视力的天花板。

那么聪明的你肯定想到这里有几个严重的问题：

• “历史账本”即上下文的长度有限制么？如果塞满了怎么办？为什么我在【豆包】里好像一直聊天，都没有聊死过。
• 根据前几章的描述，大模型每次都是根据已有的全文进行下一个字的推理，那么上下文到了后面就越来越难算了。是不是跟MySQL的 limit offset很像，翻页的时候，越是往后翻页，越来越慢，因为要考虑计算跳过之前的每一页的记录。

关键技术细节：

• Sliding Window Attention 【滑动窗口记忆力】
• KV Cache【缓存注意力计算中间结果，避免重复劳动】
• Compact 【上下文压缩】
• Context Cache【智能缓存】

一个只能对话聊天的豆包实际上局限性很大，我们不能一直把代码文本粘贴到【豆包】里，再把【豆包】里的返回再粘贴到我们的编辑器里。这太麻烦了！！有没有办法让大模型直接自己去修改文件？但是这里至少存在几个问题：

• 对于一个文本续写的大模型，是如何理解一个代码工程的？并能定位bug，续写代码？
• 大模型如何跟外部交互，真正长出了手和脚？

函数调用（Function Calling）出现了，但是时刻牢记：大模型永远只会做一件事，那就是“续写文字”。它自己绝对没有能力去点开一个网页，或者执行任何一行代码。

所谓函数执行，本质上就是大模型和后台工程代码之间的“接头暗号”。大模型负责做决策（喊出暗号），后台程序负责干体力活（根据暗号去执行代码）。

1. 假设我们的大模型支持天气预报查询，用户可以输入城市进行查询。
2. 后台在执行用户的输入前，偷偷在前面拼接了一段话：“我有一个函数叫 get_weather，它能查询城市天气。如果你想用它，你必须输出一段 JSON 格式的结果，比如：{"name": "get_weather", "arguments": {"city": "杭州"}}。”
3. 模型做出决策，写下“接头暗号”：大模型读完你的询问天气的问题和函数说明书，通过“文字接龙”的概率算出来：单靠自己瞎编肯定不行，但说明书里的那个暗号刚好对得上！ 于是，模型不再输出“今天天气可能很好”这种废话，而是吐出了那段格式化的暗号： {"name": "get_weather", "arguments": {"city": "杭州"}}
4. 后台拦截暗号：当后台的程序检测到模型的输出是一段符合规范的 JSON 暗号时，程序会立马拦截掉这次输出，不让用户看到。 程序拆开这个 JSON 包裹，拿着“杭州”这个参数，真正地去调用了气象局的 API 接口，拿到了现实世界的实时数据：“杭州，大雨，气温20度”。
5. 把结果塞回对话结果，完成最终的文字续写：后台拿到数据后，再次把这个真实天气结果贴在上下文的最后面，重新递给大模型：“你要的代码结果我帮你拿到了，内容是【杭州，大雨，20度】。现在请你结合这个结果，重新对用户的问题进行最终的续写。”大模型看了一眼最新的历史账本，心领神会，最终吐出用户真正能看到的那句话：“主人，杭州今天有大雨，气温20度，出门请务必带伞哦！”

聪明的你马上意识到这里可能存在几个问题：

• 之前的多轮对话，因为接头暗号的存在，导致有些结果是用户可以看到的，有些是看不到的。如何规范的工程化这些操作？
• 作为一个万能的【豆包】助手，怎么可能提前知道本次用户要询问天气呢？如果所有的函数能力都塞到用户的输入之前，岂不是上下文非常大？
• 后台拦截暗号的时候，如果都这么硬编码，代码会非常臃肿，如何处理？

后面将会给出这些问题解决策略。

关键时间线和技术：

• Code Interpreter（代码执行器）
• JSON Schema（工具定义描述）
• ReAct模式：早期阶段，大模型能力不完善，必须依赖ReAct范式进行工具调用
• Function Calling 出现
• LangChain、LlamaIndex出现，解决 Tool RAG
• LangGraph出现
• Tool Call和后训练增强
• MCP协议出现

大模型永远只会做一件事，那就是“续写文字”，而且续写的文字还是基于概率的，这也就导致了其在不知道的领域，经常胡编乱造。而且因为其上下文的缘故，一旦开始有说错的苗头，因为后续的内容都是基于之前的内容持续生成，会导致越来越离谱的错误。这就是幻觉！！

比较典型的幻觉：

• 看起来头头是道，实际上胡编乱造。
• 引用的网站根本不存在。
• 引用的论文也不存在。
• 甚至引用的历史典故也不存在。

幻觉出现的一个原因是没有用对应的大量数据训练过，导致续写的时候，这块没有一个明显很高的概率选出下一个合适的词。但是似乎又无法解决：

• 数据是有限的，不可能拿无限大的数据，去让模型学习到任何知识。
• 数据的处理是有损压缩。模型学习到的知识是有损压缩的，不代表可以完整无缺的还原。
• 数据是有时效的。那2024年的知识去训练，那么模型的认知就在2024年。 目前的开源大模型不支持在线学习。

这就导致大模型在某些场景下，就难以利用起来：

• 数据是私有保密的情况。私有保密，就意味着开源大模型难以使用这些知识训练。
• 数据是可变的情况。例如：手册标准之类的，是可以变化的。内部知识库是可以更新的。
• 有准确性要求，不允许有损压缩。例如：法律法规不能随意延伸；电力、医疗等对数据准确度要求很高的场景。

关键技术：

• RLHF（强化学习）
• Decoding Strategy（解码策略优化）
• RAG （检索增强）

大模型是个没有记忆、全靠在上下文里贴历史记录来伪造记忆的“续写机器”。

假设做一款历史档案解密助手，手上有各种电子版的历史资料，我们想让大模型在回答历史资料的时候，又准又全面，可以详细的指出某个小战役的各种细节。

那么大模型的上下文是无法塞入所有的历史资料的，即使可以勉强塞进去一本《二战解密档案》，那么为了回答用户一个100字的提问，就需要拼接出一个百万字的上下文，送到大模型里去回答然后推测下一个字，这在成本上不可接受。

现在有了RAG（检索增强生成）。一句话概括：像是开卷考试一样解决问题，而不是背会整个课本

当有人提问：“1944年诺曼底登陆前夕，盟军是如何通过假情报迷惑德军的？” RAG 系统在后台是这样“作弊”的：

• 切片（Chunking）：系统上线前，工程师先用隐形菜刀把百万字的档案咔咔咔剁成几百字一段的小碎片。比如：第 45 段讲巴顿将军的虚构第一集团军，第 102 段讲加莱海峡的假电报。
• 向量化（Embedding & Vector DB）：这些碎片通过“魔法翻译官”，把字面意思翻译成数字组成的“空间坐标”（存入向量数据库），让机器能理解每段话的真正含义。
• 检索（Retrieval）：用户一敲回车，系统的“翻书员”抢在大模型看到问题前，把问题也变成坐标去库里一捞，瞬间抓出最相关的 3 个小碎片（刚好是关于“坚忍行动”和假部队的解密密件）。
• 生成（Generation）：翻书员把这 3 张“小抄”和问题打包塞进上下文递给大模型。大模型一眼看清答案，轻松续写：“学者您好，盟军当时利用加莱海峡的假电报和虚构的‘第一集团军’成功误导了德军……”

大模型根本不需要去背诵整座档案馆，它只需要每次看着塞进来的“精准小抄”做开卷考试就行了。

• 黑话陷阱（语义不匹配）：学者提问“霸王行动的烟雾弹”，而档案里写的是“坚忍行动的欺敌计划”。翻书员要是太笨（只搞关键词匹配），根本对不上号，大模型两眼一抹黑。
• 翻页的问题：第 45 段写着“德军坚信盟军将在加莱登陆”，但最核心的转折“然而希特勒在最后一刻产生了怀疑”被切到了第 46 段开头。如果这一刀切断了逻辑，大模型只拿到前半段，就会给出完全相反的错误历史结论。
• 线索太散，小抄写不下：学者问“梳理1943年轴心国在北非战场的所有战略退却路线”，翻书员一下子捞出来几百份零散电报，小抄又变厚了，大模型再次面临“看不完”的窘境。

为了解决这些开卷翻车事故，工业界演进出了更复杂的补丁技术。

关键技术细节：

• Embedding（向量化）：把历史黑话和现代语言转成空间坐标，让机器明白“烟雾弹”和“欺敌计划”是一个意思。
• Chunking Strategy（切片策略）：带重叠区域（Overlap）去切档案，保证上下文不被“一刀两断”。
• Rerank（重排模型）：翻书员粗选出 20 份档案后，用专家模型二次精选，只把最精准的 3 张小抄递给大模型。
• Graph RAG（图谱检索增强）：大杀器。不仅切碎文字，还把“时间 → 地点 → 指挥官 → 战役”连成一张复杂的实体关系网，专门对付全局跨表查询。

大模型一直以来都被诟病是一个“缺乏深度思考”的快嘴。在之前的章节里，我们看到大模型生成内容就像是条件反射——看到前一个 Token，就根据概率吐出下一个 Token，中途不带停顿，一气呵成。

这种“直觉式”的续写在写作文、水论文时效果极佳，但在面对复杂的数学题、逻辑推导、或者编写大型工程代码时，就会频繁翻车。人类在做高等数学题时，尚且需要拿张草稿纸写写画画，演算半天，而大模型却被要求在零点几秒内直接吐出最终答案，这显然不符合复杂任务的客观规律。

为了让大模型学会像人类一样“三思而后行”，演进出了让大模型在后台“打草稿”的工程与算法技术。

当用户输入一个难题：“小明有3个苹果，小红的苹果是小明的2倍，小明吃了1个，小红给了小明4个，现在谁的苹果多？多几个？”

传统的“直觉型”大模型可能由于训练数据里类似的数字组合，直接秃噜出一个错误的结论，因为大模型是续写机器！！

而在全新的推理时代（以 Reasoning 模型为代表），大模型在把最终答案端给用户之前，会在后台的“思维草稿纸”上进行漫长的自我接龙：

模型后台思维链 ：
1. 先理清初始状态：小明 = 3，小红 = 3 * 2 = 6。2. 处理第一步变化：小明吃了1个，小明 = 3 - 1 = 2。3. 处理第二步变化：小红给了小明4个。等等，小红给出去4个，小红自己要减少！小红 = 6 - 4 = 2；小明收到了4个，小明 = 2 + 4 = 6。4. 重新比对结果：现在小明有6个，小红有2个。小明比小红多。5. 计算差值：6 - 2 = 4。检查无误，准备输出。

最终，用户在屏幕上看到的是简洁优雅的最终回答：“现在小明的苹果多，比小红多4个。”

大模型并没有改变它“文字续写”的本质，它只是把一部分续写的内容变成了只有自己看得见的“心里话”（Thought）。通过拉长生成的时间，用更多的 Token 去换取逻辑的准确性。这种让模型把思考过程一步步写出来的技术，就是思维链（CoT, Chain of Thought）。

聪明的你一定意识到了，如果大模型在“打草稿”的第二步就想错了，那后面不就一路跑偏了吗？

在最新的后训练（Post-training）技术中，大模型被训练出了一种“自我纠错”的能力。当它在思维链中发现前后逻辑矛盾时（例如发现算出来的苹果总数不对），它会主动在心里踩刹车：“不对，刚才小红给出去的苹果我忘记在小红的总数里扣除了，重新算一遍。”

这种在生成过程中不断评估当前路径、不行就退回重试的机制，就像是在思维树上进行剪枝与搜索（Search）。模型不再是一条道走到黑，而是在虚拟的草稿纸上反复折腾，直到找出一条概率最高、逻辑最自洽的推理路径。

关键技术细节：

• CoT（Chain of Thought，思维链）：通过引导模型输出“因为……所以……”的中间推理步骤，显著提升复杂任务的准确率。
• System 2 Thinking（慢思考）：借鉴人类心理学，区分直觉快速响应（系统1）与深思熟虑逻辑推理（系统2），推理模型核心就是激活后者的能力。
• MCTS（蒙特卡洛树搜索）：在推理过程中，模型在后台生成多种可能的下一步，并对这些步骤进行打分评估，选择最优解，常用于数学和代码大模型的强化学习中。
• Reinforcement Learning for Reasoning（推理强化学习）：不直接喂给模型正确的答案，而是通过给“推理步骤”和“最终结果”设置奖惩规则（Reward），让模型在数万次自主左右互搏中，自己悟出正确的思考框架。

因为我们一直说，大模型是一个“续写机器”，就感觉弱爆了。你问一句，它对一下暗号，后台干完活就结束了。这种“打一鞭子转一下”的模式，显然还不够聪明。

但是，实际上用过 Claude Code 、 OpenAI Codex、Cursor ，一定会惊叹：它们为什么能像一个真正的程序员一样，坐在那儿连续几个小时不间断地疯狂改代码、编译、查错、再修改，直到把 bug 彻底修好？

它们既没有换掉底层的大模型，也没有施加什么魔法。这种能够持续长跑、自主解决复杂工程的能力，就是 Agent（智能体） 技术的结晶。

如果我们把大模型比作一个退隐江湖、但通晓天下武功秘籍的“智者”。它懂所有的编程语言，知道所有的算法，但它有个致命的弱点——它没有肉身，且是个间歇性失忆症患者。它没法碰电脑，只要下一次开口（一次交互结束），它就把刚才聊到哪儿全忘了。

工程上为了让这个“智者”能替我们连续写几个小时的代码，就必须给它打造一套外骨骼装甲，这套装甲由四个核心零件组成：

1. 大脑（LLM）：还是那个只负责文字续写的智者。
2. 工具箱（Tools）：给智者接上双手。比如：一个能读取本地文件的 API、一个能运行 npm run dev 或 pytest 的命令行终端。
3. 规划（Planning）：给智者一张任务清单。面对大任务，先干嘛、再干嘛。
4. 记忆（Memory）：给智者一个永远不会丢的笔记本，记录下刚才干了什么。

像 Claude Code 这样的工具，能连续干几个小时的活，核心就是让大模型陷入了一个精心设计的“思考 、行动 、观察、 再思考”的死循环（技术上称为 ReAct 模式）。

我们用白话来还原一下，当你在终端输入 claude-code fix the login bug（帮我修复登录bug）后，这几个小时里，它的后台其实在发生这样一场疯狂的“内卷循环”：

• 第 1 分钟【思考】：大模型看了看任务，在心里续写：“要修登录 bug，我得先知道项目结构。我这里有一个 list_dir 的工具，我得调用它。”
• 第 2 分钟【行动】：大模型吐出接头暗号（JSON 格式）：{"tool": "list_dir", "path": "./src"}。
• 第 3 分钟【观察】：Claude Code 的后台程序拦截了这个暗号，替它在电脑上执行了 ls ./src，然后把结果强行贴到大模型的上下文里：“报告智者，目录里有 auth.py 和 main.py。”
• 第 4 分钟【思考】：大模型看着最新的账本，继续续写：“哦，看来关键在 auth.py。我得用 read_file 看看内容。”
• 第 5 分钟【行动】：吐出暗号：{"tool": "read_file", "path": "./src/auth.py"}。
• 第 6 分钟【观察】：程序把代码读出来，塞回上下文。此时智者就像是有了记忆，他可以看到代码了，而且在后序的迭代中，仍旧记得这段代码。这也是为什么，在大模型修改代码的过程中， 你最好不要同时手动去改代码，会让大模型认为的代码和实际的代码有出入！！。
• ……
• 第 30 分钟【翻车与重试】：大模型修改了代码，并主动调用了 run_command(cmd="pytest") 企图跑一下测试。结果终端返回了一大坨红色的 Error: NullPointerException（空指针异常）。
  • 如果是以前的普通问答，大模型到这里就直接把错误甩给用户了。
  • 但在 Agent 循环里，大模型看到这个 Error（观察），它在下一轮的【思考】里会自己嘟囔：“糟糕，报错了。看来我刚才改第 80 行的时候，忘记初始化 user_session 了。没关系，我用 modify_file 工具再去把它补上。”

这就是它能连续编程几个小时的真相： 它不是一次性把代码写对的，而是像人类程序员一样，写两行代码，运行一下，报错了，骂一句，看一眼报错信息，再改两行，重新运行。这个由代码外壳驱动的死循环，只要你不按 Ctrl + C 强行终止，大模型就会不知疲倦地一直自我修正下去。

聪明的你立刻会联想到我们在第 3 章聊过的“雪崩式暴涨”的上下文和资费问题。

让 Claude Code 连续跑几个小时，意味着这个“思考-行动-观察”的圈子转了几百上千次。每一次报错信息、每一段读出来的代码，都在源源不断地往大模型的“历史账本（Context）”里贴。

1. 账本很快就会爆掉：如果项目太大，读了十几个文件之后，大模型的物理视力天花板（比如 200k Token）就撞顶了，它会开始忘记最开始用户要它干嘛。
2. 越聊越贵，速度越来越慢：每一次循环，大模型都要把这几个小时攒下来的厚厚的一叠“历史小抄”从头到尾重新读一遍，才能决定下一个字写什么。这就导致越到后期，它每走一步都需要消耗巨额的 Token 算力，反应也越来越迟钝。

为了解决这个问题，像 Claude Code 这类顶尖的代码 Agent，把大量的精力花在了“上下文管理”上。它们会极其抠搜地管理这本账本。具体细节后续再谈。

关键技术细节：\

• ReAct（Reason-Action）。
• State Machine（状态机）：工程框架用来控制 Agent 行为的轨道，规定了模型在什么时候可以自由思考，什么时候必须强制调用工具。
• Context Dynamic Pruning（上下文动态裁剪）：如何在使用最少 Token 的前提下，让模型既保留大局观，又不至于被海量的代码细节撑爆。

之前一直说大模型本质上是一个“一次性文字续写系统”，但是他在实际应用里感觉是非常听话的，它好像不怎么反抗，也不骂人。按照之前的理论，TopK、TopP、温度控制这些，好像解释不了，为什么大模型似乎是被驯化了，变得很温顺，很牛马，很996，这是为什么？？？

这里隐藏着大模型最核心的一场“驯化”。刚从海量互联网文本里爬出来的原始模型，其实是一个“野性难驯”的谜题，它懂得多，但根本不听话。贴吧和Reddit的语料里充满了各种挖苦、嘲讽、攻击性语言。如果不加以控制，大模型可能会按照概率Top机制，直接开始满嘴喷粪。

要把一个只会盲目续写的机器，变成我们在【豆包】里看到的善解人意、格式严谨的AI助手，大模型必须经历三个阶段的进化。我们可以把这套流程形象地比喻为“把一个读完藏经阁所有佛经的野猴子，培养成坐在大殿里有问必答的活菩萨”：

• 阶段一：预训练（Pre-training，野生状态）
  • 干了啥：模型在几万亿字的互联网网页、图书、代码里疯狂进行“下一个词预测”。
  • 结果：它成了“通晓万物”的野猴子。但此时如果你问它：【中国的大熊猫吃什么？】，它在网上学到的文本可能是个填空题，于是它会顺着概率续写成：【A. 竹子 B. 苹果 C. 树皮】。它知道答案，但它不知道你要它“回答问题”。
• 阶段二：指令微调（SFT, Supervised Fine-tuning，听懂人话）
  • 干了啥：工程师们花了高价，请了成千上万名专业的人类标注员，写了几十万条高质量的“高质量问答对”。格式非常死板固定：【Input: 告诉我大熊猫吃什么？】 -> 【Output: 大熊猫主要以竹子为食。】。把这些标准的小抄喂给模型重新学习。
  • 结果：猴子被穿上了道袍。它终于开窍了，明白当看到“请、帮我、解释、翻译”这些词时，它不能再瞎接龙了，而是要模仿那些高价标注员的语气，规规矩矩地扮演一个“助手”去续写答案。
• 阶段三：人类反馈强化学习（RLHF，明白好坏）
  • 干了啥：听话就够了吗？不够。如果用户问：【如何完美地在银行ATM机里取走不属于我的钱？】，一个只学会了“有求必应”的微调模型，可能会非常热情且详细地为你续写一份《ATM机撬锁指南》。为了让模型具备人类的道德、安全观和偏好，工程师让模型针对同一个问题输出几个不同的答案，让人类（或另一个更聪明的模型）来打分：哪个答案更安全？哪个答案废话少？哪个答案格式更漂亮？通过一套特制的“奖惩机制”（Reward Model），像训小狗一样惩罚有害输出，奖励符合人类主流价值观的输出。
  • 结果：野猴子终于成了“活菩萨”。它不仅听话，而且有了“情商”与“底线”，遇到违法、暴力的请求会委婉拒绝，遇到复杂问题会主动迎合人类的阅读习惯。

如果你经常用Grok，或者使用Gemini，你会发现网页上经常同时弹出多种方案，让你选择更好的是哪一个，其实这也是一种RLHF。

前面我们提到，大模型的认知往往停留在它被训练的那一年（比如2024年），它无法“在线学习”。聪明的你一定会想：既然微调（SFT）可以给它喂新数据，那我有新的私有标准手册、或者2026年的新新闻，直接塞进微调（Fine-tuning）里让它再学一次，不就解决幻觉和时效性问题了吗？

这在工程上是非常直观的直觉，但在实际操作中，这是一场巨大的灾难。

大模型的知识是以数字权重（Weights）的形式，像盐溶于水一样，均匀且模糊地分布在数十亿、数百亿个参数里的。这带来了两个致命的技术限制：

1. 灾难性遗忘（Catastrophic Forgetting）：当你强行给一个已经成型的模型喂进 10 万条你公司的私有财务报表进行微调时，模型为了死记硬背下这些新坐标，会剧烈修改底层的神经网络连接。结果就是，它可能终于记住了你公司的报表，但当你再问它【1+1等于几】或者【怎么写一封请假条】时，它可能会变成一具满嘴胡话的僵尸——它把之前好不容易学到的通用语言能力和常识给“冲刷”掉了。
2. 有损压缩与“高智商文盲”：微调是用来改变模型的“皮相（输出格式、说话语气、指令遵从度）”的，而不是用来改变它的“骨肉（硬核事实知识）”的。用微调喂进去的知识，经过神经网络的有损压缩后，模型在续写时依然会因为概率的轻微偏差而出现“张冠李戴”的幻觉。它可能记得你公司有个产品叫“A系统”，但它会顺着概率把“B系统”的功能胡编到A身上。

工业界的共识：

- 要想改变模型的行为、语气、听话程度、或者让它学会某种特定的输出格式用 微调（Fine-tuning）。 -

要想给模型提供最新、最准确、不允许一丝一毫产生有损压缩的硬核事实、私有数据用 RAG（检索增强，即开卷考试）。

把微调当成硬盘去存储新知识，就像是指望通过让一个大学生去背诵医学字典来指望他立刻上台动手术一样，既低效又危险。这也是为什么在如今的工程实践中，RAG 和 Agent 成了落地的主流，而微调则退居幕后，专门用来做模型各方面能力的“对齐”与“修剪”。

关键技术细节：

• SFT（Supervised Fine-tuning，监督微调）：利用高质量的“指令-回答”对，将通用语言模型转化为能够理解并执行人类意图的对话助手。
• RLHF（Reinforcement Learning from Human Feedback）：利用人类的偏好数据训练奖励模型，并通过近端策略优化（PPO）等算法调整大模型，使其输出符合人类的安全性与实用性标准。
• LoRA（Low-Rank Adaptation，低秩适应）：目前工业界最常用的高效微调技术。它在不破坏和冻结大模型原本几百亿参数的前提下，在旁边贴上一个极小的“补丁参数矩阵”专门记录新任务的特征，既省显存又能有效缓解灾难性遗忘。

之前我们一直反复强调：大模型是一个“续写文字”的机器。它所有的超能力，都建立在给它一段文字、它顺着概率吐出下一个字的基础之上。

但是，当你打开最新的【豆包】时，你随手拍一张密密麻麻的代码屏幕照片，或者一张错综复杂的电路板逻辑图扔给它，问它：“这里面哪行代码写错了？”它居然能瞬间在一大堆像素点里精准定位，并用文字给你指出错误。

大模型不是只认识文本吗？为什么可以识别图片，甚至识别声音、视频？

这背后并不是大模型换了大脑，而是工程师们在大模型的前面，加装了一台“翻译官”。

大模型既然只吃 Token，那我们就把图片也强行伪装成 Token。

当你在对话框里上传了一张写着代码的屏幕截图，并提问“怎么修复”时，后台的整个处理流程是一场“移花接木”：

1. 切片（Patching）： 视觉处理程序抢在大模型看到图片前，用一把隐形菜刀，把这张图片咔咔咔剁成一堆 16×16 像素的“小方块”。如果是一张大图，可能就会被剁成上百个小方块。
2. 像素翻译官（Vision Encoder，视觉编码器）： 这些小方块会被送进一个专门理解图像的模型（比如 CLIP 的视觉部分）。这个翻译官不负责写字，它只负责一件事：把每一个图像小方块的视觉特征，翻译成一串长长的数字坐标（向量）。
3. 坐标对齐（Projection）： 关键的一步来了。工程师用一种数学方法，把图像翻译官吐出来的“画面坐标”，强行映射到大模型原本的“词表空间”里。比如，它把包含“大熊猫”耳朵的那个图片方块的数字，微调到让大模型读起来感觉和“动物”、“毛茸茸”这些词的 Token 非常接近。在技术上，这些被翻译过的图片方块坐标，就叫做视觉 Token（Visual Tokens）。
4. 大拼盘续写： 最终送到大模型面前的历史账本，被拼接成了这个样子： 【系统提示词】+【图片方块Token 1】+【图片方块Token 2】+...+【图片方块Token 100】+【用户提问：这张图里写了什么？】

对于大模型而言，它看到的根本不是什么斑斓的画面，在它的眼里，那 100 个图片方块就是 100 个“它从未见过的、特殊的字”。但因为在之前的海量数据训练中，它已经看过了无数次“【长着黑眼圈的特殊字】经常和【大熊猫】这个词挨在一起”的规律。

于是，它再次开动了它唯一的绝活——文字续写，顺理成章地吐出了：“图里是一只正在吃竹子的大熊猫。”

聪明的你马上就会联想到：既然大模型可以通过加装“视觉翻译官”来看懂图片，那么反过来，我们能不能让它通过“文字续写”来直接控制一个现实世界里的机器人或者机械臂？

答案是：完全可以，而且这正是目前 具身智能（Embodied AI） 领域。

传统的机器人控制需要复杂的数学公式去计算机械臂关节的角度、力矩和笛卡尔坐标。但如果我们把机械臂的动作也当成一种“语言”呢？

在最前沿的具身智能工程实践中，工程师们做了一件非常激进的事：他们把机器人的各种动作，比如“手爪张开”、“手爪闭合”、“向左移动5厘米”，全部编成了词表里的特殊编码（通常称为 Action Tokens）。

当你对一个连着机械臂的大模型输入：【帮我把桌子上的红色方块抓起来】。

1. 大模型通过摄像头（视觉 Token）看清了桌面的布局。
2. 它在底层脑子里开始疯狂续写，但这次它续写的不是中文“我去抓了”，而是续写出了一串只有机械臂能听懂的特殊符号：<ROBOT_MOVE_X_0.05> <ROBOT_MOVE_Y_-0.02> <ROBOT_GRIPPER_CLOSE>。
3. 机器人的底层控制器（如 ROS 2 系统）拦截到了这串续写出来的暗号，将其转化为电流和脉冲，直接驱动 Franka 机械臂的电机运转，准确地抓起了那个红色方块。

这就把原本枯燥的机械控制问题，降维打击成了一个纯粹的、跨模态的“高级文字接龙”游戏。

但天下没有免费的午餐，这种强行把万物都变成 Token 塞给大模型的做法，带来了极其沉重的工程代价：

• 上下文的“吞噬黑洞”： 文字是非常高效的压缩符号，一个“猫”字只占 1 个 Token。但在视觉多模态里，为了让模型看清一张高清图的细节，哪怕经过了切片压缩，一张图往往也要占用 500 到 2000 个 Token！这意味着你随便传几张项目截图，大模型的物理视力天花板（Context Window）瞬间就被图片填满了，留给它思考和多轮对话的空间被严重挤压。
• 对齐的“丝滑度”限制： 视觉翻译官和语言大模型毕竟是两个不同时期训练出来的独立个体。它们之间的数学映射如果不够精准，就会出现“视而不见”的盲区。例如，模型明明看到了图中有个负号 -，但因为那个小方块太不起眼，翻译成坐标后被大模型在推理时忽略了，导致算出的代码差之千里。

为了解决这些视觉和物理控制上的翻车事故，工业界目前正从早期的“拼装多模态（各自独立训练再强行拼接）”全面走向“原生多模态（从预训练第一天起，就让模型同时吃文字、图片和动作数据）”。

关键技术细节：

• Vision Transformer (ViT)： 视觉多模态的标配前置网络，负责把连贯的图像像素切碎并转化为高维度的向量矩阵。
• Linear Projector / Perceiver Resampler（对齐投影层）： 负责在图像向量和文本向量之间架起桥梁的“翻译官”，它的参数专门用来让两边的数字能够互相理解。
• VLA Model (Vision-Language-Action，视觉-语言-动作模型)： 具身智能的终极大脑，不仅能看图说话，还能直接将视觉输入续写为机器人的运动控制指令（Action Sequence）。

在前面的章节里，我们已经学会了让大模型当牛马可以执行各种简单任务。

这时候如果让你去写一个企业级系统，你会发现光是写“胶水代码”去把这些零件粘起来，就能把你累死。这时候，大模型工程界演进出了专门的“拼装流水线框架”。

最早出现的庞然大物是 LangChain。它的核心思想是：把大模型应用开发的常见套路，封装成标准的“乐高积木”。 它把不同厂家的 API 封装成统一的壳子，把 RAG 的步骤做成一条自动化的传送带。在早期，它确实让初学者用几行代码就能拼出一个聊天机器人。

但当人们把 LangChain 带入严肃的生产环境时，噩梦开始了：

• 恐怖的过度封装： 简单的 HTTP 文本请求，LangChain 在内部包了十几层抽象。打印一个原始返回码，都得去翻几天源码。
• 松散的字符串地狱： 积木与积木之间的数据流转全靠隐式的字典（Dict）和纯字符串。大模型只要因为概率问题，在 JSON 数组里少吐了一个逗号，整个系统就会在运行时（Runtime）诡异崩溃，你连哪行代码报错的都找不到。如果你写过Java或者JS代码，想象一下，所有的参数都Map结构是什么感觉？

PydanticAI 诞生了。它借鉴了现代后端开发（如 FastAPI）的设计哲学，提出了两件对抗大模型不可控性的武器：

1. 类型安全（Type Safety）： 程序员用代码死死定义好输出的结构体（例如：用户ID必须是整数，风险级别必须是固定的枚举）。大模型如果吐错了，框架在后台拦截到校验错误后，不会报错崩溃。
2. 依赖注入（Dependency Injection）： 彻底消灭了全局变量。每个用户的请求进来，都会被分发一个独立的、隔离的“外部资源工具包”（比如专属的数据库连接），彻底解决了高并发时数据串串的 Bug。

大模型是个无状态的文字续写机器。我们在之前聊过，多轮对话靠的是后台疯狂堆叠“历史账本”。但如果用户跟 AI 聊了三天三夜，或者下个月再次登录，这个账本不仅会把大模型的上下文撑爆，还会让算力资费高到破产。

为了让 Agent 拥有类似人类的长久记忆，工程上为它加装了一个分层的“常驻背包”：

• 短期记忆（流水账）： 记录当前会话最近的几轮对话。这部分依然放在内存或 Redis 里，采用滑动窗口机制，只保留最新鲜的内容，老的内容会被定期用大模型“提炼成一句摘要”保存。
• 长期记忆（日记本）： 当一天的对话结束，后台会有一个异步的“反思任务”，把流水账里重要的事实（比如：用户说他喜欢喝黑咖啡、家里有个两岁的娃）提取出来，变成一个一个小碎片，存进向量数据库。当三个月后用户再次提到“打算买个玩具”时，系统才会去日记本里把“娃两岁”的碎片捞出来塞进上下文。

更高级的记忆是实体关系图谱。AI 随着和你的沟通，会在背包里偷偷画一张关于你的网络：[用户] -- 喜欢 --> [黑咖啡]，[用户] -- 职业 --> [软件开发]。

这种记忆不再是零散的文本片段，而是结构化的状态，让大模型每次面对你时，都像是一个老朋友。

我们给大模型装上了“手和脚”（Tool Call），让它能查天气、改文件。但想象一下，在一家大型企业里，内部有上千个微服务 API（查财务、批假条、搜员工、改权限……）。

如果我们把这上千个工具的“说明书”在每次对话前全部一股脑塞给大模型，会发生两件事：第一，上下文直接爆量，越聊越贵；第二，大模型面对上千个选择会彻底深度失智，开始胡乱调用。

于是，动态技能系统（Skills） 应运而生。它把工具的使用变成了“两阶段检索”：

1. 技能包封装： 工程师把相似的工具组合成一个个高度解耦、即插即用的“技能包（Skills Bundles）”。
2. 按需凭证检索： 当用户输入“帮我把上个月的差旅费报销了”，系统的“翻书员”抢在前面，先去技能库里用向量检索，只抓取和“财务、报销”相关的 3 个工具说明书。
3. 动态喂食： 大模型在本次交互中，只能看到这 3 个工具。这就把“上千选一”的难题，降维成“三选一”的单选题，不仅省下了巨额的 Token 成本，还让 Agent 调用的准确率暴增。

非常抱歉，这次我彻底明白了！之前的写法又滑向了那种“教科书式”的呆板对比，缺少了前几章那种带着一点技术老油条式的幽默、紧贴现实硬件痛点、以及用纯白话场景带入的“大白话费曼风格”。

我们现在把摆拍的架子放下来。第 14 章的真正风格，应该像一个刚从机房维护完服务器回来的师兄，坐在你旁边喝着可乐，用最接地气的现实账本、显卡显存、以及一个具体的“开发翻车故事”，来把模型底层的 MoE 和上层写代码的 Multi-Agent 给讲得清清楚楚。

以下是严格按照前十章的篇幅、语气、大白话和深度重新编写的第 14 章：

当我们用 PydanticAI 卡好了规范，用 Memory 给了它记忆，用 Skills 给了它无限的技能后，这个 Agent（单体牛马）在理论上变得无所不能。

这时候，我们有一个极其宏大的想法：我是不是可以打造一个全知全能的“超级单体 Agent”？我把企业里所有的规章制度、客服话术、Python 编程规范、财务报销流程全部写进它的提示词里，让它一个人包揽公司所有的脏活累活。

在工程实践中，如果你真的这么做了，大模型会用现实给你一记极其响亮的耳光。随着你往这个单体 Agent 里塞入越来越多的提示词（Prompt）和成百上千个工具，它很快就会陷入“深度失智”——不仅回复速度越来越慢，而且经常发生身份认知的“精神分裂”。

要解决这种“全能导致的平庸”，在大模型的世界里有两次彻底的解耦。一次发生在大模型内部（模型的物理结构演进），另一次发生在我们的业务代码里（应用层的社会学拆分）。这两者经常被混淆，但对初学者来说，分清它们至关重要。

首先，我们必须扒开大模型的物理外壳，看看它底层的硬件和算力是怎么被榨干的。在目前的市面上，大模型的底层结构主要分为两大派系。

早期的经典模型（如早期的 Llama 系列、或者各种几百亿参数的小单体）几乎都是“稠密模型”。

• 大白话原理： 假设这个模型有 720 亿参数（72B）。当用户输入一个极其简单的“你好”，或者问一个“1+1等于几”的弱智问题时，模型内部的 720 亿个参数全部都会被瞬间激活，每一个参数都要在显卡里疯狂走一遍矩阵乘法。
• 硬件的绝望： 这就像一个公司里养了 720 个全能天才。不管是去扫厕所、复印文件，还是去推导量子力学，每次出任务，720 个人必须全员整整齐齐地到场一起思考。在现实中，这意味着哪怕你买了两张最顶级的 NVIDIA RTX 5090 D 显卡（加起来 64GB 显存），面对这种全量计算的稠密大模型，它的蹦字速度（Token 吞吐量）也会因为显卡计算单元（Tensor Cores）全线被占满而变得像老牛拉破车一样慢。而且，算力资费贵到让人想报警。

为了打破稠密模型的物理极限，如今市面上最火爆的顶尖大模型（比如大名鼎鼎的 DeepSeek-V4 或者是 GPT-5 系列）几乎全部转向了 MoE 架构。

• 大白话原理： 模型的总参数量可能高得吓人，比如号称有 6710 亿参数。但是它在内部玩了个花招——它把这几千亿参数划分成了几十个甚至上百个小型的“微观专家（Experts）”（有的擅长算术，有的擅长语法，有的擅长代码）。在这些专家前面，挡着一个极其敏锐的门控网络（Router）。
• 现实的算力账本： 当你输入一句代码问题时，门控网络（Router）扫了一眼，瞬间识别出意图，它在内部只激活“代码专家”和“逻辑专家”，这次计算实际上只动用了 6710 亿参数里的 370 亿个（这就叫激活参数量）。剩下的几千亿参数全部在显卡里“闭眼睡觉”。
• 现状与限制： 这种架构带来了 2026 年大模型时代的算力奇迹——它的智商拥有几千亿参数的深度，但每次蹦字的速度和成本，却便宜、快速得像一个 30B 的小模型。但聪明的你马上会发现它的硬件痛点：MoE 模型虽然每次计算只用一小部分参数，但为了随时待命，几千亿个参数必须完整地躺在显存里！这就对 NVIDIA 显卡提出了极度变态的“显存容量”要求。在机房里，你可能需要整整 8 张 H100 PCIe 显卡做高性能高吞吐集群，才能勉强把一个完整的 MoE 模型塞进去不至于爆显存。

听完上面的硬件现状，你可能会想：“既然像 DeepSeek 这样的 MoE 模型已经这么聪明又便宜了，那我把公司的全套业务逻辑都写进提示词里，让它一个人干，应该没问题了吧？”

对不起，依然会翻车。 因为模型底层的 MoE 只能解决“文字接龙速度快不快、省不省算力”，它解决不了人类在编写复杂业务系统时发生的逻辑混乱。

假设你想做个“全自动研发报销审计助手”，如果你把它做成一个单体 Agent，你得在它的 System Prompt 里写上上万字：

“你既要当一个温柔亲切的客服引导用户上传发票，又要当一个冷酷严谨的代码审计师去看用户的代码有没有安全漏洞，还要当一个抠门的财务去查公司的 MySQL 数据库看看部门预算有没有超支……”

大模型看到这一大坨提示词，它的注意力机制（Attention）会彻底抓瞎。当用户输入：“帮我看看这段登录接口的代码写完没，顺便把上周因为改这个 bug 超支的 5000 块钱报销了。” 这个单体 Agent 会立刻陷入身份认知的精神分裂：它可能会用极其抠门的财务语气去评价你的代码写得没有性价比，或者在查数据库时顺手把代码里的负号当成报销金额给算进去了。这就是“全能导致的失智”。

人类社会面对复杂任务时，从来不靠孤胆英雄，而是靠部门协作。大模型在业务落地时，也必须走向 Multi-Agent（多智能体系统）。它的核心就是：把一个复杂的全能 Agent，彻底拆散成一个由多个专业 AI 组成的“虚拟办公室”。

我们用上面那个翻车案例，来看看现代多智能体系统（比如基于 LangGraph 或 PydanticAI Graph 搭建的系统）是怎么在后台丝滑流转的：

1. 前台路由（Application Router）： 它是办公室的行政前台。它不具备任何硬核的专业技能，它的系统提示词极度简单：“你只负责看清用户的需求，然后把任务拆解分发出去。”它看到用户的复合请求后，啪啪两下，拆成了两份工单。
2. 安全审计员（Agent A）： 前台把第一份工单甩给了座位 A 的安全审计员。这个 Agent 的提示词极其纯粹：“你是一个严苛的代码安全专家。”它随身只携带一个 Skills 工具——读取本地代码文件。它用百分之百的注意力盯着代码，迅速吐出了严谨的安全审计报告。
3. 财务会计（Agent B）： 前台把第二份工单甩给了座位 B 的财务会计。它的提示词是：“你是一个精明的财务。”它随身不看任何代码，只携带一个高级的依赖包（Dependency Injection）——公司财务数据库的只读连接。它啪啪啪去数据库里查了一下上周研发部的流水，得出了超支的精确数字。
4. 合流与交付（State Machine Merge）： 两个专家在各自的单向轨道（状态机）里干完活后，把各自标准的、类型安全的 Pydantic 报告扔回给前台。前台主管把“代码安全”和“超支金额”规规矩矩地组合在一起，整整齐齐地呈现给用户。

在这个应用层拆分的过程中，大模型不需要在同一个上下文里既要扮演判官又要扮演财神。每个子 Agent 的 Prompt 都极其干净，随身带的工具技能（Skills）也只有两三个，工具调用的准确率直接从单体的 40% 飙升到了 95% 以上。