Home
Blog
現在像 Claude Cowork 這種長期經營的代理商正在崛起，RAG 是否已經過時？

現在像 Claude Cowork 這種長期經營的代理商正在崛起，RAG 是否已經過時？

Engineering

January 27, 2026

Min Yin

Claude Cowork是 Claude Desktop 應用程式的新代理功能。從開發人員的觀點來看，它基本上是包覆在模型上的自動化任務執行器：它可以讀取、修改和產生本機檔案，並且可以規劃多步驟任務，而不需要您手動提示每一步驟。把它想像成 Claude Code 背後的相同循環，不過是暴露在桌面上，而不是終端機。

Cowork 的關鍵能力在於它能長時間執行而不會失去狀態。它不會遇到一般的對話超時或上下文重設。它可以持續工作、追蹤中間結果，並在不同的會話中重複使用先前的資訊。這給人一種「長期記憶」的感覺，儘管其基本機制更像是持久的任務狀態 + 上下文攜帶。無論如何，這種體驗都有別於傳統的聊天模式，除非您建立自己的記憶層，否則一切都會重設。

這帶給開發人員兩個實際的問題：

如果模型已經可以記住過去的資訊，那麼 RAG 或代理的 RAG 還能在哪裡適應？RAG 會被取代嗎？
如果我們想要一個本地的、Cowork 式的代理，我們該如何自己實作長期記憶？

本文其餘部分將詳細討論這些問題，並解釋向量資料庫如何融入這個新的「模型記憶」格局。

Claude Cowork vs. RAG：區別在哪裡？

正如我之前提到的，Claude Cowork 是 Claude Desktop 內的一個代理模式，它可以讀寫本機檔案、將任務分割成較小的步驟，並且在不遺失狀態的情況下持續工作。它能維持自己的工作情境，因此多個小時的任務不會像一般聊天會話一樣重設。

RAG(Retrieval-Augmented Generation) 解決了一個不同的問題：讓模型存取外部知識。您將您的資料索引到向量資料庫中，為每個查詢擷取相關的區塊，並將它們饋送至模型中。它之所以被廣泛使用，是因為它為 LLM 應用程式提供了一種「長期記憶」的形式，可以記錄文件、日誌、產品資料等。

如果這兩個系統都能幫助模型「記得」，那麼實際上有什麼不同呢？

Cowork 如何處理記憶體

Cowork 的記憶體是讀寫式的。代理會決定當前任務或對話中哪些資訊是相關的，並將其儲存為記憶項目，之後再隨著任務的進展擷取這些資訊。這讓 Cowork 可以在長時間運作的工作流程中維持連續性，尤其是那些會隨著進度產生新的中間狀態的工作流程。

RAG 和 Agentic RAG 如何處理記憶體

標準的 RAG 是查詢驅動式的檢索：使用者提出問題，系統取得相關的文件，然後模型使用這些文件來回答。擷取的語料保持穩定和版本化，而且開發人員可以準確控制進入語料庫的內容。

現代的代理 RAG 延伸了這個模式。模型可以決定何時擷取資訊、擷取什麼資訊，以及在規劃或執行工作流程時如何使用這些資訊。這些系統可以執行長時間的任務並呼叫工具，類似於 Cowork。但即使是代理式 RAG，檢索層仍是以知識為導向，而非以狀態為導向。代理程式擷取的是權威性的事實；它並沒有將演進中的任務狀態寫回語料庫中。

從另一個角度來看：

Cowork 的記憶體是由任務驅動的：代理程式會寫入並讀取其演進中的狀態。
RAG 則是知識驅動：系統檢索模型應該依賴的既定資訊。

逆向工程 Claude Cowork：它如何建立長時間運作的代理程式記憶體

Cowork 被炒得沸沸揚揚，因為它能處理多步驟的任務，而且不會經常忘記當初在做什麼。從開發者的角度來看，我很好奇它是如何在如此長的階段中保持狀態的？Anthropic 並未公佈其內部結構，但根據 Claude 記憶模組的早期開發實驗，我們可以拼湊出一個像樣的心智模型。

Claude 似乎依賴一種混合設定：一個持續的長期記憶層加上按需檢索工具。Claude 並沒有將完整的對話內容塞入每個請求中，而是只在它認為相關時，才選擇性地拉入過去的情境。這可讓模型保持高準確度，而不致於每次都要花費大量代幣。

如果您將請求結構拆解開來，它大致上是這樣的：

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

有趣的行為並不是結構本身，而是模型如何決定更新內容以及何時執行擷取。

使用者記憶體：持久層

