LLM 技术体系
从LLM到Agent的完整AI技术栈解析，涵盖Transformer、Token、Context、Prompt Engineering、Function Calling、RAG、MCP、Agent等核心概念及其关系。
# 一、整体架构总览
AI 应用可以看成一套 从底层模型到上层智能体的技术栈：
┌─────────────────────────────┐
│ Application（AI 应用） │
├─────────────────────────────┤
│ Agent（智能体） │ ← 任务闭环：规划 → 执行 → 反思
├─────────────────────────────┤
│ Agent Skills（能力模块） │ ← Skill = Prompt + Tool + Workflow
├─────────────────────────────┤
│ Tools / MCP（工具层） │ ← 扩展 LLM 的行动能力
├─────────────────────────────┤
│ RAG / Memory（知识层） │ ← 扩展 LLM 的知识边界
├─────────────────────────────┤
│ Prompt（提示词） │ ← 控制 LLM 的行为方向
├─────────────────────────────┤
│ Context（上下文） │ ← 模型看到的全部信息
├─────────────────────────────┤
│ Token（文本单位） │ ← 模型处理的最小粒度
├─────────────────────────────┤
│ LLM / Transformer（模型） │ ← 核心计算引擎
└─────────────────────────────┘
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
LLM 负责理解语言，Prompt 负责控制行为，Tool 负责扩展能力，RAG 负责补充知识，Agent 负责完成任务。
# 二、LLM（Large Language Model）
LLM 是 AI 系统的 核心计算引擎，代表模型包括 OpenAI GPT 系列、Anthropic Claude 系列、Google Gemini 系列、Meta LLaMA 系列，以及国产的 DeepSeek、Qwen（通义千问）等。
# 2.1 本质
LLM 的本质是：基于已有文本预测下一个 Token 的概率分布。
数学形式：
P(xₜ | x₁, x₂, ..., xₜ₋₁)
给定前面所有 Token，计算下一个 Token 出现的概率。模型每次只生成一个 Token，然后将其加入输入序列，循环预测直到生成结束标志。
例如：
- 输入：
The capital of France is - 模型预测概率最高的 Token：
Paris
# 2.2 Transformer 架构
几乎所有主流 LLM 都基于 Transformer 架构（2017 年 Google 提出）。Transformer 的核心创新是 Self-Attention（自注意力）机制，让模型在处理每个 Token 时能够"关注"到输入序列中所有其他 Token 的信息。
核心组件：
| 组件 | 作用 |
|---|---|
| Self-Attention | 计算序列中每个 Token 对其他 Token 的关注权重，捕捉长距离依赖 |
| Multi-Head Attention | 多个注意力头并行工作，从不同角度理解文本关系 |
| Feed-Forward Network | 对 Attention 输出做非线性变换，增强模型表达能力 |
| Positional Encoding | 为 Token 注入位置信息（Transformer 本身不感知顺序） |
| Layer Normalization | 稳定训练过程，加速收敛 |
直观理解 Self-Attention：
输入句子："小明 昨天 在 北京 吃了 烤鸭"
当模型处理 "吃了" 这个词时：
→ 关注 "小明" （谁吃的？） 权重: 0.3
→ 关注 "北京" （在哪吃的？） 权重: 0.2
→ 关注 "烤鸭" （吃了什么？） 权重: 0.4
→ 关注 "昨天" （什么时候？） 权重: 0.1
2
3
4
5
6
7
# 2.3 模型训练流程
LLM 的训练通常分为三个阶段：
Pre-training（预训练）→ SFT（监督微调）→ RLHF / DPO（对齐）
| 阶段 | 数据 | 目标 | 成果 |
|---|---|---|---|
| Pre-training | 互联网海量文本（万亿 Token） | 学习语言模式和世界知识 | Base Model（基础模型） |
| SFT | 人工标注的指令-回答对 | 学习遵循指令、对话格式 | Chat Model（对话模型） |
| RLHF / DPO | 人类偏好数据（哪个回答更好） | 对齐人类价值观，减少有害输出 | Aligned Model（对齐模型） |
- Pre-training 让模型"博览群书"获得知识；
- SFT 让模型学会"听话"按指令行动；
- RLHF（Reinforcement Learning from Human Feedback）让模型生成人类偏好的内容。DPO（Direct Preference Optimization）是 RLHF 的简化替代方案。
# 2.4 关键特点
| 特点 | 说明 |
|---|---|
| 无持久记忆 | 每次推理独立，不会自动记住之前的对话 |
| 基于概率生成 | 输出具有随机性，同一输入可能产生不同输出 |
| 依赖上下文 | 所有"理解"都来自当前输入的 Context |
| 知识截止 | 训练数据有时间截止点，无法获取实时信息 |
| 幻觉问题 | 可能生成看似合理但事实错误的内容 |
# 2.5 推理模型（Reasoning Model）
2024-2025 年出现的重要演进方向：模型在回答前进行 显式的逐步推理，而非直接输出答案。
代表模型：OpenAI o1/o3 系列、DeepSeek-R1、Claude 的 Extended Thinking。
普通模型： 问题 → 直接回答
推理模型： 问题 → 思维链（Chain of Thought）→ 回答
2
推理模型在数学、编程、逻辑等复杂任务上表现显著优于传统模型，但推理过程消耗更多 Token，响应时间更长。
# 三、Token（模型处理单位）
Token 是 LLM 处理文本的 最小单位，是连接人类语言和模型计算的桥梁。
# 3.1 Tokenization 示例
英文：
"Hello world" → ["Hello", " world"] # 2 tokens
"unhappiness" → ["un", "happiness"] # 2 tokens（子词拆分）
2
中文：
"你好世界" → ["你", "好", "世界"] # 3 tokens
"人工智能" → ["人工", "智能"] # 2 tokens
2
代码：
"print('hi')" → ["print", "('", "hi", "')"] # 4 tokens
# 3.2 Tokenization 算法
模型使用的分词算法决定了 Token 的粒度：
| 算法 | 原理 | 代表模型 |
|---|---|---|
| BPE (Byte-Pair Encoding) | 从字符开始，反复合并最频繁的相邻字符对 | GPT 系列 |
| WordPiece | 基于似然最大化选择合并对 | BERT |
| SentencePiece | 直接在原始文本上训练，支持多语言 | LLaMA、Qwen |
BPE 算法直观理解：
初始词表：所有单字符 [a, b, c, ..., z]
第 1 轮：统计发现 "t" + "h" 最频繁 → 合并为 "th"
第 2 轮：统计发现 "th" + "e" 最频繁 → 合并为 "the"
第 3 轮：统计发现 "i" + "n" 最频繁 → 合并为 "in"
...
反复迭代直到词表达到预设大小（如 50K、100K）
2
3
4
5
6
7
# 3.3 Token 与成本
Token 直接决定三个维度的成本：
| 维度 | 影响 |
|---|---|
| 推理成本 | Token 越多，GPU 计算量越大，延迟越高 |
| 上下文容量 | Token 数量限制了模型能"看到"的信息量 |
| API 费用 | 商业模型按 Input/Output Token 分别计费 |
经验值：1 Token ≈ 3~4 个英文字符，1 个中文字约 1~2 个 Token。
# 四、Context（上下文）
Context 是 模型在单次推理中能看到的全部信息，是模型"理解力"的唯一来源。
# 4.1 基本概念
User: 我叫小明
User: 我是谁？
→ 模型回答：你叫小明（因为 Context = [我叫小明, 我是谁？]）
2
3
如果删除第一句，只输入 我是谁？，模型无法回答 —— 因为 Context 中没有相关信息。
# 4.2 Context 的组成
一次完整的 API 调用，Context 通常包含：
┌────────────────────────────────┐
│ System Prompt（角色定义、规则） │
├────────────────────────────────┤
│ RAG 检索内容（相关知识片段） │
├────────────────────────────────┤
│ Conversation History（对话历史）│
├────────────────────────────────┤
│ User Message（当前用户输入） │
├────────────────────────────────┤
│ Tool Results（工具返回结果） │
└────────────────────────────────┘
2
3
4
5
6
7
8
9
10
11
# 4.3 Context Window（上下文窗口）
Context Window 指 模型一次最多能处理多少 Token。不同模型差异很大：
| 模型 | Context Window | 发布时间 |
|---|---|---|
| GPT-3.5 | 4K / 16K | 2023 |
| GPT-4 | 8K / 32K / 128K | 2023-2024 |
| GPT-4o | 128K | 2024 |
| Claude 3.5 Sonnet | 200K | 2024 |
| Claude 4 Sonnet | 200K | 2025 |
| DeepSeek-V3 | 128K | 2025 |
| Gemini 2.0 | 1M / 2M | 2025 |
| Qwen3 | 128K | 2025 |
Context Window 正在快速增长，但更大的窗口并不意味着可以无脑堆信息 —— "大海捞针"问题（模型在长上下文中间遗漏关键信息）仍然存在。
# 4.4 Context 管理策略
当对话超过 Context Window 时，需要主动管理：
| 策略 | 原理 | 适用场景 |
|---|---|---|
| 对话裁剪 | 删除较早的对话轮次 | 简单多轮对话 |
| 摘要压缩 | 让 LLM 总结历史对话为摘要 | 长对话场景 |
| RAG | 只检索相关内容注入 Context | 知识密集型任务 |
| Memory 系统 | 持久化存储关键信息 | 跨会话记忆需求 |
| 滑动窗口 | 保留最近 N 轮 + 系统摘要 | 实时对话助手 |
# 五、Prompt（提示词）
Prompt 是 给 LLM 的输入指令文本，直接决定模型的输出质量。同一个模型，不同的 Prompt 可以产生天差地别的结果。
# 5.1 Prompt 的角色分类
| 角色 | 作用 | 示例 |
|---|---|---|
| System Prompt | 定义 AI 的身份、规则和约束 | You are a senior Go developer. Always write idiomatic Go code. |
| User Prompt | 用户的实际问题或指令 | 帮我写一个 HTTP 中间件 |
| Assistant Prompt | 模型之前的回复（对话历史） | 上一轮的回答内容 |
完整输入结构：
[System] 你是一个专业的软件架构师，使用中文回答。
[User] 如何设计一个高可用的消息队列？
[Assistant] 高可用消息队列需要考虑以下几点...
[User] 能详细说说数据持久化方案吗？
2
3
4
# 5.2 Prompt Engineering 核心技巧
| 技巧 | 说明 | 示例 |
|---|---|---|
| 角色设定 | 为模型指定专业身份 | 你是一位有 10 年经验的 Kubernetes 运维专家 |
| Few-shot | 提供示例引导输出格式 | 给 2-3 个输入输出样例 |
| Chain of Thought | 要求模型逐步推理 | 请一步一步分析这个问题 |
| 输出约束 | 限定输出格式 | 以 JSON 格式输出，包含 name 和 reason 字段 |
| 分隔符 | 用标记区分不同部分 | 使用 ---、""" 或 XML 标签分隔指令与内容 |
Few-shot 示例：
将以下技术术语翻译为中文，并给出简短解释：
Input: Container
Output: 容器 — 轻量级的操作系统级虚拟化技术，用于打包和运行应用
Input: Orchestration
Output: 编排 — 自动化管理多个容器的部署、扩缩和网络配置
Input: Service Mesh
Output:
2
3
4
5
6
7
8
9
10
# 六、Embedding 与 RAG
# 6.1 Embedding（向量嵌入）
Embedding 是将文本转换为 高维数字向量 的过程，使得语义相近的文本在向量空间中距离更近。
"Kubernetes" → [0.12, -0.45, 0.78, ..., 0.33] # 1536 维向量
"K8s 容器编排" → [0.11, -0.43, 0.76, ..., 0.31] # 语义相近，向量接近
"今天天气不错" → [0.89, 0.12, -0.56, ..., -0.22] # 语义无关，向量远离
2
3
Embedding 的核心价值：将"语义相似度"转化为"向量距离计算"，使得计算机可以量化文本之间的关系。
# 6.2 RAG（Retrieval-Augmented Generation）
RAG（检索增强生成）是解决 LLM 知识截止 和 幻觉问题 的关键技术。核心思想：先检索相关知识，再让 LLM 基于检索结果生成回答。
┌──────────────────────────────────────────┐
│ RAG 工作流程 │
│ │
│ 用户提问 │
│ ↓ │
│ Query Embedding（问题向量化） │
│ ↓ │
│ 向量检索（从知识库中找到最相关的文档片段） │
│ ↓ │
│ Context 组装（检索结果 + 用户问题） │
│ ↓ │
│ LLM 生成回答（基于检索到的上下文） │
└──────────────────────────────────────────┘
2
3
4
5
6
7
8
9
10
11
12
13
示例 — 企业知识问答系统：
用户：我们公司的年假政策是什么？
1. 向量化查询："年假政策"
2. 从企业文档向量库中检索 → 匹配到《员工手册 v3.2》第 12 章
3. 将检索到的文档片段注入 Context
4. LLM 基于原文生成准确回答（而非凭记忆编造）
2
3
4
5
6
# 6.3 RAG 的技术栈
| 组件 | 作用 | 代表工具 |
|---|---|---|
| 文档解析 | 将 PDF/Word/网页等转为纯文本 | LangChain Loaders、Unstructured |
| 文本切分 | 将长文档切分为合适大小的片段 | RecursiveCharacterTextSplitter |
| Embedding 模型 | 将文本片段转为向量 | OpenAI Embedding、BGE、Jina |
| 向量数据库 | 存储和检索向量 | Milvus、Pinecone、Chroma、Weaviate |
| 检索策略 | 优化检索准确率 | 混合检索、重排序（Reranker） |
# 七、Tools 与 Function Calling
# 7.1 为什么需要 Tools
LLM 本身只能处理文本，无法直接执行现实操作。Tools 赋予 LLM 感知和行动的能力：
| LLM 局限 | Tools 解决方案 |
|---|---|
| 无法获取实时信息 | Web Search、News API |
| 无法访问私有数据 | Database Query、File Reader |
| 无法执行计算 | Code Interpreter、Calculator |
| 无法操作外部系统 | REST API、Shell Command |
# 7.2 Function Calling（函数调用）
Function Calling 是 LLM 调用工具的 标准机制，由 OpenAI 在 GPT-4 中率先引入，现已成为行业标准。
工作流程：
1. 开发者定义可用工具（函数签名 + 描述）
2. 用户提问
3. LLM 判断是否需要调用工具
4. 若需要，LLM 输出结构化的函数调用请求（JSON）
5. 应用层执行函数，将结果返回给 LLM
6. LLM 基于结果生成最终回答
2
3
4
5
6
示例：
// 1. 定义工具
{
"name": "get_weather",
"description": "获取指定城市的当前天气",
"parameters": {
"type": "object",
"properties": {
"city": { "type": "string", "description": "城市名称" }
},
"required": ["city"]
}
}
// 2. 用户输入："东京现在多少度？"
// 3. LLM 输出工具调用
{
"function_call": {
"name": "get_weather",
"arguments": "{\"city\": \"Tokyo\"}"
}
}
// 4. 应用执行函数，返回结果
{ "temperature": 22, "condition": "晴" }
// 5. LLM 生成回答："东京现在 22°C，天气晴朗。"
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 7.3 Tool Use vs Function Calling
不同厂商的术语略有不同，但核心概念一致：
| 厂商 | 术语 | 本质 |
|---|---|---|
| OpenAI | Function Calling | LLM 输出结构化工具调用 |
| Anthropic | Tool Use | LLM 输出结构化工具调用 |
| Function Calling | LLM 输出结构化工具调用 |
# 八、MCP（Model Context Protocol）
MCP 是 AI 调用工具的 开放标准协议，由 Anthropic 于 2024 年提出，目标是统一 LLM 与外部工具之间的通信方式，类似于 AI 世界的 HTTP。
# 8.1 为什么需要 MCP
在 MCP 之前，每个 AI 应用接入外部工具都需要写一套自定义集成代码。MCP 将工具接入标准化：
MCP 之前： MCP 之后：
App1 ←自定义→ GitHub App1 ←─┐
App2 ←自定义→ GitHub App2 ←─┤── MCP ──→ GitHub MCP Server
App3 ←自定义→ GitHub App3 ←─┘
每个 App 各写一套 所有 App 使用统一协议
2
3
4
5
6
# 8.2 核心架构
AI Application
↓
MCP Client（内置于 AI 应用中）
↓（标准 MCP 协议 — JSON-RPC over stdio/SSE）
MCP Server（独立进程，封装具体工具）
↓
外部系统（GitHub、Slack、Database、File System...）
2
3
4
5
6
7
MCP Server 对外暴露三类能力：
| 能力 | 说明 | 示例 |
|---|---|---|
| Tools | 可执行的操作 | create_issue、query_database |
| Resources | 可读取的数据源 | file://project/README.md |
| Prompts | 预定义的 Prompt 模板 | 代码审查模板、SQL 生成模板 |
# 8.3 类比
| 技术 | 标准化对象 | MCP 对应 |
|---|---|---|
| HTTP | Web 客户端与服务器通信 | AI 应用与工具通信 |
| SQL | 应用与数据库查询 | AI 与外部系统操作 |
| USB | 操作系统与外设 | AI 平台与工具插件 |
# 8.4 MCP 生态
MCP 已获得广泛支持：
- AI 平台：Claude Code、Cursor、Windsurf、Continue 等
- 官方 Server：GitHub、Slack、PostgreSQL、Filesystem、Puppeteer 等
- 社区 Server：Docker、Kubernetes、Jira、Notion 等
# 九、Agent（智能体）
Agent 是 具备自主规划和任务执行能力的 AI 系统，是从"问答 AI"到"做事 AI"的关键跃迁。
# 9.1 Agent vs 普通 LLM
普通 LLM： 输入 → 输出（一次性回答）
Agent： 理解任务 → 制定计划 → 循环执行（调用工具 → 观察结果 → 调整策略）→ 输出结果
2
# 9.2 Agent 核心循环
大多数 Agent 框架遵循 ReAct（Reasoning + Acting）模式：
┌→ Think（推理）：分析当前状态，决定下一步
│ ↓
│ Act（行动）：调用工具执行操作
│ ↓
│ Observe（观察）：获取执行结果
│ ↓
│ Reflect（反思）：评估是否完成目标
│ ↓
└── 未完成 → 回到 Think
已完成 → 输出最终结果
2
3
4
5
6
7
8
9
10
# 9.3 Agent 的核心能力
| 能力 | 说明 |
|---|---|
| 任务规划 | 将复杂任务拆解为可执行的步骤 |
| 工具使用 | 根据需要选择和调用合适的工具 |
| 记忆管理 | 在任务执行过程中维护上下文状态 |
| 错误恢复 | 遇到失败时调整策略重试 |
| 自主决策 | 不需要人工逐步指导，自行完成任务 |
# 9.4 实际示例
任务：帮我排查 Kubernetes Pod CrashLoopBackOff 问题
Agent 执行过程：
1. [Think] 需要先查看 Pod 状态和事件
2. [Act] 执行 kubectl describe pod xxx
3. [Observe] 发现 OOMKilled，内存限制 256Mi
4. [Think] 需要查看实际内存使用
5. [Act] 执行 kubectl top pod xxx
6. [Observe] 实际使用 380Mi，超出限制
7. [Think] 需要调整内存限制
8. [Act] 修改 Deployment 的 resources.limits.memory 为 512Mi
9. [Observe] Pod 重启成功，状态变为 Running
10.[Result] 报告：Pod 因 OOM 崩溃，已将内存限制从 256Mi 调整为 512Mi
2
3
4
5
6
7
8
9
10
11
12
# 9.5 多 Agent 协作
复杂任务可以由多个专业 Agent 协同完成：
Orchestrator Agent（编排者）
├─ Research Agent —— 信息收集与分析
├─ Coding Agent —— 代码生成与调试
├─ Review Agent —— 代码审查与质量检查
└─ Deploy Agent —— 构建与部署
2
3
4
5
每个 Agent 拥有独立的上下文和工具集，专注于自己的领域，通过编排者协调工作。
# 十、Agent Skill（能力模块）
Agent Skill 是 Agent 的可复用能力插件，将特定领域的知识和工作流封装为标准化模块。
# 10.1 Skill 的本质
Skill = Prompt（领域知识）+ Tool（执行工具）+ Workflow（标准流程）
# 10.2 Skill 示例
Agent
├─ Deploy Skill —— 知道如何构建和部署项目
├─ Code Review Skill —— 知道代码审查的标准和流程
├─ Database Skill —— 知道如何查询和管理数据库
├─ Search Skill —— 知道如何高效检索信息
└─ Debug Skill —— 知道问题排查的方法论
2
3
4
5
6
# 10.3 Skill vs Tool
| 维度 | Tool | Skill |
|---|---|---|
| 粒度 | 单个操作（调一个 API） | 完整流程（多步骤任务） |
| 包含知识 | 否（只有接口定义） | 是（包含领域 Prompt 和最佳实践） |
| 可组合性 | 被 Skill 调用 | 组合多个 Tool |
| 示例 | search_web(query) | "先搜索 → 筛选 → 总结 → 验证" 的完整研究流程 |
# 十一、AI 系统类比（工程理解）
将 AI 技术栈类比传统计算机架构，有助于建立直觉理解：
| AI 概念 | 计算机类比 | 代表案例 |
|---|---|---|
| LLM | CPU | GPT-4o、Claude 4、DeepSeek-V3、Qwen3 |
| Token | CPU 指令 | BPE、SentencePiece 分词 |
| Context | 内存 | 对话历史、RAG 检索内容、System Prompt |
| Context Window | 内存容量 | 128K / 200K / 1M tokens |
| Prompt | 程序代码 | Prompt Template、Prompt Engineering |
| Embedding | 数据编码 | 文本向量化，语义检索 |
| RAG | 硬盘读取 | 将外部知识加载到"内存"中 |
| Tool | 外部设备 | Search API、Database、Code Interpreter |
| Function Calling | 系统调用 | LLM 请求执行外部函数 |
| MCP | 设备驱动协议 | 标准化 AI 与工具的通信 |
| Agent | 操作系统 | 调度资源，管理任务生命周期 |
| Skill | 应用程序 | 封装特定功能的可复用模块 |
LLM ≠ AI 应用，正如 CPU ≠ 计算机。LLM 只是 AI 系统的计算核心，完整的 AI 应用需要上下文、工具、知识库和 Agent 系统的配合。
# 十二、AI 系统核心公式
AI Application = LLM + Context + Prompt + RAG + Tools + Agent
各层的核心职责：
| 层 | 核心问题 |
|---|---|
| LLM | 如何理解和生成语言？ |
| Token | 如何将文本转化为模型可处理的单位？ |
| Context | 模型能看到什么信息？ |
| Prompt | 如何控制模型的行为？ |
| RAG | 如何让模型获取它不知道的知识？ |
| Tools / MCP | 如何让模型执行现实世界的操作？ |
| Agent | 如何让模型自主完成复杂任务？ |
# 十三、AI 架构演进趋势
# 1. Agent 原生化
从"人驱动 AI"走向"AI 自主执行"。Coding Agent（如 Claude Code、Cursor Agent）已经能够自主完成代码编写、测试、调试的完整闭环。
# 2. 工具协议标准化
MCP 正在成为 AI 工具调用的事实标准，推动形成类似 Web 生态中 HTTP 的统一协议层。
# 3. 多模态融合
模型不再局限于文本，同时处理文本、图像、音频、视频：
文本 ──┐
图像 ──┤── 多模态 LLM ──→ 统一理解和生成
音频 ──┤
视频 ──┘
2
3
4
代表模型：GPT-4o（文本 + 图像 + 音频）、Gemini 2.0（原生多模态）。
# 4. 多 Agent 协作系统
多个专业 Agent 组成团队，协同完成复杂项目：
| Agent 角色 | 职责 |
|---|---|
| Research Agent | 信息收集、技术调研、方案对比 |
| Coding Agent | 代码生成、重构、Bug 修复 |
| Review Agent | 代码审查、安全检查、质量把关 |
| Ops Agent | 构建、部署、监控、运维 |
# 5. 端侧推理
小参数模型（如 Qwen3-0.6B、Phi-4-mini、Gemma 3）部署到手机、PC 等终端设备，实现隐私保护和低延迟推理。