生成式人工智能解析：模型、检索、工具与应用并非同一回事

生成式人工智能并非单一组件。一个生产级生成式人工智能系统通常将生成模型与应用程序代码相结合，后者提供指令和上下文，在需要时检索外部知识，暴露用于读取或更改外部系统的工具，管理运行时状态和权限，并将结果转化为可用的产品。将模型、检索、工具、上下文、运行时和应用程序视为同一事物，会掩盖决定新鲜度、安全性、可靠性、成本和控制的边界。

“生成式人工智能”究竟意味着什么？

在模型层面，生成式人工智能指的是能够生成衍生合成内容（如文本、图像、音频、视频、代码或其他数字输出）的人工智能模型。NIST AI 600-1使用了这种面向模型的含义，并分别在模型、系统、应用程序和用例层面讨论风险。

这种区分很重要，因为人工智能模型与完整的人工智能系统不是一回事。NIST当前术语表将人工智能模型定义为使用计算、统计或机器学习技术从输入产生输出的组件，而人工智能系统可以包括使用人工智能运行的软件、硬件、应用程序、工具或实用程序。

生成式人工智能系统的最简单有用模型

作为第一个心智模型，想象一个公司助手回答：“这位客户今天能获得退款吗？”一个有用的答案可能需要几种不同的职责。语言模型可以解释问题并撰写说明，但当前订单状态可能来自数据库工具，退款政策可能来自文档检索，权限可能由应用程序强制执行，而最终操作可能需要受控的API调用。

一种常见的执行路径

1

1. 用户请求

应用程序接收自然语言问题或任务。

2

2. 应用程序策略和状态

身份、租户、权限、当前工作流状态和产品规则定义了该请求被允许做什么。

3

3. 检索或直接数据访问

当模型知识不足时，系统获取外部证据或当前事实。

4

4. 上下文构建

为模型组装指令、用户输入、选定的证据、相关状态和工具定义。

5

5. 模型推理

生成模型解释提供的上下文并产生文本、结构化输出或工具请求。

6

6. 需要时执行工具

运行时或应用程序在模型外部验证并执行已批准的工具调用。

7

7. 观察与继续

工具结果可以作为新上下文返回给模型，用于下一步推理。

8

8. 验证和产品输出

应用程序验证结果，记录所需状态或审计数据，并呈现或执行最终结果。

真实系统并不总是严格遵循这个顺序。检索可以在第一次模型调用之前发生，工具可以在代理循环中选择，确定性的应用程序逻辑可以完全绕过模型，验证可以在多个阶段进行。重点是将职责分开，而不是强加一个通用的工作流。

六个重要的边界

一个AI产品中的六项职责

	主要工作	典型输入	不同于
模型
检索
工具
上下文
运行时/编排器
应用程序

1. 模型：生成是其核心职责

生成模型将提供的输入映射为生成的输出。对于语言模型，这可以包括自然语言文本、结构化JSON、代码、分类、摘要、计划或工具调用参数。多模态生成模型可以处理额外的输入和输出类型。

模型可以在其参数中包含大量学习到的知识，但参数化知识不是实时数据库。除非通过当前输入路径提供信息，否则模型不会自动知道五分钟前创建的文档、当前库存水平、私人客户记录或应用程序状态。

这就是为什么更改模型不能自动解决知识过时、权限缺失、检索损坏、状态所有权不正确或不安全的工具执行问题。这些故障通常属于其他层。

2. 检索：查找外部证据是一项独立操作

检索在生成之前或生成过程中从外部来源选择信息。Lewis 等人于 2020 年提出的检索增强生成工作通过将参数化生成模型与检索到的非参数化记忆相结合，使这种分离变得明确。现代生产系统使用许多检索变体，但架构理念保持不变：有用的证据可以在推理时获取，而不是仅依赖模型在训练期间学到的内容。

检索可以使用词法搜索、嵌入、向量搜索、混合搜索、SQL、知识图谱、元数据过滤器、API 或其他选择机制。因此，向量数据库是一种可能的检索组件，而不是 RAG 的定义。

3. 工具：访问和操作不是模型知识

