在構(gòu)建智能體（Agentic）應(yīng)用時(shí)，上下文是決定模型響應(yīng)質(zhì)量的關(guān)鍵因素。各類智能體框架（如 LangGraph、CrewAI 等）的核心作用，本質(zhì)上是構(gòu)建包含充足上下文的增強(qiáng)型提示詞（Prompt），幫助模型生成貼合需求的結(jié)果。而記憶系統(tǒng)作為上下文的重要來源，能讓智能體記住交互歷史、用戶偏好等關(guān)鍵信息，大幅提升應(yīng)用的個(gè)性化與連續(xù)性。AWS 推出的 AgentCore Memory 服務(wù)，正是為智能體應(yīng)用提供短長期記憶管理的核心工具，本文將詳細(xì)介紹如何借助它為智能體賦予“記憶能力”。

智能體記憶的核心分類：短期與長期

在智能體應(yīng)用的語境中，記憶系統(tǒng)普遍分為短期記憶與長期記憶兩類，二者各司其職，共同為增強(qiáng)型提示詞提供上下文支撐：

• 短期記憶：聚焦當(dāng)前會(huì)話或任務(wù)周期內(nèi)的信息，比如用戶當(dāng)前的提問內(nèi)容、智能體的即時(shí)響應(yīng)、多步驟任務(wù)的中間狀態(tài)等。它的核心作用是保證單次交互的連貫性，例如在客服對(duì)話中，記住用戶剛提到的“產(chǎn)品型號(hào)”或“問題癥狀”。
• 長期記憶：則負(fù)責(zé)跨會(huì)話、跨周期的信息存儲(chǔ)，其分類可參考 LangMem 指南的定義，具體包括三類關(guān)鍵記憶：

語義記憶（Semantic Memory）：存儲(chǔ)支撐智能體響應(yīng)的事實(shí)與知識(shí)，比如用戶的長期偏好（如“偏好中文界面”“對(duì)折扣敏感”）、領(lǐng)域特定信息（如某產(chǎn)品的保修政策）、交互歷史摘要（如“用戶上月曾咨詢過賬戶登錄問題”）。

情景記憶（Episodic Memory）：記錄成功的交互案例作為學(xué)習(xí)樣本，不僅包含“發(fā)生了什么”（如用戶投訴物流延遲），還包括“如何解決”（如智能體觸發(fā)物流查詢工具并承諾補(bǔ)償）以及“為何有效”（如及時(shí)反饋安撫了用戶情緒），幫助智能體復(fù)用有效策略。

過程記憶（Procedural Memory）：定義智能體的行為規(guī)則與響應(yīng)模式，例如“當(dāng)用戶提及退款時(shí)，需先驗(yàn)證訂單狀態(tài)”，這類記憶會(huì)動(dòng)態(tài)補(bǔ)充到系統(tǒng)提示詞中，約束智能體的行為邊界。

AgentCore Memory：AWS 智能體記憶服務(wù)的核心邏輯

AgentCore Memory 是 AWS 專為智能體應(yīng)用設(shè)計(jì)的記憶管理服務(wù)，完美契合上述“短長期記憶”框架，同時(shí)提供靈活的策略配置與 API 交互能力，讓記憶集成更高效。

1. 核心層級(jí)：短期記憶與長期記憶的協(xié)同

AgentCore Memory 的運(yùn)作圍繞“記憶資源（Memory Resource）”展開，每個(gè)記憶資源相當(dāng)于一個(gè)“記憶容器”，可同時(shí)存儲(chǔ)多個(gè)用戶、多個(gè)會(huì)話的短長期記憶。其兩層記憶系統(tǒng)的分工與流轉(zhuǎn)邏輯如下：

• 短期記憶：用于存儲(chǔ)即時(shí)會(huì)話數(shù)據(jù)，每一次用戶提問、智能體響應(yīng)都會(huì)以“事件（Event）”的形式被記錄。例如用戶發(fā)送“查詢我的訂單物流”，智能體返回“正在查詢訂單 12345 的物流狀態(tài)”，這兩條信息會(huì)作為兩個(gè)事件，關(guān)聯(lián)到用戶的 actorId（用戶標(biāo)識(shí)）和 sessionId（會(huì)話標(biāo)識(shí)），存入短期記憶。
• 長期記憶：并非直接存儲(chǔ)原始會(huì)話數(shù)據(jù)，而是通過“策略（Strategy）”對(duì)短期記憶中的原始數(shù)據(jù)進(jìn)行提煉。例如，將多次會(huì)話中用戶提到的“偏好順豐快遞”“常用收貨地址為北京朝陽區(qū)”提取為用戶偏好，或把“訂單 12345 物流延遲，已補(bǔ)償 10 元優(yōu)惠券”的會(huì)話摘要存入長期記憶，供后續(xù)跨會(huì)話復(fù)用。

