深入了解大语言模型，例如 ChatGPT

引言

最近随着龙虾 OpenClaw 越来越火，大家对 Agent 的讨论也明显多了起来。不过我也发现，很多同学虽然天天听到 Agent 这个词，但对它到底是什么、为什么能工作，其实还没有形成一个比较清晰的认识。

前几天我和产品同学吃饭的时候，也聊到了很多 Agent 相关的问题。聊完之后我就觉得，这件事值得专门整理一下。因为只有先把底层的东西想明白，我们后面在工作里用 Agent，才不容易停留在“会用一点点”的层面。

如果让我用一个很粗暴但很好记的公式来概括，Agent 大概可以理解成：

Agent = Prompt + LLM + Tools

这会是一组系列文章。第一篇我只想先把 Agent 的核心，也就是 LLM 讲清楚，先不展开 Prompt 和 Tools。因为如果连 LLM 这层都没有建立起稳定认知，后面再看 OpenClaw 这类 Agent 产品时，就很容易只看到“它很好用”，但看不清它为什么能工作。

这一篇我会按 4 个部分来讲：先讲 LLM 是什么，再讲它是怎么训练出来的，然后讲它在技术上是怎么工作的，最后再落到工程世界里，看看一个模型到底是以什么形态存在的。

LLM 是什么

我觉得，想真正理解 LLM，第一步不是去背各种名词，而是先打破一个错觉：我们并不是在和一个有感知、有意识、什么都懂的“神谕”对话。

如果我要用一个不那么浪漫、但更接近现实的说法，我会说：LLM 本质上是一个基于统计规律的 Token 生成器。你也可以把它理解成，一个极其复杂的文本补全系统，或者说，一个对互联网文本和人类对话模式进行压缩和模拟的系统。

所谓基础模型（Base Model），其实就是预训练之后得到的模型。在这个阶段，模型会接触极其海量的文本数据，把语言中的统计规律“压”进参数里。

所以从工作机制上看，它不是一个拥有“自我意识”的实体，而是在给定上下文之后，去预测下一段最可能出现的内容。

LLM 是怎么训练出来的

1. 预训练阶段（Pre-training）：构建“互联网模拟器”

   我一般会把预训练理解成“打地基”的阶段。这通常是整个流程里计算量最大、耗时最长的部分，目标是让模型从海量文本中学习语言模式、世界知识和常见表达。

   数据作为原材料：开发者会从互联网等来源收集海量文本，然后经过过滤、清洗、去重、语言筛选以及隐私处理，尽量得到质量更高的训练语料。

   技术本质：这一阶段产出的基础模型，可以理解为“互联网文本词元模拟器”。它通过预测下一个词元（Next Token Prediction）来学习。从直觉上看，这有点像把大量互联网知识做成一种有损压缩，压进模型参数里。

   局限性：基础模型虽然可能已经“知道很多东西”，但它未必天然擅长以“助手”的方式稳定回答问题。很多时候，它更像是在按训练分布做续写，而不是像我们期待的那样，直接给出清晰、稳健、符合指令的答复。

2. 有监督微调阶段（SFT）：从工具到“助手”

   到了这一步，我会把它理解成：开始把“一个会续写文本的模型”，训练成“一个更像助手的模型”。

   训练逻辑：开发者不再只给它看原始互联网文本，而是会加入由人类标注员（Labelers）编写或整理的高质量对话数据。

   模仿学习：标注员通常会按照明确的规范，写出理想的助手回复。模型通过训练，学习模仿这些高质量回答的风格、结构和行为方式。

   效率对比：和预训练相比，SFT 的数据规模通常会小很多，训练成本也一般低得多。但具体要花多少时间，并没有一个固定答案，它会受到模型规模、数据量、硬件条件和训练策略的影响。

   如果从“心理模型”的角度去理解，我会说：这个阶段之后的模型，开始更像是在统计意义上模仿“一个合格助手应该怎么回答”。

