无状态架构：为什么 AI 智能体总是「失忆」

当你连续发了四条消息给一个基于大模型的客服智能体，第二次报上账号、再次描述问题后，它仍然礼貌地回复：「请问能提供一下您的账号吗？」——这不是 Bug，而是主流 LLM API 的默认行为：每一次调用彼此独立，服务器不保存会话、不维护用户身份、不记录历史轮次。

主流 API 为何选择无状态

OpenAI 的 Chat Completions API、Anthropic 的 Messages API 与 Google 的 Gemini API 共享一个常被忽略的设计前提：它们都是无状态的。所谓「记忆」，完全取决于应用在本次请求的 messages 数组里塞了什么内容。Anthropic 文档明确写明 API 是无状态的，客户端负责在每次调用时把完整对话历史一起发送；OpenAI 较新的 Responses API 虽然提供了服务端会话对象作为便捷封装，底层推理调用依然是无状态的。

这种架构选择有其工程合理性：无状态推理可以横向扩展、无需粘性会话，负载均衡简单，并能规避有状态系统常见的一整类内存与安全 Bug。对模型提供方而言，这是正确取舍；但对智能体开发者来说，这意味着不存在一个「打开即可」的内存功能，记忆完全由应用层围绕模型搭建的脚手架决定。

上下文窗口不是记忆

最直接的应对是把全部历史每轮都重发一遍。这种做法在规模放大前会先撞上三面墙：

• 成本：以 Claude Sonnet 4.6 输入 3 美元 / 百万 token 计，一个平均重发 50K token 的 100 轮会话，仅输入成本就达 15 美元，还未计入输出与工具调用。Prompt caching 仅在前缀稳定时有效，而真实对话中前缀往往并不稳定，缓存会因闲置过期，也难以在模型切换后存活。
• 延迟：上下文越长，首 token 时间越长。在跑几百轮内部循环的智能体里，延迟直接折算为美元 / 任务。
• 性能衰减：Liu 等人的 Lost-in-the-Middle 研究表明，模型从长上下文首尾检索信息的可靠性显著高于中间位置。一条埋在 40 轮会话中段的事实，统计上比放在系统提示或最近用户消息里的同样事实更难影响模型回答——模型说「不记得」，往往是因为它真没找到。

填满 1M token 上下文在 Sonnet 4.6 上单次就需 3 美元输入成本，处理耗时显著，但仍无法可靠地从中间取出某条具体事实。把窗口撑得更大只是「记忆的临时方案」，且有上限。

落地到生产环境的失效模式

把上面的架构限制推到真实用户面前，几个月内就会出现可被观察到的典型失效。

反复重新解释：每个会话都从零开始。最熟悉产品的老用户每次开新窗口都得重新告诉智能体「我是谁、在做什么、习惯怎样的术语」，代价由用户时间、信任与好感共同承担。

（注：原文在列出更多失效模式前被截断，本文基于可见内容止于此。）