前情提要 這是 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...

前情提要 在維護 linebot-arxiv 專案時，我一直想為使用者提供更深入的論文分析功能。現有的「翻譯摘要」功能只能處理論文的 Abstract 部分，但使用者往往需要了解更多：研究方法、實驗結果、圖表分析等完整內容。 過去要實現這個功能，必須： 下載 PDF 到本地伺服器 上傳到 Google Cloud Storage (GCS) 使用 Gemini API 分析 GCS 上的檔案 這個流程不僅複雜（需要管理儲存空間），還要額外成本（GCS 儲存費用 + 流量費用），對於一個簡單的 LINE Bot 來說實在太重了。 但在 2025 年 1 月，Google 在 官方部落格 宣布了一個重大更新：Gemini API 現在支援直接從 Public URL 讀取檔案！ 這意味著我們可以跳過 GCS，直接讓 Gemini 分析 arXiv 上的 PDF 論文。 這個改變帶來的不只是技術簡化，更是成本和維護上的巨大優勢。 畫面展示 舊版介面 “知道更多” - 顯示論文詳細資訊 “翻譯摘要(比較久)” - 僅翻譯 Abstract “儲存文章” - 加入收藏 新版介面 “📋 詳細資訊” - 更清晰的標籤 “📑 AI 分析 PDF” - 新功能！完整 PDF 深度分析 “💾 儲存文章” - 視覺化改進 分析結果展示 完整的結構化分析，包含論文概述、研究方法、主要發現、應用價值。 主要 Repo https://github.com/kkdai/linebot-arxiv 開發過程中遇到的問題 問題 1：舊版實作的限制 在實作論文分析功能前，現有的做法是這樣的： // ❌ 舊版 - 只能處理 Abstract 文字 func actionGPTTranslate(event *linebot.Event, values url.Values) { url := values.Get("url") result := getArticleByURL(url) // 只能取得 Abstract 的文字內容 sumResult, err := GeminiChat( fmt.Sprintf(PROMPT_Summarization, result[0].Summary.Body) ) // 回傳翻譯結果... } 這個方法有明顯的限制： ❌ 內容淺薄 - 只能分析 Abstract，無法深入論文主體 用戶: "這篇論文用了什麼實驗方法？" Bot: [無法回答，因為 Abstract 通常不會詳述方法細節] ❌ 無法理解圖表 - Abstract 是純文字，無法分析論文中的圖表和數據 ❌ 缺少完整脈絡 - 無法理解實驗設計、結果分析、討論內容 問題 2：過去的解決方案太重 要讓 Gemini 分析完整 PDF，過去唯一的方法是： # ❌...

(完整影片) 前言 這一篇 Manus (後來被 Meta 收購) 首席科學家 季逸超 的三小時訪談，真的是許多人 AI 產業的人都不能錯過的好影片。 我應該會逐漸將我看到很棒的，放在留言中。先快速講一下我看到很值得關注與分享的地方。 身為連續 AI 創業家，季逸超 分享前十年在 AI 領域創業的部分。從 Tokenize 到 LSTM 到 Transformer 相關的應用。到兩次做 AI 瀏覽器的經驗。 接下來有談到為什麼 Manus 會成功，裡面有很多他們如何解決 Cloud Provider 與 Model Provider 無法做到的事情 - 一個好的工具庫讓 LLM 可以自動去規劃事情。 也有提到 AI Agent 很像製造業，因為有太多需要優化的部分。對於 Manus 產品規劃與方向上，他也認為做對的事情就是：「決定了什麼不去做」。 裡面有許多很快帶過去的技術概念，其實都很深。我一一寫在留言。 關於 MCP 使用 快速 link https://youtu.be/UqMtkgQe-kI?t=10342 關於 MCP 使用，其實 Manus 是比較保守的，因為 MCP 這種動態發現工具的方式，會污染 Action Space ，會讓緩存命中率下降。 下降的緩存命中率，會讓成本暴增。改善方式： 不在原生 Action Space 內的 MCP 調用方式 他也說這被 Anthorpic 寫成部落格，在這裡: Code execution with MCP: Building more efficient agents如何利用代碼執行環境來提高使用MCP（Model Context Protocol）連接AI代理與外部系統的效率。MCP是一個開放標準，旨在解決AI代理與工具和數據的連接問題。文章指出，隨著MCP的廣泛應用，直接工具調用會導致上下文窗口過載和中間結果消耗過多的token。透過將MCP伺服器呈現為代碼API，代理可以更有效地管理上下文，減少token使用，並提高效率。 重要觀點 MCP的挑戰： 工具定義過載上下文窗口。 中間工具結果消耗額外的token。 代碼執行的優勢： 代理可以按需加載工具，並在執行環境中處理數據。 減少token使用，降低成本和延遲。 提供隱私保護和狀態管理的好處。 代碼執行的實現： 使用TypeScript生成可用工具的文件樹。 代理通過文件系統探索工具，僅加載所需的定義。 代碼執行的其他好處： 進行數據過濾和轉換。 使用熟悉的代碼模式進行控制流。 保護隱私的操作。 狀態持久化和技能的保存。 解決方案 代碼執行環境： 將MCP伺服器作為代碼API。 代理在執行環境中運行代碼，減少上下文窗口的負擔。 注意事項 安全性和基礎設施要求： 需要安全的執行環境，適當的沙箱、資源限制和監控。 這些基礎設施需求增加了操作開銷和安全考量。 提到 OpenAI 5 階層的 Agent https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf Level 1: Conversational AI/Chatbots Level 2: Human-Level Problem Solving/Reasoners Level 3: Agents Level 4: Innovators Level 5: Organizers from https://youtu.be/UqMtkgQe-kI?t=9650 心目中影響 AI 進程的論文 當問到，你心目中影響 AI 進程的幾篇論文: FLAN-T5 (Scaling Instruction-Finetuned Language Models) 透過微調參數，讓 11B 的 FLAN-T5 也有不錯的效果。 Word2Vec...