给 Amazon Bedrock AgentCore 做记忆生命周期

很多跑在 Amazon Bedrock AgentCore 上的 Agent 在生产环境跑几个月后，响应质量会莫名其妙下降。我发现一个很坑的点：如果不对记忆进行清理，Agent 会把几个月前已经解决的争议或者过时的操作手册当成当前的上下文。比如某个客户四个月前有个账单纠纷已经处理完了，结果 Agent 还在对话里把它当成活跃事件提起，这不仅显得呆，在某些严苛的业务场景下甚至有合规风险。

说白了，Agent 每一次对话都在产生记忆，如果不主动管理，它就会在海量过时信息里打转。要解决这个问题，不能只靠简单的 TTL（生存时间）过期，得搞一套“打分-整合-裁剪”的 nightly workflow。

这里分享一个基于 AgentCore memory、AWS Step Functions 和 Bedrock 构建的清理架构，核心逻辑是把记忆分成三类，给它们设置不同的权重和清理周期。

一、记忆类型的定义与处理策略

在写清理脚本之前，必须先给记忆分级，因为不同类型的记忆“保质期”完全不同：

• 情节记忆 (Episodic memory)： 记录的是“发生了什么”，也就是对话原件或摘要。这类信息量最大，且随时间快速失效。在生命周期策略里，这类记忆应该是第一批被清理或过期的。
• 语义记忆 (Semantic memory)： 它是从对话中提炼出的事实或偏好。比如“用户习惯在 us-east-1 区域部署”。这类信息价值高且紧凑，应该比情节记忆保留更久，并且是“整合”的核心——把多次对话中重复出现的观察结果合并成一条权威事实。
• 程序记忆 (Procedural memory)： 记录的是工作流和工具使用模式。比如“查成本时先调 Cost Explorer API 再汇总”。这类记忆最值钱，数量最少，清理门槛最高，通常保留时间最长。

二、自动化清理流程的实现步骤

要实现这个 nightly workflow，不能在对话实时链路里做（太慢），得异步跑。具体的实现路径如下：

1. 触发与扫描： 使用 AWS Step Functions 设定定时触发器，每天凌晨扫描 AgentCore memory 中所有标记为 Episodic 的条目。
2. 打分与筛选： 调用 Bedrock 模型对记忆条目进行相关性打分。如果一条记忆的时间戳已经超过阈值且打分较低，直接标记为删除。
3. 语义合并： 这是一个关键步骤。让模型扫描那些即将过期的情节记忆，判断其中是否包含需要永久保留的语义事实。如果发现了，就将其提取并写入 Semantic memory 存储区，然后再删掉原有的情节记录。
4. 执行裁剪： 通过 AWS CDK 部署的资源管理栈，统一执行删除指令，确保存储空间不被垃圾信息撑爆。

三、具体的部署配置参考

如果你打算复现这个方案，建议直接看这个 GitHub 仓库里的 CDK 堆栈（注意不要直接跑，先改配置）：

https://github.com/aws-samples/sample-memory-lifecycle-policies-for-bedrock-agentcore

在配置生命周期策略时，我建议的参数阈值参考：

• Episodic Memory： 建议保留 14-30 天，超过此时间且无高频引用则清理。
• Semantic Memory： 建议保留 90 天以上，除非被新事实覆盖。
• Procedural Memory： 基本不设置自动过期，除非手动更新 runbook。

这种架构最适合那种每天处理大量交互的客服机器人或 IT 助手。如果你只是做个简单的个人助理，数据量不大，其实用简单的 TTL 配合 GDPR 的删除要求就足够了，没必要搞这么复杂。但对于企业级 Agent，如果不做这种记忆治理，上下文窗口早晚会被垃圾信息填满，导致推理成本增加且准确率暴跌。