3. 强化学习阶段（RL）：推理能力的进阶

   这一步可以理解成：模型不只是继续模仿人类，而是开始通过“试错”和“奖励”去优化自己的行为。

   可验证领域（Math / Code）：在有明确答案的领域，比如数学和代码，模型可以生成很多条解题路径（Rollouts），然后根据结果是否正确来获得奖励。这样的训练，往往会强化模型的长链路推理、自我纠错和回溯能力。

   不可验证领域（RLHF）：对于写诗、讲笑话或者开放式表达这类没有唯一标准答案的任务，常见做法是用人类反馈强化学习（RLHF）。它会训练一个奖励模型（Reward Model）来近似模拟人类偏好，再用这个偏好去引导模型输出更符合预期的内容。

   这里也要注意，RLHF 并不是万能的。因为奖励模型本身也有偏差，甚至可能被模型“钻空子”。所以它当然有上限。但在数学、代码这类可验证任务上，强化学习确实有机会让模型学到一些很有效、甚至不完全像人类直觉的策略。

如果类比成我们上学的过程，我会这样理解：

• 预训练：相当于阅读所有教科书中的背景知识（Exposition），建立世界观。
• 有监督微调：相当于学习教科书中的例题及其专家解答（Worked Solutions），学习表达格式。
• 强化学习：相当于独立完成课后练习题（Practice Problems），通过不断试错和对答案，真正掌握解决问题的思考逻辑。

LLM 技术原理

1. 核心任务：预测下一个词元

   如果只看最底层，LLM 做的事情其实很朴素：给定一个词元序列作为上下文，然后预测下一个最可能出现的词元。

   统计概率引擎：模型本质上是在做概率分布计算。它会对词表里的大量候选词元打分，再通过采样策略决定接下来输出什么。

   推理即补全：我们平时调用模型时，它处于“推理（Inference）”阶段。这个阶段模型参数通常是固定的，它不是在边聊边重新训练自己，而是在已有参数基础上做条件补全。

   这里我只补三个最常见的推理参数：TopK、TopP 和 Temperature。它们不改变模型“知道什么”，更像是在控制模型回答时到底保守一点，还是发散一点。

   你可以这样粗略理解：TopK 决定候选池有多大，TopP 决定保留多大一块高概率候选，Temperature 决定模型敢不敢去选那些不那么主流、但可能更有变化的词。

   所以一般来说，参数收得更紧，回答会更稳、更像标准答案；参数放得更开，回答会更多变，也更容易发散。

   不过这里最重要的提醒还是一句话：这些参数调得更“活”，并不等于模型真的更聪明了。很多时候，它只是更敢说，但不一定更对。

2. 数据表示：词元化（Tokenization）

   计算机并不能直接“看懂”自然语言，所以第一步必须先把文本转成数字序列。

   BPE 算法：常见做法是使用字节对编码（BPE）这类分词方法，把常见字符组合切成词元，并映射成唯一的 ID。不同模型的词表规模不一样，但通常都是很大的一个离散集合。

   副作用：词元化意味着模型并不是像人一样逐个字符地看文字。所以它在处理拼写、字符计数，比如 strawberry 里到底有几个 r，或者做字符串反转时，往往没有大家想象中那么稳。

3. 架构基础：Transformer 与参数

   数学表达式：模型内部本质上是一个非常巨大的数学函数，由海量参数，也就是权重构成。你可以把它想成一堆被精细调过的旋钮，这些旋钮共同决定了最终输出。

   无状态性：这里我会尽量说得准确一点。模型通常没有跨请求的持久记忆，也没有真正意义上的“长期自我”。每次调用时，它主要依赖当前输入的上下文来完成这次计算。

