MCP 不只是開發工具:生產級 Agent 集成的三條路

作者:Feisky
日期:2026年4月23日 下午1:40
來源:WeChat 原文

整理版優先睇

速讀 5 個重點 高亮

MCP係生產環境Agent集成最務實嘅選擇:三條路、服務器設計與認證標準化

整理版摘要

呢篇文章係Anthropic官方博客嘅編譯,作者整理咗Agent連接外部系統嘅三條路:直接APICLIMCP。文章指出,本地開發時CLI同MCP都夠用,但一旦Agent要上雲、服務多個客戶端,MCP就幾乎係唯一選擇。Anthropic特別強調生產環境,因為生產Agent同佢哋需要連接嘅系統都喺雲上,MCP擅長處理遠程、帶認證嘅場景。

文章詳細梳理咗MCP服務器嘅設計模式,包括遠程服務器優先、按意圖分組工具、大量API用代碼編排、用MCP Apps做交互、Elicitation能力等。認證方面,CIMD簡化咗OAuth流程,Vault機制處理令牌存儲同刷新。上下文效率方面,Tool Search同程序化工具調用大大降低token佔用。最後,文章講到Skills同MCP係互補嘅,Skill提供知識,MCP提供能力,兩種組合模式可以令Claude從通用助手變成領域專家。

總括嚟講,呢篇文章對於想將Agent集成到生產系統嘅開發者好有參考價值,尤其係MCP服務器設計同認證標準化嘅實踐建議。

  • MCP係生產環境Agent集成最務實嘅選擇,前期投入大但換來可移植性同協議層標準化。
  • MCP服務器設計要遠程優先、按意圖分組工具,大量API場景可以用代碼編排(如Cloudflare模式)。
  • 認證標準化透過CIMDVault機制解決,令牌管理變成基礎設施一部分。
  • 上下文優化靠Tool Search(按需加載工具定義)同程序化工具調用(在沙箱處理結果),token佔用大幅降低。
  • Skills同MCP互補MCP提供能力,Skills提供知識,可以打包成Plugin或由服務器自帶Skill。
值得記低
連結 claude.com

原文:Building agents that reach production systems with MCP

Anthropic官方博客,講解Agent集成外部系統嘅三條路同MCP實踐

連結 modelcontextprotocol.io

MCP SDK 文檔

MCP SDK官方文檔,包含服務器同客戶端實作指南

連結 modelcontextprotocol.io

MCP Apps 擴展

MCP協議第一個官方擴展,允許工具返回交互式界面

連結 anthropic.com

進階工具使用指南

Anthropic關於點樣設計畀Agent用嘅工具嘅最佳實踐

整理重點

Agent連接外部系統嘅三條路

Anthropic將Agent接入外部系統分成三種:直接調API、用CLI,同埋行MCP協議。

直接調API係最簡單,但一多服務就會出現經典嘅M×N集成問題。

CLI快同輕量,但喺移動端、Web端同雲端冇shell嘅地方會碰壁,認證靠磁盤憑證,離生產仲差一截。

MCP走協議層,認證、發現、語義描述都標準化,一個遠程服務器可以同時服務多個客戶端。

本地開發階段CLIMCP都夠用,但Agent一上雲,MCP幾乎係唯一選擇。

整理重點

MCP服務器設計模式

Anthropic目前MCP目錄有200多個服務器,從中提煉咗幾個設計模式。

遠程服務器優先:只有遠程服務器先可以同時覆蓋Web、移動端同雲端Agent。

按意圖分組工具,唔好一比一鏡像API,減少工具數量,提高準確率。

大量API場景用代碼編排,例如Cloudflare只暴露兩個工具(搜索同執行),覆蓋2500個API端點,工具定義只佔1K token。

MCP Apps做交互,工具可以返回交互式界面,提升用戶體驗。

Elicitation能力允許服務器喺工具調用中途暫停向用戶請求輸入,安全敏感操作可以引導用戶瀏覽器完成。

  • 遠程服務器優先:確保分發到所有環境。
  • 按意圖分組工具:減少模型選擇難度,提升準確率。
  • 大量API場景用代碼編排:用搜索+執行兩個工具覆蓋數千端點。
  • 用MCP Apps做交互:圖表、表單、儀表盤直接嵌對話。
  • Elicitation能力:中途暫停請用戶輸入,適合敏感操作。
