AI代理為何天生健忘：無狀態API架構的代價

您可能見過這樣的循環：一位客户第四次聯繫基於前沿模型構建的支持代理。他們已兩次提供賬號，兩次解釋問題。代理禮貌地再次詢問：“能否確認您的賬號以便我查詢？”模型並未損壞，只是其外圍框架沒有傳遞之前的對話輪次。而API設計本身就沒有記憶兩個消息前的內容。

這不是邊界情況，而是每個主流LLM提供商API的默認行為，也是當前agent系統在生產中面臨的最大摩擦源。原因在於架構而非偶然，而該架構的成本最終都會體現在每張賬單和每個團隊的日程上。

為什麼AI代理天生健忘？

OpenAI的Chat Completions API、Anthropic的Messages API和Google的Gemini API共享一個在agent文獻中鮮少被關注的性質：它們都是無狀態的。每次調用獨立，服務器不保存會話、用户身份或之前輪次的記錄。模型“記住”的只是你的應用選擇放入此次請求消息數組中的內容。

這就是所有主要提供商選擇的架構。這並非他們在文檔中致歉的限制。Anthropic Messages API文檔明確指出：API無狀態，客户端負責在每次調用時發送完整對話歷史。OpenAI較新的Responses API提供了服務端會話對象作為便利層，但底層推理調用仍是無狀態的。狀態是應用圍繞模型維護的，而非模型自身維護的。

這一決策背後有充分的工程理由。無狀態推理無需粘性會話即可水平擴展，使負載均衡變得簡單，避免了一類困擾有狀態系統的內存和安全漏洞，並清晰地將模型（一個從輸入到輸出的函數）與應用邏輯（決定組裝什麼輸入）分離。對於提供商而言，無狀態是正確的選擇。

但對於你這位構建agent的人來説，這意味着沒有可啓用的“記憶”功能。只有你每次請求填充的上下文窗口，以及你圍繞它構建的任何腳手架。

以下代碼展示了問題：第一次調用中用户提供了賬號，但第二次調用未傳遞歷史，模型完全沒有回憶。

（代碼示例略）

第二次調用完全不知道第一次調用發生過。對API來説，這是來自同一密鑰的兩個無關請求。如果希望模型“記住”賬號，agent框架必須在下一次將其放回消息數組中。這就是2026年推理層記憶的全部運作方式。

上下文窗口不是記憶

最直接的反應是：“那我們就每次發送所有歷史。”這是大多數生產agent的做法，但直到它行不通之前都有效。在擴展完成之前，它會在三個方面失效。

首先是成本。在長時間會話中，每次輪次重發5萬詞元的對話歷史累積飛快。按Claude Sonnet 4.6每百萬詞元3美元的輸入定價（2026年7月），一次100輪次、平均重發5萬詞元的會話僅輸入成本就達15美元（不計緩存、輸出或工具調用）。提示緩存可削減成本——對話歷史是追加式前綴，緩存運行成本僅為基礎輸入價格的十分之一。但默認緩存僅存活5分鐘，而人類思考時間常超過此限；一小時緩存寫入成本翻倍；且無緩存跨會話、用户或模型交換。緩存只是打折重發，並未移除要求重發的架構。

其次是延遲。更大的上下文意味着更長的首詞元時間。用户以毫秒為單位感受成本。運行數百次內部輪次的agent以每任務美元為單位感受成本。

第三點是大多數團隊低估的：長上下文會降低模型性能。Liu等人的“中間丟失”論文表明，語言模型包括長上下文旗艦模型，從長上下文開頭和結尾檢索信息遠比從中間可靠。埋藏在40輪對話中第12輪的事實，在統計上比同樣的事實貼在系統提示或最新用户消息中對模型答案的影響更小。模型説“不記得”時並非撒謊——它常常真的無法找到眼前的東西。

更大的上下文窗口不是記憶架構，而是記憶權宜之計。區別在於權宜之計有天花板，而我們正在接近它。100萬詞元上下文窗口在Sonnet 4.6上填充成本為每請求3美元（非每會話），在Claude Fable 5上為10美元，處理需要數秒，且仍無法可靠地讓模型從中間提取特定事實。塞入更多並非前進方向。

缺乏記憶導致的四種生產故障

架構問題表現為四種不同的故障模式，任何在真實用户面前運行數週以上的agent都會遇到。

