引言

本文旨在介绍大语言模型领域中最常见的一些基础概念与术语。

如果你已经开始使用 ChatGPT、Claude、Gemini 等 AI 产品，却对 AGI、RAG、上下文窗口、缓存、微调这些词只有一个模糊印象，那么可以先从这篇文章建立一套基本认知。

---

一、先搞懂基础：AI 是怎么被训练出来的

在进入具体名词之前，有必要先花两分钟了解一个大语言模型是怎么诞生的。这能帮你理解后面所有概念分别处在什么位置。

一个现代大语言模型，通常会经历预训练和一系列后训练过程。

第一阶段：海量阅读——预训练

预训练阶段，模型会学习来自网页、书籍、论文、代码等大规模文本数据中的语言规律。

这个阶段最核心的训练目标，可以简单理解为：

根据前面的内容预测下一个 Token。

Token 是模型处理文本时使用的基本单位。它可能是一个汉字、一个英文单词的一部分，也可能是标点符号。

比如模型看到：

今天天气真……

它会计算后面出现“好”“热”“不错”等 Token 的概率。

训练最开始时，模型几乎是在随机猜测。随着预测结果不断与真实文本进行比较，模型内部数十亿甚至数千亿个参数被持续调整。

经过大量训练后，模型逐渐掌握语言结构、代码模式、知识关联以及一定程度的推理模式。

但这个阶段得到的模型，本质上更接近一个强大的文本续写模型。

---

第二阶段：学会按照指令工作——监督微调

为了让模型能够回答问题、执行指令，研究人员会准备大量高质量的“输入—输出”示例。

例如：

用户：
解释一下什么是 HTTP。

助手：
HTTP 是一种用于客户端与服务器之间传输数据的应用层协议……

模型通过这些样例学习：

• 怎样回答问题
• 怎样遵循用户指令
• 怎样组织输出
• 怎样完成总结、翻译、代码生成等任务

经过这一步后，模型才逐渐变成我们熟悉的 AI 助手。

---

第三阶段：让回答更符合人类偏好——对齐

只会回答问题还不够。

一个实际提供给用户的大模型，还需要学习：

• 哪些回答更有帮助
• 哪些回答更加准确
• 哪些内容存在安全风险
• 怎样减少无意义或低质量输出

因此模型还会继续接受偏好优化、安全训练等后训练。

不同公司和模型采用的方法并不完全相同，可能涉及人工反馈、AI 反馈、奖励模型以及各种强化学习或直接偏好优化技术。

因此，“预训练 → 微调 → 对齐”可以作为理解现代大模型训练过程的一种简化框架，但现实中的训练流程往往更加复杂。

---

二、核心概念逐个拆解

1. AGI：通用人工智能

AGI 全称：

Artificial General Intelligence，通用人工智能。

它通常指一种能够在广泛任务中学习、推理、适应新环境，并把已有能力迁移到新问题上的人工智能。

AGI 和今天的大语言模型之间到底有多远，目前并没有统一答案。

事实上，行业甚至没有一个所有人都认可的 AGI 标准。

有人认为，只要 AI 能够在绝大多数知识工作中达到人类水平，就可以称为 AGI。

也有人认为，真正的 AGI 还需要具备：

• 长期自主学习
• 环境适应
• 跨领域能力迁移
• 长期规划
• 高可靠性决策

因此，AGI 更适合作为一个长期目标和能力概念来理解。

---

2. RAG：让 AI 先查资料，再回答

大语言模型掌握的知识主要来自训练数据。

如果模型没有联网、搜索或其他外部工具，那么训练结束之后发生的事情，它无法凭空知道。

另外，公司内部文档、数据库、项目代码以及个人笔记等私有数据，本身也不会自动存在于模型参数里。

这就引出了：

RAG（Retrieval-Augmented Generation，检索增强生成）。

RAG 的基本流程很简单。

用户提出问题后，系统首先从外部知识库中检索相关内容。

例如你问：

公司退款政策是什么？

系统可能先找到内部文档中的相关段落：

退款政策：
购买后 7 天以内，可在满足条件时申请退款……

然后把这些资料与用户问题一起发送给模型：

参考资料：
购买后 7 天以内……

用户问题：
公司的退款政策是什么？

最后由模型结合这些资料生成答案。

整个流程可以概括为：

用户问题
   ↓