工具是一种接口，AI 运行时可以通过它请求模型之外的功能。工具可以查询数据库、搜索网络、读取文件、计算数值、调用内部服务、创建工单、发送消息、修改记录或触发另一项受控操作。

OpenAI 当前的函数调用文档明确了这一边界：函数调用让模型能够与外部系统交互，并访问应用程序提供的数据或操作。模型可以提议或选择调用，但真正执行操作的是外部系统。

因此，工具使用产生了两个独立问题：模型能否请求此能力？以及应用程序是否会授权并执行它？生产系统不应将模型意图与造成副作用的权限混为一谈。

4. 上下文：模型当前能看到什么

上下文是模型在特定推理步骤中可用的信息。Anthropic 的上下文工程指南将上下文描述为从 LLM 采样时包含的 token 集合。在实践中，该集合可以包含系统指令、用户消息、对话历史、检索到的证据、工具定义、工具结果、记忆摘要和选定的应用程序状态。

因此，上下文既不是完整的知识库，也不是长期记忆。一家公司可能存储一千万份文档，但只有少数段落进入一次模型调用。运行时可能保留一年的对话历史，但只暴露当前任务所需的部分。

上下文窗口还带来工程约束。添加更多文本并不能保证更好的答案；无关、过时、矛盾或低权威性的信息可能会稀释真正重要的证据。

5. 运行时与编排：协调循环

运行时或编排层协调模型如何参与任务。根据架构的不同，它可以管理会话、模型请求、工具发现、工具调用循环、重试、交接、流式事件、超时、检查点、压缩或执行环境。

有些运行时只是围绕模型 API 的薄应用代码。另一些则是完整的智能体框架。托管供应商运行时可以拥有循环的一部分，而应用程序仍然拥有领域真相、授权、业务副作用和产品生命周期。

这一边界很重要，因为运行时在哪里运行和推理在哪里运行是分开的决策。本地运行的客户端或智能体进程仍然可以调用远程模型，而远程应用程序可以调用托管在组织控制的基础设施上的模型。

6. 应用：AI 成为产品的地方

应用是围绕 AI 组件的产品边界。它拥有用户体验、领域模型、当前状态、身份、租户范围、权限、持久化、服务集成、验证、可观测性、计费或配额逻辑（如相关），以及决定 AI 被允许看到或做什么的规则。

这一层将“模型可以产生有用的输出”转变为“系统可以提供可靠的能力”。同一个模型可以参与私人研究助手、支持工作流、代码代理或商业应用，因为周围的应用程序改变了数据、工具、策略、状态和执行契约。

各部分如何在真实请求中协同工作

考虑一个支持助手被问到：“如果订单 4711 仍然符合条件，请退款，并解释原因。”该请求结合了知识、当前状态、授权、推理和副作用。

如果助手只有语言模型，它可以讨论退款，但无法安全地知道订单 4711 当前是否符合条件或执行交易。如果它只有检索，它可能找到政策，但仍然缺乏实时订单状态。如果它有工具但没有应用授权，它可能变得有能力但不安全。可靠性来自于以明确的所有权组合各层。

不同的 AI 产品使用不同的组合

模型的存在并不定义整个架构

	检索	工具	权威状态	典型能力
仅模型助手
检索增强助手
使用工具的助手
代理应用

这些是架构模式，不是成熟度排名。当任务不需要外部事实或操作时，仅模型功能可以是正确的设计。只有当任务需要这些能力时，添加检索、工具、记忆或代理循环才是合理的。

实现证据：Aaasaasa AI Client

Aaasaasa AI Client 是一个使用 Nuxt 4、Electron 和 TypeScript 构建的本地优先桌面 AI 工作区。其 AI Hub 有意将代理/客户端、提供商、模型、运行时位置、权限和 Web 客户端分开，而不是将它们视为一个“AI”设置。

这种分离创造了具体的行为。Direct Chat 可以与模型对话，而无需文件系统或 shell 工具。Codex 代理可以使用选定的工作区和权限配置文件。Ollama 可以提供直接的本地推理，而 LM Studio 和可配置的 OpenAI 兼容端点代表其他提供商路径。本地运行的 Codex 进程仍然可以使用云模型，因此 UI 和架构并不将本地运行时等同于本地推理。

