刚开始写 LLM 接口时我一直有一个很自然的误解：

既然我是在和 AI 连续聊天模型应该记得前面说过什么。比如我先告诉它：

请记住我叫小林。

再看下一轮再问，

如果它能回答出来我们很容易以为“模型记住了我”。不过，但从接口调用的角度看，事情并不是这样。

什么是无状态？

无状态代表着每一次请求都是独立的，服务端不会默认依赖上一轮请求。就像 HTTP 协议一样，服务器不天然知道“这个使用者刚才做了什么”。除非你提供 cookie、token、session 或者 Authorization header 等机制。其实，

LLM API 一样如此：模型收到一次请求。只能看到这次请求里给它的内容。它并不会自动知道你上一轮说了什么也不会自动保存所有聊天历史。话说回来，简单讲“连续对话”，并不是模型自己保存了记忆。而是应用层每次都把必要历史重新发给模型。

为什么 LLM 要设计成无状态？

直觉上看，有状态好像更方便：使用者说过什么服务端都记住下次直接接着聊。但在真实工程里这会带来很大压力：

• 服务器压力变大
• 扩容更困难
• 请求很难分发到任意机器
• 故障恢复更复杂
• 隐私和数据管理成本更高

无状态的好处是每一次请求都可以被任意一台服务器处理。只要请求本身带齐了必要信息，后端就不需要关心“之前是哪台机器处理了这个使用者”。 话说回来，这对高并发、高可用、水平 都很关键。

messages 才是模型看到的上下文

在 Chat Completions 这类接口里我们经常会传一个 messages 数组：

const messages =;
其实，

这里最关键的一点是：模型不是从某个隐藏记忆里知道“我叫小林”。而是因为这句话仍然在 messages 里面。说白了messages 就是模型这一次能看到的上下文。

If you send only last question:

The model has no reliable evidence to know who you are,so it might guess or say it doesn't know. This is not “forgetting” – it's simply missing context from your request.

一个最小的 chatHistory 例子

const chatHistory =;chatHistory.push;const response = await client.chat.completions.create({
再看model。'deepseek-v4-flash',messages:chatHistory
});chatHistory.push({
role这方面，'assistant'。content:response.choices.message.content
});// second round
chatHistory.push({
role的观点是。'user','
})，const response2 = await client.chat.completions.create({
再看model。'deepseek-v4-flash',messages:chatHistory
});

This looks like model “remembers”,but in reality it's just your code preserving conversation history and sending it again.

chatHistory 能否无限变长？

Theoretically you could keep all past turns,but in practice:

• Larger messages,more tokens → higher cost and slower responses.
• Easier to exceed context window limits.
• Distant information can distract from current task.
• The model’s attention may be diluted by unrelated past messages.

A robust system must refore manage history—trim。summarize,or prioritize relevant parts rar than blindly append everything.

LRU 思路：最近的不一定最关键，但通常更有用

• 最近对话直接保留：最近几条消息往往与当前任务紧密相关。
• 关键事实长期保存："这个项目用 Vue。其实，接口统一走 /api。不要改动使用者已有代码，所有回答用中文。" 等规则即使旧也不应删掉。
• 长对话定期：Synsizing key points reduces token usage while preserving context.
• 项目资料按需检索：If a rule changes,fetch fresh data instead of keeping stale copies.
• 固定规则放进 system prompt 或规则文件：This keeps core constraints always present without bloating every turn.

无状态把责任交给了应用层

This design means that tools such as ChatGPT。Cursor,Claude Code etc.,appear intelligent not because y remember everything internally but because y layer extensive context management on top of stateless APIs:

• User’s current file contents → included in each request.
• Coded snippets & terminal outputs → context for debugging.