检索相关资料
   ↓
资料 + 问题
   ↓
大语言模型
   ↓
生成回答

RAG 最大的价值在于，它可以让模型使用参数之外的信息。

因此特别适合：

• 企业内部知识库
• 技术文档问答
• 产品帮助中心
• 最新政策与资料
• 需要来源引用的知识问答

RAG 也是降低知识型幻觉的重要工程手段之一。

不过它并不能彻底消除幻觉。

如果检索出来的资料本身就是错的，或者检索系统没有找到真正相关的内容，那么最终答案仍然可能出错。

因此，一个完整的 RAG 系统通常需要同时解决：

检索质量 + 上下文组织 + 模型生成质量。

---

3. 上下文窗口：模型一次能看到多少信息

大语言模型并不是无限记忆。

模型每次进行推理时，只能处理有限数量的 Token，这个范围被称为：

Context Window，上下文窗口。

你可以把它理解为模型工作时的一张“临时桌面”。

桌面越大，一次能够摊开的资料就越多。

例如一个上下文窗口足够大的模型，可以同时读取：

• 大量代码文件
• 一篇长论文
• 长时间的聊天记录
• 多份技术文档

然后结合这些信息回答问题。

而如果输入内容超过模型允许的上下文长度，一部分内容就无法继续直接参与当前推理。

应用程序通常会通过几种方式解决这个问题：

• 删除不重要的旧内容
• 对历史对话进行摘要
• 使用 RAG 重新检索相关内容
• 使用长期记忆系统保存重要信息

需要注意的是：

上下文窗口并不等于长期记忆。

上下文中的信息更像是模型当前工作时能够看到的资料。

长期记忆则通常由 AI 产品的应用层另外实现。

上下文窗口也并非越大越好。

更长的输入通常意味着：

• 更多计算量
• 更高的内存开销
• 更长的输入处理时间
• 更高的 Token 成本

因此实际 AI 系统通常会尽量只把真正有用的信息放入上下文。

---

4. Prompt Cache：为什么重复上下文会更便宜

大模型应用经常需要反复发送大量相同内容。

例如：

System Prompt
+
工具定义
+
项目代码
+
长篇文档
+
历史对话
+
用户最新问题

这里前面的大部分内容，可能连续很多次请求都完全相同。

如果每次都重新处理这些 Token，就会产生大量重复计算。

因此很多模型服务都会使用：

Prompt Cache，也叫 Prefix Cache。

它会缓存之前已经处理过的输入前缀。

例如第一次请求：

系统提示词
项目代码
技术文档
用户问题 A

第二次请求：

系统提示词
项目代码
技术文档
用户问题 B

前三部分完全相同。

系统就有机会复用之前处理这些内容时产生的中间计算结果，只处理后面新增的部分。

这可以降低：

• 输入处理延迟
• 重复计算量
• 输入 Token 成本

很多 API 中看到的：

cached_tokens

通常就是指这一类被缓存并复用的输入 Token。

需要特别注意：

Prompt Cache 命中，并不意味着直接返回上一次的答案。

模型依然需要处理新的问题，并生成新的输出。

这和传统 Web 服务中的“响应缓存”是两种不同机制。

传统响应缓存可能是：

请求
 ↓
找到完全相同的历史结果
 ↓
直接返回

而 Prompt Cache 更接近：

重复上下文
 ↓
复用此前的计算
 ↓
继续处理新内容
 ↓
生成新的答案

对于大量使用长 System Prompt、代码上下文或长文档的 AI 应用来说，Prompt Cache 对成本和延迟都有很明显的影响。

---

5. 微调：让模型更适合特定任务

通用模型已经拥有很强的基础能力，但不同应用对模型行为的要求并不一样。

例如：

客服系统可能希望模型始终使用统一语气。

代码分析工具可能要求模型严格按照某种 JSON 格式返回。

某个专业领域可能存在大量专有术语和特殊任务模式。

这时可以使用：

Fine-tuning，微调。

微调是在已经训练好的模型基础上，再使用特定数据继续训练，让模型进一步适应某类任务或行为模式。

例如准备大量这样的数据：

输入：
分析下面日志中的错误原因。

输出：
{
  "error_type": "...",
  "cause": "...",
  "solution": "..."
}

经过微调后，模型会更加稳定地按照这种任务形式输出结果。

微调可以用于：

