AWS发布AgentCore记忆生命周期管理方案：夜间清理AI智能体过时记忆
AWS博客公布一套基于Step Functions的夜间记忆生命周期工作流，对Amazon Bedrock AgentCore智能体记忆进行TTL过期、相关性评分与整合修剪，并配套AWS CDK代码和回归测试。
AI解读：长期运行的AI智能体会把每次对话都存成记忆，不清理就会积累过时信息，既降低回答质量，也带来合规风险——AWS在案例中观察到客服智能体把四个月前已解决的账单纠纷当作当前问题。AWS这篇博客给出了一套可部署的工程方案：用一个共享记忆分类法，把记忆分为情节记忆、语义记忆和程序记忆三类，分别设定不同保留期；再加每晚运行的AWS Step Functions工作流，依次执行TTL过期删除、相关性衰减评分（按创建时间、最近访问时间和访问频率三项加权）、以及用Amazon Bedrock大模型把低分情节记忆整合成语义记忆，最后修剪分数低于阈值的记忆。这套方案的直接价值在于：给存储量大、运行数周以上的客服、销售、IT帮助台机器人提供了自动化的内存治理框架，并配有回归测试套件（用AgentCore Evaluations做LLM-as-judge打分）来确认修剪没有降低回答质量，以及GDPR删除处理器来满足合规删除要求。需要说明的是，这只是AWS官方博客的参考架构，不是托管服务——AgentCore memory本身不提供内置TTL自动删除，需要你自己部署CDK栈运行；对低流量个人助理类智能体，作者建议可以只用TTL和GDPR合规即可，不必跑全套工作流。成本取决于Amazon Bedrock调用量，官方估算 1000 条记忆中 20% 低于阈值时每夜约 20 次调用、约 0.01–0.02 美元，10 万条记忆则可能每月 50–100 美元。相关运维人员应把pruneDays、权重等参数在部署时调好，并先用回归测试验证质量；普通用户无需立即行动。
AWS Machine Learning博客发布一篇新文章，介绍如何为Amazon Bedrock AgentCore上的长期运行智能体设计记忆生命周期策略。文章给出可部署的架构，使用AgentCore memory、AWS Step Functions和Amazon Bedrock运行夜间生命周期工作流，代码以AWS CDK栈形式提供并托管在GitHub仓库。
文章指出，如果不对智能体记忆进行主动管理，智能体会积累过时上下文，从而降低响应质量并带来合规风险。作者观察到两个实例：一个客服智能体引用了四个月前已解决的账单纠纷并将其视为当前问题；另一个智能体因记忆中仍保留已被取代的运行手册，重复给出过时的部署建议。
记忆类型与三类生命周期策略
文章将智能体记忆分为三类：情节记忆记录对话历史，带时间戳、绑定会话、数量大，AgentCore memory用Summary和Episodic两种策略存储；语义记忆是从交互中提炼的事实和偏好，与单个对话解耦，如“用户偏好使用us-east-1区域部署”，这类记忆更持久、价值高、体积紧凑；程序记忆编码学习到的工作流和工具使用模式，如“当用户询问成本时，先查询AWS Cost Explorer API再总结”，数量少但对特定用例价值最高。
基于该分类法，文章提出三种互补的生命周期策略：TTL过期删除默认对情节记忆设 90 天，摘要记忆建议 30–60 天，语义记忆 6–12 个月，程序记忆可不设TTL；相关性衰减评分用三项加权公式计算每条记忆的分数，低于阈值则标记为待整合或修剪；基于LLM的整合把多个情节观察合成一条权威事实，仅对分数低于阈值的记忆进行。
- TTL策略在评分和整合之前执行，避免对已应删除的记忆浪费计算资源。AgentCore memory不提供内置自动删除TTL，但暴露系统生成的时间戳字段，支持ListMemoryRecords上的BEFORE/AFTER过滤操作符，修剪器使用x-amz-agentcore-memory-createdAt和BEFORE过滤器获取早于TTL的记录并删除。
- 相关性评分公式为score = W_RECENCY * exp(-decay_rate * days_since_creation) + W_ACCESS * exp(-decay_rate * days_since_last_access) + W_FREQUENCY * min(access_count / MAX_ACCESS_BASELINE, 1.0)。默认权重为W_RECENCY=0.4、W_ACCESS=0.35、W_FREQUENCY=0.25，MAX_ACCESS_BASELINE=50，权重之和为 1.0 时分数落在 0.0–1.0 之间。
- 公式中decay_rate由参数pruneDays决定：decay_rate = -ln(threshold) / prune_days。默认pruneDays=45、threshold=0.3 时，decay_rate约为 0.02676。评分会在最初几周迅速下降，之后趋于平缓；记忆虽旧但最近被访问且频繁访问，仍可获较高分数。
- pruneDays推荐起点因智能体类型而异：实时支持机器人 7 天，销售/入职智能体 21 天，通用助手 45 天，IT帮助台/运维智能体 90 天，法律/合规顾问 180 天。
工作流、测试与隐私合规
方案以共享记忆分类法和三个生命周期策略为基础，组成夜间工作流。CDK栈用EventBridge规则在每天UTC时间 2:00 触发状态机，状态机以TTL过期开始，然后评分，再根据是否存在低于阈值的记忆分支执行批量整合。所有可配置参数（memoryTtlDays、relevanceThreshold、consolidationBatchSize、pruneDays、bedrockModelId和评分权重）都从CDK context读取，可在部署时用 -c参数调整而无需改代码。
成本主要来自整合阶段的Amazon Bedrock调用。对于有 1000 条记忆且 20% 低于阈值的智能体，预计每夜约 20 次调用、约 0.01–0.02 美元；10 万条记忆时每月可能达 50–100 美元。文章建议从较高的相关性阈值开始以限制整合数量。
为确认修剪和整合没有降低回答质量，方案包含一个记忆回归测试套件，采用前后对比模式：在生命周期运行前用一组“问题和标准”对查询智能体，记录基线质量分数；运行夜间工作流后再次查询同一组问题，记录新分数。测试用例在事后分数达到或超过设定最低质量分数时通过，并计算质量差值（post - baseline）。套件与AgentCore Evaluations集成，后者作为LLM-as-judge系统，输入智能体响应和人工定义的标准，返回 0.0–1.0 的归一化质量分数，使套件完全自动化并适用于CI/CD流水线。
方案还包含一个专门的GDPR删除处理器，用于删除特定用户的所有记忆：列出该用户在AgentCore memory中的所有记忆并逐一删除，返回状态、已删除数量和失败ID。若部分失败，响应会包含失败的记忆标识以便调查和重试。每个记忆变更（评分、整合、修剪、GDPR删除）都会在Amazon CloudWatch Logs中生成包含动作类型、记忆ID和ISO 8601时间戳的结构化JSON日志，CDK栈还配置AWS CloudTrail记录AgentCore memory API调用，提供不可变审计跟踪。
- 例如，记忆回归测试套件中的示例包含两个测试用例：“用户偏好的编程语言是什么”要求响应提及之前讨论过的具体语言，最低质量分数 0.7；“总结我们上次一起做的项目”要求响应包含项目名称、关键里程碑和结果，最低分数 0.6。运行示例显示两个用例均通过，质量分数基线 0.82/0.74，生命周期后 0.85/0.71。