LLM 应用核心概念基础：从 Token 到 Agent 的必备地基

这是《Agentic RAG / Text2SQL / LangChain·LangGraph / Agent Harness》四份笔记共同的前置地基。把这些概念一次理清，后面四篇里反复出现的「Token、Embedding、Function Calling、Rerank、ReAct、上下文窗口……」就都有了着落。每个概念统一按 一句话定义 → 为什么需要 → 生活化类比 → 最小例子 → 关联概念 来讲；关键概念配可运行代码，见同目录 llm_concepts_demo.ipynb（已用 deepseek-v4-flash 实测）。

学习笔记的配套代码： https://github.com/LT-IENG/AI-Agent-Study-Notes

0. 导读：一次调用里这些概念都在哪
第一组模型与生成
1.1 Token 与分词
1.2 上下文窗口（Context Window）
1.3 生成参数：Temperature / top_p / max_tokens / stop
1.4 流式输出（Streaming）
1.5 推理模型 vs 普通模型（Thinking）
1.6 幻觉（Hallucination）
第二组表示与检索
2.1 Embedding（嵌入向量）
2.2 相似度、向量数据库与 Top-K
2.3 文本切分 Chunk：chunk_size 与 overlap
2.4 稠密 vs 稀疏、混合检索与 Rerank
第三组调用与智能体
3.1 Prompt：System / User、Zero-shot / Few-shot
3.2 Function / Tool Calling（工具调用）
3.3 结构化输出、JSON Mode 与工具调用的关系
3.4 ReAct 与 Agent：工具调用循环
3.5 MCP（模型上下文协议，速览）
第四组工程概念
4.1 上下文工程与 Token 预算
4.2 Prompt 缓存、批处理、重试与降级
4.3 可观测与评测
5. 概念关系总图与易混辨析
6. 参考资料

0. 导读：一次调用里这些概念都在哪

先看一次「带 RAG 的 Agent 回答」从头到尾发生了什么，本笔记的概念就挂在这条链路上：

flowchart LR
    U[用户问题] --> T[切成 Token<br/>受上下文窗口约束]
    T --> E[问题做 Embedding]
    E --> V[(向量库<br/>相似度 Top-K)]
    V --> CK[Chunk 切分/混合检索/Rerank]
    CK --> P[拼进 Prompt<br/>System+Few-shot+资料+历史]
    P --> M[LLM 按 Temperature 等参数生成]
    M -->|需要动手| FC[Function Calling 调工具]
    FC --> OBS[工具结果回填, 进入 ReAct 循环]
    OBS --> M
    M -->|逐 token| S[流式输出答案]

记住两条主线：「文本怎么变成机器能算的东西」（Token、Embedding、向量检索），以及**「模型怎么从『会说话』变成『会做事』」（Prompt、工具调用、Agent）**。

第一组：模型与生成

1.1 Token 与分词

一句话定义：Token（词元）是大模型处理文本的最小单位，模型不是一个字一个字、也不是一个词一个词地读，而是先由**分词器（tokenizer）**把文本切成一串 token，再映射为数字 id。

为什么需要：神经网络只能算数字，必须把文本离散成固定词表中的编号；计费、上下文长度、生成速度也都以 token 计。

类比：token 像「拼音偏旁和常见字词的混合积木」。英文常见单词是一块，生僻词被拆成几块；中文通常一个汉字约 1–2 个 token，标点、空格也算。

# 直观感受（不同模型分词结果不同，这里用字符数做近似估算）
text = "大模型 Agent 真好用"
print("字符数:", len(text))                 # 13（含空格/英文）
# 真实 token 数请用对应模型的 tokenizer，例如 tiktoken / transformers
# 经验值：1 个汉字 ≈ 1~2 token，1 个英文单词 ≈ 1~1.5 token

要点：

输入 token + 输出 token 都占上下文窗口、都计费，输出通常更贵；
中文比英文「更费 token」，做超长文档时要心里有数；
关联：1.2 上下文窗口、4.1 Token 预算。

1.2 上下文窗口（Context Window）

