前情提要 我有一個自己每天在用的 LINE Bot，linebot-helper-python。丟網址回摘要跟社群文案，丟 YouTube 連結可以針對影片連續追問，還有書籤、地點查詢那些。其中一個功能是 LIFF 語音助理：開一個網頁，用 WebSocket 接 Gemini Live API，可以按住說話或免持對話，講完的內容會整理成一則訊息推回 LINE 聊天室。 九月中 Google 發了 Gemini 3.8 Live，看完之後我想做的事情，跟公告想賣的東西不太一樣。 公告在講能力：Speech to Speech Index 排第一（82.6 分）、Big Bench Audio 97.7%、97 種語言自動偵測且可以在對話中途切換、工具呼叫可以在背景執行而不中斷對話流、即時視覺輸入。還有一顆 Gemini 3.8 Live Extended Thinking，能一邊推理一邊出聲。 我第一個念頭是：這下我可以把那個 preview 例外拔掉了。 真正的動機：一個 preview 模型埋了兩次雷 上一篇寫 agentic video 的時候提過一件事：我的智慧對話功能壞了整段時間，沒有人發現。原因是 loader/chat_session.py 寫死了 gemini-3-pro-preview，那個模型從 Vertex AI 下架之後，真實路徑直接回 404，而那個檔案的例外處理是直接 raise。 修完之後我加了一組守衛，用測試強制「模型 ID 只能出現在 config/agent_config.py」「不准使用 preview 或實驗模型」。但那組守衛有兩個例外： # Live API 僅支援 gemini-3.1-flash-live-preview；TTS 是獨立模型家族。 # 這兩處必須維持 preview 模型，不在守衛範圍內。 EXEMPT_FILES = {"services/voice_live.py", "tools/tts_tool.py"} 語音那個例外的理由是「Live API 只有這一顆模型能用」。當時是真的。但那句話一旦寫進註解，就沒有人會再去查它還成不成立——同一類 bug 的最後一個缺口，就這樣光明正大掛在那裡好幾個月。 3.8 Live 的意義因此不只是能力升級。它的模型名稱不含 -preview，這代表那個例外可以縮掉。 先問 API，不要問文件 這次我沒有先讀文件，而是直接問 API 上實際存在哪些東西： curl -s "https://generativelanguage.googleapis.com/v1beta/models?key=$KEY&pageSize=200" \ | jq -r '.models[]?.name' | rg -i 'live' models/gemini-3.5-transcribe-live models/gemini-3.1-flash-live-preview models/gemini-3.8-live models/gemini-3.8-live-extended-thinking models/gemini-3.5-live-translate-preview 一行指令拿到五個確定存在的模型名稱，比在文件裡翻半天可靠。gemini-3.8-live 就在上面，名字乾淨。 順帶還撿到一個我本來不知道的 gemini-3.5-live-translate-preview。我原本在想「要不要做即時口譯模式」，看來那是一顆專門的模型，不是拿通用模型硬幹。這個之後再說。 再往下問 metadata：   3.1-flash-live-preview 3.8-live inputTokenLimit 131072 131072 outputTokenLimit 65536 65536 supportedGenerationMethods bidiGenerateContent bidiGenerateContent 數字一模一樣。到這裡我對「可以無痛換」有了初步信心，但這還只是 metadata，不是行為。 踩坑一：我警告了一個不存在的風險 我第一次評估這件事的時候，很嚴肅地提醒了一句：「公告沒提到 Vertex AI，而這個專案的決策是全面改用 Vertex，所以 3.8 Live 不確定拿不拿得到。」 聽起來很專業。然後我去翻自己的程式碼： client = live_genai.Client( api_key=GOOGLE_AI_API_KEY, vertexai=False, http_options={"api_version": "v1beta"}, ) vertexai=False。語音這條路徑從一開始就是走 Gemini API 加 AI Studio 的金鑰，根本不走 Vertex——而...

