从 Prompt 到 Agent：把生成式 AI 的常见术语讲明白

这两年，围绕大模型的讨论越来越热，术语也越来越密。很多词听上去都像“黑话”：prompt、RAG、agent、MCP、skills、embedding、fine-tuning……它们经常被放在同一段话里，像是同一层面的概念，实际上并不是。更准确地说，这些词分别对应一个 AI 系统里的不同部位：有的是输入方式，有的是知识获取机制，有的是执行框架，有的是训练方法，还有一些则是工程化之后的接口和模块。

如果把一个生成式 AI 系统想象成一条完整链路，事情会清楚很多：用户先提出任务，系统组织上下文，必要时从外部资料中检索信息，模型据此生成回答；如果任务再复杂一点，系统还会调用工具、保存状态、分步执行，最后形成所谓的 agent。这样看，术语并不是越学越多，而是逐渐落到各自的位置上。

一、先从输入说起：Prompt、Content、Token 和 Context

Prompt 是最常见的词，也是最容易被说得过于玄乎的词。它本质上就是“给模型的指令”。OpenAI 在文档里把 prompt engineering 定义为“为模型编写有效指令，使它持续生成符合要求的内容”。这句话很朴素，但很关键：prompt 不是魔法咒语，而是任务说明书。一个好的 prompt 往往会同时包含目标、背景、约束、格式要求，甚至示例。(OpenAI Developers)

在真实系统里，prompt 很少只是用户敲进去的一句话。模型看到的输入，通常由不同角色的消息共同构成：开发者给出的系统约束、用户本轮提问、历史对话、工具返回内容，甚至还有固定模板。OpenAI 的文本生成与提示工程文档都明确采用这种消息式结构，而不是把所有内容混成一整块裸文本。换句话说，用户写的是 user prompt，系统还往往会叠加 developer prompt，后者负责规定模型“应该怎样说、不能怎样说”。(OpenAI Developers)

与 prompt 相邻、却不完全相同的一个词是 content。这个词更多出现在接口和工程语境里，通常表示消息正文，也就是“被处理的实际内容”。例如“请总结下面这篇文章”这句话里，“请总结”更像 prompt，而“下面这篇文章”的正文才是 content。它不是一套独立的方法论，更像是系统里对“内容载荷”的一种命名。OpenAI 的消息结构同样使用 content 来承载文本等内容。(OpenAI Developers)

再往底层走一步，就会碰到 token。人类按字、词、句理解语言，模型不是；模型真正处理的是 token。一个 token 不必等于一个汉字，也不必等于一个英文单词，它是模型分词器切出的计算单位。输入长度、输出长度、调用成本、上下文限制，最终几乎都要换算成 token 来算。OpenAI 的上下文与嵌入文档都把 token 作为核心计量单位来处理。(OpenAI Developers)

与 token 紧密相关的是 context，也就是上下文。所谓上下文，不只是“前面聊过的话”，而是当前这轮请求里模型可见的一切：系统规则、用户问题、历史消息、外部检索结果、工具返回值，甚至某些运行状态。context window 则是模型一次最多能处理多大的上下文范围。很多人误以为“大上下文模型”就等于“什么都能一口气看懂”，其实更准确的说法是：上下文窗口越大，系统可调度的信息越多，但这并不自动等于理解质量就一定更高。(OpenAI Developers)

二、模型不知道怎么办：RAG、Embedding 与检索

如果说 prompt 解决的是“你要模型做什么”，那么 RAG 解决的是“模型不知道时怎么办”。RAG 是 Retrieval-Augmented Generation 的缩写，通常译作“检索增强生成”。它的核心思想非常直接：不要只依赖模型在训练阶段记住的知识，而是在回答之前，先从外部知识源里找相关材料，再把这些材料放进上下文，让模型基于它们作答。(OpenAI Developers)

RAG 之所以重要，是因为大模型再强，也仍然有天然边界。它的知识可能过时，不知道你的私有文档，也可能在事实型问题上“说得很顺，但不一定可靠”。RAG 的价值，不是把模型变得更会背书，而是把它从闭卷考试改成开卷考试。模型不必什么都记住，但必须有能力在需要时拿到合适的依据。(OpenAI Developers)

