前面幾篇，我們已經幫分身裝上各種 Skills，也逐漸教會它我的工作方法，甚至開始讓它透過排程，定期替我執行任務。

但如果今天，我想交給分身一件更貼近日常工作的任務：

「幫我看看明天下午行事曆有沒有空，如果有，就安排一場跟客戶的會議，並寄 Email 通知對方。」

這件事聽起來不難。分身已經知道我平常怎麼安排會議、寄信習慣使用什麼語氣，也知道我在安排客戶會議時會注意哪些細節。

但問題來了：它要怎麼知道我的行事曆上有哪些行程？又要怎麼真的把 Email 寄出去？

如果沒有連接到我平常在用的工作系統（例如 Gmail、Google 行事曆、MS Teams 等），它頂多只能告訴我一般來說「可能」會有哪些時段適合安排會議(用猜的)，或先幫我寫好一封邀請信，最後還是得靠我自己打開行事曆、建立會議，再把信寄出去。

這時候，我們就會碰到 AI Agent 世界裡經常出現的三個技術名詞：Tool、API，以及前陣子很熱門的 MCP。

這三個東西到底是什麼？它們之間有什麼關係？又為什麼跟打造 AI 工作分身有關？

Tool：讓 AI 分身有能力動手做事

先從最容易理解的 Tool（工具）開始。

之前我們在使用 Hermes Agent 時，其實早就接觸過 Tool。像是讓它上網搜尋資料、讀取電腦裡的檔案、修改文件，甚至操作瀏覽器，背後都有相對應的工具在工作。

你可以把 Tool 想成 AI 分身手上可以使用的「工作工具」。

例如：

前面三個是 Hermes 內建工具可以提供的能力；後面兩個則是假設我們為分身接上行事曆與 Email 服務之後，可能取得的工具能力。

這裡有個很重要的觀念：AI 模型本身並沒有真的伸出一隻手去操作電腦。

當我們對分身說「幫我搜尋今天的 AI 新聞」，它會根據目前的任務，判斷需要使用網路搜尋工具，然後產生搜尋所需的參數，交由工具執行。工具取得結果之後，再把搜尋結果交回來，讓 AI 繼續分析與整理。

這個過程就叫做 Tool Calling（工具呼叫）。

也就是說，AI 負責理解我們的需求、判斷需要使用哪個工具；真正執行動作的，是背後的工具程式。

而且 Tool 並不一定要連上網路。讀取本機檔案、執行電腦指令，都可以是 Tool。只要這個能力有被提供給 Agent，並符合執行條件，它就有機會在任務中被使用。

但這裡還有一個問題。

假設我們想做的事情，是操作 Google Calendar 或 Gmail 這類外部服務，Tool 又是怎麼跟它們溝通的？

這就要認識第二個名詞：API。

API：讓不同軟體可以互相溝通

API 的全名是 Application Programming Interface，中文稱為「應用程式介面」。

這個名字聽起來有點技術，但它要解決的問題其實很常見：不同軟體之間，該怎麼交換資料、請對方幫忙做事？

舉個例子。

假設我開發了一套客戶管理系統，現在希望使用者建立客戶會議時，系統可以自動在 Google Calendar 裡新增一個行程。

總不能要求使用者每次都打開 Google Calendar，重新輸入一次日期、時間、標題和與會者吧？

這時候，就可以透過 Google Calendar 提供的 API，讓我們的程式依照指定的格式，向 Google Calendar 提出要求，例如像是下面這樣：

• 建立：會議, 10/13 15:00
• 標題：第四季客戶專案討論
• 與會者：Vicky, Kevin, Pip, John

《R森小叮嚀》

通常 API 的呼叫/回傳的格式都會使用 json，但此處為了簡化讓大家較好理解，所以使用列點的方式

Google Calendar 收到要求後，會檢查資料格式、身分及權限等條件。如果符合要求，就執行建立行程的動作，然後回傳結果。

這，就是 API 的用途。

用比喻來理解：你可以把它想成去銀行窗口申請東西時的「正式申請」請求。如果我想請求房貸，就得依照銀行事先規定的標準格式填寫申請單，提供「Input」等資料；等到銀行完成後，再回覆「Response」結果，並且執行後續動作。

API 也是類似的概念。它定義了外部程式可以提出哪些要求、要提供什麼資料，以及會做出什麼事、拿到什麼回應。

Tool 跟 API 有什麼不同？

