參考文章： Gemini API - Function Calling with Multimodal GitHub: linebot-gemini-multimodel-funcal Vertex AI - Multimodal Function Response 完整程式碼 GitHub 前情提要 相信很多人都用過 LINE Bot + Function Calling 的組合。當用戶問「我上個月買了什麼衣服？」時，Bot 呼叫資料庫查詢函式，取回訂單資料，然後 Gemini 根據那份 JSON 回答： 開發者設計的傳統流程： 用戶: "幫我看看我之前買過的那件外套" Bot: [呼叫 get_order_history()] 函式回傳: {"product_name": "棕色飛行員外套", "order_date": "2026-01-15", ...} Gemini: "您在 1 月 15 日購買了棕色飛行員外套，金額 NT$1,890。" 回答完全正確，但總覺得少了什麼——用戶說的是「那件外套」，Gemini 只是轉述 JSON 裡的文字，完全沒有辦法「確認」那件衣服長什麼樣子。如果資料庫裡剛好有三件外套，AI 根本無法判斷哪件才是用戶記憶中的那件。 AI 能讀懂文字，但看不到圖片——這個限制在傳統 Function Calling 架構下一直是死角。 直到 Gemini 推出了 Multimodal Function Response，這個問題才被真正解決。 什麼是 Multimodal Function Response？ 傳統的 Function Calling 流程是這樣的： [用戶訊息] → Gemini → [function_call] → [執行函式] → [回傳 JSON] → Gemini → [文字回答] Multimodal Function Response 改變了中間那一步。函式不只能回傳 JSON，還能在同一個回應中夾帶圖片（JPEG/PNG/WebP）或文件（PDF）： [用戶訊息] → Gemini → [function_call] → [執行函式] → [回傳 JSON + 圖片 bytes] → Gemini → [看過圖片的文字回答] Gemini 在下一輪生成回答時，能同時「看到」函式回傳的結構化資料和圖片，從而生成更豐富、更精準的回應。 官方目前支援的媒體格式： 類別 支援格式 圖片 image/jpeg, image/png, image/webp 文件 application/pdf, text/plain 這個功能的應用場景非常廣泛：電商客服（辨識商品圖片）、醫療諮詢（分析檢驗報告 PDF）、設計評審（看截圖給建議）……幾乎所有需要「函式回傳視覺資料給 AI 分析」的場景都適用。 專案目標 這次我用 Multimodal Function Response 打造了一個 LINE 電商客服機器人，示範以下場景： 用戶：「幫我看看我之前買過的那件外套」 Bot（傳統）：「您購買了棕色飛行員外套。」 Bot（Multimodal）：「從照片中可以看到這是一件棕色飛行員外套，輕量尼龍材質，側邊有金屬拉鏈裝飾口袋。這是您 1 月 15 日的訂單 ORD-2026-0115，共 NT$1,890，已送達。」+ 商品照片 差別顯而易見：Gemini 真的「看了」那件衣服，而不只是轉述資料庫裡的文字。 架構設計 為什麼不用 Google ADK？...

