在底层，绝大多数 LLM API 都是"无状态的" (Stateless)。这意味着对大模型来说，你的每一次 API 调用确实都是一个刚刚经历过记忆清除的"新窗口"。
既然大模型每次都会失忆，那么我们在网页版里体验到的"上下文连贯"是怎么做到的呢？答案在于客户端（也就是网页前端或者你写的代码）的本地缓存和历史记录拼接。
以下是你使用 API 时管理和确认上下文的具体机制：
1. 聊天记录是由你的代码"背着"一起发过去的
当你通过 API 进行多轮对话时，你不能只发送当前的新问题，你必须把之前的**全部历史对话（包括你的问题和模型的回答）**打包成一个数组（或列表），每次调用时完整地传给大模型。
举个例子：
- 第一轮调用 API： 你发送
[{"role": "user", "content": "你好，我是张三"}]。模型回答"你好，张三"。 - 第二轮调用 API： 如果你只发
[{"role": "user", "content": "我叫什么名字？"}]，模型会回答不知道。 - 正确的第二轮调用： 你必须发送
[{"role": "user", "content": "你好，我是张三"}, {"role": "model", "content": "你好，张三"}, {"role": "user", "content": "我叫什么名字？"}]。模型通过阅读前面两句的"历史记录"，才能回答出"你叫张三"。
2. 怎么确定 LLM 考虑到了上下文？
在使用 API 时，确定 LLM 是否考虑到上下文的唯一标准，就是检查你发送的 Request Payload（请求体）中是否包含了之前的消息数组 。
只要你按顺序把之前的对话喂给了它，它就必然会结合这些上下文来生成下一次的回复。
3. API SDK 的"语法糖"
虽然底层原理是每次都要手动拼接历史记录发过去，但这在写代码时很繁琐。因此，官方提供的 SDK（比如 Python 库）通常会提供一些封装好的对象来帮你自动管理上下文。
以 Gemini 的官方 SDK 为例，它有一个 ChatSession 对象。当你使用 chat.send_message("新问题") 时，这个对象会在底层自动帮你把之前保存在内存里的历史记录拼接好，一起发送给 API 端点。对你来说感觉像是在一个"窗口"里聊天，但本质上依然是每次发送越来越长的历史包。
⚠️ 一个重要的副作用：Token 消耗会像滚雪球一样
因为你每次都要把历史记录完整发一遍，这就导致了一个关键问题：上下文越长，每次请求消耗的 Token 就越多。网页版对话越到后面反应越慢、越容易报错或者达到长度上限，也是因为这个底层机制。