长时间运行的 AI Agent 会不断积累用户偏好、任务结论和历史上下文。记忆越多并不等于效果越好：过时信息会干扰推理，重复事实会增加检索噪声，保留不再需要的敏感数据还会扩大合规风险。
针对 Amazon Bedrock AgentCore memory，可以把记忆治理设计成一条夜间批处理流水线：先评分，再合并，最后按策略清理。AWS Step Functions 负责分页、并发、重试和审计，AWS CDK 则把状态机、Lambda、调度器与权限作为一套基础设施部署。
不要只按创建时间删除
简单的“保留 30 天”规则容易误删长期偏好，也可能让高风险数据滞留太久。更实用的策略会综合多个信号：
- 新鲜度：距离最后一次确认或使用过去了多久。
- 使用价值：近期是否被检索、引用或影响过 Agent 决策。
- 置信度：记忆来自用户明确陈述，还是模型推断。
- 冗余度：是否存在语义接近、更新或更可信的记忆。
- 风险等级：是否包含个人信息、凭据、财务数据或受监管内容。
- 保留约束：是否处于法律保留、调查或人工锁定状态。
一种可解释的保留分数可以写成：
retention_score = 0.35 * freshness
+ 0.30 * usage
+ 0.25 * confidence
- 0.10 * redundancy
分数不是删除命令。它只是分类依据，例如高分继续保留，中间区间进入合并流程，低分且超过最短保留期的记忆才成为清理候选。高风险数据还应采用独立的最长保留期限，而不是依赖同一套权重。
夜间状态机应该怎样拆分
可以将 Step Functions 工作流拆成以下状态：
ListMemoryPages按租户或 Agent 分页列出记忆，避免一次把全部数据装入内存。ScoreMemories用 Lambda 计算分数、风险标签和建议动作。ConsolidateCandidates把重复或相互替代的记忆压缩成一条摘要，并保留来源 ID。ApprovalGate将法律保留、低置信度冲突和敏感数据送入人工审核队列。PruneMemories删除或软删除符合条件的条目。WriteAuditRecord记录策略版本、原因、输入摘要、操作人和执行时间。
合并必须发生在清理之前。否则，两条各自看似价值较低、合在一起却能表达稳定偏好的记忆，可能被直接删除。
生产状态机还需要三个工程约束：每个动作都使用幂等键；删除任务配置有限次数重试和死信队列；单个租户失败不能中止整晚批次。Step Functions 的 Map 状态适合控制租户级并发，但并发上限应根据 AgentCore API 配额和 Lambda 保留并发共同计算。
可以直接运行的策略原型
下面的 Python 程序不依赖 AWS SDK，可以先在本地验证阈值。示例假设输入已经由 AgentCore memory 适配层转换为统一字段；接入真实环境时，只需替换读取和写回部分。
from dataclasses import dataclass
from datetime import datetime, timezone
@dataclass
class Memory:
memory_id: str
age_days: int
uses_30d: int
confidence: float
redundancy: float
risk: str = 'normal'
legal_hold: bool = False
def clamp(value: float) -> float:
return max(0.0, min(1.0, value))
def classify(memory: Memory) -> tuple[str, float, str]:
if memory.legal_hold:
return 'retain', 1.0, 'legal_hold'
freshness = clamp(1 - memory.age_days / 90)
usage = clamp(memory.uses_30d / 10)
score = (
0.35 * freshness
+ 0.30 * usage
+ 0.25 * memory.confidence
- 0.10 * memory.redundancy
)
if memory.risk == 'sensitive' and memory.age_days > 30:
return 'review_or_prune', score, 'sensitive_retention_limit'
if memory.age_days < 14:
return 'retain', score, 'minimum_retention_window'
if score < 0.20:
return 'prune', score, 'low_retention_score'
if score < 0.55 or memory.redundancy > 0.75:
return 'consolidate', score, 'low_value_or_redundant'
return 'retain', score, 'useful_memory'
memories = [
Memory('m-001', 120, 0, 0.40, 0.90),
Memory('m-002', 45, 4, 0.95, 0.80),
Memory('m-003', 40, 1, 0.90, 0.10, legal_hold=True),
Memory('m-004', 35, 2, 0.70, 0.20, risk='sensitive'),
]
for item in memories:
action, score, reason = classify(item)
print({
'memory_id': item.memory_id,
'action': action,
'score': round(score, 3),
'reason': reason,
'evaluated_at': datetime.now(timezone.utc).isoformat(),
'policy_version': '2025-01',
})
运行方式：
python3 memory_policy.py
把它迁入 Lambda 时，建议让评分函数只返回决策，不直接删除数据。真正的删除由单独的 PruneMemories Lambda 执行，并要求输入携带 policy_version、execution_id 和目标记忆的版本号。这样能避免策略更新或并发写入造成误删。
用 CDK 部署时关注这些边界
一套可部署的 CDK 栈通常包含 EventBridge Scheduler、Step Functions 状态机、多个职责单一的 Lambda、审计存储、告警和最小权限 IAM 角色。可以这样组织并部署项目：
agent-memory-lifecycle/
├── app.py
├── stacks/memory_lifecycle_stack.py
├── functions/score.py
├── functions/consolidate.py
├── functions/prune.py
└── statemachine/lifecycle.asl.json
python3 -m venv .venv
source .venv/bin/activate
pip install aws-cdk-lib constructs
cdk bootstrap
cdk synth
cdk deploy
这里的 AgentCore 读写调用应封装在适配器中，因为实际 SDK 接口和资源标识取决于所使用的 AgentCore memory 配置。IAM 不应给状态机或 Lambda 全局通配权限；把权限限制到目标记忆资源、审计表、队列和日志组。
上线前先运行“影子模式”：状态机照常评分和生成清理清单，但不执行删除。至少观察一个完整保留周期，比较误删候选、合并质量、每租户处理成本和 API 节流情况。确认结果稳定后，再从软删除过渡到物理删除，并为高风险类别保留人工审批与可恢复窗口。