# 策展 · X (Twitter) 🔥🔥

> 作者：mem0 (@mem0ai) · 平台：X (Twitter) · 日期：2026-05-13

> 原始來源：https://x.com/mem0ai/status/2054227809829364200

## 中文摘要

# Agent 的記憶對時間是盲目的，我們建立了一個時間推理層來在生產環境中修復它

我們在 Mem0 中引入了「時間推理」（Temporal Reasoning），這是一個新的記憶層，能幫助 AI Agent 不僅理解它們記住了什麼，還能理解這些記憶在何時是正確的。

長期運行的 Agent 失效的原因不僅僅是因為遺忘，而是因為它們在同一個時態下記住了太多東西。使用者的舊居住地、之前的工作、過去的計畫以及目前的偏好，通通被存放在記憶中，彷彿它們在今天都同樣有效。傳統的檢索方式可以找到正確的主題，但無法判斷該記憶是否仍然適用。

「時間推理」透過為每條記憶加上時間戳記來解決這個問題，它能管理如地點或工作經歷等不斷演變的狀態，並根據記憶是「當前」、「歷史」還是「未來」來重新排序對時間敏感的查詢。因此，當使用者詢問「我現在住在哪裡？」或「我這週在忙什麼？」時，Agent 檢索到的是正確的時間實例，而不僅僅是語意上最接近的匹配。

在我們的評估中，這一點在長期記憶基準測試中表現得最為明顯。在 LoCoMo 測試中，時間推理將整體準確率從 86.1% 提升至 90.2%，在時間相關和多跳（multi-hop）問題上的提升最為顯著。在 LongMemEval 測試中，它在 top_50 的整體準確率從 90.4% 提升至 94.8%，在多會話（multi-session）問題上提升幅度最大，因為 Agent 需要追蹤事實如何在多次對話中演變。

## 有什麼改變

1. 每條記憶都有一個時間戳記。
當寫入一條記憶時，一個獨立的時間推理過程會同時讀取記憶文字、原始對話以及發生日期。它會提取事件發生的時間、它是仍在進行中還是已完成、時間的精確度，以及記憶的類型（例如：計畫、狀態、事件、關係、偏好或缺失）。

2. 記憶被理解為時間事實，而不僅僅是文字。
系統會儲存並區分過去事件、進行中狀態、未來計畫、關係、偏好和缺失。這種時間結構與記憶本身共存，因此搜尋功能可以將「住在奧斯汀」、「下週二有牙醫預約」和「去年夏天去了日本」視為本質上不同類型的資訊。

3. 對時間敏感的查詢具備時間感知排序。
像「她現在住哪裡？」、「她這週有什麼計畫？」或「她做那份工作多久了？」這類查詢，會根據其時間意圖進行分類，且無需額外的 LLM 呼叫。隨後，時間意圖會被用於重新排序檢索結果，確保浮現的是正確的時間實例，而不僅僅是語意上最相似的結果。

時間推理是完全附加的：它疊加在現有的 Mem0 演算法管線上，而不會取代基礎的檢索系統。

## 重點摘要

- 7 種記憶類型：從一次性事件到穩定的永恆事實，每條記憶在寫入時都會被分類

- 7 種時間查詢模式：在查詢時進行分類，讀取路徑上無需額外的 LLM 呼叫

- 時間評分是附加的：它會將排序推向正確的時間實例；語意相關性始終佔主導地位

- LoCoMo：在 top_50 提升了 9.1 個百分點，這是時間重新排序發揮最大作用的地方；在各類別中整體提升 4.1 個百分點；在 1,540 個時間相關問題中提升 6.7 個百分點。

- LongMemEval：在 top_50 從 90.4% 提升至 94.8%，整體提升 4.4 個百分點；在多會話問題上提升 11.2 個百分點：在 top_50 從 82.0% 提升至 93.2%

- 平均搜尋延遲保持不變：讀取路徑上僅增加 +1 ms 的開銷

- 非同步豐富化：對延遲敏感的寫入會立即完成；時間元資料會在背景中於幾秒內進行修補

- 零資料刪除：時間元資料是附加的，因此歷史背景仍然可存取

## 試用看看

API 沒有變更。你可以像往常一樣新增記憶：

Python

```python
client.add(
    "I just accepted a job offer at Stripe. Starting in two weeks.",
    user_id="alice"
)

# Later in another conversation
client.add(
    "I left Stripe after a year. Started my own company now.",
    user_id="alice"
)

# Search returns the right answer: current state, not historical noise
client.search("where does Alice work?", user_id="alice")
# → "Alice runs her own company" (Stripe memory is now a closed state, dated)
```

Node.js

```javascript
await client.add(
  "Planning a trip to Tokyo for the spring conference.",
  { user_id: "bob" }
);

// After the trip
await client.add(
  "Just got back from Tokyo. The conference was amazing.",
  { user_id: "bob" }
);

await client.search("has Bob been to Tokyo?", { user_id: "bob" });
// → "Bob attended a conference in Tokyo" (as a past event, correctly dated)

```

