WordPress AI 代理介面選擇 | MCP、API、SSH 怎麼分

接案這幾年我們處理過大大小小的 WordPress 自動化需求，最近最常被問的一個問題是：「如果要讓 AI 代理（agent）幫客戶管網站，介面到底要選哪個？」候選人通常有三個：REST API、MCP、SSH 加上命令列工具 WP-CLI。

我們的結論先放在前面：內容管理（發文、SEO、商品上架）走 MCP；伺服器維護（部署、版本升級、災難復原）走 SSH 但由人類駕駛；REST API 過渡期可以用，但長期不該是 AI 代理的主要介面。

這條分界線不是技術偏好，是踩過坑之後不得不畫的線。下面把每一段的理由拆開講。

為誰設計，決定 AI 用起來的成本

REST API 跟 MCP 最根本的差別不在技術規格，而在「為誰設計」。

一般的網站 API 是給工程師看的：文件給人讀、欄位規格給人記、錯誤訊息給人除錯。AI 代理要用 API 的時候，本質上是在冒充工程師，開發者得先把網址、認證方式、欄位清單餵給它。即使讓它自己上網查文件，我們的實際經驗是 AI 在這一塊最容易產生幻覺——它會把 meta 寫成 metadata、把 featured_media 跟 featured_image 搞混、自信地組出一個根本不存在的網址。

MCP 則是給模型讀的協定。負責提供工具的程式（也就是 MCP 伺服器）會在執行時主動告訴 AI「我有哪些工具、每個工具吃什麼參數、回傳結果是什麼」，AI 不需要預先了解整個系統就能開始操作。

這條差別會直接反映在指令撰寫的成本上。用 WordPress 的 REST API，比較穩的做法是在執行前針對要操作的部分餵給它對應的文件，每加一個操作就要再餵一次；用 MCP 的話 AI 自己會問「我能做什麼」，再根據伺服器的設計決定下一步。

一次只做一件事的 API，AI 用起來很吃力

第二個差別是操作的方式。

REST API 通常以「增刪查改」為主：/posts、/users、/products，這符合 REST 設計哲學，但對 AI 不友善。要發一篇做過 SEO 處理的文章，AI 可能要依序呼叫四五個網址——查分類、上傳圖片、建立文章、更新 SEO 欄位——每一步之間都要決策下一步，每一次決策都是失敗點。

MCP 伺服器可以把這些重新封裝成任務導向的工具：「發布一篇 SEO 處理過的文章（標題、內文、關鍵字）」，把多個網址呼叫的編排藏在伺服器端。對 AI 來說，從「組合多個操作」變成「呼叫一個動作」，成功率、文字額度成本、出錯率的差距都很明顯。

信任邊界：WordPress 場景特別關鍵

第三個我們認為在 WordPress 場景特別關鍵的點：信任邊界。

如果用 WordPress 的 REST API，AI 必須持有應用程式密碼或登入權杖，意思是高權限憑證會直接出現在 AI 的對話脈絡裡。WordPress 本身就是惡意內容的大溫床——留言區、自訂欄位、上傳檔案都可能藏指令，這提升了「提示詞注入攻擊」的曝險（攻擊者把惡意指令藏在資料中，誘導 AI 執行非預期動作）。

MCP 把這條線拉出來：憑證留在伺服器端，AI 只持有一個短期通行證。伺服器端可以做白名單、流量限制、危險操作要求人類確認、把回傳結果先過濾再給模型。對於做 WordPress 自動化的人，這個邊界比效能差異重要得多。

對話成本：被低估的差別

REST API 的回應是給工程師處理的。一個取得文章的呼叫回來的內容裡，約 80% 是模型用不到的欄位——例如連結資訊、舊版識別碼、最後修改時間、留言開關——讀這些欄位都會吃掉 AI 的閱讀額度。

設計良好的 MCP 伺服器可以只回模型當下需要的東西，甚至附上「這個欄位通常用於 X」的提示。一個對話跑下來，整體成本跟 REST 比通常能省一個量級。

但 MCP 不是萬靈藥

話說回來，現階段能找到的多數 MCP 伺服器還是 API 的薄封裝，繼承了底層 API 的操作模型，反而多一層維護成本。

如果只是寫固定流程的腳本（每天備份、每週發報表），用 REST API 或 WP-CLI 又快又穩，硬套 MCP 是過度工程。我們的分水嶺大致是這樣：

