Google Cloud AI Live + Labs 2026 活動心得：Agent 要從 POC 走到 Production

2026 年 10 月 20 日，我去參加了 Google Cloud AI Live + Labs。主題圍繞在 AI Agent、Agentic Workplace、Google ADK（Agent Development Kit）、Multi-Agent 架構與 Agent Governance（治理）。

先說明一下這篇的性質：內容依我的現場筆記整理，部分產品名稱、版本與展示功能我還沒有獨立查證，會在文中標註「待查證」。文中的架構範例與 POC 建議，是我自己延伸的研究方向，不是主辦單位實際展示的內容。

這場活動在談什麼

一句話：AI Agent 怎麼從 Demo 變成能在正式環境長期運作的企業級系統。

過去生成式 AI 多半用在對話、摘要、內容生成與程式碼輔助。Agentic AI 則更進一步，能使用工具、存取資料、協調流程，甚至和其他 Agent 分工。Google 台灣總經理在開場丟了一句話：

How is AI driving ROI? In One Word: Agents

企業關心的重點，已經從模型本身有多強，轉向 AI 能不能真的把工作做完、提升生產力，並且算得出投資報酬。

我把整天聽下來的觀察歸成五件事：

1. Agentic Workplace：AI 從被動回答的助理，變成工作流程裡的數位協作者。
2. Multi-Agent 架構：靠專業分工與不同模型的成本差異，改善品質與 Token 效率。
3. Workflow Engineering：把 Agent 的推理能力，和可控制、可重複的流程結合。
4. Agent Governance：身分、權限、安全、監控與生命週期的管理。
5. Production Readiness：不只做出 Demo，還要長期、安全、穩定、划得來。

整場下來，我覺得核心問題是：怎麼建出品質夠好、成本可控、而且能持續管理的 Agent 系統？

Agent 的四個核心支柱

活動提出 Four Pillars of an Agent：

支柱	概念	作用
Reasoning Core	推理核心	理解任務、分析問題、決定下一步
Memory Layer	記憶層	管理對話、任務狀態與上下文
Tool Integrations	工具整合	連接外部服務、資料與應用程式
Harness	執行與控制框架	協調執行、工具使用與系統行為

Harness 被稱為 Critical Layer。我的理解是，它就是包住模型、工具與流程的那層控制機制，工具呼叫、狀態、錯誤處理、權限與可觀測性都歸它管。不過這是我的延伸理解，筆記裡沒有記下講者對 Harness 的具體定義。

另外要留意工具整合的另一面：Agent 能接 API、資料庫、MCP 和其他 Agent，同時也帶來權限過大、資料外洩、惡意輸入與未授權操作的風險。

從 Conversational AI 到 Agentic Workplace

William 分享的主題是 The Next Wave of Growth: Agentic Work，關鍵字是 AI as a Coworker。以前是我問、模型答；之後是 AI 參與工作流程，講者提到 Autonomy（自主性）、Identity（身分）、工具整合與個人化上下文。

• Skills：可重複使用的指令、知識與工作流程。
• Tools：讓 Agent 接上員工既有的工具與企業環境，連帶要處理身分驗證與資料權限。
• Contextual AI：筆記只寫了「個人化、持續學習」。但上下文更新、記憶更新與模型訓練是三件不同的事，現場沒有聽出講者指哪一種。

Gemini Agent 的展示

Eson 示範了長時間任務、Project 檔案管理、工具整合、內建 Skills，還可以展開 Thinking 看推理內容。我筆記上留了個問號「可以寫程式？」，還沒實測。

另外幾個我有記下、但都還要查證的東西：

• Dream Mode：我的第一印象有點像 Codex 的背景學習機制，但正式名稱、功能與運作方式不確定。
• Gemini for Customer Service：語音客服，包含即時對話與台灣國語的語音表現。
• Knowledge Catalog：現場的描述是 The unified context layer behind data accuracy。
• 「Gemini 4 Argon」：筆記多次出現這個名字，但正確的產品名稱與版本待查證，先不下結論。

工作坊一：Google ADK

像 n8n，但不一樣

工作坊的流程與圖形化展示，讓我第一個聯想到 n8n：都有節點、任務、流程與外部工具串接。差別在 ADK 是用程式來建立、組合與管理 Agent，走模組化、可重複使用的路線。

LlmAgent 與 Workflow Agent

