之前跟朋友在討論該如何讓 AI 控制 WordPress 網站，我的看法是如果要做的是內容管理（發文、SEO、產品上架）選 MCP；如果是伺服器維護（部署、版本升級、災難救援）選 SSH 但由人類把關；至於 REST API，過渡期可以用，但長期不該作為 agent 的主要介面，為什麼？我整理了這篇文章希望能把這條分界線拆分清楚。
為誰設計，決定了 agent 用起來的成本
REST API 跟 MCP 最根本的差別，我覺得不在技術規格，而在「為誰設計」。
REST/GraphQL API 是給工程師看的，文件給人讀、schema 給人記、錯誤訊息給人 debug。agent 要用 API 的時候，本質上是在「冒充工程師」，開發者得先把 endpoint、auth 方式、欄位餵給 agent，雖然可以請它自己上網搜尋，但有時會搞錯參數的細節，我的實際經驗是 AI 在這一塊最容易產生幻覺。
MCP（Model Context Protocol）則是給模型讀的協定，Server 在執行時主動告訴 agent「我有哪些工具、每個工具吃什麼參數、回應結果是什麼」，這種特性對 agent 來說比較天然，agent 不用預先了解整個系統就能開始操作。
這條差別會直接反映在寫 prompt 的成本上，用 WP REST API，比較穩的做法是在先針對要操作的部分餵給它對應的 API 文件，用 MCP 的話 agent 自己會問「我能做什麼」，然後根據 MCP 的設計來自動決定下一步。
CRUD 對 agent 不太友善
第二個差別是操作的方式。
REST API 通常是以 CRUD 為主要的操作方式 /posts、/users、/products，這符合 REST 哲學，但對 agent 不太友善，要發一篇 SEO 優化文章，agent 可能要依序呼叫 GET /categories、POST /media、POST /posts、PATCH /posts/{id}/meta 等等過程，每次都要在中間決定下一步，每一次決策都是失敗點。
MCP server 可以把這些重新包成以任務為導向的工具：publish_optimized_post(title, content, seo_keywords)，把多個 API 呼叫的編排藏在 server 端，對 agent 來說，從「組合多個操作」變成「呼叫一個動作」，這對成功率、token 成本、出錯率影響都很大。
信任邊界：在 WordPress 場景特別重要
第三個我覺得在 WordPress 場景特別關鍵的點：信任邊界。
如果用 WP REST API，agent 必須持有 Application Password 或 JWT，這意味著跟 agent 的上下文裡會出現高權限憑證，增加提示詞攻擊的風險，尤其 WordPress 是惡意內容的大溫床，留言區、自訂欄位、上傳檔案都可能藏指令。
MCP 把這條線拉出來：憑證留在 server 端，agent 只持有 session。Server 端可以做白名單、rate limit、危險操作要求人類確認、把回傳結果先 sanitize 再給模型，對於做 WordPress 自動化的人，這個邊界比效能差異重要得多。
Context 效率：被低估的差別
REST API 的回應是給工程師處理的。一個 GET /posts/{id} 回的 80% 是模型用不到的欄位——_links、guid、modified_gmt、讀取這些不需要的欄位都會吃 token。
設計良好的 MCP server 可以只回模型當下需要的東西，甚至附上「這個欄位通常用於 X」的提示，一個對話下來，token 成本與呼叫 REST API 的結果應該會節省許多。
但 MCP 不是萬靈藥
然而大部分現在能找到的 MCP server 還是只是 API 的封裝，繼承了底層 API 的操作，反而多一層維護成本。
如果只是寫固定流程的腳本（每天備份、每週發報表），用 REST API 加 WP-CLI 又快又穩，套 MCP 是過度工程，我的分水嶺大概是這樣：流程是否需要 agent 自主判斷下一步？需要——MCP；不需要——API/CLI。前者重點在 agent 能讀懂、能組合、不要拿到危險權限；後者重點在效能跟可控。
那 SSH 呢？跟 MCP 比起來是另一個極端
跟 REST API 比，MCP 是把抽象層往上拉；跟 SSH 比，MCP 是把抽象層往下拉，SSH 的問題不一樣，它的問題是權限太大。
權限模型：天差地別
SSH 給的是對整台機器的完整控制——能讀 wp-config.php 裡的 DB credentials、能 sudo、能改 nginx config、能 rm -rf。給 agent SSH 等於給它 root 鑰匙。
MCP 跟 REST API 則是操作網站內容，能發文、能改設定，但動不了 OS layer，即使被注入攻擊控制，最壞情況也只是亂發文章，不會把整台 server 搶走。
對 WordPress 客戶來說，這個差別不是技術細節，是信任感的問題，沒有客戶會把正式站主機的 SSH key 交給一個 LLM 操控。
操作粒度：原語層級的差異
SSH 是系統層級，使用工具：ls、grep、wp post list --format=json | jq '...'，agent 必須自己把這些指令組合成有意義的任務，這對 agent 來說很燒 token，而且每一步都可能出錯，打錯一個字、quote 沒跳脫好、pipe 順序搞反，結果就完全不同。
MCP 是任務層級，使用工具：publish_post、update_seo_meta，agent 不需要知道底層是 WP-CLI 還是 REST API 在跑，只要表達「我想做什麼」。
WP-CLI 在這裡是個有趣的中間狀態，它比原生指令高階（wp post create 比手刻 SQL 安全），但仍然是系統層級指令的操作，agent 要正確組出 --meta_input='{"_yoast_wpseo_focuskw":"..."}' 這種東西，會有失敗的可能性。
可觀測性：黑盒 vs 白盒
SSH session 對外面的人來說是黑盒。agent 跑了什麼指令、改了什麼檔案，要靠操作紀錄、或自己包一層日誌才知道，之前想導入的在「Sentry-as-TDD」那套方法論在這裡幾乎用不上，因為 SSH 操作根本不會進應用層的觀測。
MCP server 是應用層，每個工具使用都可以打 Sentry、可以結構化 log、可以接 reviewer 系統，哪個 agent 在什麼時間呼叫了什麼工具、輸入輸出是什麼、有沒有失敗全部可追，這對「事後檢討、強化 reviewer」的工作流是必要條件。
可重現性
SSH 操作是有狀態的：cd 到哪個目錄、環境變數設了什麼、背景 session 還活著嗎？agent 跨 session 操作會踩到一堆狀態問題。
MCP tool call 是無狀態的：每次呼叫的輸入跟輸出指令都很明確，重試、平行化都好做。
SSH 的場景
以下是需要 SSH 的場景：
- Disaster recovery：DB 壞了、檔案系統爆了、WordPress 進不去 admin，這時 MCP 也跟著掛——SSH 是唯一的活路。
- Server-level 操作：PHP 版本升級、nginx 改 config、cron job、log rotation——這些本來就不該包成 MCP tool。
- 效能瓶頸的批次操作：要對 50 萬筆 post meta 跑 migration，直接
wp db query比走任何 API 都快幾個數量級。 - Rsync 部署、SSH-based remote management：原本的 workflow 就在用，沒必要硬塞 agent 進來。
我會怎麼分層
以自己管理 WordPress 網站的角度來看，我是這樣切：
| 操作層次 | 介面選擇 | 自主程度 |
|---|---|---|
| Content / business logic（發文、SEO、產品上架、訂單回應） | MCP | Agent 直接操作，server 端控權限 |
| WordPress 設定變更（plugin 設定、theme options、user role） | MCP | 需要人類確認 step |
| Server-level / DevOps（部署、備份、版本升級、CVE patch） | SSH | 人類駕駛，agent 頂多協助寫 script 跟 review |
換句話說：agent 自主操作的範圍 ≠ 你自己操作的範圍。
你怎麼做？
這只是我目前的實作心得分享，如果你也在做 WordPress AI agent 或類似的自動化專案，我很想知道：
- 你給 agent 用的是 REST API、MCP 還是 SSH？
- 有沒有踩過權限太大或介面太碎的坑？
- 如果是賣給客戶的服務，你怎麼跟客戶解釋這條信任邊界？
我自己這條線還在調整，很期待聽到你是怎麼想的？
需要更深入的討論？
如果你的公司正在評估把 WordPress 接上 AI agent，或想知道現有的網站架構該怎麼安全地導入 AI 自動化——從信任邊界怎麼劃、MCP server 該不該自己寫、到怎麼跟客戶／團隊解釋這條線——這正是 Codotx 的 WordPress AI 顧問服務 在做的事。
我會根據你的網站規模、團隊技術背景、商業情境，給出可落地的分層建議，而不是一份漂亮但執行不了的架構圖。歡迎到 服務頁面 看細節，或直接預約一次諮詢聊聊。
