AI代理为何天生健忘：无状态API架构的代价

您可能见过这样的循环：一位客户第四次联系基于前沿模型构建的支持代理。他们已两次提供账号，两次解释问题。代理礼貌地再次询问：“能否确认您的账号以便我查询？”模型并未损坏，只是其外围框架没有传递之前的对话轮次。而API设计本身就没有记忆两个消息前的内容。

这不是边界情况，而是每个主流LLM提供商API的默认行为，也是当前agent系统在生产中面临的最大摩擦源。原因在于架构而非偶然，而该架构的成本最终都会体现在每张账单和每个团队的日程上。

为什么AI代理天生健忘？

OpenAI的Chat Completions API、Anthropic的Messages API和Google的Gemini API共享一个在agent文献中鲜少被关注的性质：它们都是无状态的。每次调用独立，服务器不保存会话、用户身份或之前轮次的记录。模型“记住”的只是你的应用选择放入此次请求消息数组中的内容。

这就是所有主要提供商选择的架构。这并非他们在文档中致歉的限制。Anthropic Messages API文档明确指出：API无状态，客户端负责在每次调用时发送完整对话历史。OpenAI较新的Responses API提供了服务端会话对象作为便利层，但底层推理调用仍是无状态的。状态是应用围绕模型维护的，而非模型自身维护的。

这一决策背后有充分的工程理由。无状态推理无需粘性会话即可水平扩展，使负载均衡变得简单，避免了一类困扰有状态系统的内存和安全漏洞，并清晰地将模型（一个从输入到输出的函数）与应用逻辑（决定组装什么输入）分离。对于提供商而言，无状态是正确的选择。

但对于你这位构建agent的人来说，这意味着没有可启用的“记忆”功能。只有你每次请求填充的上下文窗口，以及你围绕它构建的任何脚手架。

以下代码展示了问题：第一次调用中用户提供了账号，但第二次调用未传递历史，模型完全没有回忆。

（代码示例略）

第二次调用完全不知道第一次调用发生过。对API来说，这是来自同一密钥的两个无关请求。如果希望模型“记住”账号，agent框架必须在下一次将其放回消息数组中。这就是2026年推理层记忆的全部运作方式。

上下文窗口不是记忆

最直接的反应是：“那我们就每次发送所有历史。”这是大多数生产agent的做法，但直到它行不通之前都有效。在扩展完成之前，它会在三个方面失效。

首先是成本。在长时间会话中，每次轮次重发5万词元的对话历史累积飞快。按Claude Sonnet 4.6每百万词元3美元的输入定价（2026年7月），一次100轮次、平均重发5万词元的会话仅输入成本就达15美元（不计缓存、输出或工具调用）。提示缓存可削减成本——对话历史是追加式前缀，缓存运行成本仅为基础输入价格的十分之一。但默认缓存仅存活5分钟，而人类思考时间常超过此限；一小时缓存写入成本翻倍；且无缓存跨会话、用户或模型交换。缓存只是打折重发，并未移除要求重发的架构。

其次是延迟。更大的上下文意味着更长的首词元时间。用户以毫秒为单位感受成本。运行数百次内部轮次的agent以每任务美元为单位感受成本。

第三点是大多数团队低估的：长上下文会降低模型性能。Liu等人的“中间丢失”论文表明，语言模型包括长上下文旗舰模型，从长上下文开头和结尾检索信息远比从中间可靠。埋藏在40轮对话中第12轮的事实，在统计上比同样的事实贴在系统提示或最新用户消息中对模型答案的影响更小。模型说“不记得”时并非撒谎——它常常真的无法找到眼前的东西。

更大的上下文窗口不是记忆架构，而是记忆权宜之计。区别在于权宜之计有天花板，而我们正在接近它。100万词元上下文窗口在Sonnet 4.6上填充成本为每请求3美元（非每会话），在Claude Fable 5上为10美元，处理需要数秒，且仍无法可靠地让模型从中间提取特定事实。塞入更多并非前进方向。

缺乏记忆导致的四种生产故障

架构问题表现为四种不同的故障模式，任何在真实用户面前运行数周以上的agent都会遇到。