4. 怎么看模型规格：这些参数到底在说什么

   我觉得很多人第一次看模型说明时，最容易被一堆参数绕晕。比如有人会看到这样的描述：context window = 272k、reasoning effort = medium、参数规模 = 1000B。我的建议是，不要把它们当成“越大越好”的排行榜，而是把它们翻译成三个问题：这个模型一次能看多少内容、愿意为这次回答花多少推理预算、以及它底层大概有多大的容量。

   Context Window：这个参数描述的是模型单次请求里最多能处理多少上下文，也就是它一次能“看到”多少 Token。比如 272k context window，意思可以近似理解成它一次能处理非常长的文档、长代码、长对话历史或者多轮工具调用轨迹。这个指标越大，越适合长文总结、代码库分析、复杂 Agent 任务这类需要“大工作记忆”的场景。但它也不等于模型一定更聪明，因为“能看得下”不等于“看得准、抓得住重点”，而且上下文越长，延迟和成本通常也会更高。

   Reasoning Effort：这个参数更像是推理时愿意投入多少“思考预算”。如果一个模型支持 low / medium / high 这类档位，那它通常不是在说模型换了一个大脑，而是在说同一个模型或同一类模型，在回答前愿意走多深的推理过程。像 medium reasoning effort，我会把它理解成一个折中档位：比追求极速响应更认真，但又没有把延迟和成本拉到很高。它比较适合一般分析、复杂问答、普通代码任务。更高的 reasoning effort 往往更适合数学、规划、难代码题和多约束推理；更低的 reasoning effort 则更适合分类、抽取、改写、翻译这类不需要太多“长思考”的任务。

   参数规模（Parameters）：比如 1000B，意思就是大约一万亿级别的参数量。参数可以粗略理解成模型内部可学习的“旋钮”数量，它反映了模型承载模式和知识压缩的容量上限。一般来说，参数规模更大的模型，往往有机会具备更强的表达能力、知识容量和泛化能力，但这里我一定会提醒一句：参数量不是唯一指标，甚至很多时候不是最该看的指标。因为真正决定体验的，除了参数量，还有训练数据质量、架构设计、后训练方式、工具调用能力，以及推理时到底激活了多少参数。尤其在 MoE（Mixture of Experts）架构里，标称总参数可能非常大，但单次推理真正激活的参数只是其中一部分，所以“总参数很多”不等于“每次都全力出手”。

   如果把这三个参数翻译成选型建议，我自己的经验是这样的：当任务是长文档、长代码、复杂多轮流程时，我会优先看 context window；当任务是数学、规划、代码推理、多步骤决策时，我会优先看 reasoning effort 或模型是否擅长推理；当任务是在两个模型族之间做长期能力判断时，我才会把“参数规模”当成一个参考信号，但绝不会只看它。对大多数实际业务来说，选模型最靠谱的方法不是盯着一个数字，而是同时看任务类型、延迟、成本、上下文长度、推理深度这几个维度。

5. 训练的三大支柱阶段

   如果把整个训练过程压缩来看，我觉得可以抓住三个核心阶段：

   预训练（Pre-training）：在海量文本上训练，把语言和知识中的统计规律压缩进参数中，形成基础模型（Base Model）。

   有监督微调（SFT）：通过高质量对话数据，把模型从“会续写文本”拉向“更像助手回答问题”。

   强化学习（RL）：通过试错（Trial and Error）和奖励机制，进一步优化模型在推理、对齐和任务完成上的表现。

6. 计算限制：用“词元”换取“思考”

   我很喜欢一句工程上常说的话，叫“模型需要词元来思考（Models need tokens to think）”。这更像是一种经验性总结，而不是字面意义上的认知理论，但它确实很有解释力。

   固定算力：模型在生成每一个词元时，愿意花掉的计算资源通常是有限的。

   分布式推理：这也意味着，面对复杂问题时，模型往往需要通过更长的中间步骤，把计算压力摊开。如果你一上来就要求它“不要解释，直接给答案”，有些问题上它反而更容易出错。

7. 认知边界：瑞士奶酪模型

   我觉得还有一个很形象的比喻，叫瑞士奶酪模型。它的意思是，LLM 的能力不是一块完整平滑的平面，而是到处有洞。

   也就是说，它可能在某些点上非常强，强到让人震惊；但在另一些看起来很基础的问题上，又可能突然翻车。这说明它很多时候仍然是在依赖统计模式，而不是像我们想象的那样，稳定地掌握了一套统一而严密的逻辑体系。

LLM 心理学和局限性

