為 AI 裝上大腦：Google 揭示「情境工程」如何賦予 AI 記憶與個人化能力

大型語言模型 (LLM) 儘管能力強大，卻存在一個根本性的致命弱點：它們天生是「無狀態的 (stateless)」。每一次互動都是一次全新的開始，如同與一位記憶永遠歸零的對談者交流。這種健忘症正是將 AI 從巧妙的「無狀態」聊天機器人，提升為具備持久價值的智慧應用的最大障礙。要跨越這道鴻溝，我們需要的不是更多的提示技巧，而是一套全新的架構性準則。

近期，Google 與 Kaggle 合作的 AI 代理程式密集課程，便揭示了這套完整的藍圖。其核心概念——情境工程 (Context Engineering)——代表著一場典範轉移：從戰術性的「提示工程」，演進為一套戰略性的架構實踐。這是一門必要的紀律，旨在為 AI 裝上大腦，打造真正具備狀態感知、長期記憶與深度個人化能力的智慧代理程式。

1. 重新定義 AI 互動的基石——情境工程

長期以來，開發者社群專注於「提示工程 (Prompt Engineering)」，試圖透過精雕細琢的靜態指令來引導模型。然而，要建構真正智慧的代理程式，我們必須演進到一個更全面、更動態的框架。提示工程關注的是為模型提供一份固定的行為說明書，而情境工程則是一個完整的動態建構過程，它確保模型在每一次互動中，都能獲得完成當前任務所需的一切資訊。

這個概念的核心精神，可以用廚師的法文術語「備料 (mise en place)」來比喻。如果說提示工程只是給廚師一份食譜，那麼情境工程則是確保廚師在動手烹飪前，工作台上已經備妥了所有高品質的食材（相關情境）、鋒利的專用刀具（函式定義），並且充分理解用餐者的飲食偏好與過敏史（用戶記憶）。唯有如此，廚師才能穩定地創造出卓越且個人化的菜餚。

情境工程透過一個清晰的四步驟操作循環，在每一次對話輪次中為 AI 精心「備料」：

1. 擷取情境 (Fetch Context): 根據用戶當前查詢，從記憶、RAG 文件庫等外部系統中檢索相關資訊。

2. 準備情境 (Prepare Context): 將所有資訊動態組合成最終的提示字串。這是位於互動「熱路徑 (hot path)」上的關鍵步驟，直接影響回應延遲。

3. 調用模型與工具 (Invoke LLM and Tools): 將準備好的情境發送給 LLM，並根據其回應執行必要的工具。

4. 上傳情境 (Upload Context): 在背景非同步地將本次互動中產生或更新的資訊，寫入記憶等持久性儲存中。

這個循環所管理的複雜 payload（資訊負載），主要由三個核心部分組成，它們共同構成了 AI 的「當前意識」：

• 引導推理的情境 (Context to guide reasoning): 這部分定義了代理程式的行為模式與能力邊界，包含系統指令、工具定義與少樣本範例 (Few-Shot Examples)。

• 證據與事實資料 (Evidential & Factual Data): 這是代理程式進行推理的實質依據，包含長期記憶、透過 RAG 檢索的外部知識、以及工具的輸出。

• 即時對話資訊 (Immediate conversational information): 這部分讓代理程式錨定在當前的互動中，包含對話歷史、臨時狀態/草稿區 (State / Scratchpad) 以及用戶當前的提示。

情境工程的戰略重要性在於，它透過動態組織、篩選和注入上述資訊，直接解決了「情境腐化 (context rot)」的問題。當過多無關或陳舊的資訊塞滿模型的上下文視窗時，模型的推理能力會顯著下降。情境工程就像一位高效的資訊管理者，確保 AI 的「工作記憶」永遠保持清晰、相關且高效。

為了實現這一宏觀願景，情境工程依賴兩個核心的實踐元件：一個處理即時互動的「工作台」，以及一個儲存長期知識的「檔案櫃」。

2. 雙軌記憶系統：對話的工作台與知識的檔案櫃

為了賦予 AI 記憶，我們需要一個雙軌系統。Google 的白皮書巧妙地運用了「工作台 (workbench)」與「檔案櫃 (filing cabinet)」的比喻，來闡述這套系統的運作模式。代理程式透過「對話 (Sessions)」這個工作台來處理當前、即時的短期資訊；同時，透過「記憶 (Memory)」這個檔案櫃來建立一個有組織、可供長期查閱的個人化知識庫。這兩者協同運作，構成了 AI 從健忘到能夠學習與適應的基礎。

