參考文章： 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 開發者: 😤 "又要去翻官網文件了..." 這樣的循環你是不是很熟悉？即便是 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 渲染，有些用自訂語法 圖片說明可能在 alt、title...

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(): # 生成的標註圖片！ 功能設計 使用者體驗流程 原本收到圖片就直接分析，改成先讓使用者選擇模式： 使用者傳送圖片 │ ▼ ┌─────────────────────────────────────┐ │ 📷 已收到圖片，請選擇分析方式： │ │ │ │ ┌──────────┐ ┌─────────────────┐ │...

圖片 A 圖片 B 前情提要 在維護 linebot-helper-python 專案時，我一直面臨一個架構問題：隨著功能增加，main.py 中的 if/elif 判斷式越來越長，程式碼越來越難維護。 原本的訊息路由邏輯： # ❌ 舊版 - if/elif 地獄 async def handle_text_message(event): msg = event.message.text if msg.startswith('/clear'): # 處理清除指令 elif msg.startswith('/help'): # 處理說明指令 elif msg == '@g': # 處理 GitHub 摘要 elif is_youtube_url(msg): # 處理 YouTube 摘要 elif extract_url(msg): # 處理一般 URL 摘要 else: # 處理一般對話 這樣的架構有幾個明顯問題： ❌ 難以維護 - 新增功能就要加 elif，檔案越來越肥 ❌ 難以測試 - 所有邏輯混在一起，單元測試困難 ❌ 難以擴展 - 想要並行處理多個意圖？改起來很痛苦 ❌ 職責不清 - 對話、摘要、位置搜尋全部混在一起 在 2025 年初，Google 發布了 Agent Development Kit (ADK)，提供了建構 Multi-Agent 系統的框架。我決定用 ADK 重構整個專案，實現 Agent-to-Agent (A2A) 架構。 這篇文章記錄了完整的遷移過程，從規劃到實作的 5 個階段。 什麼是 ADK 和 A2A？ Google Agent Development Kit (ADK) ADK 是 Google 提供的 Python 框架，用於建構基於 LLM 的 Agent 系統： from google.adk.agents import Agent chat_agent = Agent( name="chat_agent", model="gemini-2.5-flash", description="處理一般對話", instruction="你是一個智能助手...", tools=[google_search_tool], ) Agent-to-Agent (A2A) 通訊 A2A 是一種架構模式，讓多個專業 Agent 協作處理複雜任務： User: "幫我找台北好吃的拉麵，然後摘要這篇文章 https://..." │ ▼ ┌─────────────────────┐ │ Orchestrator Agent │ │ (意圖解析 + 路由) │ └─────────────────────┘ │ ┌─────────────┴─────────────┐ │ Parallel...