1. LLM 的核心“人格”：无状态的统计模拟器

   没有持久的自我：如果我要给 LLM 一个尽量去魅化的定义，我会说它不是一个“人”，而更像一个词元生成器（Token Tumbler）。它没有持久的自我意识，也没有稳定延续的内在主体。

   模拟标注员行为：从某种角度看，我们和它对话，其实是在和一个“被训练成像助手一样说话的统计系统”对话。它会模仿训练数据里那些高质量回答者的语气、格式和行为模式。

   思维链的涌现：在一些经过强化学习或专门推理优化的模型里，我们会看到它表现出类似“内心独白”的现象，比如“等等，这里不对，我再想一下”。我更愿意把它理解成一种为了提高准确率而形成的外显推理行为，而不是字面意义上的人类意识活动。

2. 记忆的心理结构：参数 vs. 上下文

   我觉得理解 LLM 的时候，一个特别有帮助的类比是：它其实有两种很不一样的“记忆”。

   参数知识（内部记忆） = 模糊回忆：存储在模型权重中的知识，有点像人类很久之前看过一篇文章之后留下的模糊印象。对于冷门、罕见或者边缘事实，这种记忆往往是不稳定的。

   上下文窗口（外部记忆） = 工作记忆：你直接放进对话里的内容，更像它当前这一次任务的工作记忆。只要窗口里还在，它就能更直接地依赖这些信息来回答。

   局限性：因为参数里的知识本质上是压缩过的，所以当它遇到过时信息、冷门知识，或者训练之后才发生的新事实时，就很可能只能根据统计模式去猜。这也是幻觉的重要来源之一。

3. 计算的“物理”局限：模型需要词元来思考

   固定算力瓶颈：模型在每一步生成时能使用的算力不是无限的，所以它并不能在一个瞬间完成所有复杂推理。

   分布式推理：很多复杂问题，本来就需要一步一步拆开。如果不给它这个展开过程，而是逼它“立刻给最终答案”，它就更容易在中间偷步，最后答错。

4. “瑞士奶酪”模型：不稳定的能力边界

   瑞士奶酪式的不稳定：这也是为什么我们经常会觉得模型“有时候聪明得离谱，有时候又蠢得离谱”。

   词元化的视觉盲区：因为模型看到的不是单个字母，而是词元块，所以它在拼写、字符计数，比如 strawberry 里有几个 r，或者字符串反转等任务上，天然就比较脆弱。

   统计规律的干扰：模型有时会显得“很笨”，并不一定是因为它完全不会，而是因为训练里形成的统计模式会在某些场景里干扰它的判断。

   自信的幻觉：另一个问题是，它很容易学会一种“像是在认真回答”的风格。如果拒答能力或校准能力不够，即使不知道答案，它也可能编出一个听起来很像真的东西。

5. 应对局限性的实战建议

   不要考验记忆：如果任务要求高准确度，我的建议是，能给资料就给资料，不要让模型纯靠“回忆”。

   利用工具补偿：遇到计数、复杂算术、检索或者拼写这类任务时，优先让模型调用 Python、搜索、数据库或者其他工具，而不是依赖它脆弱的“脑补能力”。

   视为工具而非神谕：我一直觉得，正确的心态不是“相信模型”，而是“用好模型”。它非常适合当灵感来源、草稿生成器、助手和放大器，但不适合被当成无需验证的真理机器。

LLM 未来趋势

这一节我不展开太多，只给一个简短判断：未来的 LLM，大概率会继续沿着 3 个方向往前走。

1. 更强的多模态能力

   模型不会只停留在文本上，而会越来越自然地处理音频、图像，甚至视频，让“听、说、看、生成”逐渐统一起来。

2. 更完整的 Agent 能力

   模型的角色会继续从“回答问题”走向“执行任务”。也就是说，它不只是给出答案，还会把多个步骤串起来，调用工具，完成更长的工作流。

3. 更普及，也更本地化

   一方面，AI 会越来越深地嵌进各种产品和工作流里；另一方面，随着蒸馏、量化和开放权重模型的发展，越来越多能力不错的模型也会更适合在本地设备上运行。

