LLM 术语，不讲 Buzzword

围绕 LLM，在非常短的时间里形成了一整套自己的词汇：Tokens、Parameters、Context Windows、Reasoning Models、Agents、RAG、MCP、Open Weights、Inference、Prompt Caching、Mixture of Experts。然后在这些词中间，某个厂商还会再卖给你一些 Credits。

问题并不在于这些词毫无意义。恰恰相反，很多词描述的是非常真实、也很重要的技术概念。另一些则属于产品术语、分类方式或者计费模型。还有一些来自研究和工程实践，但现在被使用得如此广泛，以至于两个厂商说同一个词时，指的并不一定完全是同一件事。

结果就是：这整个领域很容易看起来像一个全新的技术宇宙，实际上其中很多东西都可以解释得非常简单。在继续深入 Agentic Work 之前，我们最好先把这些 Buzzword 拆开看一看——不是为了嘲笑这些词，而是为了后面讨论时，大家至少知道彼此到底在说什么。

AI – Artificial Intelligence

Artificial Intelligence，也就是人工智能，首先是一个非常宽泛的总称。它包括那些能够处理我们通常会与感知、语言处理、规划、模式识别、问题解决或决策等能力联系起来的计算机系统。

一个国际象棋程序可以属于 AI，一个图像识别系统可以属于 AI，Large Language Model 当然也可以属于 AI。这个区别很重要，因为今天很多人说“AI”时，实际想表达的往往是 LLM 或 generative AI。

AI 并不自动等于 LLM。LLM 只是 AI 模型中的一个特定类别。

Machine Learning

Machine Learning 指的是这样一类方法：我们不再把所有目标行为都写成明确的规则，而是通过数据来调整一个模型，让它从数据中学习相关的模式。

在传统软件里，一个极度简化的过程可以这样理解：

输入
↓
人写下的规则
↓
输出

而在 Machine Learning 中，一部分决策逻辑会在训练过程中从数据里形成。这并不意味着计算机突然开始自己决定“我要学什么、怎么学”。数据、模型架构、训练方法、优化目标和评估方式等内容，依然由人来决定。

Deep Learning 又是 Machine Learning 的一个子领域，它使用具有很多处理层的神经网络。现代 LLM 就属于这一类。

Generative AI

Generative AI 指的是能够生成新内容的 AI 系统。它可以生成文本、图像、音频、视频、程序代码，或者这些内容的组合。

这里的“新”并不自动意味着人类意义上的创造力。生成模型会根据训练中学到的结构以及当前输入来产生输出。

一个能够组织文字回答问题的 Chatbot 属于 Generative AI。根据描述生成图片的图像模型也属于 Generative AI。相比之下，一个只判断照片里有没有猫的系统，就不一定是生成式系统。

Model

在 AI 讨论中说到 Model 时，简单来说，我们指的是一个通过学习得到的数学系统，它可以根据输入产生输出。

训练过程中，大量内部数值会被不断调整。这些数值与模型架构一起，决定了模型之后如何响应新的输入。

但日常使用里，“Model”这个词其实有一点模糊。厂商给一个 Model 起名字时，实际指的往往不只是某种架构和一组 Weights。Post-Training、Tokenizer、配置，甚至某些特定的 Serving 设置，也可能影响我们最终体验到的“这个模型”。

所以，即使两个模型的规模听起来很接近，它们在技术上和质量上也并不一定可以直接比较。

Foundation Model

Foundation Model 是指在广泛数据上训练，并且之后可以作为多种不同任务基础的模型。这个概念尤其受到 Stanford Center for Research on Foundation Models 的推动。 [2]

关键并不在于某个固定的参数规模，而在于模型所扮演的角色：它是一个通用基础，之后可以通过 Prompting、Post-Training、Fine-Tuning 或额外系统被用于具体任务。

很多现代 LLM 都是 Foundation Model，但两个概念并不是同义词。Foundation Model 也可以覆盖语言以外的其他 Modalities。

LLM – Large Language Model

Large Language Model 就是大型语言模型。今天我们在 Chat 和 Coding 场景里讨论的生成式 LLM，会把信息处理成 Tokens，并且通常一步一步地产生输出。

极度简化之后，大致像这样：

当前 Context
↓
评估可能的下一个 Token
↓
确定下一个 Token
↓
加入 Context
↓
重复

一个非常常见的误解是：LLM 就像一个巨大数据库，里面提前存好了完整答案。它并不是这样工作的。一个模型回答法国首都是什么时，通常不是从传统表格里直接读取完整句子“巴黎是法国的首都”，而是根据当前 Context 和训练过程中学到的结构来逐步生成答案。

这并不否认知识和关系可以以某种形式存在于模型参数中。只是说，LLM 并不是一个传统意义上的查表系统。

