TommyPan's Blog

把 DQN 放進瀏覽器後，還能像訓練時一樣玩嗎？

Tue, 22 Sep 2026 10:00:00 +0800

把模型檔案放進網頁，和讓模型在瀏覽器裡玩好打磚塊，是兩回事。模型每次需要四張小型灰階畫面，並替四種動作估分；如果瀏覽器提供的畫面、分數或動作意思不同，它就不是在原本學習過的遊戲裡做決策。

因此，搬進瀏覽器後要問的不只是「網頁能不能載入模型」，而是「它看到同一種畫面時，是否仍選出同一個動作；接上遊戲後，規則是否也相同？」

能算出分數，還不等於真的在玩

最初的瀏覽器展示只載入模型，讓它對固定畫面估計四種動作的分數。當時頁面清楚標示遊戲尚未接上。這是有用的一步：它確認瀏覽器能讀取模型並做運算，卻沒有把模型推論說成完整遊戲。

後來模型和 Atari 遊戲都能在瀏覽器中執行，不必把每一步畫面送回 Python 伺服器。瀏覽器可使用 WebAssembly 在一般處理器上計算，也能透過 WebGPU 使用顯示卡。不同電腦支援的方式不一樣，所以看見「支援 GPU」不代表眼前這一局一定由 GPU 執行。

瀏覽器要看見同一種畫面，才能沿用模型

訓練好的模型不是直接讀取任意圖片。它會收到最近幾張畫面，並依照固定順序估計不動、發球、往右和往左。瀏覽器必須用相同方式縮小和整理畫面，也要把模型選出的動作轉成遊戲真正能執行的動作。

遊戲開始和掉命後的發球也要說清楚。發球是遊戲流程的一部分；若由網頁自動處理，就不能把它算成模型自行學會了發球。同樣地，每次操作讓遊戲前進幾個畫面、掉命後從哪裡接續，都會改變模型後來看到的情況。

先把 60 張相同畫面交給 Python 與瀏覽器中的模型比較，這批畫面上的動作選擇全部相同。這能排除一部分轉換問題，但不能代表所有畫面都會一致，更不能取代完整遊戲測試。

能玩一整局，和每一步都相同是兩回事

遊戲中一次動作就會改變下一張畫面。如果兩種環境在某一步出現小差異，後續遊戲可能一路分岔，最後得分也不同。因此，逐步走出完全相同路線，和模型是否能正常遊玩，是兩個不同的問題。

目前可以確認的是，瀏覽器能載入模型並完成實際遊戲；但這不足以宣稱每一張處理後的畫面都與 Python 完全相同，也不能保證所有瀏覽器和電腦都會得到相同分數。要判斷模型表現，仍需看多局測試，而不是只看展示畫面。

人類玩家和模型是在同一場比賽嗎？

目前的頁面把人類與 Agent 放在同一畫面，但兩邊各自有一場獨立的 Breakout。人類用鍵盤或滑鼠控制自己的遊戲；Agent 看自己的畫面，由模型選擇動作。兩邊可以一起開始或暫停，球、磚塊、生命和分數卻不共用。

你可以直接遊玩已部署的 Breakout 網頁版。它展示了模型、遊戲和網頁互動已接起來；是否比其他模型打得更好，仍要依照公平的多局比較來回答。

模型換了執行方式，DQN 還會做出相同選擇嗎？

Tue, 22 Sep 2026 10:00:00 +0800

訓練好的 DQN 可以放進另一個執行環境，讓它不必依賴原本訓練模型的程式。轉換成另一種格式後，檔案能成功載入，只表示新的執行環境看得懂它；更重要的是，它面對相同畫面時，還會不會選同一個動作？

這個差別在打磚塊裡尤其明顯。模型會替不動、發球、往右、往左估分，選出最高的一個。只要其中一次選擇改變，之後看到的遊戲畫面也可能跟著不同。

換一種方式執行，模型會改變嗎？

ONNX 是一種可讓不同軟體讀取模型的格式。ONNX Runtime 則負責實際計算。對讀者來說，可以把它想成同一份食譜交給另一個廚房：紙張讀得懂，不代表做出來的菜就一定相同。

最直接的檢查，是把完全相同的 60 張遊戲畫面交給原本的 PyTorch 模型和兩種 ONNX Runtime 執行方式，再看它們選了什麼動作。這批畫面上，三種方式的選擇全都一致，數值最大差距約 0.000162。這只說明它們在這批畫面上的行為相同，不能保證未見過的每一張畫面都完全一致。

模型輸出的分數有細微差異，但這批畫面中最高分的動作沒有改變。

怎麼量到一次選擇真正花的時間？

打磚塊一次只需要模型處理眼前的一組畫面，因此測試一次決策，而不是同時塞進大量資料。先讓模型執行幾次以完成啟動，再重複量測。P50 是一半的測量結果比它快、一半比它慢；P95 則顯示比較慢的那一端大約要等多久。

