跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

具有 10 年經驗在數位行銷與電商廣告領域，專精生成式AI應用與個人資料保護，致力於以獨特商業洞察與實戰案例研討，助力品牌突破成長瓶頸。

分類

標籤

商業策略 (31) AI自動化 (83) AI工具 (70) AI Agent (48) SEO (13) AEO (8) 內容行銷 (26) Cursor (2) Vibe Coding (42) Codex (12) MCP (2) 影音行銷 (36) Gemini (11) AI Coding (1) Meta Ads (1) Higgsfield (1) AI風險控管 (5) NotebookLM (1) GEO (1) ChatGPT (17) AI繪圖 (8) n8n (28) API串接 (13) 社群行銷 (4) 自動化講師應用 (6) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Cloudflare (5) Claude (5) 工作流 (1) 享哥宇宙 (10) 科幻喜劇 (8) AI故事 (8) 技術選型 (1) Electron (1) Tauri (1) 奇幻喜劇 (2) 台灣民間信仰 (2) Git (1) 知識變現 (4) Google (1) Google Vids (1) GSAP (1) n8n新手教學 (11) Zeabur (1) Remotion (2) Antigravity (1) 前端架構 (1) PWA (1) 資料處理 (1) 個人品牌 (1) Power Automate (1) Playwright (1) 職場溝通 (2) LINE (1)
  • article-Public APIs 開始收錄 MCP Server：48 萬 Star 的工具清單怎麼用？

    2026/10/1

    AI工具 AI Agent MCP
    Public APIs 開始收錄 MCP Server：48 萬 Star 的工具清單怎麼用？

    最近整理 Skill Library 時，我發現自己收藏了不少 MCP，真正要做事時卻還是得重新搜尋：「有沒有 Gmail MCP？」「哪個 MCP 能查 YouTube？」接著逐一看 README、確認維護狀況、安裝方式和需要的權限。 這讓我重新注意到 GitHub 上的 public-apis/public-apis 專案。它原本以公開 API 分類清單聞名，現在也加上 MCP Servers 區塊。我查閱時，GitHub 顯示約 48.5 萬顆 Star；電腦王阿達在 2026 年 9 月 5 日的介紹則記錄當時已超過 47 萬顆。Star 數會變動，這裡的數字只是查閱時的快照。 比起多收藏一個目錄，我更想建立一個流程：先說清楚工作需要什麼能力，再讓 Agent 找候選工具、比較限制，最後才決定要不要安裝 MCP。 Public APIs 的 MCP 清單有什麼不同？Public APIs 原本把公開 API 依用途分類，例如 Weather、Finance、Email、Geocoding、Government、Video 等。清單除了名稱與說明，也會列出驗證方式、HTTPS 和 CORS 等資訊，方便開發者先篩選資料來源。 README 現在另有 MCP Servers 表格，欄位包含名稱、用途、驗證方式、Transport 和安裝入口。查閱時可看到 OpenSwissData、IPstack MCP、GitHub、Filesystem 等項目。這些資料讓讀者先比較需要什麼驗證、支援哪種傳輸方式，再前往專案或安裝目錄查看細節。 它的特色不是 MCP 數量最多，而是從「我需要天氣、金融或檔案能力」這類需求出發，再找可能的 API 或 MCP。要做天氣網站，直接呼叫 API 也許就夠；若 Agent 要在多次任務中反覆查詢或執行操作，MCP 才可能比較合適。 另外，清單名稱裡的「免費 API」不代表每個服務都能無限制免費使用。實際費率、免費額度、API Key 和使用條款都要再到服務官方文件確認。 API、MCP 和 Skill 各自負責什麼？這三者不是互相取代的工具，而是處理不同層次的問題： 元件 負責的事情 常見用法 API 服務提供的資料或操作介面 網站或程式依服務文件發送請求、處理回應 MCP Server 依 MCP 協定，把工具或其他上下文能力提供給相容的 Agent 讓 Agent 透過標準介面呼叫搜尋、檔案或服務工具 Skill 說明 Agent 怎麼完成一類工作 把需求拆解、檢查步驟和交付格式整理成可重複使用的 SOP MCP Server 有時會在背後呼叫 API，但 MCP 並不是 API 的另一個名稱；有些 API 也沒有對應 MCP。Skill 則可以教 Agent 如何呼叫已設定的 MCP，也可以規定何時直接用 API。 若你還想釐清 MCP、Skill 與 CLI 的分工，可以接著看一次搞懂 MCP、Skill 與 CLI 的差異。Skill 與 Plugin 的組合方式則整理在從個人工作流到團隊交付。 找 MCP 時可以先看哪幾個地方？我會依照需求和想確認的資訊，從以下入口開始找。它們的定位不同，搜尋結果也不等於品質或安全保證。 1. Official MCP Registry：查官方登錄資料Official MCP Registry 是 MCP 專案提供的公開 Server 目錄，可以搜尋 Server 名稱與版本，並查看其 metadata。它適合用來確認某個項目是否有公開登錄，以及對應的專案或套件資訊。 不過，「出現在 Registry」不等於「經過完整安全審核」。Registry 的資料由 Server 維護者發布，使用者仍要核對來源、版本和權限；官方說明也提到社群可檢舉違規項目，由維護者處理。 2. Public APIs：從需要的能力開始找如果你還不確定該找 API 還是 MCP，可以先按資料類型或用途查 Public APIs。MCP 區塊的清單目前較精簡，優點是會把 MCP 放在原有 API 資源旁邊，讓你比較是直接呼叫 API，還是透過 Agent 使用 MCP。 3. Glama：用搜尋與篩選比較大量候選Glama MCP Servers 提供伺服器索引與搜尋，頁面可按更新日期、GitHub Star、套件下載量等條件排序。網站在 2026 年 10 月 1 日查閱時顯示約 94,668 個 Server。索引數量會改變，應以網站當下顯示為準，也別只看總數或 Star 就決定安裝。 4. Smithery：搜尋並查看伺服器管理入口Smithery 提供類別與條件篩選，並展示部分 Server 的使用資訊。頁面在 2026 年 10 月 1 日查閱時顯示 13,151 個搜尋結果。平台和目錄功能可能持續調整，因此安裝方式、方案和服務狀態要回到當下的官方說明確認。 5. GitHub 與服務官方文件：確認實作細節找到候選項目後，接著查它連結的原始 Repository 和服務官方文件。目錄摘要可以幫你發現項目，卻無法代替版本紀錄、License、安裝需求、OAuth 範圍、API 費用及原始碼審查。 用 MCP Scout 把搜尋變成工作流程與其在看到「必裝 MCP 清單」時一律先收藏，我會希望 Agent 在開始實作前先做需求分析：完成任務需要哪些資料、外部服務和操作權限？是否已經有可用的 MCP？直接呼叫 API 或使用 CLI 會不會更簡單？ 這個想法可以整理成一個 MCP Scout Skill。它不負責直接替你安裝工具，而是先找候選、標示來源與限制，再提出方案供你決定： 1234567891011121314151617181920你是我的 MCP Scout。我要完成以下工作：{{工作需求}}先分析需求並搜尋工具，不要直接開始實作、安裝或執行候選項目。第一階段：拆解需求列出完成工作需要的資料、操作與外部服務，例如搜尋、檔案、Database、Email、Calendar、Browser 或 SaaS。第二階段：搜尋候選依序查看 Official MCP Registry、public-apis/public-apis、Glama、Smithery、GitHub 與服務官方文件。最多列出 3 個候選，附上來源連結；清楚標示官方或社群專案，找不到證據時不要猜。第三階段：比較限制逐一整理提供的 Tools、Repository、License、最近更新、Transport、Agent 相容性、API Key 或 OAuth、費用、權限範圍，以及是否會讀寫本機檔案或執行 Shell。每個判斷都附上可查證的來源。第四階段：提出選擇比較使用現有 MCP、直接使用 API／SDK／CLI，或自行建立 MCP 的建置時間、維護成本、安全性、穩定性與可移植性，說明適合的方案與原因。先交付搜尋結果與建議，等待我確認後才進行安裝或授權設定。 這段流程的重點是先把需求和風險攤開來，不要讓搜尋結果直接變成安裝指令。MCP Scout 可以協助找資料，但不能只憑目錄標籤就替候選項目背書。 不需要為每件事都加上 MCP我會用三個問題快速選擇： 只是要取得一份資料或完成一次操作？ 先看 API、SDK 或 CLI 是否更直接。 Agent 是否要在不同任務中反覆使用同一項能力？ 再評估 MCP 的介面和維護成本。 真正需要保存的是工作步驟嗎？ 把判斷方法整理成 Skill；需要工具時，再讓 Skill 指向 API 或 MCP。 例如天氣網站可以直接呼叫天氣 API；如果多個 Agent 都要在對話中查詢天氣、比較時段並安排活動，MCP 可能更容易重複使用。工具是否值得封裝，仍取決於實際使用頻率、權限需求和維護成本。 最後，我想收藏的不是更多 MCP 名稱，而是一條遇到需求時找工具、核對來源、比較限制的路徑。當 Skill 知道何時呼叫 MCP，Agent 又知道缺工具時該去哪裡找，工具庫才會從收藏清單變成真正能使用的工作流程。 常見問答 (FAQ)Q1：Public APIs 的 MCP Servers 清單適合拿來做什麼？它適合從 API 類別或能力需求出發，快速發現少量相關 MCP，並查看簡介、驗證方式、Transport 和安裝入口。找到候選後，仍應到 Repository 和官方文件確認細節。 Q2：要去哪裡搜尋 MCP Server？可以先看 Official MCP Registry 的登錄資料，再用 Public APIs 按需求找候選，或用 Glama、Smithery 搜尋和篩選。最後回到 GitHub Repository 及服務官方文件確認版本、授權、費用與權限。 Q3：怎麼判斷 MCP Server 是否適合安裝？至少要確認維護者與 Repository、License、最近更新、安裝程序、Transport、憑證和費用，以及它要求的檔案、網路或 Shell 權限。目錄列出項目不等於安全認證；對高權限工具，應先檢查程式碼並在受限環境評估。 Q4：MCP、API 和 Skill 要怎麼選？一次性或單純的資料請求可先用 API、SDK 或 CLI；需要讓 Agent 以一致介面反覆呼叫的能力，可評估 MCP；需要重複遵循的工作方法則適合整理成 Skill。三者也能搭配使用。 Q5：MCP Scout 可以自動安裝它找到的 MCP 嗎？MCP Scout 可以整理需求、搜尋候選和比較限制，但搜尋結果不能代替程式碼審查或權限判斷。建議先讓它提交來源和評估結果，經人確認後再安裝、提供憑證或授予本機權限。 參考資料 電腦王阿達｜Public APIs 免費 API 資源庫介紹 GitHub｜public-apis/public-apis MCP 官方專案｜Introducing the MCP Registry Official MCP Registry Glama MCP Servers Smithery

  • article-華為「天才少年」把 AI Agent 寫成一本開源教科書，這幾章最值得先啃

    2026/9/22

    AI Agent Codex MCP
    華為「天才少年」把 AI Agent 寫成一本開源教科書，這幾章最值得先啃

    最近看到一個 GitHub 專案時，我原本以為又是一本 AI Agent 教學。 點進去之後才發現，規格有點誇張。 《深入理解 AI Agent：設計原理與工程實踐》不只免費開源，目前的 2.0 版還整理成：10 章正文、109 個配套實驗、PDF、EPUB、繁體中文版與 15 種語言版本，程式碼也一併公開。 我更在意的是，這不是把一堆工具名詞排在一起的入門書。它試圖回答一個更根本的問題：一個能在真實世界工作的 Agent 系統，到底要怎麼被設計出來？ 作者李博杰的背景也讓這件事更有意思。公開資料顯示，他曾就讀中國科大少年班學院，完成中科大與微軟亞洲研究院聯合培養博士，並曾入選華為首批「天才少年」計畫；他的個人資料頁也列出系統、研究與工程相關經歷。中國科大資料與作者個人頁都可交叉參考。 所以我特別想看：一個實際做過系統、Infra、研究與工程的人，會怎麼拆解現在大家都在談的 AI Agent？ 先記住這個公式：Agent = LLM + Context + Tools這本書一開始就把 Agent 壓成一個非常簡單的公式： Agent = LLM + Context + Tools LLM 是大腦：理解、推理、產生下一步。 Context 是它此刻知道什麼：任務、歷史、規則、檔案、記憶與工具描述。 Tools 是它做得到什麼：搜尋、查資料庫、改檔案、跑程式、操作瀏覽器或電腦。 看起來很簡單，但整本書就是沿著這三件事一路拆下去：Coding Agent、MCP、Computer Use、Memory、Multi-Agent，甚至 Agent 如何從執行紀錄持續進化。 這正是我覺得它值得讀的原因。 現在學 Agent，很容易學成「會 n8n、會串 API、會 MCP、會做 RAG、會用 Codex 或 Claude Code」。但這些其實比較像零件。 再往上一層，真正該問的是： 一個好的 Agent 系統，怎麼在正確的時候取得正確資訊、選對工具、完成任務，並且被驗證？ 如果你已經開始用 Codex、Claude Code、MCP 或 Computer Use，我反而不建議一開始從第一章一路線性讀完。下面這幾章會更有感。 第一個最推薦：Context Engineering以前大家都在談 Prompt Engineering；但在 Agent 工作流裡，Prompt 往往只是 Context Engineering 的一小部分。 Agent 表現好不好，很大程度取決於： 它目前到底看到了哪些資訊？ 哪些資料應該放進 Context，哪些要移出去？ Skill 該在什麼時候載入？ 對話與工作紀錄要如何壓縮？ 工具說明要全部塞進去，還是動態發現？ 工作做到一半 Context 撐不住時，系統要怎麼恢復？ 書中的第二章直接談 KV Cache、提示工程、Agent Skills 與 Context Compression。對已經在使用 Coding Agent 的人來說，這一章的價值很高，因為你會開始理解：為什麼同一顆模型放在不同工作環境裡，結果可能差那麼多。 下一階段的競爭未必只是「哪個模型 IQ 更高」，而是： 誰能在正確的時候，把正確的 Context 給模型。 這也和我先前整理的從 Skill 到 Agent Harness很接近：模型能力只是其中一層，工作環境如何供應 Context、工具、規則與回饋，才決定它能不能把任務走完。 第二個必看：Tools 與 MCP第四章談工具，當然也包含 MCP；但我覺得比 MCP 名稱本身更重要的，是它背後的觀念： 工具就是 Agent 的手。 LLM 再聰明，如果只能產生文字，它仍然比較像聊天機器人。 接上搜尋，它能查資料；接上資料庫，它能查詢與寫入；接上 Gmail 或 ERP，它能處理企業流程；接上瀏覽器與 Computer Use，它甚至可以操作沒有 API 的網站與 GUI 軟體。 所以 MCP 不是終點，而是讓模型應用與外部能力更容易連接的介面。真正值得思考的是： Agent 怎麼知道現在需要哪一個工具？ 工具描述是否足以讓它選對？ 它沒有能力時，能不能發現並載入合適的 Skill、MCP 或 API？ 任務結束後，怎麼把不必要的工具說明移出 Context？ 這才是走向通用 Agent 的方向。若你還在釐清 MCP、Skill 與 CLI 的角色分工，可以先讀站內這篇：AI 工具名詞全解析。 第三個可以直接跳讀：Coding Agent這本書有一句我很喜歡： 程式碼，是「可以建立新工具的工具」。 這句話很能解釋，為什麼這一兩年 Coding Agent 會變得這麼重要。 以前的 Agent 遇到沒有工具的事情，可能只能停下來；現在的 Coding Agent 可以嘗試自己寫一個小工具、跑測試、修 bug，再拿這個程式完成原本的任務。 所以 Codex、Claude Code 真正值得注意的地方，不只是「幫你寫程式」，而是它們讓 Agent 開始具備擴充自己能力的能力。 當然，這不代表可以放任 Agent 任意執行。工具權限、Sandbox、測試、Review 與明確的完成條件，仍然是系統設計的一部分。會寫程式不等於任務一定完成；能測試、能回報、能被人驗收，才是可靠的工程流程。 第四個：從 Computer Use 看 Agent 的行動範圍過去自動化多半依賴 API、CLI、MCP 或 Browser Automation。但企業裡有大量系統根本沒有 API：ERP、MES、老舊 Windows 軟體、內部行政平台，甚至只能靠滑鼠點擊的工具。 這時候 Computer Use 的意義，就不只是「AI 會控制滑鼠」。書裡從兩個角度理解它： Observation Space：Agent 可以觀察到多少世界？文字、圖片、語音、螢幕，或實體環境。 Action Space：Agent 可以對世界做多少事？產生文字、呼叫工具、點擊 GUI，甚至控制機器人。 從這條線看，Agent 正在從聊天介面走向可以工作、可以觀察結果、也能根據結果再行動的代理人。 不過，Computer Use 也會把安全與可靠性問題放大：畫面改版、權限不足、不可逆操作、錯誤回饋不清楚，都需要在流程中設計 guardrail，而不是只追求「它能不能點」。 做企業 AI，一定要補：Agent Evaluation我覺得這是現在很多課程最容易略過、但企業最需要的一章。 我們常說 Claude 比較聰明、GPT 比較穩、Gemini 的 Context 比較大，或某個 Agent「感覺」比較好用。但當 Agent 要進入企業流程，不能只靠感覺。 更好的做法是建立自己的任務集，例如 100 個真實任務，然後觀察： 要測什麼 為什麼重要 成功率 任務是否真的被完成，而不只產生看似合理的回答 成本 Token、工具呼叫與人工覆核是否能負擔 延遲 工作流程是否能在可接受時間內交付 人工介入率 哪些步驟仍需要人，以及原因是什麼 重試次數 Agent 是否經常卡住、繞圈或選錯工具 錯誤類型 問題是 Context、工具、權限、模型還是流程設計 最後才有根據決定：哪個模型、哪個 Agent、哪種 Prompt、哪個 Harness，適合這一項工作。 Evaluation 不是最後才補的報表，而是用來推動系統改進的方向盤。 更接近「AI 員工」的關鍵：持續進化我自己也非常想看第九章的 Agent 持續進化。 現在很多所謂 AI 員工，本質上仍是： 固定 Prompt + 固定 Workflow + 幾個工具 它可以每天重複執行，但不一定會從結果學到東西。 更有意思的問題是：Agent 完成一個任務後，能不能留下可分析的執行軌跡（trajectory）？這次為什麼成功？失敗在哪裡？下一次要更新 Knowledge、Prompt、Skill、工具選擇，還是程式碼？ 1234567891011任務 ↓執行 ↓留下 Trajectory ↓分析成功與失敗 ↓更新 Knowledge / Prompt / Skill / Code ↓下一次做得更好 這時候才開始接近「會成長的 AI 員工」，而不只是換了皮的 Chatbot。 前提是，你必須先有明確的成功標準與可觀測紀錄；否則 Agent 留下的只是一大串 log，沒有辦法轉成真正的改善訊號。 Multi-Agent 不是畫一張公司組織圖Multi-Agent 也很容易被玩成「行銷 Agent、PM Agent、工程 Agent、財務 Agent」排成一張組織圖。 但真正困難的工程問題反而是： Agent 之間應該分享多少 Context？哪些資訊必須隔離？ 誰負責拆任務？誰擁有最後決策權？ 交接資料如何結構化，才不會在對話中流失？ Agent 意見衝突時怎麼處理？ 怎麼避免它們彼此聊天、消耗 Token，卻沒有推進結果？ 這些都是協作系統設計問題，不是多開幾個聊天視窗就會自然解決。 如果你已經會用 Agent，我建議這樣讀如果你已經在玩 Codex、Claude Code、MCP 或 Computer Use，我會建議先走這條路： 1234567Context Engineering → Tools / MCP → Coding Agent → Computer Use → Agent Evaluation → Agent 持續進化 → Multi-Agent 再回頭補 Memory / RAG、模型後訓練、SFT / RL，通常會更有感。因為你已經知道這些零件要被放進什麼樣的工作系統裡。 而且這套內容最棒的地方，不是只讓你讀。專案目前提供 109 個配套實驗，很多概念可以直接跑、直接觀察、直接改。比起再追 20 個剛推出的 AI 工具，我更想從中挑出大約 20 個最值得玩的實驗，再拿 Codex、Claude Code、MCP 與 Computer Use 重新實作一次。 工具會換，模型也會換；但 Context 如何設計、工具如何選擇、Memory 如何管理、Agent 如何評估、任務如何拆解、執行紀錄如何轉成改善，才是更能留下來的能力。 如果你最近也覺得 AI 工具已經多到追不完，或許現在正是回頭把「Agent 到底怎麼運作」真正弄懂一次的好時間。 資料來源與延伸閱讀 bojieli/ai-agent-book：深入理解 AI Agent：設計原理與工程實踐 作者李博杰公開個人資料 中國科大：李博杰獲 2017 年微軟學者獎學金 從 Skill 到 Agent Harness：讓 AI 從知道怎麼做，走到真正完成工作 常見問答 (FAQ)Q1：這本《深入理解 AI Agent》適合完全沒有程式背景的人嗎？可以先讀第一章建立全貌，但書內不少實驗需要讀懂並修改中等複雜度的 Python，並熟悉命令列、Git、JSON 與 REST API。若你的目標是實作，建議先從自己最常用的工具與一個小任務開始，再回頭閱讀對應章節。 Q2：為什麼已經會寫 Prompt，還要學 Context Engineering？Prompt 是一次交代模型怎麼回應的指令；Context Engineering 則處理整個工作過程中，哪些任務資料、歷史、規則、工具描述與記憶應該在何時被提供或移除。長任務與工具型 Agent 的品質，通常更受後者影響。 Q3：MCP 就是讓 AI Agent 變強的關鍵嗎？MCP 能讓模型應用以較一致的方式連接外部 Tools、Resources 與 Prompts，但它不是完整的 Agent 系統。工具選擇、權限、Context、錯誤處理、驗證與工作流程，仍需要由 Agent Harness 與產品設計處理。 Q4：企業要怎麼評估 Agent 是否真的可用？先建立由真實工作組成的任務集，為每個任務設定成功條件與不可接受的錯誤，再追蹤成功率、成本、延遲、人工介入率、重試次數與錯誤類型。不要只用單次展示或主觀體感選模型與工具。 Q5：Multi-Agent 一定比單一 Agent 好嗎？不一定。只有在任務能清楚分工、交接格式明確、資訊隔離與最終決策權都設計好時，多個 Agent 才可能帶來效益。若問題本來可由一個 Agent 穩定完成，多 Agent 反而可能增加成本、延遲與溝通失誤。