整理重點

認證標準化同上下文效率

認證一直係MCP從開發到生產最頭痛嘅部分,每個服務器都要自己處理OAuth流程,邊角情況踩唔完。

CIMD簡化咗OAuth流程,減少重複授權,已經喺MCP SDKClaude.ai同Claude Code支援。

Vault機制處理令牌存儲同刷新,Managed Agents自動注入憑證,過期自動刷新,唔使自己搞密鑰管理。

令牌管理變成基礎設施一部分,應用層唔使操心,類似Kubernetes ServiceAccount自動掛載token。

上下文效率方面,Tool Search按需加載工具定義,token佔用降低85%以上,選擇準確率基本唔受影響。

程序化工具調用喺沙箱處理結果,只放最終輸出入上下文,複雜多步工作流節省約37% token。

整理重點

Skills同MCP係互補嘅

MCP畀Agent能力(能調什麼工具、能訪問什麼數據),Skills畀Agent知識(點樣用呢啲工具完成具體任務),兩者最好結合使用。

兩種組合模式:將Skills同MCP服務器打包成Plugin,或者由MCP服務器自帶Skill。

Plugin可以捆綁Skills、MCP服務器、Hooks、子Agent等組件,一鍵分發,令Claude從通用助手變成領域專家。

CanvaNotionSentry等廠商已經喺做服務器自帶Skill,MCP社區亦喺做擴展讓服務器直接分發Skills,版本跟API走。

MCP服務器只提供工具嘅話,Agent每次都要自己摸索調用順序同參數搭配,效率唔高。


題記:呢篇文編譯自 Anthropic 博客《Building agents that reach production systems with MCP[1]》。文章由 Agent 連接外部系統嘅三條路講起,重點梳理咗 MCP 服務器嘅設計模式、認證標準化、上下文優化,同 Skills 嘅互補定位。唔算長,但信息密度唔低,尤其係 Cloudflare 嘅代碼編排模式同 Vault 嘅憑證管理思路,值得做 MCP 服務器嘅人細睇同參考。

我之前幫 Claude Code 配置 MCP 服務器嘅時候,最頭痛係上下文佔用嘅問題,後來《Claude Code 終於解決咗 MCP 最大嘅痛點》嗰篇寫過 Tool Search 點樣解決呢個問題。但係用得越多越發現,上下文只係冰山一角。

本地開發時,Agent 叫個 API、行個命令行工具,一切都很順暢。但等你諗住將佢放上雲行,問題就嚟喇:CLI 工具冇 shell 可以用,API 調用嘅認證憑證要自己管,每對接一個新服務就要從頭寫一套集成代碼。

啱啱見到 Anthropic 發咗一篇博客,系統梳理咗 Agent 連接外部系統嘅三條路,同埋點解生產環境下 MCP 可能係最務實嘅選擇,分享下,俾大家參考。

將 Agent 接入外部系統

Anthropic 將 Agent 接入外部系統嘅方式分做三種:直接叫 API、用 CLI,同行 MCP 協議。

直接叫 API 係最多人嘅起點,亦係最簡單嘅。Agent 喺沙箱入面發 HTTP 請求,或者透過 function calling 叫外部服務。一個 Agent 對一個服務冇乜問題。但係接嘅服務一多,每個 Agent 同服務嘅配對都要單獨處理認證、工具描述同異常情況。做過微服務嘅人應該好熟悉,呢個就係經典嘅 M×N 集成問題。

CLI 都可以用,快、輕量,重用現有工具鏈。但係喺移動端、Web 端同雲託管平台呢啲冇 shell 嘅地方往往會四圍碰壁,認證都只可以靠磁盤上嘅憑證文件。講白咗,CLI 係本地開發嘅好幫手,離生產仲差一截。

