# 策展 · X (Twitter) 🔥🔥

> 作者：Siddharth (@Pseudo_Sid26) · 平台：X (Twitter) · 日期：2026-04-29

> 原始來源：https://x.com/Pseudo_Sid26/status/2049175615195242821

## 中文摘要

# AI 實際上是如何記憶的（完整指南）

## 你的 AI Agent 總是會忘記事情並編造細節

## 所以我決定找出原因，以下是我發現的內容。

## 

## 

---

# 簡介

大多數 Agent 的記憶錯誤並非檢索錯誤。記憶在檢索執行之前就已經出錯了。它在第 4,096 個 token 時就已經出錯，當時某些重要的資訊悄悄離開了快取，且沒有任何東西取代它。

但還有一些更早發生的事情，卻鮮少有人討論。每當模型處理 token 時，它都在執行一種注意力機制 (attention mechanism)。

該機制會悄悄地為 context 中的每個 token 評分。有些會獲得高度關注，有些則被忽略。當記憶空間滿了且必須移除某些東西時，那些低分項目就會消失。

就是這樣。這就是決策過程。沒有外部系統，沒有 RAG pipeline，只有模型自己在決定它要繼續關注什麼。

這就是 token 層級的記憶。它塑造了後續發生的一切。

> 我在閱讀 KV cache 壓縮論文時，不斷注意到數學公式背後都有同樣的現象。真正的問題不在於速度，而在於模型實際上被允許記住什麼。這感覺像是一個 Agent 設計問題，而不是基礎設施問題。

---

## 那麼，KV cache 到底是什麼？

當 Transformer 處理一個句子時，它會為每個 token 計算一個 Key 向量和一個 Value 向量。這些向量會被快取 (cached)。在下一個生成步驟中，新的 token 會對所有儲存的 (K, V) 對進行注意力計算，以決定輸出什麼。快取就是讓這個過程在每一步都不會變得昂貴到離譜的關鍵。

問題既簡單又殘酷：

- 每個新 token 都會永久增加一對 (K, V) 到快取中。
- 快取大小隨 context 長度線性增長。
- 在大型模型上達到 128k token 時，你面對的是每個層、每個頭 (head) 佔用數 GB 的記憶體。
- 硬體不在乎你的使用情境，它只會耗盡記憶體。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430393043-iaHHAT0vpaIAAUvfmpng.png)

對於 Agent 來說，這是一個每天都會遇到的真實問題。每一次工具呼叫 (tool call) 的輸出、每一份檢索到的文件、每一輪推理、對話中的每一個過去回合，它們都在消耗這個預算。當它滿了，某些東西就會被刪除。

> 問題在於，到底刪什麼？？？

把它想像成你的手機儲存空間：

1. 你正在旅行，不斷地拍照。
2. 到某個時刻，手機顯示儲存空間已滿。
3. 現在你有兩個選擇：停止拍照，或者刪除某些東西。
4. 大多數原始的系統只是停止運作。
5. 聰明的系統會問你，哪些東西是你真正還需要的。

```python
# 原始的 KV cache 長什麼樣子，沒有移除機制，只有增長
kv_cache = []

def cache_token(key, value):
    kv_cache.append((key, value))
    # 沒有評分，沒有移除，沒有預算檢查
    # 128k 個 token 後，這個列表會變得非常龐大

# 推論時的記憶體使用量
print(f"cache size: {len(kv_cache)} pairs")
print(f"approx memory: {len(kv_cache) * 2 * 4096 * 2 / 1e9:.2f} GB")
# 在 70B 模型上處理 128k token 時：約 64 GB。僅僅是為了快取。
```

---

## 初次嘗試：只保留最近的內容

最直接的方法是 StreamingLLM。保留前幾個 token（稱為注意力匯點，對模型穩定性很重要），保留一個最近 token 的滑動視窗，並丟棄中間的所有內容。固定的預算，簡單的規則。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430393228-iaHHAUleabAAEHq6Ujpg.jpg)

這確實有效。模型可以無限期運作而不會崩潰。但這也意味著任何發生在幾千個 token 之前的內容都會直接消失。如果你的任務指令在 context 的很前面，而一次工具呼叫的回應將其擠出了視窗，模型就會忘記它自己的目標。

> 「最近 = 重要」這個假設在 Agent pipeline 中造成了許多隱性的損害。一條 4 萬個 token 前的指令，可能是整個 context 中最關鍵的資訊。

> 最近性和重要性確實是兩回事。

---

## SnapKV：模型已經知道什麼是重要的

這是一個真正改變我對此問題看法的方法。

這個觀察結果非常有趣。Transformer 中的每個注意力頭在整個生成過程中，始終會關注相同的特定 token。

> 它不是隨機的！！！

- 第 7 層的第 4 個頭可能總是關注任務指令 token。
- 第 3 層的第 2 個頭可能總是關注實體名稱。
- 這種模式從第一個輸出 token 到最後一個都是穩定的。

SnapKV 提出：如果模式是穩定的，為什麼不利用它來決定保留什麼？

> 他們定義了一個觀察視窗 (observation window)，即 prompt 的最後一段。

