題記:呢篇文編譯自 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 上下文優化效果程序化工具調用係喺代碼執行沙箱裏面處理工具返回結果,而唔係原樣掉返俾模型。Agent 可以喺代碼入面循環、過濾、聚合多次調用嘅結果,只將最終輸出放入上下文。複雜嘅多步工作流可以省返大約 37% 嘅 token。
兩個模式疊加使用嘅效果更好:上下文更精簡,往返次數更少,回應都更快。
Skills 同 MCP 係互補嘅
呢個話題之前都傾過。簡單講,MCP 俾 Agent 能力(可以叫咩工具、可以訪問咩數據),Skills 俾 Agent 知識(點樣用呢啲工具完成具體任務),兩者最好結合埋一齊使用。
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 公眾號,我會定期分享實踐中嘅發現同踩坑經驗。