參考連結： Agent Skill Hub 儲存庫 whisperASR 參考範例 GitHub Pages 官方說明文件 這篇文章記錄了我在開發 Agent Skill Hub (2026 技能庫) 時，如何從零開始建構技能描述規範，並參考極簡美學打造出支援中英雙語的 GitHub Pages 文件站。 前情提要 隨著 AI Agent（如 OpenClaw 或 Gemini CLI）的普及，我們發現「如何讓 Agent 快速理解並執行特定任務」成為了關鍵。與其每次都寫長長的 Prompt，不如將常用的操作封裝成標準化的 Skills。 為了方便社群交流與 Agent 讀取，我建立了 agent-skill-hub。但只有程式碼是不夠的，我們還需要一個像樣的「門面」—— 一個既美觀又具備技術細節的文件網站。 🛠️ 第一步：標準化技能描述 (SKILL.md) 在 agent-skill-hub 中，每個技能（如 gcp-helper 或 n8n-executor）都擁有一個 SKILL.md。這個檔案的結構至關重要，因為它不只是給人看的，更是給 LLM 讀取的： Name & Description: 讓 Agent 知道這是什麼。 When to Use: 定義觸發場景。 Core Pattern: 提供標準指令範例。 Common Mistakes: 減少 Agent 幻覺導致的錯誤。 🎨 第二步：設計風格——致敬極簡美學 在設計 docs 目錄下的網頁時，我參考了 whisperASR 的風格。那種深色背景搭配亮眼點綴色（Teal）的設計，非常符合現代開發者的審美： 視覺元素重點： 漸層標題：利用 linear-gradient 營造出高端的質感。 Teal 點綴色：使用 #14b8a6 作為關鍵按鈕與標題的強調色。 卡片式佈局：清楚呈現每個技能的圖示與簡介，具備良好的回應式設計（Responsive Design）。 🌐 第三步：多國語言支援與自動跳轉 為了讓全球開發者都能使用，我採用了目錄結構化的語系管理方式： docs/ ├── index.html (語言偵測與導向) ├── en/ (英文版本) │ └── skills/ └── zh/ (繁體中文版本) └── skills/ 我在根目錄的 index.html 加入了一段簡單的 JavaScript，會根據使用者的瀏覽器設定自動引導至正確的語系： const lang = navigator.language || navigator.userLanguage; if (lang.startsWith('zh')) { window.location.href = './zh/index.html'; } else { window.location.href = './en/index.html'; } 🚀 第四步：GitHub Pages 部署流程 在 2026 年，最推薦的部署方式是將內容放在主分支的 docs/ 目錄下，這樣可以保持 main 分支的整潔，同時讓開發與文件同步更新。 1. 準備目錄結構 透過指令一次建立所有需要的目錄： mkdir -p docs/en/skills docs/zh/skills docs/assets/css 2. Git 提交與 Push 完成 HTML/CSS...

(Image generated by Nano Banana - Gemini Image Generation) 參考文章： OpenClaw 官方網站 OpenClaw 實戰教學：中文整理 FAQ 與建議 Skills OpenClaw 安全指南：資安加強建議 YouTube 教學影片：在 GCP 部署 OpenClaw 這篇文章記錄了在 Google Cloud Platform (GCP) 的 Debian/Ubuntu 環境下，安裝 OpenClaw (2026 最新版) 時遇到的權限、環境變數及進程持久化問題的完整解決流程。 前情提要 最近 AI Agent 領域非常熱門，OpenClaw 作為一個能 24 小時運作的開源 AI 代理，其強大的系統存取與瀏覽能力讓人印象深刻。為了安全起見，將它部署在雲端 VM (如 GCP GCE) 是最理想的作法，既能保證 24/7 在線，又能隔離本機的敏感資料。 但在 GCP 的預設 Debian/Ubuntu 環境中，由於權限機制與一般的 Desktop Linux 略有不同，照著官方腳本安裝往往會踩到不少坑。 🛠️ OpenClaw 在 GCP 的基本安裝流程 在進入故障排除之前，我們先快速跑一遍標準的安裝邏輯： 1. 建立 VM 執行個體 在 GCP Console 建立一個新的 VM： 機型：建議 e2-small 或 e2-medium（視您的 Agent 負載而定）。 作業系統：建議選用 Ubuntu 24.04 LTS 或 Debian 12。 硬碟：建議 20GB 以上。 2. 連線與基礎更新 透過 SSH 進入 VM 後，先執行系統更新： sudo apt update && sudo apt upgrade -y sudo apt install -y git curl build-essential 3. 正式安裝 OpenClaw 官方提供了一鍵安裝腳本： curl -fsSL https://openclaw.ai/install.sh | bash 但是！ 如果您直接執行上述腳本，在 GCP 上通常會遇到以下兩個嚴重的權限與路徑問題。 🛠️ 問題一：sudo-rs 的「HAL 9000」式拒絕 現象： 當執行官方安裝腳本時，遇到 sudo-rs 報錯： sudo-rs: I'm sorry evanslin. I'm afraid I can't do that 原因： 互動限制：透過 curl ... |...

參考文章： 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 驗證...