參考文章： Introducing the Developer Knowledge API and MCP server Google Knowledge MCP Server Developer Knowledge API Corpus Reference 前情提要 還記得上週我用 Gemini CLI 寫 Gemini API 整合時，它信心滿滿地告訴我：「這個 API 參數是這樣用的」。結果執行後噴了一堆錯誤，原來 Google 三個月前就改了 API 格式。這不是 AI 的錯，它的訓練資料截止日期就在那裡，面對日新月異的技術文件，再強的模型也會「過時」。 過去我們遇到的典型場景： 開發者: "Gemini，幫我寫一個 Gemini Function Calling 的範例" AI: "好的，你可以這樣寫..." [產生基於 2024 年 6 月文件的程式碼] 開發者: [複製貼上，執行] 終端機: ❌ Error: Parameter 'tools' format has changed in v2 開發者: 😤 "又要去翻官網文件了..." （以上就是一個範例， LLM 不清楚的部分只能去找網路。但是卻不能保證答案一定是正確且最新的用法） 這樣的循環你是不是很熟悉？即便是 Gemini 1.5 Pro，有時也會因為自己的 API 更新太快而給出舊版建議。AI 的知識是靜態的，但技術文件是動態的，這個矛盾一直困擾著我們。 為了徹底解決這個問題，Google 在 2025 年初釋出了兩大殺手級工具： Developer Knowledge API - 機器可讀的官方文件 API Knowledge MCP Server - 基於 Model Context Protocol 的即時文件查詢服務 這意味著你的 AI 助手現在不再只是「憑記憶」寫程式，而是可以在需要時主動「翻閱最新官方文件」，成為一個真正擁有官方掛保證、永不過時的開發專家。 什麼是 Developer Knowledge API？ 過去 AI 學習文件的方式：網頁爬蟲的困境 傳統上，AI 模型是透過爬蟲抓取網頁來學習文件的。但這種方式有幾個致命問題： ❌ 雜訊干擾 <!-- AI 看到的實際內容 --> <nav>...</nav> <!-- 導覽列 --> <ad>...</ad> <!-- 廣告 --> <cookie-banner>...</cookie-banner> <!-- Cookie 提示 --> <div class="content"> <!-- 真正的文件內容只佔 30% --> 這是 Gemini API 的使用方式... </div> <footer>...</footer> <!-- 頁尾 --> AI 必須從這堆 HTML 中「猜測」哪些才是真正的文件內容。 ❌ 格式不一致 有些用 <code> 標籤，有些用 <pre> 有些用 Markdown...

s 前情提要 昨天參加了 Google 舉辦的開發者尾牙聚會（Google Developer Year-end 2025），也順便參觀了 Google 板橋辦公室。很開心能以 LINE Taiwan Developer Relations 的身份，跟大家分享我在 2025 年一整年觀察到的 Gemini 技術演進心得。 在熱門動畫《葬送的芙莉蓮》中，我很喜歡一級魔法使測驗篇的角色「尤蓓爾」。她有一個獨特的能力概念：「只要能想像切得開，就一定能切得開」。 這句話完美呼應了現在的 AI 時代——想像力與理解力變得比以往更加重要。如何「精準地想像出解決問題的方式」，成為了讓 AI 能精準協助你的關鍵。這篇文章將整理當天分享的 Gemini 2025 重點功能，以及我對「軟體工程師」在 AI 浪潮下核心能力的看法。 ### 2025 Gemini 功能演進回顧 回顧 2025 年，Gemini 與 LINE Bot 的結合在多個時間點都有突破性的更新。以下是重新審視這一年來的技術節點： 時間點 功能更新 說明 2025.04 Google ADK Agent 與 Messaging API 的初步結合，展示了天氣查詢等基礎 Agent 應用。 2025.06 Gemini CLI 開發者體驗大升級，直接在終端機與 AI 協作，進行檔案操作與程式撰寫。 2025.08 Video Understanding 支援 YouTube 影片理解。透過 Gemini 2.5 直接抓取字幕與影像內容進行摘要與互動。 2025.11 File Search 強化檔案搜尋能力，支援 JSON、JS、PDF、Python 等多種格式的 RAG 應用。 2025.12 Map Grounding 結合 Google Maps Platform，讓 Bot 能回答「最近的地震資訊」或「附近的餐廳」等地理資訊問題。 #### 技術亮點詳解 ##### 1. Gemini CLI 與 Vibe Coding 在六月推出的 Gemini CLI 改變了許多開發者的習慣。不僅僅是印出 “Hello World”，它整合了 Git、Gcloud 等工具。這帶出了一個新的開發概念：Vibe Coding。 定義：這不僅是寫程式，而是透過 Gemini CLI、Vertex AI Studio 和 Antigravity 等工具，讓開發流程進入一種「心流」狀態。 關鍵：重點在於開發者如何指揮這些工具串接，而非手刻每一行代碼。 ##### 2. 視覺與地理資訊的整合 (Video & Map) 八月的 Video Understanding 讓我們能直接丟入 YouTube 連結，Gemini 就能生成摘要甚至回答影片細節。到了年底的 Map Grounding，則是補足了 LLM 最缺乏的「實時地理資訊」。 應用場景：用戶問「找餐廳」，Bot 透過 Map Grounding 找出附近的 “CHILLAX” 或 “博感情” 等餐廳，並附上地址與類型。 資料來源：結合了 World Knowledge (Google Search) 與 Private Knowledge (Your Data/RAG)，讓回答更具落地性。 ###...