把前面兩段合在一起，就會比較清楚了。

假設我們為 Hermes Agent 準備了一個「建立行事曆事件」的 Tool。

當 AI 決定要幫我建立會議時，可能會發生這樣的流程：

AI 分身 → 呼叫建立行事曆的 Tool → Tool 呼叫 Google Calendar API → Google Calendar 建立會議 → 回傳結果。

所以，Tool 是 AI 分身可以使用的能力；API 則是這個能力背後可能使用的軟體溝通方式。

而且兩者沒有一定要綁在一起。Tool 可以直接操作本機檔案，不需要外部 API；API 也可以被一般網站或 App 使用，完全不需要 AI Agent 參與。

理解這個差異之後，我們就可以進一步討論：既然有 Tool，也有 API，為什麼大家還需要 MCP？

既然已經有 API，為什麼還需要 MCP？

我們繼續想像打造 AI 工作分身的過程。

今天我想讓 Hermes Agent 能夠操作 Google Calendar，所以為它準備了一個會呼叫 Calendar API 的工具。

過幾天，我又想讓它可以寄 Gmail、整理 Notion 筆記、查看 GitHub 專案，甚至操作公司內部的客戶管理系統。

理論上，這些服務如果有提供適合的 API，我們就可以一個一個研究它們的使用方式，再為 Hermes 開發對應的工具，讓它可以使用。

但這樣的話，麻煩就開始慢慢出現了：

每個服務都有自己的 API 規格、認證方式、輸入格式與回傳結果。我們得花時間研究、開發、測試及維護這些串接。

而且如果今天寫好的工具是專門配合 Hermes Agent，未來換成其他 AI Agent（例如 Codex、Claude），還可能需要重新處理相容性問題。

這時候，就有人開始思考：

「如果 AI Agent 跟外部工具之間，可以有一套大家共同遵守的連接規則，是不是就不需要每次都從頭串接？」

這就是 MCP 想解決的問題。

MCP 是什麼？

MCP 的全名是 Model Context Protocol，中文稱為「模型上下文協定」。

它是一套最早由很有遠見的 Anthropic 開放標準，讓 AI 應用程式可以用比較一致的方式，連接外部資料來源與工具。

在 MCP 的架構裡，有兩個我們需要認識的角色：

• MCP Client（用戶端）：負責跟 MCP Server 建立連線、取得可用能力，並發出呼叫。
• MCP Server（伺服器）：對外提供工具或資料等能力，讓支援 MCP 的 AI 應用程式可以使用。

例如，有人開發了一個可以操作 GitHub 的 MCP Server，並提供查詢 Issue、查看專案資訊或建立 Issue 等工具。

當 Hermes Agent 連上這個 MCP Server 後，就可以透過 MCP 的共同規則，得知 Server 提供哪些工具、各自能做什麼，以及使用時需要哪些參數。

這樣一來，Hermes 就有機會使用這些現成工具，不必為每個功能重新開發一套專屬於 Hermes 的工具程式。

MCP 最大的價值就是能讓不同 AI 應用程式與外部能力之間，有一套相對標準化的連接方式。

當然，MCP 不只有提供 Tools，也能提供 Resources（資源）和 Prompts（提示範本）等能力。不過以我們目前打造 AI 工作分身的需求來說，先理解 MCP 如何提供 Tool，就已經足夠。

MCP Server 通常是誰開發的？難道要自己寫？

看到這裡，你可能會有另一個疑問：

「所以我想讓分身操作 Gmail、Notion 或 GitHub，就要自己開發對應的 MCP Server 嗎？」

其實通常不需要。

現在已經有不少現成的 MCP Server，可以依照來源分成三種類型：

例如，GitHub 就有官方開發的 MCP Server，讓 AI Agent 可以查詢 Repository、處理 Issue 與 Pull Request 等工作。

Notion 也提供官方 MCP 服務，讓支援 MCP 的 AI 應用程式能夠存取使用者授權的 Notion 內容。

同樣的，UX/UI 設計師常用 Figma 也有，只是它比較現實的是，你需要是訂閱帳戶，才能連接使用（免費版不提供連接）。

這裡要分清楚「開發 MCP Server」與「使用 MCP Server」是兩回事。

對一般使用者來說，通常只需要找到適合的 MCP Server，依照說明完成連線與授權，就有機會讓 Hermes Agent 使用那些外部工具。