2. 關(guān)鍵操作：事件管理與策略配置

（1）事件操作：短期記憶的核心交互

AgentCore Memory 通過三類 API 操作管理短期記憶中的事件，所有操作均需指定 memoryId（記憶資源標(biāo)識(shí)），并通過 actorId 和 sessionId 定位到具體用戶與會(huì)話：

• create_event：創(chuàng)建事件，需傳入 payload（ payload 可是字典格式的會(huì)話文本，或二進(jìn)制格式的blob數(shù)據(jù)，如用戶上傳的訂單截圖）與 eventTimestamp（事件時(shí)間戳）。
• delete_event：刪除指定 eventId 的事件，適用于清理敏感信息（如用戶要求刪除某條提問記錄）。
• get_event/list_event：查詢單個(gè)事件或列出某會(huì)話下的所有事件，用于加載歷史會(huì)話上下文。

例如，創(chuàng)建一條用戶提問事件的 API 調(diào)用邏輯（偽代碼）如下：

create_event(
    memoryId="my-agent-memory-001",
    actorId="user-123",
    sessinotallow="session-456",
    eventTimestamp="2024-05-20T14:30:00Z",
    payload={"role": "user", "content": "我的訂單 12345 還沒發(fā)貨嗎？"}
)

（2）策略配置：長期記憶的提煉規(guī)則

要啟用長期記憶，需為記憶資源配置“策略”——策略決定了如何從短期記憶的原始數(shù)據(jù)中提取有用信息。AgentCore Memory 支持 4 種策略，覆蓋不同的長期記憶需求：

其中，內(nèi)置策略（語義、摘要、用戶偏好）已集成底層模型的推理能力，無需額外配置模型；而自定義策略需用戶提供專屬指令（補(bǔ)充到系統(tǒng)提示詞中），并指定適配的模型，靈活性更高。

3. 成本差異：內(nèi)置策略與自定義策略的定價(jià)

AgentCore Memory 的定價(jià)與策略類型強(qiáng)相關(guān)（當(dāng)前處于預(yù)覽階段）：

• 內(nèi)置策略：每月每 1000 條記憶存儲(chǔ)成本為 0.75 美元，包含底層模型的推理費(fèi)用。
• 自定義策略：每月每 1000 條記憶存儲(chǔ)成本為 0.25 美元，但需單獨(dú)支付模型調(diào)用費(fèi)用。

若應(yīng)用對(duì)記憶提取規(guī)則無特殊要求，選擇內(nèi)置策略更省心；若需適配特定業(yè)務(wù)邏輯（如金融領(lǐng)域的合規(guī)信息提?。远x策略雖需額外管理模型，但成本更低。

實(shí)戰(zhàn)：將 AgentCore Memory 集成到智能體應(yīng)用

將 AgentCore Memory 集成到智能體的核心是“提前創(chuàng)建記憶資源+通過工具或生命周期鉤子交互”，同時(shí)需注意生產(chǎn)環(huán)境的安全性與性能優(yōu)化。

1. 前置準(zhǔn)備：創(chuàng)建記憶資源（生產(chǎn)環(huán)境關(guān)鍵步驟）

在生產(chǎn)環(huán)境中，記憶資源需通過基礎(chǔ)設(shè)施即代碼（IaC） 提前創(chuàng)建（如使用 AWS CloudFormation 或 Terraform），而非在智能體運(yùn)行時(shí)動(dòng)態(tài)創(chuàng)建。原因在于：

• 智能體運(yùn)行時(shí)創(chuàng)建記憶資源屬于“控制平面操作”，這類操作的配額遠(yuǎn)低于“數(shù)據(jù)平面操作”（如創(chuàng)建事件），若動(dòng)態(tài)創(chuàng)建，應(yīng)用擴(kuò)容時(shí)易觸發(fā)限流。
• 提前創(chuàng)建可便于配置最小權(quán)限 IAM 策略，保障記憶數(shù)據(jù)安全。

例如，通過 CloudFormation 創(chuàng)建記憶資源后，可為智能體配置如下 IAM 策略，僅允許其操作指定前綴的記憶資源（MemoryName-*），避免越權(quán)訪問：