MCP 行嘅係協議層。Agent 連接一個 MCP 服務器,服務器將你係統嘅能力暴露出來,認證、發現、語義描述都標準化咗。一個遠程服務器可以同時服務 Claude、ChatGPT、Cursor、VS Code 呢啲客戶端,部署喺邊度都得。MCP 嘅前期投入的確比前兩種大啲,但換嚟嘅係可移植性,同埋協議本身可以描述嘅嘢都更多。

我自己嘅感受係,本地開發階段 CLI 同 MCP 都夠用,但一旦 Agent 要上雲、要服務多個客戶端,MCP 基本上係唯一嘅選擇。咁點解 Anthropic 而家特別強調生產環境?

生產 Agent 行喺雲上

因為生產級 Agent 越嚟越多咁行喺雲上,佢哋需要連接嘅系統都喺雲上:數據存在嗰度,工單追蹤喺嗰度,基礎設施都喺嗰度。呢啲系統通常係遠程嘅、有認證嘅,啱啱係 MCP 擅長處理嘅場景。

從 Anthropic 自己嘅產品線都可以睇到呢個趨勢。前段時間發佈嘅 Managed Agents,底層就係靠 MCP 連接外部工具同數據源,之前嗰篇《Managed Agents 架構拆解》分析過佢嘅腦手分離設計。Claude Cowork、Claude Code Channels 都係類似嘅思路,MCP 喺裏面扮演嘅就係連接層嘅角色。MCP SDK 嘅月下載量由年初嘅 1 億升到 3 億,增速的確有啲猛。

不過 Anthropic 都冇話 MCP 就應該取代其他方式。API 係基礎,CLI 服務本地開發,MCP 覆蓋雲端。三條路最終都會並存。

咁問題就變成咗:決定用 MCP 之後,服務器點樣設計先好用?

MCP 服務器點樣設計先好用

Anthropic 目前 MCP 目錄裏面有 200 多個服務器。由呢啲實踐中佢哋提煉咗幾個設計模式,結合我自己寫 MCP 服務器嘅經驗,講下幾個我覺得最有價值嘅。

遠程服務器優先

只有遠程服務器先可以同時覆蓋 Web、移動端同雲端 Agent,呢個係分發嘅前提。本地服務器喺開發階段夠用,但想令 Agent 喺任何環境下都可以調用你嘅服務,一定要上遠程。

按意圖分組工具,唔好一比一鏡像 API

呢個我之前喺《Claude Code 終於解決咗 MCP 最大嘅痛點》提過,工具越少、描述越好,Agent 用起上嚟越準。一個 create_issue_from_thread 工具,好過等 Agent 自己拼 get_thread + parse_messages + create_issue + link_attachment 穩陣得多。

做過 Agent 開發嘅你應該都體會過,將底層 API 原封不動暴露俾模型,基本上就係賭佢可以自己編排出正確嘅調用序列。賭贏嘅概率唔高。我之前做 Kubernetes MCP 服務器嘅時候,最開始都係將 Kubernetes API 一比一映射成工具,結果模型淨係揀啱工具都要好幾輪,後來按運維場景重新分組,調用準確率提升咗好多。

大量 API 場景用代碼編排

如果你嘅服務有幾百個接口,按意圖分組都覆蓋唔曬。呢個時候 Cloudflare 嘅做法幾妙:只暴露兩個工具(搜索同執行),覆蓋咗大約 2500 個 API 端點,成個工具定義只佔 1K token。思路係等 Agent 寫一小段腳本,服務器喺沙箱裏面行,只返回結果。

用 MCP Apps 做交互

MCP Apps 係 MCP 協議嘅第一個官方擴展,允許工具返回交互式界面,圖表、表單、儀表盤,直接嵌喺對話入面渲染。你叫 Agent 查下數據庫嘅慢查詢,返回嘅唔係一堆文字,而係一個可以排序嘅交互式表格。呢個體驗一下字就提升上去嘞,Anthropic 話支持 MCP Apps 嘅服務器喺用戶留存上表現好很多,呢個唔難理解。