2.1 短期記憶：對話的「工作台」(Sessions)

「對話 (Session)」是一個自我包含的容器，用於記錄單一、連續的互動過程。它不僅僅是一份聊天紀錄，更是一個結構化的短期記憶單元，主要包含兩個關鍵部分：按時間順序排列的「事件 (Events)」，如用戶輸入、代理程式回應、工具呼叫等；以及結構化的「狀態 (State)」，如同一個臨時草稿區，用於存放當前任務的關鍵變數。

然而，在生產環境中管理 Session 面臨著嚴峻的挑戰：

• 安全性與隱私: 每個 Session 都與特定用戶綁定，必須實施嚴格的存取控制以確保用戶間的資料隔離。更關鍵的是，在任何對話資料被寫入永久儲存之前，都必須進行 PII (個人可識別資訊) 的偵測與編修，以符合法規要求並保護用戶信任。

• 效能與延遲: Session 資料位於每次互動的「熱路徑 (hot path)」上，意味著它需要在極短時間內被讀取與處理。隨著對話歷史變長，傳輸和處理的資料量增加，會直接導致 API 成本上升與使用者感受到的延遲增加。

• 上下文管理: 為了避免龐大的對話歷史超出模型的上下文視窗限制，必須採用「壓縮策略 (Compaction strategies)」。簡單的方法包括僅「保留最後 N 輪對話」。更複雜的方法，如「遞歸摘要 (Recursive Summarization)」，則會利用 LLM 在背景將舊的對話內容總結成精簡的摘要。這種方法能保留更高品質的情境，但其權衡之處在於需要一次額外、可能增加成本與延遲的 LLM 調用。

2.2 長期記憶：個人化的「檔案櫃」(Memory)

如果說 Session 是處理當下任務的工作台，那麼「記憶 (Memory)」就是一個精心整理、可供長期查閱的檔案櫃。此處的區分不僅是學術上的，它更是一項核心架構決策，決定了代理程式最終是成為一個事實檢索工具，還是一位個人化夥伴。Google 的專家以一個生動的類比來區分二者：RAG 如同研究圖書管理員，它讓代理程式從龐大的外部知識庫中查找事實，成為事實專家；而 Memory 則像是個人助理，它記錄了關於你的偏好與歷史互動，讓代理程式成為你的專家。

記憶的生成並非簡單的儲存，而是一個由 LLM 驅動、主動進行自我管理的 ETL (擷取、轉換、載入) 管道。這個由記憶管理器運行的過程，是一個智慧的、持續的策展行為，為了不影響用戶體驗，它必須在背景非同步執行：

1. 擷取 (Extraction): 首先，LLM 會分析嘈雜的對話紀錄，並根據預先定義好的主題，從中過濾並提取出有意義的信號。

2. 整合 (Consolidation): 接著，系統會將新擷取的資訊與檔案櫃中已有的記憶進行比對。LLM 會智慧地決定是更新現有記憶、合併重複資訊，還是刪除過時或矛盾的內容，以確保知識庫的準確性與一致性。

3. 儲存 (Storage): 最後，經過處理和整合後的記憶會被持久化儲存到向量資料庫或知識圖譜中，以備未來快速檢索。

一種更具自主性的架構模式是「記憶即工具 (Memory-as-a-Tool)」。在此模式下，代理程式被賦予 create_memory 或 query_memory 等工具，由 LLM 自行判斷在對話中何時需要儲存或檢索資訊。這賦予了代理程式更高的自主性，但其代價是可能需要額外的 LLM 調用來決定是否使用工具，從而帶來潛在的延遲與成本。

從認知科學的角度來看，這些記憶主要分為兩種類型：

• 宣告式記憶 (Declarative memory): 關於事實的知識（知道「是什麼」），例如：「用戶最喜歡的運動隊是巨人隊。」

• 程序式記憶 (Procedural memory): 關於流程的知識（知道「如何做」），例如：「成功預訂機票所需的一系列工具呼叫順序。」

2.3 記憶的基石：來源與信任 (Memory Provenance)

「垃圾進，自信的垃圾出 (garbage in, confident garbage out)」是 LLM 時代的一句格言，對於記憶系統而言更是致命風險。為了建立可靠的代理程式，我們必須能夠評估記憶的品質，而其信任度直接源自於它的來源 (provenance)——即一份記憶的原始出處與歷史。

