从模型、Token、RAG 到 MCP、Agent、Loop 和 Graph

适合读者：刚接触 AI，希望先建立完整概念地图的非技术读者

起点：我为什么整理这份白皮书

我手里的起点很具体：身边朋友对AI的好奇和一系列的问题。

里面出现了大模型、LLM、GPT、Prompt、Token、RAG、Embedding、MCP、Agent、Workflow、Harness 等一长串词。每个词单独看都能查到解释，放在一起却很容易混乱。

我整理时面对三个现实限制。

第一，读者不一定有技术背景。如果解释一个名词时又引入五个新名词，文章只会增加理解成本。

第二，模型和产品更新很快。某个版本今天还是主力，几个月后可能已经被替换。因此，版本信息必须注明核查日期，不能写成永久结论。

第三，很多词不在同一个层级。GPT 是模型家族，ChatGPT 是产品；RAG 是资料检索方法，MCP 是连接协议；Loop 是执行机制，Graph 是编排结构。把它们放进一张平级清单，记得越多，反而越难形成判断。

所以我给这份白皮书定了一个目标：不追求把所有术语都塞进来，先回答三个实用问题。

1. 这个词处在 AI 系统的哪一层？
2. 它解决什么问题？
3. 我在什么情况下需要关心它？

观察：困惑来自不同层级混在一起

我重新检查这些术语后，发现小白最容易混淆的是四组关系。

2.1 模型、产品和公司品牌混在一起

有人说自己在用 GPT，有人说自己在用 ChatGPT；有人把 Gemini 当成模型，有人把它当成应用。这些说法在日常交流里可以理解，但做技术判断时必须分开。

模型提供能力，产品提供使用界面，公司负责训练、运营和更新模型。一个产品内部也可能切换不同版本的模型。

2.2 AI 能看到的资料和 AI 原来学过的知识混在一起

模型训练时学到的内容、当前对话里的内容、临时上传的文件、知识库检索出来的资料，并不是一回事。

很多所谓“AI 怎么突然忘了”或者“为什么它不知道公司内部规定”，其实是上下文和资料来源没有处理好。

2.3 会生成文字和能执行任务混在一起

一个模型可以写出操作建议，但这不代表它已经获得读取文件、查询数据库、发送邮件或修改代码的权限。

从生成内容到执行动作，中间还需要工具、权限、运行环境和确认机制。

2.4 Agent、Workflow、Loop 和 Graph 混在一起

这四个词都和“把事情做完”有关，但关注点不同。

• Workflow 关心预先确定的步骤。
• Agent 关心根据目标动态决定下一步。
• Loop 关心一次行动之后如何观察结果并继续迭代。
• Graph 关心如何组织节点、分支、并行和回退路径。

先把这四组关系理清，后面的名词就不会散成一地。

判断：我把 AI 系统分成 7 层

我的判断是，小白不需要从模型参数开始学。先建立分层地图，更容易判断自己当前缺的是模型能力、资料、工具，还是执行流程。

这张表是我为了降低理解成本采用的整理方式，主要用于定位问题。行业里还有其他分类方法，不需要把这套分层当成固定标准。

执行：逐层拆开这些名词

4.1 AI、机器学习、深度学习和大模型

AI 是人工智能的总称。凡是让机器完成识别、预测、生成、决策或执行任务的技术，都可以放进这个大范围里。

机器学习是其中一类方法。它不依赖开发者把所有规则逐条写死，而是从数据中学习规律。

深度学习是机器学习的重要分支，通常使用多层神经网络处理复杂模式。今天常见的大语言模型、图像模型和语音模型，大多建立在深度学习技术之上。

大模型强调的是模型规模、训练数据、计算投入和通用能力。它不是“体积很大的软件”，也不是某一个公司的专属名称。

我会把这几个词理解成包含关系：

人工智能
└── 机器学习
    └── 深度学习
        └── 今天多数生成式大模型使用的技术基础

4.2 LLM、多模态模型和推理模型

LLM 是 Large Language Model，也就是大语言模型。它主要处理语言相关任务，例如问答、总结、翻译、写作和代码生成。

它生成答案时，会结合训练中学到的规律和当前上下文。它不会自动为每句话查询权威数据库，因此“说得完整”不等于“事实已经核实”。

多模态模型可以同时处理文字、图片、音频或视频。实时模型进一步强调低延迟交互，常用于语音对话、屏幕协作和实时翻译。

推理模型或 Thinking Mode 通常会在复杂问题上投入更多计算。它适合多步骤分析、代码调试和高难度判断，但往往需要更长时间和更多费用。简单任务不一定需要开启最高推理强度。