Transformer

Transformer 是一种神经网络架构。2017 年发表的 Attention Is All You Need 介绍了这种架构，并且深刻影响了现代语言模型的发展。 [1]

它的核心组成之一是 Attention 机制。非常简单地说，当模型处理某个 Token 时，Attention 可以帮助它衡量输入中哪些其他部分对于当前计算更加重要。

为了理解后面的内容，并不需要掌握其中的数学。但有一个区别必须知道：

LLM 和 Transformer 不是同义词。 很多现代 LLM 完全或部分基于 Transformer 架构。Transformer 是一种架构，而 LLM 描述的是围绕语言构建的一类模型。

Parameters

Parameters 是模型内部可调整的数值，它们在训练过程中被学习出来。因此我们经常会在模型描述中看到 7B、70B、600B 这样的数字。这里的 B 表示英文 billion，也就是十亿。

所以一个 70B 模型大约有 700 亿个 Parameters。

但单独看这个数字，其实很难判断模型真正的质量。架构、训练数据、数据质量、训练方法、Post-Training，以及 Inference 时可用的计算资源，都会影响模型的实际能力。

更多 Parameters 并不自动等于更好的模型。

到了 Mixture-of-Experts 模型里，这个简单的总参数数字会更难解释。我们后面会专门说。

Weights

Weights，也就是权重，是神经网络内部学习得到的数值。它们会影响内部信号如何被组合，并且在训练过程中不断调整。

在日常 LLM 讨论中，Weights 和 Parameters 经常几乎被当成同义词使用。严格来说两者还是有区别的：Weights 属于 Parameters，但模型也可能存在其他类型的可训练 Parameters。

当一个厂商称模型为 Open Weights 时，通常指的是模型训练完成后的权重可以被获取。这个词到底意味着什么、又不意味着什么，我们后面还会继续解释。

Training

Training 是模型学习或改变 Parameters 的过程。

极度简化之后，可以理解为：模型处理大量训练样本，做出预测，计算自己与训练目标之间的偏差，然后一步一步地调整 Parameters。这个过程会被反复执行很多次。

对于本文后面的概念，我们先记住一个简单区别就够了：

Training
数据
↓
优化
↓
被改变的模型参数


Inference
输入
↓
已经训练好的模型
↓
输出

Training 会改变模型。Inference 使用已经训练好的模型。

真正的现代训练流程当然比这张小图复杂得多，但用来区分概念已经足够。

Pre-Training 和 Post-Training

讨论现代 LLM 时，经常会遇到 Pre-Training 和 Post-Training 这两个词。

在 Pre-Training 阶段，首先会得到一个通用的 Base Model。它通过非常大规模的数据学习广泛的结构、关系和能力。

之后还可能继续进行额外的训练阶段。Post-Training 是一个总称，用来描述让 Base Model 更好地遵循指令、解决特定类型任务或者表现出某些期望行为的方法。其中可以包括 Fine-Tuning 以及不同形式的 Reinforcement Learning。

这个区别非常重要，因为两个拥有相同基础架构、Pre-Training 也相似的模型，在不同的 Post-Training 之后，实际表现可能完全不同。

Fine-Tuning

Fine-Tuning 指的是通过额外训练，有针对性地调整一个已经训练完成的模型。比如可以让模型更适合某些任务、专业领域、输出格式或者行为方式。

这里最关键的词就是 Training：Fine-Tuning 会改变模型参数。

这也是它和 Prompting、RAG 或典型 Memory 系统的根本区别。如果我每次请求都把自己的架构规则一起发给模型，我并没有 Fine-Tune 它。Agent 从项目数据库里加载信息，也不是 Fine-Tuning。

额外的 Context 并不等于 Fine-Tuning。

Inference

Inference 指的是使用一个已经训练完成的模型。我们给它 Input，让它计算出 Output。

"给我解释 Dependency Injection。"
↓
已经训练好的模型
↓
生成的回答

在正常的 Inference 中，模型的基础 Weights 不会自动发生变化。所以，一个很长的 Chat 并不会自动继续训练 Base Model，一个普通 Prompt 也不会，一个经典的 RAG 系统同样不会。

即使某个产品“记住”了关于我的某些信息，也并不意味着它一定修改了模型权重。

Inference 是使用模型，而不是自动重新训练模型。

后面讨论 Context、Memory、Retrieval 和 Agent 时，这个区别还会不断出现。

Token

Token 是语言模型使用的一种处理单位。它并不自动等于一个单词，也不自动等于一个字符。

一个常见词可能只占一个 Token，而一个罕见词或复合词可能被拆成多个 Tokens。标点符号、单词的一部分也可能成为独立 Token。