就像我們使用手機 App，不需要自己開發 App，重點是找到符合需求的工具，並正確設定使用權限。

另外，MCP Server 也不一定都在雲端。有些是在自己的電腦上執行，有些則是由服務商遠端提供。使用者需要依照服務的設計，選擇適合的連線方式。

不過，如果是非官方開發的 MCP Server 要小心安全議題：它可能需要取得工作資料、帳號授權，甚至在自己的電腦上執行程式。使用前仍然應該確認來源是否可信、是否持續維護。

MCP 會取代 API 嗎？

這是大家最常問的問題，也是我覺得特別需要釐清的地方。

很多人第一次認識 MCP，可能會以為以前要靠 API 串接的事情，現在全部改成 MCP 就好了。

但實際上，MCP 的底層很常就是 API，他們不是誰取代誰的關系。

例如，一個可以操作 Notion 的 MCP Server，背後可能依然需要使用 Notion API，才能讀取資料庫資訊、建立頁面或執行其他操作。

只是對 Hermes Agent 來說，它不需要直接處理每一個具體 API 的細節，而是透過 MCP，使用 Server 已經提供好的工具。

所以 MCP 並沒有讓 API 消失。MCP Server 背後可以使用 API，也可以操作本機程式、檔案或其他系統。

理解所有觀念後，把 Tool、API、MCP 放在一起看，終於融會貫通

講到這裡，我們已經認識三個名詞，但它們的關係可能還是有點抽象。

所以我們就從同一件工作，用兩種不同的實現方式來更具體的融會貫通這三者。

假設我希望 AI 分身幫我建立 Google Calendar 的一個會議。

方法 A：透過直接整合的 Tool

AI 分身(Hermes Agent) → 行事曆 Tool → Google Calendar API → Google Calendar

這個 Tool 的背後，可能是開發者自行寫好的程式，負責把 AI 提供的日期、時間與會議資訊，轉換成 Google Calendar API 能理解的要求。

方法 B：使用 MCP Server 提供的 Tool

AI 分身(Hermes Agent) → MCP Client → Calendar MCP Server 的 Tool → Google Calendar API → Google Calendar

這次，Agent 透過 MCP 發現並使用外部工具。至於怎麼呼叫 Google Calendar API，則交給 MCP Server 背後的程式處理。

兩種方法最後都可能成功建立會議，差別在於工具如何提供給 Agent，以及串接邏輯由誰負責。

我們可以用這張表來整理：

這三個名詞其實位在不同層次，有些任務，Hermes 內建的 Tool 就能完成；有些任務，需要自己寫工具去呼叫 API；也有些情況，使用別人已經做好的 MCP Server，就能省下不少自己串接 API 工作。

我們應該根據任務需要，決定最合適的方式。

看看你現在的分身有哪些外部工具可以用

理解觀念之後，我們回到 Hermes Agent，看看這些能力實際上在哪裡。

這次先不安裝新的 MCP Server，也不進行外部服務串接。我們只需要打開 Hermes Desktop，認識它原本就具備的工具，以及未來可以管理 MCP 的地方。

1. 從 Settings 認識 Hermes 的 Tools

開啟 Hermes Desktop，進入「技能與工具」，找到工具集相關的設定區域就能看到：

在這裡，我們可以查看 Hermes 提供的工具，以及目前啟用的工具能力。實際顯示的項目，會依使用的版本、平台與設定而有所不同。

你可能會看到跟網頁搜尋、檔案操作、瀏覽器、終端機等相關的工具組。

這篇我們先不調整設定，只要觀察有哪些工具、哪些已經啟用，就能對 Hermes 原本具備的執行能力有更具體的認識。

下次你叫 Hermes 幫忙搜尋網路、整理文件時，就可以留意聊天畫面裡的工具呼叫紀錄，看看它實際使用了哪些工具。

2. 認識 MCP Server 的管理位置

傳統要用 CLI 或手動編輯 Config 的方式來管理 MCP 設定，但這個系列文我們採用的是桌面版的 Hermes Desktop ，最新版本已有提供 MCP Server 的設定與管理功能，讓使用者可以透過圖形介面處理這類外部工具連線，不需要為了基本管理工作就手動編輯設定檔。

我們今天只需要知道：

• 如果未來想接上外部 MCP Server，可以從相關管理功能著手。
• MCP Server 連線之後，會將它提供的工具交給 Hermes 使用；實際能使用哪些工具，仍取決於連線狀態、工具設定與授權範圍。

