亞馬遜Bedrock藏了3個評分維度，AI終于學會"長記性"

你的Agent能調取過去6個月的全部會議記錄，卻在回答項目 deadline 時，把昨天剛敲定的關鍵節點埋在3月的幾十條無關狀態更新下面。

技術上全對，體驗上全廢。這是大多數Agent的通病——除非你有意識地設計檢索邏輯。

斯坦福的25個虛擬人，把記憶問題演成了行為藝術

斯坦福研究團隊構建"生成式智能體（Generative Agents）"時，給虛擬小鎮塞了25個模擬角色。每個Agent能存儲數千條觀察記錄，但問到"接下來該做什么"時，系統只靠關鍵詞隨機檢索。

結果出現荒誕循環：同一個Agent連續五次走進咖啡館，因為記憶系統分不清"我五分鐘前剛喝過"和"我一般午飯時間來"。

研究團隊用三個評分維度破解了這個困局：時效性（recency）——這件事何時發生；重要性（importance）——這件事有多關鍵；相關性（relevance）——與當前處境的關聯程度。

Amazon Bedrock AgentCore 現在把這套機制封裝成企業級基礎設施。但為什么這些維度有效、如何配置，得回到那項研究的具體設計里找答案。

上下文窗口越大，幻覺越隱蔽

大語言模型能處理極長的上下文，但這能力本身是個陷阱。企業常誤以為：給Agent完整的對話歷史和知識庫，就能產出智能行為。實際運行中，這套邏輯頻頻翻車。

想象一個客服場景：用戶提到三個月前的賬單問題、詢問當前的功能需求、還想約個電話。Agent的記憶庫里躺著數千條交互記錄，涵蓋賬單糾紛、功能反饋、日程沖突、甚至上周閑聊時提的咖啡偏好。

沒有評分機制的Agent，把所有記憶視為同等重要。上下文窗口被最近存儲的內容或基礎關鍵詞匹配填滿——它可能調取用戶上周隨口說的拿鐵口味，卻漏掉需要立即處理的賬單升級模式。

斯坦福的研究把這種失效模式量化呈現了。模擬角色Klaus Mueller被問到"推薦誰一起度過時間"時，無評分版本的系統選了Wolfgang，僅僅因為這個名字在近期觀察中出現頻率高。實際上，兩人從未有過實質性交流。

他們只是住在同一街區。

三個維度如何改寫檢索邏輯

引入三維評分后，同一問題的輸出完全不同。時效性壓低三個月前的舊記錄權重，重要性把賬單糾紛標記為高優先級，相關性確保功能需求和日程安排進入候選集。

Bedrock AgentCore 的實現允許開發者自定義各維度權重。客服場景可能調高時效性和重要性，法律文檔分析可能側重相關性和重要性，創意寫作助手或許給時效性更低權重以保留長期靈感。

這種靈活性對應著斯坦福研究的核心發現：記憶的價值不是存儲本身，而是檢索時的決策質量。

研究團隊記錄了一個典型對比。無評分系統中，Agent Maria在虛擬小鎮連續三天去同一家餐廳，因為"餐廳"關鍵詞高頻出現且近期有記錄。引入三維評分后，Maria開始根據當天心情、社交關系變化、甚至天氣選擇不同場所——行為模式從機械重復轉向情境適應。

企業部署時的真實權衡

Bedrock AgentCore 把這套機制打包成可配置模塊，但企業落地時面臨具體選擇。時效性權重過高，Agent變成"金魚記憶"，反復詢問剛確認過的信息；重要性權重過高，可能固化早期形成的偏見判斷；相關性算法設計不當，會制造"信息繭房"，只檢索與當前查詢字面匹配的內容。

AWS 官方文檔建議從均等權重起步，根據實際對話日志迭代調整。一個被驗證的模式是：客服場景時效性40%、重要性35%、相關性25%；知識庫問答場景調整為時效性20%、重要性30%、相關性50%。

這些數字不是最佳實踐，而是調試起點。每個業務場景的"重要"定義不同——賬單糾紛在SaaS公司是P0，在內容平臺可能是P2。

斯坦福研究的25個虛擬人跑了兩天模擬，產生數萬條交互記錄。Bedrock AgentCore 面對的是真實企業的百萬級會話。規模差異意味著評分算法需要更精細的工程優化，但底層邏輯沒變：讓Agent"記得"不如讓它"記得該記的"。

當Klaus Mueller最終推薦了一位真正有過深度交流的角色時，研究團隊記錄了他的檢索日志：時效性過濾掉兩周前的表面寒暄，重要性保留了那次關于職業焦慮的長談，相關性確認了對方當前的時間可用性。

三個維度的乘積，決定了一條記憶是否值得被想起。你的Agent現在擁有同樣的計算框架——問題是，你準備讓它記住什么、又忘記什么？