4.3 GPT、Gemini、Claude、MiniMax 和 DeepSeek

这些名称属于不同公司的模型家族或品牌。它们都能处理文字任务，但产品形态、工具支持、多模态能力、速度和价格并不相同。

这张表用于帮助选型，不做综合排名。我会检查五件事：任务效果、稳定性、速度、价格、工具和数据接口是否合适。

同一个模型家族也会提供不同版本。高性能版本适合复杂任务，轻量版本适合高频、低成本任务。真正选型时，需要拿自己的任务做测试。

官方资料：OpenAI Models、Gemini Models、MiniMax API Overview、DeepSeek Models。

4.4 产品入口和 API

ChatGPT、Gemini、Claude、Kimi 和豆包首先是普通用户可以打开使用的产品。它们提供聊天界面、文件上传、语音、搜索或其他功能。

API 是软件调用模型的接口。

假设我要在自己的文档系统里加入“生成摘要”功能，程序需要把文档内容和任务要求发送给模型，再接收模型返回的结果。这个过程通常通过 API 完成。

这里有三个不同对象

4.5 Prompt、System Prompt 和上下文工程

Prompt 是我交给 AI 的任务说明和材料。

我写 Prompt 时，至少会检查六项：

1. 要完成什么任务。
2. 输出给谁看。
3. 可以使用哪些资料。
4. 结果需要什么格式。
5. 哪些信息必须核实。
6. 什么情况应该停止并向人确认。

一个可执行的示例可以这样写：

请把下面三份会议纪要整理成一页决策简报。
读者是没有参加会议的项目负责人。
分别列出已确认事项、存在分歧、负责人和下一步日期。
原文没有明确负责人的项目标记为“待确认”，不要自行补充姓名。

System Prompt 更接近长期工作规则。它可以规定助手的职责、可用工具、输出标准和禁止事项。

提示词工程关注如何把当前任务说清楚。上下文工程的范围更大，还包括文件、历史记录、工具说明、项目规范、示例和权限边界。

4.6 Token 和 Context Window

Token 是模型处理内容时使用的基本计量单位。文字会被切分成小片段，再转换成模型能够处理的数字表示。

为了方便小白理解，我会暂时把它看成 AI 服务里的“文字流量”。

• 我发给模型的问题和资料，会消耗输入 Token。
• 模型返回的答案，会消耗输出 Token。
• 输入和输出越长，通常处理时间和费用越高。

这个说法只是帮助理解。Token 不是真实网络流量，也不等于固定字数。一个汉字、英文单词或标点占用多少 Token，会因模型的切分方式而不同。

Context Window 是模型一次任务能处理的上下文容量。它通常包括任务指令、历史对话、上传资料、工具返回内容和计划生成的答案。

手机套餐流量和单次文件上传上限不是同一个指标，Token 用量和 Context Window 也要分开看：前者涉及处理和计费，后者限制一次能放进多少内容。

4.7 Context、Memory 和知识库

Context 是当前这一次调用中模型能够看到的全部信息。

Memory 是应用跨轮次或跨会话保存的信息。模型不会天然永久记住所有历史。长期记忆通常由外部系统存储，并在合适的时候重新放回上下文。

知识库是一批经过组织、可以检索的资料，例如产品文档、合同、项目记录、课程材料和客服记录。

三者的关系可以整理成：

知识库或长期记忆中保存资料
          ↓ 按需取回
当前 Context 中提供相关内容
          ↓
模型根据当前可见内容生成结果

4.8 RAG 和 Embedding

RAG 是 Retrieval-Augmented Generation，通常译作检索增强生成。

假设我要确认一份合同有没有自动续约条款，系统可以按以下步骤处理：

1. 接收问题。
2. 从合同资料中检索相关段落。
3. 把问题和相关段落一起交给模型。
4. 要求模型根据原文回答并标出依据。

RAG 能减少模型凭空补充内容的概率，但不能保证答案永远正确。文档解析错误、检索遗漏、资料过期和模型误读，都会影响结果。

Embedding 是把文字、图片等内容转换成数字向量的方法。系统可以用这些向量判断语义是否接近。

例如，“收不到登录验证码”和“短信验证一直没来”用词不同，但表达的问题接近。Embedding 可以帮助知识库找到同一类处理方案。

向量数据库经常用于保存和检索这些向量，但 RAG 并不只有向量检索一种实现方式。关键词检索、混合检索和重新排序也很常见。

4.9 Structured Output 和 Function Calling

Structured Output 要求模型按照规定结构返回内容，例如符合 JSON Schema 的数据。