執行方式	一般耗時（P50）	較慢時（P95）
PyTorch CPU	2.533 ms	3.298 ms
PyTorch GPU	1.526 ms	2.862 ms
ONNX Runtime CPU	0.856 ms	1.596 ms
ONNX Runtime GPU	1.342 ms	2.663 ms

這個小模型每次只處理一組畫面，所以 ONNX Runtime CPU 反而比 GPU 快。GPU 除了計算，還要付出搬資料和啟動的時間；對較小的工作，這些額外時間可能比省下的計算還多。這是這台電腦和這個模型的結果，不能解讀成 CPU 一定比 GPU 快。

把模型縮小，為什麼動作會變？

把模型數字從較高精度改成較低精度，可以讓檔案大小幾乎減半。但數值變化也會影響模型對動作的估分，尤其當兩個動作原本就很接近時，最後選擇可能翻轉。

同樣的 60 張畫面裡，較低精度的模型有 4 次選了不同動作；模型檔案縮小約一半，但這輪測量沒有更快，反而較慢。對這個打磚塊模型而言，縮小檔案沒有換到預期的速度收益，卻改變了一部分決策，因此沒有採用。

讓 Breakout DQN 從遊戲畫面走到瀏覽器

Thu, 17 Sep 2026 10:34:00 +0800

打磚塊的球拍會跟著畫面移動，模型也能替每個動作算出分數；但這還不足以說它已經學會玩。一次漂亮的分數可能來自有利的開局，而持續執行的程式也可能只是卡在等待畫面，沒有真的繼續遊戲。

這個專案一路追問幾個更實際的問題：模型每次看見什麼？分數改變時，怎麼知道是模型變好，而不是遊戲規則變了？訓練好的模型放進瀏覽器後，還會做出原來的選擇嗎？

DQN 是一種用神經網路估計「眼前畫面下，各個動作未來可能帶來多少分」的方法。要讓這個估計有意義，遊戲、畫面和計分方式都得先說清楚；要知道它是否真的學會，還得觀察多場遊戲，而不是只挑最高分。

模型得先看見同一款遊戲

對人來說，打磚塊是一個連續畫面；對模型來說，遊戲必須把每一步整理成它能讀取的數字。單看一張畫面，不容易分辨球正往哪個方向移動，因此這個專案讓模型同時參考最近幾張畫面，再從中選擇不動、發球、往右或往左。

每次操作推進多少畫面、掉命後如何重新發球、遊戲何時算結束，都會改變模型看到的經歷。把這些規則固定，才能讓兩個版本從相近條件開始比較。這些入門概念和畫面處理方式，整理在從 Breakout 畫面理解 Q-Learning。

分數高了，模型就真的學會了嗎？

早期測試中，DQN 平均得分 4.53，高於隨機選擇動作的 1.33。乍看之下，模型似乎已經學到一些東西；但逐局檢查後發現，15 局裡有 10 局其實是在時間上限到達時被迫停止。

原因不是模型在激烈比賽中撐得更久，而是它掉命後常常沒有按下發球鍵。遊戲停在等待畫面，模型卻繼續把球拍往右移。這提醒我們，平均分數和操作次數要連同每局實際發生的事一起看。

後來的檢查也把「程式能執行」、「模型有在更新」和「遊戲表現有進步」分開處理。短程訓練可以確認資料流和更新機制接得起來，卻不能單獨回答模型是否會玩；比較學習方式時，則需要相同規則、相同起點和多次訓練。更多除錯過程收在從能跑到可信：DQN 為什麼看起來會玩，卻可能卡住？。

更快訓練，或換一種模型，會有什麼代價？

同時跑兩場 Breakout，收集相同數量的遊戲操作約快 1.6 倍，但這次訓練出的模型分數沒有一起提高。比較不同 DQN 時，較複雜的版本在部分測試中得分較高，代價是更多計算；換到新的遊戲起點後，分數也低於挑選模型時看到的高分。

這些結果說明「訓練快」、「某一批分數高」和「面對新局面也穩定」是不同問題。並行訓練與模型比較的過程，可以從訓練更快，DQN 就更好嗎？繼續閱讀。

模型搬到另一台電腦或瀏覽器後，還是原來的模型嗎？

訓練好的模型可以轉成 ONNX 格式，交給其他執行環境讀取。轉換成功只表示檔案能載入；我們還要確認它面對相同畫面時，是否仍做出相同選擇。

在一批固定畫面上，ONNX Runtime 的 CPU 與 CUDA 執行方式都保留了 PyTorch 的動作選擇；TensorRT 在這組測試中降低了較慢端的推論時間。這些結果只描述當時的模型和設備，不代表其他硬體一定得到同樣速度。模型換了執行方式，DQN 還會做出相同選擇嗎？說明了比較方式與結果。

網站也有可以直接遊玩的 Breakout。模型和遊戲在瀏覽器中執行，能正常遊玩代表部署流程已經接通；它本身不能證明模型在所有電腦上都得到相同分數，也不能證明瀏覽器產生的每一張畫面都與訓練環境完全相同。瀏覽器端的檢查和限制整理在把 DQN 放進瀏覽器後，還能像訓練時一樣玩嗎？。