具体怎么拆，取决于 Tokenizer。于是不同模型处理同样一段文字时，得到的 Token 数可能不同。同一句话换成不同语言，需要的 Token 数也可能差很多。 [3]

Tokens 会影响 Context 大小、最大输出长度、计算量、API 限制，以及很多产品的计费。

但 Token 首先是一个技术单位，不是一种货币。

Tokenizer

Tokenizer 会把文本转换成模型真正使用的 Token 单位。

一整句话在内部并不会简单变成“中文词语列表”或者“英文单词列表”，而会转成一组 Token IDs。Tokenizer 有自己的 Vocabulary，以及把文本切分成这些单位的方法。

它因此是人类可读文本与模型之间非常重要的一层接口。

Input Tokens

Input Tokens 是进入一次模型请求的 Tokens。它们往往远远不止用户屏幕上看到的那一句话。

根据具体产品，System Instructions、之前的 Chat History、Tool 描述、文档、搜索结果、Memory 条目或者项目文件都可能一起进入 Input。

所以，看起来只有一句很短的用户问题，实际送进模型的 Input 可能非常大。

Output Tokens

Output Tokens 是模型在生成过程中产生的 Tokens。在普通 Chat 里，其中大部分通常对应我们最后看到的文字。

一些 Reasoning 系统还可能额外统计内部的 Reasoning Tokens。这些 Tokens 不一定完整显示在最终回答里。它们如何被计算、是否可见、如何计费，都取决于具体厂商和模型。 [3]

所以，一段很短的最终回答并不一定意味着 Inference 过程中只进行了很少的计算。

Cached Tokens

现代 LLM 服务可以缓存重复出现的 Input 部分。如果很多请求都使用同一个很长的 System Prompt 或相同 Tool 描述，那么已经做过的一部分计算可能可以被重复利用。

厂商可能会把这些重复利用的内容显示为 Cached Tokens，并在技术上或者商业上采取不同处理。比如 OpenAI 会把 Cached Tokens 作为 Input Token Usage 的一部分展示，其他主流厂商也提供不同形式的 Prompt 或 Context Caching。 [3]

重点是：

Cached Tokens 依然是 Tokens。

缓存不会把这些内容自动变成永久模型知识，也不会自动扩大 Context Window。它可以减少重复计算，从而降低延迟或者成本。

Prompt Caching

Prompt Caching 指的是在多个请求之间重复利用已经处理过的 Prompt 部分。

当很多请求都以同样的长前缀开始时，这尤其有用，比如大量 Agent Instructions、Tool Schemas 或文档。合适的系统可以复用之前计算好的中间状态，而不是每次都从头计算。

缓存能保留多久、哪些部分可以缓存、如何收费，都是厂商自己的产品逻辑。

所以，Prompt Caching 既不是 Memory，也不是额外 Training。

KV Cache

KV Cache，也就是 Key-Value Cache，是很多 Transformer 模型在 Inference 过程中使用的一种技术优化。

自回归模型一个 Token 接一个 Token 地生成内容时，KV Cache 会保存 Attention Layers 里已经计算过的一部分状态，这样新 Token 出现时就不需要把之前所有内容重新完整计算一遍。 [16]

为了理解概念，我们只需要记住这一区别：KV Cache 是模型 Inference 内部的机制，而 Prompt Caching 是系统或厂商提供的更高层缓存概念。 两者可以有关联，但不是一回事。

Prompt

Prompt 就是我们用来影响模型的输入或指令。

它可以只是一个简单问题：

Event Loop 是什么？

但 Prompt 也可以包含 Requirements、Examples、Data、Rules 和 Constraints。尤其是在 Software Engineering 中，一个复杂任务的好 Prompt，往往越来越像一份 Specification：

这是目标。这是 Context。这些边界必须遵守。这是我期待的结果。

所以，Prompting 实际上没有 Prompt Engineering 这个词曾经听起来那么神秘。

System Prompt

很多 LLM 应用都会使用额外的 Instructions 来规定一次交互的基本框架。它们通常被称为 System Prompt。

System Prompt 可以规定系统应该扮演什么角色、有哪些 Tools 可用、需要遵循什么规则，或者输出必须采用什么格式。这些内容不一定全部对用户可见。

System Prompt 可以非常强地影响模型行为，但它依然不是一个数学证明，无法保证所有规则在所有情况下都会被百分之百遵守。

Context

Context 简单来说，就是模型在当前一次处理过程中能够获得的信息。

其中可以包括用户请求、System Instructions、之前的 Chat History、文档、Tool Results、Memory 内容或者 Retrieval Results。

所以 Context 与训练过程中形成在模型 Parameters 里的知识不是一回事。如果我把一个模型从未见过的新 API 文档放进 Context，它依然可以利用这份文档来工作。

