記憶、狀態與知識：別再把所有東西都叫做「記憶」

一個為中型旅行社打造的旅遊規劃 Copilot，被問了一個很直接的問題：「這間飯店之前是否在輪椅使用者的無障礙審查中未通過？」

助理自信滿滿地回答確實如此。這個答案聽起來合理——先前對話提過一間被否決的京都物件、使用者已經連續好幾輪在討論無障礙住宿，而且目前畫面仍顯示一個飯店比較流程正在進行中。然而，目前進行中的預訂明確要求的是有經過驗證輪椅無障礙設施的物件、目前的合約編號指向的是另一間飯店，而且實際的合作夥伴資料庫顯示這個物件沒有先前的無障礙未通過紀錄。

這裡沒有什麼神奇的錯誤。系統就是把好幾個不同的資訊層合併成了一個模糊的「記憶」概念，把先前的聊天內容、工作流程變數、暫時性證據和持久紀錄當成可以互換的東西在用。這是設計錯誤，不是智慧問題。

這種混淆在 AI 產品討論中反覆出現。團隊說系統「需要記憶」時，他們其實可能在講幾種截然不同的東西：

• 對話中跨輪次的連續性

• 進行中工作流程的結構化狀態

• 為單一任務組裝的暫時性上下文

• 應該超越任何單一會話存續的持久事實紀錄

這些是不同的職責，應該用不同方式來設計、儲存、更新和治理。

本文區分四個經常被混為一談的術語：

• 對話記憶（conversation memory）

• 任務狀態（task state）

• 工作記憶（working memory）

• 持久知識（durable knowledge）儲存

目標是實用的系統清晰度。這不是一篇討論人類認知、內心獨白或模型是否「真的記得」的文章，也不是記憶架構的廣泛調查。本文談的是有狀態 AI 系統的軟體架構，以及本系列後續內容需要的最基本詞彙。

第三篇文章建立了檢索流程（pipeline）：系統如何在生成答案之前從外部語料庫擷取證據。那是一個特定的資訊職責。本文退一步，要釐清一件事——檢索並不是系統向前傳遞的唯一資訊類型，而這裡描述的四個層次各有不同的任務、生命週期和權威性規則。

為什麼「記憶」變成了一個萬用詞

對話介面助長了術語的草率使用。當系統在持續的對話中回應時，使用者和開發者自然會把任何被重複使用的資訊叫做記憶（memory）。聽起來無害，但一旦系統需要變得可靠，問題就會浮現。

在正式系統中，不同種類的資訊扮演不同的角色：

• 有些資料幫助系統維持對話的連續性。

• 有些資料追蹤工作流程的進度和下一步驟。

• 有些資料僅為當前任務組裝，應該被丟棄或重新整理。

• 有些資料是持久的組織紀錄，具有來源、權限和更新規則。

把所有這些都叫做記憶，等於把幾個關鍵的工程問題藏起來了：

• 資訊從哪裡來？

• 它應該持續多久？

• 誰或什麼被允許更新它？

• 什麼讓它具有權威性？

• 它如何被驗證？

• 什麼時候應該被忽略？

一旦這些問題變得重要，這個萬用標籤就不夠用了。

四個層次

理解這個問題最清晰的方式，是把資訊處理分為四個層次。

對話記憶（Conversation Memory）

對話記憶（conversation memory）是跨輪次儲存的資訊，目的是讓互動保持連貫。它幫助系統接續對話，讓使用者不用每一輪都把所有內容重新講一遍。

典型範例：

• 客戶偏好火車而非巴士

• 當前有效的行程參考編號

• 「這間飯店」指的是兩輪前討論的那間物件

• 先前陳述的客戶限制條件，在本次會話期間仍然適用

它的用途：

• 對話連續性

• 當下的使用者體驗

• 跨輪次的指稱消解

它不是：

• 經過驗證的持久事實來源

• 應用程式狀態的完整表示

• 領域紀錄的替代品

對話記憶通常是輕量級、會話範圍內的，雖然有些系統會跨會話保留部分內容。但就算被保留了，它也不應自動變成權威知識。被記住的偏好，例如「以美元顯示價格」，與被記住的宣稱，例如「Hotel Sakura 在三月的輪椅無障礙稽核中未通過」，本質上是兩回事。

任務狀態（Task State）

任務狀態（task state）是關於進行中工作流程的結構化資訊。它描述的是系統正在做什麼、已經做了什麼，以及哪些識別碼或控制變數對下一步很重要。

典型範例：

• 目前行程 ID：JPN-2026-0417

• 飯店比較狀態

• 行程草稿 ID

• 哪些預訂呼叫已經完成

• 行程提案的核准狀態

