AgentCore 记忆机制实战：短期与长期记忆如何跨会话生效

一个在回复结束时就遗忘的智能体是默认行为，但对补货助手来说却是错误的行为。AWS AgentCore 的记忆能力试图解决这个问题：通过一个记忆资源同时承载短期事件日志和长期提取记录，让智能体在全新会话中依然记得管理者的区域偏好。

AgentCore 记忆机制文章截图

业务场景：为什么智能体需要记住

Northwind Gear 运营着四十家门店，每周一补货。一位门店经理曾告诉补货助手，只需要关注华北地区。到了下周一的新会话，助手又问了一遍是哪个区域。模型本身没有问题——那句话从未离开它被说出的会话，后续会话根本无从查找。

这个案例揭示了默认无状态智能体的根本局限：会话边界等于记忆边界。AWS AgentCore 的九个能力中有三个支撑这个场景——Memory 提供记忆资源，Runtime 托管智能体并为每个会话分配独立 microVM，Identity 则把 actor id 作为记忆命名空间的分区键。

MicroVM 是一种轻量级虚拟机，由 AWS 在 Firecracker 技术基础上实现。与传统的虚拟机相比，MicroVM 启动速度快（毫秒级）、内存开销小，同时提供与硬件虚拟化相同级别的安全隔离。在 AgentCore Runtime 中，每个会话都会分配一个独立的 MicroVM，这意味着不同会话之间的文件系统、内存和进程完全隔离。这种隔离机制也解释了为什么智能体默认无法跨会话保留状态——因为新会话运行在一个全新的、干净的 MicroVM 中，前一个会话的内存状态根本不存在。要实现跨会话记忆，必须依赖外部持久化服务，这正是 AgentCore Memory 要解决的问题。

记忆的两半：短期事件与长期记录

AgentCore 的记忆资源把短期和长期放在同一个资源里，但机制完全不同。短期记忆是一个仅追加的事件日志，按 actor 和 session 作为键；长期记忆则是服务从这些事件中提取出的记录，写入命名空间。

关键在于：智能体本身从不存储偏好。它只负责追加对话轮次，然后向服务提问。写入事件这个动作同时触发了提取流程，所以第二个会话才能找到第一个会话说过的话。提取不属于调用过程——CLI 在 19 秒内返回（其中 12,117 毫秒是模型调用），记录则是稍后到达的。

actor id（参与者标识符） 是 AgentCore Identity 为每个调用主体分配的唯一标识，通常对应用户或客户身份。在记忆场景中，actor id 扮演命名空间分区键的角色：所有与该用户相关的记忆记录都归属于以 actor id 为前缀的路径下。这样，不同用户的记忆天然隔离，不需要在查询时额外编写过滤条件。Actor id 与 session id 的区别在于：session id 标识一次会话，而 actor id 标识一个长期主体（如门店经理），因此 actor id 能跨越多个会话保持不变，而 session id 每次会话都会变化。将 actor id 嵌入命名空间模板（如 /users/{actorId}/preferences），就实现了“隔离即键空间属性”的设计。

命名空间设计：隔离成为键空间的属性

记忆资源通过三种策略决定长期记录的存在形式：USER_PREFERENCE 策略把偏好写入 /users/{actorId}/preferences；EPISODIC 策略把情景写入 /episodes/{actorId}/{sessionId}，反思记录则写入上一层的 /episodes/{actorId}；SEMANTIC 策略把事实写入 /users/{actorId}/facts。

actor id 被放进命名空间模板，意味着隔离是键空间的固有属性，而不是某条代码路径需要记得加的过滤器。反思命名空间位于单次会话之上，因此对 /episodes/{actorId}/ 做前缀读取时，既能拿到单个 episode，也能拿到跨所有 episode 写下的经验。

检索时机：放在系统提示词里，而非工具中

检索发生在模型被调用之前，因为记录会成为系统提示词的一部分。每次调用都创建一个全新的 Agent，而不是每个会话复用一个。缓存的 Agent 会一直提供第一轮的回忆，而检索失败会被记录并吞掉——一个记不住的智能体仍然可用。