重复解释。每次会话从零开始。最了解产品的用户，使用产品六个月后，每次聊天窗口重置时都必须教会代理他们是谁、在做什么、喜欢什么惯例。成本以用户时间、信任和好感度支付。用户挫败感随着每次重复增长，而用户是唯一注意到的人。

交接断点。会话结束，用户离开。agent在该会话中学习、推断或确立的一切消失。下一会话，同一用户或解决同一问题的队友，从相同空白状态开始。使用Cursor或Claude Code的工程团队每天早上都看到这一点：前一天的建筑决策、命名惯例和陷阱必须由人类重新加载到新聊天中。agent表观智力随会话重置。

矛盾无解。今天用户告诉agent项目使用Postgres。明天迁移后用户说使用DuckDB。一个持久记忆系统简单附加两个事实，最终得到两条矛盾条目，无机制判断哪个当前有效。当前基于向量存储的记忆实现没有“这条新事实取代旧事实”的原生概念。两者都被检索。模型基于语义相似性而非时间有效性选择。用户发现时，agent的代码已指向错误数据库。

猜测替代不知。模型不知道某事时，倾向于合理猜测而不是说“我不知道”。这既是模型训练问题，也是记忆设计问题：大多数agent记忆层无法区分“这是自信检索”和“我没有相关记忆”。没有这个区分，模型没有理由不捏造。一个能诚实说“我没有你之前部署配置的记忆，你能提醒我吗？”的agent，比编造看似合理答案的agent更有用。

每个故障有相同根源和四个不同表面症状。解决它们需要的不只是更大上下文窗口或更好嵌入模型——它需要架构。

团队实际的做法及每种方案的不足

已出现几种缓解模式，但没有一种解决根本问题，多数仅在狭窄情况下有用。

提示填充。将更多相关上下文塞进系统提示或最新用户消息。便宜、快速，但超过数千词元后崩溃，受中间丢失影响。

微调。将知识烘焙进权重。对稳定领域知识强大，但对每周变化或用户特定事实无用，且迭代痛苦。

检索增强生成。推理时从知识库拉取相关块。对文档和参考材料有效，但对逐轮演变的对话状态较差。

向量数据库。存储嵌入后的先前对话片段，按语义相似性检索。2026年最常见模式，也是最常与记忆混淆的模式。它确实检索文本，但未提供记忆层所需的时间、结构或置信属性。向量数据库本身不够，将它们视为记忆基元掩盖了真正的架构差距。

对话摘要。将较早轮次压缩成运行摘要，存活于上下文中。天生有损。摘要器本身是无状态模型，决定保留什么丢弃什么，对三轮后会重要什么毫无意识。

自定义记忆封装。每个团队构建自己的。形状大体相似，都在生产中发现团队未预料的边界情况，且都不跨应用可移植。

代理记忆库。不断增长的开源和商业库类别，将上述模式捆绑成更易采用的形式。减少工程繁重劳动，但单独不能解决时间、结构或放弃问题。

平台供应商也在行动：Anthropic的Claude Tag（2026年6月发布）在Slack内向Claude提供频道范围持久记忆。

大多数生产agent使用两到三种组合。组合足以演示，但六个月后表现转差，当同样几个问题在客户反馈中反复出现时。

每次对无状态LLM API的调用，都从应用选择保留的内容重建上下文。模型本身在请求之间什么都不记得。

没人讨论的时间问题

即使你完美解决了存储问题，仍有一个更难的问题：时间有效性。

假设你的记忆系统存储了事实“用户在Aiven工作”，因为用户18个月前说过。此后用户换过两次工作。事实仍在存储中，向量嵌入大致相同，当用户询问与工作相关的问题时仍被检索。现在它自信地错误。

当前agent记忆系统基于语义相似性检索，偶尔结合时效加权。两者都未捕捉记忆实际需要表达的：不仅是学到了什么，还有何时学到、何时真实、以及之后是否有东西取代它。真实记忆表征需要两个时间维度，而非一个：事实进入系统的时间，以及它有效的时间范围。当前大多数实现两者都未清晰追踪。

后果是一类看似幻觉但实际是过时却自信记忆的错误。模型检索到一条

（原文因成本控制截断）