先這樣就夠了，等到我們之後真的遇到需要串接某個外部服務的工作，再來研究對應的 MCP Server、授權方式，以及實際操作步驟。

那之前學過的 Skill，又跟 MCP 有什麼不同？

前面幾篇，我們花了不少時間，教 AI 分身如何使用 Skills，以及怎麼把自己的工作方法整理成 Skill。

現在又出現 Tool、API、MCP，可能有讀者朋友會開始混亂了：這幾個東西是不是有重疊？

我們就拿最前面的「幫客戶安排會議」來做說明釐清觀念。

假設我已經把自己「如何安排客戶會議」的工作方法，整理成一個 Skill，裡面包括：

• 安排會議前，先確認會議目的、所需時間與與會者。
• 優先選擇不會與既有行程衝突的時間。
• 寄給客戶的邀請信，要包含會議主題、時間及必要的準備事項。
• 對外寄信前，需要由我確認內容。

這個「Skill」可以教 AI 分身「安排客戶會議時，應該怎麼做」。

但真的執行時，它還需要有能力去讀取行事曆、建立會議，以及寄送 Email。

這些動作，就得交給相對應的 「Tools」。

至於 Tools 怎麼跟 Google Calendar、Gmail 溝通，背後可能是透過 「API」，也可能使用 「MCP Server」 提供的串接能力。

所以我們可以這樣理解：

Skill 讓分身理解我的工作方法與判斷標準；Tool 讓它有辦法執行具體動作；API 和 MCP 則可協助它操作原本無法直接接觸的外部服務。

當然，Skill 本身有時也可以包含 Script 或其他執行資源，但對我們目前建立工作分身的目的來說，先掌握這樣的分工就足夠了。

連上真實外部世界之後，也代表它做錯事的代價很大

以前（AI Chat 時代），我們請 AI 寫封 Email，就算內容寫錯了也不會怎樣，因為它並沒有連接到我們真實的 Email 服務。
但進入 Agent 時代後，現在的 AI 已經可接上我們實際工作中的 Email 環境，它就具備了把信寄出去的能力。

同樣的，讓它連接愈多我們的工作環境，就會更方便，它可以操作行事曆、專案管理系統，甚至公司內部資料庫等。

那麼，當它不小心錯誤執行時，就會影響我們的真實世界。

所以，安裝 MCP 或允許使用 Tool 時，有幾件事值得注意：

1. 先確認來源：優先查看服務官方是否有提供或推薦的 MCP Server。如果使用第三方版本，要確認開發者、程式來源及維護狀況。
2. 只開放必要權限：如果分身目前只需要查詢資料，就沒有必要同時開放刪除、修改或寄送功能。
3. 重要動作保留人工確認：例如寄信給客戶、刪除資料、修改重要紀錄，應該要求分身在執行前先取得同意，並搭配實際的權限與核准機制。
4. 不要把連線成功當成任務成功：仍然需要檢查 AI 是否使用正確的工具、資料是否正確，以及外部系統是否真的完成操作。

另外，MCP 不是一層保證安全的保護罩。就算工具使用標準協定，Server 本身的程式、授權設定以及它接觸到的外部內容，仍然可能帶來風險。

這也延續了前面我們討論過的 Skill 安全觀念：分身的能力越多，越需要知道哪些權限應該交給它，哪些事情仍然得由自己把關。

今天，看懂了 AI 分身要怎麼連接主人的工作環境

回頭看最一開始的例子：「幫我確認明天下午有沒有空，安排一場客戶會議，再把 Email 寄出去。」

現在我們應該比較能理解，要完成這件事，背後可能需要哪些條件了：

• 它要知道我的會議安排方式，可以靠 Skill
• 要讀取行事曆、建立行程和寄信，需要相應的 Tools；而這些 Tools 可能透過 API 或 MCP，與外部工作系統連接。

我們還沒真的把 Google Calendar 和 Gmail 接上，也沒有讓分身直接代替我寄信。我希望在做這些事之前，先替大家把這幾個容易混淆的觀念弄清楚。當之後再看到別人推薦某個 MCP ，或是提到要串接某個 API，至少我們會知道他在講的是什麼東西。

對一般使用者來說，也不需要每個東西都自己開發。很多能力可能已經有人做好，我們真正要學的是怎麼找到適合的工具、理解它能做什麼，以及判斷該不該把它交給自己的 AI 分身。