前言
AI圈子里每天都在冒新名词：LLM、Token、Context、Prompt……这些词你可能都听说过。但是，你真的能准确说出其中每一个概念的确切含义吗？
这篇文章不整那些虚头巴脑的商业概念，我们从最底层的工程视角出发，一个一个把这些概念拆开、揉碎讲清楚。相信读完这篇文章，你对AI的理解绝对会上升一个台阶。
一、LLM（大语言模型）
1.1 什么是LLM？
LLM全称是Large Language Model，翻译成中文就是大语言模型，简称大模型。
基本上现在所有的大模型都是基于Transformer这套架构训练出来的。这个架构最早由Google团队在2017年提出，对应的论文名是《Attention is All You Need》。
极具戏剧性的是，虽然Google发明了火种，但真正把它点燃并且引爆全世界的却是OpenAI。
1.2 大模型的发展历程
- 2020年：GPT-3发布，已经具备初步实用价值
- 2022年底：GPT-3.5横空出世，真正让大模型进入大众可用阶段
- 2023年3月：GPT-4发布，把AI的能力天花板拉到了新高度
- 至今：Claude等优秀后起之秀在各领域与OpenAI同台竞技
GPT系列是今天AI浪潮的绝对鼻祖，时至今日，GPT家族依然非常强大，GPT-4仍是业界标杆之一。
1.3 大模型的工作原理
大模型到底是怎么工作的？答案非常简单朴素：它本质上就是一个文字接龙游戏。
虽然本质是"预测下一个Token"，但通过大规模训练，这种能力涌现出了推理、总结、代码生成等复杂行为。
具体例子：
假设你向大模型提问："这个产品怎么样？"
- 模型接收这句话后，经过内部运算，预测下一个概率最高的词："非常"
- 模型把"非常"抓回来，追加到输入后面
- 继续预测下一个字："好"
- 再把"好"塞回去，继续预测："用"
- 最后输出结束标识符
完整回答："非常好用"
这就是为什么大模型要一个词一个词地输出答案——因为它就是这么运作的。
一句话总结：大模型 = 一个极其复杂的"概率文字接龙机器"
二、Token（词元）
2.1 文字与数字的桥梁
大模型本质上是一个庞大的数学函数，里面跑的全是矩阵运算。它接收的是数字，输出的也是数字，压根儿就不认识人类写的文字。
在人类和大模型之间必须有一个中间人来做翻译，这个中间人就叫做Tokenizer（分词器），负责编码和解码两件事情：
- 编码：把文字变成数字
- 解码：把数字还原成文字
2.2 Token的生成过程
以用户提问"这个产品怎么样？"为例，这句话通常会被切分成若干个Token（具体数量取决于模型的分词策略，不同模型可能略有差异）。
第一步：切分
把用户的问题拆成一个一个最小的片段，这些片段就叫做Token。
第二步：映射
把每个Token对应到一个数字上去，这个数字就叫做Token ID。
2.3 Token vs 词：不是一对一关系
你可能会想：Token就是词，对吧？
不一定！ Token和词并没有明确的一对一关系。
中文例子：
- "工作坊" → 拆成"工作"+"坊"（2个Token）
- "程序员" → 拆成"程序"+"员"（2个Token）
英文例子：
- "hello" → 1个Token
- "going" → 1个Token
- "helpful" → 拆成"help"+"ful"（2个Token）
特殊字符：
某些情况下，一个字符会被切分成多个Token。比如"✓"（对勾）需要3个Token来表示。
2.4 Token的估算标准
平均来讲：
- 1个Token ≈ 0.75个英文单词
- 1个Token ≈ 1.5~2个汉字
举例：
- 40万个Token ≈ 60~80万个汉字
- 40万个Token ≈ 30万个英文单词
总结：Token是模型自己学会的一套文本切分规则，切出来的每一块就是它一次能够处理的最小单位。
一句话总结：Token是模型理解世界的"最小语言单位"
三、Context（上下文）
3.1 大模型的"记忆"之谜
我们平时和大模型聊天，它好像能记住之前说的话。比如你开头告诉他"我的名字是小明"，他给你回复以后，你再问他"我叫什么名字"，他还是能够回答得出来。
但问题是，大模型本质上只是一个数学函数，它并不像人一样真的有记忆。它是怎么记住之前的聊天内容的呢？
答案：每次给大模型发送消息时，并不只会发我们的问题，背后的程序会自动把之前的整段对话历史找出来，一起发过去。
3.2 什么是Context？
Context（上下文）代表大模型每次处理任务时所接触到的信息总和。
Context包含的内容：
- 用户问题
- 对话历史
- 大模型正在输出的每个Token
- 工具列表
- System Prompt（系统提示词）
- 其他信息
可以把Context看成是大模型的一个临时记忆体。
3.3 Context Window（上下文窗口）
Context Window代表Context能够容纳的最大Token数量。
主流模型的Context Window：
| 模型 | Context Window |
|---|---|
| GPT-4 | 128K（约105万Token） |
| Claude 3.1 Pro | 100万Token |
| Claude Opus 4 | 100万Token |
100万个Token ≈ 150万个汉字，整个《哈利波特》全集的内容都能装下。
技术细节：为什么Context会影响推理能力？因为大模型进行复杂推理（如链式思考）需要足够长的上下文来"记住"推理过程。没有足够的Context，模型无法进行多步骤的逻辑推演。
一句话总结：Context不是记忆，是一次性打包输入
四、RAG（检索增强生成）
4.1 问题场景
假设你有一个上千页的公司产品手册，你希望大模型根据这个手册来回答用户的各种疑问，要怎么实现？
4.2 不好的方案
把手册的全部内容跟着用户问题一起扔给大模型？
问题：
- 产品手册太长
- 即使模型的Context Window不被撑爆，成本也无法控制
4.3 RAG解决方案
RAG（Retrieval-Augmented Generation，检索增强生成）可以从产品手册中抽取与用户问题最为匹配的几个片段，然后只把这几个片段发给大模型。
优势：
- 不受Context Window大小限制
- 成本大大降低
- 大模型接收的不是一整本书，可能只是几段话
RAG vs Fine-tuning：RAG是检索时动态注入知识，适合知识频繁更新的场景；微调是将知识嵌入模型参数，适合特定任务的优化。两者可以结合使用。
一句话总结：RAG = 给大模型外挂一个可检索的知识库
五、Prompt（提示词）
5.1 什么是Prompt？
Prompt（提示词）是大模型接收的具体问题或指令。
比如你向大模型提需求："帮我写一首诗。"这句话就是Prompt。
不要把Prompt想成特别复杂高端的东西，它只不过就是给大模型的一个问题或者是指令而已。
5.2 为什么Prompt很重要？
如果你只是简单地说"帮我写一首诗"，大模型可能会：
- 写古诗
- 写现代诗
- 写打油诗
原因：Prompt太模糊，它不知道你具体想要什么。
5.3 如何写好Prompt？
一个好的Prompt应该是：清晰的、具体的、明确的。
好的例子：
"请帮我写一首五言绝句，主题是秋天的落叶，风格要悲凉一点。"
这样一来，大模型就清楚多了，生成的内容也更符合你的预期。
5.4 Prompt Engineering（提示词工程）
Prompt Engineering本质上不是"黑科技"，而是"把话说清楚"——这也是为什么它门槛并不高。
现状：
- 门槛较低，本质上就是把话说清楚
- 大模型能力越来越强，即使提示词含糊不清，大模型也能大致猜出你的意图
- 现在还在提它的人寥寥无几
一句话总结：Prompt = 你和大模型沟通的唯一接口
六、User Prompt vs System Prompt
6.1 两种不同的Prompt
有些时候我们不仅要告诉大模型它要处理的具体任务，还要告诉它人设和做事规则。
User Prompt（用户提示词）
- 定义：说明具体任务的Prompt
- 来源：用户自己在对话框输入
- 示例："3加5等于几？"
System Prompt（系统提示词）
- 定义：说明人设和做事规则的Prompt
- 来源：开发者在后台配置
- 示例："你是一个耐心的数学老师，当学生问你数学问题的时候，不要直接给出答案，而是要一步一步引导学生思考，帮助他们理解解题思路。"
6.2 具体例子
场景：做一个数学辅导机器人
System Prompt（后台设置，用户看不到）：
"你是一个耐心的数学老师，当学生问你数学问题的时候，不要直接给出答案，而是要一步一步引导学生思考，帮助他们理解解题思路。"
User Prompt（学生输入）：
"3加5等于几？"
大模型的回答：
"我们可以这样想，你手里有三个苹果，然后又拿了5个，现在一共有多少个呢？你可以数一数看。"
对比：如果没有System Prompt，大模型可能直接说"8"了。
七、Tool（工具）
7.1 大模型的弱点
大模型有一个明显的弱点：无法感知外界环境。
没有Tool的大模型，本质上是"闭着眼睛说话"。
例子：
假设你问大模型："今天上海的天气怎么样？"
它可能会说：
"抱歉，我无法获取实时天气信息。我的知识库截止到某年某月，无法提供当前的天气数据。"
原因：大模型只是个文字接龙游戏，它的能力是根据训练数据来预测下一个词，但它真的没有办法去查天气预报网站拿到实时的天气数据。
7.2 什么是Tool？
Tool（工具）本质上就是一个函数，你给它输入，它就给你输出。
天气查询工具例子：
- 输入：城市、日期（两个参数）
- 内部操作：调用气象局的接口
- 输出：天气信息
有了工具，大模型就可以回答天气相关的问题了。
7.3 工作流程
完整流程涉及的角色：
- 用户：提出问题
- 大模型：理解问题，决定是否需要调用工具
- 工具：执行具体任务，返回结果
- 大模型：根据工具返回的结果，生成最终回答
具体步骤：
- 用户问："今天上海天气怎么样？"
- 大模型识别到需要天气信息
- 大模型调用天气查询工具，传入参数：城市="上海"，日期="今天"
- 工具调用气象局API，返回天气数据
- 大模型根据天气数据生成自然语言回答
- 用户收到："今天上海晴，气温25°C，适合出行。"
7.4 常见工具类型
| 工具类型 | 功能 | 示例 |
|---|---|---|
| 搜索工具 | 实时搜索互联网信息 | Google搜索、Bing搜索 |
| 计算工具 | 执行数学计算 | Python代码执行器 |
| 数据库工具 | 查询数据库 | SQL查询工具 |
| API工具 | 调用外部服务 | 天气API、股票API |
| 文件工具 | 读写文件 | 文档处理工具 |
一句话总结：Tool = 让大模型睁开眼睛看世界的能力
八、Skill（技能）
我帮你写一版“风格统一的”👇（可以直接用）
什么是Skill？
Skill（技能）是针对特定任务的预配置能力包。它把大模型、Prompt、工具、记忆等组件打包在一起，形成一个可以直接使用的功能模块。
如果说：
- Tool 是一个个“工具函数”
- 那 Skill 就是把多个 Tool + Prompt + 执行流程 组合在一起，形成一个可复用的能力模块
Skill的组成
| 组件 | 说明 | 示例 |
|---|---|---|
| 大模型配置 | 选择哪个模型 | GPT-4、Claude、Gemini |
| System Prompt | 人设和任务规则 | "你是一个Python代码专家" |
| 工具列表 | 可调用的工具 | 代码执行器、Git操作 |
| 记忆配置 | 是否需要记忆 | 短期记忆、长期记忆 |
| 输出格式 | 结果的格式要求 | JSON、Markdown、代码块 |
Skill vs Agent vs SubAgent
| 对比维度 | Skill | Agent | SubAgent |
|---|---|---|---|
| 定位 | 功能模块 | 任务执行者 | 辅助执行者 |
| 配置 | 预配置 | 动态配置 | 由Agent分配 |
| 复用性 | 高（可跨项目） | 中（项目内） | 低（任务内） |
| 自主性 | 低（被动调用） | 高（自主规划） | 低（被动执行） |
Skill的生态系统
开源Skill库：
- GitHub上的Skill仓库
- 社区贡献的Skill包
- 可直接下载使用
商业Skill市场：
- 官方Skill商店
- 第三方Skill平台
- 付费/免费Skill
自定义Skill：
- 根据业务需求定制
- 企业内部Skill库
- 持续迭代优化
九、Agent（智能体）
9.1 从大模型到Agent
前面我们学习了Tool，让大模型能够调用外部函数来获取信息。但这里有个问题：谁来决定什么时候调用工具？调用哪个工具？工具返回的结果怎么处理？
这就是Agent（智能体）登场的时候了。
Agent是大模型的进阶形态，它不仅能理解用户需求，还能自主规划和执行任务。
Agent不是更聪明，是更会做事。
9.2 Agent的核心能力
一个完整的Agent通常具备以下能力：
1. 感知能力
理解用户的意图和当前环境信息。
2. 规划能力
把复杂任务拆解成多个步骤，制定执行计划。
3. 执行能力
调用工具、访问外部API、操作文件等。
4. 反思能力
评估执行结果，调整策略，重新规划。
9.3 Agent vs 大模型的区别
| 对比维度 | 大模型 | Agent |
|---|---|---|
| 核心能力 | 文本生成 | 任务执行 |
| 主动性 | 被动响应 | 主动规划 |
| 工具使用 | 需要人工指定 | 自主决定调用 |
| 任务处理 | 单轮对话 | 多步骤任务流 |
| 记忆能力 | 有限（Context限制） | 可扩展（外部存储） |
| 错误处理 | 无 | 可重试、调整策略 |
9.4 Agent工作流程示例
场景：用户让Agent帮忙订一张去北京的机票
步骤1：理解意图
Agent分析用户需求："订去北京的机票"
步骤2：规划任务
Agent把任务拆解：
- 确定出发城市
- 确定出发日期
- 查询航班信息
- 选择合适航班
- 完成预订
步骤3：执行与交互
- Agent问："请问您从哪个城市出发？"
- 用户答："上海"
- Agent问："请问您希望什么日期出发？"
- 用户答："明天"
- Agent调用航班查询工具
- Agent展示查询结果
- Agent问："您选择哪个航班？"
- 用户选择后，Agent调用预订工具
步骤4：反馈与确认
Agent返回："已为您预订成功，订单号是..."
8.5 SubAgent（子智能体）
什么是SubAgent？
SubAgent是Agent的子智能体，用于处理Agent任务流程中的子任务。
Agent vs SubAgent的区别
| 对比维度 | Agent | SubAgent |
|---|---|---|
| 定位 | 主控智能体 | 辅助智能体 |
| 任务范围 | 完整任务 | 子任务 |
| 调用关系 | 被用户调用 | 被Agent调用 |
| 生命周期 | 长期存在 | 任务完成后销毁 |
| 决策权 | 高 | 低（由Agent分配） |
SubAgent使用场景
例子：用户让Agent写一个技术文档
- Agent接收到任务："写一份API文档"
- Agent规划：
- 调用SubAgent1：分析代码，提取API接口信息
- 调用SubAgent2：生成文档模板
- 调用SubAgent3：填充具体内容
- SubAgent1完成代码分析，返回接口列表
- SubAgent2生成文档结构
- SubAgent3根据接口信息填充文档内容
- Agent整合所有结果，返回最终文档
一句话总结：Agent = 能自己决定怎么做事的大模型
8.6 多Agent协同模式
为什么需要多Agent协同？
单个Agent虽然强大，但面对复杂任务时，往往需要"术业有专攻"。通过多个Agent协同工作，可以实现：
- 专业分工：每个Agent专注自己的领域
- 质量提升：通过互相检查、辩论，减少错误
- 效率优化：并行处理多个子任务
- 能力互补：不同Agent拥有不同的工具和知识
动态规划示例：
- 代码审查Agent：挂载代码分析工具，使用Claude模型（擅长代码理解）
- 数据分析Agent：挂载数据处理工具，使用GPT-4模型（擅长数学推理）
- 文档写作Agent：挂载文档模板工具，使用Gemini模型（擅长长文本生成）
三种主流协同模式
一、上下级协同（Hierarchical）——类比公司组织架构
结构：
工作方式：
- 中控Agent负责拆解任务、分配工作、整合结果
- 子Agent负责具体执行
- 可以多层嵌套，形成树状结构
适用场景：
- 大型项目管理
- 复杂系统的开发
- 需要严格流程控制的任务
实际案例 - 飞猪行程规划：
- 中控Agent：接收用户"规划一次北京到上海的旅行"需求
- SubAgent1：查询北京到上海的航班信息
- SubAgent2：搜索上海的酒店和景点
- SubAgent3：生成详细的行程安排
- 中控Agent：整合所有信息，输出完整行程单
实际案例 - 机票预订：
- 中控Agent：接收"预订明天北京到上海的机票"需求
- SubAgent1：查询航班信息（时间、价格、航空公司）
- SubAgent2：对比不同航班的性价比
- SubAgent3：执行预订操作
- 中控Agent：确认预订结果，返回订单号
二、师生式协同（Master-Disciple）——本质是"带思路"
结构：
工作方式：
- 专家Agent提供策略、方法论、评价标准
- 新手Agent按照专家的指导执行具体任务
- 专家可以实时反馈和调整
关键要素：
- 策划思路：如何拆解问题、制定策略
- 信息收集方法：从哪里获取信息、如何筛选有效信息
- 表达格式规范：输出应该是什么格式、包含哪些要素
- 评价标准：如何判断结果的好坏、如何改进
适用场景：
- 需要传承专业知识的任务
- 质量要求高的内容创作
- 需要标准化流程的工作
实际案例 - 单轮对话优化：
- 用户输入："帮我写一个产品介绍"
- 新手Agent：生成初步版本（可能不够专业）
- 专家Agent：提供反馈："需要突出产品的核心优势，增加数据支撑，使用更专业的术语"
- 新手Agent：根据反馈优化输出
- 专家Agent：继续指导："结构可以调整为：问题背景 → 产品解决方案 → 核心优势 → 客户案例"
- 新手Agent：按照新结构重新生成
- 最终输出：高质量的产品介绍
本质区别：上下级协同是主智能体严格拆解任务并分配，师生式协同则是通过讨论和反馈优化输出，更具互动性。
三、竞争式协同（Competitive / Debate）——让模型"互相杠"
结构：
工作方式：
- 多个Agent独立生成不同方案
- 裁判Agent对比分析各方案优劣
- 选择最优或融合多个方案
本质：多解 → 对比 → 选择最优
适用场景：
- 开放性问题（没有标准答案）
- 需要高质量输出的任务
- 容易"幻觉"的任务（需要互相验证）
- 创意类工作（需要多个视角）
实际案例 - 营销文案创作：
- 任务："为一款智能手表写营销文案"
- Agent1：强调性价比（价格优势、功能对比）
- Agent2：强调品质（材质、工艺、品牌背书）
- Agent3：强调创新（独特功能、技术突破）
- 裁判Agent：综合三个角度，生成最优文案
- 开头用创新点吸引注意力
- 中间用品质数据建立信任
- 结尾用性价比促成转化
为什么竞争式协同有效？
- 避免单一视角：不同Agent从不同角度思考，避免思维局限
- 互相验证：多个方案可以互相检查，减少幻觉和错误
- 激发创意：竞争机制激发Agent的创造力，产生更好的想法
- 质量提升：通过对比筛选，最终输出质量更高
应用场景总结
多智能体协作适用于复杂任务（如工程开发、项目上线），通过分工减轻单一智能体负担。
| 应用场景 | 推荐模式 | 理由 |
|---|---|---|
| 工程开发 | 上下级协同 | 需要严格的任务拆解和流程控制 |
| 项目上线 | 上下级协同 | 涉及多个环节，需要统一调度 |
| 代码审查 | 师生式协同 | 需要专家指导，逐步优化代码质量 |
| 内容创作 | 师生式协同 | 需要反复打磨，提升内容质量 |
| 方案设计 | 竞争式协同 | 需要多角度思考，选择最优方案 |
| 创意生成 | 竞争式协同 | 需要激发创意，避免思维固化 |
| 数据分析 | 混合模式 | 用上下级协同拆解任务，用竞争式协同验证结果 |
如何选择协同模式？
| 任务特点 | 推荐模式 |
|---|---|
| 复杂、需要严格流程 | 上下级协同 |
| 需要专业知识传承 | 师生式协同 |
| 开放性、创意类 | 竞争式协同 |
| 需要多角度验证 | 竞争式协同 |
| 大型项目管理 | 上下级协同 |
| 需要迭代优化 | 师生式协同 |
一句话总结：多Agent协同 = 让多个专业AI各司其职，通过分工、合作、竞争，共同完成复杂任务
十、思考题
Q1：Token和字符有什么区别？为什么大模型不直接处理字符？
- Token是大模型处理文本的最小单位，Token和字符不是一对一关系
- 一个Token可能对应一个词、多个字符，也可能一个字符对应多个Token
- 平均1个Token ≈ 1.5~2个汉字，或0.75个英文单词
- 不直接处理字符的原因：字符粒度太细，模型需要学习更多模式；Token粒度更符合语言单元，训练效率更高
Q2：Context Window越大越好吗？
- Context Window是大模型一次能处理的最大Token数量
- 它决定了模型能"记住"多少信息
- 影响模型的成本和性能
- 不同模型的Context Window大小不同（GPT-4：128K，Claude 3.1 Pro：100万）
- 不是越大越好：更大的Context意味着更高的计算成本，需要根据实际需求选择合适的模型
Q3：RAG和Fine-tuning有什么区别？什么时候用哪个？
- RAG：检索时动态注入知识，适合知识频繁更新的场景
- Fine-tuning：将知识嵌入模型参数，适合特定任务的优化
- RAG优势：知识可实时更新，成本低，不受Context Window限制
- Fine-tuning优势：模型对特定领域更熟悉，输出更稳定
- 两者可以结合使用：用Fine-tuning学习领域风格，用RAG获取最新知识
Q4：Agent和普通的大模型有什么本质区别？
- Agent是具备自主规划和执行能力的智能体
- 区别：
- 大模型：被动响应，只能生成文本
- Agent：主动规划，可以执行多步骤任务
- Agent的核心能力：感知、规划、执行、反思
- Agent可以自主决定何时调用工具、调用哪个工具
- Agent不是更聪明，是更会做事
Q5：Agent未来的发展方向是什么？
技术方向：
- 多模态能力：处理文本、图像、音频、视频
- 更强的规划能力：处理更复杂的任务链
- 自主学习：根据反馈优化自身行为
- 协作能力：多个Agent协同工作
应用方向：
- 垂直领域Agent：医疗、法律、金融等
- 个人化Agent：深度了解用户习惯和偏好
- 企业级Agent：处理复杂的业务流程
- 物理世界Agent：机器人、自动驾驶等
挑战：
- 安全性：防止Agent执行危险操作
- 可控性：确保Agent行为符合预期
- 成本：降低Agent运行成本
- 普适性：让更多普通人能使用Agent
十一、总结
核心概念回顾
| 概念 | 英文 | 定义 |
|---|---|---|
| 大语言模型 | LLM | 基于Transformer架构训练的大规模语言模型 |
| 词元 | Token | 大模型处理文本的最小单位 |
| 上下文 | Context | 大模型每次处理任务时接收的信息总和 |
| 上下文窗口 | Context Window | Context能容纳的最大Token数量 |
| 提示词 | Prompt | 大模型接收的具体问题或指令 |
| 检索增强生成 | RAG | 从大量文档中检索相关片段发给大模型的技术 |
| 工具 | Tool | 让大模型能够执行具体任务的函数 |
| 智能体 | Agent | 具备自主规划和执行能力的AI系统 |
| 子智能体 | SubAgent | 被Agent调用的辅助智能体 |
| 技能 | Skill | 针对特定任务的预配置能力包 |
| 模型上下文协议 | MCP | 连接大模型和外部数据源的标准化协议 |
十二、结语
AI技术日新月异，但核心概念始终如一。从最底层的LLM、Token，到中层的Context、Prompt、RAG，再到上层的Tool、Agent、Skill、MCP，这些概念构成了现代AI应用的技术栈。
希望这篇文章能帮助你建立扎实的AI知识体系。如果觉得有用，欢迎分享给更多需要的朋友！
注：本文内容基于当前主流AI技术整理，随着技术发展，部分概念可能会有更新。建议持续关注最新动态。