這條路還能繼續問什麼？

這些工作沒有宣稱 DQN 已經徹底解決打磚塊。它們建立的是一條可以繼續檢查的路徑：讓遊戲規則清楚，知道模型從畫面學到了什麼，再用多場測試判斷改動是否可靠，最後確認換了執行環境後決策仍然合理。

核心文章依照這些問題重新安排閱讀順序；此外，還有一篇獨立實驗探討「失去一條命時多扣一分」是否能改善表現：球掉一條命時多扣一分，真的會讓 AI 玩得更好嗎？

把 GPX 路線動畫交給 GPU：Windows 原生工具的設計與輸出證據

Sat, 01 Aug 2026 10:00:00 +0800

GPX 是用來保存 GPS 路線點的檔案格式；它很適合保存路線，卻不適合直接講故事：讀者看見的是一串座標，不是路線如何穿過地圖、距離如何累積，或爬升在哪裡發生。GPX Animator GPU Edition 是我做的 Windows 原生工具，讓這些資料在地圖上變成一段可以播放的動畫，再輸出成 MP4。

這篇是 GPX Animator GPU 的 Overview Article：Profile 負責快速說明 Project 身份與狀態，這裡則說清楚產品流程、上游能力、實際媒體證據，以及哪些數字只是某一次 recorded output，而不是通用 benchmark。

GPU 先解決哪一段問題？

路線的距離與高度仍然要先被整理；GPU 解決的是「把已整理的場景畫出來並輸出成影片」這一段。公開 repository 的主流程是 Windows native Rust desktop app：先用 D3D11/Direct2D（Windows 的繪圖 API）畫出地圖與路線，再放進 NVIDIA RTX texture（GPU 可直接讀寫的畫面緩衝），由 NVENC（NVIDIA 的硬體編碼器）轉成 HEVC（High Efficiency Video Coding，也就是 H.265）或 H.264，最後封裝成 MP4。

README 也明確說明它需要 Windows 10/11 x64、具備 NVENC 的 NVIDIA RTX GPU，且不接受 Intel、AMD、Microsoft WARP 或 CPU fallback。因此，「GPU-first」在這裡不是把任何電腦都宣稱成 GPU 輸出，而是把硬體前提寫進產品契約：不符合條件就拒絕輸出，讓執行路徑和證據保持一致。

載入一份 GPX 路線

以一段 0706 route run 為例，程式載入後會顯示：

讓「不禮讓行人」變成可回看的事件：YOLOv8 × DeepSORT

Sat, 01 Aug 2026 09:30:00 +0800

雨天街景裡，車輛、行人和斑馬線可能同時出現在一格畫面中；但「這台車是否在行人通過時讓行」不是單格影像能直接回答的問題。YOLO Right-of-Way Recognition 這個大學畢業專題的核心嘗試，是把一段影片轉成可以回看、檢查、討論的候選事件，而不是把一張圖片的框線直接當成交通違規判決。

本文是這個 Project 的 Overview Article：先說明畫面裡的事件如何形成，再回到真實的桌面操作、輸出影格與證據邊界。專案在作品集裡被標為 Featured，是因為它代表一段完整的學術與工程作品；這個標記不等於已驗證的偵測準確率或 production readiness。

為什麼單格偵測不夠？

影片進入系統後，YOLOv8（You Only Look Once 第 8 版）會在每一格畫面裡找出行人、車輛、機車和斑馬線；這一步是物件偵測，輸出是帶有類別與位置的框線。單格結果能回答「這裡可能有什麼」，卻不能回答「前後畫面的同一台車怎麼移動」。

因此專案再使用 DeepSORT（Deep Simple Online and Realtime Tracking）。它是一種跨畫面追蹤方法，會替偵測到的物件保留 ID，也就是識別同一個物件的編號，讓程式能把前後畫面的 car:6 視為同一個追蹤對象，而不是每格都重新編號。最後，場景規則把物件位置、斑馬線區域、車輛方向與移動軌跡放在一起，才形成「可能未禮讓」的提示。

這個分工很重要：YOLOv8 負責看見物件，DeepSORT 負責維持跨畫面的身份，規則層負責把連續觀察轉成事件提示。畫面上的 Fail to yield to pedestrians 不是 YOLOv8 單獨預測的類別，也不是法律判定。

影片畫面同時顯示偵測框、物件編號、斑馬線區域和事件提示。它展示了系統如何把分析結果疊回影片，不代表整體準確率。

使用者實際怎麼跑一次分析？

這不是只能從命令列呼叫的模型。README 和 controller.py 所描述的桌面流程，把輸入、模型、輸出與進度放在同一個 PyQt5 介面中。一次分析大致會經過：

選取一個或多個 .mp4、.avi 或 .mkv 影片，指定輸出資料夾，再從 yolov8s、yolov8l、yolov8x6 中選擇模型。README 以速度與辨識能力描述這三個選項的取捨；專案沒有在公開頁面提供可比較的評估基準（benchmark），所以不能把這些標籤寫成實測準確率。