请求结束之后，基础 Weights 依然没有因此发生变化。

Context 不是 Training。

Context Window

Context Window 描述的是一个模型或者具体 Model Endpoint 在一次处理过程中可以支持多少 Context。它通常以 Tokens 作为单位。

所以，一个 128k Context Window 并不是 128,000 个单词，而是大约 128,000 个 Tokens。Input 和 Output 如何共同占用这个限制，取决于具体模型和 API 设计。

大的 Context Window 非常有用，但它并不自动意味着其中每条信息都会被同样可靠地使用。著名的 Lost in the Middle 研究早期就展示过：在 Long Context 中，相关信息所在的位置会显著影响模型是否能够正确利用它。 [5] 后续研究和新模型已经显著改善了这类能力，但一个基本区别依然重要：

能放进 Context，和能可靠地利用 Context，是两种不同的能力。

Context Engineering

Context Engineering 指的是有意识地设计：为了某个任务，究竟应该把哪些信息提供给模型。

这远不只是写一个 Prompt。它还可以包括 System Instructions、相关文件、Tool 描述、Examples、Memory、Retrieval Results、当前 State，以及什么时候应该加载哪些信息的规则。

于是问题会从：

我怎么写出完美 Prompt？

变成：

为了做出这个具体决定，模型真正需要哪些信息？又不需要哪些？

Context Engineering 不是新的模型架构，也不是新的训练方法。它主要是在做“围绕模型信息供给”的工程。

到了 Coding Agent 场景，这个概念尤其重要。

Probabilistic

LLM 是 Probabilistic Models。这并不意味着模型只是随便掷骰子。

对于下一步可能的延续，语言模型会计算一组值，从中得到不同候选 Token 的概率。一个极度简化的例子可能是：

"天空是……"

蓝色      0.61
今天      0.08
晴朗      0.07
绿色      0.01
...

这些具体数字是随便写的，但原理不是。不同的可能延续，在当前条件下会被模型赋予不同程度的可能性。

接下来究竟如何从这些候选里选出一个具体 Token，则是另一个问题。

Sampling

Sampling 指的是从可能的下一个 Token 中选出一个具体结果的方法。

系统可以永远选择概率最高的 Token，也可以在多个合理候选中进行 Sampling。为此存在不同策略和参数，例如 Temperature、Top-K 或 Top-P。 [4]

这也解释了为什么“Probabilistic”并不意味着每次请求都必须得到完全不同的答案。反过来，同一个 Prompt 也不保证每次一定得到完全一致的输出。

模型产生的是一组可能延续的分布；Decoding Strategy 决定这组分布最终如何变成一个具体序列。

Temperature

Temperature 会影响很多生成方法中，Token 选择到底多么集中在最可能的候选上。

较低的值通常意味着选择更加集中。较高的值会让其他候选获得更多权重，因此经常会产生更多变化。 [4]

常见的简化说法是：

低 Temperature = 正确，高 Temperature = 有创意

这太简单了。Temperature 首先改变的是分布或者选择过程。一个结果在专业上因此变好还是变坏，还取决于任务、模型以及 Decoding 方法。

同样，temperature: 0 也不应该被普遍等同于“绝对 Deterministic”。不同 API 和 Inference 系统可能存在不同实现，流水线里的其他部分也可能带来变化。Anthropic 明确记录了这一限制。

Reasoning

Reasoning 是一个特别容易让技术含义和 Marketing 混在一起的词。

在研究和产品里，它今天通常用来描述这样一些模型或方法：面对更复杂的问题时，在 Inference 阶段投入更多计算。一个系统可能计算更多中间步骤、生成多个候选、检查不同解法，或者增加额外的 Search 和 Verification。

因此我们还会看到 test-time compute、inference-time compute、reasoning tokens、thinking tokens 这些词。它们并不完全等价。

Test-Time 或 Inference-Time Compute 是一个更宽泛的概念：Training 已经结束之后，在处理具体任务时增加计算。研究表明，在合适任务上，更多 Inference Compute 可以提升解题质量，但效果高度依赖具体方法和问题。 [6][7]

Reasoning Tokens 或 Thinking Tokens 则更常是某种具体实现或产品层面的术语，用来描述内部处理步骤。

所以最重要的一点其实不是技术，而是语言：

Reasoning 并不自动等于人类的思考、意识或者理解。

这个词描述的是 AI 系统的一类能力或者处理方式，而不是证明模型内部发生了人类式的思维过程。

Hallucination

当 LLM 生成的内容与事实、来源或者给定 Context 不一致，却依然听起来非常可信时，我们通常会称之为 Hallucination。