把检索放进系统提示词而非工具，是一个值得关注的架构选择：模型不依赖自己选择调用工具，记忆总是已经在上下文中。

系统提示词（System Prompt） 是每次调用大语言模型时在对话历史之前注入的一段指令或上下文，用于设定模型的行为、角色和可用的背景知识。与工具调用不同，系统提示词是模型每次推理时必然看到的输入，模型无需主动选择是否读取。在 AgentCore 的记忆架构中，检索到的长期记录被拼接进系统提示词，这样模型在生成回复时就已经拥有相关记忆，避免了“模型忘记调用工具”或“模型选择不调用工具”导致记忆未被使用的问题。将检索前置到模型调用之前，也意味着检索结果是确定性的、每次都会执行，而不是依赖模型的决策。这种设计提升了记忆的可靠性，但会增加每次调用的输入 token 数量（成本相应上升）。

实测验证：三条断言与一个独立检查

部署后运行的冒烟测试包含四条断言，全部通过：

第二个会话能检索到第一个会话写下的偏好；
actor A 无法检索到 actor B 的记忆；
EPISODIC 策略能回忆起此前失败的方法（"广州仓库不能用于华北补货"）；
没有其他用例的资源混入。

北区经理和南区经理分别写入各自的偏好命名空间，一个语义查询"这位门店经理为哪个区域补货"，对一人返回华北，对另一人返回华南。没有过滤器可以写错，因为 actor id 就是键的一部分。

提取延迟：情景记忆慢得超出预期

第三次断言带来一个意外发现：episodic 提取很慢，episode 在事件发生约十五分钟后才被写入。测试中偏好记录的提取在 1.5 秒内可见，但那是因为该偏好已被此前针对同一资源的运行提取过；新的 episode 则花了 959 秒。这不是策略损坏，而是一个更慢的队列——300 秒的超时只会失败。

对 /episodes/store_manager_north/ 的前缀读取会返回两类记录：归档在产生它的会话下的 BASE episode，以及写在上一层的 REFLECTION。这就是为什么一个模板含 {sessionId} 而另一个不含。

EPISODIC 策略（情景记忆策略） 是 AgentCore Memory 支持的三种长期记忆提取策略之一，用于记录和回忆具体的事件或经历（episode），例如“上次尝试补货时广州仓库失败了”。与之并列的还有 USER_PREFERENCE 策略（提取用户偏好，如“只关注华北地区”）和 SEMANTIC 策略（提取事实性知识，如“华北区包括北京、天津等”）。EPISODIC 记录通常包含 BASE 和 REFLECTION 两类：BASE 是事件本身的归档，挂在产生它的会话下；REFLECTION 是对事件的上层反思或总结，挂在 actor 层级。由于情景提取需要更复杂的后处理（如关联、归纳），其异步队列通常比偏好提取慢，实测延迟可达 15 分钟。

成本与排错

一次被追踪的调用消耗 3,433 输入 token 和 210 输出 token，跨两次模型调用，按每百万 token 0.62 和 1.85 美元计算约 0.0025 美元。记忆存储和提取调用另行计费，原文未测量这一项。

两个典型排错点：session id 长度不足 33 字符会在发送前失败（一个十六进制 uuid 只有 32 字符，差一个）；episodic 记录在 1500 秒内未出现不代表策略损坏，只需把期限提高到超过观察到的十五分钟。

关键经验

记忆是两套机制而非一套：你写入的事件日志，和服务提取的记录。只有后者能跨会话存活。把 actor id 放进命名空间模板，隔离就零成本且不会被某条代码路径遗忘。提取是异步且缓慢的，每条断言都需要超时，而每个超时都需要比你想象的更长。检索属于系统提示词，在模型调用之前，而不是模型可能选择或不选择的工具。拆除是真实的两步：remove all 清空契约，随后的部署执行删除。