前情提要：從單機原型到雲端生產級 AI Agent 的五階段演進 歡迎來到《Agent Platform 實戰》系列的第六篇（最終章）！回顧過去五篇文章，我們帶著 LINE AI 名片王 (kkdai/line-card-assistant) 一路闖關，完成了從本地原型到企業級 AI Agent 架構的四大階段： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：以 google.golang.org/adk/v2/workflow 實作涵蓋 Vision OCR、AddFanOut / AddFanIn 平行背景調查與 NewRequestInputEvent HITL 互動迴圈的名片工作流圖。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王：完成 Phase 1（PR #10），將專案標準化為 agents-cli (adk_go) 雙通道架構，同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定。 [Agent Platform 實戰 (3)] 破解無狀態容器的 HITL 失憶症：用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），導入 artifact/gcsartifact 與 session/vertexai 解決無狀態容器的跨實例 HITL 恢復與圖片儲存問題。 [Agent Platform 實戰 (4)] 邁向雲端雙層解耦與全持久化：用 Cloud Run LINE Webhook Gateway、Agent Runtime 與 Cloud SQL PostgreSQL 完成 LINE AI 名片王架構拼圖：完成 Phase 2 後半（Issue #5） 與 Phase 3（Issue #6，PR #12），將名片庫遷移至 Cloud SQL PostgreSQL (PostgresStore)，並打造無狀態的 Cloud Run LINE Webhook Gateway (internal/gateway)。 [Agent Platform 實戰 (5)] 打造 AI Agent 的品質飛輪 (Quality Flywheel)：用 agents-cli...

前情提要 在《Agent Platform 實戰》系列的前四篇文章中，我們一步步將 LINE AI 名片王 (line-card-assistant) 從單機原型推進為雲端原生、雙層解耦的 Google Cloud Agent Platform 架構： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：使用 google.golang.org/adk/v2/workflow 打造 12 個節點的名片處理圖（Graph Workflow），涵蓋 Vision OCR、AddFanOut / AddFanIn 平行背景調查，以及 NewRequestInputEvent 的 HITL（Human-in-the-Loop）暫停與修改迴圈。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王：完成 Phase 1（PR #10），導入 agents-cli (adk_go) 標準雙通道架構，同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定。 [Agent Platform 實戰 (3)] 破解無狀態容器的 HITL 失憶症：用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），用 artifact/gcsartifact 與 session/vertexai 讓無狀態容器支援跨實例 HITL 暫停與恢復。 [Agent Platform 實戰 (4)] 邁向雲端雙層解耦與全持久化：用 Cloud Run LINE Webhook Gateway、Agent Runtime 與 Cloud SQL PostgreSQL 完成 LINE AI 名片王架構拼圖：完成 Phase 2 後半（Issue #5） 與 Phase 3（Issue #6，PR #12），將名片庫遷移至 Cloud SQL PostgreSQL (PostgresStore)，並實作無狀態的 Cloud Run LINE Webhook Gateway (gateway.Client)。 當架構與功能都到位、準備正式將 Agent 部署上雲端生產環境（Phase 5）之前，所有 AI 工程團隊都會面臨一個最核心的靈魂拷問： 「當我們修改了一行 Prompt、調整了一個 Graph...

前情提要 在《Agent Platform 實戰》系列的前三篇文章中，我們一步步將 LINE AI 名片王 (line-card-assistant) 從概念原型推向雲端原生架構： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：我們用 google.golang.org/adk/v2/workflow 打造了 12 個節點的名片處理圖（Graph Workflow），涵蓋 Vision OCR、AddFanOut / AddFanIn 平行背景調查，以及 NewRequestInputEvent 的 HITL（Human-in-the-Loop）暫停與修改迴圈。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王：完成 Phase 1（PR #10），導入 agents-cli (adk_go) 標準雙通道架構，讓專案同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定。 [Agent Platform 實戰 (3)] 破解無狀態容器的 HITL 失憶症：用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），用 artifact/gcsartifact 將幾 MB 的名片照片移出 Session.State，並結合 session/vertexai 實作 resolvePendingHITL，讓無狀態容器即使縮容至 0 或切換實例，也能無縫接續 HITL 修改與確認存檔。 今天這篇系列文的第四集，我們要一口氣完成 Phase 2 最後一塊拼圖（Issue #5） 與 Phase 3 核心架構升級（Issue #6）（對應 PR #12）： 雲端名片資料庫持久化（PostgresStore / Cloud SQL）：將原本存在本地記憶體或容器暫存檔的名片庫，正式升級為支援 Cloud SQL PostgreSQL 的關聯式與 JSON 混合儲存，並打通 HybridSearch 與 Token 計分容錯的 BroadSearch。 雙層解耦呼叫架構（Cloud Run LINE Webhook Gateway $\rightarrow$ Agent Runtime）：將負責「LINE 驗章與圖片下載」的輕量邊緣層（Edge Layer），與負責「ADK 2.0 Graph Workflow 多模態推論與搜尋」的執行層（Execution Layer）徹底解耦！ 一、為什麼我們需要「雲端持久化鐵三角」與「雙層解耦架構」？ 當我們把 line-card-assistant 部署到...