如果把这一节和前面连起来看，我觉得未来趋势其实就一句话：模型会越来越强、越来越像基础设施，也越来越像 Agent 的底座。

LLM 实战：用 Ollama 在本地跑一个模型

如果前面讲的内容还比较抽象，那我很建议大家真的在自己电脑上跑一次本地模型。因为一旦你把模型拉到本地，再通过命令行、Web UI 和 API 去调它，你对“模型到底是什么”这件事会一下子具体很多。

1. 先建立一个直觉：模型的“实体”到底是什么

很多人第一次接触 LLM，会下意识把它想成一个悬浮在云上的智能体。但如果我们用本地部署的方式去看，它其实会变得非常具体：

• 一份或多份模型权重文件
• 一个负责加载模型、管理显存/内存、执行推理的运行时
• 一个对外暴露接口的本地服务进程

换句话说，当我们说“我本地跑了一个模型”，本质上通常是在说：我的机器上有一套模型文件，Ollama 这样的运行时把它加载起来，然后在 localhost 上提供一个 HTTP 服务，别的程序再通过这个服务来调用它。

所以从工程视角看，模型并不神秘。它既不是一个会飘来飘去的抽象概念，也不只是一个聊天窗口，而更像是一个可以被拉取、加载、调用、停止、替换的本地推理服务。

2. 安装 Ollama 并拉起一个本地模型

如果我的分享对象是大多数普通同学，那我其实不会先讲 Linux 命令行，而会直接从 Windows 安装开始。因为这条路径最符合大多数人的真实使用习惯。

最简单的做法就是直接浏览器打开 https://ollama.com/，下载 Windows 安装包，然后一路安装完成。装好之后，Ollama 会以桌面应用和本地后台服务的形式在你的机器上运行。

接下来你可以在应用里选择一个模型，把它下载下来并运行。这个过程背后做的事情，其实就是：

• 把模型文件下载到你的本地磁盘
• 由 Ollama 在本地把模型加载起来
• 再通过桌面界面或者本地 API 去调用它

所以“安装一个本地模型”这件事，第一次做完以后你会发现，它非常像安装一个带大文件依赖的本地软件，只不过这里下载下来的核心资产，不是素材包，而是模型权重。

这里我也想补一句很实用的话：本地模型不是“白送”的。它本质上是在用你的 CPU、内存、GPU、显存换隐私、可控性和离线能力。所以选模型时一定要考虑机器配置，不然很容易出现“模型能拉下来，但跑不动”的情况。

3. 在 Windows 里找到模型文件：看 Model location 和 blobs

如果想把“模型到底是什么”这件事看得更具体，我很建议大家装完 Ollama 以后，不要停留在聊天界面，而是顺手去看一下它到底把模型存到了哪里。

一个很直观的路径就是打开 Ollama 的 Settings，找到 Model location。在我这里，截图里能看到的路径类似于：

C:\Users\<你的用户名>\.ollama\models

点进去之后，你通常会看到几个目录，其中最值得看的就是 blobs 文件夹。

我觉得这一步特别有教育意义。因为当你打开 blobs 之后，你看到的不会是什么“聪明助手头像”，而是一堆看起来像哈希值命名的大文件。它们通常不是给人直接阅读的，而是 Ollama 用来存储模型权重和相关二进制对象的底层文件。

换句话说，blobs 让你非常直观地意识到一件事：模型在工程上首先是文件，而不是“人格”。它是被下载到本地磁盘上的一堆真实二进制数据，然后由运行时加载进内存或显存里参与推理。

如果再往前理解一步，你会发现这件事特别像容器镜像或者包管理系统：

• 对用户来说，我们看到的是友好的模型名字，比如 qwen3:8b
• 对运行时来说，底层实际管理的是一组具体的 blob 对象

这时候还可以顺手再看一下旁边的 manifests 目录。你可以把它粗略理解成“模型标签到具体底层文件的映射关系”。也就是说，像 qwen3:8b 这样的模型名，并不是直接等于某一个单独文件，而更像是一个入口标签；而 manifests 记录的是这个标签对应到哪些底层对象，blobs 则存着这些真正的文件内容。

