代理基礎設施
AWS 開源 AgentCore 記憶淘汰流程，以排程工作流補上內建 TTL 缺口
AWS 發布可由 CDK 部署的參考架構，定期替長期代理評分、合併及刪除記憶。這不是 AgentCore 的新原生 TTL 功能，且範例文件與程式庫對評分公式的描述尚未完全一致。
長期運行的代理會持續累積對話摘要、使用者偏好與操作經驗；若所有紀錄永久保留，檢索可能把已解決的事件或過期程序重新注入上下文。AWS 因此公開一套 [AgentCore Memory 生命週期參考架構](https://aws.amazon.com/blogs/machine-learning/designing-lifecycle-policies-for-agentcore-memory/)，把記憶區分為高頻、較快失效的 episodic memory，較耐久的 semantic memory，以及應審慎淘汰的 procedural memory。
這套方案不是 AgentCore 新增的內建自動 TTL。它利用 `ListMemoryRecords` 對系統建立時間套用 `BEFORE` 篩選，再由 EventBridge 每晚觸發 Step Functions；工作流串接 Lambda，依序執行到期刪除、相關性評分、批次合併、指標輸出及稽核紀錄。預設 episodic memory 的硬性保存期為 90 天；低分紀錄則交給 Bedrock 模型合併成帶有信心分數及來源 ID 的語意摘要，成功寫回後才刪除原件。失敗路徑會保留原始記憶並透過 SNS 示警。
工程價值在於把「忘記」變成可觀測、可回歸測試的資料管線。範例以 AgentCore Evaluations 比較整理前後的回答分數，並提供逐一刪除特定使用者記憶的處理器、CloudTrail API 稽核及 CloudWatch 儀表板。不過，[GitHub 程式庫](https://github.com/aws-samples/sample-memory-lifecycle-policies-for-bedrock-agentcore)明確標示為非生產用途；LLM 合併本質上有損，信心分數也不是忠實度證明，高風險部署仍應保存冷備份並加入人工或 grounding 驗證。
此外，公開材料目前存在版本落差：AWS 文章描述由建立時間、最近存取與存取頻率組成的三項評分，程式庫 README 卻展示兩項等權衰減公式；文章流程圖也列出五個 Lambda 階段，README 的資源清單則寫四個函式。部署者應以實際 commit 與合成後的 CloudFormation 為準，並確認 CloudTrail 查詢成本、刪除冪等性、租戶 namespace 隔離及資料保留法規，而不是直接採用示範閾值。