當 AI 學會自己打電話——MCP 協定，可能是 2026 年最安靜的技術革命

今晚十一點，我在 Mac 上敲了一行字：

"cloudflare-api MCP 認證一下"

三秒後，AI 彈出一個 OAuth 連結。我點開瀏覽器，授權，回到終端機。然後我說：

"幫我看看 Cloudflare 上有什麼 Workers。"

十秒內，它返回了一份完整的 Workers 清單——包括帳號 ID、專案名稱、部署狀態，全部精確無誤。

沒有寫一行程式碼。沒有翻一頁文件。沒有查任何 API endpoint。

這就是 MCP。

MCP 是什麼

MCP，全稱 Model Context Protocol，模型上下文協定。

這個名字聽起來很學術，翻譯成人話就是：

讓 AI 能直接呼叫第三方服務的標準化工具協定。

打一個比方。

以前你讓 AI 幫你管 Cloudflare，相當於你跟一個英語流利但沒有電話的助理說："幫我打給電信公司改個資費方案。"他聽懂了你的意思，但他沒辦法打電話，只能寫一封郵件給你，教你自己打。

MCP 做的事，就是幫這個助理裝了一支電話。

他聽完你的需求，自己打電話過去，對方接線生驗證身分，確認權限，執行操作。你全程只需要說人話。

MCP 的起源

MCP 協定由 Anthropic 在 2024 年 11 月正式發布，開源規範。

這件事的背景是：AI 模型越來越聰明，但手腳被綁著。GPT-4、Claude Opus 這些大模型可以寫程式碼、做分析、理解複雜指令，但要操作外部世界——部署一個網站、查一個資料庫、發一封郵件——它們做不到。中間隔著一道牆：API。

API 是給工程師看的。幾百個 endpoint，各自有參數、有認證方式、有 rate limit。AI 模型能讀 API 文件嗎？能，甚至能自己寫呼叫程式碼。但問題在於：讀懂和穩定執行之間隔著一道鴻溝。

人類工程師犯錯了可以 debug、看日誌、逐步排查。AI 犯錯了，整個呼叫鏈就崩了。它缺的不是理解力，而是結構化的、可執行的工具介面。

MCP 的核心正是補上這一環。但準確地說，MCP 本身不是什麼黑科技，它的價值在於三件事同時成立：

1. 大模型原生支援函式呼叫（function calling / tool use）
2. 工具用結構化 JSON Schema 描述（name、description、parameters）
3. 透過 MCP 協定統一接入，各平台一個標準

缺一不可。模型不支援 tool use，協定再好也沒用。協定不統一，每個平台各搞一套，開發者會瘋。

AI 讀到這些結構化描述，立刻知道"列出 Workers 用 workers_list"，"查日誌用 query_worker_observability"，"改 DNS 用 dns_record_update"。

不是 AI 突然變聰明了。是基礎設施終於跟上了模型的能力。

我們的經歷：三個 Session 搞定 Cloudflare 全套

今晚的經歷很有代表性，因為它完整展示了 MCP 的配置、認證和使用全流程。

第一步：寫配置

第一個 session，我讓 AI 在 ~/.claude.json 裡新增 Cloudflare MCP 伺服器。

Cloudflare 的 MCP 設計很有意思——它提供了兩種風格：

風格一：Product-specific server（專科醫生）

針對具體產品領域，提供有類型約束的工具。Cloudflare 目前有十幾個這樣的 server：

風格二：Code Mode server（全科大夫）

cloudflare-api 走了一條完全不同的路——它不是把 2500+ 個 endpoint 都暴露成獨立工具（那樣會燒掉 117 萬 token，直接撐爆上下文視窗），而是只提供兩個工具：search() 和 execute()。

AI 先用 search() 在 OpenAPI 規範裡找到對應的 endpoint，然後用 execute() 寫一段 JavaScript 直接呼叫。程式碼跑在 Cloudflare 的隔離沙盒裡。

整個 2500+ endpoint 的接入成本？約 1000 token。

這就是 Code Mode——用程式碼執行取代工具清單，token 效率提升三個數量級。

兩種風格是二選一的關係，不是疊加。我最開始不懂，五個全加上了。後來才搞清楚：product-specific server 適合你只用某一塊功能的場景，Code Mode 適合需要廣覆蓋的場景。同時掛五個反而浪費 context。這個坑，踩過才知道。