最近翻 Google Cloud 的開發環境設定文件， 在一堆 gcloud CLI、Cloud Shell、Cloud Workstations 中間，多了一段以前沒有的東西： agy plugin install https://github.com/google/skills/plugins/cloud/google-cloud-developer agy 是 Google Antigravity CLI。但真正讓我停下來的不是這個新 CLI，而是後面那串網址： Google 開始把自家的產品知識，包成 agent plugin 放在 GitHub 上發佈。 結果我打開自己的 Claude Code 一看，這個 plugin 早就裝在機器上了。所以這篇不用先裝 Antigravity CLI， 直接拿現成的來實測，看看它到底做了什麼。 這個 plugin 裡面裝了什麼 先把它拆開看。整包其實不大，5 個 skill、1 份路由規則、1 個 MCP server，全部加起來 1549 行 markdown，沒有任何程式碼： skills/gcloud/ # gcloud 指令的安全護欄與語法驗證（272 行 + 340 行參考文件） skills/retrieving-developer-knowledge/ # 查官方文件（103 行 + 182 行參考文件） skills/finding-google-skills/ # 按需從遠端目錄撈技能（134 行） skills/google-cloud-recipe-onboarding/ # 新手開第一個專案（228 行） skills/google-cloud-recipe-auth/ # 憑證與 ADC 選擇（260 行） rules/google-cloud-discovery.md # 技能路由表（30 行） 有趣的是同一個目錄底下塞了四套 manifest： .claude-plugin/plugin.json # Claude Code .codex-plugin/plugin.json # Codex gemini-extension.json # Gemini CLI / Antigravity plugin.json # 通用格式 那份通用的 plugin.json 開頭是這樣： { "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "google-cloud-developer", "version": "1.1.2", "author": { "name": "Google LLC" }, "license": "Apache-2.0" } agent-plugins.org 是個跨工具的 plugin schema。Google 沒有為自己的 Antigravity 做一份專屬格式， 而是同一包東西讓四種 agent 都吃得下去。換句話說，你不裝 Antigravity CLI 也用得到這包東西。 安裝：三條路挑一條 Antigravity CLI（文件上寫的） agy plugin install https://github.com/google/skills/plugins/cloud/google-cloud-developer Claude Code claude plugin marketplace add google/skills claude plugin install google-cloud-developer@google-plugins...