流程是否需要 AI 自主判斷下一步？需要——MCP；不需要——API 或命令列。

前者重點在 AI 能讀懂、能組合、不要拿到危險權限；後者重點在效能與可控。

那 SSH 呢？跟 MCP 比是另一個極端

跟 REST API 比，MCP 是把抽象層往上拉；跟 SSH 比，MCP 是把抽象層往下拉。SSH 的問題不一樣，它的問題是權限太大。

權限模型：天差地別

SSH 給的是對整台機器的完整控制——能讀 WordPress 設定檔裡的資料庫密碼、能用系統管理員身分執行任何指令、能改網頁伺服器設定、能一次刪掉整個資料夾。把 SSH 金鑰交給 AI，等於把整棟房子的鑰匙交出去。

MCP 跟 REST API 則是操作網站內容，能發文、能改設定，但動不了作業系統層。即使被注入攻擊控制，最壞情況是亂發文章，不會把整台伺服器搶走。

對客戶來說，這個差別不是技術細節，是信任感的問題。沒有客戶會把正式站主機的 SSH 金鑰交給一個 AI 操控——這條我們在跟接案客戶簽合約之前一定會講清楚。

操作粒度：原語還是任務

SSH 是系統層級，AI 用的是「列出檔案」「搜尋字串」「導出文章再過濾」這類零碎指令，得自己組合成有意義的任務。這對 AI 來說很燒文字額度，而且每一步都可能出錯——打錯一個字、引號沒跳脫好、指令串接順序顛倒，結果就完全不同。

MCP 是任務層級，工具長這樣：「發布文章」「更新 SEO 欄位」。AI 不需要知道底層是命令列工具還是 API 在跑，只要表達「我想做什麼」。

WP-CLI 在這裡是個有趣的中間狀態。它比原生指令高階（用 wp post create 比手刻資料庫語法安全），但仍然是系統層級指令，AI 要正確組出複雜的參數（例如把 SEO 關鍵字塞進 JSON 字串再傳進 --meta_input），實戰中失敗率比想像高。

可觀測性：黑盒還是白盒

SSH 連線對外部觀察者來說是黑盒。AI 跑了什麼指令、改了什麼檔案，要靠系統操作紀錄或自己包一層日誌才知道。應用層的觀測系統（例如 Sentry 之類的錯誤監控）幾乎用不上，因為 SSH 操作根本沒進到應用層。

MCP 伺服器是應用層，每個工具呼叫都可以打進錯誤監控、可以結構化記錄、可以接審查機制。哪個 AI 在什麼時間呼叫了什麼工具、輸入輸出是什麼、有沒有失敗，全部可追。對「事後檢討、強化審查」的工作流來說，這是必要條件。

可重現性

SSH 操作是有狀態的：切換到哪個目錄、環境變數設了什麼、背景連線還活著嗎？AI 跨對話操作會踩到一堆狀態問題。

MCP 工具呼叫是無狀態的：每次呼叫的輸入跟輸出都很明確，重試、平行化都好做。

SSH 仍然不可取代的場景

我們不是說 SSH 沒地位，恰恰相反——以下這些場景，沒有 SSH 是做不下去的：

• 災難復原：資料庫壞了、檔案系統爆了、WordPress 進不去後台，這時 MCP 也跟著掛——SSH 是唯一的活路。
• 主機層操作：PHP 版本升級、網頁伺服器改設定、定時任務、日誌輪替，這些本來就不該包成 MCP 工具。
• 效能瓶頸的批次操作：對 50 萬筆文章資料跑搬遷，直接下資料庫語法比走任何 API 都快幾個數量級。
• 遠端檔案同步、主機遠端管理：原本的工作流就在用，沒必要硬塞 AI 進來。

關鍵差別是這些場景的駕駛者是人類，AI 頂多協助寫腳本跟審查。我們在另一篇文章寫過怎麼用 Claude Code 透過 SSH 管 WordPress，那是人類在駕駛、AI 在副駕——跟本文討論的「AI 自主操作」是兩件事。

我們會怎麼分層

從替客戶設計 AI 開發流程的角度，我們是這樣切：

操作層次	介面選擇	自主程度
內容與商業邏輯（發文、SEO、商品上架、訂單回應）	MCP	AI 直接操作，伺服器端控權限
WordPress 設定變更（外掛設定、佈景主題選項、使用者權限）	MCP	需要人類確認步驟
主機層與維運（部署、備份、版本升級、漏洞修補）	SSH	人類駕駛，AI 頂多協助寫腳本跟審查

