設想一個很常見的場景：一個在 laptop 上養得好好的 agent，要搬到 cloud 給團隊一起用。本來在 terminal 裡 CLI 串 git、grep 檔案、跑 pytest 都順得要命；搬上線第一天就發現——凡是需要搆到的東西突然全部連不到。行事曆在 Google、資料在 Snowflake、issue 在 Linear，每個都在遠端、都躲在認證後面、都要一套自己的 client。搬家從「換台 VM」變成「把八個整合重蓋一次」。

Anthropic 這篇新文第一句就把整個命題壓成一行：

“Agents are only as useful as the systems they can reach.”

agent 再聰明，搆不到它該搆的系統，就是廢物。 再漂亮的 reasoning trace、再炫的 evals，打不進行事曆、打不進 Snowflake、打不進那台跑在 AWS 背後的庫存系統，對 production 來說就是零。Anthropic 把連線外部世界這件事拆成三條常見路：直接 call API、call CLI、走 MCP（Model Context Protocol）。每一條各有甜蜜區、各有天花板，但一旦 agent 搬離 laptop 上 cloud——三條路最後都會 ship，可是只有 MCP 是會越用越值錢的那條。

三條路的甜蜜區跟天花板

三條路真正的差別不是「語法不一樣」，而是**「agent 跟外部服務之間那層共通介面，到底鋪多厚、鋪到哪裡」**。Anthropic 的框架：鋪愈厚、能到的 client 跟環境愈多，但前期投資也愈大。

Direct API call 是最短路——agent 在 code-execution sandbox 裡寫 HTTP request，或透過泛用的 function-calling tool 直接打 API。一個 agent 對一個 service、或少數幾個不需要跨平台重用的整合，這條就夠用，團隊大多也從這裡起步。真正的麻煩要到規模變大才爆出來：agent 跟 service 之間沒有共通層，每配一對就是一次客製整合——自己處理認證、自己寫 tool 說明、自己處理邊角問題。Anthropic 給這個現象一個正式名字：M×N integration problem。M 個 agent × N 個 service = M×N 套客製膠水。

CLI 快、輕、吃現成工具——有 filesystem 跟 shell 就能開工，是本地環境跟 sandbox container 的天選之子。但這層共通介面薄得像紙。一出本地就撞牆：手機打不到、網頁打不到、cloud 上那些不能開 container 的平台也打不到。認證靠的是躺在 disk 上的 credential 檔，不是上線後撐得住的解法。

MCP 把共通層升格成 protocol。agent 連到一個 server，server 用標準方式把系統能力開出來——認證、探索、語意資訊，全在協定裡定義。一個 remote server，任何相容 client 都能用（Claude、ChatGPT、Cursor、VS Code，還有更多），不管 client 跑在哪種 deployment environment。代價是前期投資稍大；回報是整合本身變成便攜的資產。

三條路，三種厚度。到這裡看起來像是在選「夠用就好」還是「一步到位」——但事情沒那麼簡單。真正決定該走哪條的，不是工程偏好，是 agent 明天會跑在哪裡。

Clawd 畫重點：

M×N 這個詞看起來像教科書用語，但它其實是很多團隊痛苦放大到一半，才自己發現的現實。想像成早期美國電力——每個發電廠用自己的電壓、自己的插頭、自己的頻率，電器要跨城市用就得自備一箱變壓器。MCP 就是 agent 世界的 AC 110V 標準化，把插頭統一了之後，才長得出遍地開花的電器生態。

不過 Anthropic 自己也沒在裝聖人——文末直接講，成熟的整合最後三條都會出。API 當地基（反正 MCP server 底下也得打 API）、CLI 給本地 sandbox 用、MCP 給上雲的 agent 用。這篇的論點不是「MCP 滅 API」，是三條路各有主場，搞清楚自己的 agent 住哪再下注。(⌐■_■)

Agent 搬上雲的那一天，MCP 就從加分配備變成地基

那問題來了：為什麼 Anthropic 這麼篤定，production 最後會收斂到 MCP？

答案不在技術本身，在地點。

Production agent 愈來愈多跑在 cloud 上——才能放大、才能一直運作。而它們要搆到的系統也大多在 cloud 上：Snowflake / Databricks 上的資料、Linear / Asana 上的工作追蹤、AWS / GCP / Cloudflare 上的基礎設施。全部在遠端、全部要過認證。恰好就是一層標準化協定最擅長接的形狀。

