AI 底层架构
学习 AI 应用开发时，经常会遇到 LLM、Transformer、Token、Prompt、RAG、MCP、Agent、Skill 等概念。这些技术分别解决什么问题？它们之间又有什么关系？
从基础大模型到能够执行任务的 AI Agent，一个完整的 AI 应用通常涉及模型推理、上下文管理、工具调用、任务编排和业务应用等多个部分。
例如，让 AI 完成"读取 Excel 销售数据，分析增长趋势并生成报告"，背后可能涉及以下过程：
- 大语言模型理解用户的要求。
- 系统结合上下文和相关资料确定任务范围。
- Agent 判断需要读取文件和执行数据分析。
- 通过工具运行 Python 代码，处理数据并生成图表。
- 将分析结果整理成报告，返回给用户。
为了便于理解，我们可以将相关技术按照作用划分为五个层级。
说明：下图所示的五层架构是一种教学上的功能划分，并不是所有 AI 系统都必须遵循的统一技术标准。不同层级之间可以相互配合，某些组件也可以按实际需求省略。
AI 系统的五个层级
| 层级 | 核心技术 | 主要作用 |
|---|---|---|
| 基础模型层 | LLM、Token、Transformer、Attention | 处理输入信息，进行模型推理和内容生成。 |
| 上下文层 | Prompt、Context Window、Memory、RAG | 组织模型输入，结合对话历史和外部知识。 |
| 工具层 | Tool Calling、API、MCP、Database | 连接外部程序、数据源和服务，执行具体操作。 |
| 智能体层 | Agent、Planning、Agent Loop | 根据目标选择操作，组织多步骤任务并处理反馈。 |
| 应用层 | Skill、Workflow、Automation | 将模型和工具能力组合成实际产品与业务流程。 |
这五层可以帮助我们理解 AI 应用从底层能力到实际落地的过程。
基础模型层负责提供推理与生成能力；上下文层为模型补充任务信息；工具层负责与外部系统交互；智能体层组织任务执行；应用层则将这些能力用于具体业务。
接下来分别介绍各个层级。
1、基础模型层（Model）
基础模型层是 AI 应用的重要组成部分，负责对输入进行计算，并生成文本或其他形式的输出。
在大语言模型应用中，常见的基础概念包括 Token、Transformer 和注意力机制。
Token
Token 是模型处理文本时使用的基本单位。
模型通常不会直接将一整段文本作为不可分割的整体处理，而是先经过 Tokenizer（分词器）转换为 Token 序列，再映射为模型可以计算的数字表示。
一个 Token 可能对应一个字符、一个词的一部分、一个完整单词或者标点符号，具体取决于模型使用的分词器。
例如：
用户输入： Hello, AI! 分词后可能得到： ["Hello", ",", " AI", "!"]
以上仅为示意，不代表所有模型的实际分词结果。不同模型的 Tokenizer 可能产生不同的 Token 序列。
Token 数量会影响上下文占用、模型调用成本以及输入输出长度限制。
Transformer
Transformer 是现代大语言模型中广泛使用的神经网络架构。
它通过注意力机制等结构，对输入序列中的信息进行建模。
例如，在句子"程序员正在使用 Python 编写代码"中，模型需要结合上下文，理解 Python 指的是编程语言，而不是其他含义。
Transformer 的重要特点之一，是能够利用注意力机制处理序列中不同位置之间的信息关系。
Attention（注意力机制）
注意力机制用于计算序列中不同位置的信息关联程度，使模型能够结合相关上下文进行处理。
自注意力机制（Self-Attention）是 Transformer 的重要组成部分。
需要注意，注意力机制只是模型内部计算的一部分，并不等同于模型已经具有人类式的理解或推理过程。
LLM（大语言模型）
LLM（Large Language Model）是通过大规模数据训练得到的语言模型。
许多生成式 LLM 在推理时，根据已有输入和已生成的 Token，预测后续 Token 的概率分布，并逐步生成内容。
常见的模型包括 GPT、Claude、DeepSeek、Qwen 等系列模型。
基础模型可以用于：
- 自然语言问答与文本生成。
- 代码生成、解释和修改。
- 文本分类、信息提取和内容总结。
- 根据上下文进行推理和生成结构化结果。
不过，模型本身不一定具备访问实时信息、读取本地文件或者操作外部软件的能力。这些功能通常需要由应用提供相关工具。
2、上下文层（Context）
上下文层主要解决一个问题：模型在处理当前任务时，应该获得哪些信息？
模型的输出不仅受到自身能力影响，也与输入指令、会话历史和参考资料有关。
常见的上下文相关技术包括 Prompt、Context Window、Memory 和 RAG。
Prompt
Prompt 是提供给模型的输入内容，通常用于描述任务、指定要求以及提供必要的信息。
例如：
请分析下面的销售数据。 要求： 1. 计算每个月的销售额。 2. 找出销售额最高的月份。 3. 使用表格输出结果。 4. 不要编造缺失数据。
Prompt 可以包含任务指令、输入数据、示例和输出要求等内容。
在实际应用中，模型请求还可能包含系统指令、开发者指令以及多轮对话消息，不同消息具有不同的用途和优先级。
Context Window（上下文窗口）
上下文窗口是模型一次推理能够处理的上下文范围，通常以 Token 数量衡量。
上下文可能包含：
- 系统指令和用户输入。
- 历史对话消息。
- 检索得到的参考资料。
- 工具调用结果。
- 当前任务需要处理的数据。
例如，一个模型支持较长的上下文窗口，可以一次处理更多文档内容，但这并不意味着模型能够永久记住这些信息。
当上下文过长时，应用可能需要进行摘要、截取或检索，以保留与当前任务最相关的内容。
Memory（记忆）
Memory 用于在 AI 应用中保存和使用历史信息。
通常可以分为：
- 短期记忆：保存当前会话、任务状态和中间执行结果。
- 长期记忆：保存需要跨会话使用的信息，例如用户偏好、项目资料和历史任务记录。
长期记忆通常由数据库、文件系统或其他外部存储实现，并不是模型天然具备的永久记忆能力。
例如，AI 编程助手可以读取之前保存的项目说明，了解项目使用的编程语言、目录结构和编码规范。
RAG（检索增强生成）
RAG（Retrieval-Augmented Generation）是一种结合外部信息检索与模型生成的技术。
它主要用于让模型在回答问题之前，先查询相关资料，再结合检索结果生成内容。
典型流程如下：
用户提出问题
↓
检索知识库
↓
获取相关资料
↓
将资料加入模型上下文
↓
模型生成回答
例如，企业可以建立内部文档知识库。当员工询问公司的报销制度时，系统先检索相关制度文档，再由模型根据文档内容进行回答。
RAG 可以减少模型因缺少专业资料而产生的错误，但无法保证所有回答都准确。检索质量、资料时效性和模型对资料的理解都会影响最终结果。
需要注意，RAG 是信息检索和生成相结合的方法，并不等同于长期记忆。
3、能力扩展层（Tools）
能力扩展层负责让 AI 应用访问外部工具和数据源。
例如，模型可以生成一段 Python 代码，但要真正运行代码，就需要连接代码执行环境。
类似地，读取数据库、查询实时天气、发送邮件等操作，也需要通过工具或外部服务完成。
Tool Calling（工具调用）
Tool Calling 是模型使用外部工具的一种常见机制。
开发者向模型提供工具名称、功能说明和参数定义。模型根据当前任务，判断是否需要调用工具，并生成相应的调用请求。
例如，定义一个天气查询工具：
{
"name": "get_weather",
"description": "查询指定城市的天气",
"parameters": {
"city": "string"
}
}
当用户要求查询北京天气时，模型可以生成包含城市参数的工具调用请求。
应用程序负责验证参数、执行实际的天气查询，然后将结果返回给模型。
因此，Tool Calling 并不是模型直接执行代码，而是模型与外部执行系统之间的一种协作机制。
MCP（模型上下文协议）
MCP（Model Context Protocol）是一种开放协议，用于标准化 AI 应用与外部工具、资源和服务之间的连接方式。
通过 MCP，开发者可以将文件系统、数据库、搜索服务等能力以统一的协议接口提供给支持 MCP 的应用。
MCP 采用客户端与服务器协作的架构，主要包含以下角色：
- MCP Host：承载 AI 应用，负责协调连接与交互。
- MCP Client：在 Host 中建立和维护与 MCP Server 的连接。
- MCP Server：向客户端提供工具、资源或提示模板等能力。
例如，一个数据库 MCP Server 可以向 AI 应用提供数据库查询工具，使 Agent 能够通过受控接口查询业务数据。
注意：MCP 不是 Tool Calling 的替代品，两者解决的问题不同。
- Tool Calling：侧重模型如何选择工具并生成调用参数。
- MCP：侧重外部工具和数据能力如何以标准化方式提供给 AI 应用。
开发者也可以直接通过普通 Python 函数或 HTTP API 实现工具调用，并不一定需要使用 MCP。
API 与 Database
API 是应用程序之间进行通信的接口，数据库则用于保存和查询数据。
它们可以作为 AI 应用连接外部系统的基础能力。
例如：
- 调用天气 API，获取实时天气或天气预报。
- 查询 MySQL、PostgreSQL 等数据库，获取业务数据。
- 通过文件 API 读取和修改文档。
- 调用第三方服务，完成邮件发送或日程管理。
工具调用需要遵守权限限制。涉及修改数据、发送消息、删除文件等操作时，应根据任务风险设置相应的确认和审核机制。
4、智能体层（Agent）
智能体层负责围绕用户目标组织任务执行。
与单次模型问答相比，Agent 可以根据当前任务状态选择工具、获取执行结果，并继续决定下一步操作。
一个典型的 Agent 通常涉及以下能力：
- 目标理解：识别用户希望完成的任务。
- 任务规划：将复杂任务拆分为可执行步骤。
- 工具选择：根据任务需求选择合适的工具。
- 执行反馈：读取工具结果，判断操作是否成功。
- 任务控制：确定继续执行、请求用户确认或终止任务。
Agent Loop
Agent Loop 是组织模型决策与工具执行的一种常见运行机制。
基本流程如下：
接收任务
↓
分析任务与当前状态
↓
选择下一步操作
↓
调用工具
↓
获取工具结果
↓
判断任务是否完成
├── 否：继续执行
└── 是：输出结果
例如，用户要求 Agent 修复一段代码中的错误。
Agent 可能先读取相关文件，再分析错误原因，修改代码并执行测试。如果测试失败，则根据错误信息继续修改。
需要注意，Agent 不一定会在开始执行前生成完整计划，也可能采用边执行边决策的方式。
另外，Agent Loop 应设置最大执行步数、调用预算、超时限制和错误处理机制，避免任务无限循环。
Planning、Explore 与 Act
这些术语通常用于描述 Agent 在任务执行中的不同活动：
| 概念 | 作用 | 示例 |
|---|---|---|
| Explore（探索） | 收集信息，了解当前环境 | 读取项目文件、搜索资料 |
| Plan（规划） | 制定执行步骤和任务安排 | 确定修改哪些代码文件 |
| Act（行动） | 执行具体操作 | 修改代码、运行测试 |
这三个概念并不代表所有 Agent 都必须严格按照 Explore、Plan、Act 的固定顺序运行。
实际执行过程中，Agent 可能多次探索、调整计划和调用工具。
5、应用层（Applications）
应用层负责将模型、工具和 Agent 能力组合成面向用户的实际产品。
常见应用包括 AI 编程助手、文档处理工具、数据分析系统和企业业务自动化平台等。
Agent Skill
Skill 通常指可以复用的任务能力或操作规范。
在一些 Agent 系统中，Skill 可以由说明文件、操作步骤、脚本和相关资源组成，用于指导 Agent 完成特定类型的任务。
例如，一个用于处理 PDF 的 Skill，可能包含：
- PDF 文本提取与分析的操作说明。
- 相关 Python 脚本。
- 文件转换和输出规范。
- 常见错误及处理建议。
需要注意，Skill 并不是所有 Agent 框架都采用的统一技术标准。不同产品对于 Skill 的定义和加载方式可能存在差异。
Workflow（工作流）
Workflow 是将多个任务步骤按照一定规则组织起来的执行流程。
例如，一个自动生成周报的工作流：
读取业务数据
↓
统计关键指标
↓
生成数据图表
↓
整理周报内容
↓
保存报告
工作流可以是固定步骤，也可以在某些节点调用 Agent，根据实际情况决定下一步操作。
因此，Workflow 与 Agent 并不是完全对立的关系。实际应用中，两者经常结合使用。
Automation（自动化）
Automation 强调根据预设条件、事件或时间计划自动执行任务。
例如：
- 每天上午自动生成销售日报。
- 收到新订单后自动整理订单信息。
- 检测到任务失败时发送通知。
- 定期读取数据并更新业务报表。
自动化不一定需要大语言模型。传统程序同样可以实现定时任务、事件触发和固定流程。
当自动化系统结合 Agent 后，可以处理更多需要理解自然语言、分析非结构化数据或动态选择工具的任务。
核心名词对照
下面整理了 AI 应用开发中常见的技术术语，方便快速查阅。
| 术语 | 中文名称 | 主要作用 |
|---|---|---|
| LLM | 大语言模型 | 进行语言建模、推理与内容生成 |
| Token | 词元 | 模型处理输入与输出的基本单位 |
| Transformer | Transformer 架构 | 通过注意力等机制处理序列信息 |
| Prompt | 提示词或输入提示 | 描述任务、提供信息和约束 |
| Context Window | 上下文窗口 | 限定单次推理可处理的上下文范围 |
| Memory | 记忆 | 保存和使用历史信息及任务状态 |
| RAG | 检索增强生成 | 检索外部资料并辅助模型生成回答 |
| Tool Calling | 工具调用 | 使模型能够请求使用外部工具 |
| MCP | 模型上下文协议 | 标准化 AI 应用与外部工具和资源的连接 |
| Agent | 智能体 | 围绕目标组织决策、工具调用和任务执行 |
| Agent Loop | 智能体执行循环 | 组织任务决策、工具执行与反馈处理 |
| Skill | 可复用任务能力 | 封装特定任务的操作说明和相关资源 |
| Workflow | 工作流 | 按照规则组织多个执行步骤 |
| Automation | 自动化 | 根据预设条件或计划执行任务 |
AI Agent 完整运行流程
前面介绍了从基础模型到应用层的各项技术。接下来通过一个具体例子，将它们联系起来。
假设用户向 Agent 提出任务：
读取本月销售数据，统计各产品的销售额，生成柱状图，并保存一份分析报告。
一个具备文件读取、数据分析和文档生成功能的 Agent，可以按照以下流程完成任务。
- 接收任务：系统获取用户指令以及相关的文件位置或附件信息。
- 准备上下文：整理任务要求、当前会话信息和必要的参考资料。如需查询外部知识库，可以使用检索工具或 RAG。
- 模型决策：模型结合上下文，判断需要读取文件、处理数据和生成报告。
- 任务规划：Agent 确定主要步骤，包括读取数据、统计指标、生成图表和保存文件。
- 工具执行：调用文件工具读取数据，再通过 Python 等工具完成计算和绘图。
- 结果检查：检查工具执行状态、数据计算结果和输出文件是否符合要求。
- 输出结果：将生成的报告或文件位置返回给用户，并根据需要保存任务状态。
整个过程可以概括为：
用户提出任务
↓
准备输入与上下文
↓
LLM 分析任务
↓
Agent 规划与决策
↓
调用工具执行操作
↓
检查执行结果
├── 需要继续：再次规划或调用工具
└── 任务完成：生成最终输出
在实际系统中，部分步骤可以由固定程序控制，也可以交给模型决定。例如，数据读取和保存文件可以使用预定义工作流，而分析方式和图表选择可以由 Agent 根据数据内容确定。
注意：并非每个 Agent 都需要 RAG、MCP 或长期记忆。系统可以根据任务规模、数据来源和实际业务需求选择合适的组件。
总结
从大语言模型到 AI Agent 应用，可以按照不同技术承担的职责来理解：
- 模型层：提供语言建模、推理和内容生成能力。
- 上下文层：组织输入信息，并根据需要补充历史记录和外部知识。
- 工具层：连接外部数据源和程序，执行实际操作。
- 智能体层：围绕目标组织决策、调用工具并处理反馈。
- 应用层：将这些能力组合成用户可以使用的产品和业务流程。
对于初学者，不必一开始就同时掌握所有概念。
可以先了解 LLM、Token 和 Prompt，再学习 API 与 Tool Calling，随后通过简单的 Agent Loop 实现工具调用，最后根据需求引入 RAG、MCP、Skill 和 Workflow 等技术。
在实际开发中，选择合适的技术比堆叠更多组件更重要。一个设计清晰、工具可靠、权限受控的简单 Agent，通常比结构复杂但缺乏验证机制的系统更容易维护。
相关资料：