借助 AgentCore Memory 為智能體應用添加記憶功能
在構建智能體（Agentic）應用時，上下文是決定模型響應質量的關鍵因素。各類智能體框架（如 LangGraph、CrewAI 等）的核心作用，本質上是構建包含充足上下文的增強型提示詞（Prompt），幫助模型生成貼合需求的結果。而記憶系統作為上下文的重要來源，能讓智能體記住交互歷史、用戶偏好等關鍵信息，大幅提升應用的個性化與連續性。AWS 推出的 AgentCore Memory 服務，正是為智能體應用提供短長期記憶管理的核心工具，本文將詳細介紹如何借助它為智能體賦予“記憶能力”。
智能體記憶的核心分類：短期與長期
在智能體應用的語境中，記憶系統普遍分為短期記憶與長期記憶兩類，二者各司其職，共同為增強型提示詞提供上下文支撐：
- 短期記憶：聚焦當前會話或任務周期內的信息，比如用戶當前的提問內容、智能體的即時響應、多步驟任務的中間狀態等。它的核心作用是保證單次交互的連貫性，例如在客服對話中，記住用戶剛提到的“產品型號”或“問題癥狀”。
- 長期記憶：則負責跨會話、跨周期的信息存儲，其分類可參考 LangMem 指南的定義，具體包括三類關鍵記憶：
語義記憶（Semantic Memory）：存儲支撐智能體響應的事實與知識，比如用戶的長期偏好（如“偏好中文界面”“對折扣敏感”）、領域特定信息（如某產品的保修政策）、交互歷史摘要（如“用戶上月曾咨詢過賬戶登錄問題”）。
情景記憶（Episodic Memory）：記錄成功的交互案例作為學習樣本，不僅包含“發生了什么”（如用戶投訴物流延遲），還包括“如何解決”（如智能體觸發物流查詢工具并承諾補償）以及“為何有效”（如及時反饋安撫了用戶情緒），幫助智能體復用有效策略。
過程記憶（Procedural Memory）：定義智能體的行為規則與響應模式，例如“當用戶提及退款時，需先驗證訂單狀態”，這類記憶會動態補充到系統提示詞中，約束智能體的行為邊界。
AgentCore Memory：AWS 智能體記憶服務的核心邏輯
AgentCore Memory 是 AWS 專為智能體應用設計的記憶管理服務，完美契合上述“短長期記憶”框架，同時提供靈活的策略配置與 API 交互能力，讓記憶集成更高效。
1. 核心層級：短期記憶與長期記憶的協同
AgentCore Memory 的運作圍繞“記憶資源（Memory Resource）”展開，每個記憶資源相當于一個“記憶容器”，可同時存儲多個用戶、多個會話的短長期記憶。其兩層記憶系統的分工與流轉邏輯如下：
- 短期記憶：用于存儲即時會話數據，每一次用戶提問、智能體響應都會以“事件（Event）”的形式被記錄。例如用戶發送“查詢我的訂單物流”，智能體返回“正在查詢訂單 12345 的物流狀態”，這兩條信息會作為兩個事件，關聯到用戶的
actorId（用戶標識）和sessionId（會話標識），存入短期記憶。 - 長期記憶：并非直接存儲原始會話數據，而是通過“策略（Strategy）”對短期記憶中的原始數據進行提煉。例如，將多次會話中用戶提到的“偏好順豐快遞”“常用收貨地址為北京朝陽區”提取為用戶偏好，或把“訂單 12345 物流延遲，已補償 10 元優惠券”的會話摘要存入長期記憶，供后續跨會話復用。
2. 關鍵操作：事件管理與策略配置
（1）事件操作：短期記憶的核心交互
AgentCore Memory 通過三類 API 操作管理短期記憶中的事件，所有操作均需指定 memoryId（記憶資源標識），并通過 actorId 和 sessionId 定位到具體用戶與會話：
create_event：創建事件，需傳入payload（ payload 可是字典格式的會話文本，或二進制格式的blob數據，如用戶上傳的訂單截圖）與eventTimestamp（事件時間戳）。delete_event：刪除指定eventId的事件，適用于清理敏感信息（如用戶要求刪除某條提問記錄）。get_event/list_event：查詢單個事件或列出某會話下的所有事件，用于加載歷史會話上下文。
例如，創建一條用戶提問事件的 API 調用邏輯（偽代碼）如下：
create_event(
memoryId="my-agent-memory-001",
actorId="user-123",
sessinotallow="session-456",
eventTimestamp="2024-05-20T14:30:00Z",
payload={"role": "user", "content": "我的訂單 12345 還沒發貨嗎？"}
)（2）策略配置：長期記憶的提煉規則
要啟用長期記憶，需為記憶資源配置“策略”——策略決定了如何從短期記憶的原始數據中提取有用信息。AgentCore Memory 支持 4 種策略，覆蓋不同的長期記憶需求：
策略類型 | 作用說明 | 適用場景 |
語義策略（Semantic） | 提取事實性信息（如產品參數、訂單狀態） | 存儲領域知識、客觀數據 |
摘要策略（Summary） | 生成會話摘要，保留關鍵交互節點 | 跨會話回顧歷史對話核心內容 |
用戶偏好策略（User Preference） | 提取用戶的長期偏好（如語言、功能需求） | 個性化服務（如默認展示用戶偏好的界面） |
自定義策略（Custom） | 允許用戶自定義提取規則與模型 | 特殊業務場景（如提取合規相關信息） |
其中，內置策略（語義、摘要、用戶偏好）已集成底層模型的推理能力，無需額外配置模型；而自定義策略需用戶提供專屬指令（補充到系統提示詞中），并指定適配的模型，靈活性更高。
3. 成本差異：內置策略與自定義策略的定價
AgentCore Memory 的定價與策略類型強相關（當前處于預覽階段）：
- 內置策略：每月每 1000 條記憶存儲成本為 0.75 美元，包含底層模型的推理費用。
- 自定義策略：每月每 1000 條記憶存儲成本為 0.25 美元，但需單獨支付模型調用費用。
若應用對記憶提取規則無特殊要求，選擇內置策略更省心；若需適配特定業務邏輯（如金融領域的合規信息提取），自定義策略雖需額外管理模型，但成本更低。
實戰：將 AgentCore Memory 集成到智能體應用
將 AgentCore Memory 集成到智能體的核心是“提前創建記憶資源+通過工具或生命周期鉤子交互”，同時需注意生產環境的安全性與性能優化。
1. 前置準備：創建記憶資源（生產環境關鍵步驟）
在生產環境中，記憶資源需通過基礎設施即代碼（IaC） 提前創建（如使用 AWS CloudFormation 或 Terraform），而非在智能體運行時動態創建。原因在于：
- 智能體運行時創建記憶資源屬于“控制平面操作”，這類操作的配額遠低于“數據平面操作”（如創建事件），若動態創建，應用擴容時易觸發限流。
- 提前創建可便于配置最小權限 IAM 策略，保障記憶數據安全。
例如，通過 CloudFormation 創建記憶資源后，可為智能體配置如下 IAM 策略，僅允許其操作指定前綴的記憶資源（MemoryName-*），避免越權訪問：
{
"PolicyName": "bedrock-agentcore",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock-agentcore:CreateEvent",
"bedrock-agentcore:DeleteEvent",
"bedrock-agentcore:GetEvent",
"bedrock-agentcore:ListEvents",
"bedrock-agentcore:RetrieveMemoryRecords"
],
"Resource": [
"arn:aws:bedrock-agentcore:${AWS::Region}:${AWS::AccountId}:memory/${MemoryName}-*"
]
}
]
}
}2. 兩種集成方式：工具調用 vs 生命周期鉤子
智能體與 AgentCore Memory 的交互主要有兩種方式，需根據框架支持度與業務需求選擇：
（1）工具調用方式：通過工具函數交互
將 get_memory()（讀取記憶）、put_memory()（寫入記憶）等函數封裝為智能體的“工具”，并在系統提示詞中指導模型何時調用這些工具。例如：
- 當用戶提問“我的偏好是什么”時，模型調用
get_memory()讀取長期記憶中的用戶偏好； - 當用戶新設置“默認接收郵件通知”時，模型調用
put_memory()將該偏好寫入長期記憶。
這種方式的優勢是邏輯直觀，適合簡單場景，但需開發者手動設計工具調用規則，靈活性較低。
（2）生命周期鉤子方式：事件驅動的自動化交互
更推薦的方式是利用智能體框架的“生命周期鉤子”，將記憶操作綁定到智能體運行的特定階段，實現自動化交互。以 Strands 框架為例，其支持 4 類關鍵鉤子，可與記憶操作精準匹配：
生命周期鉤子 | 觸發時機 | 對應的記憶操作 |
AgentInitializedEvent | 智能體初始化完成后 | 加載核心語義記憶（如產品保修政策） |
BeforeInvocationEvent | 新的用戶請求開始時 | 讀取短期記憶中最近 N 條會話記錄，補充上下文 |
AfterInvocationEvent | 智能體響應生成后 | 將本次會話的關鍵信息（如用戶新需求）寫入短期記憶 |
MessageAddedEvent | 會話歷史新增消息時 | 判定消息是否需長期存儲（如用戶偏好），觸發長期記憶提煉 |
這種方式無需開發者手動 orchestrate 記憶操作，由事件驅動自動完成，大幅降低維護成本——前提是所使用的智能體框架支持生命周期鉤子（如 Strands、LangGraph 等）。
避坑指南：避免“上下文過載”，做好上下文工程
隨著模型上下文窗口的擴大（如 GPT-4.1、Claude Sonnet 4 支持 100 萬 Token），開發者易陷入“越多上下文越好”的誤區。但《Lost in the Middle：語言模型如何使用長上下文》白皮書指出，模型對長上下文的利用存在“U 型曲線”：
- 對開頭（首因效應）和結尾（近因效應）的信息處理效果最好；
- 中間部分的信息易被“忽略”，導致模型誤判或遺漏關鍵內容。
例如，若將 100 條會話歷史全部塞入提示詞，模型可能只關注前 10 條和最后 10 條，中間 80 條的用戶需求會被忽略。因此，需通過“上下文工程”優化，確保提示詞中只包含“必要信息”：
- 刪減冗余內容：過濾掉與當前任務無關的歷史會話（如用戶半年前咨詢的無關功能問題）；
- 精簡工具列表：僅傳入智能體當前任務可能用到的工具（如處理訂單問題時，無需傳入“內容創作工具”）；
- 濃縮會話歷史：用摘要策略提取歷史會話的核心信息（如“用戶 3 月曾反饋物流延遲，已補償”），而非保留完整對話；
- 卸載無用上下文：將不再需要的信息（如已完成任務的中間狀態）從提示詞中移除，僅在需要時通過記憶系統讀取；
- 驗證上下文來源：通過 RAG（檢索增強生成）從可信數據源（如企業知識庫）拉取精準信息，確保上下文的準確性。
為智能體應用添加記憶，本質是讓模型獲得“持續學習”與“個性化響應”的能力，而 AgentCore Memory 憑借其靈活的短長期記憶管理、策略配置與 AWS 生態集成優勢，成為實現這一目標的高效工具。在實際開發中，需牢記“上下文并非越多越好”，通過合理的記憶策略與上下文工程，讓智能體在“記住關鍵信息”的同時，避免“信息過載”。
最終，只有當記憶系統提供的上下文“準確、適量、合規”，并搭配最小權限的安全防護時，智能體應用才能在生產環境中穩定、可靠地運行，真正滿足用戶的個性化需求。