仲有一個叫 Elicitation 嘅能力都值得關注。佢令 MCP 服務器喺工具調用中途暫停,向用戶請求輸入。例如你叫 Agent 刪一個資源,服務器可以彈一個確認表單,而唔係直接執行。更敏感嘅操作例如 OAuth 登錄,可以將用戶引到瀏覽器入面完成,憑證唔經過 MCP 客戶端。呢個設計思路同之前傾過嘅 Managed Agents 嘅安全隔離一脈相承,敏感信息可以唔過手就唔過手。

認證呢塊終於唔使自己造輪子

講真,認證一直係 MCP 由開發到生產最令人頭痛嘅部分。本地開發時 MCP 服務器大多唔需要認證,或者直接用 API Key 求其。但係到咗生產環境,用戶授權、token 儲存、過期刷新、多租户隔離,每個環節都係坑。之前每個 MCP 服務器都要自己處理 OAuth 流程,各種邊角情況踩唔完。

最新嘅 MCP 規範喺呢塊改進咗唔少。CIMD(Client ID Metadata Documents)簡化咗客戶端註冊嘅 OAuth 流程,用戶首次授權更快,反覆彈授權框嘅情況都少咗。MCP SDK、Claude.ai 同 Claude Code 都已經支持呢個規範。

對雲端 Agent 嚟講,令牌嘅儲存同刷新係另一個痛點。Managed Agents 嘅 Vault 機制處理咗呢個問題:註冊一次用戶嘅 OAuth 令牌,創建 session 時引用 Vault ID,平台自動將憑證注入每個 MCP 連接,過期咗自己刷新。唔使自己搭密鑰管理服務,唔使每次調用傳 token。呢個思路同 Kubernetes 裏面 ServiceAccount 自動掛載 token 嘅邏輯幾似,等憑證管理變成基礎設施嘅一部分,應用層唔使操心。

上下文效率:Tool Search 同程序化調用

MCP 服務器越多,上下文佔用越大,呢個問題前面提到過。Anthropic 而家有兩個客戶端側嘅優化模式。

Tool Search 係按需加載工具定義,唔一次性全部塞入上下文。Agent 運行時搜索工具目錄,只拉取當前任務需要嘅工具。根據 Anthropic 嘅測試,工具定義相關嘅 token 佔用可以降低 85% 以上,選擇準確率基本不受影響。

Tool Search 上下文優化效果
Tool Search 上下文優化效果

程序化工具調用係喺代碼執行沙箱裏面處理工具返回結果,而唔係原樣掉返俾模型。Agent 可以喺代碼入面循環、過濾、聚合多次調用嘅結果,只將最終輸出放入上下文。複雜嘅多步工作流可以省返大約 37% 嘅 token。

兩個模式疊加使用嘅效果更好:上下文更精簡,往返次數更少,回應都更快。

Skills 同 MCP 係互補嘅

呢個話題之前都傾過。簡單講,MCP 俾 Agent 能力(可以叫咩工具、可以訪問咩數據),Skills 俾 Agent 知識(點樣用呢啲工具完成具體任務),兩者最好結合埋一齊使用。

Skills 和 MCP 的協作方式
Skills 同 MCP 嘅協作方式

具體有兩種組合模式。

第一種係將 Skills 同 MCP 服務器打包成 Plugin。Claude 嘅 Plugin 可以捆綁 Skills、MCP 服務器、Hooks、子 Agent 呢啲組件,一鍵分發。例如 Cowork 嘅數據 Plugin,裏面有 10 個 Skills 同 8 個 MCP 服務器,覆蓋 Snowflake、Databricks、BigQuery 呢啲數據工具。呢種模式令 Claude 由通用助手變成領域專家。

第二種係令 MCP 服務器自帶 Skill。Canva、Notion、Sentry 呢啲廠商已經喺度做緊,喺 Claude 嘅目錄入面將 Skill 同 Connector 放埋一齊。MCP 社區都喺度做一個擴展,等服務器直接分發 Skills,客戶端自動繼承,版本跟住 API 走。

我嘅體會係:MCP 服務器只提供工具嘅話,Agent 每次都要自己摸索調用順序同參數搭配,效率唔高。Skill 將最佳實踐編碼入去,等於俾 Agent 附咗一份操作手冊,開箱就可以按套路嚟。