它的用途：

• 工作流程控制

• 可恢復性

• 冪等性（idempotency）

• 應用程式元件之間的協調

它不是：

• 僅憑自身的對話連續性

• 關於領域的事實知識

• 為單一推理流程選取的暫時性證據

任務狀態對任何軟體團隊來說都不陌生。它不是什麼新奇的 AI 功能——就是普通的應用程式狀態，只不過剛好附加在用了模型的系統上。

這個區別之所以重要，是因為一個系統可以有出色的對話連續性，卻照樣會丟失工作流程。反過來也成立——它可以有穩健的工作流程狀態，但如果沒有以權威紀錄為基礎，照樣會答錯事實問題。

工作記憶（Working Memory）

工作記憶（working memory）是為一個任務或推理流程組裝起來的暫時性上下文。通常包括檢索到的證據子集、擷取的欄位、中間摘要，以及目前需要的指令。

典型範例：

• 從合作夥伴資料庫檢索到的三間最相關的京都無障礙飯店

• 從一個物件清單中擷取的價格和房間詳細資訊

• 為飯店選擇任務建立的暫時比較資料包

• 產出有根據的推薦時使用的中間筆記

它的用途：

• 將模型聚焦於相關上下文

• 減少不必要的上下文負載

• 在有限的證據集上進行多步驟推理

它不是：

• 持久紀錄

• 使用者個人檔案

• 工作流程帳本

工作記憶在設計上就是短暫的。它可能存在於上下文視窗（context window）、暫存結構、作業的中間儲存，或其他執行時期的層。重點在於：它是為任務而組裝的，不應該只因為它曾經有用就自動被提升為持久知識。

這也說明了為什麼更大的上下文視窗並不能取消系統設計的需求。更多的暫時上下文空間可以幫助某些任務，但來源追溯、更新策略、存取控制或長期正確性的問題，它都解決不了。

持久知識儲存（Durable Knowledge Stores）

持久知識（durable knowledge）儲存的是長期存續的資訊，系統可以隨時間推移持續檢索和使用。在這個討論裡，這些儲存最接近許多團隊口語說的「記憶」。不過即便如此，知識（knowledge）這個詞通常更精確。

典型範例：

• 合作夥伴飯店與旅遊營運商資料庫

• 簽證與入境要求資料庫

• 鐵路通票條款與票價表

• 已核准的供應商合約紀錄

• 經過驗證的無障礙稽核報告

它們的用途：

• 儲存組織知識

• 支援有根據的檢索

• 維護超越任何單一會話或任務的紀錄

• 支援來源追溯、稽核和受控更新

它們不是：

• 每次對話的逐字紀錄

• 未完成推理的自由格式暫存區

• 模型曾經看過的所有內容的無治理傾倒區

持久知識儲存需要基本的資料管理紀律。它們需要 schema 或至少穩定的結構、存取控制、時效策略、資料血緣追蹤，以及判定新素材是否夠可信而可以使用的規則。如果系統說不清楚一個持久事實從哪裡來、何時更新、是否被核准使用，那它的「記憶」設計就不夠成熟。

直接比較

這四個層次彼此相關，但不該混為一談。

層次 — 主要目的 — 典型生命週期 — 範例 — 誤用時的失敗模式

對話記憶（conversation memory） — 維持跨輪次的對話連貫性 — 會話範圍或選擇性持久 — 「客戶偏好火車而非巴士」 — 從聊天衍生的假設被當作事實

任務狀態（task state） — 追蹤工作流程進度和控制變數 — 直到任務完成或歸檔 — trip_id=JPN-2026-0417 — 工作流程漂移、重複操作、進度丟失

工作記憶（working memory） — 儲存當前任務的暫時性上下文 — 數秒到一次作業執行 — 檢索到的飯店清單和擷取的無障礙詳細資訊 — 暫時性證據被誤認為持久真相

持久知識（durable knowledge） — 儲存超越會話存續的權威紀錄 — 長期存續 — 合作夥伴資料庫、簽證要求資料庫 — 過時、無法追蹤或未經授權的事實

這個比較帶出一條實用規則：

並非所有持久性都是記憶，也並非所有類似記憶的行為都應被視為知識。

如果團隊對所有四項職責使用同一個儲存機制和一個模糊標籤，系統最終會混淆偏好與事實、工作流程與證據，或暫時上下文與持久紀錄。

實作範例：行程偏好對比事實紀錄

回到旅遊規劃 Copilot。

一位旅遊顧問正在為四口之家規劃一趟 10 天的日本無障礙行程。全程需要輪椅無障礙設施。目前的任務是把一間候選飯店與先前的客戶回饋及經過驗證的無障礙資料做比較。