> 觀察在這個視窗內哪些 token 獲得了高注意力分數。

> context 中較早出現且在此處得分高的 token 就是關鍵角色。保留這些，壓縮其餘的。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430393404-iaHHAVaZ3bwAAO3RRpng.png)

此外還有一個分群 (clustering) 步驟。當你單純挑選高分 token 時，你會得到孤立的片段，而缺乏周圍的 context。重要短語旁邊的詞通常也很重要。SnapKV 使用最大池化分群 (max-pool clustering) 將每個關鍵角色周圍的鄰居也納入。因此，你保留了重要的 token，以及足以理解它們的足夠 context。

> 結果：

- 在 1024 個快取槽位下，壓縮率達到 92%。
- 生成速度提升 3.6 倍。
- 在 16k token 下，記憶體效率提升 8.2 倍。
- 它可以在單個 A100 上運行 380k token 的 context。
- 「大海撈針」(Needle-in-a-Haystack) 的準確度幾乎沒有下降。

```python
# 簡化的 SnapKV 逐頭選擇
def snapkv_select(keys, values, obs_window_size=16, budget=1024):
    obs_queries = keys[-obs_window_size:]  # 觀察視窗

    attn_scores = obs_queries @ keys[:-obs_window_size].T  # (obs, seq_len)
    token_votes  = attn_scores.sum(dim=0)                  # 聚合投票

    # 挑選前 k 個關鍵角色
    topk_idx = token_votes.topk(budget).indices

    # 分群
    cluster_idx = expand_with_neighbors(topk_idx, kernel_size=5)

    kept_keys   = keys[cluster_idx]
    kept_values = values[cluster_idx]

    # 新的快取 = 選擇的前綴 + 完整的觀察視窗
    return concat(kept_keys,   keys[-obs_window_size:]), \
           concat(kept_values, values[-obs_window_size:])
```

最後這個測試對於 Agent 來說至關重要。它基本上是在問：如果我將一個特定的事實埋在非常長的 context 深處，你還能找到它嗎？

SnapKV 的回答是肯定的，即使在壓縮了 92% 的快取之後。這不僅僅是更快的推論，這是在受限條件下更好的工作記憶。

---

## 「Cache What Lasts」發現了什麼

SnapKV 解決了「如何壓縮」的問題。Token retention 論文更進一步，探討了為什麼某些 token 總是重要的。

研究發現，某些 token 在所有層、所有頭以及整個生成過程中，始終收集著高注意力權重。不僅僅是在某個頭或某一層，而是全域且一致地。這些才是真正的關鍵角色。

讓我印象深刻的部分是：模型內部已經在計算這個分數了。每一次注意力運算都在隱式地對 token 進行排名。Token retention 論文只是將這種排名顯式化，並實際將其用於移除決策。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430392993-iaHHAWRWKbwAQfSJ8png.png)

> 對此的直覺：

想像一下你上次閱讀一篇非常長的文件，然後有人問你相關問題。你不會記得每一句話。你記得標題、關鍵名稱、那個令人驚訝的特定統計數據。你的大腦對該文件執行了自己的保留策略，並保留了高訊號的部分。這就是模型正在做的事情，只是它是在快取中，而不是在大腦中。

- 最近性不等於重要性 —— 6 萬個位置前的 token 可能比 10 個位置前的 token 得分高得多。
- 重要性是可衡量的 —— 累積注意力權重是穩定且可靠的。
- 移除應該使用分數 —— 而不是位置、年齡或隨機抽樣。
- 預算固定 —— 但填入預算的內容應該是經過智慧選擇的。

```python
def compute_token_importance(attention_weights):
    # attention_weights 形狀: (layers, heads, seq_len, seq_len)
    
    # 在所有層、所有頭、所有查詢位置上求和
    cumulative = attention_weights.sum(dim=(0, 1, 2))  # 形狀: (seq_len,)
    
    return cumulative

scores = compute_token_importance(attn_weights)
keep   = scores.topk(budget).indices
evict  = scores.topk(seq_len - budget, largest=False).indices
```

---

## Memory Sparse Attention：另一個角度

上述論文探討的是快取中要保留什麼。MSA 則探討在計算每個新 token 時應該關注什麼。

- 全注意力 (Full attention) 是 O(n²)。在 1 億個 token 時，這是不可能的。
- MSA 將 top-k token 選擇與稀疏注意力模式相結合。
- 在不失去 End to End (端到端) 可訓練性的情況下，實現了接近線性的複雜度。

與 Agent 相關的部分是 Memory Interleave。Agent 不會處理一份巨大的文件。它們處理的是跨會話的資訊流：工具輸出、檢索到的文件、上週的使用者訊息。

MSA 處理跨非連續 context 片段的多跳推理 (multi-hop reasoning)。這是一個在注意力層解決的 Agent 記憶問題，無需任何外部檢索 pipeline。

- Top-k 選擇 —— 每個生成步驟只關注最相關的 token。
- 文件級位置編碼 —— 適用於非連續的記憶片段。
- 在 2 個 GPU 上實現 1 億 token 的吞吐量 —— 這是真實的系統效能聲明。
- 在長 context 基準測試中擊敗 RAG 系統 —— 來自模型內部的檢索。