在软件开发里，它可能是一段调用了根本不存在的 Library 方法的代码，也可能是一套被模型凭空发明的 API，或者一篇标题听起来非常真实、实际上从未发表过的论文。

所以，并不是每一个错误都自动属于 Hallucination。模型可能误解 Requirement、算错一道题、使用了真实但已经过时的 API，或者做出一个很差的架构决定。这些都可能是错的，但属于不同类型的问题。

这个词本身也是一种比喻。它不意味着模型真的像人一样“看见”了什么东西。

Noise

Noise 在 LLM 场景里并不是一个定义清晰的科学术语。开发者更多把它当成一个非常实用的说法：Output 看起来很合理，但对真正任务的价值很低。

它可以是一段完全没必要那么长的解释，可以是一堆没人要求的额外抽象，也可以是 Agent 顺手改了一堆与你原本任务无关的东西。甚至可以是五段非常自信的文字，最后真正能用的只有一句。

在 Coding Agent 场景里，Noise 还可能意味着：本来只要求一个小改动，Agent 却顺便做了很多“优化”，结果反而增加了 Review 成本。

所以这个词更像是在描述我们感受到的 Signal-to-Noise Ratio，而不是模型内部某个精确定义的机制。

Embedding

Embedding 是信息的一种数值表示。文本、图像或者其他内容，会被表示成由数字组成的 Vector。

对这篇文章来说，只需要理解一个实际效果：合适的 Embedding Model 可以让语义上相似的内容，在生成的 Vector Space 里距离更近。

这样一来，应用就可以按照“意义是否相似”进行搜索，而不只是寻找完全一样的关键词。

因此 Embeddings 经常被用于 Semantic Search 和很多 RAG 系统。但它并不是“把一整篇文档换成数字写法以后得到的一份可读副本”。

RAG – Retrieval-Augmented Generation

Retrieval-Augmented Generation 把信息检索和生成式输出结合在一起。

基本原理非常简单：

问题
↓
检索相关信息
↓
把检索结果放进 Context
↓
LLM
↓
回答

最早的 RAG Paper 描述了参数化模型知识与外部检索信息的结合。 [8]

今天 Retrieval 的实现方式可以非常不同：Embeddings 与 Vector Search、传统全文搜索、数据库、API，或者这些方法的组合。

所以，RAG 并不自动等于 Vector Database。

对于我们现在区分概念来说，更重要的是：

RAG 通常不会重新训练模型。 检索到的信息是在运行时提供给模型，并且一般通过 Context 参与当前处理。

Tool Calling / Function Calling

使用 Tool Calling 时，模型可以生成结构化输出，让周围的应用去调用一个外部 Function 或 Tool。

例如，与其自己猜柏林天气，模型可以输出类似：

Tool: getWeather
Argument:
  city: Berlin

真正的操作之后发生在语言模型之外。Runtime 或应用执行这个 Function，再把结果返回给模型。有些平台会直接在服务器侧提供这种 Tool，但基本原理一样。 [9]

因此，一个 LLM 并不会因为“它是 LLM”就天然拥有互联网、Shell 或文件系统访问权限。这些能力来自整个系统：Model、Tools 和 Permissions 的组合。

Computer Use

Computer Use 把 Tool Calling 的思路扩展到了图形用户界面。

模型或者 Agent 可以获得 Screenshots，然后请求执行点击、键盘输入之类的操作。真正执行这些动作的，依然是受控的 Runtime Environment。

这样一来，即使某个应用没有合适 API，Agent 也可能通过 UI 来操作它。

但 Computer Use 扩大的不仅是系统能力，也包括风险。如果一个 Agent 真的能够点击、输入甚至提交表单，那么它需要的 Security 和 Approval Mechanisms，就和一个只能输出文字的模型完全不同。

Memory

Memory 是 LLM 产品里最不精确的词之一。

一个系统可以把用户偏好存在数据库。一个 Coding Agent 可以持久化项目知识。一个 Chat 产品可以搜索历史对话，并把相关信息重新加载进 Context。一个 Agent 也可以在两个执行步骤之间保存自己的 State。

根据产品不同，这些机制都可能被叫作 Memory。

它们经常有一个共同点：信息被保存在 Base Model 之外或者附加系统中，之后需要时再重新提供给模型。

所以 Memory 并不自动意味着模型 Weights 被改变。

一个系统完全可以通过“在外部保存信息，然后下次请求时重新放回 Context”的方式，看起来像是真的“记住了”什么。

Agent

对于 Agent，研究界、厂商和开发者之间并没有一个所有人都完全一致采用的技术定义。

对我们来说，一个实用定义已经足够：

Agent 把 Model、Goal、Context 或 State、Tools，以及一个可以连续执行多个步骤并再次处理结果的流程组合在一起。