以下說明資訊應該如何被分離。

本範例中的對話記憶（Conversation Memory）

系統可能儲存：

• 當前有效的行程參考：JPN-2026-0417

• 客戶偏好火車旅行而非巴士

• 客戶希望住宿以櫻花季節接近度和輪椅無障礙為考量

這些資訊有助於互動保持順暢，但它本身不應被拿來回答特定飯店是否先前在無障礙審查中未通過。

本範例中的任務狀態（Task State）

系統可能追蹤：

• 目前合約 ID：KYO-H12

• 飯店比較工作流程的狀態

• 為此行程產生的行程草稿 ID

• 資深旅遊顧問是否已核准提議的路線

這些是讓應用程式能恢復工作、避免重複預訂呼叫和協調多步驟流程的關鍵。

本範例中的工作記憶（Working Memory）

系統可能組裝：

• 從合作夥伴資料庫檢索的京都無障礙飯店清單

• 從一個物件中擷取的價格和房間配置

• 經過驗證的輪椅無障礙旅遊精選清單

• 跨物件比較無障礙設施的中間筆記

這個資料包存在的目的就是支援當前分析。隨著任務演進，它可能會被重新計算或替換。

本範例中的持久知識（Durable Knowledge）

系統可能從以下來源檢索：

• 合作夥伴飯店與營運商資料庫

• 無障礙稽核紀錄

• 經過驗證的簽證與入境要求

• 已核准的鐵路通票條款（例如，JR Pass 截至 2026 年年中約 50,000 日圓/成人（7 日券），票價調整預定於 2026 年 10 月 1 日實施；Nozomi 不包含在基本通票中，2023 年 10 月起可另購補充票）

這些來源應該決定事實答案。如果資料庫顯示當前物件沒有先前的無障礙未通過紀錄，那先前在聊天中提到的內容不應該覆蓋這個結果。

這就是核心的架構教訓：系統可以記住行程偏好和互動上下文，但事實答案仍應來自有根據的知識來源。對話連續性是有用的，但它不是證據。

常見誤解

有幾個反覆出現的誤解容易導致糟糕的設計。

「聊天紀錄基本上就是知識庫。」

並不是。聊天紀錄就是對話中講了什麼的紀錄。裡面有些可能正確，有些可能是推測，有些可能下一輪就過時了。知識庫應該有明確的匯入規則、來源追溯和更新紀律。

把聊天紀錄當知識庫用的團隊，最後往往會做出把先前的猜測當成已確立事實來重複的系統。

「如果系統記得先前的輪次，它就有持久記憶。」

記住先前的輪次通常只代表應用程式儲存並重新使用了上下文。這是有用的，但不代表持久、受治理或經過驗證的知識。

持久性本身不是問題。問題在於什麼類型的資訊被持久儲存，以及它該有多大的權威性。

「提示快取（prompt caching）代表系統現在知道了這些資訊。」

並不是。快取是一種執行時期的最佳化。它可以降低重複使用上下文的處理成本，但不會把暫時的提示素材變成持久的知識資產。快取命中（cache hit）跟有來源追溯和更新策略的維護紀錄完全是兩回事。

「長上下文解決了記憶問題。」

更長的上下文視窗（context window）可以讓模型一次考慮更多內容。但狀態管理、持久儲存、檢索品質、權限或紀錄維護的問題，它都解決不了。更大的暫時工作區，終究還是暫時工作區。

「代理儲存的所有東西都應該叫做記憶。」

這正是系統變得難以理解的原因。像 user_memory、agent_memory 或 long_term_memory 這樣的儲存名稱，底下往往藏了很不一樣的東西：聊天摘要、作業變數、文件 embedding、工具追蹤和暫存區。這些應該按角色來分開，而不是按一個擬人化的隱喻來歸類。

分層混淆時會出什麼問題

模糊術語的實際代價不是語意上的，而是營運上的。

過時的聊天假設變成事實

對話早期的猜測後來被當成已驗證的資訊反覆引用。系統「記得」這項宣稱，但沒有任何權威儲存確認過它。

工作流程狀態偏離現實

助理以為自己還在評估飯店 A，但應用程式已經切換到飯店 B。如果任務狀態被埋在聊天紀錄裡而沒有用結構化方式管理，這種偏移完全在意料之中。

暫時性證據被誤認為持久紀錄

檢索到的片段或中間摘要對一個任務有用，之後就被當成經過驗證的長期事實來處理。當證據資料包是在很窄的檢索條件下組裝、而且可能不完整時，這種風險尤其大。

個人偏好干擾事實判斷

