LLM 基础机制

现在的状态非常典型：

• 已经会用一些 AI 工具；
• 也已经接触 API；
• 甚至已经在工作里和 AI 一起做事；

但这并不等于真的理解模型在做什么。

如果这一层不先补上，后面学 Prompt、Function Calling、Tool Use、Agent 工作流，都会很容易变成“会操作，不会解释”。

所以这篇文章的目标不是教我怎么调用某个接口，而是帮我回答一个更关键的问题：

当我说“我在用大模型”时，我到底在用什么？

一、 LLM

很多人在初学阶段都会自然地产生一种错觉：

• 有了模型，系统就自动“聪明”了；
• 模型能回答问题，所以它也应该能承担决策、执行、状态管理这些工作；
• 只要 Prompt 写好，整体系统就会自然变稳。

这类错觉之所以常见，是因为模型的输出看起来太像“理解”。

LLM 是系统中的一个能力模块，不是整个系统。

1. 模型擅长的是什么

大模型最擅长的，其实是：

• 根据输入上下文预测下一个最可能的 token；
• 在足够多的训练数据支持下，生成结构上合理、语义上看起来连贯的输出；
• 对复杂语言任务进行模式匹配、归纳和重组。

换成更工程化的话说，它像是一个：

强大的语言压缩与展开器。

你给它：

• 问题
• 上下文
• 约束
• 示例
• 工具结果

它会在这些输入之上生成一个“最像合理答案”的输出。

2. 模型不擅长的是什么

它并不天然擅长：

• 长期稳定保存状态；
• 精确记忆很久以前的细节；
• 永远遵守你的格式约束；
• 自动知道何时调用外部工具；
• 为复杂任务自己维持完整的执行链路；
• 保证在每一次请求中都可靠一致。

也就是说：

模型可以提供“智能”，但不能直接替代系统设计。

这就是为什么招聘里会强调：

• 任务拆解
• Tool Use
• 多步骤执行
• 记忆机制
• 状态管理
• 失败兜底
• 稳定性与成本控制

因为一旦你进入真实产品场景，你就会发现：

“让模型答出来” 和 “让产品稳定运行” 是完全不同的两件事。

二、LLM 的最小工作方式：输入、上下文、输出

如果要理解模型，最先要弄清楚的不是框架，而是最基本的工作单元。

1. 输入不是一句问题，而是一整个消息结构

在今天大多数聊天型模型接口里，输入往往不是简单的一句字符串，而是一组消息。

最常见的是：

• system
• user
• assistant

很多人一开始会把它们当成“格式要求”，但其实它们背后代表的是角色分工。

system

负责给模型设定：

• 角色
• 任务边界
• 输出规范
• 价值倾向或行为限制

它更像是：

系统级指令或规则背景。

user

是这次真实提问者提供的信息。

比如：

• 我想让你做什么
• 我关心什么
• 当前场景是什么

assistant

则是历史对话里模型自己之前说过的话。

它的意义不只是“聊天记录”，而是：

把前面的推理和承诺重新放回当前上下文里。

2. 为什么这点重要

因为很多后续问题都源自你有没有意识到：

• 模型看到的不是“你脑海里的意图”
• 模型只看到这次你喂进去的消息结构

这句话听起来简单，但它会直接改变你对很多现象的理解。

比如：

• 为什么模型明明“上一轮答应了”，这一轮又变了；
• 为什么 system prompt 里写了规则，它还是没完全照做；
• 为什么上下文一长，回答开始跑偏。

这些问题本质上都和：

模型到底看到了什么输入

有关。

三、上下文为什么是核心，而不是附属概念

“上下文”这个词很常见，但很容易被讲得过于轻飘。

对工程来说，它其实是最核心的问题之一。

1. 上下文决定模型当前的世界观

模型并不会真正“记住”你之前说过什么。

它只是每次都根据当前传入的上下文重新生成答案。

所以对模型来说：

• 当前窗口里的内容 = 它现在能参考的世界
• 窗口外的内容 = 当前这一轮几乎不存在

这就意味着：

上下文不是辅助信息，而是模型思考的全部边界。

2. 为什么上下文会让回答变好，也会让回答变差

上下文多了，模型确实可能更懂当前任务。

但上下文变多，也会带来几个典型问题：

1）噪声增加

无关信息越多，模型越难判断什么重要。

2）重点被稀释

真正关键的约束可能被埋在一堆历史信息里。

3）成本上升

上下文越长，token 越多，成本和延迟通常都会提高。

4）稳定性下降

当上下文里出现冲突信息，模型可能表现得越来越不一致。

所以在真实系统里：

上下文管理不是“多带一点更保险”，而是“带哪些、丢哪些、什么时候压缩”。

这也是为什么招聘里会把“上下文管理”当成明确能力要求。

四、Token 是什么，为什么它和成本、延迟直接相关

如果不理解 token，就很难真正理解模型为什么贵、为什么慢、为什么会超长。

1. token 不是字，也不是词

token 更像是模型内部处理文本的最小切分单元。

它不完全等于：

• 一个汉字
• 一个英文单词
• 一个标点符号

有时一个词会拆成多个 token；有时多个字符会合成一个 token。

2. 为什么你必须关心 token

因为模型的几个关键现实约束，都和 token 强相关：

1）窗口长度

上下文不是无限的，模型每次能看到的 token 总量是有限的。