配置本身是幾行 JSON。

第二步：OAuth 認證

重新啟動終端機後，MCP server 載入進來了。但它們還沒有權限存取我的 Cloudflare 帳號。

說白了，電話裝好了，但對方接線生不認識你。

於是我對 AI 說"認證一下"，它自動找到了 authenticate 工具，產生了一個 OAuth 授權連結。我在瀏覽器裡點了一下，用 Google SSO 登入 Cloudflare 帳號，授權。回到終端機，連線自動建立。

這個體驗值得細說。OAuth 是安全的——不需要我把 API Token 交給 AI，不需要我在配置檔裡寫明文密碼。AI 拿到的是一個 session 層級的臨時憑證，權限範圍由 Cloudflare 那邊控制。

這和把鑰匙交給別人的區別是：你不是給了它一把鑰匙，你是讓物業給它開了一次門。

第三步：驗證

認證完了，我想看看到底通不通。

讓 AI 跑了一個簡單的查詢：列出我帳號下所有的 Workers。

AI 透過 cloudflare-api 的 execute() 工具，在沙盒裡跑了這段程式碼：

async () => {
  const result = await cloudflare.request({
    method: "GET",
    path: `/accounts/${accountId}/workers/scripts`
  });
  return result;
}

這就是 Code Mode 的實際工作方式——AI 不是呼叫了一個 workers_list 工具，而是自己寫了一段 JS，透過 cloudflare.request() 呼叫底層 API。

十秒返回結果。Account ID 對的，Workers 清單對的。全通。

從配置到驗證，三個 session，總共可能十分鐘。

如果走傳統路線——查 Cloudflare API 文件、註冊 API Token、寫請求腳本、除錯參數、處理認證——同樣的事至少要一個下午。

關鍵洞察：MCP 和 API 的經濟學

接下來是今晚最有價值的一段討論。

認證成功之後，我突然想到一個問題：從 token 經濟的角度看，MCP 和傳統 CLI + API，哪個更划算？

答案比想像的微妙。

傳統模式

你寫程式碼（一次性投入）
→ 程式碼呼叫 API（每次執行 0 token）
→ 可以丟進排程任務無限跑

寫一次，跑一輩子。每次執行不花一分錢。

MCP 模式

你說人話（每次都要 AI 參與）
→ AI 推理選工具（消耗 token）
→ 工具 schema 常駐 context（消耗 token）
→ 返回結果塞回對話（消耗 token）

每次執行都在燒錢。工具的 schema 描述本身就佔了幾百到幾千 token，AI 還要推理該呼叫哪個工具、傳什麼參數。

對比表：

補充一個重要演進：Code Mode 正在改寫這張表。

前面提到 Cloudflare 的 cloudflare-api 用 Code Mode 把全 API 的 context 開銷壓到約 1000 token。如果用傳統方式——每個 endpoint 暴露成一個 tool——光 schema 就要 117 萬 token，直接超過絕大多數模型的上下文視窗。

Code Mode 代表的是一種趨勢：MCP 的探索模式正在變得更便宜。但它改變的是性價比，沒有改變根本邏輯——確定性操作落地成腳本仍然是最優解。

結論：MCP 當前最強的是探索能力，但正在向生產系統演化

正確的用法是分兩步走：

第一步：MCP 探索
  → "Cloudflare 有哪些 Workers？"
  → "這個 Worker 的日誌長什麼樣？"
  → "怎麼建立一個 KV namespace？"

第二步：落地成腳本
  → 探索完了，把確定性操作寫成程式碼
  → 丟進排程任務 / CI/CD
  → 0 token，永久執行

MCP 真正消滅的不是 API 呼叫，而是"我不知道該搜什麼"這個成本。

以前的流程是：Google → 翻十篇文件 → 篩選 → 找到正確 endpoint → 寫程式碼。中間那段人肉篩選，MCP 直接幹掉了。

第三種模式：當 MCP 遇上 Amazon 廣告

說到這裡，我以為兩種模式就能解釋一切了。直到我想到了 Amazon Ads。

我們在 Amazon 上銷售管理各種ASIN的ACos，日常工作之一是管廣告——拉資料、分析表現、調整 bid。Claude Code 接入了 Amazon Ads 的 MCP server，可以直接用自然語言操作廣告管理。

但這裡有一個問題：這到底算 MCP 還是 API？

答案是：都不完全是。這是第三種模式。

Amazon 廣告管理是一個判斷迴圈：

拉資料        → 可以腳本化（API）
分析表現      → 需要判斷（Claude）
做出調價決策  → 需要判斷（Claude）
執行調價      → 可以腳本化（API）

四步裡兩步需要 AI 參與，兩步可以自動化。它們交織在一起，每一輪迴圈都需要 Claude 的判斷力。

這意味著你沒辦法把 Claude 完全抽出去變成一個純腳本。每次迴圈都必須燒 token。

但這裡燒的不是摩擦成本。你燒的是判斷力。

傳統 MCP（探索型）的競爭對手是 Google 搜尋。Amazon 廣告管理的競爭對手是你自己坐那盯盤的時間。

幾千 token 值幾分錢。你盯一小時廣告值多少？

更重要的是，這個"判斷在環路裡"的模式正在加速進化。當前的實現是人類驅動——你說一句，AI 做一步。但 MCP + Agent + 記憶的組合已經在改變這一點。未來的版本更可能是：

你設目標（"把 ACOS 控制在 20% 以下"）
→ Agent 自己迴圈：拉資料 → 分析 → 決策 → 執行
→ 只在異常時通知你

這就是 Agent Loop——自主決策系統。人類從"逐步指揮"退到"設目標 + 審結果"。

用一張表把三種模式理清楚：

第三種才是 MCP 真正的終局形態。

誰在出 MCP

截至 2026 年 4 月，已經有官方 MCP 的平台包括：

2026 年 1 月，Anthropic 發布 MCP Apps，首批合作夥伴包括 Amplitude、Asana、Box、Canva、Clay、Figma、Monday.com、Salesforce。這是一個標誌性節點——MCP 從"開發者工具"正式進入"企業 SaaS 生態"。

還有一些是社群做的非官方 MCP server——比如 Telegram、Notion、Linear。品質參差不齊，但協定是標準化的。

我個人判斷，接下來大概率出 MCP 的：

• AWS Console — 不可能讓 Cloudflare 獨佔這個生態
• Google Cloud Console — GCP 資源直接自然語言操控
• Shopify — 電商 API 全打通
• Vercel / Netlify — 前端部署
• Azure — 微軟不會缺席

本質上就一句話：任何有 API 的平台，MCP 就是它的自然語言殼。

我的預測

短期（2026-2027）

MCP 會成為所有 SaaS 平台的標配功能，就像 OAuth 一樣。不出 MCP 的平台會被視為落後。

開發者的日常工作流會變成：先用 MCP 探索，再用 API 落地。MCP 不會取代 API，就像導航不會取代方向盤——你還是要自己開車，但不用再看紙本地圖了。

中期（2027-2028）

"判斷在環路裡"的第三種模式會成為主流。廣告管理、內容審核、客戶支援、財務分析——這些需要人類判斷的重複性工作，AI 會透過 MCP 深度嵌入。

token 成本會持續下降。今天覺得"每次迴圈都燒 token"不划算的場景，兩年後可能便宜到忽略不計。

長期

控制台（Console）會從主入口退居備用入口。

日常操作——查資料、改配置、發部署——會越來越多地透過自然語言完成。你不需要打開 Cloudflare 後台手動點按鈕了。你不需要登入 Amazon Seller Central 看報表了。

但 Console 不會消失。權限管理、帳單稽核、風險操作確認——這些場景需要可視化確認和合規留痕，不可能只靠一句自然語言。

更準確的說法是：Console 從操作介面變成稽核介面。

從這個角度講，MCP 不僅僅是一個協定。它是人機互動從圖形介面（GUI）到自然語言介面（NLI）的轉折點。

滑鼠點擊讓普通人能操作電腦。MCP 讓普通人能操作一切雲端服務。

門檻又降了一級。但安全門還在。

寫在最後

回到今晚。

三個 session，20分鐘，Cloudflare MCP 全部打通。我現在可以用自然語言管理我的所有 Cloudflare 資源——網域、儲存、部署、日誌、DNS。

這種感覺說實在的，有點像 2007 年第一次用 iPhone。

不是它做了什麼驚天動地的事。是你突然意識到：以前那些你以為必須那麼做的事，其實不用那麼做。