接著使用者可以選擇兩種模式：闖紅燈偵測，或車輛不禮讓行人偵測。若影片角度不適合規則判斷，也可以先在校正頁調整旋轉角度，再把校正後的畫面交給後續流程。處理單部或多部影片時，介面會顯示目前影片和全部影片的進度。

載入影片後，使用者可在同一個視窗預覽畫面、選擇模型與偵測方式，並控制播放。這呈現的是操作流程，不是模型準確率。

角度校正解決了什麼？

角度校正不是讓模型突然變準，而是先把輸入影像轉成比較符合場景規則假設的方向。對斑馬線區域、道路方向與物件位置而言，這能減少「畫面歪了，規則也跟著難以解讀」的操作問題。

旋轉校正前的輸入畫面。

旋轉後，影片方向已校正；這只改變輸入畫面，不代表後續事件判斷一定正確。

開始處理後，預覽畫面會顯示目前的影片狀態，單部影片與整批影片的進度列也會更新。這裡的進度條是使用者工作流證據：它顯示程式把影片處理當成可觀察的批次工作，而不是直接證明輸出內容的正確性。

介面同時顯示目前影片和整批影片的處理進度。

什麼證據能支持這個故事？

目前最直接的證據是三類真實輸出：桌面介面截圖、旋轉校正前後的影像，以及輸出影片中的偵測影格。它們回答的是不同問題：介面截圖說明使用者如何操作，校正影像說明輸入如何被整理，輸出影格說明偵測與規則結果如何被寫回影片。

輸出前的原始畫面，可與後續結果對照。

LadaGAN 做得太逼真之後：一場生成器與判別器的拉鋸

Sat, 01 Aug 2026 09:00:00 +0800

這是我在國立東華大學資訊工程學系「深度學習基石與實務」課程的第二個作業。我負責把在 CelebA 上訓練 LadaGAN、建立可追蹤的 synthetic dataset，以及訓練真假影像判別器接成一條完整 pipeline；本文是這個已完成 Project 的 Overview Article，不把課程作業包裝成正在維護的產品。

我一開始把問題想得很直覺：生成器越逼真，成果就越好。真正跑過幾輪模型之後，才發現事情沒有這麼單純。生成器越接近真實資料，判別器越難找到可以泛化的線索；判別器若只記住資料前處理或某一個 checkpoint 的風格，漂亮的 accuracy 也沒有太大意義。這篇文章保留模型失敗、中間 epoch、loss 曲線與評估圖，記錄我如何在清晰度、多樣性、穩定性和運算成本之間做取捨，也把報告中的數字與它們不能證明的事情分開。

這個實驗真正要回答什麼？

這份作業的目標不是只交出一張「看起來像人臉」的圖片，而是一條可以被檢查、被重跑的影像生成與分類流程：

在 CelebA 上訓練 LadaGAN，產生有多樣性的 64×64 人臉。
依報告記錄的不同 epoch checkpoint，從每個 checkpoint 生成固定數量的圖片，建立足夠大的 synthetic dataset。
把真實圖片和生成圖片混合，訓練多個影像分類模型，找出比較能辨識兩種影像分布的判別器。
使用最後的 EfficientNetV2-B1 對測試資料做真偽判斷，輸出 test.csv。

所以我想回答的問題不是「能不能生成一張好看的臉」，而是：

當生成器已經做得很逼真時，判別器到底還能不能學到穩定、可泛化的差異？

為什麼要把生成與判別放在同一條 pipeline？

HackMD 報告把整個工作拆成三個階段。第一階段訓練 LadaGAN；第二階段從生成 checkpoint 建立判別器資料；第三階段用教師提供的 1,000 張測試圖片產生最後的分類結果。

依照目前 repository README 與原始 HackMD 報告整理的 LadaGAN pipeline；這是 structural diagram，不是一次執行的 runtime trace。

箭頭表示資料與模型的先後關係：生成器先留下多個 checkpoint，再從它們建立 synthetic faces；判別器的資料集才把 real 與 fake 合併，最後輸出評估結果或教師測試集的 test.csv。圖中最重要的界線是 30,000 張評估資料與 1,000 張盲測圖片不是同一組資料。

從 SQL 到 Text-to-SQL：讓資料庫聽懂人話

Fri, 31 Jul 2026 10:00:00 +0800

公司、醫院、學校和政府每天都在累積資料，但「資料存在」不代表「每個人都能使用」。很多時候，我們知道自己想問什麼，卻不知道資料放在哪張表，也不知道該怎麼寫 SQL。

我的碩士論文研究的，就是如何讓使用者直接用自然語言提問，再由系統自動產生可以執行的 SQL。這項技術稱為 Text-to-SQL。