在 Steam Deck 上遊玩各種電腦遊戲時，經常會遇到需要安裝「社群中文化補丁」、「民間修復更新」或「MOD 擴充包」的情況。然而，許多開發者或漢化小組釋出的補丁是包裝成 Windows 的 .exe 安裝程式，並在執行時要求玩家手動選擇遊戲目錄。 這在 Steam Deck 的 SteamOS（Linux 架構）底下往往會遇到一個巨大的痛點：安裝程式的資料夾選取視窗根本找不到遊戲裝在哪裡。 本文將解析這個問題的核心成因，並分享一套目前最直覺、成功率最高且不需輸入複雜指令的「中繼搬移法」。 為什麼補丁程式會「迷路」？ SteamOS 是透過相容層（Proton 或 Wine）來模擬 Windows 環境執行程式，底層有兩個機制容易導致安裝程式卡關： 隱藏資料夾限制：Steam 預設將所有遊戲安裝在 /home/deck/.local/share/Steam/steamapps/common/。在 Linux 系統中，名稱開頭為小數點（.）的資料夾是隱藏資料夾。多數 Windows 補丁自帶的「瀏覽資料夾」瀏覽器無法辨識或顯示這些隱藏路徑。 沙盒權限隔離：如果你習慣使用 Bottles（樽）或部分 Flatpak 應用程式來啟動 .exe，這些工具預設受到沙盒權限控管，無法直接讀取使用者的系統深層檔案。 核心解法：中繼搬移三步驟 與其跟隱藏資料夾設定與 Linux 指令搏鬥，最乾淨的做法是先將遊戲資料夾搬移到非隱藏的公開目錄（如 Downloads 或 Desktop），完成補丁注入後再覆蓋回原始路徑。 第一步：複製遊戲目錄至中繼路徑 長按電源鍵，切換至 Switch to Desktop（桌面模式）。 開啟 Steam 收藏庫，在目標遊戲上點擊右鍵 ➔ 管理 ➔ 瀏覽本機檔案。 檔案總管（Dolphin）會打開遊戲所在的目錄。點擊網址列往上一層回到 common 資料夾。 對著「該遊戲的資料夾」按右鍵選擇 Copy（複製）。 從左側快捷欄進入 Downloads（下載） 或 Desktop（桌面），在空白處按右鍵選擇 Paste One Folder（貼上）。 第二步：執行補丁並透過 Z 槽選取路徑 透過 Bottles、Protontricks 或將補丁加入非 Steam 遊戲來啟動補丁 .exe。 當安裝程式跳出「請選擇遊戲安裝目錄」視窗時，點開 My Computer（我的電腦） ➔ Z: 槽（Z:\ 即對應 Steam Deck 的根目錄）。 依序展開以下公開路徑： 若剛才貼在 Downloads： Plaintext Z:\home\deck\Downloads\[你的遊戲資料夾] 若剛才貼在 Desktop： Plaintext Z:\home\deck\Desktop\[你的遊戲資料夾] 選定資料夾後按下確認，開始執行補丁寫入。由於路徑完全透明，安裝程式能順利將替換檔案解壓進去。 第三步：覆蓋回原路徑與啟動檔確認 補丁安裝完成並關閉視窗後，回到剛才的 Downloads 或 Desktop 目錄。 進入補丁更新完畢的遊戲資料夾，按 Ctrl + A 全選所有檔案，點右鍵選擇 Copy（複製）。 回到 Steam 原始的遊戲資料夾（Steam 收藏庫 ➔ 遊戲點右鍵 ➔ 管理 ➔ 瀏覽本機檔案）。 在空白處按右鍵 Paste（貼上），當系統跳出覆蓋提示時，選擇 Overwrite / Write Over（全數覆蓋）。 關鍵檢查：部分補丁在安裝後會產生獨立的執行檔（例如 Game_Patch.exe 或 Game_ZH.exe）。若有此情況，請將原本的遊戲啟動主程式（如 Game.exe）備份改名，並將補丁產生的新執行檔改回 Steam 預設的啟動檔名。 清理暫存檔案：確認無誤後，即可將 Downloads 或 Desktop 中的中繼資料夾刪除。 注意事項與除錯技巧 Linux 檔案大小寫敏感：Linux 系統會將 Data 與 data 視為完全不同的目錄。如果補丁解壓縮出來的資料夾大小寫與原遊戲不同，請手動將內容合併，避免生成雙重資料夾導致遊戲讀取不到補丁資源。 動畫與編碼相容性：若打完補丁後進入遊戲遇到文字方塊、日文缺字或開場動畫黑屏，請在 Steam 該遊戲的 內容 ➔ 相容性 中改用...

