AI 核心概念工程手册

先说结论

很多 AI 时代的新名词，本质上都能在传统软件工程里找到影子。它们不是凭空出现的新魔法，而是老工程概念换到了“模型作为决策核心”的系统里。

  flowchart LR
    A["用户目标"] --> B["Prompt<br/>指令、参数、约束"]
    B --> C["Context<br/>本次请求上下文"]
    C --> D["LLM<br/>推理与生成"]
    D --> E{"需要外部能力？"}
    E -- "否" --> F["直接回答"]
    E -- "是" --> G["Function Calling<br/>生成函数名和参数"]
    G --> H["Tool<br/>宿主程序执行"]
    H --> I["结果写回 Context"]
    I --> D
    J["MCP"] -. "标准化连接工具和资源" .-> H
    K["Skill"] -. "按需加载任务流程" .-> B
    L["Agent"] -. "规划、循环、验证" .-> D
  

1. LLM：大语言模型

LLM 是 Large Language Model，中文通常叫大语言模型。它是生成式 AI 应用里的核心推理与生成引擎，但不是整个 AI 的全部。AI 还包括计算机视觉、语音识别、推荐系统、传统机器学习、强化学习等方向。

现代 LLM 多基于 Transformer 架构。Transformer 由 Google 研究团队在 2017 年论文《Attention Is All You Need》中提出，后来被 OpenAI、Google、Meta、Anthropic 等公司广泛用于大模型训练和产品化。

从工程角度看，LLM 更像一个“概率驱动的运行时”：输入上下文，输出下一个 Token 的概率分布，再通过采样、解码、安全策略和工具结果逐步生成完整回答。

需要避免一个误解：把 LLM 说成“文字接龙”可以帮助入门，但它不是简单选择概率最高的词。实际生成受训练数据、模型参数、上下文、系统规则、采样策略、工具调用结果和安全策略共同影响。

  flowchart TB
    A["训练阶段<br/>从大量数据中学习模式"] --> B["模型参数<br/>长期能力"]
    C["推理阶段输入<br/>Prompt + Context"] --> D["LLM"]
    B --> D
    D --> E["预测下一个 Token 的概率分布"]
    E --> F["采样 / 解码 / 约束"]
    F --> G["生成输出"]
  

2. Token 与 Tokenizer

Token 是模型处理文本的基本单位。它可能是一个汉字、一个词、一个词的一部分、一个标点，甚至是一段常见字符串。Token 不等于人类语言里的“字”或“词”。

Tokenizer 是文本和数字之间的转换器。它负责把文本切成 Token，再把 Token 映射成 Token ID，供模型计算。模型输出后，还要把 Token ID 再解码成人类可读文本。

经验估算只能用于粗略判断成本和长度：

传统软件工程类比：Tokenizer 有点像编译器前端里的词法分析器，但它不是按编程语言语法切分，而是按模型训练时采用的分词规则切分。

  flowchart LR
    A["原始文本"] --> B["Tokenizer"]
    B --> C["Token"]
    C --> D["Token ID"]
    D --> E["Embedding 向量"]
    E --> F["模型计算"]
    F --> G["输出 Token"]
    G --> H["解码为文本"]
  

3. Context 与 Context Window

Context 是模型在一次推理中能看到的全部信息。它通常包括系统规则、开发者指令、用户问题、对话历史、上传文件、RAG 检索片段、工具调用结果等。

在传统软件工程里，Context 很像一次请求的上下文对象：里面放着当前任务需要的参数、状态、权限、历史记录和外部返回值。

Context Window 是一次请求最多能容纳的 Token 数量。它不是永久记忆，只是“这次请求的输入输出容量上限”。有些平台会把最大输入长度和最大输出长度分开限制。

长上下文并不自动等于高质量理解。上下文越长，成本、延迟和信息干扰都可能上升；关键不是塞得越多越好，而是把真正相关的信息放进去。

  flowchart TB
    A["Context<br/>一次请求的上下文"] --> B["系统 / 开发者规则"]
    A --> C["用户当前问题"]
    A --> D["对话历史"]
    A --> E["上传文件片段"]
    A --> F["RAG 检索片段"]
    A --> G["Tool 返回结果"]
    A --> H["输出预留空间"]
  

4. Prompt：提示词

Prompt 是给模型的任务说明、背景、输入数据和约束条件。它不只是“用户问的一句话”，也可以包括角色设定、示例、输出格式、工具使用规则、安全边界和评价标准。

常见层级如下。不同平台的命名和优先级可能不同，但思想类似：

传统软件工程类比：Prompt 像函数调用时传入的参数、配置和执行说明。区别在于，普通函数严格按代码执行；LLM 会根据自然语言指令进行概率推理，因此 Prompt 越清晰，行为越可控。

一个好的 Prompt 通常会说明：目标、背景、输入、限制、输出格式和验收标准。

