智能体记忆怎么做：分清上下文、会话与长期存储，算清运行成本

为智能体记忆付费之前，先弄清楚它到底忘了什么：当前提示词里的信息、尚未完成的任务，还是下周还要用到的知识。Anthropic 的 Claude Managed Agents 按每个会话小时的活跃运行时间收取 $0.08，模型 token 另计。但信息能保存下来，与需要时能准确调用，是两项独立的设计工作。先保存会话状态，再用简短的指令文件记录规则；等新会话确实需要调用之前工作中的特定事实，再加入长期存储。

智能体记忆是什么？先确定哪些信息必须留下来

智能体记忆，是智能体能够保留并在后续工作中重新调用的信息。 关键在于区分两件事：当前模型请求中可见的信息，以及为未来请求保存在其他地方的信息。

如果智能体重启后不认识老客户，扩大提示词容量也不会自动找回这位客户的历史。如果它忘了退款流程进行到哪一步，可搜索的偏好存储也无法可靠地还原交易进度。选产品之前，先找出缺失的信息。

从实际运行的角度，可以把记忆分成以下四类。它们是可以组合使用的不同层次，而不是互相排斥的定义。

token 是模型处理、API 计量的小段文本单位。检查点是保存下来的工作流进度记录。**向量嵌入（embedding）**是内容的数值表示，用于按语义搜索。术语再多，核心问题仍然是：该保存什么，又该在什么时候读取？

上下文窗口：模型眼前的工作台

上下文窗口容纳的是模型处理这次请求时可以使用的信息。把客户的最新消息、相关工单信息和退款政策放进去，模型才能结合它们开展工作。若漏掉之前作出的承诺，模型就没有可靠依据去兑现它。

可以把上下文想成档案室里的一张桌子。桌子再大，书架上的文件仍然不在桌面上。扩大桌面只是增加工作空间，仍然需要有人决定该取出哪些档案。

运行成本取决于提交给模型的内容，重复文本也要计算。有效的优化，是让提示词聚焦于当前决策需要的证据。需要精确信息时，保留完整标识符、约束条件和工具结果；摘要虽然短，却丢了订单 ID，这样的节省得不偿失。

会话状态：让同一项任务接得上

会话状态回答的是：“这项任务做到哪了？”对于退款智能体，它可能包括工单 ID、对话历史、审批状态，以及能够说明退款是否已提交的工具结果。Google 的会话文档区分了对话事件与该次交互中使用的临时状态。

保存对话记录有用，但宿主应用还应该用结构化记录保存业务进度。钱有没有转出去，应由支付系统确定。让模型根据对话措辞推断，容易造成原本可以避免的重复操作。

如果问题是“断线后智能体就不知道做到哪了”，先解决会话状态。状态能否持久保存，取决于它存在哪里。工作进程中的变量会随进程终止而消失；持久存储中的状态则可以由下一个工作进程重新加载。

长期存储：把有用的知识带到下一次任务

长期存储回答的是：“开始新任务时，智能体应该已经知道什么？”老客户可能更喜欢邮件联系，而不是电话。项目里可能有一项决策，解释了为什么没有采用某个集成方案。这些事实不应随一次对话结束而失去用途。

存储可以很简单：按客户 ID 读取普通记录即可。只有当问题不容易预先确定，例如“这个客户上次反对什么”，按语义搜索才更有价值。读取已知的语言偏好，并不需要这套复杂机制。

业务记录始终应是权威依据。“偏好邮件联系”可以作为记忆中的偏好；但如果决策依赖“账单是否已支付”，就应查询账务系统。记忆可以帮助定位相关记录，却不应悄悄取代它。

文件与技能：保存规则和经验

如果反复出现的问题是“编程智能体总忘记我们的规范”，文件往往已经够用。根据 Anthropic 的 Claude Code 文档，CLAUDE.md 提供书面指令，受支持的 AGENTS.md 文件提供代码仓库指导，自动记忆则保存智能体根据纠正意见和偏好写下的笔记。