一句话定义：模型一次能「看见」的最大 token 总量（输入 + 预留输出），例如 8k / 32k / 128k。

为什么需要：注意力机制要对窗口内所有 token 两两计算，窗口越大成本越高，因此有上限；超出窗口的内容模型完全看不到（不是「记不清」，是根本没传进去）。

类比：工作台面大小。你能同时摊在桌面上参考的资料有限；桌面放不下的，要先收进抽屉（外部存储/向量库），用时再取——这正是 RAG 和上下文管理存在的原因。

flowchart LR
    subgraph W[上下文窗口 = 输入 token + 输出 token]
        S[System] --> H[对话历史] --> R[检索资料] --> Q[当前问题] --> O[预留输出空间]
    end

要点：

报 context length exceeded 就是超窗，解决办法是裁剪历史 / 压缩 / 只检索最相关片段（见 RAG、Agent Harness 笔记）；
窗口大 ≠ 会用得好，塞太多无关内容会稀释注意力（「上下文焦虑」反模式）；
关联：2.3 Chunk、4.1。

1.3 生成参数：Temperature / top_p / max_tokens / stop

一句话定义：控制模型「怎么选下一个 token」的旋钮。

参数	作用	调大	调小/为 0
temperature	对概率分布的「锐化/平滑」程度	更随机、有创意（脑暴、写作）	更确定、可复现（抽取、SQL、分类常用 0）
top_p	只在累计概率前 p 的候选里采样（核采样）	候选更多样	更保守，常与 temperature 二选一调
max_tokens	本次输出的 token 上限	答案更长	防止啰嗦/失控烧钱
stop	命中指定字符串就停止生成	——	用于结构化拼装、批量生成
seed	固定随机种子	——	尽量让结果可复现（不保证完全一致）

类比：temperature 像「掷骰子的激进程度」。调 0 基本总选概率最高的词（一本正经、稳定）；调高则敢选冷门词（天马行空、也更容易出错）。

llm_deterministic = ChatOpenAI(model=..., temperature=0, max_tokens=512)   # 做事实抽取/SQL
llm_creative      = ChatOpenAI(model=..., temperature=0.9)                # 写文案/脑暴

要点：本套学习笔记里凡是「要正确、要稳定」的场景（Text2SQL、结构化抽取、Rerank 打分）都用 temperature=0。

1.4 流式输出（Streaming）

一句话定义：不等整段答案生成完，而是每产生一小段 token 就立刻推给前端。

为什么需要：大模型逐 token 生成，完整答案可能要数秒到数十秒；流式让用户「边生成边看」，显著降低等待焦虑。

类比：水管出水 vs 等一整桶水接满再给你。

# LangChain 中 invoke 与 stream 是同一套接口
for chunk in chain.stream({"question": "..."}):
    print(chunk, end="", flush=True)   # 逐块打印

要点：流式只改变「传输时机」，不改变最终内容；工具调用场景下，工具调用参数也可能以流式分片返回，框架会帮你聚合。

1.5 推理模型 vs 普通模型（Thinking）

一句话定义：推理模型（reasoning / thinking model） 在给出最终答案前，会先产生一段内部「思维链」（reasoning content / 思考过程），用更多算力换更强的多步推理；普通模型直接输出答案。

为什么需要：数学、代码、多步规划等任务，「先想再答」正确率明显更高。

类比：普通模型像「脱口而出」，推理模型像「先在草稿纸上演算，再誊写最终答案」。草稿（reasoning）和正式答案（content）是分开的两部分。

# 推理模型的返回通常多一个思考字段（不同厂商字段名不同，如 reasoning_content）
resp = llm.invoke("一个复杂的多步推理题……")
print(resp.content)            # 最终答案
# print(resp.additional_kwargs.get("reasoning_content"))  # 内部思考（如有）

工程避坑（本套笔记真实踩过）：

