當搜尋開始「寫 UI」－ Gemini的動態檢視是否預告了AI搜尋代理的誕生？

 

搜尋、App，還是檢視表？

AI 搜尋正在從「引擎」進化為「代理」，這將徹底改變電子商務與開發模式。Google Gemini的動態檢視功能，已經讓搜尋結果不再只是文字，而是互動式App。這意味著，未來商品曝光與交易，將由AI 主導，而不是使用者點擊。

在簡立峰博士於 YouTube 頻道《TechOrange：Google 從搜尋引擎到 AI 代理》的分享中，他指出 Google 正在經歷從「搜尋引擎（Search Engine）」到「AI 代理（AI Agent）」的重大轉型，並暗示未來商業模式將隨之改變。這讓我不斷思考：這將會是一個什麼樣的世界？

以下內容，根據簡博士的觀點，並搭配 Gemini 工具整理與建立圖像簡報。

AI Agent 會讓未來變成什麼樣子，其實仍然無法完全想像……

就像20年前，我無法想像有一天，每個人手上都能拿著一個像螢幕般的裝置，隨意滑動幾下，便當就能直接送到家門口。

Gemini 3帶來的衝擊

Gemini 3 在 2025 年 11 月推出後，社群媒體掀起熱烈討論。新功能幾乎每天更新，讓人應接不暇。在這波變革中，我注意到一個新選項：動態檢視（Dynamic View）。

就在這樣的情況下，我注意到 Gemini 3 工具下拉選單中出現了〔動態檢視〕。在好奇心的驅動下，我向 Gemini 3 詢問：這到底是什麼？又該怎麼使用？

於是我下了一句非常簡單的提示詞：

「規劃一個台北到宜蘭的 3 天 2 夜家庭旅遊行程，包含景點、美食與交通時間」

這竟然是一個「網頁 App」。

它把我原本需要透過搜尋清單、慢慢整理的內容，直接生成一個可互動的 App，而且地圖還是可以操作的。

我又再玩了一次。類似的提示詞：

規劃一個台北到宜蘭的 3 天 2 夜家庭旅遊行程，包含景點、美食與交通時間

 

這一次更誇張，地圖甚至直接標示出了完整的行程路徑……

我開心地把這個結果分享給同事，沒想到卻發現一件有趣的事：
〔動態檢視〕並沒有出現在我同事的工具列中，取而代之的是〔視覺版面配置〕。

於是我再次詢問 Gemini 3。在 Gemini 的建議下，我改用以下這個 Prompt：

幫我規劃一個 3 天的東京旅遊行程，並用視覺化的方式呈現。

這次生成的結果，是一頁式網頁型態的資訊頁。往下捲動後，還可以看到一個互動式問卷，詢問你希望旅遊步調是緊湊還是慢活、感興趣的主題有哪些，並根據你的選擇，推薦該地區額外可體驗的項目。

在填寫並送出問卷後，系統會重新產生一份新的視覺化行程內容。

問題來了……

為什麼我的帳號只有〔動態檢視〕，而我同事的帳號只有〔視覺版面配置〕？

於是我再次詢問 Gemini 3，而它的回答是：

這是一個非常細膩的觀察！這主要是因為 Google 目前正在針對這兩項「實驗性功能」（Labs）進行 A/B 測試（A/B Testing） 或階段性推送。

簡單來說，Google 為了測試哪種呈現方式最受用戶歡迎，會隨機將不同的用戶分到不同的測試組別，因此會出現功能選單不一致的情況。

以下是這兩者之間的關鍵差異與原因分析：

為什麼功能不一樣？ 實驗性測試 (A/B Test)：Google 官方在發佈說明中提到，這兩項功能（視覺版面配置、動態檢視）是逐步推送給不同使用者群體的。有些帳號只會看到其中一種，有些則可能兩者都有，或甚至都沒有。

帳號與裝置限制：

動態檢視 (Dynamic View)：目前主要針對網頁版（Desktop）推送，且通常需要年滿18歲的個人帳號。

視覺版面配置 (Visual Layout)：目前在行動裝置（App）與網頁版上都有機會出現。

 

原來是 … 我成年了 …  (XD抓錯重點)

〔動態檢視〕、〔視覺版面配置〕目前是「實驗性功能」（Labs）正在進行 A/B 測試（就是「用真實使用者分組測試，選出最好的版本」）與分批隨機推送，導致不同帳號看到的功能不一致。

