大模型 API 核心概念笔记

大模型 API 核心概念笔记需要先看清适用场景和关键步骤，避免只记结论却忽略实际限制。

1. 模型是无状态的

核心结论：模型无状态，上下文靠框架维护。

模型每次被调用，都是"全新的"——它不记得上一次对话说了什么。就像一个失忆症患者，每次见面都得重新自我介绍。

因此，Agent 框架必须每次都把完整的对话历史打包发给模型。

多轮对话示例

第一轮调用：

messages: [{ "role": "system","content": "你是一个编程助手" },{ "role": "user","content": "你好，你是谁？" }]

第二轮调用（必须带上历史）：

messages: [{ "role": "system","content": "你是一个编程助手" },{ "role": "user","content": "你好，你是谁？" },{ "role": "assistant", "content": "我是编程助手，有什么可以帮你？" },{ "role": "user","content": "帮我写个冒泡排序" }]

如果只发最后一条，模型完全不知道前面聊了什么，上下文全丢了。

2. 消息的四种角色

3. 模型 vs Agent 框架

模型只动嘴，框架负责动手。

1. 模型（LLM） ：只负责"想"——读消息、推理、输出文字或工具调用请求。它本身什么也不执行。
2. Agent 框架：围绕模型跑的代码，负责维护 messages 列表、真正执行工具、把结果塞回 messages、决定是否再次调用模型。

4. 工具调用的完整流程（ReAct 循环的 API 实现）

以"Vancouver 现在天气怎么样？"为例：

第一次调用用户提问 → 发给模型模型返回：我需要调用 get_weather 和 get_current_time（并行）Agent 框架执行两个工具，拿到结果第二次调用把工具结果追加到 messages → 再发给模型模型读到结果 → 直接回答用户

模型返回工具调用时，content 为 null，实际指令在 tool_calls 字段里：

{"role": "assistant","content": null,"tool_calls": [{"id": "call_abc123","function": {"name": "get_current_time","arguments": "{"timezone": "America/Vancouver"}"}}]}

这个"请求 → 工具调用 → 执行 → 送回结果 → 再请求"的循环，就是 ReAct 循环（Reason → Act → Observe）在 API 层面的具体实现。

5. API 返回格式：为什么是 choices

API 返回的顶层是 choices 数组，因为支持 n=3 这样的参数，让模型一次生成多个候选回答供你挑选。

实际开发中 99% 的情况都是 n=1（默认），直接取 choices[0].message 即可。

包一层数组是为了格式统一——不管要 1 个还是 N 个回复，调用方的处理代码不需要做特殊判断。

6. KV Cache 与首 Token 延迟（TTFT）

首 Token（TTFT）

TTFT = Time To First Token，即从发出请求到第一个字出现的等待时间。

名字虽然带 token，说的是时间，是衡量响应速度的延迟指标。

KV Cache

模型处理每个 token 时，会产生 Key 和 Value 两种中间计算结果。

1. 没有 KV Cache：每次调用都从头重新计算所有 token，包括 system prompt 和历史对话——慢。
2. 有 KV Cache：把算过的 K、V 缓存起来，下次复用，只计算新增的 token——快。

两者关系

messages 中已存在的 token（system prompt、历史对话）→ 直接读 KV Cache，跳过计算。

新增的 token（新的用户输入）→ 实时计算。

实际效果：

1. 第一次请求慢（冷启动，无缓存）
2. 后续请求快（命中缓存，复用已有计算）
3. 对话轮次越多，KV Cache 命中比例越高，TTFT 反而越稳定

这也是为什么 system prompt 要放在 messages 最前面——它永远不变，最容易被缓存复用。