**技能（skill）**是一套可复用的操作流程，通常由指令文件及配套材料组成。“如何准备发布”适合写成技能；“客户更改了配送偏好”应放进客户状态。记录之前失败的笔记可以用于两者中的任意一类，取决于它是通用经验，还是某位客户的具体事实。

Claude Code 会在使用技能时加载其正文，而可用技能的名称和描述会占用列表空间。因此，即使文件存储便宜，使用文件仍有运行成本。更详细的分析见如何降低 Claude Code 技能的上下文成本。

常驻指令保持简短，偶尔才用的流程移到技能中。同时要记住，书面指令只是对模型的指导；权限和禁止执行的操作，应由应用层控制强制落实。

智能体记忆系统仍要为每次请求组装提示词

持久存储只有把正确的信息送进下一次请求，才真正有用。 什么都存、什么都取，只会把持久化变成昂贵的历史对话重放。

把写入路径和读取路径分开设计

写入路径决定哪些内容会成为未来的记忆。客服交互结束后，可以保存已确认的联系偏好和来源引用，把一时的抱怨留在工单历史中。应用可以直接写入结构化字段，也可以让提取模型把对话整理成候选事实。

读取路径决定当前任务需要什么。先验证客户身份，确定正确的作用域，再检索适用事实，剔除过期或已被替代的记录，将筛选后的内容放进提示词。还要记录本次用了哪些记忆，便于追查错误回答。

Google 的 Memory Bank 概述介绍了如何从对话生成记忆，再将检索到的记忆插入提示词。持久知识与工作上下文仍然是分开的。

面对老客户，有用的提示词可能只需包含今天的工单、联系偏好和当前政策，通常不必带上形成这项偏好的每段聊天。无论自建数据库还是购买托管服务，如何筛选信息都是设计的核心。

内容分类，不等于存储位置

你可能会看到这些说法：情景记忆指过去发生的事件，语义记忆指事实，程序性记忆指做事的方法。这些内容分类有助于理解，但同一个事件可以保存在数据库行、文本笔记或对话记录里。

检索增强生成（RAG），是先找出相关材料，再提供给模型用于回答。 查询政策文档和查询记住的偏好，都可以用检索实现。而记忆还需要决定保留、更新和遗忘什么。RAG 也可以使用不断变化的数据源，并不天然等于一组静态文档。

记忆也不同于训练，后者会改变模型的底层参数。读取保存的笔记，只是为当前工作提供信息，并不能说明基础模型已经永久学会了这些内容。

大厂原生服务，分别解决了什么问题？

原生服务已经能承担不少持久化工作，但各家的能力边界不同。 下文的功能与价格，均于 2026 年 10 月 5 日根据服务商公开文档和定价页面核实。

开发者的起点也因此改变：先检查现有运行环境提供的对话和记忆服务。只有当这些服务无法满足某项具体的检索、可迁移性、纠错或控制需求时，才有理由引入独立供应商。

Claude 的记忆能力：应用、会话与存储各管一层

Anthropic 的 Claude 在面向用户的应用中提供记忆功能，也通过 Claude Managed Agents 为开发者提供独立的持久化能力。 Claude 应用在聊天中保存各个主题；项目则拥有独立的记忆空间和摘要。当前帮助页面说明，Free、Pro 和 Max 默认开启记忆，Team 与 Enterprise 则由所有者控制是否可用。这项应用功能并不能说明你自己的应用应如何设计客户状态架构。

Managed Agents 的会话会跨交互保留历史。要让后续会话共享知识，需要挂载记忆存储库：它是一组文本文件，智能体在 /mnt/memory/ 下读写。存储库在创建会话时挂载。每个会话支持 8 个存储库，每个存储库支持 10,000 条记忆；存满后，新记忆写入会失败，但已有记忆仍可读取和编辑。共享参考资料的存储库可设为 read_only。这些是文档明确规定的存储边界，因此应提前分区和清理，避免数据增长最终导致写入失败。