前情提要 我有一個自己每天在用的 LINE Bot，linebot-helper-python。丟網址給它會回摘要跟四個平台的社群文案，丟 YouTube 連結會回影片摘要，還有書籤、地點查詢、語音助理那些。跑在 Cloud Run 上，用 Vertex AI。 八月底 Google 發了一篇 Introducing agentic video in Gemini，看完我第一個念頭是：這東西能讓我的 bot 多做一件現在做不到的事——針對影片提問，而不是只給一份摘要。 結果做下來，公告裡沒寫的部分比寫了的更值得記。 Agentic video 是什麼 原本 Gemini 讀影片是「靜態」的：不管你問什麼，它都照固定的取樣率把整支影片的每一格畫面、每一段音訊全部塞進 context。一支兩小時的影片，光影片本身就佔掉幾十萬 token，而你可能只是想問「他有講到定價嗎」。 Agentic 模式把這件事反過來：讓模型自己決定要載入哪一段。先掃逐字稿，判斷答案可能在 1:24 附近，就只把那一段的畫面拉進來。 官方公告給的數字是長片場景 token 少 88%、成本降 66%、正確率高 7%。開啟方式就是在 Part 上多一個參數： video_part = types.Part( file_data=types.FileData(file_uri=..., mime_type="video/mp4"), media_processing="AGENTIC", # 或 "STATIC" ) 支援的模型有三個：gemini-3.7-flash、gemini-3.6-flash、gemini-3.5-flash-lite。輸入來源可以是 YouTube 網址、Cloud Storage URI，或內嵌的 base64。 它實際能做到什麼 我拿兩小時的 Google I/O ‘25 keynote 測，問「他有講到定價嗎？如果有，請給我幾分幾秒」，回來的是： 影片中有提到價格與訂閱方案的定價相關資訊。主要出現在影片的 1:24:40 到 1:26:10 左右⋯⋯ 然後正確描述了 Google AI Pro 與 Google AI Ultra 兩個方案的差異。再問 Android XR 眼鏡那段在哪，回 1:36:31 至 1:50:30，內容也對得上。 這種在兩小時影片裡精準定位的能力，是我覺得這個功能真正值錢的地方。摘要人人都會做，「這支長片裡他哪時候講到 X」目前沒什麼工具做得好。 前置條件：四個參數，少一個都不會報錯 這是這次最貴的一課，所以放前面講。 在 Vertex AI 上要讓 agentic 真的生效，四件事必須同時成立： # 條件 少了會怎樣 1 api_version="v1beta1" agentic 只在 v1beta1 提供，用 v1 會靜默退回 STATIC 2 media_processing="AGENTIC" 預設就是 STATIC，不設等於沒開 3 模型在支援名單內 不支援的模型會靜默降級為 STATIC 4 thinking_level 有設定 見下一節，這個最麻煩 關鍵字是靜默。少任何一個，API 都會回 200、答案照樣產出、看起來完全正常，只有帳單不一樣。沒有任何錯誤訊息會告訴你 agentic 沒生效。 還有兩個環境面的前提： SDK 版本：media_processing 這個欄位是 google-genai 2.20.0 才加進去的。我逐版下載驗證過，2.19.0 沒有、2.20.0 有。版本太舊的話這個參數會被當成未知欄位丟掉，一樣不報錯。 Vertex 專屬：官方文件的多輪對話範例是寫給 Gemini Developer API 的，Vertex 這條路上行為不同，後面會講。 我的作法是把這四項各寫一支測試，斷言送進 SDK 的參數： def test_thinking_level_is_low(captured): youtube_tool.summarize_youtube_video(VIDEO_URL) config = captured["call_kwargs"]["config"] assert...

當訊息可以反悔：用 Edit 與 Unsend Webhook 打造會「變形」的 LINE 團購 Bot 作者：Evan Lin，LINE Taiwan Developer Relations Team Lead 2026 年 8 月 20 日，LINE 宣布在 LINE Labs 開放「編輯訊息」功能免費試用。 對一般使用者來說，這是一個很直覺的功能：訊息送出後才發現打錯字、日期寫錯，或語氣想再調整，不必再經過「收回、重打、重新送出」的流程，直接編輯原本的文字訊息就可以了。 但我看到這個功能時，第一個想到的是另一件事： 如果使用者改掉一則已經被 LINE Bot 處理過的訊息，Bot 知道嗎？ 答案是：知道。LINE Messaging API 提供了 Edit event；而當使用者收回訊息時，也有 Unsend event 可以接收。 這篇文章想跟大家分享，我如何把這兩種 webhook event 做成一個有故事的 LINE Bot Demo，以及實作時幾個容易忽略、卻非常重要的細節。 完整範例程式碼放在 GitHub： https://github.com/kkdai/linebot-edit-unsend 先從 LINE Labs 的「編輯訊息」開始 目前在 LINE Labs 試用編輯訊息，需要先符合以下條件： 手機版 LINE 更新至 26.12.0（含）以上版本。 進入「主頁 → 設定 → LINE Labs」。 開啟「訊息編輯」。 在一般一對一與群組聊天室中，文字訊息送出後 15 分鐘內可以編輯；Keep 筆記則是 6 天內。照片、影片、語音、檔案與貼圖目前不能編輯。修改後，聊天室會顯示「已編輯」，但不提供舊版本查看或還原。 這裡還有一個跟 Bot 開發直接相關的限制：目前與 LINE 官方帳號的一對一聊天室不支援編輯訊息。因此，要測試 Messaging API 的 Edit event，必須把 Bot 加入群組聊天室。 功能與啟用方式可以參考 LINE 台灣新聞室公告。 從 UI 功能想到 Bot 的資料一致性 過去 Bot 收到文字訊息後，常見的處理流程是： 接收 message webhook。 解析文字。 寫入資料庫或觸發後續流程。 回覆處理結果。 如果訊息送出後不能修改，這個模型很單純。但當訊息可以被編輯，原本的文字便不一定是使用者最後的意圖。 例如使用者送出： 珍珠奶茶 / 半糖 / 少冰 / 1 Bot 已經把它記錄成一杯 60 元的飲料。幾秒後，使用者直接編輯原訊息： 珍珠奶茶 / 微糖 / 去冰 / 2 如果 Bot 沒有處理 Edit event，聊天室看到的是兩杯，但後端仍然記成一杯。畫面上的世界和 Bot 裡的世界就分開了。 這就是 Edit event 最實際的價值：它不只是通知「文字改過了」，而是讓服務有機會同步使用者的最新意圖。 團購變形記：讓 API Demo 有一個故事 為了同時展示 edit 與 unsend，我把 Bot 設定成「百變店長・單單」，負責拯救下午三點陷入低電量的辦公室。 Demo 流程如下： 團主輸入...

前情提要 我有一個自己在用的 macOS App，gemini-live-translate-macos。它用 ScreenCaptureKit 直接抓指定 App 的音訊，不需要 BlackHole 那類虛擬音效卡，然後丟給 Gemini Live API 做即時翻譯，一邊出繁中字幕、一邊播中文語音。開發過程寫過兩篇，第一篇是用 AGY CLI 從零做出來，第二篇是 Claude Code 接力把它從能動變成好用。 這次要加的東西起點很單純：我看到 Live API 多了一份「即時逐字稿」的文件，想說既然已經在接 Live API 了，加個純逐字稿模式應該就是改幾個參數的事。 結果查完文件才發現，Google 這次一口氣放了兩顆名字很像但能力差很多的模型，而我真正想要的那個功能（語者分離）在我原本以為的那顆上面根本沒有。 兩個名字只差兩個字的模型 先把差異攤開，這是我花最多時間才搞清楚的部分：   gemini-3.5-transcribe-live gemini-3.5-transcribe 走哪個 API Live API（WebSocket 串流） Interactions API（一般 HTTP 請求） 使用情境 邊講邊出字 錄完之後整份丟進去 語者分離 不支援 最多 8 位 字詞層級時間戳 不支援 支援 音訊長度 單次 session 10 分鐘 1 小時，開語者分離時 30 分鐘 智慧模式 SMART 可用 smart 與語者分離互斥 暫定字幕 有 interimInputTranscription 不適用 官方文件在 Live 那頁的限制章節寫得很直白： Speaker diarization is not supported in live streaming sessions. For speaker diarization, use the non-streaming Audio transcription endpoint. 所以「即時看到誰在講什麼」這件事，目前做不到。要語者分離就得錄下來、會後整份送出去。這個限制決定了我後面整個架構。 即時那顆：interim 是它的重點 setup 的形狀跟原本的翻譯模型不一樣，responseModalities 要是 TEXT，轉錄參數放在 setup.inputAudioTranscription 底下： { "setup": { "model": "models/gemini-3.5-transcribe-live", "generationConfig": { "responseModalities": ["TEXT"] }, "inputAudioTranscription": { "languageCodes": [], "mode": "SMART" }, "realtimeInputConfig": { "automaticActivityDetection": { "disabled": false } } } } languageCodes 留空是自動偵測語言，填 ["en-US"] 這種 BCP-47 代碼則是給它語言偏好。mode 有兩個值：VERBATIM 逐字保留所有內容，SMART 會拿掉 uh、um 這類填充詞並自動補上格式。會議記錄我選 SMART，讀起來乾淨很多。 還有一個 customVocabulary 可以塞專有名詞，上限 1000 條，但文件建議 100 條以內效果最好。這次我沒做，等真的遇到人名一直被聽錯再說。 回應端則多了一個原本翻譯模型沒有的欄位： interimInputTranscription：說話中的暫定結果，會被後面的內容覆蓋...