如果程序需要读取负责人、日期和状态，结构化输出通常比一段自由文字更容易处理和验证。

Function Calling 让模型根据任务选择已定义的函数或工具，并给出调用参数。真正执行动作的是外部程序，不是模型本身。

这一区分很重要：模型提出“调用哪个工具、使用什么参数”，运行环境决定是否允许执行，并把结果返回给模型。

4.10 CLI、工具调用和 MCP

CLI 是命令行接口。开发者可以用命令启动服务、处理文件、运行测试和查看错误。

当 Coding Agent 获得受控的命令行权限后，它可以读取项目、修改文件、运行测试，再根据结果继续处理。但可执行不等于应该无限授权，目录范围、网络权限和高风险命令都需要限制。

MCP 是 Model Context Protocol。它定义了 AI 应用与外部工具和数据源之间的一种标准连接方式。

MCP 常见的三类能力是：

广告

MCP 解决连接标准问题，不自动解决权限、质量和安全问题。接上一个 MCP Server，意味着系统获得了新的能力，也扩大了需要管理的访问范围。

官方资料：MCP Architecture。

4.11 Workflow、Agent、Loop 和 Graph

Workflow 适合路径明确的任务。

例如，每周固定收集数据、生成图表、填写模板、交给负责人审核。这些步骤提前可以确定，就没有必要让模型每次重新规划整条路线。

例如，检查一批项目资料是否完整。Agent 可能需要先查看目录，再判断缺少哪些文件，然后决定是检索其他位置、生成缺失清单，还是请人补充信息。

Loop 是 Agent 常见的运行机制：

读取当前状态
    ↓
决定下一步
    ↓
调用工具或生成结果
    ↓
检查结果是否满足条件
    ├── 满足：结束
    └── 不满足：更新状态并进入下一轮

Loop 必须设置退出条件。常见条件包括任务完成、达到最大轮数、费用上限、连续失败或等待人工确认。

Graph 使用节点和边表示任务结构。节点负责处理工作，边决定下一步进入哪个节点。它可以包含顺序执行、条件分支、并行处理、回退和 Loop。

Graph 里可以有多个 Loop，Agent 也可以运行在 Workflow 的某一个节点里。它们可以组合，不需要四选一。

参考：LangGraph Graph API。

4.12 Coding Agent、Vibe Coding 和 Harness

Coding Agent 可以进入项目环境，读取代码、修改文件、运行命令、查看错误并继续修复。Codex、Claude Code、Cursor 等产品都提供了类似能力，但具体权限和工作方式不同。

Vibe Coding 通常指通过自然语言与 AI 协作完成软件。它降低了开始做工具的门槛，但并不会自动消除测试、安全和维护成本。

如果项目只用于个人试验，失败代价可能较低。如果涉及付款、账号、隐私数据或生产业务，代码审查、自动测试、备份和权限控制就不能省略。

Harness 在 Agent 工程中通常指模型外围的运行和控制层，可能包括工具、权限、提示词、上下文策略、日志、测试、重试和人工审批。

Harness 不是像 MCP 那样有统一规范的标准术语。不同作者使用这个词时，范围可能不同。我会先看对方具体把哪些组件算进 Harness，再讨论方案。

4.13 Evals、Tracing、Observability 和 Human-in-the-loop

Evals 用来评估 AI 输出是否达到预定标准。标准可以是事实准确率、格式合格率、任务完成率或人工评分。

Tracing 记录一次任务经过了哪些模型、工具、参数和步骤，便于定位错误。

Observability 关注系统长期运行中的质量、延迟、费用、失败率和异常情况。

Human-in-the-loop 指在关键节点让人参与。人可以审核结果、修改状态、批准动作或终止任务。

Agent 的自主程度越高，这四项越不能拖到最后再补。

4.14 训练、微调、蒸馏和量化

训练是模型从大量数据中学习规律的过程。

微调是在已有模型基础上，用特定数据继续训练，使模型更适合某类任务或表达方式。

蒸馏通常让较小模型学习较大模型的一部分能力，用较低成本完成目标任务。

量化通过降低计算精度减少内存和算力需求，方便模型在资源有限的设备上运行。压缩程度过高也可能影响效果。

这些概念主要帮助我理解模型新闻和部署选择。普通用户并不需要先学会训练模型，才能开始使用 AI。

结果：一项任务怎样穿过整张地图

为了检验这张地图是否有用，我会用一个明确的假设任务来检查。

假设我要把会议记录、项目文档和一份数据表整理成决策简报。这里说的是示例，不是虚构成我的真实项目。