這篇文章是 AAP-SQL Project 的 Overview Article：它提供足夠的資料庫與 Text-to-SQL 背景，讓沒有先讀 Project Profile 的讀者也能理解研究問題、方法、結果與限制。論文本身是 Project 的 Milestone；研究實作、設定與重現邊界則保留在 AAP-SQL 公開 repository，論文書目與全文入口可由 Handle 永久連結查閱。

不過，在介紹我的方法之前，我想先從最基本的問題開始：資料庫到底長什麼樣子？SQL 又在做什麼？

先認識資料庫：表、欄位與資料列

關聯式資料庫可以想成一組彼此有關聯的試算表。假設一間商店有兩張表：

顧客表 customers

customer_id	name	city
101	Amy	Taipei
102	Bob	Tainan

訂單表 orders

order_id	customer_id	amount
9001	101	1200
9002	101	650
9003	102	800

直向的 name、city、amount 稱為欄位，描述資料具有哪些屬性；橫向的每一筆內容稱為資料列。整個資料庫有哪些表、欄位與型別，合起來稱為 Schema（資料庫結構）。

其中，customers.customer_id 是每位顧客不重複的編號，稱為主鍵。orders.customer_id 則指向顧客表中的同名編號，稱為外鍵。靠著這個關係，我們才知道訂單 9001 和 9002 都屬於 Amy。

真實資料庫當然比這複雜得多：可能有數十張表、數百個欄位，而且名稱常是縮寫。使用者只看到「顧客」和「訂單」，系統看到的卻可能是 cust_info、txn_hdr 和一大串編號。

SQL 是怎麼向資料庫提問的？

SQL（Structured Query Language）是操作關聯式資料庫的語言。若要找出住在台北的顧客，可以寫：

在本地 Docker 執行 n8n，並用 Cloudflare Tunnel 接收 Webhook

Thu, 31 Jul 2025 11:00:00 +0800

本地的 n8n 可以在 localhost:5678 正常執行，但外部服務看不到你的 localhost。這也是很多 webhook 教學最容易跳過的地方：容器啟動成功，只代表本機能開啟介面，不代表 GitHub、付款服務或其他雲端服務能把 HTTP 請求送進來。

這篇文章整理一條 2025 年在 Windows 上實作過的路徑：用 Docker 保存 n8n 資料，再用 Cloudflare Tunnel 把一個公開主機名稱路由到本機服務。命令與介面會隨 n8n、Docker Desktop 和 Cloudflare 的版本改變；文末會標出今天仍可沿用、以及必須重新核對的部分。

先分清楚：本機服務和公開 webhook

n8n 是以工作流程節點串起資料輸入、處理與輸出的自動化平台。當 webhook 節點顯示 http://localhost:5678/... 時，它只是在本機監聽。外部服務無法把請求直接送到你的私有網路，所以需要一個公開入口，再由入口把流量轉回本機。

這不是把 n8n 的管理介面「免費放到網路上」的同義詞。公開入口增加了攻擊面，應該只發布必要的 hostname 與 route，並為 n8n、憑證和 webhook payload 設定適當的安全策略。

Docker 只負責讓 n8n 穩定地跑起來

原始實作使用 n8nio/n8n 映像與 /home/node/.n8n 掛載路徑。持久化 volume 的重點是保留 workflow、credential 加密資料、設定與執行紀錄；若只用 --rm 而沒有掛載資料，容器刪除後就會失去本機狀態。

目前 n8n 官方仍提供單容器命令，但已在該頁標示 Docker Compose 是推薦路徑；官方也提醒 self-hosting 需要自行處理資源、安全與更新。下面的命令只示範本機驗證，並不宣稱是 production 部署：

docker volume create n8n_data
docker run -it --rm \
 --name n8n \
 -p 5678:5678 \
 -e GENERIC_TIMEZONE="Asia/Taipei" \
 -e TZ="Asia/Taipei" \
 -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
 -v n8n_data:/home/node/.n8n \
 n8nio/n8n

啟動後，先在本機確認 http://localhost:5678 可以打開並完成初始設定。若目標是長期執行，應改讀官方 Docker Compose 範例、固定映像版本、保存 encryption key、設定備份與更新流程；latest 是可變的標籤，不應當成可重現版本。

Gemini Balance 部署體驗：從零開始的AI代理服務搭建心得

Sun, 13 Jul 2025 10:30:00 +0800

前言

在探索AI服務部署的過程中，我發現了一個非常實用的項目 - Gemini Balance。這是一個專為 Gemini API 設計的輪詢代理服務，能夠實現負載均衡、API密鑰管理和使用監控等功能。本文將分享我從零開始部署這個服務的完整體驗和心得。

什麼是 Gemini Balance？

Gemini Balance 是一個開源的 Gemini API 代理服務，主要特色包括：

負載均衡：支援多個 API 密鑰輪詢使用
使用監控：提供詳細的 API 使用統計和監控面板
訪問控制：支援自定義訪問令牌管理
數據持久化：支援 SQLite 和其他數據庫存儲
易於部署：支援多種部署平台

技術架構分析

核心組件

Gemini Balance 的技術架構包含以下核心組件：