推理模型往往不支持某些普通模型支持的参数，例如强制 tool_choice、response_format=json_schema，会直接 400；
多轮对话要把上一轮的思考字段按厂商要求回传，否则可能报错（老式 Agent 框架因此与推理模型不兼容，现代 LangGraph/create_agent 已处理）；
推理模型更慢、更贵，简单任务用普通/轻量模型即可，别「杀鸡用牛刀」。

1.6 幻觉（Hallucination）

一句话定义：模型生成了流畅但不符合事实/无中生有的内容（编造 API、编造出处、错误数字），且语气往往非常自信。

为什么会发生：模型本质是在「预测最可能的下一个 token」，它优化的是「像不像人话」，而不是「真不真」；参数化知识可能过时或不全。

怎么缓解（按工程有效性）：

RAG：让答案「有据可依」，只依据检索资料回答（本系列主线）；
工具调用/计算：把算数、查库、查天气交给确定性工具，不让模型「口算编造」；
降低 temperature、要求给引用、让模型自我核查；
结构化约束输出，减少自由发挥空间。

关键认知：幻觉无法被「提示词」彻底消灭，只能靠「外部事实锚定」（检索 + 工具）显著降低——这是 RAG 与 Agent 存在的根本理由之一。

第二组：表示与检索

2.1 Embedding（嵌入向量）

一句话定义：Embedding 是把一段文本（词/句/段）映射成一串数字（向量，例如 768 个浮点数）的过程，使得语义越相近的文本，向量在空间里距离越近。这是「用意思检索，而不是用字面匹配」的基石。

为什么需要：计算机无法直接理解「两句话意思相不相同」，但能算两个向量的距离。有了向量，就能把「语义相似」变成可计算的「数值相近」，从而支持语义搜索、聚类、推荐、RAG。

类比：给每句话在一张「语义地图」上定一个坐标。「怎么退款」和「退货流程怎么走」字面完全不同，但坐标挨得很近；「苹果手机」和「苹果水果」字面相近，坐标却被区分开（好的 embedding 能结合语境）。

flowchart LR
    A1["怎么退款"] --> E[Embedding 模型] --> V1["[0.12, -0.8, ...]"]
    A2["退货流程"] --> E --> V2["[0.10, -0.77,...]"]
    A3["今天天气"] --> E --> V3["[-0.9, 0.3, ...]"]
    V1 -.距离近.-> V2
    V1 -.距离远.-> V3

关键性质：

维度固定：同一个 embedding 模型输出长度固定（如 768/1024/1536）；不同模型的向量不能混用比较；
Embedding 模型 ≠ 对话模型：它不聊天、只负责「文本→向量」，是另一类独立模型（如 OpenAI text-embedding-3、bge、Qwen3-Embedding）；DeepSeek 官方目前不提供 embedding 接口，这也是本套笔记的 RAG 用本地轻量向量演示的原因；
相似度通常用余弦相似度（-1~1，越接近 1 越相似）或点积/欧氏距离。

# 概念示意（真实在线 embedding）：
# vec = embeddings.embed_query("怎么退款")  -> 一串定长浮点数
# 配套 Notebook 用本地字符 n-gram 向量直观演示“文本->向量->余弦相似度”的全过程

关联：2.2 向量检索、2.4 稠密/稀疏。

2.2 相似度、向量数据库与 Top-K

相似度检索：把问题也 embedding 成向量，与库里所有向量算相似度，取最接近的。
Top-K：只取相似度最高的 K 条（K 常取 3~20），在「召回全」和「噪声少」之间折中。
向量数据库（Vector Store）：专门存储海量向量并用 ANN（近似最近邻） 算法做毫秒级相似搜索的数据库，如 Chroma、FAISS、Milvus、Qdrant、pgvector。

flowchart LR
    Q[问题] --> EQ[Embedding] --> ANN[(向量库 ANN 检索)]
    DB[(文档向量)] --> ANN
    ANN --> K[Top-K 最相似片段] --> LLM[拼进 Prompt 给 LLM]

类比：向量库像「按意思找相似」的超快速图书馆索引；不用它，就得把问题和每篇文档逐一算相似度，文档一多就慢到不可用。

要点：向量库返回的是素材而不是答案——它负责「找得准」，最终「答得对」仍由 LLM 基于素材完成。