使用者特定的上下文——像偏好的格式或當前的關注焦點——混進檢索或排序邏輯裡，扭曲了事實輸出。一旦個人化改變了呈現哪些證據，它就不再是中性的。

隱私與保留問題

團隊把太多對話上下文保留太久，因為他們把所有東西都叫做記憶，卻從未定義保留邊界。這造成了明顯的治理和安全風險。

重複帶來的虛假信心

如果資訊被快取、重複或跨輪次儲存，使用者可能會覺得它更可靠了。但重複不等於驗證。一個流暢的系統如果把錯誤的層次當成權威，可以長期持續犯同樣的錯。

實用設計指南

改善這些系統最簡單的方法：別再把「記憶」當成單一功能來設計，轉而去設計有明確合約的資訊層。

1. 給每個層次一個明確的任務

動手實作之前先定義：

• 該層次儲存什麼

• 它為什麼存在

• 它存活多久

• 誰可以更新它

• 它具有什麼權威性

如果一個層次回答不了這些問題，它可能藏了多個職責。

2. 區分權威性與便利性

對話記憶（conversation memory）是便利的。工作記憶（working memory）是有用的。當事實正確性重要時，兩者都不該優先於持久知識（durable knowledge）。

聽起來理所當然，但許多產品出問題的原因恰恰就是便利性上下文比權威紀錄更容易取得。

3. 保持任務狀態的結構化

不要靠自由格式的聊天文字來追蹤工作流程進度。把識別碼、狀態和轉換存在明確的應用程式結構中。這讓可恢復性、除錯和稽核都變得更容易。

4. 把工作記憶視為可丟棄的

暫時性證據資料包應該是可以重新整理、可以替換的。如果需要成為持久知識的一部分，就應該透過單獨的匯入或核准流程來提升，而不是讓它們停留在模糊的中間狀態。

5. 對持久知識要求來源追溯

當持久儲存驅動答案時，系統應能追蹤紀錄從哪來的、何時更新，以及是否被核准用於當前用途。在嚴肅的企業或旅行社場景中，這不是選配。

6. 明確設計保留策略

對話記憶、任務狀態日誌、工作記憶成品和持久知識儲存不需要相同的保留期限。把它們全部混為一談，通常會導致不必要的刪除或不必要的累積。

本文不是什麼

這不是在說所有 AI 系統都只有一種正確的記憶架構。合適的設計取決於產品、風險概況和工作流程。

這也不是在說每個系統從第一天就需要精密的多層儲存。簡單的產品可以從簡單開始。不過即便是簡單的產品，也能從正確命名層次中受益。

最重要的是，這不是在替擬人化的語言背書。有用的問題不是模型是否像人一樣在記憶，而是：哪個系統元件用什麼策略儲存什麼資訊。

為什麼在談論代理之前這個區分很重要

一旦系統超越了單次提示（one-shot prompting），大家就會開始用助理、代理（agent）或自主工作流程來描述它們。如果記憶（memory）、狀態（state）和知識（knowledge）還是混為一談，後續討論馬上就會變得混亂。

助理可能不需要管理複雜的任務狀態就能保持對話連續性。代理可能需要明確的任務狀態（task state）來協調多步驟動作。更自主的系統可能兩者都需要，還得從持久知識中擷取資訊，並為每個子任務組裝暫時的工作記憶（working memory）。

這些不是不同種類魔法的標籤，而是建立在不同職責資訊層之上的不同控制模式。

這就是通往本系列下一部分的橋樑。在我們能清楚談論助理、代理和自主性之前，得先知道系統往前傳遞什麼資訊、它現在正在做什麼、它正在用什麼暫時性證據，以及它被允許信任哪些持久來源。

來源附註

本文參考以下官方與研究來源：

• OpenAI. "Conversation state." 應用程式端管理對話連續性與狀態處理的官方參考。developers.openai.com/api/docs/guides/conversation-state

• OpenAI. "Prompt caching." 用來區分執行期快取重用與持久記憶或權威知識的官方參考。developers.openai.com/api/docs/guides/prompt-caching

• Anthropic. "Context windows." 將上下文視為有界工作記憶，而非模型訓練語料的參考。docs.anthropic.com/en/docs/build-with-claude/context-windows

• Park, J. S., O'Brien, J. C., Cai, C. J., et al. "Generative Agents: Interactive Simulacra of Human Behavior." 關於儲存經驗、檢索與反思作為明確架構的研究參考。arxiv.org/abs/2304.03442

• Packer, C., Wooders, S., Lin, K., et al. "MemGPT: Towards LLMs as Operating Systems." 將記憶階層視為系統設計問題的參考。arxiv.org/abs/2310.08560

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." 資料治理、來源脈絡與可信任使用框架參考。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence