AI 代理介面選擇框架

定義

將 AI 代理（agent）連接到外部系統時的介面決策框架。核心變數不是「哪個技術好」，而是「AI 的自主程度」——介面選擇必須匹配你願意讓 AI 自主操作的範圍。三條軸線決定選擇：自主程度、信任邊界、可觀測性。

關鍵數據點（附來源）

• 三層分配（來源：WordPress AI 代理文章）：
  • 內容與商業邏輯（發文、SEO、商品上架、訂單回應）→ MCP，AI 直接操作
  • 設定變更（外掛、佈景主題、權限）→ MCP，需人類確認步驟
  • 主機層維運（部署、備份、漏洞修補）→ SSH，人類駕駛
• 介面與自主程度的對應（來源：WordPress AI 代理文章）：
  • 完全自主多步驟 → MCP
  • 半自主、需人類審查每步 → REST API 加薄封裝
  • 人類駕駛、AI 副駕 → SSH 加命令列
• 自寫 MCP 伺服器約 200-400 行程式碼能涵蓋多數場景（來源：WordPress AI 代理文章）

三個核心判斷維度

1. 自主程度（核心問題）

流程是否需要 AI 自主判斷下一步？

• 需要 → 任務導向介面（MCP），把多步驟編排藏在伺服器端
• 不需要 → 增刪查改介面（REST API）或命令列（適合固定排程腳本）

2. 信任邊界

憑證的存放位置決定攻擊面：

• REST API：AI 持有應用程式密碼 / 登入權杖，憑證進入對話脈絡
• MCP：憑證留在伺服器端，AI 只持有短期通行證，伺服器端可做白名單、流量限制、人類確認、回傳結果過濾
• SSH：等於整台機器的 root 鑰匙，作業系統層完全暴露

3. 可觀測性

失敗後能不能追？

• MCP / REST API：應用層，每個呼叫可進錯誤監控系統、可結構化記錄、可接審查機制
• SSH：黑盒，應用層觀測系統打不到，要靠系統操作紀錄或自己包一層日誌

前提與局限性

• 資源前提：「自寫 MCP 伺服器」假設讀者有 200-400 行程式碼能力。沒有開發資源的客戶只能退回 REST API 加薄封裝
• 場景前提：分界線針對「全自主 AI 代理」場景。如果是「人類駕駛、AI 副駕」（每步審查），REST API 跟 SSH 的劣勢大幅縮減
• 平台前提：託管型 WordPress（WordPress.com、WP Engine）沒有 SSH，框架只剩 MCP vs REST API 二選一
• 時間前提：MCP 生態系還在成長中（2026 年），WordPress 沒有業界標準的 MCP 伺服器，自寫是預設選項；兩年後可能改變
• 模型前提：「WP-CLI 失敗率比想像高」跟模型版本相關，隨模型能力提升此結論可能弱化

衝突標記

• 與 [[MCP 外部工具整合]] 中既有的「SSH 文章認為 MCP 太受限」觀點看似衝突，實則互補：差別在誰在駕駛——人類駕駛時 SSH 是工具加倍器，AI 自主時 SSH 是核彈級風險

跨域類比

• 人機介面設計史：CLI（工程師）、GUI（一般使用者）、語音（對話式）的設計演進。MCP 之於 AI，等於 GUI 之於人類——介面要匹配使用者的認知模式
• 銀行櫃員與金庫管理員的分權：櫃員（MCP）只能執行特定操作、留稽核紀錄；金庫管理員（人類駕駛 SSH）才有 root 權限。最小權限原則跑了一百年，AI 業界才剛開始學
• 醫療院所角色分層：護理師、醫師、外科醫師的自主範圍被嚴格定義，越權操作有法律後果。AI 代理是「新角色」，自主範圍該怎麼定義是同類問題

關聯概念

• [[MCP 外部工具整合]]
• [[開發工具鏈整合]]
• [[AI 工具選擇策略]]
• [[wordpress-外掛開發實踐]]