2.3 文本切分 Chunk：chunk_size 与 overlap

一句话定义：入库前把长文档切成一个个小块（chunk），分别向量化；chunk_size 是每块目标大小，chunk_overlap 是相邻块的重叠长度。

为什么需要：① embedding 模型有输入长度上限；② 整篇主题混杂，向量会被「平均化」、检索不精；③ 塞进 LLM 上下文有限，小块才能按需取用。

类比：把一本厚书拆成一张张带编号的卡片，检索时只抽出最相关的几张，而不是搬整本书。

from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,     # 每块约 500 字符
    chunk_overlap=50,   # 相邻块重叠 50 字符，防止一句话/一个论点被从中间切断
    separators=["\n\n", "\n", "。", "，", " "],  # 优先在更“自然”的边界切
)
chunks = splitter.split_text(long_text)

要点：

overlap（重叠） 是为了让被切开的边界信息在两块里都有，避免「半句话」问题；
块太大→检索不精、费 token；块太小→丢失上下文。需要按文档类型调，代码/表格常用专门切分器；
每个 chunk 通常带 metadata（来源文件、页码、chunk 序号），用于溯源引用。

2.4 稠密 vs 稀疏、混合检索与 Rerank

检索方式	原理	擅长	短板
稀疏检索 Sparse（BM25/关键词）	按词项匹配、词频打分	精确词：型号、错误码、人名、缩写	不懂同义、不懂语义
稠密检索 Dense（向量）	embedding 后比向量距离	同义、近义、跨语言语义匹配	对生僻专名/数字/拼写不敏感
混合检索 Hybrid	两者都召回，用 RRF 融合排名	兼顾语义与关键词，生产标配	实现略复杂
Rerank 精排	用 Cross-Encoder 把「问题+每个候选」成对再打分	从粗召回里精选最相关，显著提准	慢、有成本，只对少量候选做

flowchart LR
    Q[问题] --> D[稠密向量召回]
    Q --> S[稀疏 BM25 召回]
    D --> RRF[RRF 融合去重]
    S --> RRF
    RRF --> RR[Rerank 交叉精排 Top-N]
    RR --> CTX[精选上下文给 LLM]

为什么要「粗召回 → 精排」两级：向量/BM25 是双塔——问题和文档各自编码、互不见面，快但粗，适合先从海量里捞回几十个候选；Rerank 是交叉——让问题和每个候选拼在一起精细判断，准但慢，只对这几十个做。这与 Agentic RAG 笔记里的「先粗后细取证」一脉相承。

Multi-Query / HyDE（检索前改写，知道即可）：Multi-Query 让 LLM 把问题改写成多个同义说法分别检索以扩大召回；HyDE 先让 LLM「假想」一段答案，再用这段更像文档的假答案去检索，缓解「问题短、文档长」的表述落差。

第三组：调用与智能体

3.1 Prompt：System / User、Zero-shot / Few-shot

一句话定义：Prompt 是给模型的输入指令。消息分角色：System（设定身份与规则，优先级高）、User（用户输入）、Assistant（模型历史回复）。

Zero-shot（零样本）：不举例，直接让模型做；
Few-shot（少样本）：在 Prompt 里给几个「输入→期望输出」的范例，让模型照格式/风格做，对稳定输出格式特别有效；
Chain-of-Thought（思维链）：引导模型「一步步想」，提升多步推理（推理模型把这步内化为 thinking）。

messages = [
    {"role": "system", "content": "你是严谨的客服，只依据资料回答"},
    {"role": "user",   "content": "few-shot 示例 + 真实问题……"},
]

要点：System 放稳定不变的规则（利于缓存，见 4.2）；把「输出格式、边界、不许做什么」讲清楚，比反复强调「请准确」有效得多。

3.2 Function / Tool Calling（工具调用）⭐

一句话定义：模型不直接回答，而是输出一个结构化请求——「我要调用哪个工具（函数名）、参数是什么」；由你的代码真正执行，再把结果回填给模型，模型据此继续或作答。这是让 LLM 从「会说」到「会做」的关键机制，也是 Agent 的基础。