換句話說：AI 自主操作的範圍 ≠ 你自己操作的範圍。這條線怎麼畫，會直接決定客戶網站的安全姿態，以及未來除錯時你會不會崩潰。

對應到工具棧，我們目前的組合技大致是：MCP 伺服器處理內容層（自寫，把發文、SEO 欄位、媒體上傳收成任務導向工具）、REST API 留給固定排程腳本、SSH 留給人類加 Claude Code 副駕。

延伸思考

這篇文章的觀點建立在幾個前提上，值得進一步思考：

• 「自寫 MCP 伺服器」假設讀者有 200-400 行程式碼能力——沒有開發資源的客戶只能退回 REST API 加薄封裝，分界線會往「能用就好」傾斜
• 分界線針對「全自主 AI 代理」場景——如果是人類駕駛、AI 副駕（每步審查），REST API 跟 SSH 的劣勢就大幅縮減
• 託管型 WordPress（WordPress.com、WP Engine）沒有 SSH 可用，這層討論不適用，只剩 MCP 跟 REST API 二選一

其他領域也有類似的分層智慧：

• 銀行櫃員與金庫管理員的分權——櫃員（MCP）只能執行特定操作、留稽核紀錄；金庫管理員（人類駕駛 SSH）才有 root 權限。最小權限原則銀行業跑了一百年，AI 業界才剛開始學
• 醫療院所的角色與權限分層——護理師、醫師、外科醫師的自主範圍被嚴格定義，越權有法律後果。AI 代理是「新角色」加入這個體系，自主範圍該怎麼定義是同類問題
• 這套框架可以遷移到任何「給 AI 開放系統能力」的場景——AI 客服接 CRM、AI 寫程式接版控、AI 助理接行事曆、AI 採購接 ERP，問的都是同一句話：「我願意讓他自主到什麼程度？」

關鍵概念：AI 代理介面選擇框架、MCP 外部工具整合、開發工具鏈整合

常見問題

WordPress AI 代理用 REST API 不行嗎？為什麼一定要 MCP？

可以用，但要承擔幾個成本：高權限憑證會直接進到 AI 的對話脈絡、增刪查改操作組合容易出錯、文字額度消耗高。短期試做或一次性腳本用 REST 完全沒問題，但只要 AI 要長期自主操作、要做多步驟任務，建議轉到 MCP。

MCP 伺服器自己寫還是用現成的？

如果你的需求只是「把現成 WordPress REST API 包一層」，現成的 MCP 伺服器夠用；但如果要把多個操作組成任務導向工具（例如一個「發布 SEO 文章」就把分類、圖片、欄位全處理掉），通常還是自己寫一支比較好維護。我們的實作經驗是，自寫伺服器約 200 到 400 行程式碼就能涵蓋多數場景。

把 SSH 交給 AI 真的不行嗎？有沒有比較安全的做法？

要的話一定要做三件事：（一）開一個權限最小化的登入帳號，限制能執行的指令；（二）每一個破壞性操作都要人類二次確認；（三）所有指令都要留下稽核紀錄，但即使做了這些，比起用 MCP，攻擊面還是大得多。我們的建議是，能用 MCP 解的別丟給 SSH。

客戶不懂這些，要怎麼解釋這條信任邊界？

我們的講法通常是這樣：「您家裡也有水電工進來修東西，您不會把家裡鑰匙、保險箱密碼、提款卡密碼一次全給他。AI 也一樣——它應該只拿到完成這次任務需要的權限，而不是整把鑰匙。」這個比喻幾乎都能讓客戶秒懂。

---

WordPress AI 代理的介面選擇不是「哪個技術比較好」，是「我願意讓 AI 自主到什麼程度」。把這條線畫對了，後續的指令成本、攻擊面、可觀測性、客戶信任問題會一起被解掉；畫錯了，每一個都會回來找你。

如果你正在替團隊或客戶設計 WordPress 的 AI 開發流程，卡在「該選哪個介面」「權限怎麼切」「客戶信任邊界怎麼設計」這類問題，歡迎聯絡我們聊聊你的場景，或加入我們的 LINE 官方帳號。我們也提供 WordPress 接案者的 AI 開發升級方案，從流程盤點、AI 開發框架設計，到上線後的資安監控，把這條分界線真正落到你的開發循環裡。