建構高效的生產級上下文感知多智能體框架 Google 官方這篇部落格深入探討了在開發複雜的AI 智能體時，如何透過系統化的「情境工程」 來解決由於資訊量爆炸帶來的效能瓶頸，以Google ADK 為例，提出了一套全新的架構設計理念。 核心挑戰：情境瓶頸隨著智慧體處理的任務越來越複雜（如長期工作流程、深度研究、程式碼維護），它們需要追蹤的資訊量呈指數級增長。僅依靠擴大模型的「上下文視窗」並非長久之計，面臨三大壓力： · 成本與延遲：上下文越長，推理成本越高，反應速度越慢。 · 訊號衰減：大量無關的日誌或過時資訊會導致模型“迷失”，無法抓取關鍵指令（Lost in the middle）。 · 物理限制：真實場景中的資料量（如RAG 檢索結果、完整對話記錄）最終總是會溢出任何固定的視窗限制。 核心理念：上下文即“編譯視圖” 文章提出了一個根本性的思維轉變：不要把上下文看作是一個不斷追加的字串緩衝區，而應將其視為對底層狀態的「編譯視圖」。 · 來源資料(Source)：完整的會話記錄、長期記憶和文件。 · 編譯器(Compiler)：一系列的處理流程，負責過濾、排序和轉換資料。 · 視圖(View)：最終發送給LLM 的「工作上下文」。 關鍵架構設計 A. 分層結構(Structure: The Tiered Model) ADK 將上下文資料分為四個層級，以分離「儲存」與「展示」： · 工作上下文(Working Context)：即時建構的、僅供本次呼叫使用的Prompt。它是臨時的、經過優化的。 · 會話(Session)：結構化的、持久的互動日誌（包含使用者訊息、工具呼叫、錯誤訊息等）。它是客觀的「事實」。 · 記憶(Memory)：跨會話存在的長期知識（如使用者偏好）。 · 製品(Artifacts)：大型資料物件（如PDF、CSV、長日誌）。它們只被引用（透過名稱/版本），而不是直接貼進Prompt。 B. 管道化處理(Flows and Processors) 透過定義有序的“處理器鏈”，開發者可以像搭積木一樣控制上下文的生成。例如：先做權限檢查，再插入系統指令，最後插入經過壓縮的歷史記錄。這讓上下文的建置過程變得可觀測、可測試。 C. 智慧相關性管理(Relevance) 為了保持上下文的“精簡”，系統和智能體共同決定此時此刻需要什麼資訊： · 按需載入製品：智能體預設只看到檔名的引用。只有當它確信需要查看內容時，才會呼叫工具將其暫時載入進來。用完即丟，避免永久污染上下文。 · 主動/被動記憶檢索：透過工具主動搜尋或透過預處理器自動注入相關的長期記憶。 · 壓縮與過濾：在會話層自動執行後台任務，將舊的詳細日誌「壓縮」為摘要，或直接按規則過濾掉無用的噪音。 D. 多智能體協作(Multi-agent Context) 在多智能體系統中，為了防止「上下文爆炸」和幻覺，ADK 採用了嚴格的作用域控制： · 按需交接：當主智能體呼叫子智能體時，預設不傳遞所有歷史記錄，只傳遞必要的指令和最少量的上下文。 · 敘事轉換(Narrative Casting)：當切換智能體時，系統會將前一個智能體的「助手訊息」轉換為「敘事背景」（例如：「[背景資訊]：智能體A 剛才說了...」）。這防止了新智能體誤以為之前的操作是自己做的，從而產生認知混亂。 總結這篇文章的核心觀點是：生產級的AI 智能體開發，不能只靠“堆砌Token”，而必須建立一套高效的上下文生命週期管理系統。 透過將上下文視為一個動態編譯的、分層的、按需加載的系統，開發者可以構建出既聰明（擁有足夠資訊）又高效（低延遲、低成本）的智能體應用。 閱讀原文