Claude 保留了一個長期記憶庫，並隨時間更新。與 ChatGPT 更可預測的記憶體系統不同，Claude 的記憶體系統感覺更有「生命力」。Claude 將記憶儲存在類似 XML 的區塊中，並透過兩種方式進行更新：

隱含更新：有時候，模型只是判斷某些東西是穩定的偏好或事實，然後靜靜地寫入記憶體。這些更新不是即時的，它們會在幾個回合之後顯示出來，而且如果相關的對話消失了，較舊的記憶體也會逐漸消失。
明確更新：使用者可以使用memory_user_edits 工具直接修改記憶 (「記得 X」、「忘記 Y」)。這些寫入是立即的，行為上更像是 CRUD 操作。

Claude 正在運行背景啟發式方法來決定什麼值得持久化，而不是等待明確的指示。

會話檢索：隨選部分

Claude不會像許多 LLM 系統一樣保留滾動摘要。相反地，它有一個擷取函數的工具箱，只要它認為缺少上下文，就可以呼叫這個工具箱。這些檢索呼叫並非每次都會發生 - 模型會根據自己的內部判斷來觸發它們。

最突出的是conversation_search 。當使用者說「上個月的那個專案」這樣含糊不清的話，Claude 通常會啟動這個工具來挖掘相關的內容。值得注意的是，當語句模棱兩可或使用不同的語言時，它仍能運作。這很明顯地暗示了

某種語意匹配 (嵌入)
可能結合規範化或輕量級翻譯
為了精確度而分層的關鍵字搜尋

基本上，這看起來很像是在模型的工具集中捆綁了一個微型的 RAG 系統。

Claude 的檢索行為如何與基本歷史緩衝區不同

從測試和日誌中，有幾個模式很突出：

擷取不是自動的。模型選擇何時呼叫它。如果它認為已經有足夠的上下文，它甚至不會去煩惱。
擷取的區塊包括 使用者與助理的訊息。這是很有用的 - 它比只有使用者的摘要能保留更多的細節。
令牌使用保持正常。由於歷史記錄不是每次都會注入，因此長時間的會話不會出現不可預測的氣球。

總體來說，它感覺像是一個檢索增強的 LLM，只是檢索是模型本身推理循環的一部分。

這個架構很聰明，但不是免費的：

檢索增加了延遲和更多的「移動零件」（索引、排序、重新排序）。
模型偶爾會錯誤判斷它是否需要上下文，這表示您會看到典型的「LLM 遺忘症」，即使資料是可用的。
調試變得更棘手，因為模型行為取決於隱形的工具觸發，而不只是提示輸入。

Claude Cowork 與 Claude Codex 在處理長期記憶方面的對比

相較於 Claude 重檢索的設定，ChatGPT 處理記憶體的方式更有條理、更可預測。ChatGPT 不會進行語意查詢，也不會把舊會話當成迷你向量倉，而是透過下列分層元件，直接將記憶注入每個會話：

使用者記憶體
會話元資料
當前會話訊息

使用者記憶體

使用者記憶體是主要的長期儲存層--跨會話持續存在並可由使用者編輯的部分。它儲存了相當標準的東西：名稱、背景、正在進行的專案、學習偏好等等。每個新的對話都會在一開始就注入這個區塊，因此模型總是以一致的使用者觀點開始。

ChatGPT 以兩種方式更新這一層：

明確更新：使用者可以告訴模型「記住這個」或「忘記那個」，記憶體就會立即改變。這基本上是模型透過自然語言揭露的 CRUD API。
隱含更新：如果模型發現符合 OpenAI 長期記憶規則的資訊，例如工作職稱或偏好，而使用者並未停用記憶功能，它就會自行悄悄地新增這些資訊。

從開發人員的角度來看，這一層是簡單、確定且容易推理的。不需要嵌入查詢，也不需要啟發式的擷取方式。

會話元資料

Session Metadata 處於光譜的另一端。它是短暫的、非持久性的，而且只會在會話開始時注入一次。將其視為會話的環境變數。這包括以下項目

您所在的裝置
帳戶/訂閱狀態
粗略的使用模式（活動天數、模型分佈、平均對話長度）

此元資料可協助模型針對目前環境塑造回應，例如，在行動裝置上撰寫較短的答案，而不會污染長期記憶。

目前會話訊息

這是標準的滑動視窗歷史：目前會話中的所有訊息，直到達到代幣限制為止。當視窗變得太大時，較舊的內容會自動刪除。

最重要的是，這種驅逐不會觸及使用者記憶體或跨會話摘要。只有本機會話歷史會縮小。