時間推理功能預設為所有 Mem0 專案啟用。如果你在特定呼叫中需要標準檢索，請在該呼叫中傳入 `temporal_reasoning=False` 即可跳過。

## 儲存了什麼

每條記憶現在都可以攜帶四種時間結構：

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

且每條記憶都屬於七種類型之一：

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

進行中的事實（狀態、關係、偏好）帶有一個狀態鍵（state key）：這是一個穩定的識別碼，將同一個人關於同一個演變事實的所有記憶連結起來。當新的狀態取代舊狀態時，舊狀態的 `event_end` 會自動設定。時間軸保持整潔，不會刪除任何內容。

## 運作原理

寫入：分離提取與時間豐富化

記憶提取與時間豐富化是有意分開處理的。提取模型執行它一貫的工作：讀取對話並以自然語言寫入記憶。隨後，時間推理過程會對這些記憶進行處理，並為每一條記憶返回結構化的時間元資料，涵蓋發生時間、記憶類型、是否仍處於活動狀態以及相關的時間欄位。

保持這些步驟分離意味著每一部分都可以獨立改進。更好的提取模型不會影響時間豐富化，反之亦然。

對於延遲敏感的應用程式，時間豐富化可以非同步執行。記憶會立即寫入，因此 `add` 呼叫會快速返回，背景工作執行緒隨後會補上時間元資料。在豐富化完成之前，搜尋功能會優雅地回退到這些記憶的基礎行為。

讀取：意圖分類、檢索與時間重新排序

查詢會根據其時間意圖進行分類，無需額外的 LLM 呼叫。系統能識別以下模式：

- `historical_range`：「三月發生了什麼事？」

- `current_state`：「她現在住哪裡？」

- `duration_state`：「她做那份工作多久了？」

- `upcoming`：「她這週有什麼計畫？」

- `soft_recency`：「她最近在忙什麼？」

關鍵在於，這種分類不會過濾檢索結果。對於每個查詢，檢索過程都是一樣的；時間意圖不會決定哪些記憶進入候選池。它僅用於重新排序步驟，每個檢索到的候選記憶都會根據其儲存的時間元資料與查詢意圖的匹配程度進行評分。

這是刻意設計的。按時間預先過濾會導致遺漏日期不精確或缺失的記憶。相反，時間評分是附加的，這是一種疊加在語意相關性之上的軟性訊號。語意契合度強但時間對齊度弱的記憶，其排名仍會高於時間對齊完美但語意契合度弱的記憶。時間層會微調排名，但不會覆蓋它。

時間評分發生在檢索之後，作為一種附加的排序訊號，因此最佳的時間匹配可以超越那些僅在語意上相似的記憶。

# 結果

我們測試了基礎演算法（mem0.ai/research）在沒有時間推理的情況下，以及在 LoCoMo 和 LongMemEval 基準測試中啟用時間推理後的效能。

## LoCoMo

LoCoMo 包含 1,540 個問題，涵蓋時間、多跳、開放領域和單跳類別。這些問題能區分出具備時間概念的系統與不具備時間概念的系統。

我們以兩種視角呈現結果：按檢索截止深度（retrieval cutoff）和按問題類別。

由於這些視角對基準測試的聚合方式不同，它們的整體數字預計不會完全吻合。截止深度表顯示了不同檢索深度的效能，而類別表則顯示了按問題類型的效能。

按檢索截止深度的效能

我們測試了基礎演算法（mem0.ai/research）在沒有時間推理的情況下，以及在啟用時間推理後，按檢索截止深度的效能：所有類別。

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

LoCoMo 最強的增益出現在 top_50，準確率從 82.7% 提升至 91.8%。隨著候選池中候選項目增加，時間重新排序有更多空間從近乎相同的替代選項中區分出正確的時間實例，這正是 LoCoMo 基準測試旨在強調的問題類型。

按問題類別的效能

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

關於閱讀表格的說明：
下方的 LoCoMo 結果顯示了同一基準測試的兩種不同視角。類別細分報告了按問題類型的效能，其整體分數是根據每個類別中的問題數量加權計算的。截止深度表報告了按檢索深度（top_10、top_20、top_50 和 top_200）的效能。由於這些視角對基準測試的聚合方式不同，它們的整體數字預計不會完全吻合。

僅時間推理類別

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

總體而言，我們在 1,540 個問題中看到了 4.1 個百分點的提升。最大的勝利出現在最重要的地方：時間和多跳問題，系統必須判斷哪個實例適用以及現在什麼才是正確的。

開放領域類別的下滑（96 個問題，-1.9 個百分點）是真實存在的，我們正在積極調整。這只是基準測試的一小部分，且這些問題不太可能從時間重新排序中受益。我們在此明確提出，是為了讓它可見，而不是掩蓋它。

## LongMemEval