這是我覺得整個工作坊最值得記的一張表：

ADK 元件	自身是否需要 LLM 推理	用途
LlmAgent	是	理解任務、推理、選擇工具
SequentialAgent	否	依序執行子 Agent
ParallelAgent	否	平行執行子 Agent
LoopAgent	否	重複執行子 Agent

Workflow Agent 本身不需要 LLM 推理，但它底下的子 Agent 仍可能用 LLM。也就是說，ADK 裡的 Agent 是「架構元件」，不是每一個都有自主決策能力。需要判斷的交給 LlmAgent，順序明確的交給 Workflow Agent。

開發與部署工具

• ADK Web：本機開發與測試 UI，可以檢查工具呼叫、結果與 Console 資訊。
• Agent CLI：筆記記的是可用於部署與切換部署環境。
• Cloud Shell：工作坊裡安裝與操作工具用的雲端終端。
• Agent Runtime：後端執行環境，可再研究容器化與 Console 管理。

幾個省錢的做法

• ModelConsult Tool：現場提到讓模型之間互相呼叫、分工以節省 Token。概念上是主 Agent 接任務，挑其他模型處理子工作再整合。正式名稱、機制與支援版本待查證。
• Skills Lifecycle：長任務不要一次載入所有技能，按需載入，避免上下文過長。

版本方面，筆記寫著「ADK v2.11，不要用 v1」。但我沒記下套件名稱、完整版本與原因，所以只當作現場紀錄，不當成確認過的版本建議。

工作坊二：從 POC 到 Production

這堂我覺得最有共鳴。講者拋出三個把 POC 推向正式環境的挑戰：

1. 工具與存取驗證：Agent 代表誰使用工具？能不能寫入、刪除、修改？
2. Agent Evaluation：我的筆記形容它是「黑魔法」，因為很難像傳統程式那樣，用固定輸入對固定輸出來驗證。
3. Agent Management：Agent 一多，身分、版本、權限與生命週期全部變成管理問題。

兩個口號式的轉變也很好記：

• Monoliths → Mesh：從單一集中式系統，走向網狀的 Agents。職責會更清楚，但協作、權限、追蹤、錯誤歸因、成本與維護也都跟著變重。
• YOLO → Workflows：正式環境不能只靠 Agent 自由發揮，需要 Safety、Legal Compliance 與 Human-in-the-Loop（HITL，人工介入）。查資料可以自動，刪資料、動到金額這類敏感操作，值得加人工確認。

重點是把自主推理，放進可控制的流程裡。

Agent Governance：我覺得最有分量的一段

講者點出 Agent 可能碰到的問題：資料暴露、權限過大、工具呼叫被惡意輸入影響、操作難以追蹤，以及異常 Agent 沒辦法即時停下來。治理分成三個面向：

Visibility（可視性）

• Universal Discovery：集中發現與管理 Agent
• Lifecycle Visibility：觀察使用狀況與生命週期
• Observability：追蹤 Token、工具呼叫、結果與錯誤

要能回答：成本或執行異常時，追得到是哪個 Agent、哪個任務、哪位使用者、哪個工具嗎？

Control（控制）

• Identity、Lifecycle Management、Compliance
• 要分清楚使用者本人的權限，和 Agent 執行時用的權限；Agent 可能代表使用者，也可能有獨立的服務身分。

Security（安全）

• Network and Policy、Threat Detection、Payload Monitoring
• Stopping a Rogue Agent：不只預防，過程中還要能偵測異常、限縮權限或直接中止。

活動提到的相關元件，我整理成對照表：

治理需求	活動提及的元件	我想研究的重點
資源管理	Agent Registry	發現、註冊、版本、政策套用
身分授權	Agent Identity、IAM、Auth Manager	身分、權限、委派
政策控制	Agent Gateway（IAM Policy、Semantic Policy Engine）	統一存取與政策
品質安全評估	Evaluations	測試與風險檢驗
內容防護	Model Armor	有害內容與安全檢查
執行環境	Agent Runtime	部署與執行管理

舉個講者的例子：建一個查 BigQuery 資料表的 Agent，只允許特定使用者操作，而且不同使用者能呼叫的委派工具也不同。最後要能回答那句話：到底是誰，透過哪個 Agent，對哪個資源，做了什麼操作？