为什么需要：LLM 本身不能查数据库、不能算数（会编）、不能调 API。工具调用把「决策（调什么、传什么参）」交给擅长理解意图的模型，把「执行（确定性计算/IO）」交给代码，各取所长。

类比：你（模型）在餐厅看菜单点菜，告诉服务员「来一份宫保鸡丁，微辣」（函数名+参数），后厨（你的代码）真正做菜，再把菜端回来（ToolMessage），你最后用餐（组织答案）。你不进厨房，但决定吃什么。

完整五步闭环（务必亲手走一遍，Notebook 有可运行版）：

sequenceDiagram
    participant U as 用户
    participant M as 模型
    participant C as 你的代码
    participant T as 工具/函数
    U->>M: 问题
    M->>C: 返回 tool_calls=[{name, args, id}]（不执行，只“申请”）
    C->>T: 按 name 找到函数，用 args 真正执行
    T-->>C: 执行结果
    C->>M: 回填 ToolMessage(result, tool_call_id=id)
    M->>U: 结合结果生成最终自然语言答案

from langchain_core.tools import tool
from langchain_core.messages import HumanMessage, ToolMessage

@tool
def multiply(a: int, b: int) -> int:
    """两数相乘。需要精确乘法时使用。"""   # docstring + 类型注解 => 自动生成工具说明/参数 schema
    return a * b

llm_with_tools = llm.bind_tools([multiply])         # 1) 把工具“说明书”绑定给模型
msgs = [HumanMessage("3 乘 4 等于多少")]
ai = llm_with_tools.invoke(msgs)                    # 2) 模型决定调工具（而非硬算）
print(ai.tool_calls)      # [{'name':'multiply','args':{'a':3,'b':4},'id':'call_xxx'}]
msgs.append(ai)
for tc in ai.tool_calls:                            # 3) 代码真正执行
    result = multiply.invoke(tc["args"])
    msgs.append(ToolMessage(str(result), tool_call_id=tc["id"]))  # 4) 结果回填，id 必须对应
print(llm.invoke(msgs).content)                    # 5) 模型给最终答案 -> 12

关键认知与易错点：

模型本身绝不执行函数，它只输出「调用意图」，执行永远发生在你的代码里（安全边界在你手里）；
工具的 docstring 和参数描述是给模型看的接口文档，写不清就会误调（这在 Agent Harness 里叫 ACI 设计）；
参数靠 JSON Schema（由类型注解自动生成）约束，模型按 schema 填参；
ToolMessage.tool_call_id 必须与请求 id 一一对应，多工具并行时尤其重要；
模型必须支持 function calling（DeepSeek-v4、GPT、Claude 等主流模型都支持）；
推理模型可能不支持「强制 tool_choice」，用默认 auto 即可（本套笔记实测过）。

3.3 结构化输出、JSON Mode 与工具调用的关系

一句话定义：让模型输出符合指定 schema 的结构化数据（而不是自由文本），方便程序直接消费。

三种常见手段对比：

方式	怎么做	适用/注意
直接要求 + 正则解析	Prompt 让它输出 JSON，自己解析	最脆弱，容易多逗号/被 markdown 包裹
JSON Mode（response_format）	接口强制返回合法 JSON	只保证是 JSON，不保证字段 schema；部分推理/兼容模型不支持
工具调用承载（最稳，推荐）	用一个 Pydantic 类当「工具」，模型把结构化结果放进 tool_calls.args	走 function calling 通道，字段/类型有保证，兼容性最好

from pydantic import BaseModel
class City(BaseModel):
    city: str
    country: str
# 通用稳妥写法（推理模型也能用）：把 Pydantic 类当工具绑定，从 tool_calls 取结构化结果
ai = llm.bind_tools([City]).invoke("法国首都是哪里？通过调用工具返回")
obj = City(**ai.tool_calls[0]["args"])     # City(city='巴黎', country='法国')