代理程式必須根據記憶的來源類型與時效性來評估其可信度。例如，由 CRM 系統預先載入的引導式資料 (Bootstrapped Data) 通常具有高可信度，而從對話中隱性推斷 (implicitly inferred) 的用戶偏好則可信度較低。這種信任層級在解決衝突時至關重要：當 CRM 記錄的聯絡資訊與用戶在對話中的隨口提及不一致時，系統應優先採納哪個版本？此外，當用戶撤銷對某個數據源的訪問權限時，所有源自該數據的衍生記憶都必須被可靠地刪除或重新生成，這對維護數據完整性與用戶隱私構成了重大的運營挑戰。

理論框架雖已清晰，但其實際應用充滿挑戰。接下來，讓我們借鏡來自第一線專家的洞見，探討這些概念如何從理論走向實踐。

3. 專家洞察：從理論到實踐的未來展望

本節匯集了來自 Google 內外部專家的觀點，深入探討情境工程與記憶系統在真實世界中的應用、挑戰與未來趨勢。

Google Labs 的 Stephen Johnson 將 NotebookLM 描述為一個「面向消費者的上下文管理使用者介面」。他指出，這個工具讓非開發背景的用戶也能直觀地控制模型的上下文，只需上傳文件，就能決定模型應該基於哪些資訊進行回應。藉助百萬級 token 的上下文視窗和背後強大的 RAG 技術，用戶可以輕鬆地與大量資料進行深度對話，這正是情境工程理念在產品形態上的絕佳體現。

在開發者框架層面，Google 的 Julia Visinger 揭示了 ADK (Agent Development Kit) 的未來藍圖。ADK 近期引入了更清晰的上下文劃分，將其分為「靜態指令」（代理程式的核心身份）、「使用者訊息」（用戶的原始輸入）和「輪次指令」（應用程式在每次請求中動態生成的引導）。Visinger 強調，這種結構化設計之所以至關重要，是因為它能確保在生產環境中進行審計、保障安全性和實現規模化的需求。展望未來，ADK 將在動態上下文注入與記憶個人化方面進行大量投入。

來自 Cohere 的 Jay Alamar 則從模型與檢索的角度提供了深刻洞見。他強調，高效的記憶系統遠不止於簡單的向量搜索，而是需要一個結合了關鍵字搜索、向量搜索以及多層次重排（reranking）的混合式檢索系統。在深入探討了記憶來源、衝突解決和整合的複雜性後，白皮書作者、Google 工程師 Kimberly Milam 的觀點則顯得格外有力，她坦言：「把記憶做好非常、非常困難 (it is very very hard to do memory well)」。這句話精準地總結了高品質記憶維護的挑戰，也凸顯了其在建構可靠代理程式中的核心地位。

專家們的洞見描繪了一幅充滿機遇與挑戰的畫卷，從他們的實踐與展望中，我們可以提煉出整個領域發展的宏觀結論。

4. 結論：打造真正具備適應性 AI 的藍圖

綜合來看，情境工程並非單一技術，而是構建下一代智慧代理程式的總體性指導原則與核心紀律。它透過精妙地協調「對話 (Sessions)」這一即時工作台和「記憶 (Memory)」這一長期檔案櫃，為 AI 系統性地解決了「健忘症」這一根本缺陷。這套框架讓代理程式從只能進行一次性問答的研究圖書管理員，進化為能夠真正學習、適應並深入了解用戶的個人助理。

這一框架的深遠影響在於，它為開發者社群提供了一套清晰的藍圖。依循這套藍圖，開發者可以打造出能夠與用戶建立長期關係、具備持續性與深度個人化能力的 AI 體驗。這意味著未來的 AI 不再是冷冰冰的工具，而是能夠與我們共同成長，記住我們偏好、理解我們目標的智慧夥伴。這正是通往下一代個人化、自適應 AI 服務的必經之路。

正如 Jay Alamar 在課程中向開發者社群發出的呼籲：「勇於挑戰極限 (shoot for the sky)」。情境工程、Session 與 Memory 等新工具與框架已經備妥，現在正是利用它們來共同塑造代理程式與 AI 未來的最佳時機。一場關於 AI 互動體驗的深刻變革，正由此拉開序幕。

--------------------------------------------------------------------------------

資料來源

• Context Engineering: Sessions, Memory, Authors: Kimberly Milam and Antonio Gulli