採用曲線也印證這不是 Anthropic 自己在自嗨。Anthropic 原文的數字：MCP SDK 下載量最近突破每月 3 億，從年初的 1 億一路衝上來。而且 Anthropic 自家最近端出的幾樣招牌菜——Claude Cowork、Claude Managed Agents、Claude Code 的 channels——底下統統都是 MCP 在撐：

Millions of people use MCP with Claude every day, and the protocol underpins much of what we’ve shipped recently, including Claude Cowork, Claude Managed Agents, and channels in Claude Code.

Protocol 不是規劃表上的一句話，是已經在 prod 吃流量的基礎設施。

Clawd 忍不住說：

把數字翻譯一下：3 億/月的 SDK 下載，代表這東西早就不是 demo 玩具，而是進了主流工具鏈。從 1 億衝到 3 億只花了不到一年——這個斜率要嘛是開發者生態真的爆開、要嘛是 Anthropic 自家產品把 MCP 塞進預設路線。很可能兩個一起。

但這裡藏了一個商業故事值得拉出來嚼：Anthropic 表面上把 MCP 定位成「別人寫 server、Anthropic 寫 client」的開放協定，骨子裡卻在最猛的 client 側（Claude.ai / Code / Cowork）跟最猛的 server 基建側（Managed Agents vault、CIMD auth）同時出牌。教科書級平台打法——底層標準化當公共財，上面再做自己的產品差異化。W3C 時代的瀏覽器大戰，劇本一模一樣 ╰(°▽°)⁠╯

兩個 tool 搞定 2,500 個 endpoint——設計對了，效果差一百倍

好，MCP 在理論上贏了。但一個設計爛的 MCP server 跟沒有 MCP 一樣廢——甚至更糟，因為多了一層沒在幫忙的抽象。Anthropic 自己的 directory 掛著 200+ 個 MCP server、每天被幾百萬人用，跟企業合作下來歸納出一套經驗法則。不是美學偏好，是「server 設成這樣，agent 才真的接得穩」。

先丟一個數字：

Cloudflare’s MCP server is the reference example—two tools (search and execute) cover ~2,500 endpoints in roughly 1K tokens.

Cloudflare 的 MCP server，兩個 tool、大約 1K token 的說明，就搆到約 2,500 個 endpoint。 同樣一大片 API，如果按 endpoint 一個一個做成 tool，光 tool 說明就能把 agent 的 context window 吃光。差別不在 API 本身，在 server 怎麼設計。

Cloudflare 怎麼做到的？兩層心法，一層比一層反直覺。

第一層：tool 是菜單，不是流程圖。 做菜的比喻——餐廳菜單寫「蔥爆牛肉」，廚房裡卻是切菜、醃肉、熱鍋、下料、翻炒、起鍋。客人只要那盤菜，中間那六步是 API，不是菜單。Anthropic 給了一個對照：

A single create_issue_from_thread tool beats get_thread + parse_messages + create_issue + link_attachment.

一個「從 thread 開 issue」的 tool，屌打四個拆開的 tool。agent 每呼叫一次都消耗 context 跟思考空間，能一步做完卻硬切四步，就是在繳冤枉稅。少、但描述清楚的 tool 永遠打贏多、把 API 一比一照抄的 tool。

第二層才是狠的：如果 API 大到連「照目的分組」都分不完呢？ Cloudflare、AWS、Kubernetes 這種幾千個 endpoint 的怪獸，按 intent 分組也是上百個 tool。Anthropic 的解法不是列得更細，而是收得更瘦——把露出來的 tool 收到只剩兩個，讓 agent 寫 code。agent 寫一小段 script、server 在 sandbox 跑、結果丟回來。agent 的 context 不被幾千個 tool description 淹沒，語義上又保留完整的操作空間——一支筆通往整個動作空間，比幾千張表格好用太多。

Clawd OS：

這招本質上是把**「列舉全部動作」換成「給 agent 一支筆」**——寫 code 的表達力比列 tool 高太多了。一個迴圈、一個 filter、一個 grep，抵過上百個分開的 endpoint call。

但讓 Clawd 真正興奮的不是技巧本身，而是這背後的設計哲學翻轉。傳統思維是「API 有什麼，tool 就列什麼」——鏡射、列滿、看起來安全。Cloudflare 說不對，該交給模型想的是「目標」，該交給固定流程跑的是「API 序列」——code orchestration 剛好把兩邊切得最乾淨。這不是 hack，是重新想過「tool 的職責到底是什麼」之後的結論 (๑•̀ㅂ•́)و✧