要点：结构化输出的「现代正解」本质就是借工具调用通道强约束 schema，比让模型「自觉吐 JSON」可靠得多。

3.4 ReAct 与 Agent：工具调用循环

一句话定义：Agent（智能体）= LLM + 工具 + 一个「思考→行动→观察」的控制循环，循环多少轮、调什么工具由模型根据中间结果自主决定；ReAct（Reason+Act）就是这个循环最经典的范式。

flowchart LR
    Q[任务] --> T[Thought 思考:下一步做什么]
    T --> A[Action 调用工具]
    A --> O[Observation 观察结果]
    O -->|未完成, 带着结果再思考| T
    O -->|信息足够| F[Final Answer 最终回答]

单次工具调用：开发者写死「调一次工具就回答」；
Agent / ReAct：模型看到 Observation 后自己决定「再调一次 / 换个工具 / 补读资料 / 可以作答」，是动态多轮的；
框架（LangGraph、create_agent）帮你维护这个循环、消息历史、终止条件；手写一遍这个循环就理解了所有 Agent 框架内核（见 LangChain/LangGraph、Agent Harness 笔记）。

关键护栏：循环必须有步数/时间/token 上限和明确终止条件，否则可能死循环烧钱（见 Agent Harness）。

3.5 MCP（模型上下文协议，速览）

一句话定义：MCP（Model Context Protocol） 是 Anthropic 提出的开放标准，用来统一「模型/Agent 应用」连接外部工具与数据源的方式，类似「AI 世界的 USB 接口」。

为什么需要：没有标准时，每接一个工具/系统都要写一套定制集成（M×N 问题）；MCP 让工具方实现一次 MCP Server，任何支持 MCP 的客户端（Claude Desktop、IDE、LangChain 等）都能即插即用。

与 Function Calling 的关系：Function Calling 是「模型如何表达要调工具」的模型层机制；MCP 是「应用如何发现并接入外部工具」的集成层协议——MCP Server 暴露的工具，最终仍通过 function calling 被模型调用。知道概念与定位即可，深入实现见 MCP 官方文档。

第四组：工程概念

4.1 上下文工程与 Token 预算

一句话定义：上下文工程（Context Engineering） 是系统性决定「每一步往模型有限的上下文窗口里放什么、放哪、删什么、外置什么」，并像管理预算一样管理 token。

为什么需要：Agent 多轮跑下来，历史、工具结果、检索资料会迅速撑爆窗口；什么都塞（上下文焦虑）会淹没关键信息、抬高成本和延迟。

四个常用手段（详见 Agent Harness 笔记）：

裁剪：只保留系统提示 + 最近/最相关消息；
压缩（Compaction）：把早期多步过程总结成摘要；
外置记忆：暂不用的写文件/库存起来，需要时再取；
渐进披露 / 子代理隔离：用到才加载细节，用独立上下文处理信息密集子任务。

4.2 Prompt 缓存、批处理、重试与降级

Prompt Caching（提示缓存）：把不变的前缀（System、工具定义、长文档）缓存，重复请求时这部分大幅提速降价（常见约 1/10 成本）。实践：稳定内容前置、动态内容后置（static-first, dynamic-last）、任务中途别换模型/改前缀。
Batch（批处理）：不急的大量请求走批量接口，通常更便宜。
重试与退避：对限流/超时/网络抖动做有限次指数退避重试。
降级链：重试不行 → 换工具/换更小模型（degrade）→ 跳过非关键步骤（skip）→ 带上下文上报人工（human）。

4.3 可观测与评测

Tracing（链路追踪）：记录每次调用的输入输出、工具调用、耗时、token，是非确定 Agent 可调试的前提（如 LangSmith）；
评测集 + 回归：准备一批标准问答，改 Prompt/换模型后批量跑分，防止「改好一个、改坏三个」；
LLM-as-judge：用模型按标准给答案打分，是 RAG/Agent 常用的自动评测手段。

5. 概念关系总图与易混辨析

5.1 一张图把所有概念串起来