该实现还包含 Qdrant/向量支持、文档提取功能和经过身份验证的目录 MCP 代理。这些组件说明了另一个边界：检索基础设施和工具访问可以存在于同一产品中，而不会成为模型本身的属性。

常见的类别错误

边界崩溃时的故障模式

边界错误不仅仅是术语问题。它们会造成不同的生产故障，需要不同的修复方法。

在更换模型之前先诊断故障层

	症状	可能的边界问题	首要架构检查
答案过时
缺少公司事实
不安全的副作用
提供了大量文本但答案混乱
意外的云使用
代理停滞或重复

什么是稳定的，什么对版本敏感？

本文中的架构区分有意保持供应商中立。下面的当前示例是实施事实，在 API 演变时应重新检查。

因此，一篇权威文章应同时保留两个层面：用于架构的稳定概念，以及用于当前实现的带日期证据。将两者混为一谈会使文章不必要地快速过时。

AI 组件边界测试

在评估 AI 功能时，请按顺序提出以下问题。答案揭示了系统实际拥有哪些组件，以及哪些责任仍然是隐含的。

生产设计的七个问题

1

1. 什么生成输出？

确定确切的模型及其提供的模态或结构化输出。

2

2. 模型之外哪些事实是权威的？

确定文档、数据库、API、当前状态和其他事实来源。

3

3. 如何选择相关信息？

区分直接查找、搜索、检索、排序和上下文构建。

4

4. 什么可能导致真实的副作用？

列出工具和外部操作，然后确定谁验证和授权它们。

5

5. 什么作为上下文到达模型？

明确指令、证据、状态、历史、记忆和工具定义。

6

6. 谁拥有循环？

确定管理调用、事件、重试、工具循环和会话的运行时或框架。

7

7. 什么仍然是应用程序的责任？

明确身份、权限、领域状态、验证、持久化、可观测性和用户体验。

生成式 AI 不是什么

生成式 AI 不是 LLM 的同义词，尽管 LLM 是生成式模型的主要类别。它也不是 RAG、向量数据库、代理、工具协议、聊天机器人界面或应用程序的同义词。

这些概念可以相互关联，但每个概念回答不同的架构问题。LLM 问的是语言输出如何产生。检索问的是外部证据来自哪里。工具问的是外部能力如何暴露。上下文问的是模型能看到什么。运行时问的是执行如何协调。应用程序问的是能力如何成为受控产品。

知识图谱中接下来去哪里

一旦这些边界清晰，更深入的主题就更容易定位。RAG 属于检索和上下文构建。检索触发器决定何时需要外部证据。代理记忆关注跨时间持续存在的内容。工具调用和 MCP 属于能力访问。代理框架属于运行时编排。RBAC、租户隔离和领域授权属于应用程序和平台安全边界。

局限性

六层模型是一张责任地图，而不是要求每个产品都部署六个独立服务。小型应用可以在一个进程内实现上下文构建、检索和编排。托管平台可以将多项职责捆绑在一个 API 之后。物理部署可以合并，而语义归属仍然保持独立。

不同供应商和研究中的术语也各不相同。“智能体”、“运行时”、“记忆”、“工具”、“连接器”和“上下文”可能有不同的定义。这里的定义旨在明确操作归属和故障诊断，而不是声称每个框架都使用相同的词汇。

Aaasaasa AI Client 部分记录了一种实现模式。它表明明确的边界是可行的，但并不能证明相同的组件布局对每个 AI 产品都是最优的。

什么会改变这个答案？

如果模型架构本身开始将权威外部状态、权限、持久事务副作用和可验证的源访问作为内在属性，而不是由周围系统提供的能力，那么责任地图将需要修订。当前的生产架构并未使这成为一个安全的普遍假设。

个别实现示例会更快地发生变化。托管检索工具、智能体 API、MCP 集成、上下文管理功能和提供商能力都在快速演进。这些细节应更新，而不应破坏生成、证据、能力访问、上下文、执行和应用控制之间的基本区别。

结论

一旦“AI”不再被视为一个黑箱，生成式 AI 的设计就会变得更容易。模型是生成组件，而不是完整产品。检索提供外部证据。工具暴露能力。上下文将选定的信息带入当前推理。运行时协调执行。应用程序拥有权威的产品边界。