前情提要 在前兩篇系列文章中： 《[Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王》：我們用 google.golang.org/adk/v2/workflow 實作了包含 Deterministic Router、AddFanOut / AddFanIn 三路平行背景調查，以及 NewRequestInputEvent Human-in-the-Loop (HITL) 暫停與迴圈修正 的 12 節點名片助理。 《[Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王》：我們導讀了 agents-cli 官方開發生命週期，解答了 Agent Runtime 的 Scale-to-Zero 機制，並完成 Phase 1（PR #10），將專案改造為同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定的 adk_go 標準雙通道架構。 進入 Phase 2（Issue #3 & Issue #4），我們要面對把這套系統推向生產環境（Cloud Run / Agent Runtime 自動擴縮容叢集）時最經典、也最容易踩坑的分散式系統難題：當容器隨時會 Scale to Zero 或負載平衡到不同實例時，多模態名片照片（Binary Image）該放哪裡？正在等待使用者按按鈕的 HITL 暫停狀態又該如何跨實例恢復？ 這篇系列文的第三集，就帶大家深入拆解我們在 PR #11 中如何用 ADK Go v2.6.0 的 artifact/gcsartifact (GCS Artifact Service) 與 session/vertexai (Agent Platform Sessions) 徹底治好無狀態容器的「HITL 失憶症」！ 一、為什麼原本的 HITL 在雲端多實例環境會「失憶」與「爆肥」？ 在單機或單一 Container 實例開發時，把所有東西塞進記憶體都跑得飛快；但一旦部署到會自動水平擴縮（Horizontal Auto-scaling）或縮容至 0（Scale-to-Zero）的 Google Cloud Run 或 Vertex AI Agent Runtime，原本第一版的設計就會馬上撞上兩座高牆： 痛點 1：把幾 MB 的名片照片 []byte 塞進 Session.State 的「狀態爆肥」反模式 在第一版中，當 LINE 使用者傳來一張高解析度名片照片時，我們是直接把下載下來的 imageBytes []byte 放進 ADK 的 Session.State["image_bytes"]： // ❌ 第一版作法：直接把幾 MB 的原始圖片 []byte 塞進 Session...

前情提要 在上一篇文章《[Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王》中，我們用 Golang (google.golang.org/adk/v2/workflow) 與 LINE Messaging API SDK v8 從零打造了 line-card-assistant（LINE AI 名片王），把 ADK 2.0 Graph Workflow 的四大核心能力 —— Deterministic Router 確定性路由、AddFanOut / AddFanIn 平行背景調查與匯聚、以及 NewRequestInputEvent Human-in-the-Loop (HITL) 暫停與迴圈修正 —— 完整跑通並部署到了 Google Cloud Run。 不過，當我們把這個單體式（Monolithic）的 LINE Bot 推上雲端後，若要進一步往企業級 AI Agent 平台（Production-grade Agent Platform）演進，馬上就會遇到幾個架構層級的叩問： 跨實例的 HITL Session 狀態保存在哪裡？ 在第一版中，我們使用 session.InMemoryService() 搭配本地 SQLite。當 Cloud Run 因為流量擴縮（Auto-scaling）或重新部署而切換 Container 實例時，正在等待使用者按下「✅ 確認儲存」的 HITL 暫停狀態（Checkpoint）就會因為記憶體重置而消失。 如何讓這個名片 Agent 被其他 Agent 呼叫（Agent-to-Agent, A2A）？ 如果公司內部還有另一個「CRM 業務助理 Agent」或「行事曆排程 Agent」，希望能直接透過標準 A2A 協定 查詢我們名片王裡的聯絡人或請它代寫破冰信，綁死在 LINE Webhook /webhook 入口的單體伺服器是無法直接對外提供標準 Agent 介面的。 如何有系統地評估（Evaluate）與觀測（Observe）整張 Graph？ 改了一行 Prompt 或調整了一個節點後，要怎麼確保 OCR 準確率、Fan-Out 平行工具呼叫軌跡（Tool Trajectory）與搜尋品質沒有退化？ 為了解決從「寫出一個 Agent 原型」到「上線維運企業級 Agent」的鴻溝，Google 官方推出了全新的命令列與技能工具組 —— agents-cli (Google Agents CLI)，作為 Google Cloud Agent Platform（現整合為 Gemini Enterprise Agent Platform） 的統一開發入口。 這篇系列文的第二集，我們就來深入導讀 agents-cli 官方開發指南，解答大家最常問的 Agent Runtime 擴縮容（Scale-to-Zero）與計費機制，並帶大家一步步看我們如何完成 Phase 1 架構升級（PR #10）：在不破壞原本 LINE Bot 功能的前提下，將專案重構為符合 adk_go + agent_runtime 規範的雙通道架構！ 一、深入解析 Google Cloud Agent Platform 與 agents-cli 官方指南 在動手改程式碼之前，我們先透過 Google 官方的《Getting...

前情提要 在過去一年多的 AI Agent 開發熱潮中，許多開發者第一個寫出來的 Agent 往往長這樣：寫一段超長的 System Instruction，再把五、六個 Tools 全部塞給同一個 LLMAgent，然後祈禱模型能夠乖乖照著步驟 A → B → C → D 執行。 一開始做 Demo 很驚艷，但只要一上生產環境，問題馬上浮現： 步驟越多、失控率越高：當 Prompt 裡塞滿了「先做 OCR、再去查資料庫有沒有重複、同時上網查這家公司在做什麼、然後組出預覽卡片問使用者、如果使用者說要改職稱就重新產生預覽、確認後才能寫入 DB 並寫一封破冰信」，模型偶爾就會跳過查重、或是還沒等使用者確認就直接寫入資料庫。 不該花 Token 的地方也在燒錢與等待：像是「依據 LINE 事件種類分流」或「正規化電話號碼格式」這種 100% 確定性的邏輯，交給 LLM 判斷不僅慢，還可能出錯。 獨立任務被迫排隊執行：查資料庫、Google 搜尋公司背景、比對近期對話紀錄明明互不相干，卻因為單一 Agent 的線性對話迴圈而變成循序等待。 為了解決這個痛點，Google 在 Agent Development Kit (ADK) 2.0 正式引入了重磅功能 —— Graph Workflows（圖形工作流），並且同步支援 Python 與 Go (google.golang.org/adk/v2/workflow)！ 看到這個更新後，我立刻決定用最熟悉的 Golang + LINE Messaging API SDK v8 實際打造一個完整的開源專案 line-card-assistant（LINE AI 名片王），把 ADK 2.0 Graph Workflow 的所有核心武器（AddRoute 條件路由、AddFanOut / AddFanIn 平行處理與匯聚、NewRequestInputEvent Human-in-the-Loop 暫停等待與迴圈修正）全部實戰跑過一遍，並部署上 Google Cloud Run。 這篇文章會先帶大家導讀 Google 官方針對 ADK Graph Workflows 必讀的兩篇核心技術文件，接著一步步拆解我們如何用 Go 程式碼將這些圖形工作流模式落地到 LINE Bot 中！ 一、Google 官方怎麼定義 Graph Workflow？兩篇必讀指南解析 在開始看程式碼之前，強烈建議大家先理解 ADK 團隊設計 Graph Workflows 的核心哲學。Google 官方在近期發布了兩份非常關鍵的開發者指南： Google Cloud 官方部落格：Graph Workflows in ADK: Everything You Need to Know（由 ADK 團隊的 Annie Wang 與 Shangjie Chen 撰寫） ADK 官方技術文件：Graph-based agent workflows (adk.dev/graphs) 我們把這兩篇官方文章的精華濃縮整理如下： 1. 什麼是「Graph Engineering（圖形工程）」？ 在《Graph Workflows in ADK: Everything You Need to Know》一文中，作者以一個「客服退費審核流程（Customer Refund Workflow）」為例，點出了一個核心觀念： 當工作流程變複雜時，可靠性來自於將「工作流控制權（Workflow Control）」與「模型推理（Model Reasoning）」分離。 Graph Engineering...