《从0到1将 AI核心名词连成线》
🎯困惑:AI 圈每天冒出成吨新名词——LLM、Token、RAG、MCP、Agent……
你可能都见过,但它们之间到底什么关系?是平级的,还是上下游?
本文做一件事:把这堆名词串成一条线。
一端是底层数学运算,一端是能帮你干活的智能体。沿着这条线,你不会迷路。
一、底层引擎:模型怎么「理解」文字
Transformer:让机器看到上下文
🎯矛盾:人类语言模糊——「我喜欢吃苹果」是水果还是手机,你一秒判断,机器不能。
早期方法叫 RNN(循环神经网络)。像一个孩子读课文,一个字一个字往下啃。读到后面前面就忘了。又慢,又容易丢信息。
2017 年,Google 提出了Transformer。
它的核心叫自注意力机制(Self-Attention)。不再一个字一个字读——一句话全扔进去,每个词同时看其他所有词,找出谁跟自己最相关。就像一个小组讨论:每个人都能听到所有人的发言,再决定自己该说什么。
💡 Transformer 是发动机,不是整辆车。GPT、Claude、Gemini、LLaMA——都是用这台发动机造的车。
LLM:文字接龙高手
Large Language Model(大语言模型)。这个名字太学术了。换个说法:LLM 是一个训练出来的「文字接龙高手」。
- 你写「床前明月」,它接「光」
- 你问「1+1=?」它答「2」
- 你让它写代码,它一行行生成
原理没变——每一步都是预测下一个最合理的词。但当参数量从几百万膨胀到几千亿之后,奇怪的事情发生了:它会推理了,会翻译了,会写诗了,会「举一反三」了。
这个从量变到质变的过程,研究者称之为涌现(Emergence)。「大」字不是广告词——它是这个现象的前提。
💡 LLM = Transformer + 海量数据 + 超大参数规模。文字接龙玩出了智能。
📌本站小结
- Transformer 解决了「如何理解上下文」——发动机
- LLM 用海量数据把这台发动机放大,产生了「涌现智能」——整车
- 但 LLM 不识字——它里面跑的是矩阵乘法,只吃数字
二、翻译层:文字怎么变成模型能算的东西
Token & Tokenizer
🎯矛盾:模型只吃数字,吐出来的也是数字。它压根不认识「你好」——就像一个只会说二进制的外星人。
你得在中间架一个翻译官。这就是Tokenizer(分词器)。
它干两件活:
编码(Encode):文字 → 数字
- 把文字切成小片段——每个片段就是一个Token
- 每个 Token 去词典里查表,映射成一个数字——Token ID
解码(Decode):数字 → 文字
- 模型每次吐出一个 Token ID
- 反向查表,变回文字片段
- 拼起来,流式输出给你
Token 是大模型处理文字的最小颗粒度。它不是一个「词」——一个英文单词可能被切碎成 2 个 Token
| 语言 | 1 个 Token 约等于 |
|---|---|
| 英文 | 0.75 个单词 |
| 中文 | 1.5 ~ 2 个汉字 |
为什么 GPT 按 Token 计费?因为 Token 就是它的「汽油」——灌进去的每一升,它都得烧。
但 Token ID 只是一个索引号。「猫」= 4867,「狗」= 3291。光看这俩数字,你看不出它们都是宠物。
Embedding:数字到语义的映射
Embedding干的事:把这个编号,映射成高维空间里的一个坐标。
在这个空间里,意思相近的词位置也近。「猫」离「狗」很近,离「汽车」很远。大模型所有的「理解」,本质上就是在这个向量空间里做加减法。
一个经典到被用烂、但真的很好懂的例子的例子:
- 「国王」-「男人」+「女人」≈「王后」
- 「北京」-「中国」+「日本」≈「东京」
📌本站小结
- Tokenizer:文字 → 数字(翻译官)
- Embedding:数字 → 有语义的向量(给编号注入意思)
- 模型终于能「看懂」文字了——但它不能只处理当前这句话,它需要记住之前聊了什么
三、工作记忆与使用说明书
Context(上下文)
🎯矛盾:你跟一个人聊天,他三秒前你说过的话全忘了。这对话能进行下去吗?
但模型就是这样——它本身没有「记忆」。每次你发消息,平台并不是只把这句话发过去。它会打包一整袋信息一起塞给模型。这袋信息就是Context(上下文)。
袋子里面装着:
- 你们之前的所有对话记录
- 你刚发的这句话
- 后台给模型定的「人设说明书」(System Prompt)
- 它能用的工具清单
- 它自己已经输出的内容——所以它知道自己说了什么,不会重复
模型读完这袋信息,再决定下一个 Token 是什么。
但这袋子有容量上限。Context Window(上下文窗口)就是袋子能装的 Token 上限。GPT-4 Turbo 是 128K Token——大约一整本《三体》第一部。超出窗口的对话,模型就「忘干净了」。
这就像你的办公桌——桌面上只能铺开有限的东西。铺不下的收进抽屉,对当下来说等于不存在。
Prompt(提示词)
Prompt = 你给模型的输入。分成两种类型:
| 类型 | 谁写的 | 干什么用 |
|---|---|---|
| System Prompt | 开发者,用户看不到 | 定义模型是谁、什么能做、什么不能做 |
| User Prompt | 你写的 | 具体任务——「帮我翻译」「写段代码」 |
曾经有一段时间,Prompt Engineering被视为一门手艺——怎么措辞、怎么排列、怎么用「让我们一步一步思考」来引导推理。现在风向变了。不是因为 Prompt 不重要了,而是因为模型变聪明了。你不需要像教小孩一样小心翼翼遣词造句——把需求讲清楚就行。措辞技巧在贬值,思维清晰度在升值。
📌本站小结
- Context = 模型的工作记忆,窗口大小决定记忆力上限
- Prompt = 你给模型下的「任务书」+ 后台定的「人设」
- 但模型有个死穴:它的知识冻结在训练完成那一天。它不知道「现在发生了什么」
四、知识补丁:让模型知道「现在」
RAG(检索增强生成)
🎯矛盾:大模型是个博学的古人。它知道训练数据里的一切——但如果训练截止到 2024 年 6 月,它就不知道 2024 年 7 月之后的事。更关键的是,你公司的内部文档、你的个人笔记、你团队的代码规范——它从来没「读」过。
怎么办?两种思路。
第一种思路:考试带小抄。
提问时,先到外部知识库(文档、数据库、网页)里翻一圈,把相关内容找出来,贴在你的问题后面——一起发给模型。模型一看:「哦,这是参考资料,我按这个来答。」
这就是RAG(Retrieval-Augmented Generation,检索增强生成)。
流程:
- 你提问
- 系统先去知识库检索相关内容
- 把检索结果拼进 Context
- 模型基于「外部资料 + 自身知识」生成答案
市面上大部分「AI 知识库」「AI 客服」产品,底层就是 RAG。优点是快、便宜、不碰模型。缺点是检索质量决定回答质量——搜不到就等于没有。
Fine-tuning(微调)
第二种思路:让模型背书。
拿你的领域数据——医学文献、法律合同、产品说明——对模型做额外训练。调整它的一部分参数,让它在特定领域的表现大幅提升。这就是Fine-tuning(微调)。
通才修一门专业课,变成专才。
| RAG(检索增强) | Fine-tuning(微调) | |
|---|---|---|
| 怎么工作 | 不动模型,外部查资料塞进去 | 改模型本身,内化知识 |
| 类比 | 考试带小抄 | 背书 |
| 优点 | 快、便宜、资料随时更新 | 领域表现更深层、更稳定 |
| 缺点 | 检索质量决定上限 | 贵、慢、更新知识要重新训练 |
两个方案不互斥。很多产品的路径是:先 RAG 快速上线 → 收集真实用户反馈 → 再用 Fine-tuning 深耕。
Hallucination(幻觉)
模型会一本正经地胡说八道。
这不是 bug——这是 LLM 的本质。它不是在「查数据库」,它是在「预测下一个 Token」。每一步选概率最高的那个——但概率高不等于事实正确。当模型缺乏相关知识,被推到知识边界之外,它不会说「我不知道」。它编。编得还很像那么回事。
这是理解 LLM 最关键的认知:它是一个概率系统,不是一个知识库。
RAG 能减少幻觉(用外部资料把它按住)。更好的 Prompt 能减少幻觉(让它知道边界在哪)。但消除幻觉?目前做不到。
Temperature(温度)
控制模型「脑洞」大小的旋钮。
模型预测下一个 Token 时,并不总是选概率最高的那个。有时候故意选个偏的——答案就会更有「创意」。Temperature 就是调节这个「敢不敢偏」的参数。
- 低温度(趋近 0):保守,每次选最安全的词。输出稳定,但可能干巴。
- 高温度(趋近 1+):冒险,偶尔选小概率词。更有趣,但也更容易跑偏。
写代码 → 低温度。写诗 → 高温度。
📌本站小结
- 模型知识有截止日期 → RAG 给它「带小抄」
- 通用能力不够专 → Fine-tuning 让它「背书」
- 但模型本质是概率预测,不是数据库 → 幻觉无法根除
- Temperature 调节「保守 vs 创意」的平衡
- 但这些全是认知层面的补丁——模型仍然被困在文字世界里。它没有手脚
五、突破边界:让模型触碰现实
Tool(工具调用)
🎯矛盾:大模型是「缸中之脑」。它能聊量子力学,但不知道现在几点。它能解释天气原理,但查不了明天的温度。它能分析你贴进去的代码,但读不了你硬盘上的文件。因为你每次喂给它的,只有文字。
要想让它感知和影响外部世界,就得给它装手脚。这就是Tool(工具)。
本质上,Tool 就是一个函数(Function)。模型需要查天气时,它不「猜」天气——它输出一个信号:「我要调用get_weather这个函数,参数是城市名。」平台收到信号,执行这个函数,把真实结果(「上海,26°C,多云」)塞回 Context。模型再基于结果继续生成。
流程:用户 → 平台 → 大模型 → 调用工具 → 工具返回结果 → 大模型 → 用户
没有 Tool,模型是图书管理员——只能聊。有了 Tool,模型是你的助理——能查、能写、能发、能改。
但问题又来了。
MCP(模型上下文协议)
🎯矛盾:每个平台接入工具的方式都不一样。OpenAI 有一套规范,Anthropic 有一套,Google 又有一套……你写一个工具,想在所有平台跑,得分别适配。工具多了,适配组合指数爆炸——N 个工具 × M 个平台 = N×M 套适配代码。
这是典型的「接口不统一」问题。历史上被解决过很多次。最像的那一次:所有手机充电口统一成Type-C——之前每家都有自己的充电口,出门带一堆线。统一之后,一根线到处用。
MCP(Model Context Protocol)就是 AI 世界的 Type-C。
Anthropic 在 2024 年底提出的开放协议,定义了工具与 AI 平台之间怎么通信。你按 MCP 写一个服务端,所有支持 MCP 的平台都能直接用。工具开发者不用再为每个平台写适配,平台方不用再为每个工具做集成。这就是协议的力量——把 N×M 的问题变成 N+M。
📌本站小结
- Tool 给模型装上了手脚,让它触碰现实
- MCP 给 Tool 定了统一接口——Type-C 化了
- 模型有了工具,但它还是被动的——每次都得等你的指令
六、自主层:模型开始「自己干活」
Agent(智能体)
🎯矛盾:普通聊天模式——你问一句,它答一句。你让它查天气,它返回天气。但如果任务复杂一点呢?
「帮我研究一下 MCP 协议,写一篇综述,发到我的博客上。」
这不是一问一答能解决的。它需要:搜索资料 → 阅读整理 → 撰写文章 → 发布到博客平台。中间可能遇到:链接失效需要换源、文章太长需要分段、发布失败需要重试。
Agent(智能体)就是能干这种活的系统。你给目标,它自己:
- 拆解成子任务
- 决定每一步调用什么工具
- 根据工具返回的结果,调整下一步计划
- 循环,直到完成
Agent 和普通聊天的核心区别:Agent 有自主决策权。它不是照着脚本跑——它会根据中间结果选路。
两个经典的 Agent 构建框架:
- ReAct(Reasoning + Acting)——「想一步,走一步」。每轮先推理当前状况 → 决定下一步行动 → 执行 → 观察结果 → 再推理……如此循环。
- Plan and Execute——「先画地图,再走路」。先制定完整计划,然后按计划执行。中途发现计划错了,再修正。
知名 Agent 产品:Claude Code、Codex CLI、Gemini CLI、Cursor 的 Agent 模式——2025 年,Agent 正在从概念变成每个开发者都能用的日常工具。
Agent Skill(智能体技能)
一个 Agent 能做的事太多了。你不想每次都把所有能力列出来让它选——Context 窗口本来就紧张。所以需要把常用的能力「打包」:给一个名字、一个触发条件、一套执行步骤。这就是Skill。
比如一个翻译 Skill:
- 触发条件:用户要求翻译某个文件
- 执行步骤:读取文件 → 按指定语言翻译 → 保持格式 → 保存到指定路径
Skill 和普通 Prompt 的区别:Prompt 是一次性的,Skill 是封装好可复用的。它就像一个 U 盘——写一次,插上就能用,换一台机器照样用。
📌终点站小结
- Agent 让模型从「被动回答」升级到「主动规划」
- Skill 把 Agent 的能力打包成可插拔的模块
- 从 Transformer 到 Agent Skill,走完了一整条从「数学运算」到「自主干活的 AI」的进化链
好了,感谢你的阅读,祝你有开心的一天!