5. Function Calling：函数调用形式

Function Calling 是很容易漏掉的一层。更准确地说，它是 Tool Calling 中最常见的一种形式，解决的问题是：模型如何用结构化方式告诉宿主程序“我想调用哪个函数，以及参数是什么”。

它的关键点：

• 模型不会直接执行函数。
• 开发者先把可调用函数的名称、描述、参数结构提供给模型。
• 模型根据用户问题判断是否需要调用函数。
• 如果需要，模型输出函数名和参数。
• 宿主程序解析这个调用请求，真正执行函数。
• 执行结果再放回上下文，让模型生成最终回答。

OpenAI 文档把 Function Calling 放在工具调用体系里，用来让模型连接外部系统和访问训练数据之外的信息；函数通常用 JSON Schema 描述输入参数。也就是说，Function Calling 不是独立于 Tool 的另一套机制，而是 Tool Calling 的一种具体表达方式。

传统软件工程类比：Function Calling 像“接口契约 + RPC 调用请求”。模型负责生成调用意图和参数，应用程序负责校验、授权、执行和返回结果。

  sequenceDiagram
    participant U as 用户
    participant M as LLM
    participant A as 宿主应用
    participant F as 函数实现

    U->>M: 北京今天适合穿什么？
    M->>A: function_call: get_weather({city: "北京"})
    A->>A: 校验参数与权限
    A->>F: 执行 get_weather
    F-->>A: 返回天气数据
    A-->>M: function_call_output
    M-->>U: 结合天气给出穿衣建议
  

Function Calling 和普通函数调用的区别：

6. Tool：工具执行

Tool 是模型可请求使用的能力接口。Function Calling 描述“怎么请求调用某个函数”，Tool 则是“模型实际可用的能力集合”。

Tool 可以是：

• 一个本地函数。
• 一个 HTTP API。
• 一个数据库查询。
• 一个搜索引擎。
• 一个文件读写接口。
• 一个代码执行环境。
• 一个浏览器或电脑控制能力。
• 一个企业内部系统操作。
• 一个平台内置工具。

传统软件工程类比：Tool 就是函数实现、服务接口、脚本、命令行工具、平台内置能力或外部系统。它承担真实副作用，因此必须有权限、审计、参数校验和错误处理。

  flowchart LR
    A["Function Calling<br/>调用请求"] --> B["Tool Router<br/>选择工具"]
    B --> C["参数校验"]
    C --> D["权限检查"]
    D --> E["执行 Tool"]
    E --> F["返回结构化结果"]
    F --> G["写回 Context"]
  

Tool 与 Function Calling 的关系可以这样记：

7. MCP：模型上下文协议

MCP 全称是 Model Context Protocol，即模型上下文协议。它是一个开放协议，用来标准化 AI 应用连接外部工具、数据源和工作流的方式。

如果 Function Calling 解决的是“模型怎样请求调用一个函数”，MCP 解决的是“不同 AI 应用怎样统一发现、连接和使用一批外部能力”。

MCP 的核心角色：

MCP 很像 AI 时代的 LSP。LSP 让不同编辑器用统一协议接入不同语言服务；MCP 让不同 AI 应用用统一协议接入不同工具和数据源。它标准化的是上下文交换与能力接入方式，并不规定应用内部必须如何组织 LLM 推理流程。

  flowchart LR
    A["AI Host<br/>聊天应用 / IDE / Agent 平台"] --> B["MCP Client"]
    B <-- "JSON-RPC / MCP" --> C["MCP Server"]
    C --> D["Tools<br/>函数能力"]
    C --> E["Resources<br/>数据与上下文"]
    C --> F["Prompts<br/>提示模板"]
    D --> G["外部系统<br/>数据库 / API / 文件 / 浏览器"]
    E --> G
  

需要注意：MCP 提高了复用性，但不等于“开发一次，所有平台完全无差别运行”。实际效果还取决于客户端是否支持 MCP、支持哪些能力、权限如何配置、运行环境是否允许访问对应资源。

8. RAG：检索增强生成

RAG 全称是 Retrieval-Augmented Generation，即检索增强生成。它的核心不是让模型“记住所有资料”，而是在回答前先从外部知识库中检索相关片段，再把片段放进 Context。

传统软件工程类比：RAG 像“搜索索引 + 查询召回 + 请求时注入”。它不是训练模型，也不是扩大模型永久记忆，而是在运行时给模型补充相关材料。

  sequenceDiagram
    participant U as 用户
    participant A as AI 应用
    participant R as 检索系统
    participant K as 知识库 / 向量库
    participant M as LLM

    U->>A: 提问
    A->>R: 根据问题检索
    R->>K: 查询相关文档片段
    K-->>R: 返回候选片段
    R-->>A: 排序后返回相关内容
    A->>M: 问题 + 片段 + 指令
    M-->>A: 生成回答
    A-->>U: 返回答案
  