Claude 定价页面列出的费用是每个活跃会话小时 $0.08，另加标准 token 费用，未列出单独的记忆存储费率。详细定价文档说明，运行时间只在 running 状态下累计，idle、rescheduling 和 terminated 的时间不计入。

实际做预算时，应计算智能体工作的时间，而不是会话存在的时间。持久文件并不意味着模型输入免费，挂载存储库也不意味着智能体自动知道该关注哪份文档。

OpenAI 的对话状态：对话能持久保存，上下文仍要计费

OpenAI 的 Conversations API 为 Responses API 提供持久对话线程，后者负责生成模型响应和工具交互。一个对话 ID 可以跨会话、设备或任务复用，保存消息、工具调用和工具输出。另一种方式是用 previous_response_id 串联响应。对话状态指南指出，响应链中先前的输入仍需计费。它还区分了默认保存 30 天的响应对象，以及不受这项 30 天到期限制的对话对象和条目。

持久对话线程能让工作接续下去。但哪些事实应该用于未来互不相关的对话线程，仍须由应用决定。客户与对话之间的映射也要持久保存；如果下一个工作进程找不到正确的 ID，对话存得再完整也帮不上忙。

OpenAI 定价页面说明，Responses API 不在模型用量之外单独收费，也没有列出独立的 Conversations 费率。以一个代表性费率为例，GPT-6.1 Sol 的短上下文标准价是每百万输入 token $2，每百万输出 token $10。模型、处理模式、上下文长度和工具都会影响账单。

如果还要选择对话存储之外的运行方案，可以在确定应用必须持久保存什么之后，阅读 OpenAI Agents API 与 Agents SDK 对比。

Google Sessions 与 Memory Bank：分别管理对话状态和持久事实

Google 的 Gemini Enterprise Agent Platform 将 Sessions 与 Memory Bank 分开。 Sessions保存交互历史和对话状态；Memory Bank生成并管理后续会话要用的事实，支持作用域、到期时间和修订版本。

Google 的检索文档说明，记忆的作用域必须与请求的作用域完全一致。作用域是赋予记忆的身份和分组，创建后不能更改。开发者仍须提供正确的身份，并强制控制谁有权使用这些信息。

当前定价页面列出：Sessions 与 Memory Bank 存储费为每 GiB·月 $0.30，Memory Bank 的修订版本也计入存储；读取费用为 $0.085/3M 次，写入费用为 $0.085/1M 次，通过 Agent Compute 按实际比例计费。记忆生成和向量嵌入的 token 另计。这套定价自 2026 年 9 月 1 日起生效。

对开发者来说，这是一项托管的生命周期服务，不只是存放聊天记录的空间。对运营者来说，生成 token 和保留修订版本的费用都应纳入预算。Google 运行资源中的“Agent Memory (RAM)”指计算机的工作内存，与记住的客户事实是不同的资源。

智能体记忆的运行成本怎么算？

要判断是否省钱，先把完整的写入和读取循环算清楚。 记忆可以减少重复输入，却也增加提取、检索和维护工作。存储便宜，不足以决定哪种方案划算。

可用的成本模型是：

每月记忆成本 = 提取与更新 + 存储 + 检索 + 检索内容的输入 token + 额外运行时间 + 运营工作。

运营工作包括纠错、调整保留策略、处理写入失败和排查问题。即使供应商账单上没有这些项目，也应记录。别硬套一个编造的时薪，使用团队实际的人力和事故成本。

月度预算示例：算出省钱的临界点

假设一个自建智能体每月有 10,000 次需要接续历史的运行，目前每次都重放 10,000 个历史输入 token。改为按需筛选后，每次只提供 1,000 个记忆 token，并在每次运行结束后花费 2,000 个输入 token 和 200 个输出 token来提取记忆。

这些是用于演算的工作负载假设，不是实测性能。Claude Sonnet 5.5 的标准费率是每百万输入 token $2，每百万输出 token $10。