## 方法比較

目前在這個領域大約有十幾篇重要的論文。它們都分享相同的直覺，但在如何對 token 評分以及如何設定預算上有所不同。

我最近也在一個 notebook 中比較了所有這些方法。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430393075-iaHHAXLAdbEAAh8YTpng.png)

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430393339-diaHHAXRQ1bwAA5ZNpng.png)

MOLA NOTEBOOK

---

## 與 Agent 記憶的連結

這對構建 Agent 的人來說才是真正重要的。

大多數關於 Agent 記憶的討論都從檢索層開始。向量資料庫、情節記憶、摘要策略。所有這些都是真實且重要的。但它們接收的輸入，都來自一個必須先決定要關注什麼的模型。該決策發生得更早，在 token 層級，並且影響下游的一切。

如果一個關鍵 token 在影響生成之前就從 KV cache 中被移除，它就消失了。沒有 RAG pipeline 會檢索到它。沒有記憶管理器會處理它。模型根本沒有正確處理它，輸出結果也反映了這一點。如果該錯誤的輸出被寫入外部記憶體，你現在就有了從注意力層開始的「錯誤記憶傳播」(False Memory Propagation)，甚至在任何外部系統介入之前就發生了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777430393082-iaHHAXtMhbwAAxC21png.png)

> 對此的直覺：

想像你正在為一個 SaaS 產品構建一個客戶支援 Agent。

- 使用者進行了 2 小時的故障排除會話。
- 他們在開始時解釋了他們的整個設定。
- 然後你經歷了 15 次工具呼叫、日誌、配置。
- 當你深入到第 15 個問題時，最初的設定 context 可能已經從快取中被移除了。
- 現在模型開始提出忽略使用者在開始時提到的特定限制的建議。
- 這不是因為檢索錯誤，而是因為正確的 token 在檢索變得相關之前就已經消失了。

## 這導致的真實問題

這不是理論上的，這些是在生產環境中發生的事情：

- **迷失在中間 (Lost in the middle)**：模型在長 context 的中間可靠地遺忘資訊，因為大多數移除策略偏好非常新和非常早期的 token。
- **工具輸出稀釋 (Tool output dilution)**：大量的工具回應將早期的任務指令擠出了有效視窗。
- **RAG 注入浪費**：你檢索了 20 個區塊，但稀疏注意力只對其中幾個進行了有意義的處理，其餘的都浪費了 context 預算。
- **系統提示詞失憶 (System prompt amnesia)**：系統提示詞中的關鍵限制在生成過程中被移除，模型編造了一個替代方案。
- **從注意力開始的 FMP**：一個幻覺產生的中間 token 在注意力上獲得了高分，因為模型正在主動使用它，它在移除過程中存活下來，並毒害了生成鏈。
- **跨會話冷啟動**：沒有跨會話的 KV 狀態持久化，意味著每個會話都是全新的，工作記憶必須從檢索中重建，而這總是一種有損的重構。

---

# 結論

最終的狀態是一個能夠動態且智慧地管理自身記憶預算的 Transformer，而無需在外部進行任何工程設計。這不僅僅是一個更好的推論系統，這是為在其之上運行的每個 Agent 提供的更好的記憶基底。

- **逐頭保留 (Per head retention)**：不同的頭關注不同的 token，移除應該尊重這一點。
- **階段感知壓縮 (Phase aware compression)**：預填充 (prefill) 和解碼 (decoding) 具有不同的記憶體配置，應分開處理。
- **可恢復性 (Recoverability)**：移除不一定是永久的。
- **KV 狀態持久化**：在會話結束時儲存快取狀態，下一個會話重新載入，實現無需向量資料庫的跨情節連續性。

能妥善處理長視角任務的 Agent，不會是那些擁有最花俏檢索 pipeline 的 Agent。它們將是那些模型本身在長 context 中保留了正確內容，且外部記憶層接收到足夠乾淨的輸入以進行實際運作的 Agent。

因此，Token 層級的記憶是基礎，而不是上限。每個檢索 pipeline 和記憶管理器接收的輸入，都來自一個先決定了要關注什麼的模型。該決策發生在 KV cache 中。這對 Agent 設計很重要，而不僅僅是推論速度。

---

## 免責聲明

本文由作者研究並撰寫，由 Sonnet 4.6 編輯。縮圖取自 Pinterest。

參考文獻 -

[1] SnapKV · arxiv.org/abs/2404.14469

[2] Cache What Lasts · arxiv.org/abs/2512.03324

[3] MSA · arxiv.org/abs/2603.23516

[4] D2O · arxiv.org/abs/2406.13035

[5] H2O · arxiv.org/abs/2306.14048

[6] Scissorhands · arxiv.org/abs/2305.17118

[7] StreamingLLM · arxiv.org/abs/2309.17453

[8] PyramidKV · arxiv.org/abs/2406.02069

[9] CAKE · arxiv.org/abs/2501.10107

[10] SCOPE · arxiv.org/abs/2501.13981

## 標籤

Agent, 記憶系統, 教學資源, AI