前情提要 這是 LINE Bot AP2 整合系列的第二篇文章。在第一篇文章中，我們完成了基本的 Shopping Agent 和 Payment Agent 整合，實作了 Cart Mandate、HMAC-SHA256 數位簽章、以及 OTP 驗證機制。 但是在實際部署後，我重新審視了 AP2 官方 Spec，發現我們漏掉了一個很重要的元件：Credential Provider。 這篇文章會分享： 為什麼需要 Credential Provider 重新審視 AP2 Spec 後發現的問題 如何實作完整的三層式支付架構 Payment Token 的安全機制 實際的踩坑經驗 回顧：原本的架構問題 在第一版的實作中，我們的支付流程是這樣的： 用戶選擇商品 → 創建 Cart Mandate → 直接發起支付 → OTP 驗證 → 完成 這個流程有幾個問題： 支付方式寫死: 每次都用同一張卡，沒有讓用戶選擇 敏感資料暴露: 卡號等資訊在多個地方傳遞 缺少 Token 化: 沒有一次性 Token 機制，存在重放攻擊風險 重新審視 AP2 Spec 重新讀了 AP2 的 Spec 文件後，我發現完整的架構應該是這樣的： ┌─────────────────────────────────────────────────────┐ │ Layer 1: Shopping Agent (購物層) │ │ - 商品搜尋與購物車管理 │ │ - 創建 Cart Mandate │ │ - 商家簽章 (Merchant Signature) │ └──────────────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Layer 2: Credential Provider (憑證層) ⭐ 這次新增！ │ │ - 安全儲存用戶的支付憑證（加密） │ │ - 根據交易情境選擇最佳支付方式 │ │ - 發行一次性 Payment Token │ │ - Token 綁定特定 Mandate │ └──────────────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Layer 3: Payment Agent (支付層) │ │ - 使用 Token 發起支付（不是卡號！） │ │ - 用戶簽章 (User Signature) │ │ - OTP 驗證...