• **重放历史：**10,000 次运行 × 10,000 个 token = 100M 输入 token，费用为 $200/月。
• **筛选上下文：**10,000 × 1,000 = 10M 输入 token，费用为 $20/月。
• **提取记忆：**20M 输入 token 的费用是 $40；2M 输出 token 的费用是 $20。合计 $60/月。

按需筛选方案在计入其他成本前，每月已需 $80。因此，在新增的存储、搜索、运行时间、重试和维护上，最多还能花 $120/月；超过这个额度，总成本就会高于 $200 的历史重放基线。两种方案都没有计入相同的基础任务执行与回答生成成本。

值得计算的就是这个临界点：省下的历史重放费用，必须超过记忆带来的全部额外费用。如果提取过程需要读取整份原始对话，就用实际读取量替换这里假设的提取输入量。如果只有偶尔发生的变化才需要新增记忆，就按更低的写入频率计算。

缓存费率来自 Anthropic 定价文档。缓存能降低重复处理的价格，但不会判断某条记忆是否仍然有效，也不会判断它是否属于当前用户。

活跃运行时间与存储，分别列账

假设 10,000 次 Claude Managed Agents 运行，每次活跃运行 6 分钟。运行时间费用就是 1,000 会话小时 × $0.08 = $80/月，token 和其他适用用量另计。这项计算采用公开的运行时间费率；每次六分钟是设定的活跃时长，不是实测基准。比较本来就使用同一运行环境的记忆方案时，只应加入记忆带来的增量运行时间。

按 Google 当前的计费项，假设免费额度用完后，还有 10 个计费 GiB·月、3M 次计费读取和 1M 次计费写入。存储与操作的小计为 $3.00 + $0.085 + $0.085 = $3.17/月，不含记忆生成 token、向量嵌入、智能体推理和运行时间。Google 的定价页面列出的账户月度免费额度为 1 GiB·月存储和 50 个 Agent Compute 小时；本例假设这些额度均已用完。GiB 是二进制存储单位，大约相当于十亿字节。

不能据此认定某家服务商的整套记忆服务更便宜，因为这些账单计量的工作不同。应按计划运行的工作流估算，包括智能体多久读取、写入、重新生成事实，以及把它们加载进上下文。

智能体记忆管理：常见故障与修复办法

生产环境真正难的是控制哪些事实能成为可信上下文。 存储库能可靠地保存有用知识，也同样能持久保存错误事实、返回其他客户的记录，或保留恶意指令。

事实过期：保留来源和有效期，行动前重新核实

假设客户更换了账单联系人，智能体却继续使用之前那个人的信息。如果只是保存新消息，没有让旧记忆失效，就会留下两个看起来都有效的答案。

修复办法是记录归属、来源引用、观察到该事实的时间，以及它何时有效或到期。纠正时要定位到具体记录。将被替代的事实标记为不再有效，而不是让搜索决定哪个版本听起来更贴近问题。到期机制通常称为生存时间（time to live，TTL），它限制事实可以被使用多久，却无法在到期前发现所有变化。

涉及当前账户状态、库存、价格或访问权限时，在执行操作的那一刻读取负责维护该值的系统。记忆可以保留先前决策及其解释，实时核验则提供当前事实。Google 文档将到期与记忆修订列为生命周期控制，并不是允许忽略这一差别。

记忆串到其他用户：检索之前强制核验身份

在所有用户的数据中搜索“最近的取消”，或让应用接受模型自行指定的用户 ID，都会埋下泄漏隐患。即使数据库查询正确限定了作用域，仅按问题内容缓存结果，也可能造成相同的泄漏。

修复办法是从经过身份验证的应用请求中确定客户和账户身份。写入、读取、更新、删除、导出、后台任务和缓存，都必须使用这项身份约束。缺少必需作用域的请求直接拒绝。应用层之外，存储或服务层也要强制执行访问控制；提示词写着“只使用这位客户的记录”，并不能约束查询。

