把 AI 这些名词一次讲明白
引言¶
这几年，大模型领域的新名词几乎是成批出现的。今天大家在聊 prompt engineering，明天开始谈 RAG，后天又冒出 skill、agent、context engineering、harness engineering、MCP。很多人越看越乱，不是因为这些词本身多难，而是因为它们并不处在同一层。有的词在讲模型，有的词在讲知识接入，有的词在讲工具调用，有的词在讲系统可靠性。只要层次一混，理解就会越来越费劲。(Anthropic)
真正有用的理解方式，不是把这些词当成一堆独立术语硬背下来，而是先建立一个整体认识：现代 AI 应用已经不是“一个模型回答一个问题”这么简单，而是“模型被放进一套工程系统里工作”。模型只是其中的一部分，外面还包着提示、上下文、知识库、工具、执行流程、评测机制和安全约束。只要你先接受这一点，后面的很多概念就会自然归位。(OpenAI)
先把总图看清楚¶
如果把一个 AI 应用比作一家公司里的员工，模型本身更像“大脑”或者“核心员工”，负责理解语言、推理和生成内容。但光有这个员工，公司并不能运转。它还需要资料库，需要工作手册，需要办公流程，需要权限系统，需要质检环节，也需要知道什么时候该查资料、什么时候该调用工具、什么时候该停下来请人确认。AI 工程里的大量新名词，其实就是在给这些外围部分命名。(OpenAI)
所以你可以先形成一个最重要的判断：凡是讨论“模型本身能力”的，通常属于底座层；凡是讨论“如何给模型信息”的，通常属于上下文和知识层；凡是讨论“如何让模型做事”的，通常属于工具和 agent 层；凡是讨论“如何让它稳定、安全、可验收”的，通常属于 harness engineering、guardrails、evals 这一层。理解这四层，后面所有术语基本都能放回正确位置。(Anthropic)
大语言模型¶
大语言模型，也就是 LLM，是现代 AI 应用的底座。它最核心的能力，是根据上下文预测接下来的 token，并在这个基础上表现出写作、问答、翻译、总结、代码生成、推理等能力。表面上看，它像是在“理解世界”，但工程上更准确的说法是，它非常擅长根据已有上下文生成高概率、结构合理、语义连贯的输出。(OpenAI开发者)
很多初学者最容易误解的一点，是把模型和应用直接画等号。其实模型并不天然知道你的公司制度，不天然会访问你的本地文件，也不会真正帮你点按钮、发请求、改数据库。模型只负责“想”和“说”，至于“看什么资料”“能用什么工具”“输出是否可信”，都要靠工程系统在外部补上。因此，现代 AI 应用的竞争，越来越不是单纯比谁模型更大，而是比谁围绕模型做出的系统更完整。(OpenAI)
Prompt Engineering¶
Prompt engineering 可以翻成提示工程。它最直接的意思，就是把给模型的说明写得更清楚、更有效，让模型更稳定地输出你想要的结果。OpenAI 的文档把它定义为编写有效指令的过程，其目标是让模型持续地产出符合要求的内容。(OpenAI开发者)
对于零基础读者来说，可以把 prompt engineering 想成“给新人布置任务”。如果你只说一句“帮我写一下”，模型就只能靠猜；如果你说清楚目标、对象、语气、格式、长度、禁区、示例，它就更容易做好。也就是说，提示工程并不神秘，本质上就是把模糊要求变成明确要求。只不过对象不是人，而是模型。(OpenAI开发者)
但提示工程也有明显上限。因为它通常是一次一写、一次一用，强依赖当前这轮对话。你今天把这套规则写进去，明天换个任务又要重写。随着系统变复杂，单靠 prompt 已经很难管理，所以后来才会出现 skill、context engineering 这类更系统化的做法。你可以把 prompt engineering 看成起点，而不是终点。(Anthropic)
Context Engineering¶
Context engineering 近一年特别热，因为越来越多团队意识到，真正影响模型表现的，不只是某一段 prompt，而是模型在这一轮任务里到底“看到了什么”。Anthropic 把 context engineering 讲得很明确：上下文是有限资源，关键不只是往里塞信息，而是如何筛选、组织、压缩、维护这些信息，让 agent 在有限窗口里依然能做出正确决策。(Anthropic)
这和 prompt engineering 的区别，可以用一句很直白的话来区分。Prompt engineering 更像是在写“任务说明书”，而 context engineering 更像是在搭建“工作台”。说明书只是工作台上的一个部分，工作台上还可能有历史对话、任务状态、外部检索内容、工具定义、用户偏好、摘要、错误日志等等。模型最终不是只看一段 prompt，而是在看整张工作台。(Anthropic)
为什么这个概念很重要？因为当任务变成多轮、多步骤、有工具、有记忆的时候，模型性能很大程度上不再取决于它本身有多强，而取决于你是否把正确的信息，在正确的时间，以正确的结构给了它。很多“模型明明很强却总做不好”的问题，根源其实不是模型笨，而是上下文工程没做好。(Anthropic)
Skill¶
Skill 最容易让人误会成“一个小模型”或者“一个插件模型”，其实它都不是。Claude Code 的官方文档写得很直接：skill 是通过 SKILL.md 和相关文件打包起来的一组指令，Claude 会把它当作自己的工具箱能力之一，在相关时自动使用，或者让用户手动调用。Anthropic 的完整指南则进一步说明，skill 本质上是一套打包成文件夹的任务说明，用来教 Claude 处理某类固定任务或工作流。(Claude)
所以，skill 的本质不是训练新模型，而是把“原本要你反复写进 prompt 的方法论”模块化、产品化。比如你希望模型总是按某种分析框架来答题，总是用某种格式输出，总是遵守某些边界条件，那么与其每次都重新解释一遍，不如把这些内容打包成一个 skill。这样做的好处，是复用性更强，也更稳定。(Claude)
为什么很多人会觉得 skill 很像模型？因为它用起来确实有那种“切换到某种专家模式”的感觉。原因不在于底层模型参数变了，而在于 skill 往往把角色、规则、流程、示例、边界、参考资料一次性都装进了上下文系统里。模型在这种环境下工作时，表现得就像“暂时变成了某种专家”。但说到底，变的是上下文，不是模型权重。(Claude)
Embedding¶
Embedding 可以理解成“把文本变成向量”。OpenAI 的文档把 embeddings 描述为一种数值表示，它能够捕捉文本之间的语义相关性，因此很适合用在搜索、聚类、推荐、分类等任务里。(OpenAI开发者)
对于新手来说，最简单的理解方式是这样的。人读文字时，能凭感觉知道两句话是不是在说同一件事；机器不能直接有这种感觉，所以就需要把文字转成一串数字，让“语义相近”的句子在数学空间里彼此靠近。这个数值化结果，就是 embedding。它本身不负责回答问题，也不负责生成文章，它更像是机器处理语义时的一种中间表示。(OpenAI开发者)
Embedding 在现代 AI 应用里很重要，因为很多知识检索系统都依赖它。只要涉及“从一堆文档里找到和当前问题最相关的内容”，大概率就会用到 embedding。你可以把它理解成 RAG 的一个基础零件。没有它，很多语义检索能力就很难高效实现。(arXiv)
Vector Database¶
向量数据库是和 embedding 配套出现的概念。既然文本已经被转成向量，那么这些向量总得存起来，并且要支持快速搜索。向量数据库就是专门干这件事的。它的核心能力不是传统数据库那种精确匹配，而是“找出在向量空间里最相近的内容”。(arXiv)
你可以这样理解二者关系。Embedding 负责把内容变成“机器可比较”的形式，向量数据库负责把这些结果高效保存并在需要时迅速找回来。前者解决表示问题，后者解决存储和检索问题。很多人一提 RAG 就只记得“模型会查资料”，但实际上查资料能不能查得准，很大程度取决于 embedding 做得怎么样，以及向量数据库里的索引和检索策略设计得怎么样。(arXiv)
RAG¶
RAG 是 Retrieval-Augmented Generation 的缩写，中文通常叫检索增强生成。这个概念最经典的来源，是 2020 年 Lewis 等人的论文。论文的核心思想很清晰：纯靠模型参数存知识会遇到三个问题，一是知识更新困难，二是难以给出信息来源，三是在知识密集型任务上容易出错。所以他们提出，把参数记忆和外部非参数记忆结合起来，在生成之前先检索相关资料，再基于检索结果生成答案。(arXiv)
如果用最通俗的话说，RAG 就是“让模型学会先查，再答”。传统模型更像闭卷考试，脑子里记住多少就答多少；RAG 更像开卷考试，先去翻资料，再组织答案。这样做有两个直接好处。第一，它能接入最新知识和私有知识，不用每次知识更新都重新训练模型。第二，它能让答案尽量建立在外部依据之上，减少凭空乱说的概率。(arXiv)
但要注意，RAG 不是“外挂一个文档就结束了”。真正的 RAG 是一整条链路。通常要先把文档切成块，再为每个块生成 embedding，然后存进向量索引里。用户提问时，也要把问题转成 embedding，再做相似检索，把最相关的内容送给模型，最后才由模型生成答案。这里面任何一个环节做不好，最终效果都会受影响。比如分块过粗，容易混入无关内容；分块过细，又可能丢上下文；检索不准，后面生成再强也没用。(arXiv)
还有一个常见误解，是把 RAG 和微调混为一谈。二者解决的问题不同。RAG 主要解决“模型缺少外部可更新知识”的问题，而微调主要解决“模型在某类任务上的行为不够稳定、不够贴合”的问题。一个偏知识接入，一个偏行为适配。它们可以配合使用，但不能互相替代。(arXiv)
Function Calling¶
Function calling 是很多人真正接触“AI 能做事”时会遇到的关键词。OpenAI 的文档把它定义得很明确：给模型一组可用工具的描述，模型根据用户请求判断是否要调用某个函数，并返回需要的参数；真正执行函数的是外部系统，执行结果再回传给模型，由模型整合成最终回答。(OpenAI开发者)
这里最关键的一点是，模型不会真的去运行你的函数。它只是提出“我建议调用这个工具，并且参数应该是这些”。真正发请求、查数据库、改日历、发邮件、执行代码的，是你外面的程序。这也是为什么 function calling 非常重要：它把模型从一个“只会说”的系统，推进到一个“会借助外部能力完成任务”的系统。(OpenAI开发者)
对零基础读者来说，可以把它理解成这样：模型像一个会安排工作的经理，工具像下面的执行部门。经理不会自己去仓库搬货，也不会自己手工录数据，但它会说“现在该让财务查一下”“让日历系统建一个会议”“让搜索工具找一下资料”。这就是 function calling 的本质。(OpenAI开发者)
MCP¶
MCP 是 Model Context Protocol 的缩写。Anthropic 在发布时把它定义为一种开放标准，用来让数据源和 AI 工具之间建立安全、双向的连接。官方还用了一个很形象的比喻，把 MCP 说成 AI 应用的“USB-C 接口”。这句话很有帮助，因为它直接点出了 MCP 的定位：它不是一个具体工具，而是一种通用连接标准。(Anthropic)
为什么会需要这种标准？因为在没有统一协议的时候，每接一个工具、每接一个数据源，都可能要单独写一套连接方式。这样一来，生态很难扩展，维护也非常麻烦。MCP 的意义在于，它试图定义一套统一的接入方式，让不同 AI 客户端都能更容易地连接不同工具服务。(Anthropic)
很多人会把 MCP 和 function calling 混在一起。其实二者不是一层概念。Function calling 解决的是“模型如何表达自己想调用哪个工具”，而 MCP 解决的是“这些工具和数据源如何被标准化接进系统”。前者更靠近模型交互，后者更靠近系统接口。一个像“经理提出调用请求”，一个像“公司各部门的接线规范”。(OpenAI开发者)
Workflow¶
Workflow 就是工作流。它的核心不是模型，而是步骤。OpenAI 关于构建 agents 的资料里，反复强调设计流程、编排流程和安全流程，因为很多真实业务任务都不是一句 prompt 能完成的，而是需要一连串固定步骤。(OpenAI)
你可以把 workflow 理解成“预先设计好的办事路线”。比如先读文档，再抽取信息，再检查格式，最后生成报告。每一步谁来做、什么时候做、失败怎么办、是否需要人工确认，都是提前写好的。工作流的优点是稳定、清楚、可测试，特别适合那些边界明确、重复性高的任务。(OpenAI)
它和 agent 的区别在于，workflow 里的路线基本是提前定好的，而 agent 更强调根据环境自己决定下一步。前者像走固定流程，后者像边走边判断。很多实际系统并不是二选一，而是把 agent 放进 workflow 里，或者让 workflow 成为 agent 可调用的一部分。(OpenAI)
Agent¶
Agent 是最近最火也最容易被滥用的一个词。OpenAI 的相关资料把它描述为一种能够围绕目标执行多步操作的系统，通常会涉及工具调用、状态维护、任务编排和安全控制。简单说，agent 不再只是“回答问题”，而是开始“持续做事”。(OpenAI)
普通聊天模型更像“你问一句，它答一句”。Agent 则更像“你给它一个目标，它开始自己推进”。比如你说“帮我整理这周会议并发给团队”，它可能先读取日历，再归纳重点，再生成邮件，再等待确认，再发送。这个过程中，它不是只完成一次生成，而是在多步循环里持续判断下一步要做什么。(OpenAI)
不过要特别注意，agent 不是越自主越好。现实里真正好用的 agent，往往不是“什么都自己决定”，而是“在明确边界内自动推进”。一旦权限、状态、上下文、失败处理没设计好，所谓 agent 很容易变成不稳定的自动化脚本。因此，agent 真正的难点，不只是让它会动，而是让它动得可靠。(OpenAI)
Fine-tuning¶
Fine-tuning 是微调。OpenAI 的文档说明，微调是在基础模型之上，使用你自己的任务样例继续训练，以便模型在特定任务上表现得更稳定、更贴合你的需求。官方还强调，在很多场景下，微调并不是替代 prompt engineering，而是和 prompt engineering 一起使用。(OpenAI开发者)
对于初学者来说，可以这样理解。基础模型像一个通识能力很强的人，但不一定完全适应你的写作风格、业务术语、固定格式或者特定任务习惯。微调就是用一批高质量示例，把它往你想要的方向“再教一遍”。这样做的结果，不是给它新增一个外部知识库，而是让它在某类行为上更稳定。(OpenAI开发者)
因此，微调和 RAG 的差别一定要分清。你有一套经常变化的文档，希望模型总能引用最新内容，这更像 RAG 问题；你希望模型固定用某种术语、某种格式、某种输出风格回答，这更像微调问题。一个解决“知道什么”，一个解决“怎么表现”。(arXiv)
Harness Engineering¶
Harness engineering 是最近开始频繁出现的新术语。它之所以让人摸不着头脑，是因为它不像 RAG 那样有一篇经典论文先把概念钉死，而更像是工程圈对某类实践逐渐形成的叫法。OpenAI 在 2026 年关于 Codex 的文章里，把 harness engineering 放在“agent-first”软件开发语境下讨论；Martin Fowler 的文章也把它和 context engineering 放在一起，强调其作用是帮助工程师建立对 coding agent 结果的信任。(OpenAI)
通俗一点讲，harness engineering 关心的不是“模型会不会想”，而是“模型在真实工程里怎么被管起来”。当你让一个 coding agent 去写代码时，真正麻烦的并不是它能不能生成代码片段，而是你如何规定它的工作方式。它能访问哪些文件，生成后要跑哪些测试，改动要不要通过 CI，失败了怎么回滚，哪些操作必须人工审批，输出结果如何记录，日志怎么留，评估如何做。这整套围绕模型的执行支架，就是 harness。(OpenAI)
所以你可以把 harness engineering 理解成“模型运行壳层工程”或者“执行支架工程”。如果 skill 更偏向能力包，context engineering 更偏向信息供给，那么 harness engineering 就更偏向执行控制和可靠性交付。它不直接提升模型智商，但它决定了模型在真实系统中能不能被放心使用。尤其在 coding agent 这类高风险场景里，这个概念会越来越重要。(OpenAI)
Evals¶
Evals 就是评测。OpenAI 的文档明确指出，AI 系统的输出具有非确定性，所以传统软件里那种“输入固定、输出固定”的测试方式并不够用。AI 评测需要更系统的方法，比如构造测试集、批量运行、定义评分标准、跟踪版本变化、比较不同提示和不同系统方案的效果。(OpenAI)
这件事为什么重要？因为 AI 系统最容易给人一种错觉：看起来偶尔答得很好，好像已经可用了。但只要一上真实业务，往往会暴露出大量不稳定性。没有评测，你可能根本不知道它在 100 个样本里到底成功了多少次，在哪类问题上最容易翻车，换一个 prompt 是不是反而变差了。Evals 的价值，就是把“感觉不错”变成“可量化地知道它行不行”。(OpenAI)
从这个角度看，evals 和 harness engineering 其实关系很近。前者更偏“怎么测”，后者更偏“怎么管和怎么交付”。二者共同指向同一个目标，就是让 AI 不再停留在演示效果，而能走向工程可信。(OpenAI)
Hallucination¶
Hallucination 通常翻译为幻觉，指的是模型生成看起来很像真的、实际上却不正确或没有依据的内容。虽然这个词不是今天这些新术语里最新的，但它始终是 AI 应用里最根本的问题之一。RAG、工具调用、评测、护栏、上下文工程，这些东西最后都在不同程度上服务于同一个目标：减少模型在关键任务中一本正经地说错话。(arXiv)
为什么模型会出现幻觉？根源并不只有一个。有时是训练数据里没有足够信息，有时是上下文不完整，有时是检索没命中正确资料，有时是模型为了保证回答流畅，宁可补全也不愿承认不知道。所以减少幻觉，从来不是一句“换个更强模型”就能彻底解决，而往往要靠整套系统一起配合。(arXiv)
这些概念之间的关系¶
现在把这些概念重新放回同一张图里，会清楚很多。大语言模型是底座，负责推理和生成。Prompt engineering 和 context engineering 负责告诉模型该怎么工作、该看到什么。Skill 是把一套可复用的任务规则和方法封装起来。Embedding 和向量数据库负责给知识检索打基础。RAG 负责把外部知识接进来。Function calling 和 MCP 负责把外部工具和系统接进来。Workflow 和 agent 负责让任务从“回答一次”走向“持续执行”。Fine-tuning 负责让模型在某类任务上更稳定。Harness engineering 和 evals 负责让整套系统变得可控、可测、可交付。(Anthropic)
你会发现，它们并不是互相替代的关系，而是逐层叠加的关系。真正成熟的 AI 应用，往往不是只用了某一个热门名词，而是把这些层次中的若干部分组合在一起。比如一个企业知识助手，可能同时用了 prompt engineering、context engineering、RAG、function calling、workflow、evals。一个 coding agent，则可能再往上叠加 skill、MCP、harness engineering 和更严格的测试约束。(OpenAI)
初学者最该记住的判断方法¶
以后你再看到新的 AI 名词，不要先被名字吓到。先问自己四个问题。这个词是在讲模型本身，还是在讲模型外面的系统。它是在解决知识问题，还是在解决执行问题。它是在解决“怎么给信息”，还是在解决“怎么做事”。它是在提升能力表现，还是在提升可靠性和交付性。只要先问这几个问题，大多数术语都能很快归类。(Anthropic)
说到底，现代 AI 工程的变化方向非常明确：模型依然重要，但真正决定应用价值的，越来越是围绕模型搭建的系统。谁能把知识接入、工具使用、上下文管理、执行控制和评测闭环做扎实，谁就更可能把“看起来聪明的模型”变成“真正可用的产品”。这也是为什么你会感觉新名词越来越多，因为行业正在从“研究模型”走向“建设系统”。(Anthropic)
结语¶
如果只记一句话，那么最值得记住的是这一句：今天的大模型应用，核心已经不只是模型，而是模型加上一整套围绕它运转的工程结构。Skill 不是模型，RAG 不是模型，agent 也不是模型，harness engineering 更不是模型，它们共同组成了现代 AI 应用的外部骨架。理解了这一点，再看这些术语时，你就不会觉得它们彼此打架，而会发现它们其实是在回答同一个问题：怎样把模型变成真正可靠、真正可用、真正能落地的系统。(Anthropic)