代理服務器：處理 API 請求轉發和負載均衡
監控模組：收集和展示使用統計數據
數據存儲：SQLite 數據庫存儲配置和統計信息
Web 界面：提供管理和監控功能

負載均衡策略

服務採用輪詢（Round Robin）策略進行負載均衡：

請求分發：按順序將請求分配給不同的 API 密鑰
故障轉移：當某個密鑰出現問題時自動切換
使用統計：記錄每個密鑰的使用情況和響應時間

架構流程圖

graph TD A[客戶端請求] --> B[Gemini Balance 代理] B --> C{負載均衡器} C --> D[API Key 1] C --> E[API Key 2] C --> F[API Key N] D --> G[Gemini API] E --> G F --> G G --> H[響應結果] H --> I[統計記錄] I --> J[監控面板] H --> A

這個架構確保了：

MCP 客戶端建置與設定教學

Tue, 08 Jul 2025 10:00:00 +0800

我們將說明如何建置與設定 MCP 客戶端，特別聚焦於 RooCode 工具與本地模型的整合，以及實際的應用。

1. 安裝與設定 Roo code

roo code 是一款支援本地 AI 助手的 VS Code 擴充套件。安裝步驟如下：

前往 Visual Studio Marketplace 或Extensions 搜尋「Roo code」並點擊安裝。
安裝後，Roo code 圖示會出現在 VS Code 側邊欄。

2. 本地模型支援

Roo code 支援多種本地模型，包括 Ollama、LM Studio 等。這些工具可讓你在本地運行大型語言模型（LLM），並與 MCP 協議整合。

如何使用N8N來建立一個自動化部落格訂閲系統

Sat, 05 Jul 2025 11:00:00 +0800

如果你也要做一個電子報系統在 Huggingface Spaces 上了話，可能會遇到以下問題，可以參考這篇文章

2025年7月31日

在本地 Docker 執行 n8n，並用 Cloudflare Tunnel 接收 Webhook

從本地 Docker 執行 n8n 的基本路徑出發，理解為什麼 webhook 需要公開入口，以及 Cloudflare Tunnel 在這裡解決的邊界。

Tommy Pan 閱讀更多 →

Hugging Face Spaces 部署指南

Mon, 23 Jun 2025 10:00:00 +0800

前言

當你嘗試按照官方指引部署 Hugging Face Spaces 時：

git init
git add app.py requirements.txt
git commit -m "Initial commit"
git remote add origin https://huggingface.co/spaces/YOUR_USERNAME/mcp-sentiment
git push -u origin main

你可能會遇到各種錯誤。本指南將帶你逐步解決這些問題，並成功部署到 Hugging Face Spaces。

為什麼原始指令無法運作？

自 2023 年 10 月 1 日起，Hugging Face 停止支援密碼身分驗證，因此當你使用 HTTPS URL 推送時，會收到以下錯誤訊息：

remote: Password authentication in git is no longer supported.
You must use a user access token or an SSH key instead.

第一步：建立 Hugging Face Space

前往 huggingface.co/spaces
點選「Create new Space」
填寫以下資訊：

Owner: 選擇你的使用者名稱或組織
Space name: 輸入名稱（例如：mcp-sentiment）
License: 選擇授權條款
Space SDK: 選擇 Gradio
Hardware: 選擇 CPU basic（免費）
Visibility: 選擇 Public 或 Private

第二步：準備專案檔案

建立 requirements.txt

使用 Gradio MCP 建立伺服器，并部署在Hugging Face Space

Mon, 23 Jun 2025 10:00:00 +0800

Gradio MCP 整合介紹

Gradio 透過自動將您的 Python 函數轉換為 MCP 工具，提供了一種簡單的方式來創建 MCP 伺服器。當您在 launch() 中設置 mcp_server=True 時，Gradio 會：

自動將您的函數轉換為 MCP 工具
將輸入元件映射到工具參數架構
從輸出元件確定回應格式
設置 JSON-RPC over HTTP+SSE 進行客戶端-伺服器通訊
創建網頁介面和 MCP 伺服器端點

專案設置

首先，讓我們為專案創建一個新目錄並設置所需的依賴項：

# Windows

mkdir mcp-sentiment
cd mcp-sentiment
python -m venv venv
source venv/bin/activate
pip install "gradio[mcp]" textblob

創建伺服器

Hugging Face Spaces 需要一個 app.py 檔案來建立 space，所以 Python 檔案的名稱必須是 app.py 創建一個名為 app.py 的新檔案，包含以下程式碼：

import json
import gradio as gr
from textblob import TextBlob

def sentiment_analysis(text: str) -> str:
 """
 分析給定文本的情感。

 Args:
 text (str): 要分析的文本

 Returns:
 str: 包含極性、主觀性和評估的 JSON 字串
 """
 blob = TextBlob(text)
 sentiment = blob.sentiment

 result = {
 "polarity": round(sentiment.polarity, 2), # -1 (負面) 到 1 (正面)
 "subjectivity": round(sentiment.subjectivity, 2), # 0 (客觀) 到 1 (主觀)
 "assessment": "positive" if sentiment.polarity > 0 else "negative" if sentiment.polarity < 0 else "neutral"
 }

 return json.dumps(result)