完整过程可以这样拆：

1. 我先定义读者、简报格式和不得补写的信息。这一层涉及 Prompt 和 System Prompt。
2. 我把会议记录和项目文档放进当前 Context，资料较多时使用知识库和 RAG。
3. 系统用 Embedding 或关键词检索找到与问题相关的内容。
4. 模型通过 Structured Output 返回事项、负责人、日期和风险字段。
5. 如果需要读取数据表或生成文件，系统调用经过授权的工具，也可能通过 MCP 连接外部资料源。
6. 固定的整理步骤放进 Workflow，需要判断资料缺口的部分交给 Agent。
7. Agent 在 Loop 中检查结果；复杂分支用 Graph 管理状态和回退路径。
8. Tracing 记录执行过程，Evals 检查结果，发布前由人确认。

到这里，模型只是系统中的一个组件。最终质量还取决于资料、检索、工具、流程、权限和验收。

复盘：哪些地方最容易学偏

完成这轮整理后，我认为有六个误区需要单独记下来。

6.1 把模型版本当成长期知识

版本名称会变化。白皮书可以记录核查时点，但不能替代厂商的实时模型列表。

6.2 把更长输出当成更强能力

回答长不代表判断更准确。真正需要检查的是依据、完成条件和错误率。

6.3 把 RAG 当成事实保证

RAG 只是增加可用资料。资料错误、检索错误或模型理解错误仍然会传递到结果中。

6.4 把 MCP 当成自动化系统本身

MCP 解决连接方式。任务如何编排、权限如何控制、结果如何验收，仍然需要另外设计。

6.5 把 Agent 当成越自主越好

自主性会增加不可预测路径。任务越重要，停止条件、权限范围、日志和人工确认越重要。

Harness、Vibe Coding、GEO 等词都有现实使用场景，但定义并不总是一致。

GEO 通常指 Generative Engine Optimization，也就是研究内容如何进入并影响生成式答案。目前相关研究仍在发展，术语、测量方法和长期效果没有完全统一。我不会把它包装成一套稳定公式。

参考：GEO 原始论文、2026 年 GEO 研究综述。

方法：小白可以怎样开始

如果从零开始，我建议分四轮学习。

第一轮：先分清对象

先分清公司、模型、产品和 API。能回答“我现在使用的是哪个产品，它调用了什么模型”，这一轮就够了。

第二轮：学会提供任务和资料

练习 Prompt、Context、Token、知识库和 RAG。重点是减少模型必须猜测的信息，提示词够用、清楚即可。

第三轮：理解工具和执行

学习 Function Calling、Structured Output、MCP、Workflow、Agent、Loop 和 Graph。先从低风险、可回退的任务开始。

第四轮：建立验收

给任务设置完成条件、来源要求、最大轮数、费用范围和人工确认点。记录失败原因，再调整流程。

我会用下面这张清单检查一个 AI 任务：

风险边界：这套方法会在哪些地方失效

8.1 幻觉和来源错误

模型可能生成看起来合理但并不准确的内容。涉及事实、数字、引用、法律、医疗和财务判断时，需要核对可靠来源。

8.2 Prompt Injection

外部网页、文件或工具返回内容可能包含诱导指令，试图让 Agent 忽略原有规则。只靠 System Prompt 不能完全防护，还需要最小权限、输入隔离、参数校验和审批。

8.3 隐私和数据权限

上传资料前，需要确认其中是否包含客户信息、商业秘密、账号凭证或其他受限制数据。能上传不代表有权上传。

8.4 自动执行的影响范围

发送邮件、付款、删除数据、修改生产系统和公开发布内容，都可能造成难以撤销的影响。此类动作应设置明确授权和人工确认。

8.5 成本和无限循环

长上下文、高推理强度、重复工具调用和没有退出条件的 Loop 都会增加成本。预算和最大轮数应该成为流程的一部分。

8.6 版权和原创性

通用概念和事实可以被不同作者解释，但具体案例、章节编排、比喻和表达可能受到版权保护。

结语

我整理这份白皮书的目标很简单：让小白不用先背下所有英文缩写，也能看清一个 AI 系统怎样工作。

真正长期有用的能力，是看到一个新名词时，能判断它属于模型、资料、工具、执行还是控制层；知道它解决什么问题，也知道它没有解决什么问题。

模型会继续更新，名词也会继续增加。相比追逐每一个版本，我更看重三件事：把任务说明白、把风险控制住、对结果持续复盘。

关于作者

Kimberly｜@king1818888

Australia AI Engineer，每天用 AI 建系统、做内容，也是 X 创作者。