Production 的三道牆：文字不夠、agent 瞎猜、token 進不去

Remote 鋪好了、tool 收好了。然後呢？然後就是 production 特有的三道牆——在 demo 環境完全碰不到、一上線就撞得滿頭包的那種。

第一道牆：agent 吐出來的東西，沒人想看。 文字回傳是 MCP 的底線，但 KPI 該給圖表、填表該給表單、長時間任務該給進度條。文字不是答案的最佳形狀，偏偏大多數 MCP server 只會吐文字。Anthropic 把這個能力缺口放進 MCP Apps——protocol 的第一個官方擴充——讓 tool 能回傳可互動的介面，直接在 chat 裡長出來。他們觀察到的結果很直白：有 MCP Apps 的 server，採用率跟留存明顯高於只回純文字的 server。目前 Claude.ai、Claude Cowork、還有其他多數主流 AI 工具都支援這個擴充。

第二道牆更刁鑽：agent 做到一半發現缺資訊，怎麼辦？ 傳統答案只有兩個——亂猜一個（幻覺），或者丟一段摘要給 user，叫人去別的介面填（體驗斷裂）。Elicitation 開出第三條路：tool call 中途可以暫停、問 user、再繼續。Form mode 讓 server 丟一份 schema、client 渲染原生 form，補一個缺的參數、確認一個破壞性操作；URL mode 把 user 導到瀏覽器，跑 downstream OAuth 或收款——任何不該流經 MCP client 的敏感東西都走這條。原文交代相容性：form mode 廣泛支援；URL mode 在 Claude Code 已上線，其他 client 還在陸續接。

第三道牆，也是最多 side project 死在上面的那道：agent 拿不到 token。 場景：agent 跑在雲上、要幫 user 操作 GitHub 或 Snowflake，得拿著 user 的 token——但那個 token 不能流進 LLM、也不能寫死在 code 裡。最新 MCP spec 支援 CIMD (Client ID Metadata Documents) 做 client 註冊，新 user 第一次 auth 會順很多，之後也比較不會突然跳出來要重新登入。授權完事下一個難題是：雲上的 agent 要怎麼保管、重複使用這些 token？Anthropic 有自家的解——Claude Managed Agents 裡的 Vaults：user 的 OAuth token 登記一次、session 起來靠 vault ID 帶進來、平台自動注入對的 credential 並自動 refresh。SP-167 拆過這套產品本體，這裡不重複。

三道牆，一道比一道無聊、一道比一道致命。Demo 的時候都不是問題——反正 demo 都跑在本地、用自己的 token、吐文字也沒差。搬上線那天，這三道牆才會一起從地板冒出來。

Clawd 溫馨提示：

三道牆裡面，Elicitation 是最該讓 agent 圈集體慚愧的。Tool call 中途暫停問一下再繼續——這個 UX primitive 在 web app 圈叫 modal 彈窗，存在超過二十年了。Agent 圈直到 MCP 這個 spec 才正式把它收進制度裡。二十年。

Vault + CIMD 那組也是——本質上就是承認「auth 是 production 的必修課，但跟 agent 邏輯完全沒關係」這個現實，然後把它收進平台層。之前不少 agent side project 爛在原型階段、上不了正式環境，就是卡在這類「不難但很煩、一寫就兩千行」的認證基建。現在有人幫蓋了。補得比想像中還晚，但補上了 ┐(￣ヘ￣)┌

Agent 看起來很聰明，其實正在挨餓

Server 端搞定了——remote、intent-grouped、auth 有 vault 撐。換到 client 端，也就是 agent 自己那邊，還有一個大家愛忽略的問題：agent 的 context window 看起來很大，其實已經快被吃光了。

MCP server 普及之後，一個 agent 可能同時連到幾十個 server、幾百個 tool。把全部 tool definition 一次塞進 context window——大部分用不到，但每一個都佔著思考空間。就像一個人的桌子夠大，但上面堆滿了用不到的參考書，結果連筆記本放的位置都沒有。

Anthropic 列了兩招，各自附上實測數字。

第一招擋在入口：需要才載入。 一開始不塞全部 tool，agent 跑到需要某一類工具時，再去搜尋清單、拉進來用。Anthropic 的實測：

tool search tends to cut tool-definition tokens by 85%+ while maintaining high selection accuracy.

注意 “tends to”——通常砍 85%+，並維持選擇準確度。不是保證值、是常態觀察。落地的感受：原本 agent 連到 8 個 server，tool spec 塞滿 context 前段、真正能思考的空間被擠掉一半；換上 tool search 之後，本來只撐得了 5 步的任務能撐到 15 步以上。差別不是優化幾個百分點——是 agent 跑不跑得完一個真實任務。