# 創建 Gradio 介面
demo = gr.Interface(
 fn=sentiment_analysis,
 inputs=gr.Textbox(placeholder="輸入要分析的文本..."),
 outputs=gr.Textbox(), # 從 gr.JSON() 改為 gr.Textbox()
 title="文本情感分析",
 description="使用 TextBlob 分析文本情感"
)

# 啟動介面和 MCP 伺服器
if __name__ == "__main__":
 demo.launch(mcp_server=True)

程式碼理解

分析關鍵元件：

在 OBS 用 Zoom-to-Mouse 聚焦游標：一則安裝筆記

Mon, 23 Jun 2025 10:00:00 +0800

錄製程式教學時，游標常常知道自己正在指哪裡，但觀眾不一定看得清楚。OBS Zoom-to-Mouse 是一支 Lua script，能在 OBS Studio 裡讓指定的 Display Capture 來源以游標位置為焦點縮放，再用熱鍵切回原本畫面。這篇只保留一條可重現的安裝路徑，並把相容性限制說清楚；它是一則 focused Note，不是完整的 OBS 錄影教學。

這支腳本改變的是哪個畫面？

腳本不是在作業系統桌面上放大滑鼠，也不是替影片後製加上特效。它會讀取 OBS 場景中的顯示擷取來源，利用 crop/pan 的方式改變可見區域，讓游標附近看起來被放大。上游 README 也提醒，顯示器排列、裁切、縮放比例或非 Display Capture 來源不符合預期時，腳本可能需要手動提供來源位置與尺寸。

原始文章保存的上游資源頁面；下載前應以原作者 repository 的最新版本與說明為準。

安裝和啟用只需要三個位置

從 OBS Zoom-to-Mouse 的原作者 repository 下載 obs-zoom-to-mouse.lua。
在 OBS 中打開 Tools → Scripts，按 + 載入 Lua script。
在 File → Settings → Hotkeys 為 Toggle zoom to mouse 綁定快捷鍵；若要獨立控制游標跟隨，再設定 Toggle follow mouse during zoom。

原始安裝步驟中的 Scripts 設定畫面；選取的來源與欄位名稱會依 OBS 或腳本版本改變。

載入後，先在腳本設定選擇要縮放的 Display Capture，再錄一小段測試影片。按一次熱鍵應該以目前游標位置作為放大焦點；再按一次還原。若啟用自動跟隨，游標接近放大區域邊界時，畫面才會繼續移動。

了解MCP能力以及部署到Anaconda

Sun, 22 Jun 2025 10:00:00 +0800

MCP 主要有下列四個功能類型，分別對應著不同的使用情景

工具（Tools）

工具是AI模型可以通過MCP協議調用的可執行函數或行動。

控制：工具通常是由模型控制的，意味著AI模型（LLM）根據用戶的請求和上下文決定何時調用它們。
安全性：由於工具執行具有副作用的操作的能力，因此工具的執行可能會很危險。因此，它們通常需要用戶的明確批准。

範例：取得給定位置的當前天氣資料的天氣工具：

def get_weather ( location: str ) -> dict :
 """取得指定位置的目前天氣。"""
 # 連接到天氣 API 並取得資料
 return {
 "temporary" : 72 ,
 "conditions" : "Sunny" ,
 "humidity" : 45
 }

資源（Resources）

資源是AI模型可以訪問唯讀的數據源。

控制應用程式控制：資源由應用程式控制，這意味著主機應用程式通常決定何時存取它們。
安全性：由於它們是唯讀的，因此它們的安全風險通常比工具低。

實例：存取檔案內容、檢索資料庫記錄、讀取設定資訊。範例：提供對文件內容的存取的資源：

def read_file ( file_path: str ) -> str :
 """讀取指定路徑下檔案的內容。"""
 with open (file_path, 'r' ) as f:
 return f.read()

提示詞（Prompts）

提示詞是可重用的指令段，用於指導AI模型執行特定任務。

控制使用者控制：提示由使用者控制，通常作為主機應用程式 UI 中的選項呈現。
目的：想辦法將使用工具以及資源的方式最佳化。
選擇：使用者通常在 AI 模型開始處理之前撰寫提示詞。
用例：常見的工作流程、專門的任務範本、引導式互動。

範例：審查程式碼

def code_review(code: str, language: str) -> list:
 """Generate a code review for the provided code snippet."""
 return [
 {
 "role": "system",
 "content": f"You are a code reviewer examining {language} code. Provide a detailed review highlighting best practices, potential issues, and suggestions for improvement."
 },
 {
 "role": "user",
 "content": f"Please review this {language} code:\\n\\n```{language}\\n{code}\\n```"
 }
 ]

取樣(sampling)

採樣允許伺服器請求客戶端（具體來說，主機應用程式）執行 LLM 互動。