功能是否出現，與使用者分組、帳號條件，以及裝置平台（網頁或 App）皆有關，因此可能只看到其中一種、同時看到兩種，或完全未顯示。

如果你也感到好奇，不妨親自觀察看看自己的帳號目前出現的是哪一個功能。接下來我們談談這兩者的特色：

動態檢視（Dynamic View）

如果要用一句話形容它：它就像是一位「懂得寫程式的前端工程師」。

Google 的動態檢視（Dynamic View），允許使用者在搜尋結果中，直接看到可互動的「比較表」、「時間軸」或「地圖儀表板」。

這是一個非常關鍵的技術躍進，因為它引入了兩個重要概念：

l   Generative UI（生成式介面）

l   Agentic Coding（代理程式碼生成）

核心角色

建構者

在這個模式中，LLM 不再只是負責「寫文字」，而是扮演一個能夠即時建構 UI 的角色。

運作邏輯

1. 意圖判斷

模型會先判斷這個問題，適合用哪一種呈現形式，例如「表格」、「地圖」或「時間軸」。

2. 資料擷取

從搜尋到的非結構化文本中，精準提取出結構化資料（通常是 JSON）。

3. 元件生成

這是最關鍵的一步。

LLM 不再只是生成文章，而是即時撰寫程式碼（多半是前端框架的 Props，或是輕量級的 HTML / JavaScript），用來定義 UI 元件的結構與互動方式。

4. 用戶端渲染

瀏覽器接收到這段程式碼後，即時渲染出一個專屬於這個問題的微型 App。

技術本質

動態檢視 (Dynamic View) 的輸出結果是：

Structured Data + Logic（結構化資料 + 邏輯）

這代表 AI 已經開始理解「UI 與互動邏輯」，而不再只是處理文字內容。

視覺版面配置（Visual Layout）

如果用一句話形容它：它更像是一位由資料驅動的「雜誌編輯」。

當你搜尋「室內設計靈感」或「2025 流行穿搭」時，搜尋結果不再只是條列式文字，而是呈現為精美的格狀圖片牆，甚至包含自動播放的影片。

這正是視覺版面配置（Visual Layout）的典型應用。

技術定位

從技術角度來看，視覺版面配置（Visual Layout）並不算真正的 Generative AI。它更像是一個效率極高的「數位策展人」或「雜誌編輯」。

運作邏輯

l   搜尋引擎先透過 實體辨識（NER, Named Entity Recognition） 判斷查詢是否具有高度視覺需求。

l   接著，從檢索結果中擷取圖片、影片等 metadata。

l   最後，由 Layout Engine 將這些素材填入預先定義好的 Grid System 或 Masonry Layout 樣板中。

技術本質

Presentation Layer（表現層）的最佳化

視覺版面配置 （Visual Layout）讓資訊「變好看、好掃描」，但它不會創造新內容，也不涉及推理或決策行為。

Google 搜尋上的 AI 模式（AI Overview）

當我們把視角拉回簡博士所提到的「從搜尋引擎到 AI 代理」，我注意到新版 Google 搜尋介面中，多了一個 「AI 模式」。

那麼問題來了：這算是 Search Engine 的加強版？還是已經邁向Search Agent？

一句話形容它：基於檢索增強生成（RAG）的「研究助理」。

核心角色

閱讀者與寫作者（Reader & Writer）

技術架構

這是一個標準的 RAG（Retrieval-Augmented Generation） 架構：

1. Retrieve（檢索）
   系統先抓取 Top-N 個相關網頁。
2. Context Injection（脈絡注入）
   將這些網頁內容作為 Context Window，提供給 LLM。
3. Generate（生成）
   模型根據 Prompt（例如「請總結並附上來源」），生成一段自然語言摘要。

技術本質

AI 模式的輸出結果是：Unstructured Text（非結構化文字）

它確實能幫助使用者節省大量閱讀時間，但本質上仍然只是「資訊壓縮」：

• 它不進行運算
• 不具備互動能力
• 也無法主動執行任務

簡單的來說：

• 動態檢視：AI 開始「寫 UI 與邏輯」
• 視覺版面配置：搜尋結果的視覺化與排版升級
• AI 模式：AI 幫你「讀書與整理」