这种分离不仅仅用于解释。它告诉工程师过时事实的来源、授权应属于哪里、为什么本地运行时仍可使用云推理、为什么 RAG 不等于向量数据库、为什么工具调用需要验证，以及为什么更改模型无法修复所有系统故障。

因此，持久的架构问题不是“我们使用哪个 AI 模型？”而是：每个组件拥有哪些职责，哪些证据跨越每个边界，以及哪一层被允许改变真实状态？

常见问题

生成式 AI 系统边界

生成式 AI 和 LLM 是一回事吗？

不是。LLM 是一种生成模型。生成式 AI 还包括其他模态，生产级生成式 AI 系统可以在模型周围包含检索、工具、运行时逻辑、应用状态、权限、持久化和用户界面。

RAG 是模型的一部分吗？

通常不是。RAG 是一种应用/系统模式，它检索外部信息并向模型提供选定的证据。一些平台将检索与模型 API 紧密打包，但职责仍然不同。

RAG 需要向量数据库吗？

不需要。RAG 可以使用向量搜索、词法搜索、混合检索、SQL、API、知识图谱或其他方法。其定义属性是为生成而检索外部信息，而不是某一种存储技术。

工具和上下文是一回事吗？

不是。工具是一种外部能力。它的定义可以在上下文中表示，其结果稍后也可能进入上下文，但实际能力在模型外部执行。

在本地运行 AI 客户端意味着模型是本地吗？

不是。运行时位置和推理位置是分开的。本地桌面应用或智能体可以调用远程模型，而远程应用可以调用内部托管的模型。

谁应该为 AI 工具强制执行权限？

应用程序或运行时安全边界应强制执行授权。模型可以请求操作，但模型意图绝不应被视为足够的执行权限。

当前应用状态应属于哪里？

权威的易失状态通常应保留在拥有它的应用程序或领域系统中。AI 可以在需要时通过受控上下文或工具访问接收相关状态。

术语表

核心术语

生成模型

一种 AI 模型，旨在生成衍生的合成内容，如文本、图像、音频、视频、代码或结构化输出。

检索

从外部源或存储中为当前任务选择相关信息的过程。

RAG

检索增强生成：一种模式，将检索到的外部信息提供给生成模型以改进当前输出。

工具

暴露给 AI 运行时用于读取数据、计算、搜索或执行外部操作的能力。

上下文

模型在特定推理步骤中可用的信息。

运行时 / 编排器

协调模型调用、工具调用、任务循环、会话、重试、事件或执行环境的软件层。

应用程序

拥有用户交互、权威状态、权限、验证、持久化和业务行为的产品和领域层。

提供商

暴露对一个或多个模型访问权限的服务或运行时；提供商身份和模型身份是分开的关注点。

主要来源和实现证据

以下稳定定义以标准/研究为依据；快速变化的实现示例使用当前官方工程文档。Aaasaasa AI Client 是原始实现证据，并已对照其截至 2026 年 7 月 26 日的代码库/文档状态进行核查。

NIST AI 600-1 — 生成式人工智能概况

NIST 的生成式 AI 概况，包括生成式 AI 的定义，并明确区分模型级、系统级、应用级和用例级关注点。

NIST — 人工智能模型

NIST 术语表中对 AI 模型的当前定义：信息系统的组成部分，使用 AI 技术从输入产生输出。

NIST — 人工智能系统

NIST 术语表中当前的 AI 系统定义，表明 AI 系统可以包括使用 AI 的数据系统、软件、硬件、应用程序、工具或实用程序。

Lewis 等 — 面向知识密集型 NLP 任务的检索增强生成

2020 年提出 RAG 公式的论文，该公式将生成模型与检索到的非参数记忆相结合。

OpenAI — 文件搜索

Responses API 中托管文件检索的当前官方文档，使用上传文件知识库、语义搜索和关键词搜索。

OpenAI — 函数调用

当前官方文档，将工具/函数调用描述为模型与外部系统、数据和操作之间的接口。

Anthropic — 面向 AI 智能体的有效上下文工程

工程指南将上下文定义为 LLM 采样期间可用的 token 集合，并解释为什么上下文选择是一个有限资源问题。