Google Opal 從期待到失望

#ai #security #kubernetes #googlecloud

Google Opal 從期待到失望

Google Opal

前陣子 Google Labs 推出的 Opal 引起了不小的轟動，號稱終結「Vibe Coding」，只要用自然語言描述，就能生成一個完整的應用程式或是自動化AI流程，抱著極高的期待去測試，想看看它是否能取代我手邊那些 Python Script 或 Make Workflow。

原先我是有一個懶人記帳方法，由於現在大多是電子付費，因此我會固定的把信用卡電子帳單從gmail搬到Gdrive上，然後再叫LLM幫我分析與記帳，順便給我一些節流建議。

1. Expectation vs. Reality

天真的我嘗試了一個非常經典、也覺得是 Google 生態系理應最擅長的場景：「智慧郵件自動化助手」。

理論上，Google 擁有 Gmail API、Vertex AI (Gemini 模型) 和強大的 Cloud 架構，這應該是「自家後院」最容易實現的功能。

Opal 的回應 (Error)：

“This application requires tools that are not supported.”
系統甚至厚臉皮地建議我： “Feel free to try this instead: ‘An app that takes user-provided email content (e.g., copied and pasted email text) as input…’”

目前支援的Input大多都還是停留在文字匡的輸入，可以串接的工具也是少之又少…

2. 為什麼 Opal 會讓人失望？

為什麼一個 Google 的工具，卻連讀取 Google 的 Gmail 都做不到？

A. 沙盒困境 (The Sandbox Dilemma)

Opal 目前的架構設計是 “Stateless Generative UI” (無狀態生成式介面)。它生成的 App 運行在一個高度封閉的沙盒環境中。

沒有 OAuth 授權機制： 真實的郵件處理需要使用者授權 (OAuth 2.0) 存取 Gmail，而Opal 目前似乎沒有內建這種「代表使用者身分 (On-behalf-of flow)」的授權模組。
缺乏 Function Calling (工具呼叫)： 現代的 AI Agent (如 LangChain 或 Vertex AI Agent) 核心在於 Function Calling — — 模型判斷需要資料時，會去呼叫外部 API，Opal 目前的「工具」僅限於它內建的幾個簡單功能，它無法「掛載」外部或 Google 內部的 API。