行级安全，是由数据库限制调用者能看到哪些数据行。 等效的服务授权也可以限定存储库或作用域边界。共享政策材料与私人客户事实，应有明确不同的权限设置。

在自己的环境里，用不同的虚构用户和容易识别的私人事实测试隔离边界。不只看最终回答，也要查看检索结果和排队中的任务。模型没有在回答中使用泄漏事实，不代表私人数据一直处于隔离状态。

错误记忆变成指令：把好写入关

取回的文档可能包含“下次忽略退款限额”。如果智能体把这句话保存成长期规则，恶意内容就会延续到未来的工作。这叫记忆投毒，即将错误或敌对内容保存下来，供以后复用。

把观察到的信息与约束行为的指令分开。共享政策设为只读，记录智能体写入的主张来自哪里，并审查可能改变行为的修改。Google 的 Memory Bank 治理部分明确描述了这项风险。即使检索文本要求改变权限，宿主控制的权限也必须继续生效。

摘要、并发写入与删除，也要分别处理

摘要可能删掉真正重要的条件：“包裹退回后批准退款”变成“已批准退款”。准确的业务状态应保存在生成摘要之外，同时保留指向原始证据的引用。如果一条记忆不足以证明必需条件已经满足，就检索来源，或请求澄清。

并发写入者可能覆盖彼此的纠正。更新前先检查版本，遇到冲突后重新加载。Anthropic 为此提供了 content_sha256 前置条件。

检索过量需要另一种修复：设定上下文预算，优先使用适用且有权访问的事实。检索文本越多，token 越多，也可能把相互矛盾的内容一起带进来。确定的字段应精确查询，宽泛搜索则应有明确的使用理由。

删除还必须覆盖衍生数据。依据保留策略，删除或使相关摘要、搜索条目、缓存和保留的历史失效。Anthropic 的记忆版本文档指出，删除当前记忆不会删除保留的版本；历史内容需通过单独的内容擦除路径处理。

你究竟需要哪种智能体记忆系统？

当某项具体信息必须跨过某个具体边界继续保留时，再采取行动。 要让工作更连贯，不必为每一种“忘记”都购买新服务。

开发者可以先从持久会话记录开始，解决未完成任务丢失进度的问题。如果后续会话需要固定的偏好，再加入小规模的用户记录。只有无法按已知键可靠选出有用事实时，才加入语义搜索。重复的项目指令和操作流程，用文件与技能最直接。

运营者应在状态丢失导致重复工作、过期回答或重复操作时立即处理。记录加载的 token、写入频率和检索结果，同时记录纠错情况。如果还没有人负责到期和删除机制，就先缓一缓自动提取长期记忆，先明确哪些事实应该留下来。

采购者应询问供应商：状态存在哪里，如何查看和纠正，能跨过哪些边界，以及如何强制控制访问。如果托管产品能替团队省去原本要自己运行的生命周期管理工作，它就有价值。可迁移性、删除能力和实际工作负载的账单，应决定采购选择。

如果无状态任务每次都能收到全部必需的当前输入，而且后续任务不需要它的历史，那么你不受影响。保留审计日志仍可能有用，但不需要因此自动把日志注入未来的提示词。

小方案遇到明确的瓶颈时，选择才需要改变。客户偏好字段够用，直到你需要从漫长历史中找出相关事件。会话记录够用，直到每次新请求都得筛查无关的旧任务。操作手册够用，直到缺失的知识变成不断变化的客户状态，而不是稳定的流程。

AI 智能体记忆工具：Mem0、Zep 和 Letta 各适合哪一层？

Mem0 是一种记忆集成方案，从提交的消息中提取事实，再为指定用户检索这些事实。 它的快速入门文档展示了 add 搭配 user_id 的写入方式，以及按对应过滤条件搜索、再把返回的记忆传给模型的过程。最后这一步正是集成边界：持久保存的事实，仍要提供给负责回答的智能体。