要理解现代检索系统，embedding 几乎绕不过去。OpenAI 的定义很清楚：embedding 是一段数据的向量表示，向量之间的距离可以反映相关性，距离小通常意味着内容更相关。它的意义在于，搜索不再只是关键词匹配，而是开始比较“语义上的接近程度”。“大模型幻觉”和“LLM 编造事实”这两句话，字面未必一样，但语义上相近，embedding 就试图把这种相近性表达出来。(OpenAI Developers)

所以，语义搜索、向量检索、向量数据库这些词，本质上都建立在 embedding 之上。工程上通常会先把文档切成小块，为每一块生成 embedding，然后把这些向量存入索引系统；用户提问时，也把问题转成向量，在库里找最接近的若干段内容，再把它们送回模型。这就是今天大量企业知识问答、文档助手和内部搜索系统的基本骨架。OpenAI 的 Web QA 教程就展示了从网页抓取、生成 embeddings 到构造搜索功能的整条流程。(OpenAI Developers)

围绕 RAG 还有一组常见词：chunking、recall、precision、re-ranking。它们说的其实都是同一件事——怎样把“该找的内容”找出来，并把“最有用的内容”排到前面。文档切块切得不好，语义再强也会失真；召回太弱，关键证据进不了上下文；噪声太多，模型反而更容易答偏。因此，RAG 不是“加一个向量库”那么简单，它本质上是对知识获取过程的工程化设计。(OpenAI Developers)

三、模型不只说话，还要做事：Tools、Workflow 与 Agent

当模型只是回答问题时，事情还比较简单；一旦它要查天气、发邮件、读数据库、执行代码，语言本身就不够了。这时候会出现 tool calling，也常叫 function calling。OpenAI 官方把它定义为：让模型接入应用提供的数据与动作，使模型能够访问训练数据之外的信息，并与外部系统交互。说得更通俗一点，tool 是模型的“手”，让它不只会说，还能真正做。(OpenAI Developers)

与工具能力相配套的，是 structured outputs，也就是结构化输出。OpenAI 的定义是：通过给定 JSON Schema，确保模型生成的结果符合指定结构，而不是随意输出一大段自然语言。这件事在工程里非常重要，因为自然语言适合人读，不适合程序接；如果系统下一步还要继续处理模型结果，那么固定字段、固定枚举、固定层级，远比“看起来像是对的”更有价值。(OpenAI Developers)

再往前一步，就是 workflow。Anthropic 在“Building Effective AI Agents”里把 workflow 和 agent 区分得很清楚：workflow 是由开发者预先编排好的多步流程，模型和工具按既定路径被调用；agent 则不同，agent 的关键特征是模型可以根据中间结果动态决定下一步做什么。这个区分很重要，因为很多产品嘴上说自己是 agent，实际上只是多步 workflow。前者强调自主决策，后者强调可控编排。(Anthropic)

所以，agent 并不只是“会用工具的聊天机器人”。更严格地说，agent 是一种能够围绕目标进行分步决策的系统：它要能看当前状态、选择下一步动作、调用合适工具，并根据外部反馈修正自己的路径。Anthropic 把这类系统描述为从“augmented LLM”逐步演化而来的更复杂架构，其中检索、工具和记忆都是核心增强部件。(Anthropic)

这也解释了另一个常被误解的词：memory。这里的“记忆”通常不是神秘的“模型真的记住了你”，而是系统把与用户或任务相关的重要信息保存下来，并在合适的时候重新放回上下文。对 agent 来说，记忆尤其重要，因为一个复杂任务往往跨越多个步骤，系统必须知道自己已经做过什么、还缺什么、哪些结论已经得到外部验证。(Anthropic)

四、为什么 MCP 和 Skills 会越来越重要

当模型开始接入更多外部系统时，一个现实问题就出现了：每接一个工具、一个数据库、一套企业系统，都要单独写一遍对接逻辑，成本很高，也很难复用。MCP，也就是 Model Context Protocol，正是试图解决这个问题。MCP 官方规范把服务器可暴露的能力分成三类：resources、prompts 和 tools。resources 用来提供上下文和数据，prompts 用来提供模板化消息和工作流，tools 则是模型可执行的函数能力。(Model Context Protocol)

因此，MCP 的意义不在于发明了新能力，而在于把“模型如何接外部能力”这件事标准化了。官方对 tools 的定义很明确：它们让模型与外部系统交互，比如查数据库、调用 API、执行计算。resources 则让服务器把文件、数据库 schema 或应用级信息作为上下文暴露给模型。prompts 则更偏模板和工作流。把这三者放在一个统一协议里，实际上就是在为 AI 系统建立标准接口层。(Model Context Protocol)