只有 動態檢視 (Dynamic View) ，真正跨進了 Agentic Coding 的領域。

什麼才是真正的 Search Agent？

一開始，我以為「動態檢視（Dynamic View）」已經符合 Search Agent 的定義。但再進一步詢問 Gemini 之後才發現，它其實只是非常接近 Search Agent，卻仍未真正跨過那條界線。

Gemini 的說法是：

「動態檢視（Dynamic View）並不完全等同於一般定義中的 Search Agent，
但它確實運用了 Agentic Coding 的技術。」

換句話說，〔動態檢視〕更像是：
「會寫程式的 UI 設計師」，而不是「會替你跑完整流程的代理人」。

關鍵差異在於：Agentic Coding ≠ Agent

〔動態檢視〕使用了 Agentic Coding Capabilities（代理式程式碼生成能力）。
這代表系統背後，確實存在一個「能自主寫程式碼的 Agent」。

當你輸入問題時，這個 Agent 會自行判斷：

• 這個問題適合用「表格」呈現，還是「地圖」？
• 需要哪些欄位？
• UI 的互動方式應該如何設計？

然後，它會即時產生對應的 UI 程式碼。

但重點在於：它只負責「生成」，不負責「完成任務」。

 

那麼，〔動態檢視〕距離真正的 Search Agent，還差在哪裡？

在 AI Engineering 的嚴格定義中（可參考 LangChain、AutoGPT 等架構），
一個真正的 Agent，必須同時具備 3A 循環，缺一不可。

3A 循環：Agent 的最低門檻

1.           Autonomy & Planning（自主性與規劃能力）

目前多數 AI 功能仍然是被動回應式的：

你問，它答

你停，它就停

〔動態檢視〕也是如此。下圖是對照說明

 

差異在於：是否能「自行拆解並規劃步驟」

2.           Tool Use（工具使用能力）

Agent 必須具備與外部世界互動的「手腳」。這通常透過以下方式實現：

Function Calling

Headless Browser（如 Puppeteer / Playwright）

API 操作（訂房、付款、行事曆）

〔動態檢視〕的能力，止步於「產生 UI」：

它能顯示資訊

但無法點擊按鈕

也無法填寫表單或完成付款

能看 ≠ 能做

3.           Reasoning Loop（推理與修正循環）

這是 Agent 與「聰明工具」之間最本質的差異。真正的 Agent 必須具備 ReAct 迴圈：

Observation（觀察） → Thought（思考） → Action（行動） → 再次觀察

結語：給開發者的啟示－Web 的未來在哪裡？

【動態檢視】揭示了生成式 UI（Generative UI）的新方向：App 介面將不再固定，而是由 AI 依據使用者意圖即時構建最適合的 UI 元件，對前端架構的靈活性提出前所未有的挑戰。

 

我們正處於搜尋引擎歷史上最激動⼈⼼的時刻。

·         AI 模式 （AI Overview） 幫我們讀書。

·         動態檢視（Dynamic View ）幫我們造工具。

·         而未來的 Search Agent，將幫我們把事情做完。

簡博士在影片中指出，這項技術將大幅的改變商業模式。過去，商品的曝光依賴搜尋、廣告與點擊率；然而，在 AI Agent 模式下，未來商品如何被 AI（Search Agent）看見，甚至由其代理完成下單，將成為全新的挑戰。

這一轉變意味著電子商務正醞釀一場革命，而這場革命與 Search Agent 的發展息息相關。對開發者與商業營運者而言，洞察並掌握這個問題的解方，似乎是下一階段的關鍵任務。

簡博士給我們的功課很明確：開始使用 AI。

他並謙虛地分享，自己的講章正是與 AI 對話、協作產出的成果。

這篇文章是我聽完演講後完成的作業。我使用 Google Gemini 提問並整理對話內容，導入 NotebookLM，在過程中多次提煉與匯入、匯出，並透過 ChatGPT 驗證與反覆檢視、Microsoft 365 協助編輯及潤稿。

若您對於學習 Google AI 生態系有更多的興趣，歡迎參考以下課程可以了解更多的技巧喔！您可在下列課程中了解更多技巧喔！


相關學習資源︰

【AIGVC-AI】Vibe Coding：Google Gemini 3雲端Vibe Coding實戰

【AIGNM-AI】善用Google NotebookLM實現高效學習