寫喺最後

回頭望生產環境 Agent 集成外部系統呢件事,由於 Agent 行喺雲上,需要連接嘅服務都喺雲上,中間就需要一個標準化嘅協議層。

相比直接 API 調用同命令行 CLI,MCP 目前係呢個位置上最合適嘅協議,特別係遠程 MCP 服務器。MCP 嘅優勢在於佢係開放協議,唔綁定任何一家模型廠商,一個服務器起好咗,Claude、ChatGPT 之類嘅任意 AI Agent 都可以用。


相關資源:

  • • 原文連結:https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
  • • MCP SDK 文檔:https://modelcontextprotocol.io/docs/sdk
  • • MCP Apps 擴展:https://modelcontextprotocol.io/extensions/apps/overview
  • • 高級工具使用指南:https://www.anthropic.com/engineering/advanced-tool-use
  • • 寫好 Agent 工具:https://www.anthropic.com/engineering/writing-tools-for-agents
  • • MCP 規範(含 CIMD 同 Elicitation):https://modelcontextprotocol.io/specification/2025-11-25

好啦,今日就傾到呢度。如果你都喺度探索 AI Agent 技術同 MCP 集成,歡迎關注 Feisky 公眾號,我會定期分享實踐中嘅發現同踩坑經驗。


題記:本文編譯自 Anthropic 博客《Building agents that reach production systems with MCP[1]》。文章從 Agent 連接外部系統的三條路講起,重點梳理了 MCP 服務器的設計模式、認證標準化、上下文優化,以及 Skills 的互補定位。不算長,但信息密度不低,尤其是 Cloudflare 的代碼編排模式和 Vault 的憑證管理思路,值得做 MCP 服務器的人細看和參考。

我之前給 Claude Code 配 MCP 服務器的時候,最頭疼的是上下文佔用的問題,後來《Claude Code 終於解決了 MCP 最大的痛點》那篇寫過 Tool Search 怎麼解決這個事。但用得越多越發現,上下文只是冰山一角。

本地開發時,Agent 調個 API、跑個命令行工具,一切都很絲滑。但等你想把它放到雲上跑,問題就來了:CLI 工具沒有 shell 可用,API 調用的認證憑證要自己管,每對接一個新服務就要從頭寫一套集成代碼。

剛剛看到 Anthropic 發了一篇博客,系統梳理了 Agent 連接外部系統的三條路,以及為什麼生產環境下 MCP 可能是最務實的選擇,分享一下,供大家參考。

把 Agent 接入外部系統

Anthropic 把 Agent 接入外部系統的方式分成三種:直接調 API、用 CLI,以及走 MCP 協議。

直接調 API 是最多人的起點,也是最簡單的。Agent 在沙箱裏發 HTTP 請求,或者通過 function calling 調用外部服務。一個 Agent 對一個服務沒什麼問題。但接的服務一多,每個 Agent 和服務的配對都要單獨處理認證、工具描述和異常情況。做過微服務的人應該很熟悉,這就是經典的 M×N 集成問題。

CLI 也能用,快、輕量,複用現有工具鏈。但在移動端、Web 端和雲託管平台這些沒有 shell 的地方往往會到處碰壁,認證也只能靠磁盤上的憑證文件。說白了,CLI 是本地開發的好幫手,離生產還差一截。

MCP 走的是協議層。Agent 連上一個 MCP 服務器,服務器把你係統的能力暴露出來,認證、發現、語義描述都標準化了。一個遠程服務器可以同時服務 Claude、ChatGPT、Cursor、VS Code 這些客戶端,部署在哪都行。MCP 的前期投入確實比前兩種大一些,但換來的是可移植性,以及協議本身能描述的東西也更多。

我自己的感受是,本地開發階段 CLI 和 MCP 都夠用,但一旦 Agent 要上雲、要服務多個客戶端,MCP 基本是唯一的選擇。那為什麼 Anthropic 現在特別強調生產環境?

生產 Agent 跑在雲上

