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

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

（原文因成本控制截斷）