擴大 Context Window 解決不了 Agent 的記憶問題：Redis 提出三層記憶架構
Redis Engineering Blog · 2026-06-17
Redis 工程師 Jim Allen Wallace 於 2026 年 6 月 17 日在官方部落格發表分析，指出業界普遍誤解「更大的 context window 等於更好的 agent 記憶」，並提出以外部持久化層為核心的三層記憶架構。這篇文章同時開源了 redis/agent-memory-server（當前版本 v0.15.2），提供可直接整合 MCP 的 agent 記憶基礎設施。
Context Window 與記憶的根本差異
語言模型的 context window 本質上是每次 inference 的輸入緩衝區，呼叫結束後即清空，無法跨 session 保存任何狀態。agent 若要在多輪對話或多次執行之間「記住」過去發生的事情，必須將資訊存入外部系統，再於下次呼叫前主動注入。單純把 window 從 128K 擴充到更大，只是推遲了問題發生的時間點，並不解決跨 session 連續性。
另一個被低估的問題是「Lost in the Middle」效應：模型對 context 頭尾的注意力遠高於中間部分。NoLiMa 基準測試對 13 個宣稱支援 128K token 的模型進行評估，發現在 32K token 處就有 11 個模型的表現跌破短輸入表現的 50%，大多數模型真正能承載推理任務的有效範圍僅約 2K token。GPT-3.5-Turbo 在答案埋在 context 中間時，甚至比完全不看 context 的基線還要差。
成本面的問題同樣嚴峻。LLM API 是無狀態的，每次呼叫都必須重新傳送完整對話歷史；隨著對話輪數增加，累積輸入 token 數以二次方速度成長。對於會在單次任務中發出數十甚至數百次 API 呼叫的 agent，這個成本放大效應比人工對話場景嚴重得多。
三層記憶模型
文章將 agent 記憶拆分為三個各自獨立的層級。短期記憶（short-term memory）存活於單一 session，以 context window 中的對話訊息呈現；工作記憶（working memory）指當前 inference call 正在處理的材料，包含已從外部檢索並注入的片段；長期記憶（long-term memory）則必須存放在外部資料庫，能夠跨 session 持久保存。
實驗數據顯示，選擇性檢索在準確率與效率上均優於「全量歷史重播」策略。一個記憶增強系統在基準測試上達到 81.95% 準確率，每次查詢僅消耗 1,294 個 token，相當於使用完整 context 的 5%。另一套系統的 p95 延遲比全量 context 方案低 91%，而且準確率更高。這說明問題的答案不是更大的 window，而是更精準的檢索。
redis/agent-memory-server 架構
redis/agent-memory-server 以 Python 實作，提供 REST API 與 MCP server 兩種介面。工作記憶層使用 Redis 的 in-memory 資料結構儲存當前 session 的互動歷史；長期記憶層以 Vector Search 對話題、實體、偏好進行語義索引，支援 semantic、keyword 與 hybrid 三種搜尋模式；此外還有語義快取（semantic caching）層，能以意義而非文字完全比對來命中快取，例如「Product A 有哪些功能？」和「告訴我 Product A 的功能」會被視為同一查詢。
LLM 整合透過 LiteLLM 實作，支援 OpenAI、Anthropic、AWS Bedrock、Ollama、Azure、Gemini，不綁定特定供應商。MCP server 模式支援 stdio（適合 Claude Desktop）與 SSE 兩種傳輸方式，可透過 mcp.json 設定檔直接掛載到支援 MCP 的 agent 框架。記憶提取策略可設定為 discrete（離散事件）、summary（摘要）、preferences（偏好）或 custom（自定義），讓開發者根據應用場景調整索引行為。
文章強調記憶層在設計上與模型和 agent 框架解耦——LangGraph 從一開始就將 checkpointing 設計為 database-agnostic，更換模型或擴大 window 不會影響記憶持久化層的運作。安裝方式支援 Docker 映像與以 uv 套件管理器的原始碼部署兩種路徑。
Google 聯合微軟等多家公司發布 ARD 規範：讓 AI Agent 能在全網動態發現工具與能力
Google Developers Blog · 2026-06-17
Google 資深工程師 Junjie Bu 與 Srinivas Krishnan 於 2026 年 6 月 17 日宣布 Agentic Resource Discovery（ARD）規範正式公開，版本為 v0.9 Draft。這份規範由微軟、Google、Hugging Face、GoDaddy、Cisco、Databricks、GitHub、Nvidia、Salesforce、ServiceNow、Snowflake 等組成的工作小組共同起草，目標是讓 AI agent 能在執行期間跨組織邊界動態發現、驗證並連接分散於全網的工具與服務。
問題背景：Agent 如何找到它需要的能力
現有的 MCP、A2A、Skills 等協議解決的是 agent 如何「呼叫」能力的問題，但並未定義 agent 如何「找到」能力。ARD 明確將自身定位在呼叫之前的發現階段，不取代任何現有執行協議，而是作為能力發現的前置層。規範中定義的 agentic resource 涵蓋 MCP server、A2A agent、Skill、Canvas、Plugin、API 及 workflow 等各種可被呼叫的外部能力。
沒有標準化的發現機制意味著 agent 只能依賴硬編碼的端點或人工維護的清單，無法在運行時動態調整能力組合。ARD 嘗試讓能力發現像 DNS 解析一樣透明且可信賴——agent 提出任務需求，系統自動返回符合條件且可驗證的能力列表。規範特別強調「ARD 不是 MCP，不是 A2A，不是 Skills，也不是 API runtime，不取代任何一個」，它的作用域完全在呼叫發生之前。
兩層架構：Catalog 與 Registry
ARD 的核心架構由兩個層次組成。第一層是 Catalog：組織在自己的域名下託管一份 ai-catalog.json 檔案，以域名所有權作為加密信任的基礎，列出該組織發布的所有 agentic resource。這個設計讓域名本身成為信任錨點，不需要中心化的憑證機構。Catalog 支援嵌套結構，允許組織將子系統的能力委託給獨立管理的 catalog。
第二層是 Registry：作為搜尋引擎，爬取各組織發布的 catalog，建立索引，並在 agent 查詢時返回帶有驗證元資料的匹配結果。ARD 規範的主要技術文件存放於 spec/ard.md，schema 定義以 CDDL、JSON Schema 與 OpenAPI 三種格式提供於 spec/schemas/ 目錄，一致性測試工具則在 conformance/ 目錄，方便實作者驗證合規性。
Google Cloud 的企業實作與規範開放性
Google Cloud 在 Gemini Enterprise Agent Platform 上提供 Agent Registry，作為 ARD 規範的企業級實作。它在開放規範基礎上增加了治理、唯一命名空間分配、流量出口策略與合規驗證等企業需求，並透過 Agent Identity 機制處理身份驗證問題。
規範以 Apache 2.0 授權發布於 ards-project/ard-spec，狀態仍為草稿，工作小組持續接受社群透過 issue 與 PR 提交意見。規範同時發布了配套的 AI Catalog Standard，定義 ai-catalog.json 的詳細格式。ARD 的提出填補了從「我需要做某件事」到「我知道要呼叫哪個端點」之間那段缺失的環節，是 agentic web 基礎設施拼圖中尚未成形的一塊。
原始來源：Agentic Resource Discovery Specification — agenticresourcediscovery.org
A2UI 與 MCP Apps 三種整合模式：在宣告式與自訂 Agentic UI 之間找到平衡
Google Developers Blog · 2026-06-17
Google A2UI 團隊及 MCP UI 共同創始人 Ido Salomon、Liad Yosef 於 2026 年 6 月 17 日在 Google Developers Blog 發表文章，說明如何將 A2UI 宣告式框架與 MCP Apps 的 iframe 自訂能力結合。文章提出三種具體的架構模式，對應不同的部署場景；A2UI 當前穩定版本為 v0.9.1，v1.0 規範候選版本已進入 release candidate 階段。
兩種 Agentic UI 方法的根本取捨
MCP Apps 透過 iframe 提供完整的網頁技術自由度（HTML、CSS、JavaScript），開發者可以建構任意複雜的互動介面，但代價是與宿主應用的視覺風格不一致，以及 iframe 固有的效能與安全限制。A2UI 採取相反的設計哲學：以 JSON payload 定義「要渲染什麼」而非「怎麼渲染」，agent 只能請求來自預先審核的 component catalog 中的元件（如 Card、Button、TextField），由宿主應用的原生設計系統負責實際渲染，確保一致性與安全性，但犧牲了對 UI 細節的直接控制。
A2UI 使用 a2ui:// URI scheme 識別資源，payload MIME type 為 application/a2ui+json。元件以扁平列表加 ID 引用的方式組織，支援漸進式更新，不需要在每次狀態改變時重傳整個 UI 樹。安全模型基於能力授權（capability-based security），JSON 格式本身不可執行，消除了 XSS 等注入攻擊面。
三種整合模式的技術細節
第一種模式是「A2UI over MCP Servers」：MCP server 直接以 application/a2ui+json MIME type 回傳 A2UI payload，繞過 iframe，讓宿主應用以原生元件渲染 agent 意圖。靜態介面（如設定表單）透過 MCP Resources 傳遞；動態介面（如即時資料視覺化）透過 MCP Tools 在工具回應中以 EmbeddedResource 包裝 payload 傳遞。用戶端在 MCP 初始化時透過 capabilities.a2ui.clientCapabilities 宣告支援的 catalog ID，無狀態 server 則可以在每次訊息的 _meta 欄位接收能力聲明。
第二種模式是「MCP Apps in A2UI Components」：將狀態複雜或需要高度客製化的 MCP App 封裝在 A2UI 元件的安全 iframe 中。狀態同步透過事件驅動循環實現：MCP App 內的狀態變化觸發 tool call，A2UI 元件攔截並轉換為 action，AI agent 協調宏觀狀態變化，更新後的資料同時補充原生元件與嵌入式元件。這個模式讓宿主應用能保持整體設計一致性，同時把複雜的專業功能委託給獨立的 MCP App。
第三種模式是「A2UI inside MCP Apps」：MCP App bundle 內嵌自己的 A2UI renderer，讓不支援 A2UI 的傳統宿主環境也能呈現動態宣告式 UI，對既有系統的架構改動最小。三種模式的互動事件處理方式一致：用戶操作觸發名為 action 的 tool call，帶入解析後的 context 值，server 處理輸入並回傳更新的 UI payload。
A2UI Agent SDK 與跨框架支援
A2UI Agent SDK 負責 schema 驗證、catalog 管理與 prompt 生成，可透過 PyPI 安裝。A2UI 的設計目標是與傳輸層解耦：payload 可以透過 A2A Protocol 或 AG-UI 傳送，渲染層已有 Flutter、Web、Angular、Lit、React 的實作，TypeScript（70.5%）與 Python（19.4%）為主要開發語言。MCP resource annotation 可透過 annotations=types.Annotations(audience=["user"]) 控制 LLM 可見性——UI JSON 渲染給用戶但對語言模型隱藏，避免不必要的 token 消耗。
原始來源：google/A2UI — GitHub