RAG 的价值：

• 降低把整本文档塞进 Context 的成本。
• 让回答更贴近指定资料。
• 方便接入企业内部知识库。
• 资料更新时不一定要重新训练模型。

RAG 的限制：检索错了，模型也容易答错；片段太少会漏信息，片段太多会增加噪音。所以 RAG 的关键工程点不是“有没有向量库”，而是切分、召回、排序、引用、权限和评测。

9. Agent：智能体

Agent 不是一种单独的模型，而是一套围绕模型构建的任务执行系统。它能根据目标进行规划、调用工具、观察结果、调整下一步，并循环推进任务。

传统软件工程类比：Agent 像工作流引擎、任务编排器、状态机和控制循环的组合。LLM 提供推理和决策能力，Agent 框架负责把决策变成可执行步骤。

Agent 常见能力：

• 理解目标。
• 拆解任务。
• 制定计划。
• 选择工具。
• 调用工具。
• 观察结果。
• 更新计划。
• 验证完成度。
• 在必要时请求用户补充信息。

  flowchart TD
    A["目标输入"] --> B["规划"]
    B --> C["选择下一步"]
    C --> D{"需要 Tool？"}
    D -- "是" --> E["Function Calling"]
    E --> F["Tool 执行"]
    F --> G["观察结果"]
    D -- "否" --> G
    G --> H{"目标完成？"}
    H -- "否" --> B
    H -- "是" --> I["验证并输出"]
  

常见模式：

10. Skill：技能配置

Skill 是预先写好的任务操作手册或能力包，通常以 Markdown 说明为核心，也可以配合脚本、模板、示例和配置文件。

图里说 Skill 的本质是“按需加载”，这个判断很准确。Skill 不是每次都塞进上下文，而是在任务匹配时加载相关说明，让 Agent 知道这一类任务应该怎么做。

传统软件工程类比：Skill 像插件、策略文件、Runbook、操作手册、任务模板。它不是模型能力本身，而是给模型和 Agent 的可复用执行规范。需要注意的是，Skill 是 Agent / Coding Assistant 生态里常见的工程化概念，不是所有 AI 平台都会使用同一个命名。

Skill 通常会说明：

• 什么时候使用这个 Skill。
• 任务执行步骤。
• 需要读取哪些资料或模板。
• 可以调用哪些脚本或工具。
• 输出格式是什么。
• 风险和验证要求是什么。

  flowchart LR
    A["用户任务"] --> B{"匹配某类任务？"}
    B -- "否" --> C["普通 Prompt 执行"]
    B -- "是" --> D["加载 Skill"]
    D --> E["读取说明 / 模板 / 脚本"]
    E --> F["Agent 按流程执行"]
    F --> G["按标准验证输出"]
  

Prompt 和 Skill 的区别：

11. 从传统软件系统看 AI 应用架构

一个典型 AI 应用可以按下面方式拆解：

  flowchart TB
    A["前端 / 用户入口"] --> B["应用后端"]
    B --> C["Prompt 组装层"]
    C --> D["Context 管理"]
    D --> E["LLM API"]
    E --> F{"模型是否请求工具？"}
    F -- "否" --> G["返回答案"]
    F -- "是" --> H["Function Calling 解析"]
    H --> I["Tool 权限与参数校验"]
    I --> J["Tool / MCP Server / 外部 API"]
    J --> K["工具结果"]
    K --> D
    L["RAG 检索系统"] --> D
    M["Skill 库"] --> C
  

如果用一句工程话概括：

AI 应用 = 传统软件系统 + LLM 推理引擎 + 上下文管理 + 工具调用协议 + 外部能力执行 + 验证与安全控制。

12. 容易混淆的概念

13. 最小记忆版

• LLM：语言推理和生成引擎。
• Token：模型处理文本的颗粒。
• Tokenizer：文本和 Token ID 的转换器。
• Context：这次请求模型能看到的全部信息。
• Prompt：给模型的任务说明和约束。
• Function Calling：模型用结构化方式请求调用函数。
• Tool：真正执行外部能力的函数、API 或系统。
• MCP：AI 应用连接工具和资源的客户端 / 服务端协议。
• RAG：先检索资料，再把相关片段交给模型。
• Agent：会规划、调用工具、观察结果、持续推进的执行系统。
• Skill：按需加载的任务操作手册或插件。

14. 参考资料

• Transformer 原始论文：《Attention Is All You Need》
• OpenAI Function Calling 文档：https://developers.openai.com/api/docs/guides/function-calling
• OpenAI Tools 文档：https://developers.openai.com/api/docs/guides/tools
• Model Context Protocol 文档：https://modelcontextprotocol.io/docs/getting-started/intro
• MCP 2025-06-18 Specification：https://modelcontextprotocol.io/specification/2025-06-18