flowchart TD
    subgraph 表示层[把世界变成向量]
        T[Token/分词] --> EMB[Embedding]
        CH[Chunk 切分] --> EMB
        EMB --> VS[(向量库 Top-K)]
    end
    subgraph 检索层[找对资料]
        VS --> HYB[稠密+稀疏混合] --> RR[Rerank 精排]
    end
    subgraph 生成层[组织并生成]
        SYS[System/Few-shot Prompt] --> LLM
        RR --> LLM[LLM 按 temperature 生成]
        LLM -->|流式| OUT[答案]
    end
    subgraph 行动层[从会说到会做]
        LLM -->|tool_calls| FC[Function Calling]
        FC --> TOOL[执行工具并回填] --> REACT[ReAct 循环=Agent]
        REACT --> LLM
    end
    subgraph 工程层[可靠落地]
        CE[上下文工程/预算] --> CACHE[缓存/重试/降级] --> OBS[追踪/评测]
    end
    LLM -.受约束于.-> CE

5.2 高频易混概念辨析

容易混淆	区别一句话
Token vs 字/词	Token 是模型分词器切出的单位，中文一字常≈1~2 token，不等于字词
Embedding 模型 vs 对话模型	前者只把文本转向量（不聊天），后者负责理解与生成；是两类独立模型
向量检索 vs Rerank	前者双塔、快而粗、用于海量召回；后者交叉、准而慢、用于少量精选
BM25 vs 向量	BM25 比字面关键词（稀疏），向量比语义（稠密），互补成混合检索
Function Calling vs MCP	FC 是模型层「表达调用意图」的机制；MCP 是应用层「接入外部工具」的标准协议
Function Calling vs 结构化输出	结构化输出可借 FC 通道实现，但 FC 本意是「调用外部动作」
单次工具调用 vs Agent	前者流程写死；后者在 ReAct 循环里由模型自主决定调什么、调几次
JSON Mode vs Function Calling	JSON Mode 只保证合法 JSON、不保证字段；FC 带 schema、字段类型更可靠
RAG vs Agentic RAG	RAG 流程写死「检索一次再答」；Agentic RAG 把检索做成工具、由 Agent 自主多轮取证
Zero-shot vs Few-shot	不给例子 vs 给几个范例；要稳定输出格式时 Few-shot 更稳
温度低 vs 温度高	低=确定可复现（抽取/SQL）；高=多样有创意（写作/脑暴）

5.3 学习路径建议

先吃透 Token / 上下文窗口 / Embedding / 相似度（表示层）；
再走通 Chunk → 向量检索 → RAG（检索层），对应《Agentic RAG》笔记；
掌握 Function Calling → ReAct/Agent（行动层），对应《LangChain/LangGraph》《Agent Harness》；
结构化数据场景看《Text2SQL》；最后用工程层概念（上下文、护栏、可观测）把 demo 变成可靠系统。

6. 参考资料

OpenAI 官方文档：Concepts（tokens、function calling、structured outputs、embeddings）：https://platform.openai.com/docs/concepts
DeepSeek 官方文档（对话/函数调用/推理模型说明）：https://api-docs.deepseek.com/
LangChain 概念文档（Models、Prompts、Retrievers、Tools、Agents）：https://docs.langchain.com/oss/python/langchain/overview
LangGraph 概念（Agent 循环、持久化、人在回路）：https://docs.langchain.com/oss/python/langgraph/
ReAct 论文：https://arxiv.org/abs/2210.03629
RRF（Reciprocal Rank Fusion）论文：https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf
RAG 原始论文：https://arxiv.org/abs/1905.10650 ；HyDE：https://arxiv.org/abs/2212.10496
MCP 官方站点与规范：https://modelcontextprotocol.io/
同系列笔记：《Agentic RAG》《Text2SQL》《LangChain/LangGraph》《Agent Harness》学习笔记。

配套动手材料（同目录）：llm_concepts_demo.ipynb（Token/温度/流式、Embedding 与余弦相似度本地可视化、Function Calling 五步闭环、结构化输出、ReAct 最小循环，已用 deepseek-v4-flash 逐格实测）、requirements.txt、.env.example。