所以如果让我用一句很适合分享的话来总结，就是：模型名是标签，manifests 是索引，blobs 是实体文件。

我觉得这一步很适合在分享里现场演示，因为它能帮很多人从“AI 很神秘”切换到“原来它就是本地磁盘上的一堆模型文件，再加一个运行时”。

4. Ollama 的原生 API 长什么样

如果你想从“聊天 UI 使用者”再往前走一步，我很建议直接看 API。因为一旦你开始用 API 调模型，你就会更容易把它理解成一个标准的软件服务，而不是一个神秘对话框。

Ollama 的原生接口风格比较直接，常见的是 http://localhost:11434/api/chat。一个最简请求大概长这样：

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [
    { "role": "user", "content": "你好，介绍一下你自己" }
  ]
}'

这个格式其实已经很说明问题了：

• model 指定你想调用哪个本地模型
• messages 是输入对话
• 返回值里会包含模型生成的回复

所以从接口层看，模型已经很像一个普通服务了。你发一个 JSON 请求，它回你一个 JSON 响应。

5. OpenAI 兼容格式

很多现有框架、SDK、应用默认使用的是 OpenAI 的 API 协议。Ollama 的一个实用点就在这里：它提供了 OpenAI 兼容接口，所以很多原本面向 OpenAI 写的代码，只要把 base_url 改到本地，例如 http://localhost:11434/v1/，就可以切过去继续用。

你可以把这件事简单理解成：应用层说的还是 OpenAI 这套“语言”，只是背后真正回答你的，不再是云端模型，而是你本地跑起来的模型。

6. Anthropic 兼容格式

同样地，根据 Ollama 官方文档，它也提供了 Anthropic Messages API 兼容。这意味着一些原本期望 Anthropic 协议的工具，也可以通过改一下地址，连到本地 Ollama。

我觉得这部分最重要的认知，不是记住具体请求长什么样，而是理解一件事：很多时候，应用接入的并不只是“某一家模型厂商”，而是一套协议格式。只要本地运行时兼容这套协议，应用层就可以比较平滑地切过去。

7. 为什么我觉得这一节很重要

我一直觉得，真正理解模型，不只是理解 Transformer、Token、RLHF 这些概念，还要理解它在工程世界里到底是以什么形态存在的。

一旦你真的用 Ollama 跑过一次本地模型，你会发现模型在工程上其实很像这样一套东西：

• 模型权重文件
• 推理运行时
• 本地 HTTP 服务
• 一个或多个上层 UI / SDK / Agent 框架

这时候你再回头看龙虾 OpenClaw，就更容易理解它为什么最终能以一个 Agent 产品的形态呈现在我们面前。你会更清楚地知道：底下有模型，有推理运行时，有协议兼容层，有工具调用能力，也有最后给用户使用的产品界面。

而这篇文章作为这个系列的第一篇，我想先把最底下这一层，也就是 LLM 讲明白。等这一层理解清楚了，后面再继续讲 Prompt、Tools 以及 Agent 本身，整个链路就会顺很多。

总结

如果要把这篇文章最后收成 3 个 takeaway，那我希望大家带走的是这 3 件事：

1. LLM 不是神谕，它本质上是一个基于统计规律做下一个 Token 预测的系统。
2. LLM 的能力来自训练、采样、上下文和推理预算等多种因素共同作用，不能只看一个参数，也不能把它神化。
3. 当我们把 LLM 放回工程世界里去看，它就是模型文件、推理运行时和服务接口的组合；理解了这一层，后面再看 OpenClaw 这样的 Agent 产品，很多问题都会清楚得多。

下一篇我会继续往上走一层，聊 Prompt 和 Tools 为什么会决定一个 Agent 的行为边界，以及为什么同样底层是 LLM，不同 Agent 产品最后的体验会差这么多。

参考资料

• 原视频（3 小时+）：https://youtu.be/7xTGNNLPyMI?list=TLGGF2qs5wlgDR4xMzAzMjAyNg

• Previous
  Feed 流