一个简单的 Agentic Loop 可以这样理解：

目标
↓
评估当前情况
↓
选择下一步动作
↓
执行 Tool
↓
观察结果
↓
重新评估
↓
...
↓
完成

一个有用的区别是：这个过程里有多少步骤是固定写死的，又有多少下一步决策由模型动态完成。比如 Anthropic 会区分更明确预定义的 Workflows，以及由模型更加动态控制流程的 Agents。 [12]

真实产品里的边界当然是连续的。并不是每一个写着“Agent”的产品，都具有同样程度的 Autonomy。

Coding Agent

Coding Agent 是一个为软件开发准备了相应环境和 Tools 的 Agent。

它可以搜索 Repository、读取和修改文件、启动 Compiler 或 Linter、运行 Tests、检查 Git Diff，或者执行 Shell Commands。

这让它和“只对你粘贴进来的 Code Block 做回答”的普通 Chat 有本质区别。Coding Agent 可以再次观察自己的修改结果：

修改代码
↓
运行 Tests
↓
读取错误
↓
分析原因
↓
修复代码
↓
再次测试

这种 Feedback Loop 是现代 Agentic Coding Workflows 的核心组成部分之一。

Subagent 通常只是另一个 Agent，主 Agent 会把更小、更明确的子任务交给它。这里同样不存在一种唯一标准化的架构。

Agent Harness

Agent Harness 指的是包围在模型外部的 Runtime 和 Control Layer。

这一层可以负责建立 Context、控制 Tool Calls、保存 State、检查 Permissions、请求 Human Approval，以及组织多步骤 Agent Loops。Microsoft 目前也用类似方式描述 Agent Harness：它是让 Language Model 能够真正进行较长时间 Agent 工作的 Runtime Scaffolding。 [13]

这个区分很有帮助：

Model
=
产生输出与决策

Harness
=
组织 Context、Tools、State、
Permissions 与执行过程

Agent
=
由这些部分共同组成

如果两个 Coding 产品使用同一个 Base Model，却表现出非常不同的效果，其中很大一部分差异可能就来自 Harness。

Agentic AI

Agentic AI 是一个总称，用来描述那些不只产生一次回答，而是能更自主地朝某个目标持续工作的 AI 系统。

其中可以包含 Planning、Tool Use、观察中间结果、执行连续动作，以及根据结果调整后续步骤。NIST 等机构现在也会用这个词描述更 Autonomous、Goal-Directed 的 AI 系统。 [11]

但是，“Agentic”并没有一条清晰技术边界。一个只能从三个预定义 API Calls 中选择一个的系统，和一个能够长时间分析 Repository 并委派任务的 Coding Agent，差别非常大。可是在产品页面上，两者都可能被描述成 Agentic。

所以 Agentic 既不是一种新的模型架构，也不自动等于完全 Autonomy。

MCP – Model Context Protocol

Model Context Protocol，简称 MCP，用来标准化 AI 应用与外部能力或信息之间的连接。

截至 2026 年 9 月，2026-07-28 是当前 MCP Specification。这个版本的变化之一，是让协议核心更明显地朝 Stateless Request/Response Communication 方向发展。 [10]

但为了理解 MCP，最重要的并不是记版本号，而是知道它到底做什么。MCP Server 可以提供标准化的 Tools、Resources 和 Prompts，兼容的 Hosts 或 Clients 能够发现并使用这些能力。

简化后：

AI 应用
↓
MCP Client
↓
标准化协议
↓
MCP Server
↓
Tools / Resources / 外部系统

这样，不同 AI 产品就不需要为每一个 Tool 或 Data Source 都重新发明一套完全不同的集成方式。

MCP 不是模型，也不是 Agent。它也不自动等于 RAG 或 Memory。Agent 可以通过 MCP 调用 Tool，Retrieval System 可以通过 MCP 获取数据，Memory System 也可以通过 MCP 接入。

MCP 标准化的是连接。它不是使用这些连接的 Agent。

Frontier Model

Frontier Model 不是一种具体模型架构。

这个词通常用来描述处在当前能力前沿附近的高性能 General-Purpose Models。英国对 Frontier AI 的定义同样强调这个相对性质：它描述的是，在某一个时间点，能力达到或超过当时最先进系统水平的模型或系统。 [14]

这里最重要的是“某一个时间点”。

2023 年算 Frontier 的模型，到了 2026 年完全可能已经不在能力前沿。

所以 Frontier 描述的是相对于当前技术水平的位置，而不是某种具体技术结构。

Multimodal

一个 Multimodal 模型或系统，可以处理或者生成多种类型的信息。

典型 Modalities 包括文本、图像、音频和视频。一个模型可能同时接收文本和图片，但只输出文本。另一个可能既理解语音，也生成语音。