MCP 通信協議

Sat, 21 Jun 2025 10:00:00 +0800

MCP 定義了一套標準化的通信協議，使客戶端和服務器能夠以一致、可預測的方式交換資訊。這種標準化對於整個社區的互操作性至關重要。

JSON-RPC：基礎架構

MCP 的核心使用 JSON-RPC 2.0 作為客戶端和服務器之間所有通信的消息格式。JSON-RPC 是一種輕量級的遠程過程調用協議，以 JSON 編碼。

JSON-RPC 特點

人類可讀性強，易於調試
語言無關性，支援在任何編程環境中實現
成熟穩定，具有清晰的規範和廣泛的採用

三種消息類型

MCP 使用三種基本消息類型進行通信：

1.請求（Requests）

從客戶端發送到服務器以啟動操作。請求消息包括唯一標識符、要調用的方法名稱和方法的參數（如果有）。

{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "tools/call",
 "params": {
 "name": "weather",
 "arguments": {
 "location": "San Francisco"
 }
 }
}

2.響應（Responses）

從服務器發送到客戶端以回覆請求。響應消息包括與相應請求相同的 id 和 result（成功時）或 error（失敗時）。

// 成功響應示例
{
 "jsonrpc": "2.0",
 "id": 1,
 "result": {
 "content": [
 {
 "type": "text",
 "text": "San Francisco 今天的溫度是 22°C"
 }
 ]
 }
}

// 錯誤響應示例
{
 "jsonrpc": "2.0",
 "id": 1,
 "error": {
 "code": -32000,
 "message": "無法取得天氣資料"
 }
}

3.通知（Notifications）

單向消息，不需要響應。用於事件通知或狀態更新。通知消息沒有 id 欄位。

MCP 架構組件

Fri, 20 Jun 2025 10:00:00 +0800

客戶端-服務器架構

Model Context Protocol (MCP) 建立在客戶端-服務器架構上，該架構支援 AI 模型與外部系統之間的結構化通信。

三大核心組件

MCP 架構由三個主要組件組成，每個組件都有明確定義的角色和責任：

1. 主機 (Host)

使用者直接使用的 AI 應用程式，如 ChatGPT 或 Cursor。負責處理使用者請求、介面呈現和整體協調。

主要責任：用戶交互界面、請求路由、結果呈現
特性：可同時管理多個客戶端連接

2. 客戶端 (Client)

主機內的組件，負責與服務器通信。一個客戶端只連接一個服務器，但主機可有多個客戶端。

主要責任：協議谈判、消息傳輸、連接管理
特性：1:1 關係（一個客戶端對一個服務器）

3. 服務器 (Server)

提供外部功能的程式，如搜尋引擎、數據庫連接或檔案操作等。可在本地或遠端運行。

主要責任：執行具體功能、返回結果、管理狀態
特性：獨立部署，支援多個客戶端連接

MCP 通信流程

下面展示了 MCP 組件之間的通信流程：

Model Context Protocol (MCP) 基礎概念

Tue, 17 Jun 2025 14:30:00 +0800

爲什麽不能單靠LLM來解決事情

雖然大型語言模型（LLM）能憑訓練語料生成近似人類的回答，但它若缺乏對外部世界的即時存取，就難以讀取企業專屬資料或主動執行工具操作。

MCP 概述：AI 應用程式的 USB-C

Model Context Protocol (MCP) 正在重新定義 AI 應用程式與外部世界的互動方式。作為由 Anthropic 在 2024 年底推出的開放標準，MCP 解決了長期困擾 AI 開發者的整合複雜性問題，為整個生態系統帶來了前所未有的標準化和互操作性。

什麼是 Model Context Protocol？

Model Context Protocol 是一個開放的通信協議，專門設計用於標準化 AI 模型與外部數據源、工具和服務之間的交互。該協議建立在 JSON-RPC 2.0 基礎之上，提供了一個輕量級、可擴展的框架，使 AI 應用程式能夠安全、高效地存取外部資源。

MCP 的核心理念是創建一個統一的接口層，讓 AI 模型能夠無縫地與各種外部系統進行通信，而無需為每個特定的整合開發自定義解決方案。這種標準化方法不僅降低了開發複雜度，還提高了整個 AI 生態系統的互操作性。

AI 應用程式的 USB-C

MCP 常被稱為「AI 應用程式的 USB-C」。就像 USB-C 為各種外設提供標準化的連接介面一樣，MCP 為 AI 模型連接外部功能提供了一致的協議。

生態系統受益者

使用者：能在各種 AI 應用程式中享受更簡單、一致的體驗
AI 應用程式開發者：可輕鬆整合不斷成長的工具和資料來源生態系統
工具和資料提供者：只需建立一個實現方案，即可與多個 AI 應用程式配合使用
更廣泛的生態系統：受益於提升的互通性、創新力，以及降低的碎片化

M×N 整合問題

在討論 MCP 的核心概念之前，我們首先需要理解它試圖解決的關鍵問題。