skills 则属于另一层概念。OpenAI 把 skills 描述成一种模块化、可版本化的能力包，本质上是把指令、流程和规范打包起来复用。它不是单个工具，而更像一种“已经沉淀好的做事方法”：某个 skill 里可能包含说明文档、模板、脚本、约束和文件结构，用来稳定地完成某类任务。换句话说，tool 更像扳手，skill 更像一整套装配手册。(OpenAI Developers)

这就是为什么今天很多 AI 应用不再只比“模型本身有多强”，而开始比“谁更会组织上下文、谁更会接工具、谁更会沉淀工作流”。模型能力正在逐渐平台化，真正拉开差距的，越来越是围绕模型搭建起来的系统能力。(OpenAI Developers)

五、模型为什么会这样表现：SFT、DPO、RFT 与 Evals

如果说前面讲的是“模型运行时怎么工作”，那训练层解决的就是“模型为什么会这样工作”。最基础的一步是 supervised fine-tuning，也就是 SFT。OpenAI 的定义是，用示例输入和已知的高质量输出来训练模型，让它更稳定地产生你想要的风格和内容。它非常像“拿标准答案带着做题”：模型不是凭空悟出来，而是被反复示范什么样的回答才算好。(OpenAI Developers)

但很多任务没有唯一标准答案，尤其在语气、风格、偏好这些更主观的问题上，直接给“唯一正确输出”并不现实。这时候 DPO，Direct Preference Optimization，就会出现。OpenAI 的描述是：基于 prompt 和成对回答，让模型学习哪一种输出更受偏好。它训练的不是“唯一正确答案”，而是“相比之下，哪个更好”。这非常适合品牌语气、摘要风格、对话偏好这类任务。(OpenAI Developers)

再进一步，就是 reinforcement fine-tuning，也就是 RFT。OpenAI 对 RFT 的定义是：不是依赖固定的标准答案，而是依赖你定义的反馈信号或可编程 grader，给候选回答打分，再让高分输出更可能出现。它更像在训练策略，而不是训练模板。适合那些答案可以验证、但不适合简单做成“题目—标准答案”对的数据场景。(OpenAI Developers)

模型训练之外，还有一个经常被低估的词：evals。OpenAI 在评估最佳实践里强调，生成式 AI 的输出具有可变性，传统软件测试方法不足以覆盖这种非确定性，因此需要 evals 来系统地测试模型表现。换句话说，评估不是锦上添花，而是 AI 工程真正走向生产环境的前提。你不能只看“模型有时表现不错”，而要知道它在你的场景里、你的数据上、你的约束下，究竟稳定到什么程度。(OpenAI Developers)

六、把这些词放回一条完整链路里

到这里，很多术语其实已经能自然串起来了。用户先用 prompt 提出任务，系统把它和历史消息、规则、资料一起组织成 context；如果模型需要外部知识，就通过 RAG 去检索相关内容，而 embedding、语义搜索和向量索引负责把“相关”这件事算出来；如果模型还要查数据库、发邮件或操作别的系统，就通过 tools 进行调用；当整个过程被预先写成固定步骤时，它更像 workflow；当模型能根据目标和反馈自主决定下一步动作时，它才更接近 agent；而 MCP 提供的是这整套外部能力的标准接入方式，skills 则是把成熟经验沉淀成可复用模块。模型之所以会以某种方式说话，则是因为背后经历了 SFT、DPO 或 RFT 等不同形式的优化，而 evals 负责判断这些优化到底有没有真正生效。(OpenAI Developers)

结语

今天的生成式 AI 讨论，最容易出问题的地方，不是模型太复杂，而是不同层次的概念被混在一起。Prompt 不是 agent，RAG 不是向量库，tool 不是 skill，MCP 也不是某个具体产品。它们共同构成的是一个从输入、检索、执行到训练和评估的完整系统。真正理解这些词，不是为了显得懂行，而是为了在面对具体问题时，知道该从哪一层下手：是 prompt 写得不清楚，还是上下文组织得不好；是检索没有找对资料，还是工具设计不合理；是流程本该做成 workflow，却被误当成 agent；又或者，其实问题已经到了需要微调和评估的阶段。把这些边界分清，很多“AI 术语”就不再是术语，而会变成工程判断的一部分。(OpenAI Developers)