第二招擋在出口：結果先揉過才進 context。 Tool 吐出來的原始回應不直接塞回 model，而是先丟進 code execution sandbox 整理、過濾、彙總，只有算完的結論進 context。Anthropic 的數字：

this reduces token usage by roughly 37% on complex multi-step workflows.

兩道過濾器疊起來才是複利效果——入口擋雜訊、出口擠水分——不是二選一。

Clawd murmur：

Claude / ChatGPT / Cursor 的 context 都在幾十萬 token 等級了，看起來很寬裕。這是做 agent 的人最常踩的盲區。

打個比方：一間 30 坪的辦公室聽起來夠大，但如果前 15 坪堆滿了沒人在看的合約副本（tool spec）、再 5 坪放上週的會議記錄（prior turns）、2 坪是公司章程（system prompt），實際能攤開筆電工作的空間剩不到 8 坪。Context 看起來夠用 ≠ agent 真的有空間思考。 省 context 不是為了省 token 費用，是為了讓 agent 在真正需要思考的時候，桌上還有地方攤開資料 ٩(◕‿◕｡)۶

結語：三條路一起 ship，MCP 會複利——附上使用說明書之後更猛

文章的收束句：

In practice, mature integrations will ship all three: the API as the foundation, a CLI for local-first environments, and MCP for cloud-based agents.

成熟的整合三條路都會 ship——API 當地基、CLI 給 local-first 環境、MCP 給雲端 agent。不是單選題。但 Anthropic 把關鍵差異點出來：當 production agent 搬到雲上那一刻，MCP 從「有也不錯」變成「少了不行的那一層」——而且它是唯一會複利的那一條。

複利怎麼來的？今天寫好一個 remote server，它自動能被所有相容 client 吃、也能跑在各種部署環境裡。協定繼續長、擴充繼續進來，同一個 server 不用自己出新版，就會跟著變強。原文的總結很漂亮：

Every integration built on MCP strengthens the ecosystem: fewer edge cases to solve alone, fewer bespoke integrations to maintain.

每一個建在 MCP 上的整合都在強化生態——要自己踩的坑變少、要自己維護的客製整合變少。

不過 Anthropic 在文章後半埋了一個更低調、但可能更重要的伏筆：MCP 不只是管子，附上 skill 之後它變成帶使用說明書的工具箱。Skill 是前陣子 SP-179 Garry Tan skillify 拆過的做法——把失敗經驗結晶成 SKILL.md + 固定腳本。MCP 給 agent 原料（tool + data），skill 教 agent 怎麼把這些原料煮成一桌菜。Anthropic 自己的 Cowork data plugin 已經是這個形狀：10 個 skill + 8 個 MCP server，覆蓋 Snowflake、Databricks、BigQuery、Hex。而 Canva、Notion、Sentry 這些 provider 也開始在發布 MCP server 時順手附上 skill——agent 一次拿到工具箱跟 SOP 手冊。MCP 社群正在做一個讓 server 直接把 skill 一起送出來的擴充，成形之後 skill 會跟 API 一起版本化，API 改版 skill 也跟著換。

回到開頭那個搬家搬到崩潰的 agent。如果那八個系統都有 remote MCP server，搬上線那天不是「重蓋八個整合」，而是「連上八條線」。差別就在這裡。不是技術選型，是部署地點的函數。

Clawd 畫重點：

「provider 附一份 skill」這件事讀起來像加分配備，但它可能是 MCP 生態最低調卻最重要的演化。想像一下：今天連到一個新的 MCP server，agent 除了拿到 tool list，還拿到「這些 tool 該怎麼組合、常見錯誤是什麼、這家 API 有哪些坑」——等於雇主把工具箱交給新員工的同時，把公司 SOP 手冊一起發下去。短期看會有一波「誰的 skill 寫得好誰就吃到 agent 流量」的平台競爭，跟早期 App Store ASO 的動態有點像。

但最實用的結論，留給正在做 side project 的人：如果 agent 只搆 2-3 個 service、只給自己用，直接 call API 就夠了。 等哪天要上線、給多個 client 用、或讓別人也能接——那才是重新評估走 MCP 的時候。別還在 MVP 階段就硬上 MCP——過早優化從來不是因為工具不好，而是因為選的時機不對 ʕ•ᴥ•ʔ