時間推理也提升了 LongMemEval 在我們最新基準上的效能，在 500 個問題中，top_50 達到 94.8%，top_200 達到 94.4%。

最大的 top_50 增益來自多會話問題，準確率從 82.0% 提升至 93.2%。在 top_200 時，最強的提升出現在時間推理類別，從 93.2% 提升至 97.0%。

LongMemEval 特別有用，因為它強調了生產環境記憶系統中出現的情況：舊事實與新事實競爭、使用者偏好隨時間演變，以及需要結合多次會話證據的問題。

按問題類別和檢索截止深度的效能

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

LongMemEval 最強的提升在 top_50，時間推理將整體準確率從 90.4% 提升至 94.8%。多會話問題類別增益最大，從 82.0% 提升至 93.2%，因為時間結構幫助系統追蹤多次對話中何時發生了什麼事。

在 top_200 時，時間推理整體達到 94.4%，領先 V3 基準的 93.4%。時間推理類別從 93.2% 提升至 97.0%，顯示隨著候選集擴大且包含更多近乎重複或時間偏移的事實，帶有日期的記憶元資料變得更有價值。

知識更新仍然是附加記憶架構中最難的類別。最新的演算法版本刻意保留歷史記憶，而不是刪除或替換它們，因此較舊的語意相似事實仍可能出現在較新的事實附近。時間推理賦予系統更強的時間感知能力，而我們最近推出的記憶衰減功能，透過降低較舊、較不即時的記憶隨時間的影響，進一步解決了過時記憶的壓力。這是從靜態記憶狀態轉向記憶演變的更廣泛轉變的一部分：在保留歷史的同時，讓當前的真相更容易檢索。

## 搜尋延遲

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

平均延遲基本上沒有變化，僅增加 +1 ms。尾端延遲（p95）增加較明顯（約 198 ms），這在部署時值得監控。

## 應用

- 個人助理與 Copilot。「使用者晚餐偏好什麼？」應該返回當前的偏好，而不是兩年對話中提到過的每一頓飯的累積。最近陳述的偏好排名高於歷史偏好。被取代的偏好（使用者從素食轉為魚素）不會作為衝突的事實浮現。

- 程式開發 Agent 與開發工具。「使用者在忙什麼？」指的是本衝刺（sprint）的內容，而不是六個月前悄悄終止的副專案。計畫類型的記憶會自然地從當前狀態查詢中老化，無需手動修剪。

- CRM 與銷售智慧。「客戶目前的合約等級是什麼？」可以精確回答。訂閱等級由狀態鍵連結。客戶升級會關閉舊等級並開啟新等級。沒有歧義，也不會根據過時的背景產生幻覺答案。

- 醫療保健與照護協調。「病患目前正在服用什麼藥物？」是一個時間精確度至關重要的問題。停用的藥物帶有 `event_end`。活躍的藥物則沒有。活躍狀態優先浮現，已關閉的狀態則作為歷史背景存在。

- 長期運行的 Agent。任何在數週或數月內累積記憶的系統都會遇到同樣的瓶頸：最舊的記憶感覺與最新的記憶一樣即時。時間推理賦予這些 Agent 內建的時效感，無需手動修剪。

## 總結

時間推理改變了記憶在整個管線中的行為方式：記憶如何被寫入、分類和排序。在寫入時分類一次，讓讀取保持免費。以附加方式評分，確保語意相關性在必要時依然勝出。永遠不要刪除，因為時間背景是元資料，而不是替代品。

結果在兩個基準測試中都有體現：LoCoMo 的時間相關問題提升 6.7 個百分點，LongMemEval 的整體準確率在 top_50 從 90.4% 提升至 94.8%（多會話問題提升幅度最大）。平均延遲在讀取路徑上基本上保持不變，僅增加 +1 ms。寫入保持快速。讀取保持高效。歷史保持完整。

這就是我們在發布前想要達到的標準，也是未來發展的基礎：跨越衝突的時間軸進行推理、檢測過時事實，以及追蹤信念如何隨時間演變。

## 下一步

時間推理是基礎。隨著每條記憶都帶有時間戳記，下一層是時間問答：直接回答如「使用者擁有當前訂閱多久了？」這類問題，這些答案是根據儲存的時間元資料計算出來的，而不是從語意相似度推斷出來的。

接下來是時間衝突解決：當關於同一狀態的兩條記憶具有重疊或矛盾的時間視窗時，系統將標記該衝突，而不是默默地選擇其中一個。

兩者皆向後相容。今天寫入的記憶將在無需任何遷移的情況下與這些改進相容。請在文件中閱讀更多內容。

---

Mem0 是一個智慧型、開源的記憶層，專為 LLM 和 AI Agent 設計，旨在跨會話提供長期、個人化且具備上下文感知的互動。

- 在此取得你的免費 API Key：app.mem0.ai

- 或從我們的開源 GitHub 儲存庫自行託管 Mem0

## 標籤

Agent, 記憶系統, 功能更新, 開源專案, Mem0