AI 基础术语速通 · 课程预备 - 企业级 AI Native 开发实战AI 基础术语速通 · 课程预备
预计阅读 15 分钟
AI 基础术语速通#
如果你第一次系统学 Agent 工程，先把这 12 个词过一遍：Token、Context Window、Prompt、Temperature、模型大小、Reasoning、RAG、Fine-tuning、多模态、Agent、蒸馏、幻觉。
嗨！我是 BlueLeap 小老师，今天带你 15 分钟弄懂 Agent 工程师必会的 12 个 AI 术语
0. 一句话先讲明白#
这节不是 AI 百科，而是给后面课程扫清“听不懂术语”的障碍。你不需要先懂 Transformer、反向传播或 GPU 集群；但你需要知道 token 为什么会烧钱、context 为什么会爆、prompt 为什么能改变 Agent 行为、Tool use 和 MCP 为什么是 Agent 工程的核心。
读完这节，你再看 Claude Code、Codex、Grok Build、MCP、ACP、A2A、Sandbox，会少很多“概念卡顿”。
1. Token：模型真正读写的单位#
小老师提醒：先学 token，再学成本控制；否则你很难解释为什么一次长任务会突然变贵。
Token 是模型处理文本的基本单位，不等于字符，也不等于中文“字”。英文里，一个常见单词可能是 1 个 token，也可能被拆成多个 token；中文里，1 个汉字通常约等于 1 个 token，但不同 tokenizer 会有差异。粗略估算时，可以记：英文 1 token 约 0.75 个单词，中文 1 个汉字约 1 个 token。
API 按 token 计费，是因为模型真正计算的是 token 序列。你发给模型的是 input tokens，模型生成的是 output tokens；两者都占算力和显存，但输出通常更贵，因为生成时需要一步步预测下一个 token。
本地估算可以用 tokenizer。OpenAI 系常用 tiktoken，Anthropic 系 tokenizer 规则不同，但估算思路一样：先把文本切成 token，再乘以单价。快速感知可以这样跑：
和钱挂钩的例子：如果某模型 input price 是 $3 / 1M tokens，你塞进去 1M input tokens，input 成本就是 $3。一篇 5000 中文字博客，粗略按 5000-8000 tokens 估算，input 成本大约 $0.015-$0.024；如果让模型输出同等长度，还要再按 output 单价算一遍。
做 Agent 工程为什么要懂 token？因为长任务不是“聊得久”那么简单，它会不断把历史、文件、工具结果塞进上下文。token 越多，成本越高、延迟越高，也越容易撞上 Context Window。
2. Context Window：模型一次能看的工作台#
小老师提醒：Context Window 不是记忆力，而是模型这一轮推理能摆开的桌面大小。
Context Window 是模型一次请求里能容纳的最大 token 数，包括 system prompt、user prompt、历史消息、工具结果、RAG 文档、图片转写文本，以及模型要输出的空间。它不是长期记忆，只是“这一轮推理时摆在桌面上的材料”。
它有上限，原因之一是 attention 的计算成本会随序列长度快速增长，经典 self-attention 复杂度接近 O(n²)。工程实现会有优化，但长上下文仍然意味着更多显存、更多延迟和更高成本。
2026-06 参考表（不同平台、套餐、beta 开关会有差异，正式使用前以 provider 文档和本机/API 返回为准）：
| 模型 | 上下文 | 备注 |
|---|
| Claude Opus 4.X / Sonnet 4.X | 200K；部分 API/平台 1M | Anthropic docs 显示 Claude 4 系基础 200K，Opus/Sonnet 4.6 等有 1M context 可用范围 |
| GPT-5 series | 400K；部分路由可能更低 | OpenAI GPT-5 docs 标注 400K context、128K max output |
| Gemini 2.X | 1M-2M | Google long-context docs 以 1M+ 为核心，Gemini 2.5 Pro 曾发布 1M、2M coming soon |
| Grok 4 / Grok Build | 256K | xAI docs 中 Grok Build 0.1 标注 256K context |
| DeepSeek V3.X | 128K-1M | V3/V3.1 常见 128K；DeepSeek 新 API/版本可能显示 1M，需按模型版本核对 |
| Qwen / GLM | 128K-1M | Qwen3 系有 256K、可扩到 1M 的说明；GLM 4.5 常见 128K，4.7 文档提到 200K |
超过 context 会发生什么？三种情况都见得到：直接报错、自动 truncate、或者静默丢掉最前面的历史。最危险的是第三种：Agent 看起来还在工作，但它已经忘了最早的约束、设计决策或用户目标。
在 Claude Code 里，管理长上下文的关键机制是 /compact：把历史对话压缩成摘要，再保留最近消息继续工作。深入机制见 /compact 发生了什么。做长任务时，你要学会主动 compact、保存决策日志、把关键约定写进 Memory，而不是无限堆聊天历史。
3. Prompt / System Prompt：你给模型的任务和规则#
小老师提醒：Agent 的稳定性，很多时候不是模型参数决定的，而是 system prompt 和工具边界决定的。
Prompt 就是你发给模型的输入，但工程里要分层看：system prompt 是最高优先级的行为规则，user prompt 是用户当前任务，tool result 是工具调用后塞回来的事实材料。模型最后看到的是这些消息拼起来的一整个上下文。
System prompt 决定 Agent 行为基调：它能规定“你是代码审查员”“先写计划再改文件”“禁止泄漏 secret”“遇到不确定事实要查证”。User prompt 决定这次具体要做什么，比如“帮我修 CI”或“写一节 MCP 教程”。
为什么 Agent 工程师要懂这个？因为很多 Agent bug 不是模型笨，而是 prompt 层级乱：安全规则写在 user prompt 里，被后续消息冲掉；工具边界没写清，模型乱调；输出格式没约束，下游 parser 直接崩。
后面课程里的 Hooks、Slash Commands、Skills、Memory，本质都在解决同一个问题：把临时 prompt 变成稳定、可复用、可审计的工程规则。Skills 入口见 Skills 系统。
4. Temperature / Top-p：随机度和候选词范围#
小老师提醒：代码、事实、JSON 输出要稳；创作、命名、脑暴才需要更高随机度。
Temperature 可以理解成“随机度旋钮”。低 temperature 更稳定、更保守；高 temperature 更发散、更有创意。写代码、抽取事实、生成 JSON 时通常调低；写广告文案、脑暴标题、做创意探索时可以调高。
Top-p 可以理解成“候选词收窄器”。模型每一步都会给很多候选 token 概率，top-p 只从累计概率前 p 的候选里采样。top_p=0.9 表示只在最可能的一批候选里选，尾部小概率词被排除。
做 Agent 工程时，temperature 不是越高越聪明。代码修复、SQL、配置文件、JSON-RPC 示例，建议低随机度；否则同一个输入每次输出不一样，测试和复现都会变难。创作类任务可以调高，但也要配合事实校验。
| 场景 | Temperature | Top-p | 原因 |
|---|
| 代码修复 / 单测生成 | 0-0.3 | 0.8-1.0 | 稳定、可复现 |
| 文档总结 / 信息抽取 | 0-0.4 | 0.8-1.0 | 降低胡编 |
| 产品命名 / 标题脑暴 | 0.7-1.0 | 0.9-1.0 | 需要多样性 |
| 严格 JSON 输出 | 0 | 1.0 | 尽量确定 |
5. 模型大小：B 参数、Dense 和 MoE#
模型大小里的 B 是 billion parameters，7B 就是约 70 亿参数，70B 是约 700 亿，405B 是约 4050 亿，1T 是约 1 万亿。参数不是智商分数，但它通常影响容量、成本、延迟和部署门槛。
Dense 模型每次推理基本会激活全模型参数。你可以把它理解成“所有专家都参与”。很多闭源旗舰模型可以按 dense 心智模型理解：质量高、行为稳定，但推理成本通常高。
MoE（Mixture of Experts）模型有很多专家，但每个 token 只激活其中一部分。DeepSeek V3、Mixtral、部分 Qwen/GLM 系列都采用或探索过 MoE 思路。好处是总参数很大、每次激活参数较少，所以单位推理成本可以更低。
为什么常说 MoE “便宜但慢启动”？因为系统要做路由、加载专家、调度不同专家的计算；在冷启动、低并发或显存紧张时，调度开销会更明显。大规模服务化后，MoE 的性价比通常很好；本地单机跑则未必舒服。
Agent 工程里，选模型不只看大。简单分类、格式转换、日志摘要，7B/13B 可能足够；复杂代码迁移、多文件推理、长链路规划，才需要大模型或 reasoning 模型。
6. Reasoning / Extended Thinking：先想再答#
Reasoning 模型会把更多算力花在中间推理上，你可以粗略理解为“先想再答”。Claude 有 extended thinking，OpenAI o-series / GPT-5 reasoning 支持 reasoning effort，DeepSeek R1 是典型 reasoning 模型。
和直接答相比，reasoning 更适合数学、多步推理、复杂代码、跨文件 bug、计划拆解。它不一定让所有任务都更好：写一段普通文案、总结一页短文、改一个变量名，开很高 reasoning 只会慢和贵。
| 场景 | 建议 |
|---|
| 复杂重构、跨模块定位 bug | 开 reasoning / high effort |
| 单文件小修、格式化、翻译 | 不开或低档 |
| 代码审查、迁移方案 | 中高档 |
| 创意文案 | 不一定需要 reasoning，调 temperature 更重要 |
注意：reasoning 不是“不会幻觉”的保证。它只是给模型更多推理预算，事实正确仍要靠工具、RAG、测试和人工验收。
7. RAG / Embedding / Vector DB：把外部知识塞进 prompt#
RAG（Retrieval-Augmented Generation）一句话：先从外部知识库检索相关材料，再把材料塞进 prompt 让模型回答。它解决的是“模型训练时不知道你公司内部文档、最新代码、私有数据”的问题。
Embedding 是把文本变成向量。两个文本意思越接近，向量方向越接近；常用余弦相似度判断相似。比如用户问“退款多久到账”，系统把问题向量化，去知识库里找和它最相近的退款政策片段。
Vector DB 用来存和查这些向量。选型一句话：
| 方案 | 适合 |
|---|
| pgvector | 已有 Postgres、小规模到中等规模、运维简单 |
| Pinecone | 托管、省心、商业化检索 |
| Qdrant | 开源向量库、过滤条件强 |
| Weaviate | 向量 + schema + 检索功能比较完整 |
为什么 Agent 工程师要懂 RAG？因为你不可能把所有项目文档都塞进 system prompt，也不应该让模型凭记忆答内部事实。MCP 可以把检索能力做成 Tool，把文档片段做成 Resource，见 MCP 协议入门。
8. Fine-tuning vs In-context Learning vs RLHF#
In-context Learning 是“不改模型，只在 prompt/context 里给示例和规则”。比如给 3 个 commit message 示例，让模型按同样风格生成第 4 个。这是 Agent 工程最常用的方式。
Fine-tuning 是用数据继续训练模型，让它学会某种风格、格式或领域模式。它适合大量稳定样本、任务边界清楚、输出格式固定的场景，比如客服分类、固定格式抽取、品牌语气统一。
RLHF 是用人类反馈或偏好信号训练模型，让它更符合人类期望。普通 Agent 工程师通常不会自己做 RLHF；你更多是在使用已经 RLHF 过的模型。
为什么 99% Agent 工程师不需要 fine-tune？因为 Agent 的问题常常不是“模型不会这个领域”，而是“上下文没给够、工具没接好、约束没写清、验收没自动化”。先用 prompt、RAG、Tools、Memory、Skills，成本低、迭代快。
多模态模型能处理文本以外的输入：图片、截图、PDF 页面、语音、视频帧。Claude、GPT-5、Gemini 三家在 vision 场景都很强；具体能力和价格随模型变化，正式项目以 provider docs 为准。
工程里最常见的 vision 用法不是“看猫图”，而是：
- 截图 debug：把报错 UI、浏览器控制台、设计稿截图给模型
- OCR：读 PDF、合同扫描件、发票、表格截图
- UI review：让模型检查布局、对齐、遮挡和视觉层级
- 图表解释：让模型先读图，再结合数据做说明
Agent 工程里，多模态输入也会占 context。图片通常会被模型内部转成视觉 token 或等价表示，价格和上下文消耗都不是 0。截图 debug 很好用，但不要一次塞 50 张无关截图。
小老师提醒：会调工具，才是从聊天机器人走向 Agent 工程的分界线。
LLM 只生成文字；Agent 会为了完成目标调用工具、读文件、写代码、跑测试、查网页、创建 issue。差别不在模型本身，而在外面那层循环：计划、调用工具、观察结果、继续下一步。
Tool use / function calling 是模型调用外部函数的机制。模型输出结构化参数，host 执行工具，再把结果返回给模型。比如模型决定调用 read_file("src/app.ts")，host 真正去读文件，模型再基于结果继续。
MCP 是协议层：它规定一个 server 如何向 host 暴露 tools、resources、prompts。这样你不用为每个 LLM 应用写一套私有插件。MCP 入口见 MCP 协议入门。
本课程后面的 Claude Code、Codex、Grok Build 都是 Agent 工程实践：模型不是一次回答结束，而是在工具和上下文之间循环，直到代码、测试、文档或审查目标完成。
11. Distillation：大模型教小模型#
Distillation（蒸馏）一句话：用大模型的输出、推理过程或偏好结果训练小模型，让小模型在部分任务上接近大模型表现。
为什么蒸馏后小模型推理快？因为小模型参数少、显存占用低、每 token 计算更便宜。它不需要每次都请“大老师”上场，而是把常见模式学进自己参数里。
蒸馏适合边界稳定、重复度高的任务：格式化、分类、固定问答、简单代码补全、客服意图识别。不适合把一个小模型硬蒸馏成通用博士；复杂开放任务仍然需要强模型、RAG 或工具。
Agent 工程里，你可以先用大模型跑出高质量轨迹，再把某些稳定子任务交给小模型。比如主 Agent 用 Claude/GPT-5，日志分类器用便宜小模型。
12. Hallucination：模型为什么会幻觉#
Hallucination（幻觉）是模型生成了看起来合理但事实错误的内容。它会发生，是因为模型本质是在给定上下文下生成最可能的 token，不是直接查询真相数据库。
- 上下文里没有答案，但用户逼它回答
- 温度太高，输出发散
- RAG 检索到不相关材料
- 工具结果被截断或过期
| 手段 | 作用 |
|---|
| 降 temperature | 减少发散 |
| RAG 给证据 | 让模型基于外部材料回答 |
| system prompt 约束 | 要求不确定就说不知道 |
| 工具验证 | 用测试、数据库、搜索、lint 校验 |
| 多轮审查 | 让另一个 agent 或 reviewer 查错 |
Agent 工程里，别追求“模型永不幻觉”。正确目标是：关键事实可追溯，关键操作可验证，错误能被测试、审计或 reviewer 抓住。
| 术语 | 一句话 | Agent 工程里的用处 |
|---|
| Token | 模型读写的单位 | 成本、延迟、上下文都按它算 |
| Context Window | 一次请求能看的 token 上限 | 决定长任务何时 compact / RAG |
| Prompt | 给模型的任务和规则 | 决定 Agent 行为 |
| Temperature | 随机度 | 控制稳定 vs 创意 |
| Top-p | 候选词范围 | 控制采样尾部 |
| Dense / MoE | 模型结构 | 影响成本、速度、部署 |
| Reasoning | 先想再答 | 复杂推理和代码任务更稳 |
| RAG | 检索后生成 | 接入私有知识 |
| Embedding | 文本转向量 | 做语义检索 |
| Fine-tuning | 继续训练模型 | 固定任务大规模优化 |
| Agent | 会调用工具的模型循环 | 自动完成工程任务 |
| MCP | 暴露工具/资源/提示的协议 | 标准化 Agent 能力接入 |
| Distillation | 大模型教小模型 | 降成本、降延迟 |
| Hallucination | 合理但错误的生成 | 需要证据和验证 |
🎬 视频版即将上线：本节 12 个术语将出 12 个 30-60s 短视频，由 BlueLeap 小老师 IP 形象主讲 + AI 配音 + B站 / 抖音同步发布。订阅 BlueLeap 官方频道关注。
bash
python - <<'PY'
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
text = "AI Native 工程师要懂 token，因为成本、上下文和延迟都由它决定。"
print(len(enc.encode(text)))
PY
text
system: 你是代码审查 agent。先找风险，不要先夸。
user: review 这个 PR，重点看权限和数据迁移。
tool result: git diff 输出...
assistant: 按严重程度列 findings。
