Agent 要上生產？MCP 才是那個繞不開的基礎設施
整理版優先睇
MCP係Agent上生產嘅關鍵基礎設施，正跑出網絡效應
呢篇文章係整理自Anthropic嘅技術博客，講解Agent點樣連接生產系統。作者認為，Agent再聰明，碰唔到系統就只係聊天機械人，而目前最核心嘅瓶頸唔係模型能力，而係Agent同外部系統之間嘅連接方式。文章系統咁比較咗三條路：直接調API、跑CLI、同用MCP協議層，最後指出MCP因為標準化同網絡效應，正成為Agent世界嘅TCP/IP。
整體結論係：MCP唔係最花哨嘅方案，但係最可能存活落嚟嘅一個。Anthropic從200+ MCP Server提煉出五個設計模式，包括建遠程Server、按意圖組織工具、必要時讓Agent寫代碼、利用MCP Apps提升交互、用標準化鑑權。另外有兩個節省Token嘅技巧：工具搜索同程序化工具調用。最後講MCP+Skills可以打造領域專家，捆綁分發或從Server分發Skills。對於技術決策者，問題已經唔係用唔用MCP，而係點樣將MCP Server做到足夠好。
- MCP因為標準化同網絡效應，成為Agent連接生產系統嘅預設方案，好似TCP/IP咁。
- 建遠程Server係關鍵，覆蓋Web、移動端同雲端Agent，一次建設處處可用。
- 按意圖組織工具，唔好一對一包REST API，模型需要更少、更聰明嘅工具。
- 如果操作面太大，讓Agent寫代碼，用搜索+執行兩個工具覆蓋成千上萬端點。
- MCP+Skills可以捆綁分發，令Agent變成領域專家，Canva、Notion等已經採用。
連接Agent嘅三條路
Anthropic歸納出連接Agent同外部系統嘅三條路：直接調API、跑CLI、用MCP。直接調API係大多數團隊嘅起點，Agent喺沙箱寫代碼發HTTP請求，但每多一個服務就多一套鑑權邏輯，
複雜度係乘法級
。CLI更輕量，Agent直接在Shell跑命令，但只限有文件系統嘅環境。
MCP係協議層，一次建設處處可用
Agent連接到MCP Server，鑑權、服務發現、工具語義全部標準化，一個遠程Server兼容所有客戶端。
MCP點解贏？網絡效應
一個協議成唔成，睇有冇人用。Anthropic數據顯示MCP SDK月下載量由年初1億突破
3億
，已經過咗嚐鮮階段，進入
默認選項
階段。背後邏輯係生產級Agent正在遷移到雲端，需要標準化方式打通鑑權牆後面嘅系統。
五個設計模式令MCP Server更好用
Anthropic從200+ MCP Server提煉出五個模式，全部都係實際踩坑後嘅經驗。關鍵在於
更少、更聰明嘅工具，永遠比一堆原子操作好用
。另外一個重要原則是按意圖組織工具，唔好一對一包REST API。以下係五個模式：
- 1 建遠程Server：唯一覆蓋Web、移動端同雲端Agent嘅方式，主流客戶端優先適配。
- 2 按意圖組織工具：直接暴露高層次工具例如create_issue_from_thread，唔好比模型拆解多步操作。
- 3 如果操作面太大，讓Agent寫代碼：Cloudflare只暴露搜索同執行兩個工具，用沙箱跑腳本，覆蓋約2500個端點只佔1000 token。
- 4 利用MCP Apps同Elicitation做交互：工具可以返回圖表表單，Server可以暫停問用戶確認操作，提升安全同採用率。
- 5 用標準化鑑權：CIMD配合Claude Vaults，OAuth token一次註冊自動注入，唔使自己造輪子。
節省Token嘅兩個殺手級技巧
工具搜索：按需搜索工具定義，減少85%以上token
唔好喺啓動時加載所有工具定義，而係運行時按需搜索，保持高選擇準確率。
程序化工具調用：工具結果先喺沙箱循環過濾聚合，只畀最終結果模型
複雜多步工作流嘅Token消耗降低約37%。呢兩個模式可以疊加，令上下文更精簡、交互輪次更少、響應更快。
MCP + Skills = 領域專家
MCP畀Agent「手」去操作系統，Skills就係「腦」知道點用工具完成工作。Anthropic提出兩種組合模式：
捆綁分發同從Server分發Skills
呢兩個模式可以幫Agent變成
領域專家
- 捆綁分發：將Skills同MCP Server打包成Plugin，例如數據分析Plugin包含10個Skills同8個MCP Server，Agent拎到一個完整能力包。
- 從Server分發Skills：Server直接攜帶Skills，客戶端連線就自動獲說明書，版本跟API走。Canva、Notion、Sentry已經採用。
一個 Agent 幾聰明都好，如果掂唔到你嘅系統，佢都只係一個聊天機械人。
呢句話聽落好似廢話，但係佢揭示咗而家 AI 工程化最核心嘅瓶頸——唔係模型能力唔夠，而係 Agent 同外部系統之間欠一條可靠嘅「線」。
Anthropic 發表咗一篇技術博客，系統咁講咗佢哋喺呢個問題上嘅諗法：Agent 點樣連接生產系統？邊種方式最終會勝出？同埋，點樣將 MCP（Model Context Protocol）做到真正好用。
今日我哋就嚟拆解呢篇文章背後嘅信號。
三條路，各有各嘅天花板
連接 Agent 同外部系統，業界收窄成三條路：直接 call API、行 CLI、用 MCP。
「直接 call API」 係大多數團隊嘅起點。Agent 喺 sandbox 入面寫 code 發 HTTP request，簡單直接。但問題係——每多接一個服務，就多一套鑑權邏輯、工具描述同異常處理。M 個 Agent × N 個服務，複雜度係乘法級。
「CLI」 更輕量，Agent 直接喺 shell 入面行你嘅 command line 工具。本地開發特別爽。但佢天然受限於「有 file system 同 shell」嘅環境——手機端、Web 端、雲端託管嘅 Agent，CLI 掂唔到。
「MCP」 嘅思路唔同：佢唔係一個 tool，而係一個 protocol 層。Agent 連接到一個 MCP Server，呢個 Server 將你係統嘅能力曝露出來，鑑權、服務發現、工具語義全部標準化。一個遠端 Server，所有兼容嘅 client 都用得——Claude、ChatGPT、Cursor、VS Code，唔揀環境。
「代價係咩？」 前期投入多少少。回報係咩？一次建設，周圍用得。
點解話 MCP 喺「贏」
一個 protocol 成唔成，唔係睇設計有幾優雅，係睇有冇人用。
Anthropic 畀出嘅數據好直接：MCP SDK 每月下載量已經突破 「3 億」，年初仲係 1 億。呢個增速代表佢已經過咗「試新嘢」階段，進入咗「默認選項」階段。
背後嘅邏輯都好清楚——「生產級 Agent 正在搬去雲端」。佢哋需要 7×24 運行、彈性伸縮，而佢哋要掂到嘅系統同樣喺雲端：數據倉庫、項目管理工具、基礎設施平台。呢啲系統都喺鑑權牆後面，你需要一個標準化嘅方式去打通。
MCP 啱啱就係呢個標準化層。
呢個同互聯網早期嘅故事驚人相似。當年每個網絡協議都有自己嘅一套連接方式，直到 TCP/IP 成為公共層。MCP 正在成為 Agent 世界嘅「TCP/IP」——唔係最花俏嘅方案，但可能係最終生還嗰個。
五個設計模式，決定你嘅 MCP Server 好唔好用
Anthropic 喺博客入面總結咗佢哋從 200+ MCP Server 同大量企業合作中提煉出嘅模式。呢啲唔係理論，係踩過坑之後嘅經驗。
1. 建立遠端 Server，唔好淨係做本地
遠端 Server 係分發能力嘅關鍵。佢係唯一可以同時覆蓋 Web、手機端同雲端 Agent 嘅部署方式，亦係所有主流 client 優先適配嘅模式。如果你淨係做本地 Server，你嘅覆蓋面自然受限。
2. 按意圖組織 tool，唔係按 API endpoint
呢條特別重要。
好多團隊嘅第一反應係將 REST API 一對一封裝成 MCP tool。但模型唔係 programmer——佢唔擅長將 get_thread → parse_messages → create_issue → link_attachment 串埋一齊。
更好嘅做法：直接曝露一個 create_issue_from_thread tool，等 Agent 一步到位。「更少、更聰明嘅 tool，永遠比一堆原子操作好用。」
3. 如果操作面太大，畀 Agent 寫 code
Cloudflare、AWS、Kubernetes 呢類平台有成千上百個操作，你冇可能將每個都封裝成一個意圖 tool。Cloudflare 嘅做法係：淨係曝露兩個 tool——搜索同執行。Agent 寫一小段 script，Server 喺 sandbox 入面行，返回結果。兩個 tool 覆蓋大約 2500 個 endpoint，context 只係佔大約 1000 token。
呢個模式嘅本質係：「將編排能力交畀模型嘅 code 生成能力，而唔係 tool 設計者嘅窮舉能力。」
4. 利用 MCP Apps 同 Elicitation 做交互
MCP 唔止係傳文字。MCP Apps 擴展允許 tool 返回圖表、表單、dashboard 等交互界面，直接喺 chat 入面渲染。Anthropic 嘅數據顯示，提供 MCP Apps 嘅 Server 喺採用率同留存率上顯著優於純文字 Server。
Elicitation 就允許 Server 喺執行途中暫停，向用戶要資訊——確認一個危險操作、補一個缺失參數、完成下游 OAuth。呢個令到 Agent 嘅行為更安全、更符合預期。
5. 用標準化鑑權，唔好自己造輪
MCP 最新規範支援 CIMD（Client ID Metadata Documents）做 client 註冊，配合 Claude 平台嘅 Vaults 能力，OAuth token 註冊一次，後續自動注入同 refresh。唔使自己整密鑰儲存，唔使每次 call 都要傳 token。
令到 client 更慳 Token 嘅兩個殺手鐧技巧
如果你喺構建 MCP client（Agent 側），context 效率至關重要。兩個模式值得留意：
「Tool 搜索（Tool Search）」：唔係喺啟動時 load 曬所有 tool 定義，而係運行時按需要搜索。Anthropic 測試顯示，呢個可以減少 85% 以上嘅 tool 定義 token，同時保持高選擇準確率。
「程式化 Tool 調用（Programmatic Tool Calling）」：tool 結果唔直接返畀模型，而係先喺 code sandbox 入面循環、過濾、聚合，淨係將最終結果畀模型。複雜多步 workflow 嘅 token 消耗降低大約 37%。
呢兩個模式可以疊加。效果：更精簡嘅 context、更少嘅交互輪次、更快嘅響應。
MCP + Skills = 領域專家
MCP 畀咗 Agent 「手」——可以操作外部系統。但淨係得手唔夠，重要有「腦」——知道點樣用呢啲 tool 完成真正嘅工作。呢個就係 Skills 嘅角色。
Anthropic 畀出兩個組合模式：
「捆綁分發」：將 Skills 同 MCP Server 打包成 Plugin。例如佢哋嘅數據分析 plugin，包含 10 個 Skills 同 8 個 MCP Server，覆蓋 Snowflake、Databricks、BigQuery 等平台。Agent 攞到嘅唔係一堆散修修嘅 tool，而係一個領域專家嘅完整能力包。
「從 Server 分發 Skills」：MCP 社區正在開發一個擴展，等 Server 直接攜帶 Skills。Client 連上 Server 就自動獲得使用說明書，版本跟住 API 走。Canva、Notion、Sentry 已經係咁做。
寫喺最後：複利效應
回到開頭嘅三條路——成熟嘅集成最終會三條都行：API 係地基，CLI 服務本地環境，MCP 覆蓋雲端 Agent。
但 MCP 係嗰個有複利效應嘅層。今日你起一個遠端 Server，佢可以掂到所有兼容 client。聽日 protocol 新增咗一個擴展，你嘅 Server 唔使改一行 code，就自動獲得新能力。接入嘅 client 越多、擴展越豐富，你當初嗰個投入嘅回報就越大。
對於技術決策者嚟講，問題已經唔係「使唔使用 MCP」，而係「點樣將 MCP Server 做到足夠好」。
「Protocol 之戰嘅終局，從來唔係邊個最優雅，而係邊個先跑出網絡效應。」
MCP 正在跑。
❝原文連結：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
❞
一個 Agent 再聰明，如果碰不到你的系統，它就只是一個聊天機器人。
這句話聽起來像廢話，但它揭示了當前 AI 工程化最核心的瓶頸——不是模型能力不夠，而是 Agent 和外部系統之間缺一根可靠的"線"。
Anthropic 發佈了一篇技術博客，系統性地講了他們在這個問題上的思考：Agent 怎麼連接生產系統？哪種方式最終會勝出？以及，怎麼把 MCP（Model Context Protocol）做到真正好用。
今天我們就來拆解這篇文章背後的信號。
三條路，各有各的天花板
連接 Agent 和外部系統，業界收斂出三條路：直接調 API、跑 CLI、用 MCP。
「直接調 API」 是大多數團隊的起點。Agent 在沙箱裏寫代碼發 HTTP 請求，簡單直接。但問題是——每多接一個服務，就多一套鑑權邏輯、工具描述和異常處理。M 個 Agent × N 個服務，複雜度是乘法級的。
「CLI」 更輕量，Agent 直接在 shell 裏跑你的命令行工具。本地開發特別爽。但它天然受限於"有文件系統和 shell"的環境——移動端、Web 端、雲端託管的 Agent，CLI 夠不着。
「MCP」 的思路不同：它不是一個工具，而是一個協議層。Agent 連接到一個 MCP Server，這個 Server 把你係統的能力暴露出來，鑑權、服務發現、工具語義全部標準化。一個遠程 Server，所有兼容的客戶端都能用——Claude、ChatGPT、Cursor、VS Code，不挑環境。
「代價是什麼？」 前期投入稍多。回報是什麼？一次建設，處處可用。
為什麼說 MCP 在"贏"
一個協議能不能成，不看設計多優雅，看有沒有人用。
Anthropic 給出的數據很直接：MCP SDK 月下載量已經突破 「3 億」，年初還是 1 億。這個增速意味着它已經過了"嚐鮮"階段，進入了"默認選項"階段。
背後的邏輯也很清楚——「生產級 Agent 正在遷移到雲端」。它們需要 7×24 運行、彈性伸縮，而它們要觸達的系統同樣在雲端：數據倉庫、項目管理工具、基礎設施平台。這些系統都在鑑權牆後面，你需要一個標準化的方式去打通。
MCP 恰好是這個標準化層。
這和互聯網早期的故事驚人相似。當年每個網絡協議都有自己的一套連接方式，直到 TCP/IP 成為公共層。MCP 正在成為 Agent 世界的"TCP/IP"——不是最花哨的方案，但可能是最終存活下來的那個。
五個設計模式，決定你的 MCP Server 好不好用
Anthropic 在博客中總結了他們從 200+ MCP Server 和大量企業合作中提煉出的模式。這些不是理論，是踩過坑之後的經驗。
1. 建遠程 Server，不要只做本地
遠程 Server 是分發能力的關鍵。它是唯一能同時覆蓋 Web、移動端和雲端 Agent 的部署方式，也是所有主流客戶端優先適配的模式。如果你只做本地 Server，你的覆蓋面天然受限。
2. 按意圖組織工具，而非按 API 端點
這一條特別重要。
很多團隊的第一反應是把 REST API 一對一包成 MCP 工具。但模型不是程序員——它不擅長把 get_thread → parse_messages → create_issue → link_attachment 串起來。
更好的做法：直接暴露一個 create_issue_from_thread 工具，讓 Agent 一步到位。「更少、更聰明的工具，永遠比一堆原子操作好用。」
3. 如果操作面太大，讓 Agent 寫代碼
Cloudflare、AWS、Kubernetes 這類平台有成百上千個操作，你不可能把每個都包成一個意圖工具。Cloudflare 的做法是：只暴露兩個工具——搜索和執行。Agent 寫一小段腳本，Server 在沙箱裏跑，返回結果。兩個工具覆蓋約 2500 個端點，上下文只佔約 1000 token。
這個模式的本質是：「把編排能力交給模型的代碼生成能力，而不是工具設計者的窮舉能力。」
4. 利用 MCP Apps 和 Elicitation 做交互
MCP 不只是傳文本。MCP Apps 擴展允許工具返回圖表、表單、儀表盤等交互界面，直接在聊天中渲染。Anthropic 的數據顯示，提供 MCP Apps 的 Server 在採用率和留存率上顯著優於純文本 Server。
Elicitation 則允許 Server 在執行過程中暫停，向用戶要信息——確認一個危險操作、補一個缺失參數、完成下游 OAuth。這讓 Agent 的行為更安全、更符合預期。
5. 用標準化鑑權，別自己造輪子
MCP 最新規範支持 CIMD（Client ID Metadata Documents）做客戶端註冊，配合 Claude 平台的 Vaults 能力，OAuth token 註冊一次，後續自動注入和刷新。不用自建密鑰存儲，不用每次調用傳 token。
讓客戶端更省 Token 的兩個殺手級技巧
如果你在構建 MCP 客戶端（Agent 側），上下文效率至關重要。兩個模式值得關注：
「工具搜索（Tool Search）」：不在啓動時加載所有工具定義，而是運行時按需搜索。Anthropic 測試顯示，這能減少 85% 以上的工具定義 token，同時保持高選擇準確率。
「程序化工具調用（Programmatic Tool Calling）」：工具結果不直接返回給模型，而是先在代碼沙箱裏循環、過濾、聚合，只把最終結果給模型。複雜多步工作流的 token 消耗降低約 37%。
這兩個模式可以疊加。效果：更精簡的上下文、更少的交互輪次、更快的響應。
MCP + Skills = 領域專家
MCP 給了 Agent "手"——能操作外部系統。但光有手不夠，還需要"腦"——知道怎麼用這些工具完成真正的工作。這就是 Skills 的角色。
Anthropic 給出兩個組合模式：
「捆綁分發」：把 Skills 和 MCP Server 打包成 Plugin。比如他們的數據分析插件，包含 10 個 Skills 和 8 個 MCP Server，覆蓋 Snowflake、Databricks、BigQuery 等平台。Agent 拿到的不是一堆零散工具，而是一個領域專家的完整能力包。
「從 Server 分發 Skills」：MCP 社區正在開發一個擴展，讓 Server 直接攜帶 Skills。客戶端連上 Server 就自動獲得使用說明書，版本跟着 API 走。Canva、Notion、Sentry 已經在這樣做了。
寫在最後：複利效應
回到開頭的三條路——成熟的集成最終會三條都走：API 是地基，CLI 服務本地環境，MCP 覆蓋雲端 Agent。
但 MCP 是那個有複利效應的層。今天你建一個遠程 Server，它能觸達所有兼容客戶端。明天協議新增了一個擴展，你的 Server 不用改一行代碼，就自動獲得新能力。接入的客戶端越多、擴展越豐富，你當初那個投入的回報就越大。
對於技術決策者來說，問題已經不是"要不要用 MCP"，而是"怎麼把 MCP Server 做到足夠好"。
「協議之戰的終局，從來不是誰最優雅，而是誰先跑出網絡效應。」
MCP 正在跑。
❝原文連結：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
❞