1. 模型是无状态的
核心结论：大模型本身是无状态的，对话上下文需要依赖 Agent 或应用框架来维护。
模型每一次 API 调用，都是一次“全新会话”——它不会自动记住上一轮对话的内容。可以把它理解成一个没有长期记忆的问答引擎，每次交流都需要重新提供背景信息。
因此，Agent 框架或聊天应用在每次请求模型时，都必须把完整或必要的对话历史一并打包发送给模型。
多轮对话示例
第一轮调用：
messages: [{ "role": "system","content": "你是一个编程助手" },{ "role": "user","content": "你好，你是谁？" }]
第二轮调用（必须带上历史）：
messages: [{ "role": "system","content": "你是一个编程助手" },{ "role": "user","content": "你好，你是谁？" },{ "role": "assistant", "content": "我是编程助手，有什么可以帮你？" },{ "role": "user","content": "帮我写个冒泡排序" }]
如果只发送最后一条用户消息，模型就无法知道前面讨论过什么，整个上下文信息也会随之丢失。
2. 消息的四种角色
| 角色 | 谁写的 | 作用 |
|---|---|---|
system | 开发者 | 定义模型的“角色设定”和行为规则，通常只有一条，并放在消息列表最前面 |
user | 用户 | 表示用户输入的问题、指令或请求内容 |
assistant | 模型（上一轮） | 保存模型之前的回复，重新拼接回 messages 中，帮助模型延续上下文 |
tool | Agent 框架 | 记录工具执行后的返回结果，并通过 tool_call_id 与对应的工具请求建立关联 |
3. 模型 vs Agent 框架
模型负责“思考与生成”，Agent 框架负责“执行与调度”。
- 模型（LLM） ：只负责“想”——读取消息、进行推理、输出自然语言内容，或者生成工具调用请求。它自身并不会真的执行外部操作。
- Agent 框架：围绕大模型 API 运行的业务代码，负责维护 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 或第一个字之间的等待时间。
虽然名称里带有 token，但它本质上描述的是时间，是评估大模型响应速度的重要延迟指标。
KV Cache
模型在处理每个 token 的过程中，会产生 Key 和 Value 两类中间计算结果。
- 没有 KV Cache：每次调用都要从头计算全部 token，包括 system prompt 和历史对话内容——因此更慢。
- 有 KV Cache：把已经计算过的 K、V 结果缓存起来，后续请求优先复用，只需要计算新增 token——因此更快。
两者关系
messages 中已经存在的 token（system prompt、历史对话）→ 可以直接读取 KV Cache，跳过重复计算。
新增的 token（新的用户输入）→ 需要实时重新计算。
实际效果：
- 第一次请求通常较慢（冷启动，没有缓存）
- 后续请求通常更快（命中缓存，复用已有计算结果）
- 随着对话轮次增加，KV Cache 的命中比例会更高，TTFT 往往也会更稳定
这也是为什么 system prompt 通常要放在 messages 最前面——因为它基本不会变化，最适合被缓存并长期复用。