这段描述用于理解架构，并不能证明 Mem0 是你的工作负载下最值得购买的产品。

Zep 构建 Context Graph，将事实、关系及其来源按时间组织成网络。 它的官方文档介绍了标明事实何时开始有效、何时失效的时间戳，也明确指出，来源可追溯并不保证内容正确。不断变化的账户关系适合这种结构，但来源仍须可信。

图谱描述信息如何相互连接，并不会免除开发者限定调用者可访问哪些记录的责任。

Letta 提供记忆块，即持久保存并放在智能体提示词前部的内容区块。 它的记忆块文档说明，区块始终可见，无需检索，也可以设为只读。稳定的工作资料可以采用这种模式。代价也很直接：始终可见的内容会占用上下文，所以区块应保持聚焦。

具体产品推荐、部署选择和套餐比较，见 2026 年 AI 智能体持久记忆系统推荐。先在本文中确定需要哪一层，再按这项需求比较工具。

智能体记忆，有哪些被夸大了？

“智能体什么都记得”并不是完整的产品承诺。 真正该问的是：事实能否留下来，能否在正确的任务中被取回，以及使用时是否仍然正确、仍然有权访问。

更大的上下文窗口，只是让你能提供更多材料，不会替你选择正确的客户记录。向量存储按语义搜索，并不会天然知道旧偏好已被撤销。智能体写下的笔记保存的是一项主张，并不能证明这项主张。

自动写入越多，运营工作也可能越多。把每次抱怨都存成长期偏好，会让智能体形成失真的客户画像。重复提取的成本可能高于读取结构化字段。一组简短、可检查且正确的事实，可能比庞大的可搜索历史更有用。

最有说服力的采购理由应更具体：产品能管理你需要的某种持久化与检索生命周期，而且控制方式和成本都说得清。只有它省下的运营工作值得花钱时，才购买这个结果。

下周一就动手：先修好一种反复发生的遗忘

挑一个反复运行的工作流，写清楚下一次运行究竟需要什么。 对客服智能体，可以先看未完成的工单、老客户的联系偏好，以及退款操作流程。

1. 1

   给每项信息找到合适的位置

   工单进度放进会话与业务状态；已核实的联系偏好放进用户记录；退款流程放进指令文件或技能。当前支付状态仍由支付系统保存。

2. 2

   明确谁可以读取和修改

   在宿主应用中确定身份，对每项操作和缓存强制限定作用域，并让普通任务会话只能读取共享流程。

3. 3

   保存、纠错和遗忘一起设计

   记录来源和有效期。让运营者能定位到具体记录进行纠正，并提供覆盖衍生副本及保留版本的删除路径。

4. 4

   验证边界，同时记录账单

   在自己的环境中检查重启后能否接续工作、变更的事实能否生效，以及用户之间是否隔离。记录模型 token、写入、读取、活跃运行时间和纠错工作。等明确需求超出这套小型设计的能力，再购买额外的记忆基础设施。

智能体记忆分哪些类型？

做生产环境决策时，区分上下文窗口、会话状态、长期存储，以及文件或技能。情景、语义和程序性记忆描述的是内容：过去的事件、事实和指令。它们并不指定某种数据库或供应商。

智能体的记忆技能是什么？

技能是一套智能体可以读取并执行的可复用流程。它能跨会话保留做事的方法；要学习和更新客户事实，则需要独立的写入与读取生命周期。

AI 智能体记忆架构包括什么？

它结合两条路径：写入路径保存有用信息，读取路径为模型请求选出当前有效且有权使用的材料。持久化、身份、纠错、到期机制和上下文预算，都是架构的一部分。

有哪些智能体记忆的实际例子？

未完成的退款工单需要会话状态。老客户已确认的语言偏好需要持久记录。退款操作手册适合放进技能或指令文件。当前请求需要时，这些信息才进入上下文窗口。

订阅邮件通讯，获取更多关于构建和运营智能体的实用指南。