重複解釋。每次會話從零開始。最瞭解產品的用户，使用產品六個月後，每次聊天窗口重置時都必須教會代理他們是誰、在做什麼、喜歡什麼慣例。成本以用户時間、信任和好感度支付。用户挫敗感隨着每次重複增長，而用户是唯一注意到的人。

交接斷點。會話結束，用户離開。agent在該會話中學習、推斷或確立的一切消失。下一會話，同一用户或解決同一問題的隊友，從相同空白狀態開始。使用Cursor或Claude Code的工程團隊每天早上都看到這一點：前一天的建築決策、命名慣例和陷阱必須由人類重新加載到新聊天中。agent表觀智力隨會話重置。

矛盾無解。今天用户告訴agent項目使用Postgres。明天遷移後用户説使用DuckDB。一個持久記憶系統簡單附加兩個事實，最終得到兩條矛盾條目，無機制判斷哪個當前有效。當前基於向量存儲的記憶實現沒有“這條新事實取代舊事實”的原生概念。兩者都被檢索。模型基於語義相似性而非時間有效性選擇。用户發現時，agent的代碼已指向錯誤數據庫。

猜測替代不知。模型不知道某事時，傾向於合理猜測而不是説“我不知道”。這既是模型訓練問題，也是記憶設計問題：大多數agent記憶層無法區分“這是自信檢索”和“我沒有相關記憶”。沒有這個區分，模型沒有理由不捏造。一個能誠實説“我沒有你之前部署配置的記憶，你能提醒我嗎？”的agent，比編造看似合理答案的agent更有用。

每個故障有相同根源和四個不同表面症狀。解決它們需要的不只是更大上下文窗口或更好嵌入模型——它需要架構。

團隊實際的做法及每種方案的不足

已出現幾種緩解模式，但沒有一種解決根本問題，多數僅在狹窄情況下有用。

提示填充。將更多相關上下文塞進系統提示或最新用户消息。便宜、快速，但超過數千詞元后崩潰，受中間丟失影響。

微調。將知識烘焙進權重。對穩定領域知識強大，但對每週變化或用户特定事實無用，且迭代痛苦。

檢索增強生成。推理時從知識庫拉取相關塊。對文檔和參考材料有效，但對逐輪演變的對話狀態較差。

向量數據庫。存儲嵌入後的先前對話片段，按語義相似性檢索。2026年最常見模式，也是最常與記憶混淆的模式。它確實檢索文本，但未提供記憶層所需的時間、結構或置信屬性。向量數據庫本身不夠，將它們視為記憶基元掩蓋了真正的架構差距。

對話摘要。將較早輪次壓縮成運行摘要，存活於上下文中。天生有損。摘要器本身是無狀態模型，決定保留什麼丟棄什麼，對三輪後會重要什麼毫無意識。

自定義記憶封裝。每個團隊構建自己的。形狀大體相似，都在生產中發現團隊未預料的邊界情況，且都不跨應用可移植。

代理記憶庫。不斷增長的開源和商業庫類別，將上述模式捆綁成更易採用的形式。減少工程繁重勞動，但單獨不能解決時間、結構或放棄問題。

平台供應商也在行動：Anthropic的Claude Tag（2026年6月發佈）在Slack內向Claude提供頻道範圍持久記憶。

大多數生產agent使用兩到三種組合。組合足以演示，但六個月後表現轉差，當同樣幾個問題在客户反饋中反覆出現時。

每次對無狀態LLM API的調用，都從應用選擇保留的內容重建上下文。模型本身在請求之間什麼都不記得。

沒人討論的時間問題

即使你完美解決了存儲問題，仍有一個更難的問題：時間有效性。

假設你的記憶系統存儲了事實“用户在Aiven工作”，因為用户18個月前説過。此後用户換過兩次工作。事實仍在存儲中，向量嵌入大致相同，當用户詢問與工作相關的問題時仍被檢索。現在它自信地錯誤。

當前agent記憶系統基於語義相似性檢索，偶爾結合時效加權。兩者都未捕捉記憶實際需要表達的：不僅是學到了什麼，還有何時學到、何時真實、以及之後是否有東西取代它。真實記憶表徵需要兩個時間維度，而非一個：事實進入系統的時間，以及它有效的時間範圍。當前大多數實現兩者都未清晰追蹤。

後果是一類看似幻覺但實際是過時卻自信記憶的錯誤。模型檢索到一條

（原文因成本控制截斷）