因為生產級 Agent 越來越多地跑在雲上,它們需要連接的系統也在雲上:數據存在那裏,工單跟蹤在那裏,基礎設施也在那裏。這些系統通常是遠程的、帶認證的,正好是 MCP 擅長處理的場景。

從 Anthropic 自己的產品線也能看出這個趨勢。前段時間發佈的 Managed Agents,底層就是靠 MCP 連接外部工具和數據源,之前那篇《Managed Agents 架構拆解》分析過它的腦手分離設計。Claude Cowork、Claude Code Channels 也是類似的思路,MCP 在裏面扮演的就是連接層的角色。MCP SDK 的月下載量從年初的 1 億漲到了 3 億,增速確實有點猛。

不過 Anthropic 也沒說 MCP 就應該替代其他方式。API 是基礎,CLI 服務本地開發,MCP 覆蓋雲端。三條路最終都會並存。

那問題就變成了:決定用 MCP 之後,服務器怎麼設計才好用?

MCP 服務器怎麼設計才好用

Anthropic 目前 MCP 目錄裏有 200 多個服務器。從這些實踐中他們提煉了幾個設計模式,結合我自己寫 MCP 服務器的經驗,聊聊幾個我覺得最有價值的。

遠程服務器優先

只有遠程服務器才能同時覆蓋 Web、移動端和雲端 Agent,這是分發的前提。本地服務器在開發階段夠用,但想讓 Agent 在任何環境下都能調用你的服務,必須上遠程。

按意圖分組工具,不要一比一鏡像 API

這個我之前在《Claude Code 終於解決了 MCP 最大的痛點》提過,工具越少、描述越好,Agent 用起來越準。一個 create_issue_from_thread 工具,比讓 Agent 自己拼 get_thread + parse_messages + create_issue + link_attachment 靠譜得多。

做過 Agent 開發的你應該都體會過,把底層 API 原封不動暴露給模型,基本就是在賭它能自己編排出正確的調用序列。賭贏的概率不高。我之前做 Kubernetes MCP 服務器的時候,最開始也是把 Kubernetes API 一比一映射成工具,結果模型光是選對工具就要好幾輪,後來按運維場景重新分組,調用準確率提升了很多。

大量 API 場景用代碼編排

如果你的服務有幾百個接口,按意圖分組也覆蓋不完。這時候 Cloudflare 的做法挺妙的:只暴露兩個工具(搜索和執行),覆蓋了大約 2500 個 API 端點,整個工具定義只佔 1K token。思路是讓 Agent 寫一小段腳本,服務器在沙箱裏跑,只返回結果。

用 MCP Apps 做交互

MCP Apps 是 MCP 協議的第一個官方擴展,允許工具返回交互式界面,圖表、表單、儀表盤,直接嵌在對話裏渲染。你讓 Agent 查一下數據庫的慢查詢,返回的不是一堆文本,而是一個可排序的交互式表格。這體驗一下子就提升上去了,Anthropic 說支持 MCP Apps 的服務器在用戶留存上表現好很多,這個不難理解。

還有一個叫 Elicitation 的能力也值得關注。它讓 MCP 服務器在工具調用中途暫停,向用戶請求輸入。比如你讓 Agent 刪一個資源,服務器可以彈一個確認表單,而不是直接執行。更敏感的操作比如 OAuth 登錄,可以把用戶引到瀏覽器裏完成,憑證不經過 MCP 客戶端。這個設計思路和之前聊過的 Managed Agents 的安全隔離一脈相承,敏感信息能不過手就不過手。

認證這塊終於不用自己造輪子了

說實話,認證一直是 MCP 從開發到生產最讓人頭疼的部分。本地開發時 MCP 服務器大多不需要認證,或者直接用 API Key 湊合。但到了生產環境,用戶授權、token 存儲、過期刷新、多租户隔離,每個環節都是坑。之前每個 MCP 服務器都得自己處理 OAuth 流程,各種邊角情況踩不完。

最新的 MCP 規範在這塊改進了不少。CIMD(Client ID Metadata Documents)簡化了客戶端註冊的 OAuth 流程,用戶首次授權更快,反覆彈授權框的情況也少了。MCP SDK、Claude.ai 和 Claude Code 都已經支持這個規範。