ChatGPT 與 Claude 最大的差異在於如何處理「最近但非目前」的會談。如果 Claude 認為過去的內容是相關的，它會呼叫搜尋工具來擷取。ChatGPT 不會這麼做。

相反地，ChatGPT 會保留一個非常輕量級的跨會話摘要，並注入到每次對話中。關於這一層的幾個關鍵細節：

它只會總結使用者訊息，不會總結助理訊息。
它儲存的項目非常少，大約只有 15 個，足以捕捉穩定的主題或興趣。
它不進行嵌入計算、類似度排序，也不呼叫檢索。它基本上是預先咀嚼的上下文，而不是動態查詢。

從工程的角度來看，這種方法以靈活性換取可預測性。這樣就不會發生奇怪的擷取失敗，推論的延遲也會保持穩定，因為沒有任何東西是在飛行中擷取的。缺點是，除非 ChatGPT 將六個月前的訊息寫入摘要層，否則它不會隨機讀取這些訊息。

讓代理程式記憶體可寫的挑戰

當代理程式從唯讀記憶體（典型的 RAG）轉移到可寫記憶體時（可記錄使用者的動作、決定和偏好），複雜度就會快速增加。您不再只是檢索文件；您還要維護模型所依賴的成長狀態。

可寫記憶體系統必須解決三個真正的問題：

記住什麼：代理需要規則來決定哪些事件、偏好或觀察值得保留。如果不這樣做，記憶體的大小就會爆炸，或是充滿雜訊。
如何儲存與分層記憶體：並非所有的記憶都是一樣的。近期項目、長期事實和短暫筆記都需要不同的儲存層、保留政策和索引策略。
如何在不破壞檢索的情況下快速寫入：記憶體必須持續寫入，但如果系統不是為高吞吐量插入而設計，頻繁更新可能會降低索引品質或減慢查詢速度。

挑戰 1：什麼值得記住？

並非使用者所做的每件事都應該最終留在長期記憶體中。如果有人建立了臨時檔案，並在五分鐘後刪除，那麼永遠記錄下來對任何人都沒有幫助。這就是核心難題：系統如何判斷什麼才是真正重要的？

(1) 判斷重要性的常見方法

團隊通常會依賴混合的啟發式方法：

以時間為基礎：最近的動作比舊的動作重要
基於頻率：重複存取的檔案或動作較為重要
基於類型：某些物件本質上比較重要 (例如專案組態檔案與快取檔案)

(2) 當規則衝突時

這些訊號經常會發生衝突。上星期建立的檔案，今天卻被大量編輯，應該以年齡還是活動為優先？沒有單一「正確」的答案，這就是重要性評分會迅速變得混亂的原因。

(3) 向量資料庫如何提供協助

向量資料庫提供您執行重要性規則的機制，而不需要手動清理：

TTL：Milvus 可以在設定時間後自動移除資料
衰減：可以降低較舊向量的權重，讓它們自然地從檢索中消失。

挑戰二：實際中的記憶體分層

隨著代理運行的時間越來越長，記憶體也越堆越高。將所有記憶體保留在快速儲存區是無法持續的，因此系統需要一種方法將記憶體分成熱（經常存取）和冷（很少存取）兩層。

(1) 決定何時成為冷記憶體

在此模型中，熱記憶體指的是保留在 RAM 中以進行低延遲存取的資料，而冷記憶體指的是移至磁碟或物件儲存以降低成本的資料。

決定何時記憶體變成冷記憶體可以用不同的方式處理。有些系統使用輕量級模型，根據動作或檔案的意義和最近的使用情況來估計其語意重要性。其他系統則依賴簡單、基於規則的邏輯，例如移動 30 天內未被存取或一週內未出現在檢索結果中的記憶體。使用者也可以明確地將某些檔案或作業標記為重要，以確保它們永遠保持熱狀態。

(2) 冷熱記憶體的儲存位置

一旦分類，熱記憶體和冷記憶體的儲存方式是不同的。熱記憶體保留在 RAM 中，用於經常存取的內容，例如作用中的工作上下文或最近的使用者動作。冷記憶體則會移至磁碟或物件儲存系統 (如 S3)，雖然存取速度較慢，但儲存成本卻低得多。由於冷記憶體很少被使用，而且通常只在長期參考時才會被存取，因此這種權衡方式運作良好。

(3) 矢量資料庫如何提供協助

Milvus 和 Zilliz Cloud支援這種模式，在維持單一查詢介面的同時，啟用冷熱分層儲存，因此經常存取的向量會留在記憶體中，而較舊的資料則會自動移至成本較低的儲存空間。