兩個要查證的點：Semantic Policy Engine（用自然語言設政策）如何轉成可執行規則、有什麼限制；Model Armor 在輸入、輸出與工具呼叫各階段怎麼整合。筆記裡還用「地板測試」形容 Model Armor，意思是基本的安全檢驗，不是萬靈丹。

我自己的心得

不是每一步都需要 LLM

看完 ADK 的 Workflow Agent，我最大的感想是 n8n 的文藝復興：Agent 替流程加上了推理能力，但不是所有步驟都該交給 LLM。步驟明確的就維持固定、可驗證的程式邏輯，有不確定性、需要判斷的地方，再讓 LlmAgent 上場。

Token 成本的四個面向

1. 模型分工：不同複雜度的任務，用不同成本的模型。
2. 上下文管理：Skills Lifecycle、記憶與資料預處理。
3. 可觀測性與成本歸因：追蹤 Token、工具呼叫與流程成本。
4. 預先測試：靠評估減少錯誤執行、重試與不必要的複雜度。

成本不能只看單次 Token 單價，要看整個任務的總成本與品質。

警報、防禦、止損

單一 POC 看不出來，但多 Agent 系統必須及早想清楚：哪個 Agent 出錯、哪個工具造成異常、Token 有沒有爆量、有沒有權限違規、能不能立刻中止。

IAM 不要最後才補

只要 Agent 牽涉多位使用者、多個部門、不同資料層級，身分與權限就該在架構設計初期納入，不是上線前才補。

不用 Google Cloud 也能借用這些想法

我參加這場活動的目的之一，是想知道：就算不用 Google Cloud 的服務，能不能參考背後的架構理念，自己搭 Agent 系統。我把能力拆成幾塊：

能力	自行研究的方向
Agent Framework	Agent 定義、工具呼叫、工作流程
Runtime	任務實際執行環境
Tool Integration	API、資料庫、MCP
Registry	Agent、Skills、工具管理
Identity	身分驗證、權限控制
Gateway	工具政策、流量與限制
Observability	執行紀錄、Token、成本與歸因
Evaluation	品質、安全、任務完成檢驗
Workflow	固定流程、人工審核

這只是能力拆解，不代表每個 Google Cloud 服務都有完全等價的開源替代品。

最簡化的架構大概長這樣：

使用者
  ↓
任務入口
  ↓
主 Agent／Workflow
  ↓
Sub-Agent／Tools
  ↓
執行結果

橫向再加上身分權限、任務紀錄、Token 用量、錯誤處理、測試評估與人工確認。起步時先確認每個元件是不是真的需要，再逐步擴張。

接下來我打算優先驗證的 POC（都是我自己的規劃）：

• POC A：Multi-Agent 與模型分工，比較單一模型與多模型在 Token、品質、時間上的差異。
• POC B：Workflow Agent，比較固定流程與 LLM 自主決策各適合哪些任務。
• POC C：Skills Lifecycle，驗證按需載入對上下文與成本的幫助。
• POC D：Observability，記錄工具呼叫、Token、時間、錯誤與結果。
• POC E：Governance，做一個簡化的使用者、Agent、工具存取限制。

待查證清單

• ADK 工作坊使用的版本與建議版本（含「v2.11，不要用 v1」的原因）
• ModelConsult Tool 的正式名稱與功能
• 「Gemini 4 Argon」、Dream Mode、Knowledge Catalog 的正式資訊
• ADK Agent 與 Gemini App 的整合方式
• Semantic Policy Engine 的政策能力
• Gemini、Claude、Codex 在長時間任務上的比較
• ADK 與 n8n 的維護成本差異

參考資料

• CloudMile：Google Agent Development Kit（ADK）多代理架構與 Travel Concierge 應用案例

結語

這場活動給我最大的收穫，不是多認識幾個 Google Cloud 產品，而是重新想了一遍 AI Agent 的軟體工程。

Agent 不只是替 LLM 加幾個工具。一旦它參與企業流程、跟其他 Agent 協作，就得面對架構、分工、身分驗證、權限、安全、測試、可觀測性、部署與維運，外加一個新的成本變數：Token。

所以要先分清楚哪些工作用固定 Workflow、哪些才需要 LLM 推理，再把 LLM、Workflow、Skills、Tools、Runtime 與 Governance 組成一套能持續管理的系統。

最後的目標很樸實：品質要好，又不能花太多錢。