前情提要 在上一篇文章中，我們探討了如何利用 LINE Bot 中實現 Agentic Vision。今天，我們要將視角轉向 AI Agent 的另一個重要領域：電子商務與互通性。 目前的 AI Agent大多是「孤島」。如果你想買書，你可能需要一個專門的書店 Bot；想買雜貨，又需要另一個雜貨 Bot。這些 Agent 彼此不互通，使用者體驗也支離破碎。 為了解決這個問題，Universal Commerce Protocol (UCP) 應運而生。它就像是商務世界的 HTML，定義了一套標準的語言，讓不同的 AI Agent（買家代理人與賣家代理人）能夠互相「溝通」並完成複雜的商務交易。 在這篇文章中，我將帶大家深入 devbooks_agent 的程式碼，這是一個基於 UCP 實作的技術書店 Agent，展示它是如何運作的。 什麼是 UCP 與 A2A？ 在進入程式碼之前，先簡單理解兩個核心概念： UCP (Universal Commerce Protocol)：一套標準化的商務協議。它定義了「商品」、「訂單」、「結帳」等資料結構（Schema），確保你的 Agent 說出的 “Product” 和我的 Agent 理解的 “Product” 是同一回事。 A2A (Agent-to-Agent)：Agent 之間的溝通模式。在這裡，我們會有兩個角色： User Agent (Client)：代表使用者，負責發送需求（例如：「我想買一本 React 的書」）。 Business Agent (Merchant)：代表商家（如 DevBooks），負責提供商品資訊、處理訂單。 我們今天的重點就是這個 Business Agent —— devbooks_agent。 專案結構概覽 devbooks_agent 是一個標準的 Python 專案，使用了 Google 的 Agent Development Kit (ADK)。 devbooks_agent/ ├── src/devbooks_agent/ │ ├── agent.py # Agent 的大腦：定義工具與行為 │ ├── ucp_profile_resolver.py # UCP 握手協議：確認彼此能力 │ ├── store.py # 模擬的資料庫與商務邏輯 │ ├── data/ │ │ ├── ucp.json # UCP 能力宣告 │ │ ├── products.json # 書籍目錄 │ │ └── agent_card.json # Agent 的名片 │ └── main.py # 程式入口點 1. 定義 Agent 的能力 (ucp.json) 首先，Agent 需要告訴世界它「會做什麼」。這透過 ucp.json 來定義。這就像是 Agent 的履歷表。 { "ucp": { "version": "2026-01-11", "capabilities": [ { "name": "dev.ucp.shopping.checkout", "version": "2026-01-11", "spec": "https://ucp.dev/specs/shopping/checkout" },...

前情提要 在完成 LINE Bot 的 Multi-Agent Orchestration 架構 之後，原本的圖片分析功能是直接將圖片送到 gemini-2.5-flash 做識別。但 Google 在 2026 年 1 月發布了 Gemini 3 Flash 的 Agentic Vision 功能，讓模型不再只是「看」圖片，而是能主動寫 Python 程式碼來放大、裁切、標註圖片。 這讓我想到一個有趣的使用場景： 使用者傳一張照片，說「幫我把咖啡標記出來」，AI 不只回覆文字描述，還會畫出 bounding box 標註在圖片上，把標註後的圖片傳回 LINE。 本文記錄了實作這個功能的完整過程，包括踩到的坑和解決方案。 Agentic Vision 是什麼？ 傳統的圖片分析是靜態的：丟圖片給模型，模型回傳文字描述。 Agentic Vision 把圖片理解變成一個主動的調查過程，使用 Think → Act → Observe 循環： ┌─────────────────────────────────────────────────────────────┐ │ Agentic Vision 流程 │ │ │ │ 1. Think - 分析圖片，規劃要怎麼深入調查 │ │ 2. Act - 寫 Python 程式碼（裁切、放大、標註、計算） │ │ 3. Observe - 觀察程式碼執行結果（包括生成的標註圖片） │ │ 4. 重複以上步驟直到完成分析 │ └─────────────────────────────────────────────────────────────┘ 技術核心 模型：gemini-3-flash-preview 關鍵功能：code_execution 工具 — 讓模型能寫並執行 Python 程式碼 輸出：除了文字分析，還能回傳模型生成的標註圖片 # 啟用 Agentic Vision 的 API 呼叫 response = client.models.generate_content( model="gemini-3-flash-preview", contents=[image_part, "幫我把咖啡標記出來"], config=types.GenerateContentConfig( tools=[types.Tool(code_execution=types.ToolCodeExecution)], thinking_config=types.ThinkingConfig(thinkingBudget=2048), ) ) # Response 包含多種 part：文字、程式碼、執行結果、標註圖片 for part in response.candidates[0].content.parts: if part.text: # 文字分析 if part.executable_code: # 模型寫的 Python 程式碼 if part.code_execution_result: # 程式碼執行結果 if part.as_image(): # 生成的標註圖片！ 功能設計 使用者體驗流程 原本收到圖片就直接分析，改成先讓使用者選擇模式： 使用者傳送圖片 │ ▼ ┌─────────────────────────────────────┐ │ 📷 已收到圖片，請選擇分析方式： │ │ │ │ ┌──────────┐ ┌─────────────────┐ │...