所以，“Multimodal”并不自动意味着这个模型可以同样好地读取和生成所有 Modalities。真正支持哪些 Input 和 Output，依然需要单独检查。

VLM – Vision Language Model 则是在这个范围里更具体的一类模型，主要指能够同时处理视觉信息和语言的系统。

Open Weights

在 Open-Weights Model 中，训练完成的模型 Weights 会被公开。只要 License、Software 和 Hardware 允许，就可以下载这些权重，并在自己的基础设施上运行模型。

但这并不意味着模型周围的一切都是开放的。Training Data 可能未知，Training Code 可能不存在，License 可能限制某些用途，完整训练流程也可能无法复现。

Open Weights 首先只表示 Weights 可以获得，并不意味着整个模型项目都是开放的。

Open Source

在传统软件里，Open Source 有非常成熟的定义。但把这个概念直接搬到 AI 系统上会复杂很多，因为除了 Source Code，还涉及 Model Parameters、Training Methods，以及有关 Training Data 的信息。

因此 Open Source Initiative 在 2024 年发布了 Open Source AI Definition 1.0。它要求使用、研究、修改和分享 AI 系统的自由，并对 Code、Parameters 和 Training Data Information 提出了相应要求。 [15]

这个定义并没有结束所有关于“Open Source AI”的争论，但至少提供了一个比产品页面上随便写个“Open”更精确的标准。

在技术讨论里，一个简单区别依然非常有用：

Open Weights 并不自动等于 Open Source。

Local Model

狭义上说，Local Model 是直接运行在本地设备或计算机上的模型，比如开发者 PC、Notebook 或 Workstation。

它应该和 Self-Hosted 区分开来。Self-Hosted Model 也可以完全由你控制，但可能运行在内部 GPU Server 或公司自己的 Cluster 上。

日常讨论中两个词经常会混用，但在技术讨论里，这个区别很有帮助：

local
=
运行在本地设备上


self-hosted
=
运行在我或组织控制的基础设施上

这两个词本身都不说明模型质量、License 或开放程度。Open-Weights Model 可以 Local 运行，但并不是必须这样运行。

MoE – Mixture of Experts

在 Mixture-of-Experts Model，简称 MoE 中，一些模型层包含多个子网络，这些子网络被称为 Experts。在处理某个 Token 时，一个 Router 会决定应该使用其中哪些 Experts。

这里的“Expert”不要理解得太字面。模型里不一定真的存在一个清晰可解释的“Java Expert”“数学 Expert”或者“中文 Expert”。从技术上看，它们首先只是不同的子网络，模型会在它们之间进行 Routing。

一个著名例子是 Mixtral 8x7B，它对于每个 Token 只选择 8 个 Experts 中的 2 个。 [17]

简化后：

Token
↓
Router
↓
┌────────┬────────┬────────┬────────┐
Expert A Expert B Expert C Expert D
   ✓               ✓
↓
被选中的 Experts 继续计算

这样，模型可以拥有非常多的总参数，而不需要每个 Token 都使用全部 Experts。

Total Parameters

Total Parameters 表示一个 MoE 模型的全部参数数量。其中也包括那些在当前 Token 处理过程中没有被选中的 Experts 的参数。

所以，这个数字能说明整个模型规模，但不能直接说明每一步处理时究竟有多少 Parameters 真正参与计算。

Active Parameters

Active Parameters 指的是某一条具体计算路径中实际参与处理的 Parameters。在 Sparse MoE 模型里，这个数字往往会明显小于 Total Parameters。

厂商具体怎么统计 Active Parameters，最好查看 Model Card 或 Paper，因为除了 Experts 之外，通常还存在多个共享的模型部分。

关键区别是：

非常多 Total Parameters
≠
每个 Token 都使用全部 Parameters

因此，一个 MoE 模型只告诉你“600B Parameters”，但不给其他信息，这个数字的解释价值远没有第一眼看起来那么大。

Quantization

Quantization 会降低模型数值在保存或部分计算时使用的数值精度。目标通常是减少内存占用和计算成本。

很多模型本来就会以 FP16 或 BF16 运行。更激进的 Quantization 可以把 Weights 压到 8 Bit、4 Bit 或更紧凑的表示。根据具体方法，Inference 的其他部分也可能被 Quantize。 [16]

这对于 Local Models 特别有意义。一个以完整精度无法放进显存的模型，在 Quantized 之后可能就可以运行。

这个过程中可能产生 Quality Loss。损失有多大，取决于模型、方法、Bit Width 和具体任务。

所以：

16 Bit 变 4 Bit = 只剩四分之一“智力”

这种理解是错的。数值精度和模型能力并不是这样线性变化。