{
  "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. 兩種集成方式：工具調(diào)用 vs 生命周期鉤子

智能體與 AgentCore Memory 的交互主要有兩種方式，需根據(jù)框架支持度與業(yè)務(wù)需求選擇：

（1）工具調(diào)用方式：通過工具函數(shù)交互

將 get_memory()（讀取記憶）、put_memory()（寫入記憶）等函數(shù)封裝為智能體的“工具”，并在系統(tǒng)提示詞中指導(dǎo)模型何時(shí)調(diào)用這些工具。例如：

• 當(dāng)用戶提問“我的偏好是什么”時(shí)，模型調(diào)用 get_memory() 讀取長期記憶中的用戶偏好；
• 當(dāng)用戶新設(shè)置“默認(rèn)接收郵件通知”時(shí)，模型調(diào)用 put_memory() 將該偏好寫入長期記憶。

這種方式的優(yōu)勢(shì)是邏輯直觀，適合簡(jiǎn)單場(chǎng)景，但需開發(fā)者手動(dòng)設(shè)計(jì)工具調(diào)用規(guī)則，靈活性較低。

（2）生命周期鉤子方式：事件驅(qū)動(dòng)的自動(dòng)化交互

更推薦的方式是利用智能體框架的“生命周期鉤子”，將記憶操作綁定到智能體運(yùn)行的特定階段，實(shí)現(xiàn)自動(dòng)化交互。以 Strands 框架為例，其支持 4 類關(guān)鍵鉤子，可與記憶操作精準(zhǔn)匹配：

這種方式無需開發(fā)者手動(dòng) orchestrate 記憶操作，由事件驅(qū)動(dòng)自動(dòng)完成，大幅降低維護(hù)成本——前提是所使用的智能體框架支持生命周期鉤子（如 Strands、LangGraph 等）。

避坑指南：避免“上下文過載”，做好上下文工程

隨著模型上下文窗口的擴(kuò)大（如 GPT-4.1、Claude Sonnet 4 支持 100 萬 Token），開發(fā)者易陷入“越多上下文越好”的誤區(qū)。但《Lost in the Middle：語言模型如何使用長上下文》白皮書指出，模型對(duì)長上下文的利用存在“U 型曲線”：

• 對(duì)開頭（首因效應(yīng)）和結(jié)尾（近因效應(yīng)）的信息處理效果最好；
• 中間部分的信息易被“忽略”，導(dǎo)致模型誤判或遺漏關(guān)鍵內(nèi)容。

例如，若將 100 條會(huì)話歷史全部塞入提示詞，模型可能只關(guān)注前 10 條和最后 10 條，中間 80 條的用戶需求會(huì)被忽略。因此，需通過“上下文工程”優(yōu)化，確保提示詞中只包含“必要信息”：

1. 刪減冗余內(nèi)容：過濾掉與當(dāng)前任務(wù)無關(guān)的歷史會(huì)話（如用戶半年前咨詢的無關(guān)功能問題）；
2. 精簡(jiǎn)工具列表：僅傳入智能體當(dāng)前任務(wù)可能用到的工具（如處理訂單問題時(shí)，無需傳入“內(nèi)容創(chuàng)作工具”）；
3. 濃縮會(huì)話歷史：用摘要策略提取歷史會(huì)話的核心信息（如“用戶 3 月曾反饋物流延遲，已補(bǔ)償”），而非保留完整對(duì)話；
4. 卸載無用上下文：將不再需要的信息（如已完成任務(wù)的中間狀態(tài)）從提示詞中移除，僅在需要時(shí)通過記憶系統(tǒng)讀??；
5. 驗(yàn)證上下文來源：通過 RAG（檢索增強(qiáng)生成）從可信數(shù)據(jù)源（如企業(yè)知識(shí)庫）拉取精準(zhǔn)信息，確保上下文的準(zhǔn)確性。

為智能體應(yīng)用添加記憶，本質(zhì)是讓模型獲得“持續(xù)學(xué)習(xí)”與“個(gè)性化響應(yīng)”的能力，而 AgentCore Memory 憑借其靈活的短長期記憶管理、策略配置與 AWS 生態(tài)集成優(yōu)勢(shì)，成為實(shí)現(xiàn)這一目標(biāo)的高效工具。在實(shí)際開發(fā)中，需牢記“上下文并非越多越好”，通過合理的記憶策略與上下文工程，讓智能體在“記住關(guān)鍵信息”的同時(shí)，避免“信息過載”。

最終，只有當(dāng)記憶系統(tǒng)提供的上下文“準(zhǔn)確、適量、合規(guī)”，并搭配最小權(quán)限的安全防護(hù)時(shí)，智能體應(yīng)用才能在生產(chǎn)環(huán)境中穩(wěn)定、可靠地運(yùn)行，真正滿足用戶的個(gè)性化需求。