• 固定输出格式
• 特定语言风格
• 分类任务
• 信息抽取
• 专业领域表达
• 特定指令行为

现在也有很多参数高效微调技术，例如：

LoRA（Low-Rank Adaptation）。

它不需要重新训练模型全部参数，而是在模型内部增加少量可训练参数，从而显著降低训练成本。

---

三、Agent 与 Harness：模型为什么开始真正“做事”

到了 2026 年，理解大语言模型已经不能只停留在 Model 本身。

越来越多 AI 产品开始以 Agent 的形式出现。

理解 Agent，其实可以先记住一个很简单的公式：

Agent ≈ Model + Harness

这里的 Model，就是我们前面一直讨论的大语言模型。

它负责理解语言、分析问题、进行推理，并决定下一步应该做什么。

真正让模型从“聊天”走向“执行”的，则是后面的 Harness。

Harness 到底是什么？

Harness 原本就有“马具、套具”的意思。

放到 AI Agent 中，可以把它理解成：

围绕模型搭建的一整套运行环境和控制系统。

模型本身并不会天然拥有终端、浏览器、文件系统，也不会自动知道有哪些工具可以调用。

这些能力都需要外部系统提供。

一个 Harness 中通常可能包含：

• 工具
• 文件与代码环境
• 浏览器和搜索
• Session
• 上下文管理
• Sandbox
• Agent Loop
• 权限和执行控制

模型负责决定“应该做什么”，Harness 则负责把这种决定变成真实的操作。

例如模型可能判断：

我需要先查看这个项目的 CMake 配置。

Harness 才真正负责把项目文件提供给模型，并允许它读取文件、执行命令，再把执行结果返回给模型。

所以，同一个 Model 放在不同 Harness 中，表现出来的能力可能完全不同。

而最近Deepseek Harness比较火, 刚好可以拿它做一个例子。

它官方给出的描述恰好就是：

Agent = Model + Harness

DeepSeek Harness 并不是一个新的大语言模型，而是一套运行 Agent 的基础设施。它负责把模型与工具、Skills、Session、Sandbox、Storage、Agent Loop、调度以及 UI 等能力连接起来。

它还有一个很明显的设计理念：

Everything is a Plugin。

也就是说，Agent 的很多能力都可以作为插件安装、替换或重新组合。

例如，一个 Coding Agent 可以拥有文件编辑、Shell、搜索、规划甚至子 Agent 等能力；而一个非常精简的 Agent，也可以只保留 Shell 和文件编辑器。

这很好地说明了一件事情：

Agent 的能力，不只是由模型决定的。

模型当然非常重要，但它能够看到什么、调用什么工具、保存什么状态、运行在什么环境中，同样会直接影响最终效果。

因此，当我们今天讨论一个 Agent“强不强”时，仅仅问：

它用了什么模型？

已经不够了。

还应该继续问：

这个模型运行在什么 Harness 上？

四、几个容易被误解的地方

AI 到底有没有推理能力？

现代大语言模型已经能够完成：

• 数学推导
• 代码分析
• 多步骤规划
• 逻辑问题
• 复杂工具调用

因此工程领域通常会直接使用“推理能力”这个词描述这些表现。

但目前没有证据表明，大语言模型采用了和人脑完全相同的推理机制。

而且模型的推理仍然存在明显的不稳定性。

它可能：

• 使用错误前提继续推导
• 在长推理链中漏掉条件
• 得出逻辑完整但事实错误的结论
• 对相同问题给出不同答案

因此在工程应用中，比讨论“模型是不是真的在思考”更重要的问题是：

它的推理结果是否可靠、能否验证。

---

上下文窗口越大越好吗？

更大的上下文窗口意味着模型能够一次处理更多资料。

但同时通常也意味着更高的计算、内存和 Token 成本。

因此实际应用中追求的最好是：

让模型看到当前任务真正需要的信息。

这也是 RAG、上下文压缩和记忆系统存在的重要原因。

---

RAG 能彻底解决幻觉吗？

不能。

RAG 可以给模型提供可靠资料，但最终效果依赖整个检索链路。

例如：

问题
 ↓
检索到了错误资料
 ↓
模型认真阅读错误资料
 ↓
生成一个非常完整的错误答案

所以 RAG 系统真正需要关注的是：

有没有检索到正确、相关、足够的信息。

---