Quantization 本质上是一个 Engineering Trade-off：Memory、Compute、Hardware Requirements 和可能的 Quality Change 之间需要取舍。

Credit

最后来到一个与 LLM 内部工作方式关系意外地不大的词。

Credit 并不是语言模型的基本技术单位。Credits 属于厂商定义的 Product 或 Billing Logic。

一个 Credit 可以代表一定数量的 Tokens，也可以代表一次 Tool Call、一分钟 Compute Time、一次 Model Request，或者这些东西的任意组合。一个 Credit 到底是什么意思，必须看具体产品。

仅仅看到：

这个产品包含 10,000 Credits。

几乎无法推断你真正可以使用多少 LLM 资源。

术语	含义
Token	模型使用的技术处理单位
Credit	厂商自己定义的使用或计费单位

Tokens 属于技术。Credits 属于产品或商业模型。

厂商当然可以根据 Tokens 来计算 Credits。但这并不会让 Credits 变成 Tokens。

从 Buzzword 到共同语言

读到这里，我们当然还没有完成一门 Machine Learning 专业课程。这本来也不是目标。

但至少现在，我们可以把 Model Cards、产品页面和开发者讨论中不断出现的一些词分开来看。模型会经过 Training，然后在 Inference 中被使用。它会在 Context 内处理 Tokens，Tokenizer 决定文字如何被拆成这些单位，Sampling 会影响不同可能延续最终如何变成一个具体输出。Reasoning 可以包含额外的 Inference Compute，但这并不意味着人类式思考。

RAG 会把外部信息带进 Context，Memory 可以把信息保存在模型之外，Tools 给 AI System 提供行动能力。Harness 负责组织这些环境，而 Agent 可以在多个步骤里使用它们。MCP 则可以标准化这些系统与外部能力之间的连接方式。

至于 Credits？它们可能只是决定厂商还能让我们继续玩多久。

这样一来，这套术语至少没有那么神秘了；如果之后想查某个概念，可以在本系列的术语表中找到。接下来的问题会更难一点：如果一个厂商告诉我们“某个 Coding Agent 可以解决一定比例的真实 Software Tasks”，这个数字到底是怎么来的？

Benchmark 是什么？SWE-bench 实际测了什么？Verified、Pro 或 Pass@k 又是什么意思？为什么一个 Benchmark Score 并不等于“这个模型可以替代百分之多少的软件开发者”？

下一篇文章，我们就从这里开始。

参考资料

[1] Ashish Vaswani, Noam Shazeer, Niki Parmar et al.: Attention Is All You Need. Advances in Neural Information Processing Systems 30, 2017. arXiv: 1706.03762.

[2] Rishi Bommasani, Drew A. Hudson, Ehsan Adeli et al.: On the Opportunities and Risks of Foundation Models. Stanford Center for Research on Foundation Models, 2021. arXiv: 2108.07258.

[3] OpenAI: 关于 Tokens、Usage、Reasoning Tokens 与 Prompt Caching 的技术文档，2026 年版本。

[4] Hugging Face Transformers: Generation / GenerationConfig. 技术文档，2026 年版本。

[5] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang: Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12, 2024, pp. 157–173. DOI: 10.1162/tacl_a_00638.

[6] Charlie Snell, Jaehoon Lee, Kelvin Xu, Aviral Kumar: Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Parameters for Reasoning. International Conference on Learning Representations, 2025.

[7] Mohsen Hariri et al.: Test-Time Scaling in Reasoning LLMs: Inference Regimes, Evaluation, and Reproducibility. Preprint, 2026. arXiv: 2608.04001.

[8] Patrick Lewis, Ethan Perez, Aleksandra Piktus et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33, 2020. arXiv: 2005.11401.

[9] Anthropic: Tool use with Claude 与 How tool use works. 技术文档，2026 年版本。

[10] Model Context Protocol: Model Context Protocol Specification 2026-07-28 及相关 Release Notes，2026 年 7 月 28 日。

[11] National Institute of Standards and Technology: Agentic AI. NIST, 2026.

[12] Anthropic: Building Effective Agents. 技术文档。

[13] Microsoft: Agent Harness. Microsoft Agent Framework Documentation，2026 年 8 月版本。

[14] UK Department for Science, Innovation and Technology: Frontier AI: capabilities and risks – discussion paper. 2025 年更新版本。

[15] Open Source Initiative: The Open Source AI Definition – Version 1.0. 2024，2026 年 9 月仍为稳定版本。

[16] Hugging Face Transformers: 关于 Quantization、Cache strategies 与 How caching works 的技术文档，2026 年版本。

[17] Albert Q. Jiang et al.: Mixtral of Experts. 2024. arXiv: 2401.04088.