2）成本

大多数 API 都是按 token 计费。

3）延迟

token 越多，模型通常处理得越慢。

4）系统设计

如果你把所有历史、规则、知识、工具结果无脑都塞进去，系统会很快变得：

• 贵
• 慢
• 不稳定

所以从工程角度看，token 从来不只是计费单位，它还是：

上下文设计能力的压力测试。

五、为什么模型会“看起来懂”，但其实不稳定

这也是很多人在工作里最容易产生错觉的地方。

1. 模型输出像理解，不等于它真的建立了稳固概念

LLM 之所以让人惊艳，是因为它能给出：

• 连贯的解释
• 看起来像推理的步骤
• 甚至看起来像“理解你真正想要什么”的回答

但工程里必须意识到：

像理解，不等于可依赖。

2. 你在工作里最容易遇到的几类问题

1）格式漂移

你让它输出 JSON，它有时还是会多说一句话。

2）约束失效

你写了“只能输出 3 条”，它有时还是会输出 4 条。

3）上下文污染

前面聊天里的一些历史内容会把当前任务带偏。

4）错误自信

模型可能会一本正经地讲错。

5）重复与空转

在多轮任务里，它可能开始自我重复，或者做无意义延长。

这些现象不是边角问题，而是理解 Agent 的基础。

因为你越早明白“模型天然不稳定”，后面越能理解：

• 为什么需要结构化输出
• 为什么需要工具调用
• 为什么需要状态机或工作流
• 为什么需要失败兜底

六、为什么这篇基础理论会直接连接到 Agent

有人会觉得：

“我不是要学 Agent 吗？为什么先讲这么多 LLM 基础？”

答案很简单：

Agent 不是凭空多出来的一层魔法，它是建立在模型边界之上的系统组织方式。

如果你不知道模型本身有什么问题，就很难理解 Agent 为什么要多出这些组件：

• 规划
• 工具
• 状态
• 记忆
• 工作流
• 重试与回退

也就是说：

• LLM 基础告诉你 模型能做什么 / 不能做什么
• Agent 设计则是在回答 系统应该怎么补上这些缺口

这也是为什么我把这篇放在整个教程序列的第一个理论模块。

七、和岗位要求的关系：这篇文章在 JD 里对应哪一层

这篇内容表面上还没写到“Agent 架构”，但实际上已经对上了招聘里最基础的一层要求：

对应要求 1：LLM 应用开发经验

如果一个人只是会复制调用代码，他只能算“接过 API”。

真正有 LLM 应用开发经验的人，至少会逐步意识到：

• 输入结构很重要
• 上下文选择很重要
• token 很重要
• 输出稳定性不是默认给你的

对应要求 2：Prompt / 上下文管理

这篇其实已经在为这部分打地基：

• Prompt 不是咒语
• 上下文不是越多越好
• 输出边界必须靠设计来约束

对应要求 3：Agent 在真实产品中的问题

比如：

• 延迟
• 稳定性
• 不可控性
• 成本

这些都和模型的基础工作方式直接相关。

所以如果这篇内容真的吃透，后面读 JD 的很多词就不会再只是“熟悉的热词”，而会变成能解释的结构。

八、本篇小练习：不要做项目，先做 3 个小观察

这篇不安排大项目，只安排 3 个最小观察任务。

练习 1：观察消息结构对输出的影响

找一个你常用的模型接口，分别用：

• 只有 user
• system + user
• 多轮 user + assistant 历史

问同一个问题。

记录：

• 输出差异
• 稳定性差异
• 风格差异

练习 2：观察上下文变长后输出是否变乱

把同一个任务放在：

• 短上下文
• 长上下文

两种场景里跑一遍。

观察：

• 模型是否更容易偏题
• 是否更容易忘掉要求
• 是否更容易输出冗余内容

练习 3：记录一次“模型明明像懂了，但其实不稳”的例子

从你工作里的真实使用中，找一个这样的例子：

• 看起来答得很像那么回事
• 但重复几次就不一致
• 或者一换措辞结果就漂了

把这个例子写下来。

这一步很重要，因为它会帮你真正从“用户视角”切换到“系统视角”。

九、这篇学完之后，你应该达到什么状态

不是“我学完了 LLM”，而是你至少应该能清楚说出下面这些话：

• LLM 是系统中的一个能力模块，不是整个 Agent 系统；
• 模型每次只基于当前上下文工作；
• 上下文管理是稳定性的关键来源之一；
• token 不只是计费单位，也影响窗口、成本和延迟；
• 模型看起来懂，不等于它天然可靠；
• 后面的 Tool Use、工作流、状态管理，都是在补模型本身的边界。

如果这些话你已经能用自己的语言复述出来，那这篇就算真正学到了。

十、小结

这篇文章最核心的结论，其实可以压缩成一句话：

先理解模型边界，后理解 Agent 设计。

如果模型本身在你脑中还是一个模糊的“黑箱”，后面的 Agent 只会学成一堆看似高级的词。

但如果你先把：

• 输入
• 上下文
• token
• 输出稳定性
• 模型边界

这些基础问题理清楚，那么后面再学 Tool Use、Function Calling、工作流与 RAG，就会稳很多。

而下一篇，我会继续往前走，进入更贴近实际工程的一层：

Prompt、Context 与输出约束：为什么模型有时听话，有时跑偏。