和LLM打交道，你得先弄明白这些词

刚开始接触大模型那会儿，我被各种术语轰炸得够呛。Prompt、Context、RAG、Agent…每个词看起来都认识，但放在一起就懵了。后来在项目里摸爬滚打了一阵，才慢慢理清这些概念之间的关系。

今天想用最直白的方式，把这些基础概念串一遍。不管你是刚入门，还是已经在用LLM做产品，希望这篇文章能帮你建立一个清晰的知识框架。

LLM：那个读了全世界书但没出过门的毕业生

LLM（大语言模型），说人话就是一个用海量文本训练出来的“超级大脑”。ChatGPT、文心一言、通义千问，都是LLM的具体实现。

我习惯把它想象成一个读了全世界所有书、文章和网页的超级大学毕业生。他知识渊博，能说会道，上知天文下知地理。但他有个致命弱点——没有任何亲身经历，也无法接触实时世界。

他知道“雨”是什么，但不知道现在外面有没有下雨。他知道“点餐”的完整流程，但他没法自己去厨房做饭，也没法打电话订外卖。

理解这一点特别重要，因为后面要讲的Prompt、RAG、Tool Calling这些东西，本质上都是在帮这个毕业生“补上”他缺失的能力。

LLM到底是怎么工作的？

LLM的核心能力其实就一件事：根据已经出现的文字，预测下一个最可能出现的文字。不断重复这个过程，就拼成了一整段回答。

训练阶段，它用互联网、书籍、代码这些海量文本，学会了“在这种上下文里，下一个词通常是什么”。它不是在背标准答案库，而是在学习语言的统计规律和模式。

使用阶段，你把Prompt喂给它，它从第一个字开始往后“接龙”，直到写完或者触发停止条件。所以从本质上说，LLM是一个极其强大的文本续写和模式匹配工具，而不是真的“理解世界”或者“拥有意识”。

那复杂的推理能力、实时的事实查询是怎么来的？靠的就是Prompt技巧、RAG、Tools这些“外挂”——这些我们后面会讲到。

Token：计费的最小单位

Token是模型读写文本的最小处理单位，不等同于一个汉字或一个英文单词。

英文里，一个词差不多就是一个Token。中文复杂一些，一个字可能对应1到2个Token，取决于分词方式。你发的Prompt、模型返回的答案、工具调用塞进上下文的内容，都会换算成Token数量。

API按Token计费。上下文能装多少东西，也是用Token上限来衡量的。我习惯把Token想成稿纸上的“字数块”：稿纸总格数是有限的（上下文窗口），写太长了就得删掉一些；写得越多，出版社（云厂商）收的钱也越多。

上下文窗口：LLM的“工作记忆”上限

上下文窗口（Context Window）指的是单次请求里，模型能同时“看进去”的最大Token总量。

窗口越大，能带的对话历史、系统说明、RAG检索出来的资料就越多。但窗口不是无限的，满了就得截断最旧的内容，或者做摘要压缩。这是LLM的硬限制，不是软件想记多少就能记多少。

很多人刚用时会有个误解，觉得模型“记得”之前聊过什么。其实每次请求，你都得把历史对话重新塞回去。窗口就像毕业生的“临时工作台”，台面就那么大，资料摞太厚就得撤掉一些。

Temperature：控制“胡说”的程度

Temperature（温度）控制模型生成时的随机性和创造性，一般在0到2之间。

低温（比如0到0.3）意味着输出更确定、更保守。同样的问法问多次，答案都差不多。适合写代码、生成JSON、做事实问答。

高温（比如0.8到1.2）意味着更发散、更有创意，但也更容易跑偏。适合头脑风暴、写文案。

如果把Temperature设为0（如果模型支持的话），基本上就是每次都选概率最高的下一个词，输出最稳定。我的理解是：低温像严考官，只让写标准答案；高温像鼓励你多角度发挥，但可能跑题。

推理模型 vs 非推理模型：会不会“多想几步”

这是按模型的行为习惯分的，不是说它们是两种完全不同的东西。

非推理模型（比如GPT-4o、Claude Sonnet的常规版本）收到问题后，一般直接生成答案。它们也能推理，但更依赖你在Prompt里写“请一步步思考”。

推理模型（比如OpenAI的o系列、DeepSeek-R1、带extended thinking的型号）则会在内部先展开多步推理，有时候你还能看到它的“思考过程”，然后再给出结论。数学题、复杂逻辑、多步规划这类任务，推理模型明显更强。

代价也很直观：推理模型更慢、更贵，思考过程本身也会消耗Token。所以我现在选模型的习惯是：日常聊天、翻译、简单抽取用常规模型，又快又省；遇到难题、需要多步拆解的时候，再上推理模型。

流式输出：边想边说

流式输出（Streaming）指的是模型生成一个字就立刻推给你一个字，而不是等整篇回答写完了再一次性返回。

体验上就是ChatGPT里那种字一个个蹦出来的感觉。技术上一般用SSE（Server-Sent Events）或者类似的流式HTTP协议，前端边收边渲染。

这个功能适合长回答、聊天场景。但如果你需要严格的JSON输出，流式就不太友好，除非你配合流式解析工具，或者等收完了再做校验。还是用那个比喻：毕业生边想边说，你不需要等整篇演讲稿打印完才能听到第一句。

Completion vs Chat Completion：两种接口形态

这是调用LLM API时的两种常见模式，名字来自OpenAI，但其他厂商基本都有类似概念。

Completion（文本补全），是你给一段没写完的文本，模型接着往下写。这是早期GPT-3的风格，比如你给“请用三句话介绍北京：”，模型就续写后面的内容。没有结构化的角色概念，全靠你拼进这一段Prompt里。

Chat Completion（对话补全），是你给一组带角色的消息列表（system/user/assistant），模型在对话语境下生成下一条助手消息。现在的聊天产品、Agent框架，几乎都用这一种。好处是可以分开写系统人设、用户问题、历史对话轮次，也方便Tool Calling把工具返回结果塞进对应的消息角色里。

在实际项目里，Completion已经比较少单独使用了，Chat Completion是绝对的主流。你用Mastra这类框架时，agent.generate()或stream()这些方法，底层都是在调Chat Completion接口，只是帮你做了封装。

---

以上这些是理解和使用LLM最基础的概念。后面要讲的Prompt怎么写、Context怎么管、Agent怎么设计，都建立在这些底层机制之上。理解了这些，就拿到了和这个“超级毕业生”打交道的说明书。

下一篇我们接着聊Prompt。