對雲端 Agent 來說,令牌的存儲和刷新是另一個痛點。Managed Agents 的 Vault 機制處理了這個問題:註冊一次用戶的 OAuth 令牌,創建 session 時引用 Vault ID,平台自動把憑證注入每個 MCP 連接,過期了自己刷新。不用自己搭密鑰管理服務,不用每次調用傳 token。這個思路和 Kubernetes 裏 ServiceAccount 自動掛載 token 的邏輯挺像的,讓憑證管理變成基礎設施的一部分,應用層不用操心。

上下文效率:Tool Search 和程序化調用

MCP 服務器越多,上下文佔用越大,這個問題前面提到過。Anthropic 現在有兩個客戶端側的優化模式。

Tool Search 是按需加載工具定義,不一次性全塞進上下文。Agent 運行時搜索工具目錄,只拉取當前任務需要的工具。根據 Anthropic 的測試,工具定義相關的 token 佔用能降低 85% 以上,選擇準確率基本不受影響。

Tool Search 上下文優化效果
Tool Search 上下文優化效果

程序化工具調用是在代碼執行沙箱裏處理工具返回結果,而不是原樣扔回給模型。Agent 可以在代碼裏循環、過濾、聚合多次調用的結果,只把最終輸出放進上下文。複雜的多步工作流能省掉大約 37% 的 token。

兩個模式疊加使用的效果更好:上下文更精簡,往返次數更少,響應也更快。

Skills 和 MCP 是互補的

這個話題之前也聊過。簡單說,MCP 給 Agent 能力(能調什麼工具、能訪問什麼數據),Skills 給 Agent 知識(怎麼用這些工具完成具體任務),兩者最好結合着一起使用。

Skills 和 MCP 的協作方式
Skills 和 MCP 的協作方式

具體有兩種組合模式。

第一種是把 Skills 和 MCP 服務器打包成 Plugin。Claude 的 Plugin 可以捆綁 Skills、MCP 服務器、Hooks、子 Agent 這些組件,一鍵分發。比如 Cowork 的數據 Plugin,裏面有 10 個 Skills 和 8 個 MCP 服務器,覆蓋 Snowflake、Databricks、BigQuery 這些數據工具。這種模式讓 Claude 從通用助手變成領域專家。

第二種是讓 MCP 服務器自帶 Skill。Canva、Notion、Sentry 這些廠商已經在做了,在 Claude 的目錄裏把 Skill 和 Connector 放在一起。MCP 社區也在做一個擴展,讓服務器直接分發 Skills,客戶端自動繼承,版本跟着 API 走。

我的體會是:MCP 服務器只提供工具的話,Agent 每次都得自己摸索調用順序和參數搭配,效率不高。Skill 把最佳實踐編碼進去,等於給 Agent 附了一份操作手冊,開箱就能按套路來。

寫在最後

回頭看生產環境 Agent 集成外部系統這件事,由於 Agent 跑在雲上,需要連接的服務也在雲上,中間就需要一個標準化的協議層。

相比直接 API 調用和命令行 CLI,MCP 目前是這個位置上最合適的協議,特別是遠程 MCP 服務器。MCP 的優勢在於它是開放協議,不綁定任何一家模型廠商,一個服務器建好了,Claude、ChatGPT 之類的任意 AI Agent 都能用。


相關資源:

  • • 原文連結:https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
  • • MCP SDK 文檔:https://modelcontextprotocol.io/docs/sdk
  • • MCP Apps 擴展:https://modelcontextprotocol.io/extensions/apps/overview
  • • 高級工具使用指南:https://www.anthropic.com/engineering/advanced-tool-use
  • • 寫好 Agent 工具:https://www.anthropic.com/engineering/writing-tools-for-agents
  • • MCP 規範(含 CIMD 和 Elicitation):https://modelcontextprotocol.io/specification/2025-11-25

好了,今天就聊到這兒。如果你也在探索 AI Agent 技術和 MCP 集成,歡迎關注 Feisky 公眾號,我會定期分享實踐中的發現和踩坑經驗。